- Pharo-dev - lists.pharo.org

Re: [Pharo-project] petit parser help

by Lukas Renggli

> I only played a little with PetitParser but I think the answer is in > PetitXml>>#element. You see in the action block that it compares the > "qualified" of the open and close tags and if they're different it returns a > PPFailure. It also takes care of the inlineTag in the same block by asking > if the fifth node is '/>'. This "taking care of the inlineTag" is just an ugly optimization, but it makes the parser extremely fast :-) Ideally you start with a grammar as you propose and add then check if open and close tag are the same in the callback, as in the example above. Another subtlety that you see in the above example that is the parser: [ :stream | stream position ] asParser This object returns the position in the stream and makes it possible to create the failure at the beginning of the close tag. Again, this is not required to start with. You can create the failure object like below, it just will not point you to the right place in the input then: PPFailure message: 'tags not matching' at: 0 Lukas -- Lukas Renggli www.lukas-renggli.ch

April 26, 2011

Re: [Pharo-project] petit parser help

by Ricardo Moran

I only played a little with PetitParser but I think the answer is in PetitXml>>#element. You see in the action block that it compares the "qualified" of the open and close tags and if they're different it returns a PPFailure. It also takes care of the inlineTag in the same block by asking if the fifth node is '/>'. element "[39] element ::= EmptyElemTag | STag content ETag" ^ $< asParser , qualified , attributes , whitespace optional , ('/>' asParser / ($> asParser , content , [ :stream | stream position ] asParser , '</' asParser , qualified , whitespace optional , $> asParser)) ==> [ :nodes | *nodes fifth = '/>'* ifTrue: [ Array with: nodes second with: nodes third with: #() ] ifFalse: [ *nodes second = nodes fifth fifth* ifTrue: [ Array with: nodes second with: nodes third with: nodes fifth second ] ifFalse: [ PPFailure message: 'Expected </' , nodes second qualifiedName , '>' at: nodes fifth third ] ] ] I hope this helps. Cheers, Richo On Mon, Apr 25, 2011 at 6:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi Lukas, all > I'm finally working on a HTML petit parser (a very basic one, based on XML > petit parser) and I have a serious problem (well... besides my complete > ignorance about petit parser, he...) > I need to match this pattern: > > openTag, contents, closeTag (that will be something like "<html> ... > </html>") > inlineTag (that will be something > like "<br/>") > openTag (that will be something > like "<link ...>" or "<img src='anUrl'>") > > so, after try some variants... I came with this construct: > > element > "[39] element ::= EmptyElemTag | STag content > ETag" > > ^(self inlineTag / (self openTag, content, self closeTag) / self > openTag) > ==> [ :nodes | ]. > > openTag > ^ $< asParser, qualified, whitespace optional, attributes, > whitespace optional, $> asParser > > inlineTag > ^ $< asParser, qualified, whitespace optional, attributes, > whitespace optional, '/>' asParser > > closeTag > ^'</' asParser , qualified , whitespace optional , $> asParser > > > so... the problem here is that the statement > > self openTag, contents, self closeTag > > matchs with > > ... > <link ...> > </html> > > and for that reason, the resulting tree is invalid. > > So, I need a way to ensure the openTag name is equal to the closeTag name. > > How can I do that? > > Cheers, > Esteban >

April 26, 2011

Re: [Pharo-project] Pharo 1.2.1 to Pharo 1.2.2

by Miguel CobÃ¡

El lun, 25-04-2011 a las 11:00 -0500, Miguel CobÃ¡ escribiÃ³: > How will this upgrade path will be handled? > > In some email of previous week this is mentioned: > > SystemVersion newVersion: 'Pharo1.2.2a'. I meant: SystemVersion newVersion: 'Pharo1.2.1a'. > > But evaluated in a Pharo 1.2.1 update 12345 starts updating from 12342 > and stops on 12345, so I think that is wrong. > > Evaluating > > SystemVersion newVersion: 'Pharo1.2.2a' > > begin the update from 12346 and stops on 12350 so I think that is the > correct one, right? > > Or should users begin with: > > https://gforge.inria.fr/frs/download.php/28436/PharoCore-1.2.2a-12345.zip > > and update from there? (This implies migrate to a new image, not so much > a update from 1.2.1 to 1.2.2 but a migration). > > Thanks in advance. > > Anyone? -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 26, 2011

Re: [Pharo-project] What is a well documented class?

by csrabak＠bol.com.br

What would be a "casual user" of a class in Smalltalk? -- Cesar Rabak Em 25/04/2011 18:19, Alexandre Bergel < alexandre.bergel(a)me.com > escreveu: Ok, focusing on the instance variables. I think there is two kind of documentation, one for the casual user, and another for the developers. Alexandre On 25 Apr 2011, at 16:09, DougEdmunds wrote: > 2cents about "what is a well-documented class?": > > Information about the state variables (instance variables): what goes in the > slot, and what it's for. > > Good examples (the layout gets skewed doing copy/paste) > > in RxsPredicate > > Instance Variables: > > predicate A one-argument block. If it evaluates to the value > defined by > when it is passed a character, the predicate is considered to > match. > > negation A one-argument block that is a negation of > . > > > SMxMorph > > Structure: > instance var Type Description > bounds Rectangle A Rectangle indicating my position and a size that will > enclose me. > > owner SMxMorph My parent SMxMorph, or nil for the top-level SMxMorph, > which is a > or nil world, typically a SMxPasteUpMorph. > > submorphs Array My child Morphs. > > fullBounds Rectangle A Rectangle minimally enclosing me and my > submorphs. > > color Color My primary color. Subclasses can use this in different > ways. > > extension SMxMorphExtension Allows extra properties to be stored without > adding a > or nil storage burden to all morphs. > > > -- > View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3474024.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

Re: [Pharo-project] petit parser help

by Casey Ransberger

I played with PEGs awhile ago. Recommend reading the wikipedia article. You can use a couple of lookahead type tricks, pay attention to the bit about "syntactic predicates." I can't remember what the exact phrasing is in PetitParser, but there should be an "and" predicate and a "not" predicate that can effectively give you look ahead because they don't consume any input... Or something like that. After grokking the whole predicates bit, you will probably look at PetitParser again and it'll just make sense. That's how it went for me anyhow, though it's already rather jumbled because it was about a week of my life a year ago;) On Apr 25, 2011, at 2:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Lukas, all > I'm finally working on a HTML petit parser (a very basic one, based on XML petit parser) and I have a serious problem (well... besides my complete ignorance about petit parser, he...) > I need to match this pattern: > > openTag, contents, closeTag (that will be something like "<html> ... </html>") > inlineTag (that will be something like "<br/>") > openTag (that will be something like "<link ...>" or "<img src='anUrl'>") > > so, after try some variants... I came with this construct: > > element > "[39] element ::= EmptyElemTag | STag content ETag" > > ^(self inlineTag / (self openTag, content, self closeTag) / self openTag) > ==> [ :nodes | ]. > > openTag > ^ $< asParser, qualified, whitespace optional, attributes, whitespace optional, $> asParser > > inlineTag > ^ $< asParser, qualified, whitespace optional, attributes, whitespace optional, '/>' asParser > > closeTag > ^'</' asParser , qualified , whitespace optional , $> asParser > > > so... the problem here is that the statement > > self openTag, contents, self closeTag > > matchs with > > ... > <link ...> > </html> > > and for that reason, the resulting tree is invalid. > > So, I need a way to ensure the openTag name is equal to the closeTag name. > > How can I do that? > > Cheers, > Esteban

April 26, 2011

[Pharo-project] petit parser help

by Esteban Lorenzano

Hi Lukas, all I'm finally working on a HTML petit parser (a very basic one, based on XML petit parser) and I have a serious problem (well... besides my complete ignorance about petit parser, he...) I need to match this pattern: openTag, contents, closeTag (that will be something like "<html> ... </html>") inlineTag (that will be something like "<br/>") openTag (that will be something like "<link ...>" or "<img src='anUrl'>") so, after try some variants... I came with this construct: element "[39] element ::= EmptyElemTag | STag content ETag" ^(self inlineTag / (self openTag, content, self closeTag) / self openTag) ==> [ :nodes | ]. openTag ^ $< asParser, qualified, whitespace optional, attributes, whitespace optional, $> asParser inlineTag ^ $< asParser, qualified, whitespace optional, attributes, whitespace optional, '/>' asParser closeTag ^'</' asParser , qualified , whitespace optional , $> asParser so... the problem here is that the statement self openTag, contents, self closeTag matchs with ... <link ...> </html> and for that reason, the resulting tree is invalid. So, I need a way to ensure the openTag name is equal to the closeTag name. How can I do that? Cheers, Esteban

April 25, 2011

Re: [Pharo-project] Better debugging...

by Camillo Bruni

I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics. The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: - interception of message sends - per thread [ok] - of specific classes [missing] - of specific instances [missing] - interception of instance variable access, read/write - per thread [missing] - of specific classes [missing] - of specific instances [missing] - of specific instance variables [missing] Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf

April 25, 2011

Re: [Pharo-project] What is a well documented class?

by Alexandre Bergel

Ok, focusing on the instance variables. I think there is two kind of documentation, one for the casual user, and another for the developers. Alexandre On 25 Apr 2011, at 16:09, DougEdmunds wrote: > 2cents about "what is a well-documented class?": > > Information about the state variables (instance variables): what goes in the > slot, and what it's for. > > Good examples (the layout gets skewed doing copy/paste) > > in RxsPredicate > > Instance Variables: > > predicate <BlockClosure> A one-argument block. If it evaluates to the value > defined by > <negated> when it is passed a character, the predicate is considered to > match. > > negation <BlockClosure> A one-argument block that is a negation of > <predicate>. > > > SMxMorph > > Structure: > instance var Type Description > bounds Rectangle A Rectangle indicating my position and a size that will > enclose me. > > owner SMxMorph My parent SMxMorph, or nil for the top-level SMxMorph, > which is a > or nil world, typically a SMxPasteUpMorph. > > submorphs Array My child Morphs. > > fullBounds Rectangle A Rectangle minimally enclosing me and my > submorphs. > > color Color My primary color. Subclasses can use this in different > ways. > > extension SMxMorphExtension Allows extra properties to be stored without > adding a > or nil storage burden to all morphs. > > > -- > View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3474024.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011

Re: [Pharo-project] Error with latest ProfStef in Pharo 1.3

by Alexandre Bergel

Ok, tomorrow at 13:20 - 13:30 (GMT+1) on skype Alexandre On 25 Apr 2011, at 15:26, laurent laffont wrote: > > On Mon, Apr 25, 2011 at 8:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > May be I can check this with my local developer group on Tuesday (we meet from 12:30 -> 13h30. If you wake up early :) > > 13:30 in france is 8:30 in Chile. I usually arrive at 8:20 at work. So, we meet on tomorrow? > Using IRC? > > No problem. We can use skype. > > Laurent. > > > > Cheers, > Alexandre > > > Laurent > > > > We could then write new tests, make sure ProfStef works for Pharo 1.3 and fix the bug found by Mariano. > > > > Cheers, > > Alexandre > > > > > > On 24 Apr 2011, at 12:33, laurent laffont wrote: > > > > > > > > On Sun, Apr 24, 2011 at 6:43 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > ah ah! This is what we have changed during the pharo cast. > > > Laurent, do you want that we have a look at it together? > > > > > > haha I won't be able to look at it until Tuesday. > > > > > > Laurent. > > > > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 24 Apr 2011, at 11:30, Mariano Martinez Peck wrote: > > > > > > > "Error 'Please use buildTutorialTopicFor: instead'" > > > > > > > > when I try to open it from the menu. > > > > > > > > ProfStefHelpTutorialBuilder >> buildHelpTopicFrom: aHelpTopicDescription > > > > "Start building from the given help topic description" > > > > > > > > ^(self new) > > > > rootToBuildFrom: aHelpTopicDescription; > > > > build; > > > > topicToBuild > > > > > > > > the rpoblem is that #new > > > > > > > > I am using last versions of Pharo1.3 > > > > > > > > -- > > > > Mariano > > > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011

Re: [Pharo-project] What is a well documented class?

by Alexandre Bergel

> The tool is a text editor ;-) Woooaaa... That can't be :-) please check the email I just sent. Alexandre > > If we agree on my suggestions, we can compose a set of guidelines to arrive at deliverables that comply with them. > > One tool could be a template and a checklist to help the writer of the documentation. > > -- > Cesar Rabak > > Em 25/04/2011 14:59, Alexandre Bergel < alexandre.bergel(a)me.com > escreveu: > Ok, but what would be a tool that help you write comment? This cannot be the system browser. > > Alexandre > > > On 25 Apr 2011, at 12:37, csrabak(a)bol.com.br wrote: > >> I think a well documented class is a class which can be understood by reading its documentation without having to resort to anything else, be it running the test only to see something not obvious, reading the code to understand the working which the document fell short; and without having to assemble a mini encyclopedia of references in order to grasp the contents of the documentation. >> >> my 0.019999 >> >> -- >> Cesar Rabak >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2011