[Newbies] Re: squeak and the jvm
Hi Ben, on Wed, 08 Nov 2006 20:33:49 +0100, you wrote: On Nov 8, 2006, at 12:43 PM, Klaus D. Witzel 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. If what you want to do is to access Java objects from Squeak (and vice versa), you could also consider running the two VMs in parallel, and setting up a sort of bridge to communicate between them. Having thought over this for a while, I must say that a VM^2 solution sounds intriguing for folks who are in need of the static j* libraries (for some reason) but at the same time do not want to miss incremental development, image based persistence and BlockContexts :) This might help you even if your eventual goal is to port Squeak to run in JVM bytecode. :) Sure. We did a bridge for Squeak and .NET: http://www.saltypickle.com/SqueakDotNet Yes, I'm an admirer of that effort. I know people have asked for Sq/.Net and (hopefully) are using it (Hans, this is what I was talking about, perhaps you already have this URL?). /Klaus That program is a port of a similar bridge we did for Ruby. In both cases, we started out running the two VMs in different processes, and just sending socket-based messages between them; later, we got things working in a single process. Getting the basics up and running for one of these things is actually pretty quick, in my experience. I think that the bridge approach has a lot to recommend it, in that you retain the advantages of both environments, and can use the regular production VM of both. (There are of course still some difficulties.) Benjamin Schroeder ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
[Newbies] Re: squeak and the jvm
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
Re: Re: [Newbies] Re: squeak and the jvm
Hi Mike, On 11/8/06, Michael Kohout [EMAIL PROTECTED] 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. the HotSwap features of the JVM are fairly constrained when compared to those available in Smalltalk. Java's HotSwap does not allow for schema changes, i.e., you cannot add or remove fields to classes (or change their type, which would albeit be not too interesting in a Smalltalk implementation). You also cannot add or remove any methods. You cannot change methods' signatures. All you *can* do is change the implementations (i.e., bytecodes) of existing methods, but recall that you cannot change their signature, i.e., add or remove parameters or return types. But I don't have a clue about #become. What does it do? Take this example: someObject become: someOtherObject The effect of this code is that all references to someObject are turned into references to someOtherObject, and vice versa. Literally, the object becomes another one. Best, Michael ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
[Newbies] Re: squeak and the jvm
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
Re: [Newbies] Re: squeak and the jvm
Thanks Klaus. Sodoes #become change the address of what 'after' points to, so these two references now point to the same location in memory, or does it clone what 'before' references and point 'after' to it? Or does it do something more complex? On 11/8/06, Klaus D. Witzel [EMAIL PROTECTED] 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 [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 ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
[Newbies] Re: squeak and the jvm
On Wed, 08 Nov 2006 19:07:40 +0100, Michael Kohout wrote: Thanks Klaus. Sodoes #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 [EMAIL PROTECTED] 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 [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 ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: squeak and the jvm
On Nov 8, 2006, at 12:43 PM, Klaus D. Witzel 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. If what you want to do is to access Java objects from Squeak (and vice versa), you could also consider running the two VMs in parallel, and setting up a sort of bridge to communicate between them. This might help you even if your eventual goal is to port Squeak to run in JVM bytecode. We did a bridge for Squeak and .NET: http://www.saltypickle.com/SqueakDotNet That program is a port of a similar bridge we did for Ruby. In both cases, we started out running the two VMs in different processes, and just sending socket-based messages between them; later, we got things working in a single process. Getting the basics up and running for one of these things is actually pretty quick, in my experience. I think that the bridge approach has a lot to recommend it, in that you retain the advantages of both environments, and can use the regular production VM of both. (There are of course still some difficulties.) Benjamin Schroeder ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
