Hello folks,
during my visit at ESUG i had a conversation with Stephane, about different things, one of them is to make a better and cleaner compiler implementation.
Current compiler code contains a lot of hacks and to be fair, is not a best example of good smalltalk code. What i'm proposing, is to establish a comittee for designing a better smalltalk compiler , which will replace old one on all existing Squeak forks. I think comittee should collect & discuss all feature requests, which new compiler should have, and then we can implement it and include in every and all forks. It is also, IMO, would be a good to make compiler modular - put it as separate package and maintain it as separate fork-independent entity. This will ensure that all existing forks in future will use the same compiler as the rest. Which will make people's life much easier :)
I hope with support of atomic loading (btw a new compiler is a good test-bed for atomic loading) we should be able to load it at will :)
OMeta?
On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko siguctua@gmail.com wrote:
Hello folks,
during my visit at ESUG i had a conversation with Stephane, about different things, one of them is to make a better and cleaner compiler implementation.
Current compiler code contains a lot of hacks and to be fair, is not a best example of good smalltalk code. What i'm proposing, is to establish a comittee for designing a better smalltalk compiler , which will replace old one on all existing Squeak forks. I think comittee should collect & discuss all feature requests, which new compiler should have, and then we can implement it and include in every and all forks. It is also, IMO, would be a good to make compiler modular - put it as separate package and maintain it as separate fork-independent entity. This will ensure that all existing forks in future will use the same compiler as the rest. Which will make people's life much easier :)
I hope with support of atomic loading (btw a new compiler is a good test-bed for atomic loading) we should be able to load it at will :)
-- Best regards, Igor Stasenko AKA sig.
On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko siguctua@gmail.com wrote:
Hello folks,
during my visit at ESUG i had a conversation with Stephane, about different things, one of them is to make a better and cleaner compiler implementation.
I thought this was the purpose of the NewCompiler project. Is that project not good enough? Or is this a request to make it standard?
-Ralph
On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:
On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:
Hello folks,
during my visit at ESUG i had a conversation with Stephane, about different things, one of them is to make a better and cleaner compiler implementation.
I thought this was the purpose of the NewCompiler project.
No, you cannot remove Squeak's compiler and use only NewCompiler, if that would have been your question.
/Klaus
Is that project not good enough? Or is this a request to make it standard?
-Ralph
2008/9/1 Klaus D. Witzel klaus.witzel@cobss.com:
On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:
On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:
Hello folks,
during my visit at ESUG i had a conversation with Stephane, about different things, one of them is to make a better and cleaner compiler implementation.
I thought this was the purpose of the NewCompiler project.
No, you cannot remove Squeak's compiler and use only NewCompiler, if that would have been your question.
/Klaus
Is that project not good enough? Or is this a request to make it standard?
Yes, the main question about it, why it didn't replaced old compiler?
There are some bad things in current compiler, which makes it really hard to play with: try implement a visitor pattern with its AST - you will go into trouble very soon, because some nodes properties is not fully exposed, or accessible in a cryptic way. That's why VMMaker, for instance, using an extensions/patching to be able to reach all interesting properties of parse nodes. A bytecode generation is spead among AST nodes, and interesting, that you can't insert some kind of analyzer or pre/postprocessor without patching methods, because there is no separation in responsibility who emits the bytecodes.A MethodNode returns you a hot baked CompiledMethod instance. It would be good to make a bytecode generation placed in separate class , which using a visitor pattern to generate a bytecode. There are also an agressive rewrite rules, sitting at early processing stage which replacing original selectors like #ifTrue:{ifFalse:} or #to:do: , so you can't see an original parsed AST from source code, but getting already twisted preoptimized tree , which not reflects an original source 1:1.
-Ralph
Please have a look at my closure compiler. This puts bytecode generation into a separate class (a subclass of Encoder).You can find the code on the download page of my blog.
Marcus Denker and I are in agreement that we will merge my Closure compiler into Markus' NewCompiler "some time soon".
The thought of a committee fills me with horror :) I don't think we need anything so baroque :)
Best Eliot
On Mon, Sep 1, 2008 at 3:43 AM, Igor Stasenko siguctua@gmail.com wrote:
2008/9/1 Klaus D. Witzel klaus.witzel@cobss.com:
On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:
On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:
Hello folks,
during my visit at ESUG i had a conversation with Stephane, about different things, one of them is to make a better and cleaner compiler implementation.
I thought this was the purpose of the NewCompiler project.
No, you cannot remove Squeak's compiler and use only NewCompiler, if that would have been your question.
/Klaus
Is that project not good enough? Or is this a request to make it standard?
Yes, the main question about it, why it didn't replaced old compiler?
There are some bad things in current compiler, which makes it really hard to play with: try implement a visitor pattern with its AST - you will go into trouble very soon, because some nodes properties is not fully exposed, or accessible in a cryptic way. That's why VMMaker, for instance, using an extensions/patching to be able to reach all interesting properties of parse nodes. A bytecode generation is spead among AST nodes, and interesting, that you can't insert some kind of analyzer or pre/postprocessor without patching methods, because there is no separation in responsibility who emits the bytecodes.A MethodNode returns you a hot baked CompiledMethod instance. It would be good to make a bytecode generation placed in separate class , which using a visitor pattern to generate a bytecode. There are also an agressive rewrite rules, sitting at early processing stage which replacing original selectors like #ifTrue:{ifFalse:} or #to:do: , so you can't see an original parsed AST from source code, but getting already twisted preoptimized tree , which not reflects an original source 1:1.
-Ralph
-- Best regards, Igor Stasenko AKA sig.
El 9/1/08 5:39 PM, "Eliot Miranda" eliot.miranda@gmail.com escribió:
The thought of a committee fills me with horror :) I don't think we need anything so baroque :)
Best Eliot
Peron said: If you wish nothing happens, nominate a comitee
2008/9/2 Edgar J. De Cleene edgardec2001@yahoo.com.ar:
El 9/1/08 5:39 PM, "Eliot Miranda" eliot.miranda@gmail.com escribió:
The thought of a committee fills me with horror :) I don't think we need anything so baroque :)
Best Eliot
Peron said: If you wish nothing happens, nominate a comitee
You both right. My intent was only to get people's attention on this problem and discuss different points of view and their needs. Then implementors (like me) making things need to be done. Thats all. If no-one sharing the thought that we need a better compiler at all, then i can simply take away my words, and we will stay where we still sitting. :)
Where is this new compiler project? Where is NewCompiler? I would like to see it. Does anybody know where that book about the Squeak Compiler went to?
the rest down below is all nonsense and I wouldn't read it if I were you.
i knew this was going to cost me.
What is atomic loading? Does it mean no dependencies or dependencies are handled? It seems to me that there needs to be some kind of intellegent dependencies manager that works a lot better and is a lot smarter than what has been put out there so far.
How can I learn about how a good Squeak compiler works? Without years and millions of dead hours?
Modularity is very good. I think that all of Squeak should be very self explaining. This can be done if you put your explanations of what is going on after the body of the method. Colored source is good too. See Dolphin. But without reformating.
I am making picoLARC on sourceforge.net. Each lisp/smalltalk expression gets compiled by an instance of a Compiler Class. Each expression( let if define etc ) has its own KEGLambdaLispCompiler subClass with one standard method and zero or more helper methods in it. Each Compiler outputs an instance of a subClass of the Eval Class. An Eval can be evaluated at runtime by >>evalWithActivationRec: or it could generate byte codes which do the same thing via some method like EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker could tie Evals together or do optimizations? Is this not a good design? I know I like the part about one Compiler Class for each expression and one corresponding Eval Class. But I haven't done any byte code generation yet so I don't know about that part. One Compiler per Eval is not strict. The ApplicationCompiler can output several different related kinds of Evals for the different function calls and message sends.
What is this visitor pattern? I don't like the idea of putting byte code generation into a single Class. But I feel like maybe I don't know what I'm talking about. To modify the byte code generation for an expression you would subClass the Eval Class and modify the
generateByteCodeOn: aCodeStream. The initial implementor would try to
seperate out the parts that might be modified by someone into seperate methods that get called by
generateByteCodeOn: so these helper methods would generally be overridden
and not
generateByteCodeOn: unless that method was really simple. So the initial
implementor has to think about reuse and the places where modification might occure. So you would have a lot of simple
generateByteCodeOn: methods instead of one big complex one.
There are all different ways of calling a function or method or query etc in picoLARC and these are all subClasses of KEGLambdaLispApplicationEvalV6p1 and it seems to work fine.
But overriding >>generateByteCodesOn: is not good enough is it? The Compiler Classes can't have hard coded Eval instance creations either right? The Compiler Class has to be subClassed also and the
meaningOf:inEnviron: needs to have a
( self createEval ) expression in it that could be subClassed and overridden. And then that subClass has to be easily inserted into the expression dispatch table that pairs up expressions with expression Compilers. So when that table gets made there should be a ( tableModifier modify: table ) which could stick the < expression Compiler
pairs in that are needed.
I think that is all that would be required to modify the compilation of an expression. I will have to make these changes to picoLARC so it will be more modifiable.
I think the Compiler should be very modular. For picoLARC one Class per expression and one Class per Eval seems to work good. Stuffing lots of seperate things into a single Class and doing a procedural functional thing and not an OOP thing does not seem good to me.
I think that the Compiler should be very clean and a best practices example with a long comment at the bottom of each method telling all about what it does. Writing it out and referencing other related methods helps to think about what is really going on and then a better design without hacks comes out. I don't think hacking should be encouraged at all. Hacking just makes a mess.
And then this practice of not making any Package comments has got to stop. I think that people who do that should be admonished in some way. I think that the Package comment for the Compiler should contain the design document for it that tells all about how it is designed. If it needs to be long then it should be long. It should include: How to understand the Compiler. There should be a sequence of test cases that start simple and show how it all works.
And that should go for the VM too. This idea that the VM can be opaque and only recognizable to a few is not good.
These should be works of art and not hacked up piles of rubbish to be hidden away into obscurity.
There is this idea that one should only care about what something does. And the insides of it are a random black box that you tweek and pray on. But I think that the insides should be shown to the world. They should be displayed on a backdrop of velvet. Especially the Compiler and VM and VM maker. And then the whole Windowing thing should be modularized so you can have multiple different Windowing systems.
And what about having multiple VMs? It would be cool if picoLARC could be inside of Squeak in that way. It would be cool if one VM was generalized so that it could support different dialects and languages. And another was specific and fast. And you could make various kinds of VMs and images and output them onto disk without a lot of trouble. It would come with gcc and all that junk all set up so it would just work. If you already had gcc you could tell it not to download it.
picoLARC has simple name spaces called Nodules where you can have Nodules inside of Nodules and Nodules can multiply inherit variables from others. Maybe such a thing could be used in Squeak? Then you could have multiple VMs. And VMs inside of VMs.
I think that Dolphin Smalltalk could be held up as an example of pretty.
I hope picoLARC will be another one.
I think that Squeak is pretty in a somewhat cancerous sort of way. The cancer is all the hacking. That goes on. The vision is great but the hacking and undocumenting gum up all those big ideas.
Sure it's quick but it rots away quickly too.
Undocumented features. In Smalltalk this is less of a problem but in like Lisp say you make this great feature but then don't document it. You might as well have not even made it.
On Mon, Sep 1, 2008 at 2:12 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/9/2 Edgar J. De Cleene edgardec2001@yahoo.com.ar:
El 9/1/08 5:39 PM, "Eliot Miranda" eliot.miranda@gmail.com escribió:
The thought of a committee fills me with horror :) I don't think we
need
anything so baroque :)
Best Eliot
Peron said: If you wish nothing happens, nominate a comitee
You both right. My intent was only to get people's attention on this problem and discuss different points of view and their needs. Then implementors (like me) making things need to be done. Thats all. If no-one sharing the thought that we need a better compiler at all, then i can simply take away my words, and we will stay where we still sitting. :)
-- Best regards, Igor Stasenko AKA sig.
2008/9/2 Kjell Godo squeaklist@gmail.com:
Where is this new compiler project? Where is NewCompiler? I would like to see it. Does anybody know where that book about the Squeak Compiler went to?
the rest down below is all nonsense and I wouldn't read it if I were you.
i knew this was going to cost me.
What is atomic loading? Does it mean no dependencies or dependencies are handled? It seems to me that there needs to be some kind of intellegent dependencies manager that works a lot better and is a lot smarter than what has been put out there so far.
The atomic loading is not about handling dependencies (they are present and adressed as well, of course), but about installing a number of changes in system replacing old behavior in a single short operation, which can guarantee a safety from old/new behaviour conflicts.
How can I learn about how a good Squeak compiler works? Without years and millions of dead hours?
Sure, you need some experience in compiling things, especially smalltalk. Or , at least , if you even don't have such experience, but using Parser/Compiler for own purposes, your experience is valuable as well, since you can highlight different problems or propose better interface or new functionality.
Modularity is very good. I think that all of Squeak should be very self explaining. This can be done if you put your explanations of what is going on after the body of the method. Colored source is good too. See Dolphin. But without reformating.
I am making picoLARC on sourceforge.net. Each lisp/smalltalk expression gets compiled by an instance of a Compiler Class. Each expression( let if define etc ) has its own KEGLambdaLispCompiler subClass with one standard method and zero or more helper methods in it. Each Compiler outputs an instance of a subClass of the Eval Class. An Eval can be evaluated at runtime by >>evalWithActivationRec: or it could generate byte codes which do the same thing via some method like EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker could tie Evals together or do optimizations? Is this not a good design? I know I like the part about one Compiler Class for each expression and one corresponding Eval Class. But I haven't done any byte code generation yet so I don't know about that part. One Compiler per Eval is not strict. The ApplicationCompiler can output several different related kinds of Evals for the different function calls and message sends.
What is this visitor pattern?
http://en.wikipedia.org/wiki/Visitor_pattern
I don't like the idea of putting byte code generation into a single Class. But I feel like maybe I don't know what I'm talking about. To modify the byte code generation for an expression you would subClass the Eval Class and modify the
generateByteCodeOn: aCodeStream. The initial implementor would try to seperate out the parts that might be modified by someone into seperate methods that get called by generateByteCodeOn: so these helper methods would generally be overridden and not generateByteCodeOn: unless that method was really simple. So the initial implementor has to think about reuse and the places where modification might occure. So you would have a lot of simple generateByteCodeOn: methods instead of one big complex one.
There are all different ways of calling a function or method or query etc in picoLARC and these are all subClasses of KEGLambdaLispApplicationEvalV6p1 and it seems to work fine.
But overriding >>generateByteCodesOn: is not good enough is it? The Compiler Classes can't have hard coded Eval instance creations either right? The Compiler Class has to be subClassed also and the
The problem in Squeak compiler that you will need to override much more classes than just Compiler to emit different bytecode, for instance.
meaningOf:inEnviron: needs to have a
( self createEval ) expression in it that could be subClassed and overridden. And then that subClass has to be easily inserted into the expression dispatch table that pairs up expressions with expression Compilers. So when that table gets made there should be a ( tableModifier modify: table ) which could stick the < expression Compiler
pairs in that are needed.
I think that is all that would be required to modify the compilation of an expression. I will have to make these changes to picoLARC so it will be more modifiable.
I think the Compiler should be very modular. For picoLARC one Class per expression and one Class per Eval seems to work good. Stuffing lots of seperate things into a single Class and doing a procedural functional thing and not an OOP thing does not seem good to me.
I think that the Compiler should be very clean and a best practices example with a long comment at the bottom of each method telling all about what it does. Writing it out and referencing other related methods helps to think about what is really going on and then a better design without hacks comes out. I don't think hacking should be encouraged at all. Hacking just makes a mess.
+1
The design should allow replacing critical parts of compiler by subclassing without the need in modifying original classes. A so-called extensions , or monkey patching is very bad practice which in straightly opposite direction from modularity.
I thinking, maybe at some point, to prevent monkey patching, a deployed classes can disallow installing or modifying their methods.
And then this practice of not making any Package comments has got to stop. I think that people who do that should be admonished in some way. I think that the Package comment for the Compiler should contain the design document for it that tells all about how it is designed. If it needs to be long then it should be long. It should include: How to understand the Compiler. There should be a sequence of test cases that start simple and show how it all works.
And that should go for the VM too. This idea that the VM can be opaque and only recognizable to a few is not good.
VM tend to be complex. And complexity comes from inability of our hardware/OS work in a ways how we need/want it.
These should be works of art and not hacked up piles of rubbish to be hidden away into obscurity.
There is this idea that one should only care about what something does. And the insides of it are a random black box that you tweek and pray on. But I think that the insides should be shown to the world. They should be displayed on a backdrop of velvet. Especially the Compiler and VM and VM maker. And then the whole Windowing thing should be modularized so you can have multiple different Windowing systems.
And what about having multiple VMs? It would be cool if picoLARC could be inside of Squeak in that way. It would be cool if one VM was generalized so that it could support different dialects and languages. And another was specific and fast. And you could make various kinds of VMs and images and output them onto disk without a lot of trouble. It would come with gcc and all that junk all set up so it would just work. If you already had gcc you could tell it not to download it.
What is gcc? And why it required to make VM? ;)
picoLARC has simple name spaces called Nodules where you can have Nodules inside of Nodules and Nodules can multiply inherit variables from others. Maybe such a thing could be used in Squeak? Then you could have multiple VMs. And VMs inside of VMs.
I think that Dolphin Smalltalk could be held up as an example of pretty.
Maybe, if you know how to deal with license & copyrights when taking their source and blindly putting it to Squeak :)
I hope picoLARC will be another one.
I think that Squeak is pretty in a somewhat cancerous sort of way. The cancer is all the hacking. That goes on. The vision is great but the hacking and undocumenting gum up all those big ideas.
Sure it's quick but it rots away quickly too.
Undocumented features. In Smalltalk this is less of a problem but in like Lisp say you make this great feature but then don't document it. You might as well have not even made it.
So, here is an idea, start the VM from scratch, and, redo the entire project to allow what we want in Squeak, and the compiler. I know that is a really crazy idea, but I think it could be possible. I have been thinking about a couple of very unlikely, but, possible, maybe, VM ideas, but, what do you guys think about that?
On Mon, Sep 1, 2008 at 7:56 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/9/2 Kjell Godo squeaklist@gmail.com:
Where is this new compiler project? Where is NewCompiler? I would like
to
see it. Does anybody know where that book about the Squeak Compiler went to?
the rest down below is all nonsense and I wouldn't read it if I were you.
i knew this was going to cost me.
What is atomic loading? Does it mean no dependencies or dependencies are handled? It seems to me that there needs to be some kind of intellegent
dependencies
manager that works a lot better and is a lot smarter than what has been
put
out there so far.
The atomic loading is not about handling dependencies (they are present and adressed as well, of course), but about installing a number of changes in system replacing old behavior in a single short operation, which can guarantee a safety from old/new behaviour conflicts.
How can I learn about how a good Squeak compiler works? Without years
and
millions of dead hours?
Sure, you need some experience in compiling things, especially smalltalk. Or , at least , if you even don't have such experience, but using Parser/Compiler for own purposes, your experience is valuable as well, since you can highlight different problems or propose better interface or new functionality.
Modularity is very good. I think that all of Squeak should be very self explaining. This can be done if you put your explanations of what is
going
on after the body of the method. Colored source is good too. See
Dolphin.
But without reformating.
I am making picoLARC on sourceforge.net. Each lisp/smalltalk expression gets compiled by an instance of a Compiler Class. Each expression( let
if
define etc ) has its own KEGLambdaLispCompiler subClass with one standard method and zero or more helper methods in it. Each Compiler outputs an instance of a subClass of the Eval Class. An Eval can be evaluated at runtime by >>evalWithActivationRec: or it could generate
byte
codes which do the same thing via some method like EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker could tie Evals together or do optimizations? Is this not a good design?
I
know I like the part about one Compiler Class for each expression and one corresponding Eval Class. But I haven't done any byte code generation
yet
so I don't know about that part. One Compiler per Eval is not strict.
The
ApplicationCompiler can output several different related kinds of Evals
for
the different function calls and message sends.
What is this visitor pattern?
http://en.wikipedia.org/wiki/Visitor_pattern
I don't like the idea of putting byte code generation into a single Class. But I feel like maybe I don't know what
I'm
talking about. To modify the byte code generation for an expression you would subClass the Eval Class and modify the
generateByteCodeOn: aCodeStream. The initial implementor would try to seperate out the parts that might be modified by someone into seperate methods that get called by generateByteCodeOn: so these helper methods would generally be
overridden
and not generateByteCodeOn: unless that method was really simple. So the
initial
implementor has to think about reuse and the places where modification
might
occure. So you would have a lot of simple generateByteCodeOn: methods instead of one big complex one.
There are all different ways of calling a function or method or query etc
in
picoLARC and these are all subClasses of KEGLambdaLispApplicationEvalV6p1 and it seems to work fine.
But overriding >>generateByteCodesOn: is not good enough is it? The Compiler Classes can't have hard coded Eval instance creations either right? The Compiler Class has to be subClassed also and the
The problem in Squeak compiler that you will need to override much more classes than just Compiler to emit different bytecode, for instance.
meaningOf:inEnviron: needs to have a
( self createEval ) expression in it that could be subClassed and overridden. And then that subClass has to be easily inserted into the expression dispatch table that pairs up expressions with expression Compilers. So when that table gets made there should be a ( tableModifier modify: table ) which could stick the < expression
Compiler
pairs in that are needed.
I think that is all that would be required to modify the compilation of
an
expression. I will have to make these changes to picoLARC so it will be more
modifiable.
I think the Compiler should be very modular. For picoLARC one Class per expression and one Class per Eval seems to work good. Stuffing lots of seperate things into a single Class and doing a procedural functional
thing
and not an OOP thing does not seem good to me.
I think that the Compiler should be very clean and a best practices
example
with a long comment at the bottom of each method telling all about what
it
does. Writing it out and referencing other related methods helps to
think
about what is really going on and then a better design without hacks
comes
out. I don't think hacking should be encouraged at all. Hacking just
makes
a mess.
+1
The design should allow replacing critical parts of compiler by subclassing without the need in modifying original classes. A so-called extensions , or monkey patching is very bad practice which in straightly opposite direction from modularity.
I thinking, maybe at some point, to prevent monkey patching, a deployed classes can disallow installing or modifying their methods.
And then this practice of not making any Package comments has got to
stop.
I think that people who do that should be admonished in some way. I
think
that the Package comment for the Compiler should contain the design
document
for it that tells all about how it is designed. If it needs to be long
then
it should be long. It should include: How to understand the Compiler. There should be a sequence of test cases that start simple and show how
it
all works.
And that should go for the VM too. This idea that the VM can be opaque
and
only recognizable to a few is not good.
VM tend to be complex. And complexity comes from inability of our hardware/OS work in a ways how we need/want it.
These should be works of art and not hacked up piles of rubbish to be
hidden
away into obscurity.
There is this idea that one should only care about what something does.
And
the insides of it are a random black box that you tweek and pray on. But
I
think that the insides should be shown to the world. They should be displayed on a backdrop of velvet. Especially the Compiler and VM and
VM
maker. And then the whole Windowing thing should be modularized so you
can
have multiple different Windowing systems.
And what about having multiple VMs? It would be cool if picoLARC could
be
inside of Squeak in that way. It would be cool if one VM was generalized
so
that it could support different dialects and languages. And another was specific and fast. And you could make various kinds of VMs and images
and
output them onto disk without a lot of trouble. It would come with gcc
and
all that junk all set up so it would just work. If you already had gcc
you
could tell it not to download it.
What is gcc? And why it required to make VM? ;)
picoLARC has simple name spaces called Nodules where you can have Nodules inside of Nodules and Nodules can multiply inherit variables from others. Maybe such a thing could be used in Squeak? Then you could have multiple VMs. And VMs inside of VMs.
I think that Dolphin Smalltalk could be held up as an example of pretty.
Maybe, if you know how to deal with license & copyrights when taking their source and blindly putting it to Squeak :)
I hope picoLARC will be another one.
I think that Squeak is pretty in a somewhat cancerous sort of way. The cancer is all the hacking. That goes on. The vision is great but the hacking and undocumenting gum up all those
big
ideas.
Sure it's quick but it rots away quickly too.
Undocumented features. In Smalltalk this is less of a problem but in
like
Lisp say you make this great feature but then don't document it. You
might
as well have not even made it.
-- Best regards, Igor Stasenko AKA sig.
Here is an idea that might increase modularity in the compiler and VM and might encourage multiple compilers and VMs:
Instead of having the Compiler dump byte codes directly into a ByteArray you have a SmalltalkByteCodeStream which displays all the different functionalities of the VM in a systematic way.
*********************** Each byte code instruction that the VM recognizes would be expressed as a SmalltalkByteCodeStream method that encodes that instruction.
***********************
In this way the functionality of the VM becomes self documenting.
In order to find out the public functionality of the VM you would look at the public methods in the SmalltalkByteCodeStream. These methods should be well documented with comments after the body of the methods.
The byte code instructions that the VM recognizes become a well documented public set of instructions that compiler makers can make their compilers on. These instructions become the VM's public language.
Each VM would have its own SmalltalkByteCodeStream so you might name them SmalltalkByteCodeStreamForVM1 and SmalltalkByteCodeStreamForVM2 etc.
So like if you were encoding an ifTrue:ifFalse: expression in a naive way you could do it like:
aSmalltalkByteCodeStreamForVM1 nextPutAll: aBooleanExpression ; nextIfStackTopTrueSkipNextIfStackTopFalse ; skipNext:( SmalltalkByteCodeStream jumpSize ) ; yourselfDo:[ :sbcs | jumpToFalseMarker := sbcs makeSpaceForJump ] ; nextPutAll: ifTrueBranchExpression ; yourselfDo:[ :sbcs | jumpToExitMarker := sbcs makeSpaceForJump ] ; yourselfDo:[ :sbcs | jumpToFalseMarker fillInCodeFor: sbcs position ] ; nextPutAll: ifFalseBranchExpression yourselfDo:[ :sbcs | jumpToExitMarker fillInCodeFor: sbcs position ]
Object>>yourselfDo: aBlock aBlock value: self . ^self .
SmalltalkByteCodeStream>>nextPutAll: aByteCodeGenerator aByteCodeGenerator generateByteCodesOn: self
SmalltalkByteCodeStream>>makeSpaceForJump ^( JumpInstructionMarker new position: self position on: self ; yourself ) yourselfDo:[ :na | self position:( ( self position ) + ( SmalltalkByteCodeStream jumpSize ) ) ]
JumpInstructionMarker>>fillInCodeFor: expressionPosition | oldPosition | oldPosition := stream position . stream position: jumpInstructionPosition ; nextPutJumpByteCode ; intoNext: ( SmalltalkByteCodeStream jumpSize ) - ( SmalltalkByteCodeStream jumpByteCodeSize ) putInteger: expressionPosition ; position: oldPosition "<---( stream is a WriteStream on a ByteArray or something )" On Mon, Sep 1, 2008 at 8:14 PM, David Zmick dz0004455@gmail.com wrote:
So, here is an idea, start the VM from scratch, and, redo the entire project to allow what we want in Squeak, and the compiler. I know that is a really crazy idea, but I think it could be possible. I have been thinking about a couple of very unlikely, but, possible, maybe, VM ideas, but, what do you guys think about that?
I think that the new VM2 should be right next to the old VM1 in the running image. So you could use the old VM1 to make the new VM2.
Each VM can have multiple name spaces. Each VM generates a VM space with multiple name spaces inside of it. Each name space could have its own Object Class and Class hierarchy. Or you could have a hierarchy being run by VM1 and switch it over to be run by VM2. And back and forth at runtime.
Perhaps the CPU could be thought of as a big VM and then the SmalltalkByteCodeStreamForCPU would generate machine code into the ByteArray that the SmalltalkByteCodeStreamForCPU was on. And that ByteArray would be stuck into the CompiledMethodForCPU.
It would be cool if each VM was an Object and you could do things like:
( VM2 inImage: anImage inNameSpace: aNameSpace usingCompiler: aCompiler eval:'[ someSmalltalkCode ]' )
In that way the old VM could call up the new VM and have it evaluate some code. And when that code was done if ever then the old VM would continue from there. Or the new Image could fork into a new thread. etc.
You would want the debugging to be able to step into this expression so that you could really see how the VM2 works.
( VM2 simulation inImage: anImage inNameSpace: aNameSpace usingCompiler: aCompiler eval: '[ someSmalltalkCode ]' )
would allow you to see the byte codes being evaluated before your very eyes. And then the simulation is translated into C or machine code to make VM2. It would be cool if Squeak had a portable assembler in it so you didn't have to use C at all. And that portable Assembler could be SmalltalkByteCodeStreamForCPUIA32 SmalltalkByteCodeStreamForCPUIA64 etc. Instead of the traditional archain neumonics used in assemblers we could use Smalltalk messages instead to generate that machine code. The above expression would allow you to see an image being loaded up and a name space within that image being selected and a Compiler being used to compile '[ someSmalltalk ]' and then being able to see Smalltalk expressions being evaluated in the debugger in that image and name space on that VM. And when you hop into a message send then the byte code debugger would move to the front of the screen and show the byte codes being executed if desired. It would be cool if there was a machine code debugger so you could hop into a byte code instruction and see how it is being evaluated. It would interpret what was in the registers and what was on the stack as Objects. There would be inspectors.
Hopefully this kind of thing would allow multiple VMs and multiple images and multiple compilers all to be running at the same time. Hopefully it would encourage VM development and compiler development such that Squeak could branch out in all different ways.
You could have SmalltalkByteCodeStreamForV8 which would make public the functionality of the V8 Java VM. And then you could have the V8 VM be one of the VMs inside of Squeak.
You can switch from VM to VM at runtime.
You can use the old VMs to make a new one.
There are Smalltalk debuggers and byte code debuggers and machine code debuggers.
There is the traditional Squeak VM and there are platform specific VMs that can all run side by side. There are multiple different Windowing systems all running side by side. Some native and some not. Some the old Squeak way and some the Dolphin way some the Java way. etc.
Squeak's portable assembler SmalltalkByteCodeStreamForCPU can be used to output an executable file that has zero or more VMs inside of it into a Directory on disk with zero or more image files and souce code files for the different name spaces and hierarchies. Then you fire up that executable and those VMs are inside of it.
It would be cool if there was a PEFileStream that could be used to make public all the sections inside of a PE format executable file. With a sequence of tests going from simple to complex and lots of documentation.
I do think that there should be a new VM and it should run right alongside of the old one and be the first of many.
On Mon, Sep 1, 2008 at 7:56 PM, Igor Stasenko siguctua@gmail.comwrote:
2008/9/2 Kjell Godo squeaklist@gmail.com:
Where is this new compiler project? Where is NewCompiler? I would like
to
see it. Does anybody know where that book about the Squeak Compiler went to?
the rest down below is all nonsense and I wouldn't read it if I were
you.
i knew this was going to cost me.
What is atomic loading? Does it mean no dependencies or dependencies
are
handled? It seems to me that there needs to be some kind of intellegent
dependencies
manager that works a lot better and is a lot smarter than what has been
put
out there so far.
The atomic loading is not about handling dependencies (they are present and adressed as well, of course), but about installing a number of changes in system replacing old behavior in a single short operation, which can guarantee a safety from old/new behaviour conflicts.
How can I learn about how a good Squeak compiler works? Without years
and
millions of dead hours?
Sure, you need some experience in compiling things, especially smalltalk. Or , at least , if you even don't have such experience, but using Parser/Compiler for own purposes, your experience is valuable as well, since you can highlight different problems or propose better interface or new functionality.
Modularity is very good. I think that all of Squeak should be very self explaining. This can be done if you put your explanations of what is
going
on after the body of the method. Colored source is good too. See
Dolphin.
But without reformating.
I am making picoLARC on sourceforge.net. Each lisp/smalltalk
expression
gets compiled by an instance of a Compiler Class. Each expression( let
if
define etc ) has its own KEGLambdaLispCompiler subClass with one standard method and zero or more helper methods in it. Each Compiler outputs an instance of a subClass of the Eval Class. An Eval can be evaluated at runtime by >>evalWithActivationRec: or it could generate
byte
codes which do the same thing via some method like EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker could tie Evals together or do optimizations? Is this not a good
design? I
know I like the part about one Compiler Class for each expression and
one
corresponding Eval Class. But I haven't done any byte code generation
yet
so I don't know about that part. One Compiler per Eval is not strict.
The
ApplicationCompiler can output several different related kinds of Evals
for
the different function calls and message sends.
What is this visitor pattern?
http://en.wikipedia.org/wiki/Visitor_pattern
I don't like the idea of putting byte code generation into a single Class. But I feel like maybe I don't know what
I'm
talking about. To modify the byte code generation for an expression you would subClass the Eval Class and modify the
generateByteCodeOn: aCodeStream. The initial implementor would try to seperate out the parts that might be modified by someone into seperate methods that get called by generateByteCodeOn: so these helper methods would generally be
overridden
and not generateByteCodeOn: unless that method was really simple. So the
initial
implementor has to think about reuse and the places where modification
might
occure. So you would have a lot of simple generateByteCodeOn: methods instead of one big complex one.
There are all different ways of calling a function or method or query
etc in
picoLARC and these are all subClasses of
KEGLambdaLispApplicationEvalV6p1
and it seems to work fine.
But overriding >>generateByteCodesOn: is not good enough is it? The Compiler Classes can't have hard coded Eval instance creations either right? The Compiler Class has to be subClassed also and the
The problem in Squeak compiler that you will need to override much more classes than just Compiler to emit different bytecode, for instance.
meaningOf:inEnviron: needs to have a
( self createEval ) expression in it that could be subClassed and overridden. And then that subClass has to be easily inserted into the expression dispatch table that pairs up expressions with expression Compilers. So when that table gets made there should be a ( tableModifier modify: table ) which could stick the < expression
Compiler
pairs in that are needed.
I think that is all that would be required to modify the compilation of
an
expression. I will have to make these changes to picoLARC so it will be more
modifiable.
I think the Compiler should be very modular. For picoLARC one Class per expression and one Class per Eval seems to work good. Stuffing lots of seperate things into a single Class and doing a procedural functional
thing
and not an OOP thing does not seem good to me.
I think that the Compiler should be very clean and a best practices
example
with a long comment at the bottom of each method telling all about what
it
does. Writing it out and referencing other related methods helps to
think
about what is really going on and then a better design without hacks
comes
out. I don't think hacking should be encouraged at all. Hacking just
makes
a mess.
+1
The design should allow replacing critical parts of compiler by subclassing without the need in modifying original classes. A so-called extensions , or monkey patching is very bad practice which in straightly opposite direction from modularity.
I thinking, maybe at some point, to prevent monkey patching, a deployed classes can disallow installing or modifying their methods.
And then this practice of not making any Package comments has got to
stop.
I think that people who do that should be admonished in some way. I
think
that the Package comment for the Compiler should contain the design
document
for it that tells all about how it is designed. If it needs to be long
then
it should be long. It should include: How to understand the Compiler. There should be a sequence of test cases that start simple and show how
it
all works.
And that should go for the VM too. This idea that the VM can be opaque
and
only recognizable to a few is not good.
VM tend to be complex. And complexity comes from inability of our hardware/OS work in a ways how we need/want it.
These should be works of art and not hacked up piles of rubbish to be
hidden
away into obscurity.
There is this idea that one should only care about what something does.
And
the insides of it are a random black box that you tweek and pray on.
But I
think that the insides should be shown to the world. They should be displayed on a backdrop of velvet. Especially the Compiler and VM
and VM
maker. And then the whole Windowing thing should be modularized so you
can
have multiple different Windowing systems.
And what about having multiple VMs? It would be cool if picoLARC could
be
inside of Squeak in that way. It would be cool if one VM was
generalized so
that it could support different dialects and languages. And another was specific and fast. And you could make various kinds of VMs and images
and
output them onto disk without a lot of trouble. It would come with gcc
and
all that junk all set up so it would just work. If you already had gcc
you
could tell it not to download it.
What is gcc? And why it required to make VM? ;)
picoLARC has simple name spaces called Nodules where you can have
Nodules
inside of Nodules and Nodules can multiply inherit variables from
others.
Maybe such a thing could be used in Squeak? Then you could have
multiple
VMs. And VMs inside of VMs.
I think that Dolphin Smalltalk could be held up as an example of pretty.
Maybe, if you know how to deal with license & copyrights when taking their source and blindly putting it to Squeak :)
I hope picoLARC will be another one.
I think that Squeak is pretty in a somewhat cancerous sort of way. The cancer is all the hacking. That goes on. The vision is great but the hacking and undocumenting gum up all those
big
ideas.
Sure it's quick but it rots away quickly too.
Undocumented features. In Smalltalk this is less of a problem but in
like
Lisp say you make this great feature but then don't document it. You
might
as well have not even made it.
-- Best regards, Igor Stasenko AKA sig.
-- David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com
On Sun, Sep 7, 2008 at 3:39 PM, Kjell Godo squeaklist@gmail.com wrote:
Here is an idea that might increase modularity in the compiler and VM and might encourage multiple compilers and VMs:
Instead of having the Compiler dump byte codes directly into a ByteArray you have a SmalltalkByteCodeStream which displays all the different functionalities of the VM in a systematic way.
***********************Each byte code instruction that the VM recognizes would be expressed as a SmalltalkByteCodeStream method that encodes that instruction.
This is what I've done in my Closure compiler. There are different back-ends for different bytecode encodings. Subclasses of BytecodeEncoder decide how to encode abstract opcodes such as PushReceiver ReturnTop etc. These classes implement two methods for each opcode, sizeFoo and genFoo, e.g. sizePushReceiver and genPushReceiver.
I have four encoders. One for the current V3 instruction set, and one for its long-form subset. One for the V3 set extended with 5 closure opcodes, and one for its long-form subset. I can generate code for any of these simply by initializing the compiler with the relevant encoder.
The code is available on my blog (as is a description of the compiler).
***********************In this way the functionality of the VM becomes self documenting.
In order to find out the public functionality of the VM you would look at the public methods in the SmalltalkByteCodeStream. These methods should be well documented with comments after the body of the methods.
The byte code instructions that the VM recognizes become a well documented public set of instructions that compiler makers can make their compilers on. These instructions become the VM's public language.
Each VM would have its own SmalltalkByteCodeStream so you might name them SmalltalkByteCodeStreamForVM1 and SmalltalkByteCodeStreamForVM2 etc.
So like if you were encoding an ifTrue:ifFalse: expression in a naive way you could do it like:
aSmalltalkByteCodeStreamForVM1 nextPutAll: aBooleanExpression ; nextIfStackTopTrueSkipNextIfStackTopFalse ; skipNext:( SmalltalkByteCodeStream jumpSize ) ; yourselfDo:[ :sbcs | jumpToFalseMarker := sbcs makeSpaceForJump ] ; nextPutAll: ifTrueBranchExpression ; yourselfDo:[ :sbcs | jumpToExitMarker := sbcs makeSpaceForJump ] ; yourselfDo:[ :sbcs | jumpToFalseMarker fillInCodeFor: sbcs position ] ; nextPutAll: ifFalseBranchExpression yourselfDo:[ :sbcs | jumpToExitMarker fillInCodeFor: sbcs position ]
Object>>yourselfDo: aBlock aBlock value: self . ^self .
SmalltalkByteCodeStream>>nextPutAll: aByteCodeGenerator aByteCodeGenerator generateByteCodesOn: self
SmalltalkByteCodeStream>>makeSpaceForJump ^( JumpInstructionMarker new position: self position on: self ; yourself ) yourselfDo:[ :na | self position:( ( self position ) + ( SmalltalkByteCodeStream jumpSize ) ) ]
JumpInstructionMarker>>fillInCodeFor: expressionPosition | oldPosition | oldPosition := stream position . stream position: jumpInstructionPosition ; nextPutJumpByteCode ; intoNext: ( SmalltalkByteCodeStream jumpSize ) - ( SmalltalkByteCodeStream jumpByteCodeSize ) putInteger: expressionPosition ; position: oldPosition "<---( stream is a WriteStream on a ByteArray or something )" On Mon, Sep 1, 2008 at 8:14 PM, David Zmick dz0004455@gmail.com wrote:
So, here is an idea, start the VM from scratch, and, redo the entire project to allow what we want in Squeak, and the compiler. I know that is a really crazy idea, but I think it could be possible. I have been thinking about a couple of very unlikely, but, possible, maybe, VM ideas, but, what do you guys think about that?
I think that the new VM2 should be right next to the old VM1 in the running image. So you could use the old VM1 to make the new VM2.
Each VM can have multiple name spaces. Each VM generates a VM space with multiple name spaces inside of it. Each name space could have its own Object Class and Class hierarchy. Or you could have a hierarchy being run by VM1 and switch it over to be run by VM2. And back and forth at runtime.
Perhaps the CPU could be thought of as a big VM and then the SmalltalkByteCodeStreamForCPU would generate machine code into the ByteArray that the SmalltalkByteCodeStreamForCPU was on. And that ByteArray would be stuck into the CompiledMethodForCPU.
It would be cool if each VM was an Object and you could do things like:
( VM2 inImage: anImage inNameSpace: aNameSpace usingCompiler: aCompiler eval:'[ someSmalltalkCode ]' )
In that way the old VM could call up the new VM and have it evaluate some code. And when that code was done if ever then the old VM would continue from there. Or the new Image could fork into a new thread. etc.
You would want the debugging to be able to step into this expression so that you could really see how the VM2 works.
( VM2 simulation inImage: anImage inNameSpace: aNameSpace usingCompiler: aCompiler eval: '[ someSmalltalkCode ]' )
would allow you to see the byte codes being evaluated before your very eyes. And then the simulation is translated into C or machine code to make VM2. It would be cool if Squeak had a portable assembler in it so you didn't have to use C at all. And that portable Assembler could be SmalltalkByteCodeStreamForCPUIA32 SmalltalkByteCodeStreamForCPUIA64 etc. Instead of the traditional archain neumonics used in assemblers we could use Smalltalk messages instead to generate that machine code. The above expression would allow you to see an image being loaded up and a name space within that image being selected and a Compiler being used to compile '[ someSmalltalk ]' and then being able to see Smalltalk expressions being evaluated in the debugger in that image and name space on that VM. And when you hop into a message send then the byte code debugger would move to the front of the screen and show the byte codes being executed if desired. It would be cool if there was a machine code debugger so you could hop into a byte code instruction and see how it is being evaluated. It would interpret what was in the registers and what was on the stack as Objects. There would be inspectors.
Hopefully this kind of thing would allow multiple VMs and multiple images and multiple compilers all to be running at the same time. Hopefully it would encourage VM development and compiler development such that Squeak could branch out in all different ways.
You could have SmalltalkByteCodeStreamForV8 which would make public the functionality of the V8 Java VM. And then you could have the V8 VM be one of the VMs inside of Squeak.
You can switch from VM to VM at runtime.
You can use the old VMs to make a new one.
There are Smalltalk debuggers and byte code debuggers and machine code debuggers.
There is the traditional Squeak VM and there are platform specific VMs that can all run side by side. There are multiple different Windowing systems all running side by side. Some native and some not. Some the old Squeak way and some the Dolphin way some the Java way. etc.
Squeak's portable assembler SmalltalkByteCodeStreamForCPU can be used to output an executable file that has zero or more VMs inside of it into a Directory on disk with zero or more image files and souce code files for the different name spaces and hierarchies. Then you fire up that executable and those VMs are inside of it.
It would be cool if there was a PEFileStream that could be used to make public all the sections inside of a PE format executable file. With a sequence of tests going from simple to complex and lots of documentation.
I do think that there should be a new VM and it should run right alongside of the old one and be the first of many.
On Mon, Sep 1, 2008 at 7:56 PM, Igor Stasenko siguctua@gmail.comwrote:
2008/9/2 Kjell Godo squeaklist@gmail.com:
Where is this new compiler project? Where is NewCompiler? I would
like to
see it. Does anybody know where that book about the Squeak Compiler went to?
the rest down below is all nonsense and I wouldn't read it if I were
you.
i knew this was going to cost me.
What is atomic loading? Does it mean no dependencies or dependencies
are
handled? It seems to me that there needs to be some kind of intellegent
dependencies
manager that works a lot better and is a lot smarter than what has been
put
out there so far.
The atomic loading is not about handling dependencies (they are present and adressed as well, of course), but about installing a number of changes in system replacing old behavior in a single short operation, which can guarantee a safety from old/new behaviour conflicts.
How can I learn about how a good Squeak compiler works? Without years
and
millions of dead hours?
Sure, you need some experience in compiling things, especially smalltalk. Or , at least , if you even don't have such experience, but using Parser/Compiler for own purposes, your experience is valuable as well, since you can highlight different problems or propose better interface or new functionality.
Modularity is very good. I think that all of Squeak should be very
self
explaining. This can be done if you put your explanations of what is
going
on after the body of the method. Colored source is good too. See
Dolphin.
But without reformating.
I am making picoLARC on sourceforge.net. Each lisp/smalltalk
expression
gets compiled by an instance of a Compiler Class. Each expression( let
if
define etc ) has its own KEGLambdaLispCompiler subClass with one standard method and zero or more helper methods in it. Each Compiler outputs an instance of a subClass of the Eval Class. An Eval can be evaluated at runtime by >>evalWithActivationRec: or it could generate
byte
codes which do the same thing via some method like EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker could tie Evals together or do optimizations? Is this not a good
design? I
know I like the part about one Compiler Class for each expression and
one
corresponding Eval Class. But I haven't done any byte code generation
yet
so I don't know about that part. One Compiler per Eval is not strict.
The
ApplicationCompiler can output several different related kinds of Evals
for
the different function calls and message sends.
What is this visitor pattern?
http://en.wikipedia.org/wiki/Visitor_pattern
I don't like the idea of putting byte code generation into a single Class. But I feel like maybe I don't know
what I'm
talking about. To modify the byte code generation for an expression
you
would subClass the Eval Class and modify the
generateByteCodeOn: aCodeStream. The initial implementor would try to seperate out the parts that might be modified by someone into
seperate
methods that get called by generateByteCodeOn: so these helper methods would generally be
overridden
and not generateByteCodeOn: unless that method was really simple. So the
initial
implementor has to think about reuse and the places where
modification might
occure. So you would have a lot of simple generateByteCodeOn: methods instead of one big complex one.
There are all different ways of calling a function or method or query
etc in
picoLARC and these are all subClasses of
KEGLambdaLispApplicationEvalV6p1
and it seems to work fine.
But overriding >>generateByteCodesOn: is not good enough is it? The Compiler Classes can't have hard coded Eval instance creations either right? The Compiler Class has to be subClassed also and the
The problem in Squeak compiler that you will need to override much more classes than just Compiler to emit different bytecode, for instance.
meaningOf:inEnviron: needs to have a
( self createEval ) expression in it that could be subClassed and overridden. And then that subClass has to be easily inserted into the expression dispatch table that pairs up expressions with expression Compilers. So when that table gets made there should be a ( tableModifier modify: table ) which could stick the < expression
Compiler
pairs in that are needed.
I think that is all that would be required to modify the compilation of
an
expression. I will have to make these changes to picoLARC so it will be more
modifiable.
I think the Compiler should be very modular. For picoLARC one Class
per
expression and one Class per Eval seems to work good. Stuffing lots of seperate things into a single Class and doing a procedural functional
thing
and not an OOP thing does not seem good to me.
I think that the Compiler should be very clean and a best practices
example
with a long comment at the bottom of each method telling all about what
it
does. Writing it out and referencing other related methods helps to
think
about what is really going on and then a better design without hacks
comes
out. I don't think hacking should be encouraged at all. Hacking just
makes
a mess.
+1
The design should allow replacing critical parts of compiler by subclassing without the need in modifying original classes. A so-called extensions , or monkey patching is very bad practice which in straightly opposite direction from modularity.
I thinking, maybe at some point, to prevent monkey patching, a deployed classes can disallow installing or modifying their methods.
And then this practice of not making any Package comments has got to
stop.
I think that people who do that should be admonished in some way. I
think
that the Package comment for the Compiler should contain the design
document
for it that tells all about how it is designed. If it needs to be long
then
it should be long. It should include: How to understand the Compiler. There should be a sequence of test cases that start simple and show how
it
all works.
And that should go for the VM too. This idea that the VM can be opaque
and
only recognizable to a few is not good.
VM tend to be complex. And complexity comes from inability of our hardware/OS work in a ways how we need/want it.
These should be works of art and not hacked up piles of rubbish to be
hidden
away into obscurity.
There is this idea that one should only care about what something does.
And
the insides of it are a random black box that you tweek and pray on.
But I
think that the insides should be shown to the world. They should be displayed on a backdrop of velvet. Especially the Compiler and VM
and VM
maker. And then the whole Windowing thing should be modularized so you
can
have multiple different Windowing systems.
And what about having multiple VMs? It would be cool if picoLARC could
be
inside of Squeak in that way. It would be cool if one VM was
generalized so
that it could support different dialects and languages. And another
was
specific and fast. And you could make various kinds of VMs and images
and
output them onto disk without a lot of trouble. It would come with gcc
and
all that junk all set up so it would just work. If you already had gcc
you
could tell it not to download it.
What is gcc? And why it required to make VM? ;)
picoLARC has simple name spaces called Nodules where you can have
Nodules
inside of Nodules and Nodules can multiply inherit variables from
others.
Maybe such a thing could be used in Squeak? Then you could have
multiple
VMs. And VMs inside of VMs.
I think that Dolphin Smalltalk could be held up as an example of
pretty.
Maybe, if you know how to deal with license & copyrights when taking their source and blindly putting it to Squeak :)
I hope picoLARC will be another one.
I think that Squeak is pretty in a somewhat cancerous sort of way. The cancer is all the hacking. That goes on. The vision is great but the hacking and undocumenting gum up all those
big
ideas.
Sure it's quick but it rots away quickly too.
Undocumented features. In Smalltalk this is less of a problem but in
like
Lisp say you make this great feature but then don't document it. You
might
as well have not even made it.
-- Best regards, Igor Stasenko AKA sig.
-- David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com
I do think that there should be a new VM and it should run right alongside of the old one and be the first of many.
You could easily write a new vm on top of the old one using OMeta.
On Sun, Sep 7, 2008 at 5:39 PM, Kjell Godo squeaklist@gmail.com wrote:
Here is an idea that might increase modularity in the compiler and VM and might encourage multiple compilers and VMs:
Instead of having the Compiler dump byte codes directly into a ByteArray you have a SmalltalkByteCodeStream which displays all the different functionalities of the VM in a systematic way.
***********************Each byte code instruction that the VM recognizes would be expressed as a SmalltalkByteCodeStream method that encodes that instruction.
***********************In this way the functionality of the VM becomes self documenting.
In order to find out the public functionality of the VM you would look at the public methods in the SmalltalkByteCodeStream. These methods should be well documented with comments after the body of the methods.
The byte code instructions that the VM recognizes become a well documented public set of instructions that compiler makers can make their compilers on. These instructions become the VM's public language.
Each VM would have its own SmalltalkByteCodeStream so you might name them SmalltalkByteCodeStreamForVM1 and SmalltalkByteCodeStreamForVM2 etc.
So like if you were encoding an ifTrue:ifFalse: expression in a naive way you could do it like:
aSmalltalkByteCodeStreamForVM1 nextPutAll: aBooleanExpression ; nextIfStackTopTrueSkipNextIfStackTopFalse ; skipNext:( SmalltalkByteCodeStream jumpSize ) ; yourselfDo:[ :sbcs | jumpToFalseMarker := sbcs makeSpaceForJump ] ; nextPutAll: ifTrueBranchExpression ; yourselfDo:[ :sbcs | jumpToExitMarker := sbcs makeSpaceForJump ] ; yourselfDo:[ :sbcs | jumpToFalseMarker fillInCodeFor: sbcs position ] ; nextPutAll: ifFalseBranchExpression yourselfDo:[ :sbcs | jumpToExitMarker fillInCodeFor: sbcs position ]
Object>>yourselfDo: aBlock aBlock value: self . ^self .
SmalltalkByteCodeStream>>nextPutAll: aByteCodeGenerator aByteCodeGenerator generateByteCodesOn: self
SmalltalkByteCodeStream>>makeSpaceForJump ^( JumpInstructionMarker new position: self position on: self ; yourself ) yourselfDo:[ :na | self position:( ( self position ) + ( SmalltalkByteCodeStream jumpSize ) ) ]
JumpInstructionMarker>>fillInCodeFor: expressionPosition | oldPosition | oldPosition := stream position . stream position: jumpInstructionPosition ; nextPutJumpByteCode ; intoNext: ( SmalltalkByteCodeStream jumpSize ) - ( SmalltalkByteCodeStream jumpByteCodeSize ) putInteger: expressionPosition ; position: oldPosition "<---( stream is a WriteStream on a ByteArray or something )" On Mon, Sep 1, 2008 at 8:14 PM, David Zmick dz0004455@gmail.com wrote:
So, here is an idea, start the VM from scratch, and, redo the entire project to allow what we want in Squeak, and the compiler. I know that is a really crazy idea, but I think it could be possible. I have been thinking about a couple of very unlikely, but, possible, maybe, VM ideas, but, what do you guys think about that?
I think that the new VM2 should be right next to the old VM1 in the running image. So you could use the old VM1 to make the new VM2.
Each VM can have multiple name spaces. Each VM generates a VM space with multiple name spaces inside of it. Each name space could have its own Object Class and Class hierarchy. Or you could have a hierarchy being run by VM1 and switch it over to be run by VM2. And back and forth at runtime.
Perhaps the CPU could be thought of as a big VM and then the SmalltalkByteCodeStreamForCPU would generate machine code into the ByteArray that the SmalltalkByteCodeStreamForCPU was on. And that ByteArray would be stuck into the CompiledMethodForCPU.
It would be cool if each VM was an Object and you could do things like:
( VM2 inImage: anImage inNameSpace: aNameSpace usingCompiler: aCompiler eval:'[ someSmalltalkCode ]' )
In that way the old VM could call up the new VM and have it evaluate some code. And when that code was done if ever then the old VM would continue from there. Or the new Image could fork into a new thread. etc.
You would want the debugging to be able to step into this expression so that you could really see how the VM2 works.
( VM2 simulation inImage: anImage inNameSpace: aNameSpace usingCompiler: aCompiler eval: '[ someSmalltalkCode ]' )
would allow you to see the byte codes being evaluated before your very eyes. And then the simulation is translated into C or machine code to make VM2. It would be cool if Squeak had a portable assembler in it so you didn't have to use C at all. And that portable Assembler could be SmalltalkByteCodeStreamForCPUIA32 SmalltalkByteCodeStreamForCPUIA64 etc. Instead of the traditional archain neumonics used in assemblers we could use Smalltalk messages instead to generate that machine code. The above expression would allow you to see an image being loaded up and a name space within that image being selected and a Compiler being used to compile '[ someSmalltalk ]' and then being able to see Smalltalk expressions being evaluated in the debugger in that image and name space on that VM. And when you hop into a message send then the byte code debugger would move to the front of the screen and show the byte codes being executed if desired. It would be cool if there was a machine code debugger so you could hop into a byte code instruction and see how it is being evaluated. It would interpret what was in the registers and what was on the stack as Objects. There would be inspectors.
Hopefully this kind of thing would allow multiple VMs and multiple images and multiple compilers all to be running at the same time. Hopefully it would encourage VM development and compiler development such that Squeak could branch out in all different ways.
You could have SmalltalkByteCodeStreamForV8 which would make public the functionality of the V8 Java VM. And then you could have the V8 VM be one of the VMs inside of Squeak.
You can switch from VM to VM at runtime.
You can use the old VMs to make a new one.
There are Smalltalk debuggers and byte code debuggers and machine code debuggers.
There is the traditional Squeak VM and there are platform specific VMs that can all run side by side. There are multiple different Windowing systems all running side by side. Some native and some not. Some the old Squeak way and some the Dolphin way some the Java way. etc.
Squeak's portable assembler SmalltalkByteCodeStreamForCPU can be used to output an executable file that has zero or more VMs inside of it into a Directory on disk with zero or more image files and souce code files for the different name spaces and hierarchies. Then you fire up that executable and those VMs are inside of it.
It would be cool if there was a PEFileStream that could be used to make public all the sections inside of a PE format executable file. With a sequence of tests going from simple to complex and lots of documentation.
I do think that there should be a new VM and it should run right alongside of the old one and be the first of many.
On Mon, Sep 1, 2008 at 7:56 PM, Igor Stasenko siguctua@gmail.comwrote:
2008/9/2 Kjell Godo squeaklist@gmail.com:
Where is this new compiler project? Where is NewCompiler? I would
like to
see it. Does anybody know where that book about the Squeak Compiler went to?
the rest down below is all nonsense and I wouldn't read it if I were
you.
i knew this was going to cost me.
What is atomic loading? Does it mean no dependencies or dependencies
are
handled? It seems to me that there needs to be some kind of intellegent
dependencies
manager that works a lot better and is a lot smarter than what has been
put
out there so far.
The atomic loading is not about handling dependencies (they are present and adressed as well, of course), but about installing a number of changes in system replacing old behavior in a single short operation, which can guarantee a safety from old/new behaviour conflicts.
How can I learn about how a good Squeak compiler works? Without years
and
millions of dead hours?
Sure, you need some experience in compiling things, especially smalltalk. Or , at least , if you even don't have such experience, but using Parser/Compiler for own purposes, your experience is valuable as well, since you can highlight different problems or propose better interface or new functionality.
Modularity is very good. I think that all of Squeak should be very
self
explaining. This can be done if you put your explanations of what is
going
on after the body of the method. Colored source is good too. See
Dolphin.
But without reformating.
I am making picoLARC on sourceforge.net. Each lisp/smalltalk
expression
gets compiled by an instance of a Compiler Class. Each expression( let
if
define etc ) has its own KEGLambdaLispCompiler subClass with one standard method and zero or more helper methods in it. Each Compiler outputs an instance of a subClass of the Eval Class. An Eval can be evaluated at runtime by >>evalWithActivationRec: or it could generate
byte
codes which do the same thing via some method like EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker could tie Evals together or do optimizations? Is this not a good
design? I
know I like the part about one Compiler Class for each expression and
one
corresponding Eval Class. But I haven't done any byte code generation
yet
so I don't know about that part. One Compiler per Eval is not strict.
The
ApplicationCompiler can output several different related kinds of Evals
for
the different function calls and message sends.
What is this visitor pattern?
http://en.wikipedia.org/wiki/Visitor_pattern
I don't like the idea of putting byte code generation into a single Class. But I feel like maybe I don't know
what I'm
talking about. To modify the byte code generation for an expression
you
would subClass the Eval Class and modify the
generateByteCodeOn: aCodeStream. The initial implementor would try to seperate out the parts that might be modified by someone into
seperate
methods that get called by generateByteCodeOn: so these helper methods would generally be
overridden
and not generateByteCodeOn: unless that method was really simple. So the
initial
implementor has to think about reuse and the places where
modification might
occure. So you would have a lot of simple generateByteCodeOn: methods instead of one big complex one.
There are all different ways of calling a function or method or query
etc in
picoLARC and these are all subClasses of
KEGLambdaLispApplicationEvalV6p1
and it seems to work fine.
But overriding >>generateByteCodesOn: is not good enough is it? The Compiler Classes can't have hard coded Eval instance creations either right? The Compiler Class has to be subClassed also and the
The problem in Squeak compiler that you will need to override much more classes than just Compiler to emit different bytecode, for instance.
meaningOf:inEnviron: needs to have a
( self createEval ) expression in it that could be subClassed and overridden. And then that subClass has to be easily inserted into the expression dispatch table that pairs up expressions with expression Compilers. So when that table gets made there should be a ( tableModifier modify: table ) which could stick the < expression
Compiler
pairs in that are needed.
I think that is all that would be required to modify the compilation of
an
expression. I will have to make these changes to picoLARC so it will be more
modifiable.
I think the Compiler should be very modular. For picoLARC one Class
per
expression and one Class per Eval seems to work good. Stuffing lots of seperate things into a single Class and doing a procedural functional
thing
and not an OOP thing does not seem good to me.
I think that the Compiler should be very clean and a best practices
example
with a long comment at the bottom of each method telling all about what
it
does. Writing it out and referencing other related methods helps to
think
about what is really going on and then a better design without hacks
comes
out. I don't think hacking should be encouraged at all. Hacking just
makes
a mess.
+1
The design should allow replacing critical parts of compiler by subclassing without the need in modifying original classes. A so-called extensions , or monkey patching is very bad practice which in straightly opposite direction from modularity.
I thinking, maybe at some point, to prevent monkey patching, a deployed classes can disallow installing or modifying their methods.
And then this practice of not making any Package comments has got to
stop.
I think that people who do that should be admonished in some way. I
think
that the Package comment for the Compiler should contain the design
document
for it that tells all about how it is designed. If it needs to be long
then
it should be long. It should include: How to understand the Compiler. There should be a sequence of test cases that start simple and show how
it
all works.
And that should go for the VM too. This idea that the VM can be opaque
and
only recognizable to a few is not good.
VM tend to be complex. And complexity comes from inability of our hardware/OS work in a ways how we need/want it.
These should be works of art and not hacked up piles of rubbish to be
hidden
away into obscurity.
There is this idea that one should only care about what something does.
And
the insides of it are a random black box that you tweek and pray on.
But I
think that the insides should be shown to the world. They should be displayed on a backdrop of velvet. Especially the Compiler and VM
and VM
maker. And then the whole Windowing thing should be modularized so you
can
have multiple different Windowing systems.
And what about having multiple VMs? It would be cool if picoLARC could
be
inside of Squeak in that way. It would be cool if one VM was
generalized so
that it could support different dialects and languages. And another
was
specific and fast. And you could make various kinds of VMs and images
and
output them onto disk without a lot of trouble. It would come with gcc
and
all that junk all set up so it would just work. If you already had gcc
you
could tell it not to download it.
What is gcc? And why it required to make VM? ;)
picoLARC has simple name spaces called Nodules where you can have
Nodules
inside of Nodules and Nodules can multiply inherit variables from
others.
Maybe such a thing could be used in Squeak? Then you could have
multiple
VMs. And VMs inside of VMs.
I think that Dolphin Smalltalk could be held up as an example of
pretty.
Maybe, if you know how to deal with license & copyrights when taking their source and blindly putting it to Squeak :)
I hope picoLARC will be another one.
I think that Squeak is pretty in a somewhat cancerous sort of way. The cancer is all the hacking. That goes on. The vision is great but the hacking and undocumenting gum up all those
big
ideas.
Sure it's quick but it rots away quickly too.
Undocumented features. In Smalltalk this is less of a problem but in
like
Lisp say you make this great feature but then don't document it. You
might
as well have not even made it.
-- Best regards, Igor Stasenko AKA sig.
-- David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com
Kjell Godo wrote:
Where is this new compiler project? Where is NewCompiler? I would like to see it. Does anybody know where that book about the Squeak Compiler went to?
Isn't it based on the Blue Book and the bluebook "missing chapters" ? http://stephane.ducasse.free.fr/FreeBooks.html
karl
On Tue, Sep 2, 2008 at 12:38 PM, Karl Ramberg karlramberg@gmail.com wrote:
Kjell Godo wrote:
Where is this new compiler project? Where is NewCompiler? I would like to see it. Does anybody know where that book about the Squeak Compiler went to?
Isn't it based on the Blue Book and the bluebook "missing chapters" ? http://stephane.ducasse.free.fr/FreeBooks.html
karl
There was an online book called something like: Guided Tour Of The Squeak Compiler or something like that. I saw the link to it and tried to click on it but it was not there.
Dear Edgar,
Peron said: If you wish nothing happens, nominate a comitee
The problem is that it is imposible today that "nothing" happen... and most problems are visible after time... as seen in the country of Peronismo.
The thought of a committee fills me with horror :) I don't think we need anything so baroque :)
Eliot: you must also firm a license agreement ...
Ale.
----- Original Message ----- From: "Edgar J. De Cleene" edgardec2001@yahoo.com.ar To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, September 01, 2008 6:02 PM Subject: Re: [squeak-dev] Re: Making a better Compiler for all
El 9/1/08 5:39 PM, "Eliot Miranda" eliot.miranda@gmail.com escribió:
The thought of a committee fills me with horror :) I don't think we need anything so baroque :)
Best Eliot
Peron said: If you wish nothing happens, nominate a comitee
2008/9/1 Eliot Miranda eliot.miranda@gmail.com:
Please have a look at my closure compiler. This puts bytecode generation into a separate class (a subclass of Encoder).
This is one of the things we really need to be decoupled.
You can find the code on the download page of my blog. Marcus Denker and I are in agreement that we will merge my Closure compiler into Markus' NewCompiler "some time soon". The thought of a committee fills me with horror :) I don't think we need anything so baroque :)
Well, i only hope, that you will not need to say to people words like: 'this stuff not working because you need my compiler to use it'. Or words like: 'this stuff works only in mine fork'. Maybe it is not hurts someone losing a potential contributors and splitting community over and over. But i think having something in common, like compiler is for best of all. Maybe i'm not right - it is always easier to manage a small group of contributors which never asking anyone's opinion how to do things, and in result they deliver things like Morphic and Etoys (sorry :) which nearly impossible to decouple from the rest of system, because obviously no one thought about things like running squeak w/o Morphic before.
And me, as a Squeak board member, as well as others were elected on the wave of making Squeak having better modularity. The lack of modularity in Squeak is one of the bigger issues in system, which prevents it to be easily managed and adopted for different solutions. One of the critical steps towards modularity is to make better, modular compiler. Of course, we can wait a little and start using NewSpeak, so there is nothing to do or worry about, isnt? ;)
Best Eliot
Hi,
Maybe i'm not right - it is always easier to manage a small group of contributors which never asking anyone's opinion how to do things, and in result they deliver things like Morphic and Etoys (sorry :) which nearly impossible to decouple from the rest of system, because obviously no one thought about things like running squeak w/o Morphic before.
I think it show that they can´t doit in other way, and it is good to work the best way for the "author/worker". The problem is what is missing that make people think they can´t decouple (anyPartOfTheSystem) by themselves. imho it reveals a failure in education efforts -download aFish instead of try fishing- and is a problem of this times (too easy/fast to fileIn and doIt).
A compiler framework is described as something we want, but we need more than two instances/compilers to start to think we have a framework (it can´t be invented). A way to make a framework emerge is to have more than one person/group working on alternatives and provide a set of open topDown requirements in form of tutorials/exemplars of use of Smalltalk compilation solutions. A swiki page with guides on how people want to use aNewSmalltalkCompiler may be used to guide people interested in write a concrete support.
best, Ale.
----- Original Message ----- From: "Igor Stasenko" siguctua@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, September 01, 2008 6:08 PM Subject: Re: [squeak-dev] Re: Making a better Compiler for all
2008/9/1 Eliot Miranda eliot.miranda@gmail.com:
Please have a look at my closure compiler. This puts bytecode generation into a separate class (a subclass of Encoder).
This is one of the things we really need to be decoupled.
You can find the code on the download page of my blog. Marcus Denker and I are in agreement that we will merge my Closure compiler into Markus' NewCompiler "some time soon". The thought of a committee fills me with horror :) I don't think we need anything so baroque :)
Well, i only hope, that you will not need to say to people words like: 'this stuff not working because you need my compiler to use it'. Or words like: 'this stuff works only in mine fork'. Maybe it is not hurts someone losing a potential contributors and splitting community over and over. But i think having something in common, like compiler is for best of all. Maybe i'm not right - it is always easier to manage a small group of contributors which never asking anyone's opinion how to do things, and in result they deliver things like Morphic and Etoys (sorry :) which nearly impossible to decouple from the rest of system, because obviously no one thought about things like running squeak w/o Morphic before.
And me, as a Squeak board member, as well as others were elected on the wave of making Squeak having better modularity. The lack of modularity in Squeak is one of the bigger issues in system, which prevents it to be easily managed and adopted for different solutions. One of the critical steps towards modularity is to make better, modular compiler. Of course, we can wait a little and start using NewSpeak, so there is nothing to do or worry about, isnt? ;)
Best Eliot
-- Best regards, Igor Stasenko AKA sig.
On Mon, Sep 1, 2008 at 2:13 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:
No, you cannot remove Squeak's compiler and use only NewCompiler, if that would have been your question.
That was not really my question.
I thought that the purpose of the NewCompiler project was to replace the old compiler. Am I wrong?
If so, is this just another way of telling people to support the NewCompiler project, or is it saying that we need a NewNewCompiler project.
If not what is wrong with NewCompiler, and why can't it become the standard Squeak compiler some day?
If you are saying we should all get behind NewCompiler, then we can ask what needs to be done to finish it, but first I am asking whether that is what you mean.
I've hacked the Squeak compiler a little and I think that everybody who has done that will agree that it should be replaced. As far as I can see, the NewCompiler people have a good design, and it should be possible use it in place of the old compiler, if not now, then with a little more work.
-Ralph
On Mon, Sep 1, 2008 at 2:13 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:
No, you cannot remove Squeak's compiler and use only NewCompiler, if that would have been your question.
May I urge that all efforts include Eliot's Cog work. He is making changes to the compiler to support closures and the Cog VM.
On Mon, 01 Sep 2008 18:06:00 +0200, Brent Pinkney wrote:
On Mon, Sep 1, 2008 at 2:13 AM, Klaus D. Witzel wrote:
No, you cannot remove Squeak's compiler and use only NewCompiler, if
that
would have been your question.
May I urge that all efforts include Eliot's Cog work. He is making changes to the compiler to support closures and the Cog VM.
Yes, sure. A good compiler supports *any* underlying instruction set and architecture (within a predetermined, plan-able framework), even the historical ones if someone wants to afford that.
I'm used to that in my shop; I think that everybody is.
On Mon, 01 Sep 2008 15:09:31 +0200, Ralph Johnson wrote:
On Mon, Sep 1, 2008 at 2:13 AM, Klaus D. Witzel wrote:
No, you cannot remove Squeak's compiler and use only NewCompiler, if that would have been your question.
That was not really my question.
NP, and sorry for disturbing your cycles.
I thought that the purpose of the NewCompiler project was to replace the old compiler. Am I wrong?
This would be interesting to find out, what "to replace" plans where there, also from a "managable" POV. I'm afraid I don't know any historical records which detail such plan, except the "can replace" wording mentioned in
- http://wiki.squeak.org/squeak/search?search=newcompiler&casesensitive=fa...
Anybody have more/other pointers?
If so, is this just another way of telling people to support the NewCompiler project, or is it saying that we need a NewNewCompiler project.
No, I'm in favor of Igor's suggestion: make a new compiler. And ask people what they want in it, possible answers (but no limited to)
o faster compilation (faster than what? *) o don't aim to be a framework for *everything* o just be reliable and do the job o decompilation from CompiledMethod guaranteed (!) o very good syntax error messages/selections o very good spelling/correction support o no more "private" public hacks, because: o extensibility/dialects only by subclassing (or so, Traits anybody?) o better/more optimization of compiled methods? o backward compatability at the bytecode level? o evaluation restricted to what properly does #storeOn:? o clear rules for name-spaceing and modularizing things? o my favorite: less knowledge about how other classes work ;)
*) there are some 123 classes in NewCompiler & friends (not counting some roots like SmaCCParser) , versus some 30 classes in old compiler & friends.
If not what is wrong with NewCompiler, and why can't it become the standard Squeak compiler some day?
Because too much packages depend on what/how old compiler makes/does things? (my POV depends on my use of things, YMMV).
For a prominent example, VMMaker cannot make much use of NewCompiler without rewriting the most vital parts of it almost from scratch (IMHO). But VMMaker is needed for getting the next VM out.
If you are saying we should all get behind NewCompiler, then we can ask what needs to be done to finish it, but first I am asking whether that is what you mean.
I mean, that Squeak community cannot have both: complains about too many hacks being/"unmaintainable" in the old compiler and, be rather silent when NewCompiler happens to be mentioned.
That would be a huge waste of time and effort and a very dark & sticky & disgusting shadow over things IMHO.
The compiler is too important for letting business go as usual (e.g. let's wait what happens and if nothing happens then do nothing; no offense, we all have our full plate). That's how I think about it.
I've hacked the Squeak compiler a little and I think that everybody who has done that will agree that it should be replaced.
Yes, replaced, made obsolete, so that nothing can depend on it any longer. Then it can be put on the downloadable package list, for people who want it and/or want to maintain it. Good move, that is.
As far as I can see, the NewCompiler people have a good design, and it should be possible use it in place of the old compiler, if not now, then with a little more work.
Then why is it not used in a promising project like COG, right from the beginning? This rather rhetorical question has nothing against Eliot, I understand the answer he blogged.
/Klaus
-Ralph
squeak-dev@lists.squeakfoundation.org
-
Alejandro F. Reimondo -
Brent Pinkney -
David Zmick -
Edgar J. De Cleene -
Eliot Miranda -
Igor Stasenko -
Karl Ramberg -
Kjell Godo -
Klaus D. Witzel -
Ralph Johnson