Hi Mike,
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).
/Klaus
On 11/8/06, Klaus D. Witzel <[EMAIL PROTECTED]> wrote:
Hi Mike,
if by "more message oriented opcode" you mean Gilad Bracha's
Invokedynamic
opcode
- 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
are
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?
/Klaus
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@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
