New Compiler
Locked
 
|
Hi,
Marcus Denker and myself will be working on the New Compiler for Pharo. We have a plan draft of the steps that need to be followed in order to get it up and running in Pharo: 1.- Write good tests for each module parse, check, codeGen, execute and check if works. First simple example, and then complex ones. Test recompilation too. 2.- Performance, how long does it take compared to the old compiler. 3.- Error messages: at least like in the old compiler. 4.- Introduce Eliot's Closures. Soon we will have a more detailed and formal list of thing to be done. Cheers, Jorge Ressia _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi Jorge,
great to hear. I have two things that I wish you add to your list: 1. My first wish also affects the old compiler, but that should be easy to fix in Pharo. Currently there are dozens of selectors in Behavior that hardcode the currently used compiler #parseClass, #compilerClass, #evaluatorClass, #decompilerClass, #subclassDefinerClass, ... I would prefer to have exactly one entry point, for example under the name #compiler. This object could act like a compiler MOP on the receiving class and set through a preference for all classes of the system that do not override this method themselves. This would make it much cleaner to have different compilers in the image, swap them on the fly, get rid of various hacks and overrides and even allow to unload the old compiler. 2. My second wish is only about the new compiler. One thing stroke me when working on transactional memory and domain specific languages, is that the new compiler isn't as extensible as it advertises. The problem is there is no central place where the different phases (parsing, annotation, bytecode generation) of the compilation is triggered. Currently this happens at various places throughout the system. This has not only the problem that extending the compiler is difficult without patching it, but also makes it nearly impossible to get certain information at a particular place of the process. For example, during parsing it is not know in what class the method is supposed to be compiled, or during bytecode generation I don't know the source code anymore, etc. I suggest to introduce a compilation context, that is accessible anywhere and that can pass necessary information through the compilation phases. Furthermore I suggest to implement the delegation to the different parts of the compiler in a deticated object that can be subclassed and used for example if somebody wants to cleanly replace, customize or extend certain parts of the compiler. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I would love to have one compilerContext object so that we do not have
to pass all these parameters plague It would be nice to have compile: 'text' context: (aCompilerContext) aCompilerContext in: aClass ; silently: true ; inCategory: 'zork' But this is something we should do after :) On Mar 4, 2009, at 10:59 AM, Lukas Renggli wrote: > Hi Jorge, > > great to hear. I have two things that I wish you add to your list: > > 1. My first wish also affects the old compiler, but that should be > easy to fix in Pharo. Currently there are dozens of selectors in > Behavior that hardcode the currently used compiler #parseClass, > #compilerClass, #evaluatorClass, #decompilerClass, > #subclassDefinerClass, ... I would prefer to have exactly one entry > point, for example under the name #compiler. This object could act > like a compiler MOP on the receiving class and set through a > preference for all classes of the system that do not override this > method themselves. This would make it much cleaner to have different > compilers in the image, swap them on the fly, get rid of various hacks > and overrides and even allow to unload the old compiler. > > 2. My second wish is only about the new compiler. One thing stroke me > when working on transactional memory and domain specific languages, is > that the new compiler isn't as extensible as it advertises. The > problem is there is no central place where the different phases > (parsing, annotation, bytecode generation) of the compilation is > triggered. Currently this happens at various places throughout the > system. This has not only the problem that extending the compiler is > difficult without patching it, but also makes it nearly impossible to > get certain information at a particular place of the process. For > example, during parsing it is not know in what class the method is > supposed to be compiled, or during bytecode generation I don't know > the source code anymore, etc. I suggest to introduce a compilation > context, that is accessible anywhere and that can pass necessary > information through the compilation phases. Furthermore I suggest to > implement the delegation to the different parts of the compiler in a > deticated object that can be subclassed and used for example if > somebody wants to cleanly replace, customize or extend certain parts > of the compiler. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Jorge Ressia
Jorge Ressia wrote:
> Hi, > > Marcus Denker and myself will be working on the New Compiler for > Pharo. And once again I ask. Why can this not be a New Compiler for everyone? Why can it not be a "New Compiler, full stop" as a black box, that will work for anyone who interfaces to it in a certain way? 1) I am not asking you to be backward compatible. 2) Thinking about it in this way will help you to design to be more modular and to not make too many assumptions about the rest of the system. 3) Having a wider audience encourages documentation. 3) Additional benefits come from a wider potential deployment and testing. 4) It will benefit you to get used to the compiler being a loadable, pluggable (unpluggable?) module. It will encourage others to code the rest of pharo in such a way as to not tie it in to closely. You may also architect for the Compiler being a loadable/switchable chunk that can be swapped atomically, and reverted if things go wrong. 5) If you get the interfaces right, others may contribute alternative compilers within the framework. I don't think that others understand my expectation for 3.11+ is not for squeak to remain compatible at all costs, but to envisage a platform that can handle big changes. Not in an evolutionary way as pharo is doing, but in a revolutionary way such as Rio is doing. Your announcement that you are "doing a new compiler" is exactly the kind of revolutionary enhancement that we are eager to be able to adopt. If you think about it, you will probably run the Pharo-old and pharo-new alongside for a while until Pharo-new becomes ready enough to be a step change. I believe that progress for squeak will be best made in carefully crafted step changes, and I have fully expected new compiler be one such change. Marcus seems upset by the way he feels he has been treated by the squeak community in the past. But I am not part of that past, I arrived (from ST/X) in the 3.8/3.9 era. We are in a new phase now, that of finding ways to embrace the progress that others make, and seeking to make use of it. thanks in advance Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>> Marcus Denker and myself will be working on the New Compiler for
>> Pharo. > And once again I ask. Why can this not be a New Compiler for everyone? > Why can it not be a "New Compiler, full stop" as a black box, that > will > work for anyone who interfaces to it in a certain way? I am sure nobody is against getting the new compiler for Squeak or other dialects. However, it seems to me to be easier to achieve in Pharo. Again, if someone is willing to port it to other platform, that's great Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
2009/3/4 Stéphane Ducasse <[hidden email]>:
> I would love to have one compilerContext object so that we do not have > to > pass all these parameters plague > > It would be nice to have > compile: 'text' context: (aCompilerContext) > > aCompilerContext > in: aClass ; > silently: true ; > inCategory: 'zork' > > But this is something we should do after :) This is something i'm already done in own implementation of parser. I have a context object which role is to respond to such things like silently/interactive, class etc.. > - Show quoted text - > On Mar 4, 2009, at 10:59 AM, Lukas Renggli wrote: > >> Hi Jorge, >> >> great to hear. I have two things that I wish you add to your list: >> >> 1. My first wish also affects the old compiler, but that should be >> easy to fix in Pharo. Currently there are dozens of selectors in >> Behavior that hardcode the currently used compiler #parseClass, >> #compilerClass, #evaluatorClass, #decompilerClass, >> #subclassDefinerClass, ... I would prefer to have exactly one entry >> point, for example under the name #compiler. This object could act >> like a compiler MOP on the receiving class and set through a >> preference for all classes of the system that do not override this >> method themselves. This would make it much cleaner to have different >> compilers in the image, swap them on the fly, get rid of various hacks >> and overrides and even allow to unload the old compiler. >> >> 2. My second wish is only about the new compiler. One thing stroke me >> when working on transactional memory and domain specific languages, is >> that the new compiler isn't as extensible as it advertises. The >> problem is there is no central place where the different phases >> (parsing, annotation, bytecode generation) of the compilation is >> triggered. Currently this happens at various places throughout the >> system. This has not only the problem that extending the compiler is >> difficult without patching it, but also makes it nearly impossible to >> get certain information at a particular place of the process. For >> example, during parsing it is not know in what class the method is >> supposed to be compiled, or during bytecode generation I don't know >> the source code anymore, etc. I suggest to introduce a compilation >> context, that is accessible anywhere and that can pass necessary >> information through the compilation phases. Furthermore I suggest to >> implement the delegation to the different parts of the compiler in a >> deticated object that can be subclassed and used for example if >> somebody wants to cleanly replace, customize or extend certain parts >> of the compiler. >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Jorge Ressia
Please don't loose the fact that the Alien support mucks about in the
compiler too. On 4-Mar-09, at 12:51 AM, Jorge Ressia wrote: > Hi, > > Marcus Denker and myself will be working on the New Compiler for > Pharo. We have a plan draft of the steps that need to be followed in > order to get it up and running in Pharo: -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Jorge Ressia
On Wed, Mar 4, 2009 at 9:51 PM, Jorge Ressia <[hidden email]> wrote:
I would like to see a different way of editing code: any modifications in a code pane are assumed to be unsaved changes to the source code. This means that things like "Print it" and error messages should go to a separate text pane on the UI somewhere - maybe a pop-up at the location of the error, or in a status bar, or maybe a separate list of errors/warnings like other IDEs do??? I haven't looked at the code for reporting error messages, but I'm assuming (and hoping) that the compiler just reports an error message and a character index, and the "presentation layer" does the notification? Gulik. -- http://gulik.pbwiki.com/ _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/3/5 Michael van der Gulik <[hidden email]>:
> > > On Wed, Mar 4, 2009 at 9:51 PM, Jorge Ressia <[hidden email]> wrote: > >> >> 3.- Error messages: at least like in the old compiler. > > > I would like to see a different way of editing code: any modifications in a > code pane are assumed to be unsaved changes to the source code. This means > that things like "Print it" and error messages should go to a separate text > pane on the UI somewhere - maybe a pop-up at the location of the error, or > in a status bar, or maybe a separate list of errors/warnings like other IDEs > do??? > > I haven't looked at the code for reporting error messages, but I'm assuming > (and hoping) that the compiler just reports an error message and a character > index, and the "presentation layer" does the notification? > I prefer a status line (or more complex morph) which appears at the bottom of text area - there can be shown an error message , as well as 'accept/cancel' buttons. We also could make it appear only if source has changed. > Gulik. > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |