- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Seaside] Seaside on Pharo-Kernel

by stephane ducasse

On Aug 11, 2011, at 12:12 AM, Igor Stasenko wrote: > On 9 August 2011 18:59, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Wow. This is awesome: a working Seaside image in 4.3 MB. >> > Indeed. > Now if we could have some remote browsing/remote debugging tools.. > (please say nothing about RFB) Normally with what we are doing around having an environment + ring + nick papoulyas work we should get there. Stef

Aug. 11, 2011

Re: [Pharo-project] omit support in PetitParser

by Tudor Girba

Hi, Camillo, thanks for taking an interest and for letting us know that you committed. Lukas, thanks for the answer. I would also like to add one comment: omit is maybe interesting for small and quick parsers in which you have the grammar and the parser together. However, for anything significant, if you want to split the grammar and the various parsers, it all of a sudden becomes less useful because you do not want to restrict the grammar. I also took a quick look at the implementation. There are simply too many ifs that add complexity to an already non-trivial code. All in all, I think we should retire this add-on. Cheers, Doru On 11 Aug 2011, at 07:31, Lukas Renggli wrote: > Hi Camillo, > >> I quickly hacked (with a lot of tests) support for omit in PetitParser. >> This should simplify some parsing efforts as an additional filtering step could be avoided. >> >> parser := ($" asParser omit, $" asParser negate star flatten, $" asParser omit) >> parser parse: '"asdfsd"' "yields directly #('asdfsd') " >> >> vs >> >> parser := ($" asParser, $" asParser negate star flatten, $" asParser) >> parser parse: '"asdfsd"' >> >> which yields #($" 'asdfsd' $") > > I don't really see use of #omit. The element is still in a collection > and you need to extract it from there. What is the benefit other than > it is now at index 1 instead of 2? > > Also the implementation has some problems: > > 1. #omit makes it really hard to compose grammars, because parsers > suddenly get very asymmetric and start to affect each others behavior > depending on how you compose them. > > 2. For the same reason grammar transformation becomes impossible, one > of the design goals of PetitParser. > > 3. #omit makes a typical grammar (the smalltalk one) roughly 15% > slower without even using the new feature. > > 4. There are various methods (#-, #match..., #copy..., ...) that need > to be fixed when you add state to a parser. > > 5. There is no need for eager (#initialize) as well as lazy > initialization (kills the possibility for a quick invocation). > > 6. Please do not remove PPParser class>>new and do not change how > initialization works, otherwise you break GemStone, VisualWorks, and > GNU Smalltalk. The Seaside wiki has some nice documentation of how to > correctly initialize objects (basically following the pattern of > Objective-C). > > I think, problems 1, 3 (!), 4, 5 and to some extent also 2 could be > solved if the implementation was a bit more object-oriented. That is, > if you added a PPOmitParser that would dispatch from #parseOn: to some > other parsing method #parseOmittedOn: you wouldn't need all those > #ifTrue:ifFalse:. > >> I pushed my solution to the petitparser repos. I didn't add full support for flatten. > > Did you see #map: and #permutation:? Both allow you do the same in a > less invasive way: > > parser := ($" asParser , $" asParser negate star flatten, $" asParser). > parser map: [ :begin :inner :end | inner ] > > or > > parser := ($" asParser , $" asParser negate star flatten, $" asParser). > parser permutation: #(2) > > Additionally, did you see the experimental binding/capturing > functionality in PetitBeta? This kind of provides something much more > general and (I believe) much more powerful without the above > drawbacks. Bind-Capture allows you to bind certain parse results > anywhere down the tree to names and directly access them later on in a > capture block. It also deals with unpacking and reshuffling > collections automatically, check the tests for that. > > Your example would look like: > > parser := ($" asParser , ($" asParser negate star flatten bind: > #inner) , $" asParser). > parser capture: [ :inner | inner ] > > Cheers, > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Obvious things are difficult to teach."

Aug. 11, 2011

Re: [Pharo-project] omit support in PetitParser

by Lukas Renggli

Hi Camillo, > I quickly hacked (with a lot of tests) support for omit in PetitParser. > This should simplify some parsing efforts as an additional filtering step could be avoided. > > Â Â parser := ($" asParser omit, $" asParser negate star flatten, $" asParser omit) > Â Â parser parse: '"asdfsd"' "yields directly Â #('asdfsd') " > > vs > > Â Â parser := ($" asParser, $" asParser negate star flatten, $" asParser) > Â Â parser parse: '"asdfsd"' > > which yields Â #($" 'asdfsd' $") I don't really see use of #omit. The element is still in a collection and you need to extract it from there. What is the benefit other than it is now at index 1 instead of 2? Also the implementation has some problems: 1. #omit makes it really hard to compose grammars, because parsers suddenly get very asymmetric and start to affect each others behavior depending on how you compose them. 2. For the same reason grammar transformation becomes impossible, one of the design goals of PetitParser. 3. #omit makes a typical grammar (the smalltalk one) roughly 15% slower without even using the new feature. 4. There are various methods (#-, #match..., #copy..., ...) that need to be fixed when you add state to a parser. 5. There is no need for eager (#initialize) as well as lazy initialization (kills the possibility for a quick invocation). 6. Please do not remove PPParser class>>new and do not change how initialization works, otherwise you break GemStone, VisualWorks, and GNU Smalltalk. The Seaside wiki has some nice documentation of how to correctly initialize objects (basically following the pattern of Objective-C). I think, problems 1, 3 (!), 4, 5 and to some extent also 2 could be solved if the implementation was a bit more object-oriented. That is, if you added a PPOmitParser that would dispatch from #parseOn: to some other parsing method #parseOmittedOn: you wouldn't need all those #ifTrue:ifFalse:. > I pushed my solution to the petitparser repos. I didn't add full support for flatten. Did you see #map: and #permutation:? Both allow you do the same in a less invasive way: parser := ($" asParser , $" asParser negate star flatten, $" asParser). parser map: [ :begin :inner :end | inner ] or parser := ($" asParser , $" asParser negate star flatten, $" asParser). parser permutation: #(2) Additionally, did you see the experimental binding/capturing functionality in PetitBeta? This kind of provides something much more general and (I believe) much more powerful without the above drawbacks. Bind-Capture allows you to bind certain parse results anywhere down the tree to names and directly access them later on in a capture block. It also deals with unpacking and reshuffling collections automatically, check the tests for that. Your example would look like: Â parser := ($" asParser , ($" asParser negate star flatten bind: #inner) , $" asParser). parser capture: [ :inner | inner ] Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 11, 2011

Re: [Pharo-project] got a surprising behavior

by Camillo Bruni

could not reproduce in a fresh image ;) On 2011-08-11, at 01:53, Camillo Bruni wrote: > so let's test this :D > > On 2011-08-10, at 23:33, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I got a really strange behavior: >> I integrated >> >> - Issue 4607: Refactor Debugger >> content:notifying:. Thanks Camillo Bruni. >> http://code.google.com/p/pharo/issues/detail?id=4607 >> >> - Issue 4606: Fix drawing shadow of morphs. Thanks Igor Stasenko. >> http://code.google.com/p/pharo/issues/detail?id=4606 >> >> and I could not type enter on workspace >> I could everywhere else. >> >> I could reopen a workspace and it worked and suddenly stopped again. >> >> >> stef > >

Aug. 11, 2011

Re: [Pharo-project] got a surprising behavior

by Camillo Bruni

so let's test this :D On 2011-08-10, at 23:33, StÃ©phane Ducasse wrote: > Hi guys > > I got a really strange behavior: > I integrated > > - Issue 4607: Refactor Debugger >> content:notifying:. Thanks Camillo Bruni. > http://code.google.com/p/pharo/issues/detail?id=4607 > > - Issue 4606: Fix drawing shadow of morphs. Thanks Igor Stasenko. > http://code.google.com/p/pharo/issues/detail?id=4606 > > and I could not type enter on workspace > I could everywhere else. > > I could reopen a workspace and it worked and suddenly stopped again. > > > stef

Aug. 10, 2011

[Pharo-project] omit support in PetitParser

by Camillo Bruni

I quickly hacked (with a lot of tests) support for omit in PetitParser. This should simplify some parsing efforts as an additional filtering step could be avoided. parser := ($" asParser omit, $" asParser negate star flatten, $" asParser omit) parser parse: '"asdfsd"' "yields directly #('asdfsd') " vs parser := ($" asParser, $" asParser negate star flatten, $" asParser) parser parse: '"asdfsd"' which yields #($" 'asdfsd' $") I pushed my solution to the petitparser repos. I didn't add full support for flatten. cami

Aug. 10, 2011

Re: [Pharo-project] [Seaside] Seaside on Pharo-Kernel

by Igor Stasenko

On 9 August 2011 18:59, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Wow. This is awesome: a working Seaside image in 4.3 MB. > Indeed. Now if we could have some remote browsing/remote debugging tools.. (please say nothing about RFB) > On Tue, Aug 9, 2011 at 3:11 PM, Pavel Krivanek <squeak3(a)continentalbrno.cz> > wrote: >> >> There is a prepared image: >> >> >> https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Seas… >> >> -- Pavel >> >> On Tue, Aug 9, 2011 at 3:03 PM, Sven Van Caekenberghe <sven(a)beta9.be> >> wrote: >> > Hi Pavel, >> > >> > This is really cool! >> > >> > Sven >> > >> > On 09 Aug 2011, at 12:52, Pavel Krivanek wrote: >> > >> >> Hi, >> >> >> >> there's possible to load Seaside to the Pharo-Kernel. >> >> >> >> 1) Load PharoKernel-Gofer image from CI server >> >> >> >> (https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Gofe…) >> >> >> >> 2) run the image with seaside.st script as an argument. That will >> >> create about 4.1 MB image with basic Seaside packages and basic >> >> examples. >> >> >> >> 3) run the image with run.st script (note that starting of the server >> >> in the seaside.st script will hang, currently I have no idea why). >> >> >> >> 4) see if everything works at >> >> http://localhost:8080/examples/examplebrowser >> >> >> >> Cheers, >> >> -- Pavel >> >> <run.st><seaside.st>_______________________________________________ >> >> seaside mailing list >> >> seaside(a)lists.squeakfoundation.org >> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > >> > _______________________________________________ >> > seaside mailing list >> > seaside(a)lists.squeakfoundation.org >> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > -- > Mariano > http://marianopeck.wordpress.com > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Best regards, Igor Stasenko AKA sig.

Aug. 10, 2011

Re: [Pharo-project] Pharo Kernel OSProcess evaluator

by Igor Stasenko

Pavel, could you provide some details, about where and how it could be used. And maybe some examples. Because its not clear , what is it. Because i think that most people get used to having an UI and using headless images is something much more complicated (since you cannot see what happens). On 10 August 2011 23:28, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > link: https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20OSPr… > > On Wed, Aug 10, 2011 at 11:27 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> I created a new job on CI server that creates a Pharo Kernel image >> with OSProcess loaded and simple console based evaluator. Of course >> something like Coral would be better ;-) >> >> Cheers >> -- Pavel >> > > -- Best regards, Igor Stasenko AKA sig.

Aug. 10, 2011

Re: [Pharo-project] got a surprising behavior

by Igor Stasenko

On 10 August 2011 23:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I got a really strange behavior: > Â Â Â Â I integrated > > Â Â Â Â - Â Issue 4607: Â Refactor Debugger >> content:notifying:. Thanks Camillo Bruni. > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4607 > > Â Â Â Â - Issue 4606: Fix drawing shadow of morphs. Thanks Igor Stasenko. > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4606 > > and I could not type enter on workspace > I could everywhere else. > > I could reopen a workspace and it worked and suddenly stopped again. > what i can say that apparently it has nothing to do with shadows. so blame mr. Camillo Bruni :) > > stef > -- Best regards, Igor Stasenko AKA sig.

Aug. 10, 2011

[Pharo-project] [update 1.4] #14080

by StÃ©phane Ducasse

14080 ----- - Issue 4607: Refactor Debugger >> content:notifying:. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=4607 - Issue 4606: Fix drawing shadow of morphs. Thanks Igor Stasenko. http://code.google.com/p/pharo/issues/detail?id=4606 - Issue 4607: Minor-fix-to-the-old-MCMergeBrowser. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=4601 more to come as soon as I get some sleep :) Stef

Aug. 10, 2011