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
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 Ron@USMedRec.com
-----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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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 Ron@usmedrec.com 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 Ron@USMedRec.com
-----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 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
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
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 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
Hi Mike,
On 11/8/06, Michael Kohout mwkohout@gmail.com 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
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
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 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
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
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
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:
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@lists.squeakfoundation.org
-
Benjamin Schroeder -
Klaus D. Witzel -
Michael Haupt -
Michael Kohout -
Ron Teitelbaum