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

Re: [Pharo-project] omit support in PetitParser

by StÃ©phane Ducasse

for smalltalkhub I think that everyproject will have an inbox so that people can deal the way thye want with incoming code. On Aug 11, 2011, at 4:10 PM, Lukas Renggli wrote: >> In any case, the current code should be reverted. While you play with another implementation, could you move the current versions from the PetitParser repository? > > I will remove it. I assume that the Helvetia image doesn't work > anymore, because it always uses the latest version. Maybe changes > (other than simple fixes) should be posted somewhere else to give some > time for discussion before an eventual merge. > > Lukas > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 11, 2011

Re: [Pharo-project] omit support in PetitParser

by Lukas Renggli

> In any case, the current code should be reverted. While you play with another implementation, could you move the current versions from the PetitParser repository? I will remove it. I assume that the Helvetia image doesn't work anymore, because it always uses the latest version. Maybe changes (other than simple fixes) should be posted somewhere else to give some time for discussion before an eventual merge. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 11, 2011

Re: [Pharo-project] Zinc: urls without scheme

by Sven Van Caekenberghe

On 11 Aug 2011, at 14:52, Igor Stasenko wrote: > Yes, of course we could just fix url and that's it. > But my question was more general (because i knew why and where it fails ;) OK ;-) > But ok.. If you think we should always explicitly use scheme, > in that case, i think it should produce errors earlier, i.e. > if it cannot detect any scheme, it should raise a malformed url error. > Because as you can see in > > ScriptLoader new installingInstaller > > it throws error at random place, when MC trying to connect using URL. > I'd prefer that URL throw an error, so we could see 1-2 stack frames > below the caller who passing wrong url, > but not like today, it buried under a lot of unrelated stuff from MC. Well, I did some commits (with more tests) adding support so that ZnUrl fromString: 'www.squeaksource.com/installer' defaultScheme: #http becomes equivalent to ZnUrl fromString: 'http://www.squeaksource.com/installer' although I think the second is better (and it is what #asZnUrl currently wants). I did not (yet) change the current behavior of #asZnUrl to either always use #http as default scheme or throw an exception for a missing scheme, because I still think that it can be useful to have neither of these two behaviors, see for example ZnUrlTests>>#testParsePathOnly and ZnUrlTests>>#testRelative. But maybe we'll come across more arguments in the future. Sven > On 11 August 2011 14:24, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> Hi Igor, >> >> On 05 Aug 2011, at 11:07, Igor Stasenko wrote: >> >>> The problem is in: >>> >>> ScriptLoader new installingInstaller. >>> >>> without default scheme this thing is broken, since it using url >>> without scheme. :( >>> >>> Of course i could use gofer for loading it.. but i found this is most >>> easy way to load installer. >> >> I studied this a bit, but the base problem is the specification of the MC location. If you replace: >> >> mc := Smalltalk globals >> at: #MCHttpRepository >> fPresent: [ :repoClass | repoClass location: 'www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ]. >> >> with >> >> mc := Smalltalk globals >> at: #MCHttpRepository >> ifPresent: [ :repoClass | repoClass location: 'http://www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ]. >> >> in ScriptLoader>>#installingInstaller, >> >> it should work. Note that all MCHttpRepository are created like this, the template specifies it as well: >> >> MCHttpRepository >> location: 'http://www.squeaksource.com/' >> user: '' >> password: '' >> >> I could make this into a patch/slice if you want. >> >> Concering ZnUrl parsing, I am not sure that something has to change. ZnUrl is based on WAUrl that behaves the same. I just checked java.net.URL and they even throw an exception when you don't specify a scheme ;-) (because of the ambiguity). >> >> Consider also relative URLs: for example, in the context of http://www.example.com:8080/examples/index.html, the relative URL about.html should be resolvable/composable to http://www.example.com:8080/examples/about.html. The current ZnUrl implementation sees about.html (but also foo.com) as a path, which is OK in this absolute/relative idea. The older Url class turns about.html into a host specification instead, which would be wrong from this prespective. >> >> On the other hand, most browsers (and curl for example), will consider a string like 'foo' to mean a host as in http://foo >> >> With the scheme prefix 'http://' you actually indicate what you want, maybe some extra API can support this default behavior programmatically, I am still thinking about this. >> >> Regards, >> >> Sven >> >> >> >> > > >

Aug. 11, 2011

Re: [Pharo-project] omit support in PetitParser

by Tudor Girba

Hi Camillo, A first-class omit would be better especially given that you could package it as an extension. In any case, the current code should be reverted. While you play with another implementation, could you move the current versions from the PetitParser repository? Cheers, Doru On 11 Aug 2011, at 15:14, Camillo Bruni wrote: > Thanks for the vast answers and pointing out critical parts of the implementation. > > On 2011-08-11, at 08:14, Tudor Girba wrote: >> 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. > > Yeah and that's exactly the reason why I think this is useful. Since we want to use PetitParser also for small "dirty" projects where portability is a secondary problem. And I still disagree that it becomes less useful, it is just a way of filtering your output from parser in a very simple way ;). Furthermore having the omit doesn't mean that you will have to use it. t mean there is also the #flatten message which goes somewhat into the same direction IMO, since it is there for modifying directly in the parser the data. It could be omitted as well and put into 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. > > Indeed the implementation is not very nice, and more of a preliminary hack to see if it works, I will definitely do a second pass with lukas' suggestion for a first-class object to denote the omit property. > >> 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. > > it shouldn't be about the behavior of the grammes, I might have not done everything correctly in my implementation, but the way the parsing rules are evaluation is not changed, its should be only affecting the output of the parsers (in this sense a special PPActionParser). > >>> 2. For the same reason grammar transformation becomes impossible, one >>> of the design goals of PetitParser. > > sure, but having the feature doesn't mean you have to use it. And in my case it would simply some of the parsers I use. > Actually in the end the Omit is nothing but a special PPActionParser right? (Just a curious question, how do you handle grammar transformation in this case?) > >>> 3. #omit makes a typical grammar (the smalltalk one) roughly 15% >>> slower without even using the new feature. > > yep thats an implementation issue, as you mentioned addressing this with a first-class object won't affect existing grammars at all. > >>> 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). > > right, thats indeed an ugly property of my hack (=> first class objects will do) > >>> 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). > > ok, that was a bit hasty > >>> 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: > > Of course in my example this is straight forward, but in a bit more complex parser with a couple of options or intermediate tokens you don't want it would be nicer to directly specify it on the parser nodes. And in such a sense only affect how flatten works... > >>> 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 ] > > > Ah cool, this is indeed a bit nicer, didn't have at the new branch yetâ¦ will do ;) > > -- www.tudorgirba.com "Some battles are better lost than fought."

Aug. 11, 2011

Re: [Pharo-project] omit support in PetitParser

by Camillo Bruni

Thanks for the vast answers and pointing out critical parts of the implementation. On 2011-08-11, at 08:14, Tudor Girba wrote: > 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. Yeah and that's exactly the reason why I think this is useful. Since we want to use PetitParser also for small "dirty" projects where portability is a secondary problem. And I still disagree that it becomes less useful, it is just a way of filtering your output from parser in a very simple way ;). Furthermore having the omit doesn't mean that you will have to use it. t mean there is also the #flatten message which goes somewhat into the same direction IMO, since it is there for modifying directly in the parser the data. It could be omitted as well and put into 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. Indeed the implementation is not very nice, and more of a preliminary hack to see if it works, I will definitely do a second pass with lukas' suggestion for a first-class object to denote the omit property. > 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. it shouldn't be about the behavior of the grammes, I might have not done everything correctly in my implementation, but the way the parsing rules are evaluation is not changed, its should be only affecting the output of the parsers (in this sense a special PPActionParser). >> 2. For the same reason grammar transformation becomes impossible, one >> of the design goals of PetitParser. sure, but having the feature doesn't mean you have to use it. And in my case it would simply some of the parsers I use. Actually in the end the Omit is nothing but a special PPActionParser right? (Just a curious question, how do you handle grammar transformation in this case?) >> 3. #omit makes a typical grammar (the smalltalk one) roughly 15% >> slower without even using the new feature. yep thats an implementation issue, as you mentioned addressing this with a first-class object won't affect existing grammars at all. >> 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). right, thats indeed an ugly property of my hack (=> first class objects will do) >> 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). ok, that was a bit hasty >> 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: Of course in my example this is straight forward, but in a bit more complex parser with a couple of options or intermediate tokens you don't want it would be nicer to directly specify it on the parser nodes. And in such a sense only affect how flatten works... >> 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 ] Ah cool, this is indeed a bit nicer, didn't have at the new branch yetâ¦ will do ;)

Aug. 11, 2011

Re: [Pharo-project] Zinc: urls without scheme

by Igor Stasenko

Yes, of course we could just fix url and that's it. But my question was more general (because i knew why and where it fails ;) But ok.. If you think we should always explicitly use scheme, in that case, i think it should produce errors earlier, i.e. if it cannot detect any scheme, it should raise a malformed url error. Because as you can see in ScriptLoader new installingInstaller it throws error at random place, when MC trying to connect using URL. I'd prefer that URL throw an error, so we could see 1-2 stack frames below the caller who passing wrong url, but not like today, it buried under a lot of unrelated stuff from MC. On 11 August 2011 14:24, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi Igor, > > On 05 Aug 2011, at 11:07, Igor Stasenko wrote: > >> The problem is in: >> >> ScriptLoader new installingInstaller. >> >> without default scheme this thing is broken, since it using url >> without scheme. :( >> >> Of course i could use gofer for loading it.. but i found this is most >> easy way to load installer. > > I studied this a bit, but the base problem is the specification of the MC location. If you replace: > > mc := Smalltalk globals > Â Â Â Â at: #MCHttpRepository > Â Â Â Â fPresent: [ :repoClass | repoClass location: 'www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ]. > > with > > mc := Smalltalk globals > Â Â Â Â at: #MCHttpRepository > Â Â Â Â ifPresent: [ :repoClass | repoClass location: 'http://www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ]. > > in ScriptLoader>>#installingInstaller, > > it should work. Note that all MCHttpRepository are created like this, the template specifies it as well: > > MCHttpRepository > Â Â Â Â location: 'http://www.squeaksource.com/' > Â Â Â Â user: '' > Â Â Â Â password: '' > > I could make this into a patch/slice if you want. > > Concering ZnUrl parsing, I am not sure that something has to change. ZnUrl is based on WAUrl that behaves the same. I just checked java.net.URL and they even throw an exception when you don't specify a scheme ;-) (because of the ambiguity). > > Consider also relative URLs: for example, in the context of http://www.example.com:8080/examples/index.html, the relative URL about.html should be resolvable/composable to http://www.example.com:8080/examples/about.html. The current ZnUrl implementation sees about.html (but also foo.com) as a path, which is OK in this absolute/relative idea. The older Url class turns about.html into a host specification instead, which would be wrong from this prespective. > > On the other hand, most browsers (and curl for example), will consider a string like 'foo' to mean a host as in http://foo > > With the scheme prefix 'http://' you actually indicate what you want, maybe some extra API can support this default behavior programmatically, I am still thinking about this. > > Regards, > > Sven > > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 11, 2011

Re: [Pharo-project] Zinc: urls without scheme

by Sven Van Caekenberghe

Hi Igor, On 05 Aug 2011, at 11:07, Igor Stasenko wrote: > The problem is in: > > ScriptLoader new installingInstaller. > > without default scheme this thing is broken, since it using url > without scheme. :( > > Of course i could use gofer for loading it.. but i found this is most > easy way to load installer. I studied this a bit, but the base problem is the specification of the MC location. If you replace: mc := Smalltalk globals at: #MCHttpRepository fPresent: [ :repoClass | repoClass location: 'www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ]. with mc := Smalltalk globals at: #MCHttpRepository ifPresent: [ :repoClass | repoClass location: 'http://www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ]. in ScriptLoader>>#installingInstaller, it should work. Note that all MCHttpRepository are created like this, the template specifies it as well: MCHttpRepository location: 'http://www.squeaksource.com/' user: '' password: '' I could make this into a patch/slice if you want. Concering ZnUrl parsing, I am not sure that something has to change. ZnUrl is based on WAUrl that behaves the same. I just checked java.net.URL and they even throw an exception when you don't specify a scheme ;-) (because of the ambiguity). Consider also relative URLs: for example, in the context of http://www.example.com:8080/examples/index.html, the relative URL about.html should be resolvable/composable to http://www.example.com:8080/examples/about.html. The current ZnUrl implementation sees about.html (but also foo.com) as a path, which is OK in this absolute/relative idea. The older Url class turns about.html into a host specification instead, which would be wrong from this prespective. On the other hand, most browsers (and curl for example), will consider a string like 'foo' to mean a host as in http://foo With the scheme prefix 'http://' you actually indicate what you want, maybe some extra API can support this default behavior programmatically, I am still thinking about this. Regards, Sven

Aug. 11, 2011

Re: [Pharo-project] Pharo Kernel OSProcess evaluator

by Pavel Krivanek

On Thu, Aug 11, 2011 at 1:06 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Thu, Aug 11, 2011 at 12:23:51PM +0200, Pavel Krivanek wrote: >> 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 > > Cool :)) > > Here is another read-eval interpreter that you may want to look at > just for fun: > > Â http://wiki.squeak.org/squeak/6023 > > I think your simple interpreter is better for what what you are doing > here, but it's interesting to experiment with Squeak/Pharo as a /bin/sh > replacement too. > > Dave Hi Dave, I know about it and I looked at it to see if it could be used for Pharo Kernel. Currently it has many Morphic dependencies and it was easier to write the simple evaluator loop ;-) -- 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] Pharo Kernel OSProcess evaluator

by David T. Lewis

On Thu, Aug 11, 2011 at 12:23:51PM +0200, Pavel Krivanek wrote: > 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 Cool :)) Here is another read-eval interpreter that you may want to look at just for fun: http://wiki.squeak.org/squeak/6023 I think your simple interpreter is better for what what you are doing here, but it's interesting to experiment with Squeak/Pharo as a /bin/sh replacement too. Dave > > > 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

[Pharo-project] Explicitly avoiding process switch

by Mariano Martinez Peck

Hi guys. We were discussing yesterday with Marcus about the following.... I remember a problem we have in Pharo because of changing "foo == nil" to "foo isNil" in some important places like Process/Delay/Semaphore. Such change introduces a suspension point, where if I understand correctly, the scheduler can switch to another process only during method sends. #== is optimized with a special bytecode and there is no message send. Sending #isNil is a message sent, and hence we introduce a suspension point. In 99% of the cases this is not a problem. But I can imagine that there are places (mostly those related to Process/Delay/Semaphore) where this changes can be very very bad. To do some experiments, I want to remove the bytecode for #== but of course, I think I will have all these problems. And there are more. Marcus told me that some optimizations done by the compiler end up sending #==. And I also remember some code he told me (I think it was #allObjectsDo:) that would never finish because of the block closure objects creation. So...what about making the necessity of NOT sending a message or NOT introducing a suspension point more explicit? first we should have the support for that and second know each place where we need them. The most basic thing I can think of is doing something like: (ParseNode classVarNamed: 'StdSelectors') at: #== put: #bytecodedEqualEqual. Compiler recompileAll. And put a nice comment why one may want to use #optimizedEqualEqual. But again, in which places should I change #== for #bytecodedEqualEqual Any thought or idea about them is really appreciated. Thanks -- Mariano http://marianopeck.wordpress.com

Aug. 11, 2011