March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.1] #11243

by Marcus Denker

On Mar 4, 2010, at 11:30 AM, Lukas Renggli wrote: >> indeed. In turn, Helvetia would actually simplify the implementation. E.g. Quasi-Quoting >> is very nice when building AST snippits to be inserted. > > The situation also has its advantages :-) > > I recently rewrote the Quasiquoting bootstrap code in a new and much > simpler way. Instead of directly plugging it into the NewCompiler and > generating byte code, I reimplemented the quoting mechanism as a pure > parse tree transformation on the AST. Like this it is the whole thing > is independent of the actual compiler being used. The quote, unquote > and splice nodes can be transformed to traditional nodes as a > preprocessing step to any backend. > Very good! This means it fits nicely into the pure-AST model fo Reflectivity... (where bytecode is just an execution artefact, like the machine code in a JIT, but never used as the model of Reflection or presented to the programer in any form) > >> With Johan, I plan to use Helvetia together with Reflectivity for some research project. > > Cool. Keep me in the loop on that. > Will do. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 4, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues

by Henrik Johansen

FWIW, this quote from the following discussion on Squeak-dev distills what I was trying (but failing) to demonstrate: "We shouldn't stop trying to support well-behaved ensure blocks properly. Because if we don't then ensure becomes entirely random. Or can anyone here explain why it would be reasonable to expect that this version works: p := [[Processor yield] ensure:[Transcript show: 'finished']] fork. Processor yield. p terminate. but this one doesn't: p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork. Processor yield. p terminate. (we're using yield here to denote any kind of process switch) If the only thing that determines whether an ensure block is executed is a process switch, then we basically have random, non-predictable unwind handling. Which is a problem that is entirely unrelated to whether the unwind block is itself well-behaved or not. " In a book with chapters discussing topics such as ensure and processes, (based on Pharo 1.0 which is unlikely to contain any fixes for such an issue), it deserves at least a mention. Cheers, Henry Den 03.03.2010 15:33, skrev Levente Uzonyi: > On Wed, 3 Mar 2010, StÃ©phane Ducasse wrote: > >> >> On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: >> >>> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: >>> >>>> >>>>>> PS. For the not-so-faint-of-heart, open a Transcript and try >>>>>> evaluating: >>>>>> |proc| >>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>>>> 'Finish!' Processor yield.]] newProcess. >>>>>> proc resume. >>>>>> Processor yield. >>>>>> proc suspend. >>>>>> proc terminate. >>>>> Why don't we get it printing? >>>> Forgot a . there, supposed to be >>>> >>>> |proc| >>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>> 'Finish!'. Processor yield.]] newProcess. >>>> proc resume. >>>> Processor yield. >>>> proc suspend. >>>> proc terminate. >>>> >>>> on my machine it prints: >>>> *Start!Start!Finish! >>> >>> The problem occurs because Transcript >> #endEntry (sent from #show:) >>> takes a while to execute, so the process (proc) prints 'Start!', but >>> it gets terminated before execution reaches #resetContents (#reset in >>> Squeak). So 'Start!' is still in the stream. Then our process >>> executes the >>> #ensure: block and it prints 'Start!' and 'Finish!' too. >> >> >> Thanks for the explanation levente! >> But I'm still dizzy :) why Transcript show: 'Finish' would also print >> 'start' ? > > Transcript is just a stream. #show: is just a combination of > #nextPutAll: and #endEntry. #endEntry displays the contents of the > stream and when that's done it removes everything from the stream with > #resetContents. #resetContents is never executed, because the process > is terminated before that. So the contents of the stream are kept and > displayed again later. > > > Levente > >> >>> >>> There's worse problem with #ensure: and #terminate is that, a >>> process executing an #ensure: block can be terminated. If you >>> evaluate this code: >>> >>> | process stage1 stage2 stage3 counter | >>> stage1 := stage2 := stage3 := false. >>> counter := 0. >>> process := [ >>> [ stage1 := true ] ensure: [ >>> stage2 := true. >>> 1000000 timesRepeat: [ counter := counter + 1 ]. >>> stage3 := true ] ] newProcess. >>> process resume. >>> Processor yield. >>> process suspend. >>> process terminate. >>> 1000 milliSeconds asDelay wait. >>> { stage1. stage2. stage3. counter } explore >>> >>> you will find that stage1 and stage2 is reached as expected, but >>> stage3 is not and counter is less than 1000000. That's because the >>> forked process started evaluating the #ensure: block, but it was >>> terminated by our process. >>> >>> Is this the expected behavior when sending #terminate to a process >>> which is evaluating an #ensure: block? >>> >>> >>> Cheers, >>> BalÃ¡zs & Levente >>> >>> >>>> >>>> *yay >>>> Henry* >>>> * >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

> indeed. In turn, Helvetia would actually simplify the implementation. E.g. Quasi-Quoting > is very nice when building AST snippits to be inserted. The situation also has its advantages :-) I recently rewrote the Quasiquoting bootstrap code in a new and much simpler way. Instead of directly plugging it into the NewCompiler and generating byte code, I reimplemented the quoting mechanism as a pure parse tree transformation on the AST. Like this it is the whole thing is independent of the actual compiler being used. The quote, unquote and splice nodes can be transformed to traditional nodes as a preprocessing step to any backend. > And of course Bytesurgeon screams for a Language-Boxes DSL (even though not directly > related to Reflectivity). Yeah, but first I have to get everything working again. My demo image is still a pre-closure one. > With Johan, I plan to use Helvetia together with Reflectivity for some research project. Cool. Keep me in the loop on that. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Marcus Denker

On Mar 4, 2010, at 10:58 AM, Lukas Renggli wrote: >> But I *definitly* need the infrastructure... in some form. I need to get Reflectivity to >> work again, it's needed for at least Jorge's work and JB's work... and for other research >> on Reflection. > > Helvetia needs it too. Now I am using the old compiler as a backend, > that works reasonably well. I have other problems getting it to work > in the latest Pharo now. > indeed. In turn, Helvetia would actually simplify the implementation. E.g. Quasi-Quoting is very nice when building AST snippits to be inserted. And of course Bytesurgeon screams for a Language-Boxes DSL (even though not directly related to Reflectivity). With Johan, I plan to use Helvetia together with Reflectivity for some research project. So... yes. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

> But I *definitly* need the infrastructure... in some form. I need to get Reflectivity to > work again, it's needed for at least Jorge's work and JB's work... and for other research > on Reflection. Helvetia needs it too. Now I am using the old compiler as a backend, that works reasonably well. I have other problems getting it to work in the latest Pharo now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Marcus Denker

On Mar 4, 2010, at 9:53 AM, Lukas Renggli wrote: >>> I'll try to build the tests and come up with a better solution. >> >> You what I would love to spend 2/3 weeks just coding in the new compiler and making sure >> that it has the right abstractions/messages to deal with issue like that. > > The problem is that the New Compiler is not really in a better state > than the old compiler. Of course it has more objects and is much > easier to extend, but all in all it is a mess too. This is mostly due > to the fact that the system below it changed quite a bit in the past > years (pragmas, properties, closures, primitives, new bytecodes, ...) > and that the New Compiler had to be patched and changed quite heavily > to accommodate these new requirements that it was not designed for. > Maintaining and fixing the New Compiler got so extremely expensive > that it is questionable if this is still a viable platform? Ask Jorge > and Marcus. It needs work.... the problem is that I did not have any time and energy to work on it. (traveling/moving and learning new languages are nice, but two time in one year was too much...). But I *definitly* need the infrastructure... in some form. I need to get Reflectivity to work again, it's needed for at least Jorge's work and JB's work... and for other research on Reflection. I plan to somehow allocate more energy to this the next weeks (and maybe scale down on Pharo bugfix harvesting. Note to self: Definitly I should not start any new things in addition). One thing that is clear: In general, having X things doing the same is not going to work in the long run. We need to concentrate to have one Ok instance of everything. This is true for GUI toolskits, Parsers, ASTs, Compilers, Browsers... Than we can iterate on this one thing to make it better. Wasting engery to maintain multiple instances of everything makes no sense. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Peter Hugosson-Miller

On Thu, Mar 4, 2010 at 10:08 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Strange to see how subjective it is... > > My brain is well trained to rectangle blocks and I arrive to the > > opposite conclusions on each point. > > I agree 100% with all that Doru wrote. These patterns have been > successfully used for almost a decade in open-source projects like > Seaside, Moose, Magritte, Mondrian, Pier, Glamour, PetitParser, > Grease, OmniBrowser, SqueakSource, ... > Indeed, it appears to be very subjective, with clearly stated arguments for both sides, so it's doubtful there will ever be consensus on this. FWIW, I agree 100% with everything Eliot wrote (although I admit he piqued my curiosity with the mention of the "trailing period" :-p Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Cheers, Peter

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

> Strange to see how subjective it is... > My brain is well trained to rectangle blocks and I arrive to the > opposite conclusions on each point. I agree 100% with all that Doru wrote. These patterns have been successfully used for almost a decade in open-source projects like Seaside, Moose, Magritte, Mondrian, Pier, Glamour, PetitParser, Grease, OmniBrowser, SqueakSource, ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Jorge Ressia

Yes, the New compiler is not better. However, I think the New Compiler is the right direction to pursue. After fighting with it for some months to make the Closures work in it I can tell you that I learn a great deal from it, painfully :) . But I now have a pretty good idea of what it is required to have a modularized compiler with more suitable abstraction for this particular domain. I implemented many tests and I have to implement a lot more. Then, I believe that by expressing ourselves through these tests we will be able to modify the compiler to make it look the way we want. At least that is my plan with the New compiler. Cheers, Jorge On Thu, Mar 4, 2010 at 9:53 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> I'll try to build the tests and come up with a better solution. >> >> You what I would love to spend 2/3 weeks just coding in the new compiler and making sure >> that it has the right abstractions/messages to deal with issue like that. > > The problem is that the New Compiler is not really in a better state > than the old compiler. Of course it has more objects and is much > easier to extend, but all in all it is a mess too. This is mostly due > to the fact that the system below it changed quite a bit in the past > years (pragmas, properties, closures, primitives, new bytecodes, ...) > and that the New Compiler had to be patched and changed quite heavily > to accommodate these new requirements that it was not designed for. > Maintaining and fixing the New Compiler got so extremely expensive > that it is questionable if this is still a viable platform? Ask Jorge > and Marcus. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

>> I'll try to build the tests and come up with a better solution. > > You what I would love to spend 2/3 weeks just coding in the new compiler and making sure > that it has the right abstractions/messages to deal with issue like that. The problem is that the New Compiler is not really in a better state than the old compiler. Of course it has more objects and is much easier to extend, but all in all it is a mess too. This is mostly due to the fact that the system below it changed quite a bit in the past years (pragmas, properties, closures, primitives, new bytecodes, ...) and that the New Compiler had to be patched and changed quite heavily to accommodate these new requirements that it was not designed for. Maintaining and fixing the New Compiler got so extremely expensive that it is questionable if this is still a viable platform? Ask Jorge and Marcus. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010