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

Re: [Pharo-project] [Moose-dev] Re: removing versions from configurations

by Tudor Girba

Hi Stef, On 26 Apr 2011, at 09:42, StÃ©phane Ducasse wrote: > > On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote: > >> Hi Stef, >> >> On 25 Apr 2011, at 18:50, StÃ©phane Ducasse wrote: >> >>> Indeed but loading default could have destroyed your image. >>> So RPackage should not be managed with default. >> >> I do not understand. The continuous integration server is there to check these issues. > > the proof is that it did not work. > >> The correspondent would be to load now the current baseline. If that breaks, it breaks and people look at it. >> >> Moose is now developed on multiple fronts and serves multiple interests that are not necessarily synchronized. So, we want to depend on latest things because this ensures communication and puts more pressure on synchronizing issues. This is why we want to play with the latest Pharo (hopefully, we will the development to it next week). >> >> Every time we depend on something fixed, we introduce the difficulty of migrating to the next version. > > yes but this is the price to pay if you want a really robust package system. > I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system > where I can lose half of my work. Sure. Just do not work with the baseline then. Although I am sure that when you are developing RPackage, you do want to load the very latest versions of packages :) >>> Now for stable I'm not sure that I set it up well so watch out. >> >> The tests say that for the use of Moose, RPackage works Ok. > > The problem is that the scenario of Moose is just to create Moose model and RPackage is much more than that. > We found conceptual problem with announcement dependencies with benjamin and fix that. > Then for example, Rpackage was not in sync with > - the announcement changes because it was violating encapsulation (law of demeter bad practice) > In addition there are multiple things that now I have to carefully check. Because MC is not nice and we are replicating > this aspects and making rpackage brittle because MC is brittle. I understood that. I was just saying that for Moose it looks like it is working. However, we do not test to see what happens if something is loaded in the image after RPackage was installed, so this is why we are probably missing the issue :(. > So sorry but I need to control the version I work with and there is no way I will work on RPackage with default > (and yes this is a pain for me too to have to change all the time the configuration but this is the only way). I do not understand your line of reasoning. You do not have to work with default to provide a default. If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. You did not remove the other baseline, but you removed default. In any case, my message came from the point of view of someone who integrates and it is not related to default. I understand your needs but I wanted to point out the dangers that come with removing a version. Cheers, Doru > > Stef > > >> >> Cheers, >> Doru >> >> >> >>> Stef >>> >>> On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage. >>>> >>>> I fixed it now by using #stable, but that is not the issue. >>>> >>>> I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "From an abstract enough point of view, any two things are similar." >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Don't give to get. Just give." >> >> >> >> >> >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not how it is, it is how we see it."

April 26, 2011

Re: [Pharo-project] Suggestions: move examples from UIThemes class to ExampleBuilderMorph class

by StÃ©phane Ducasse

edmund enter bug entries else your suggestions will be lost. Stef On Apr 25, 2011, at 8:56 PM, DougEdmunds wrote: > A couple of suggestions > > Part 1. > Move the methods in the UIThemes class, protocol 'examples' to > ExampleBuilderMorph class, protocol 'examples'. > > Rationale: Every one of these examples first creates an instance of > ExampleBuilderMorph > as the base class that the example is built on. These examples do not > demonstrate > anything about how to use UITheme. > > I made a file that duplicates the methods from UITheme class -examples- to > ExampleBuilderMorph class -examples-, suitable for filein. Methods such as > ExampleBuilderMorph class >>exampleBasicControls work fine, > indicating they have no dependence on UITheme. > The file's 347 lines, so I'm not posting it here, unless requested. > > Part 2. > Then move ExampleBuilderMorph and ExampleRadioButtonModel from > Polymorph-Widgets > into a new package called Polymorph-Widgets-Examples. > > Rationale: This would be reduce the size of Polymorph-Widgets, and make it > more > obvious that there are some examples of the widgets to look at. > UITheme class is not the place where one expects to find examples of > buttons, > checkboxes, etc. Also this would be consistent with other Morphic packages. > (Morphic-MorphTreeWidget and Morphic-MorphTreeWidget-Examples) > > --- > > > > > > -- > View this message in context: http://forum.world.st/Suggestions-move-examples-from-UIThemes-class-to-Exam… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 26, 2011

Re: [Pharo-project] removing versions from configurations

by StÃ©phane Ducasse

On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote: > Hi Stef, > > On 25 Apr 2011, at 18:50, StÃ©phane Ducasse wrote: > >> Indeed but loading default could have destroyed your image. >> So RPackage should not be managed with default. > > I do not understand. The continuous integration server is there to check these issues. the proof is that it did not work. > The correspondent would be to load now the current baseline. If that breaks, it breaks and people look at it. > > Moose is now developed on multiple fronts and serves multiple interests that are not necessarily synchronized. So, we want to depend on latest things because this ensures communication and puts more pressure on synchronizing issues. This is why we want to play with the latest Pharo (hopefully, we will the development to it next week). > > Every time we depend on something fixed, we introduce the difficulty of migrating to the next version. yes but this is the price to pay if you want a really robust package system. I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system where I can lose half of my work. >> Now for stable I'm not sure that I set it up well so watch out. > > The tests say that for the use of Moose, RPackage works Ok. The problem is that the scenario of Moose is just to create Moose model and RPackage is much more than that. We found conceptual problem with announcement dependencies with benjamin and fix that. Then for example, Rpackage was not in sync with - the announcement changes because it was violating encapsulation (law of demeter bad practice) In addition there are multiple things that now I have to carefully check. Because MC is not nice and we are replicating this aspects and making rpackage brittle because MC is brittle. So sorry but I need to control the version I work with and there is no way I will work on RPackage with default (and yes this is a pain for me too to have to change all the time the configuration but this is the only way). Stef > > Cheers, > Doru > > > >> Stef >> >> On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage. >>> >>> I fixed it now by using #stable, but that is not the issue. >>> >>> I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "From an abstract enough point of view, any two things are similar." >>> >> >> > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > >

April 26, 2011

Re: [Pharo-project] Fix proposed to make alt+t open a transcript in PharoCore 1.3

by Marcus Denker

On Apr 25, 2011, at 3:55 PM, Damien Cassou wrote: > http://code.google.com/p/pharo/issues/detail?id=4093 > We should role back to the old transcript... all of the many problems with transcript will then be fixed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 26, 2011

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 25, 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 25, 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