[Newbies] Re: squeak and the jvm
Klaus D. Witzel
klaus.witzel at cobss.com
Wed Nov 8 17:43:40 UTC 2006
on Wed, 08 Nov 2006 18:13:17 +0100, you wrote:
> Yes, this is what I was referring to. Hotswapping is sort of there
> for the jvm. When I use Eclipse, it tries to hotswap. Sometimes it
> fails. Sometimes it doesn't. But, referring the criteria in my reply
> to Ron's email, would loosing guaranteed hotswapping cause Squeak to
> "lose it's soul?" I dunnknow. I'm a newbie. And I don't write
> Squeak for a living.
Having read your response to Ron's I think that all you ask for is to
compile Squeak source code into JVM bytecode such that your application
code can access the existing Java API's.
Is this correct?
If so, you'd need no hotswapping: your classes, inst vars and methods
don't change when your app runs in production mode.
In my previous response I considered running *all* of the Squeak .image on
the JVM, that would be quite a difference and would rely on 100%[tm]
hotswapping (etc) being supported.
> But in a Java environment I can tell you it isn't that bad. And it's
> downsides could be mitigated so long as Squeak/JVM could provide some
> runtime mechanism to register some services to begin at startup(like
> Commanche, etc). Maybe this would be a tolerable compromose to most
> Squeak developers if it provides more opportunities to use Squeak in
> the wider world and enlarges it's user base.
> But I don't have a clue about #become. What does it do?
It changes the object identity of receiver and argument regardless of
where they are referenced (in the Squeak .image), like in
before := 'Klaus'.
after := 'kwl'.
before become: after.
after printString "prints 'Klaus' "
There are applications in Smalltalk/Squeak which depend on #become: for
example when growing an OrderedCollection.
But if in such cases (like OrderedCollection) you'd always use a
corresponding Java class then, again, it wouldn't matter.
I can say so because I have written a compiler for Smalltalk source code
into JVM bytecode, which works and can compile itself, but it's not ready
for prime time yet (and all the limitations of the JVM like #become: and
hotswapping, etc, apply).
> On 11/8/06, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
>> Hi Mike,
>> if by "more message oriented opcode" you mean Gilad Bracha's
>> - http://www.google.com/search?q=jvm+Invokedynamic
>> this is not sufficient for full Smalltalk/Squeak. Though it may be
>> sufficient for scripting languages (languages in which, usually, types
>> unknown at compile-time).
>> What is also needed is full "hotswapping"
>> - http://blogs.sun.com/gbracha/entry/jsr292_and_hotswapping
>> and support for Smalltalk's #become: ...
>> But, perhaps, you had something else in mind?
>> On Wed, 08 Nov 2006 16:55:50 +0100, Michael Kohout wrote:
>> > I suppose this is more of a pie in the sky type question, but with the
>> > changes coming to the Java virtual machine in version 7, where the jvm
>> > itself provides a more message oriented opcode, has any consideration
>> > gone into perhaps porting squeak to run on the jvm?
>> > I'm aware of talks2 but it seems as if development on that
>> > effort(based on the public releases/news) is at a standstill.
>> > thanks
>> > Mike Kohout
>> Beginners mailing list
>> Beginners at lists.squeakfoundation.org
More information about the Beginners