August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo Kernel OSProcess evaluator

by Pavel Krivanek

Hi, the main task of this build is to ensure that we can load OSProcess and provide a pattern for the user jobs that want to use OSProcess. https://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ke… The next purpose of this image is to enable an interactive communication with the image and make the development of headless images easier. What you get is something similar to irb or interactive python interpreter. And of course it may be used for simple Smalltalk scripts. For example the command: squeakvm -headless PharoKernel-OSProcessEvaluator.image < script > out.txt where the script file looks like this: 20000 factorial Smalltalk snapshot: false andQuit: true (ending with lf) Cheers, -- Pavel On Thu, Aug 11, 2011 at 12:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. 11, 2011

Re: [Pharo-project] omit support in PetitParser

by Lukas Renggli

> 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). Some people asked me where to find the mentioned documentation: http://code.google.com/p/seaside/wiki/ObjectInitialization. Note that the described principles are not only useful if you want to write portable software, but also more generally to keep hierarchies extensible. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 11, 2011

Re: [Pharo-project] got a surprising behavior

by StÃ©phane Ducasse

I do not think that this is linked to the these changes. Because camillo changes were about MC :) and debugger After I could not reproduce it. Stef On Aug 11, 2011, at 2:04 AM, Camillo Bruni wrote: > > 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] [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