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

Re: [Pharo-project] Bug in parsing numbers in PPSmalltalkGrammar?

by StÃ©phane Ducasse

frank just to be clear, we do not like the GNU syntax for Coral, else we would have done it before. See my reply to your question in the coral mailing-lits I think that Eval [] Class [] Import [] but I do not want nested definition nor class extension or class definition as in GNU. So if you want a GNU syntax then make sure that it is optional and that we can get coral without it. Stef On Aug 11, 2011, at 10:48 PM, Frank Shearar wrote: > I'm extending Coral to support Gnu Smalltalk syntax, and ran into > something strange. > > I asked Lukas and he said that since others would be interested, I > should repost the question here. So: > > Gnu Smalltalk's class variable declarations take the form of > [<identifier> := <expression>.]* at the end of an object definition. > To that end I wrote a #classVars production like so: > > classVars > ^ (assignment , expression , $. asParser) star > "Possibly I need to support the lack of a dot on the last > expression. Not relevant at the moment" > > This didn't work as expected. Looking further, I found this oddity: > > p := PPSmalltalkParser new. > p number end parse: '1.' "=> #(#(nil #($1) nil) 1.0)" > > I would expect this to fail, because "1." isn't a number (but see below). > > Indeed, ripping out the parser of #number: > > n := ($- asParser optional , #digit asParser plus , ($. asParser , > #digit asParser plus) optional) end. > n parse: '1.' "=> end of input expected at 1" > > So I experimented a bit, and it seems like#number is being overly > eager in consuming that $. character, and Number >> #readFrom:'s > reading '1.': > > Number readFrom: '1.' readStream "=> 1.0" > > p := PPSmalltalkParser new. > p number end parse: '1' "=> #(#(nil #($1) nil) 1)" > > p := PPSmalltalkParser new. > p number end parse: '1.0' "=> #(#(nil #($1) #($. #($0))) 1.0)" > > p := PPSmalltalkParser new. > p number end parse: '1. ' "=> end of input expected at 2" > > Or am I being silly? > > frank >

Aug. 11, 2011

[Pharo-project] Bug in parsing numbers in PPSmalltalkGrammar?

by Frank Shearar

I'm extending Coral to support Gnu Smalltalk syntax, and ran into something strange. I asked Lukas and he said that since others would be interested, I should repost the question here. So: Gnu Smalltalk's class variable declarations take the form of [<identifier> := <expression>.]* at the end of an object definition. To that end I wrote a #classVars production like so: Â classVars Â Â Â ^ (assignment , expression , $. asParser) star Â Â Â "Possibly I need to support the lack of a dot on the last expression. Not relevant at the moment" This didn't work as expected. Looking further, I found this oddity: Â p := PPSmalltalkParser new. Â p number end parse: '1.' "=> #(#(nil #($1) nil) 1.0)" I would expect this to fail, because "1." isn't a number (but see below). Indeed, ripping out the parser of #number: Â n := ($- asParser optional , #digit asParser plus , ($. asParser , #digit asParser plus) optional) end. Â n parse: '1.' "=> end of input expected at 1" So I experimented a bit, and it seems like#number is being overly eager in consuming that $. character, and Number >> #readFrom:'s reading '1.': Â Number readFrom: '1.' readStream "=> 1.0" Â p := PPSmalltalkParser new. Â p number end parse: '1' "=> #(#(nil #($1) nil) 1)" Â p := PPSmalltalkParser new. Â p number end parse: '1.0' "=> #(#(nil #($1) #($. #($0))) 1.0)" Â p := PPSmalltalkParser new. Â p number end parse: '1. ' "=> end of input expected at 2" Or am I being silly? frank

Aug. 11, 2011

[Pharo-project] 1.3 link downloads 1.4 image

by Max Leske

The "Pharo 1.3" link on the webpage (beneath "Pharo 1.3 image (unstable)") actually downloads the 1.4 image. So at the moment there is no way to get a 1.3 image from the webpage. Max

Aug. 11, 2011

[Pharo-project] startup errors

by Camillo Bruni

While working on Coral we encountered a rather annoying behavior of pharo images when starting up. We wanted to check if we can debug the CoralScriptLoader, but of corse since this happens at image startup time this is not a good ideaâ¦ HOWEVER we were no longer able to run the image as it immediately crashes during the startup. Now I wonder if it would make sense to add a couple of on:do: in SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup scripts and then only show them after all other startupListItems are processed. All in all the behavior would not much differ from what is going on right now, but would prevent stupid users like me from losing a whole image. camillo

Aug. 11, 2011

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

by Sven Van Caekenberghe

On 11 Aug 2011, at 17:01, Igor Stasenko wrote: > I don't understand how relative urls are ehmm related to this. > By definition, you cannot construct a relative url out of a single > argument, because it raising a question, relative to what? > So, the right way to construct relative url is to be: > > relativeUrl := 'about.html' asRelativeUrlTo: someBaseUrl. > > while: > > relativeUrl := 'about.html' asRelativeUrl > > makes no sense at all. > > That means, in own turn, that expression > 'xyz' asUrl > could only be used for producing absolute urls with all consequence > (such as picking default scheme etc). That is not how I see it (for now at least). The difference between absolute and relative URLs is a known concept: http://en.wikipedia.org/wiki/Url#Absolute_vs_relative_URLs My view is that some string is parsed into an URL, which results in a object that has the (derived) property of being absolute or relative. It is true that a relative URL can only make sense in the context of a absolute URL, but that does not means that we cannot talk about or deal with a relative URL as a proper URL. Some intelligent operation to merge an absolute and relative one must be added in the future (this is possible only in a limited way now). In a sense, it comes down to what 'foo' as[Zn]Url should mean: either it is the host foo (old Url, browser interpretation), or the path foo (ZnUrl interpretation). Your point about the resulting error in your particular case is valid, I will look into that. But I still think that if you want a string to represent a URL unambiguously, you better add the scheme (as I wrote earlier). Sven

Aug. 11, 2011

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

by Dale Henrichs

----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: "A friendly place where any question about pharo is welcome" <pharo-users(a)lists.gforge.inria.fr>, "Pharo | Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Wednesday, August 10, 2011 3:12:27 PM | Subject: Re: [Pharo-users] [Seaside] Seaside on Pharo-Kernel | | 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) Igor, If you want to do development in a Seaside image, check out tODE[1]. It's a Smalltalk development environment written in Seaside that has been ported to Pharo and GemStone ... code browsing, inspectors, debugger, metacello/monticello integration are all there. The current version of tODE is a proof of concept but it is a highly functional proof of concept. I've been doing about 80% of my development in tODE for the last couple of months ... the current version of tODE doesn't use RING, but I plan to use RING (and port it to GemStone) for the next version ... [1] http://code.google.com/p/tode/ Dale

Aug. 11, 2011

[Pharo-project] Next target for pharo

by Noury Bouraqadi

It's running Linux. Noury Begin forwarded message: > Date: 4 aoÃ»t 2011 06:00:16 HAEC > Subject: Raspberry Pi Interview With Eben Upton > Source: robots.net > > > > > > The robot revolution just got a little closer thanks to some of the cool devices that are coming down the pipe. One such cool device is called the Raspberry Pi. The Raspberry Pi device is basically a $25 Linux PC on a credit card sized board! This microcomputer looks perfectly suited as a low cost, micro form factor, low power, PC performance robot brain. If you think that's unbelievable, well, believe it! Sure it's not available just yet but already the Alpha Boards are being manufactured and they anticipate the devices will be available for sale later in 2011. > > I contacted the Director of the Raspberry Pi Foundation, Eben Upton, and he graciously answered some of my questions pertaining to his foundation, the Raspberry Pi device, and how the device relates to robotics. After the jump, read more about the Raspberry Pi device and read the interview by Director, Eben Upton. > Read moreâ¦ > Noury Bouraqadi http://car.mines-douai.fr/noury -- -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)

Aug. 11, 2011

Re: [Pharo-project] omit support in PetitParser

by Camillo Bruni

On 2011-08-11, at 15:26, Tudor Girba wrote: > 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? sure sure remove it :) > 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

[Pharo-project] PPElementParser & a small PetitTests contribution

by Damien Pollet

While we're at it, I committed a tiny change to the assertions in PPAbstractParserTest, so that assertions return the parse result. I needed it for cases where I don't want to compare to an expected result, but still make further assertions than just "yup, it parses". For Coral I also wrote a simple PPDelegateParser subclass that applies its inner parser to the stream first element. It's like: PPPredicateObjectParser>>matching: elementParser message: aString ^ self on: [ :each | elementParser matches: each ] message: aString BUT: it will return the parse result of its inner parser, rather than the accepted element as-is. I use it to parse the argument array in a Coral script, some arguments are expected to be integers or other parseable. It allows me to predefine a bunch of utility parsers for simple argument types, that return a ready-to-use object. If you want to see the code, it's PPElementParser in the Coral package http://www.squeaksource.com/Coral.html but mostly it looks like this: parseOn: aStream | result | aStream atEnd ifTrue: [ ^ PPFailure message: 'element expected' at: aStream position ]. result := parser "end" parse: aStream uncheckedPeek. ^ result isPetitFailure ifFalse: [ aStream next. result ] ifTrue: [ PPFailure message: (message ifNil: ['error: ' , result printString , ' in element']) at: aStream position ] What do you think? I'm still not sure what the best way is. I hesitated between subclassing PPDelegateParser, PPLiteralParserâ¦ maybe a factory method in PPPredicateObjectParser would work as well: -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 11, 2011

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

by Igor Stasenko

On 11 August 2011 15:42, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > 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. > I don't understand how relative urls are ehmm related to this. By definition, you cannot construct a relative url out of a single argument, because it raising a question, relative to what? So, the right way to construct relative url is to be: relativeUrl := 'about.html' asRelativeUrlTo: someBaseUrl. while: relativeUrl := 'about.html' asRelativeUrl makes no sense at all. That means, in own turn, that expression 'xyz' asUrl could only be used for producing absolute urls with all consequence (such as picking default scheme etc). > 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 >>> >>> >>> >>> >> >> >> > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 11, 2011