On Wed, 08 Nov 2006 19:07:40 +0100, Michael Kohout wrote:
Thanks Klaus. So....does #become change the address of what 'after' points to,
Yes, and vice versa, simultaneously.
so these two references now point to the same location in memory,
No, but there is a variant of #become: which can do that if needed.
or does it clone what 'before' references and point 'after' to it?
No, there is no cloning (copying) involved, just a pointer swap whereever these two pointers appear in the .image (so in every object pointing to them).
Or does it do something more complex?
No, it's just one of the two straight forward cases above.
/Klaus
On 11/8/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
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 klaus.witzel@cobss.com wrote:
Hi Mike,
if by "more message oriented opcode" you mean Gilad Bracha's Invokedynamic opcode
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"
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