Dear all, today started the PyPy-Squeak sprint in Bern, with the bold goal of using PyPy the generate a Squeak VM. A sprint is one week of full- time hacking. If you are interested in daily progress reports, please refer to
http://pypysqueak.blogspot.com/
cheers, AA
Sounds intriguing. But can you elaborate on what it means to "use PyPy to generate a Squeak VM"?
Cheers, - Andreas
Adrian Kuhn wrote:
Dear all, today started the PyPy-Squeak sprint in Bern, with the bold goal of using PyPy the generate a Squeak VM. A sprint is one week of full-time hacking. If you are interested in daily progress reports, please refer to
http://pypysqueak.blogspot.com/cheers, AA
Hi ho,
I'd love to be in Bern right now... :-/
On 10/22/07, Andreas Raab andreas.raab@gmx.de wrote:
Sounds intriguing. But can you elaborate on what it means to "use PyPy to generate a Squeak VM"?
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
But then... (Adrian, you know what comes next.)
Short version: Why Python? Why not Squeak?
Long version: we've got a wonderful language, Smalltalk, and a great implementation of that language, Squeak. There is an implementation of Squeak "in itself", or rather, in Slang. Close, but, alas, no cigar.
Slang is not much more than a Smalltalk-ish syntax for C. Some things that are used most naturally in Smalltalk simply cannot be done in Slang, which adds a great deal of complexity to VM development for Squeak. RPython, on the other hand, is a minimally stripped-down version of Python - it almost lays the full power of Python into the hands of the VM developer.
So what about, instead of using an "alien" language for developing the Squeak VM, Squeak itself? Possibly after a minimal strip down, much like the one applied to Python?
The main benefit for Squeak VM development that can be drawn from the PyPy project is not RPython. Or: should not be RPython. Maybe I'm overly puristic, but hey, I still favour Squeak over Python for whatever reasons, so I'm not being inconsistent. ;-)
The main benefit, in my opinion, is in the way the PyPy tool chain is built. The approach of taking away abstractions step by step and finally generating C code is elegant and well-designed. A similar tool chain for Squeak would be a great thing to have. It would also allow Squeak to remain a "Smalltalk implemented in itself", which is a nice property.
So, instead of PySquee or SqueePy, what about SqueeSquee?
(Disclaimer: this is not to bash PyPy. Not at all. It's amazing work that takes one of the edges off of VM development in my very humble opinion, and that should be widely adopted beyond the Python realm. This also is not to bash VMMaker or any of its contributors or maintainers. See above.)
Best,
Michael
Michael Haupt wrote:
On 10/22/07, Andreas Raab andreas.raab@gmx.de wrote:
Sounds intriguing. But can you elaborate on what it means to "use PyPy to generate a Squeak VM"?
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
And what exactly does *that* mean? Rewrite the code generator in Python to generate C code from Slang? Rewrite the VM in Python? Use PyPy translation tools to generate code from Squeak parse trees? There are so many possible ways of "using tools" ...
Cheers, - Andreas
But then... (Adrian, you know what comes next.)
Short version: Why Python? Why not Squeak?
Long version: we've got a wonderful language, Smalltalk, and a great implementation of that language, Squeak. There is an implementation of Squeak "in itself", or rather, in Slang. Close, but, alas, no cigar.
Slang is not much more than a Smalltalk-ish syntax for C. Some things that are used most naturally in Smalltalk simply cannot be done in Slang, which adds a great deal of complexity to VM development for Squeak. RPython, on the other hand, is a minimally stripped-down version of Python - it almost lays the full power of Python into the hands of the VM developer.
So what about, instead of using an "alien" language for developing the Squeak VM, Squeak itself? Possibly after a minimal strip down, much like the one applied to Python?
The main benefit for Squeak VM development that can be drawn from the PyPy project is not RPython. Or: should not be RPython. Maybe I'm overly puristic, but hey, I still favour Squeak over Python for whatever reasons, so I'm not being inconsistent. ;-)
The main benefit, in my opinion, is in the way the PyPy tool chain is built. The approach of taking away abstractions step by step and finally generating C code is elegant and well-designed. A similar tool chain for Squeak would be a great thing to have. It would also allow Squeak to remain a "Smalltalk implemented in itself", which is a nice property.
So, instead of PySquee or SqueePy, what about SqueeSquee?
(Disclaimer: this is not to bash PyPy. Not at all. It's amazing work that takes one of the edges off of VM development in my very humble opinion, and that should be widely adopted beyond the Python realm. This also is not to bash VMMaker or any of its contributors or maintainers. See above.)
Best,
Michael
Hi Andreas,
On 10/22/07, Andreas Raab andreas.raab@gmx.de wrote:
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
And what exactly does *that* mean? Rewrite the code generator in Python to generate C code from Slang? Rewrite the VM in Python? Use PyPy translation tools to generate code from Squeak parse trees? There are so many possible ways of "using tools" ...
it means (simplified) rewriting the VM in Python and compiling it using the PyPy tool chain.
Best,
Michael
Michael Haupt wrote:
On 10/22/07, Andreas Raab andreas.raab@gmx.de wrote:
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
And what exactly does *that* mean? Rewrite the code generator in Python to generate C code from Slang? Rewrite the VM in Python? Use PyPy translation tools to generate code from Squeak parse trees? There are so many possible ways of "using tools" ...
it means (simplified) rewriting the VM in Python and compiling it using the PyPy tool chain.
How interesting! I'm very curious about the results. There are at least two areas where I could see some interesting outcomes:
1) How to write a Squeak VM that actually consists of objects. This will be interesting since I've always felt that it shouldn't really be all that hard to drop the limitations of the code generator (after all, Ian's entire work is based on a comparable approach) so it'll be interesting to see what the structure of this VM will be.
2) Performance comparisons. It should be interesting to see how a PyPy VM compares in benchmarks, either for improving PyPy (or learning how and why a Squeak VM is different than for example a Python VM) or what to do to make the C Squeak VM faster. This should be in particular relevant if PyPy does some dataflow analysis which we've never run on the Slang code.
Cheers, - Andreas
Hi Andreas and Michael,
On 22 Oct 2007, at 23:25 , Michael Haupt wrote:
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
And what exactly does *that* mean? Rewrite the code generator in Python to generate C code from Slang? Rewrite the VM in Python? Use PyPy translation tools to generate code from Squeak parse trees? There are so many possible ways of "using tools" ...
it means (simplified) rewriting the VM in Python and compiling it using the PyPy tool chain.
more precise, it means writing a Smalltalk bytecode interpreter in RPython and using the PyPy tool chain to generate a VM out of this.
Why not SqueeSquee?
We discussed this option yesterday. Its first step would be to define a subset of Smalltalk in the same way it is done with RPython (reduced Python). Let's call this RSqueak. Then, one would implement a new front end for the PyPy tool chain, based on RSqueak and written in Smalltalk. Like that we could feed the chain from Smalltalk, and later start to build our own VM generation tool chain in Smalltalk.
Alas, we feel not yet ready to do that. The Pypy sprinters miss in- depth understanding of Smalltalk, whereas we Squeak sprinters miss in- depth understanding of PyPy. Hence we decided for the current goal to learn from each other, keeping SqueeSquee as a long term goal in mind.
That's at least how I grok this week's goals. But, that I initiated this sprint does not mean that my view is authoritative, the other sprinters best speak for themselves. I will ask the other sprinters to join the discussion on this list also today...
cheers, AA
Hi again,
On 10/23/07, Andreas Raab andreas.raab@gmx.de wrote:
So how does RPython compare to Slang? Or Pepsi for that matter?
RPython is a full-fledged Python with some restrictions: for example, lists may only contain elements of the same type. I quote from the DLS paper on PyPy:
"This sublanguage is not restricted syntactically, but only in the way it manipulates objects of different types. The restrictions are a compromise between the expressivity and the need to statically infer enough type information to generate efficient code. RPython still supports exceptions, inheritance but limited to single inheritance with some mix-in support, dynamic dispatch, to some extent keywords arguments and varargs, first-class function and class values, limited use of bound methods, runtime isinstance and type queries, but no runtime reflection. Bindings in class and global namespaces are assumed constant. RPython code can be run on a Python interpreter without severe semantics mismatches."
That is quite unlike Slang, isn't it?
BTW I don't think that, should SqueeSquee be approached one day, there will have to be some kind of RSqueak. If Pepsi is the target language of a SqueeSquee "VMMaker", then the differences are not too large.
Best,
Michael
Hi Adrian,
On 10/23/07, Adrian Kuhn akuhn@gmx.ch wrote:
Why not SqueeSquee?
We discussed this option yesterday. Its first step would be to define a subset of Smalltalk in the same way it is done with RPython (reduced Python). Let's call this RSqueak. Then, one would implement a new front end for the PyPy tool chain, based on RSqueak and written in Smalltalk. Like that we could feed the chain from Smalltalk, and later start to build our own VM generation tool chain in Smalltalk.
oh, I was not suggesting to reuse the entire PyPy tool chain, but rather to reuse the ideas that have become manifest in it. I also don't think that RSqueak will be absolutely necessary, given that Pepsi could be the target.
Nevertheless, good luck for the sprint!
Best,
Michael
I am intruiged by what motivated this? Is it curiosity, will it create a VM that is better in some way, will it result in a better mechanism for creating VMs?
Joerg
-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Adrian Kuhn Sent: October 22, 2007 11:43 PM To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] Pypy-Squeak VM generation news
Hi Andreas and Michael,
On 22 Oct 2007, at 23:25 , Michael Haupt wrote:
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
And what exactly does *that* mean? Rewrite the code generator in Python to generate C code from Slang? Rewrite the VM in
Python? Use
PyPy translation tools to generate code from Squeak parse trees? There are so many possible ways of "using tools" ...
it means (simplified) rewriting the VM in Python and compiling it using the PyPy tool chain.
more precise, it means writing a Smalltalk bytecode interpreter in RPython and using the PyPy tool chain to generate a VM out of this.
Yes, curiosity. At least for me. It is to learn how the pypy tool chain works and to learn how a Squeak VM works. The first was fully unknown to me, the latter not in details. Regarding the features of the VM that will result from this endeavor ... that's open, it has not yet been generated, neither benchmarked :)
cheers, AA
On 25 Oct 2007, at 19:37 , Joerg Beekmann wrote:
I am intruiged by what motivated this? Is it curiosity, will it create a VM that is better in some way, will it result in a better mechanism for creating VMs?
Joerg
-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Adrian Kuhn Sent: October 22, 2007 11:43 PM To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] Pypy-Squeak VM generation news
Hi Andreas and Michael,
On 22 Oct 2007, at 23:25 , Michael Haupt wrote:
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
And what exactly does *that* mean? Rewrite the code generator in Python to generate C code from Slang? Rewrite the VM in
Python? Use
PyPy translation tools to generate code from Squeak parse trees? There are so many possible ways of "using tools" ...
it means (simplified) rewriting the VM in Python and compiling it using the PyPy tool chain.
more precise, it means writing a Smalltalk bytecode interpreter in RPython and using the PyPy tool chain to generate a VM out of this.
Pypy is several orders of magnitude more complex than what we have in place now. So I'm curious to learn what that machinery can achieve for Squeak, too.
- Bert -
On Oct 25, 2007, at 14:30 , Adrian Kuhn wrote:
Yes, curiosity. At least for me. It is to learn how the pypy tool chain works and to learn how a Squeak VM works. The first was fully unknown to me, the latter not in details. Regarding the features of the VM that will result from this endeavor ... that's open, it has not yet been generated, neither benchmarked :)
cheers, AA
On 25 Oct 2007, at 19:37 , Joerg Beekmann wrote:
I am intruiged by what motivated this? Is it curiosity, will it create a VM that is better in some way, will it result in a better mechanism for creating VMs?
Joerg
-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Adrian Kuhn Sent: October 22, 2007 11:43 PM To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] Pypy-Squeak VM generation news
Hi Andreas and Michael,
On 22 Oct 2007, at 23:25 , Michael Haupt wrote:
My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
And what exactly does *that* mean? Rewrite the code generator in Python to generate C code from Slang? Rewrite the VM in
Python? Use
PyPy translation tools to generate code from Squeak parse trees? There are so many possible ways of "using tools" ...
it means (simplified) rewriting the VM in Python and compiling it using the PyPy tool chain.
more precise, it means writing a Smalltalk bytecode interpreter in RPython and using the PyPy tool chain to generate a VM out of this.
Hi,
On 10/25/07, Joerg Beekmann Joerg@deepcovelabs.com wrote:
I am intruiged by what motivated this? Is it curiosity, will it create a VM that is better in some way, will it result in a better mechanism for creating VMs?
my hope is that it will lead to a different and more high-level development approach for the Squeak VM. While Slang does a good job for the VM as it is, it is certainly not using high-level abstractions (and never had the intention to), which would be much more convenient.
Of course, high-level abstractions may prevent dealing with low-level details, which are all over the place in VM implementations. This is where the tool chain comes into play: the gory details are realised by means of applying smart tools to the high-level source code.
I think the PyPy approach is extremely promising.
Best,
Michael
Good Morning in Bern
and happy PyPySqueak :)
Thank you very much for keeping the rest of the world informed!
BTW the codespeak.net server seems to be unreachable from here :(
- http://codespeak.net/~cfbolz/squeak-brainstorming.jpg
/Klaus
On Mon, 22 Oct 2007 22:07:54 +0200, Adrian Kuhn wrote:
Dear all, today started the PyPy-Squeak sprint in Bern, with the bold goal of using PyPy the generate a Squeak VM. A sprint is one week of full-time hacking. If you are interested in daily progress reports, please refer to
http://pypysqueak.blogspot.com/
cheers, AA
It is down :(
On 23 Oct 2007, at 9:28 , Klaus D. Witzel wrote:
BTW the codespeak.net server seems to be unreachable from here :(
/Klaus
vm-dev@lists.squeakfoundation.org
-
Adrian Kuhn -
Andreas Raab -
Bert Freudenberg -
Joerg Beekmann -
Klaus D. Witzel -
Michael Haupt