squeak and the jvm
Locked
 
|
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 [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
Hi Michael,
There are some really talented people doing some of this now. See: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-September/108634 .html But what is even more exciting to me is the Strongtalk VM. The guys that wrote the Java VM first wrote Strongtalk. Sun shelved it but recently released the VM as Open Source. What I would like to see is a Strongtalk VM for Squeak! http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-September/108247 .html Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists [hidden email] > -----Original Message----- > From: Michael Kohout > Sent: Wednesday, November 08, 2006 10:56 AM > > 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 > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
In reply to this post by mwkohout
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 [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
In reply to this post by Ron Teitelbaum
Sweet. I've heard of Strongtalk, don't know much about it, but great.
But in my humble opinion, if running on the jvm will allow people to use the java libs and allow "plugins" written in java(thus lowering the barrier of entry for people like me, since we'd no longer have to rebuild the whole vm) that would be a real bon to bringing smalltalk/squeak into the corporate world. At my employer(the largest state university system in the state of Minnesota, aka MnSCU) yesterday we had our first meeting about a new, multiyear project we're embarking on. We settled on Spring, JPA, and Struts 1.3. *Settled* being the operative word. No one is happy. We like Squeak and it's image based development, ease in testing, and quick development cycles. BUT we must have stuff like Oracle support and broad, well documented apis(and no, 'look at the source' doesn't count) before we can throw millions of dollars at a project using it. Squeak, if it hitches itself to the jvm, and if it allows people to use Java APIs with the minimum of fuss, and doesn't lose it's soul in the process could come into very common usage. And you'd all be carried like heroes through my cube farm. Mike Kohout On 11/8/06, Ron Teitelbaum <[hidden email]> wrote: > Hi Michael, > > There are some really talented people doing some of this now. See: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-September/108634 > .html > > But what is even more exciting to me is the Strongtalk VM. The guys that > wrote the Java VM first wrote Strongtalk. Sun shelved it but recently > released the VM as Open Source. What I would like to see is a Strongtalk VM > for Squeak! > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-September/108247 > .html > > Ron Teitelbaum > President / Principal Software Engineer > US Medical Record Specialists > [hidden email] > > > > -----Original Message----- > > From: Michael Kohout > > Sent: Wednesday, November 08, 2006 10:56 AM > > > > 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 > > [hidden email] > > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
In reply to this post by Klaus D. Witzel
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. 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? On 11/8/06, Klaus D. Witzel <[hidden email]> 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 > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Re: Re: squeak and the jvm
|
|
Hi Mike,
On 11/8/06, Michael Kohout <[hidden email]> 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 [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
In reply to this post by mwkohout
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 <[hidden email]> 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 >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
Thanks Klaus. So....does #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 <[hidden email]> 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 <[hidden email]> 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 > >> [hidden email] > >> http://lists.squeakfoundation.org/mailman/listinfo/beginners > >> > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
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 <[hidden email]> 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 <[hidden email]> 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 >> >> [hidden email] >> >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> >> >> >> >> _______________________________________________ >> Beginners mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Re: squeak and the jvm
|
|
In reply to this post by Klaus D. Witzel
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 [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
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 [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
«
Return to Squeak - Beginners
|
1 view|%1 views
| Free forum by Nabble | Edit this page |