June 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50103 Home: https://github.com/pharo-project/pharo-core

June 10, 2015

important bug, needs review (15607 can not browse version containing non-ascii characters)

by Nicolai Hess

15607 <https://pharo.fogbugz.com/default.asp?15607> Trying to browse "versions" on a method which contains non-ascii characters causes SubscriptOutOfBounds error (not my bug, not my solution, but is important and needs a review) This is about ]lang[ tag in sources/changes file and reading nextChunks from a MultiByteFileStream

June 10, 2015

Pharo 4, format on accept/display

by Paul DeBruicker

Hi I've hacked together an implementation of format on accept & display. I know someone is redoing that functionality to better suit future needs. Should I publish what I've got as a slice to the Pharo40Inbox for people to use that may miss it now that do not want to wait for the new hotness? Thanks Paul

June 10, 2015

Re: [Pharo-dev] Comments in STON

by Sven Van Caekenberghe

> On 10 Jun 2015, at 15:13, stepharo <stepharo(a)free.fr> wrote: > > This is in the entreprise book. I added a subsection on comments. > May be I committed but forgot to push. > Now I did it. And now I see it. I made a small change. > Stef > > > Le 9/6/15 21:50, Sven Van Caekenberghe a Ã©crit : >> Where exactly can I find what you changed ? >> I don't see any commit of you on github ... >> >>> On 09 Jun 2015, at 20:10, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> >>> Le 9/6/15 20:06, stepharo a Ã©crit : >>>> I will update the STON chapter :) >>> Done :) >>> >>>> >>>> Le 8/6/15 23:39, Sven Van Caekenberghe a Ã©crit : >>>>> I would do it like this: use a wrapping stream to skip comments. >>>>> >>>>> === >>>>> Name: STON-Core-SvenVanCaekenberghe.59 >>>>> Author: SvenVanCaekenberghe >>>>> Time: 8 June 2015, 11:34:32.886167 pm >>>>> UUID: 7ab942b5-9d1a-44c3-9d58-da29feb72380 >>>>> Ancestors: STON-Core-SvenVanCaekenberghe.58 >>>>> >>>>> Add experimental STONCStyleCommentsSkipStream and tests >>>>> === >>>>> Name: STON-Tests-SvenVanCaekenberghe.54 >>>>> Author: SvenVanCaekenberghe >>>>> Time: 8 June 2015, 11:34:52.918771 pm >>>>> UUID: 3dcb2c9c-6efe-4d62-bf36-3bbe91f09d08 >>>>> Ancestors: STON-Tests-SvenVanCaekenberghe.53 >>>>> >>>>> Add experimental STONCStyleCommentsSkipStream and tests >>>>> === >>>>> >>>>> Then you can do as follows: >>>>> >>>>> STON fromStream: (STONCStyleCommentsSkipStream on: 'Point[/* this is X*/ 1, /* this is Y*/ 2] // Nice huh ?' readStream). >>>>> >>>>> => 1@2 >>>>> >>>>> STON fromStream: (STONCStyleCommentsSkipStream on: '// Here is how you create a point: >>>>> Point[ >>>>> // this is X >>>>> 1, >>>>> // this is Y >>>>> 2 ] >>>>> // Nice huh ?' readStream). >>>>> >>>>> => 1@2 >>>>> >>>>> This helper class would be useable in other contexts too (like NeoJSON). >>>>> >>>>> The advantage is that it does not change the STON (or JSON) syntax itself, it just add some functionality for those who want it. >>>>> >>>>> What do you think ? >>>>> >>>>> Sven >>>>> >>>>> PS: this probably needs some more testing >>>>> >>>>>> On 08 Jun 2015, at 17:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>>> On 08 Jun 2015, at 17:03, Damien Cassou <damien.cassou(a)inria.fr> wrote: >>>>>>> >>>>>>> >>>>>>> Sven Van Caekenberghe <sven(a)stfx.eu> writes: >>>>>>> >>>>>>>> I am not so sure we should add that. >>>>>>>> >>>>>>>> The JSON spec explicitly does not allow comments because of fear of abuse (that the comments would be used to add semantic meaning outside the spec). >>>>>>> really? That's surprising. Comments in configuration files are very >>>>>>> important. Even more when the configuration files are templates for new >>>>>>> users. >>>>>> I know some people are using STON in ways that I did not originally anticipate, that is of course cool, but writing configuration files was not the original goal. STON is a version of JSON that is closer to our object model. >>>>>> >>>>>> Like I said, I will think about it. >>>>>> >>>>>>> -- >>>>>>> Damien Cassou >>>>>>> http://damiencassou.seasidehosting.st >>>>>>> >>>>>>> "Success is the ability to go from one failure to another without >>>>>>> losing enthusiasm." --Winston Churchill >>>>> >>>> >>>> >>> >> >> > >

June 10, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Richard Sargent

camille teruel wrote >> On 10 Jun 2015, at 19:11, Chris Cunningham < > cunningham.cb@ > > wrote: >> >> Inteteresting.... >> >> On Wed, Jun 10, 2015 at 9:36 AM, Camille < > camille.teruel@ > <mailto: > camille.teruel@ > >> wrote: >> Hello Pharoers and Moosers, >> >> I did a Pratt parser extension for PetitParser. >> >> > <snip> > >> @PP Devs: >> I had trouble with the PPContext furthestFailure that is taken into >> account instead of the failures I return, so I had to redefine >> #parseWithContext: to return the failures I want. The results given by >> furthestFailure were not very meaningful in my case (the same is true for >> PPExpressionParser btw). >> But I guess it was introduced because it gives good results in other >> cases. >> So would it be possible to change this behavior to let the parser decide >> if it returns the furthestFailure or the original failure? >> >> The intent behind the furthestFailure is that it give the failure that >> gets the furthest into the source stream. It is most useful when there >> are embedded choice operators in the parser - the original/pre furthest >> behaviour would return the last failure, which depending on the incoming >> stream and the order of the choice options could be significantly not >> useful. >> >> I ran into this when working with the sql parser, which started off with >> the outer choice of (by memory): >> ^ selectStatement / insertStatement / updateStatement / >> deleteStatement >> If I was trying to part a select statement that had an error at the very >> end of the statement, the parser would return an error talking about how >> the incoming stream failed in deleteStatement. Not useful. >> >> I would be saddened if this further failure was not available. > > Yes in that case returning the furthest failure gives better results. > However, this donât give meaningful messages in all cases. > For exemple with the calculator I gave in my previous message, if I parse > â1+â I want to get âexpression expected at: 2â but instead it returns â$- > expected at 2'. > Iâm not proposing to remove this feature but to let parsers decide to use > it or not. > Something like (changes in bold): > > PPParser>>parseWithContext: context > | result | > context initializeFor: self. > result := self parseOn: context. > > "Return the furthest failure, it gives better results than the last > failure" > (result isPetitFailure and: [ self wantsFurthestFailure and: [ context > furthestFailure notNil ] ]) > ifTrue: [ ^ context furthestFailure ]. > ^ result This screams at me. Why not just delegate to the context and use a context that returns the preferred failure? e.g. end with: ^context preferredResultFor: result. > > PPParser>>wantsFurthestFailure > ^ true > > Like this, one can return the failures he wants. > > PPPrattParser>>wantsFurthestFailure > ^ false > > > Camille > >> >> -cbc -- View this message in context: http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 10, 2015

Re: [Pharo-dev] Detecting the context/producer of code change announcements

by Max Leske

> On 10 Jun 2015, at 17:13, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi everybody, > > I'm writing you to discuss about a new feature for Pharo. I would like to know your opinions and ideas. Thanks in advance. > > My point is that there are operations like "MC version load", "change set file in", "RB refactoring execution", or "class copy" that produce code change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't know that. I mean, a subscriber that listens a ClassAdded can't know if it is product of a "high-level" operation, or if it was manually performed by the user in the Nautilus browser. > > I think Pharo should provide a way to detect this information, because it can be very useful. For example, I can tell you about a tool I work on: Epicea. Epicea logs code changes while developer works (like traditionally done with the .changes file), and the user can browse, undo and redo changes. Now, imagine that your vm crashed and then you want to recover "lost" changes... you don't want to see hundreds of changes produced by Monticello when loading packages: in this case, such changes are noise and make you waste time when selecting what to redo. In Epicea package I have a workaround for detecting some "high-level" operations, but Epicea would need support from Pharo for a nice implementation. > > Brainstorming on implementations. > > I think announcements are a good mechanism to implement this feature. A simple approach is to provide begin and end announcements (e.g. MCVersionLoadBegin and MCVersionLoadEnd). Then, somebody that subscribes to such announcements can have a stack or state machine to know the context where each code change announcement is produced. It would look like: > > MCVersionLoader >> load > ... > SystemAnnouncer uniqueInstance announce: (MCVersionLoadBegin versionName: ...). > [ ... produce code changes ... ] ensure: [ > SystemAnnouncer uniqueInstance announce: (MCVersionLoadEnd versionName: ...) ]. > > which may be re-written with a convenience method as: > ... > SystemAnnouncer uniqueInstance > announceBefore: (MCVersionLoadBegin versionName: ...) > announceAfter: (MCVersionLoadEnd versionName: ...) > do: [ ... produce code changes ... ] > > but, going one step further, we could reify the concept of announcement begin and end like: > ... > announcement := (MCVersionLoad versionName: ...). > SystemAnnouncer uniqueInstance > announceBefore: (AnnouncementBegin of: announcement) > announceAfter: (AnnouncementEnd of: announcement) > do: [ ... produce code changes ... ] > > which could be re-written as: > ... > SystemAnnouncer uniqueInstance > announceBeforeAndAfter: (MCVersionLoad versionName: ...) > do: [ ... produce code changes ... ] > > I think any approach can work, but I'd love to have some feedback. I like the idea. What Iâm afraid of is however, that the dependency between begin and end announcements is implicit in your examples. The only things that tell you that they belong together are the convenience implementation on SystemAnnouncer and the naming. Iâm not familiar enough with announcements to post example code. The other thing would maybe be to force subscribers to subscribe to both announcements (again, not sure how). My point is, I want to look at one of the announcements and see that I have to work with a set of announcements. Benâs idea of hierarchichal announcements sounds pretty interesting. Maybe this is too restricting but how about saying: there exists a dependency between two announcements A and B such that whenever A is being announced, B has to have been announced before (Iâll leave the implementation to others :p). The other thing would be to clean up the announcer situationâ¦ Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s <https://youtu.be/keqdqFu1ejk?t=10m55s>). That way, if youâre interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer. I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) ) Cheers, Max > > Kind regards, > MartÃn >

June 10, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Chris Cunningham

That sounds very reasonable to me. -cbc On Wed, Jun 10, 2015 at 10:45 AM, Camille <camille.teruel(a)gmail.com> wrote: > > On 10 Jun 2015, at 19:11, Chris Cunningham <cunningham.cb(a)gmail.com> > wrote: > > Inteteresting.... > > On Wed, Jun 10, 2015 at 9:36 AM, Camille <camille.teruel(a)gmail.com> wrote: > >> Hello Pharoers and Moosers, >> >> I did a Pratt parser extension for PetitParser. >> >> <snip> > >> @PP Devs: >> I had trouble with the PPContext furthestFailure that is taken into >> account instead of the failures I return, so I had to redefine >> #parseWithContext: to return the failures I want. The results given by >> furthestFailure were not very meaningful in my case (the same is true for >> PPExpressionParser btw). >> But I guess it was introduced because it gives good results in other >> cases. >> So would it be possible to change this behavior to let the parser decide >> if it returns the furthestFailure or the original failure? >> > > The intent behind the furthestFailure is that it give the failure that > gets the furthest into the source stream. It is most useful when there are > embedded choice operators in the parser - the original/pre furthest > behaviour would return the last failure, which depending on the incoming > stream and the order of the choice options could be significantly not > useful. > > I ran into this when working with the sql parser, which started off with > the outer choice of (by memory): > ^ selectStatement / insertStatement / updateStatement / deleteStatement > If I was trying to part a select statement that had an error at the very > end of the statement, the parser would return an error talking about how > the incoming stream failed in deleteStatement. Not useful. > > I would be saddened if this further failure was not available. > > > Yes in that case returning the furthest failure gives better results. > However, this donât give meaningful messages in all cases. > For exemple with the calculator I gave in my previous message, if I parse > â1+â I want to get âexpression expected at: 2â but instead it returns â$- > expected at 2'. > Iâm not proposing to remove this feature but to let parsers decide to use > it or not. > Something like (changes in bold): > > PPParser>>parseWithContext: context > | result | > context initializeFor: self. > result := self parseOn: context. > > "Return the furthest failure, it gives better results than the last > failure" > (result isPetitFailure and: [ *self wantsFurthestFailure and: [ *context > furthestFailure notNil* ]* ]) > ifTrue: [ ^ context furthestFailure ]. > ^ result > *PPParser>>wantsFurthestFailure* > * ^ true* > > Like this, one can return the failures he wants. > > *PPPrattParser>>wantsFurthestFailure* > * ^ false* > > > Camille > > > -cbc > > >

June 10, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Camille

> On 10 Jun 2015, at 19:11, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > > Inteteresting.... > > On Wed, Jun 10, 2015 at 9:36 AM, Camille <camille.teruel(a)gmail.com <mailto:camille.teruel@gmail.com>> wrote: > Hello Pharoers and Moosers, > > I did a Pratt parser extension for PetitParser. > > <snip> > @PP Devs: > I had trouble with the PPContext furthestFailure that is taken into account instead of the failures I return, so I had to redefine #parseWithContext: to return the failures I want. The results given by furthestFailure were not very meaningful in my case (the same is true for PPExpressionParser btw). > But I guess it was introduced because it gives good results in other cases. > So would it be possible to change this behavior to let the parser decide if it returns the furthestFailure or the original failure? > > The intent behind the furthestFailure is that it give the failure that gets the furthest into the source stream. It is most useful when there are embedded choice operators in the parser - the original/pre furthest behaviour would return the last failure, which depending on the incoming stream and the order of the choice options could be significantly not useful. > > I ran into this when working with the sql parser, which started off with the outer choice of (by memory): > ^ selectStatement / insertStatement / updateStatement / deleteStatement > If I was trying to part a select statement that had an error at the very end of the statement, the parser would return an error talking about how the incoming stream failed in deleteStatement. Not useful. > > I would be saddened if this further failure was not available. Yes in that case returning the furthest failure gives better results. However, this donât give meaningful messages in all cases. For exemple with the calculator I gave in my previous message, if I parse â1+â I want to get âexpression expected at: 2â but instead it returns â$- expected at 2'. Iâm not proposing to remove this feature but to let parsers decide to use it or not. Something like (changes in bold): PPParser>>parseWithContext: context | result | context initializeFor: self. result := self parseOn: context. "Return the furthest failure, it gives better results than the last failure" (result isPetitFailure and: [ self wantsFurthestFailure and: [ context furthestFailure notNil ] ]) ifTrue: [ ^ context furthestFailure ]. ^ result PPParser>>wantsFurthestFailure ^ true Like this, one can return the failures he wants. PPPrattParser>>wantsFurthestFailure ^ false Camille > > -cbc

June 10, 2015

Re: [Pharo-dev] Detecting the context/producer of code change announcements

by Ben Coman

On Wed, Jun 10, 2015 at 11:13 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi everybody, > > I'm writing you to discuss about a new feature for Pharo. I would like to > know your opinions and ideas. Thanks in advance. > > My point is that there are operations like "MC version load", "change set > file in", "RB refactoring execution", or "class copy" that produce code > change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't > know that. I mean, a subscriber that listens a ClassAdded can't know if it > is product of a "high-level" operation, or if it was manually performed by > the user in the Nautilus browser. > > I think Pharo should provide a way to detect this information, because it > can be very useful. For example, I can tell you about a tool I work on: > Epicea. Epicea logs code changes while developer works (like traditionally > done with the .changes file), and the user can browse, undo and redo > changes. Now, imagine that your vm crashed and then you want to recover > "lost" changes... you don't want to see hundreds of changes produced by > Monticello when loading packages: in this case, such changes are noise and > make you waste time when selecting what to redo. In Epicea package I have a > workaround for detecting some "high-level" operations, but Epicea would need > support from Pharo for a nice implementation. > > Brainstorming on implementations. > > I think announcements are a good mechanism to implement this feature. A > simple approach is to provide begin and end announcements (e.g. > MCVersionLoadBegin and MCVersionLoadEnd). Then, somebody that subscribes to > such announcements can have a stack or state machine to know the context > where each code change announcement is produced. It would look like: > > MCVersionLoader >> load > ... > SystemAnnouncer uniqueInstance announce: (MCVersionLoadBegin versionName: > ...). > [ ... produce code changes ... ] ensure: [ > SystemAnnouncer uniqueInstance announce: (MCVersionLoadEnd > versionName: ...) ]. > > which may be re-written with a convenience method as: > ... > SystemAnnouncer uniqueInstance > announceBefore: (MCVersionLoadBegin versionName: ...) > announceAfter: (MCVersionLoadEnd versionName: ...) > do: [ ... produce code changes ... ] > > but, going one step further, we could reify the concept of announcement > begin and end like: > ... > announcement := (MCVersionLoad versionName: ...). > SystemAnnouncer uniqueInstance > announceBefore: (AnnouncementBegin of: announcement) > announceAfter: (AnnouncementEnd of: announcement) > do: [ ... produce code changes ... ] > > which could be re-written as: > ... > SystemAnnouncer uniqueInstance > announceBeforeAndAfter: (MCVersionLoad versionName: ...) > do: [ ... produce code changes ... ] > > I think any approach can work, but I'd love to have some feedback. > > Kind regards, > MartÃn > The first thought that occurs to me is whether Announcements can be hierarchical. So the "low-level" announcements have a "high-level" announcement as their parent. Then the "recover changes" interface shows only the high-level changes at the first tree level, but you can still drill down to disable individual "low-level" changes. Sorry, in trying to think of an opinion for begin/end pattern I come up blank. Not enough experience with it. cheers -ben

June 10, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Chris Cunningham

Inteteresting.... On Wed, Jun 10, 2015 at 9:36 AM, Camille <camille.teruel(a)gmail.com> wrote: > Hello Pharoers and Moosers, > > I did a Pratt parser extension for PetitParser. > > <snip> > @PP Devs: > I had trouble with the PPContext furthestFailure that is taken into > account instead of the failures I return, so I had to redefine > #parseWithContext: to return the failures I want. The results given by > furthestFailure were not very meaningful in my case (the same is true for > PPExpressionParser btw). > But I guess it was introduced because it gives good results in other > cases. > So would it be possible to change this behavior to let the parser decide > if it returns the furthestFailure or the original failure? > The intent behind the furthestFailure is that it give the failure that gets the furthest into the source stream. It is most useful when there are embedded choice operators in the parser - the original/pre furthest behaviour would return the last failure, which depending on the incoming stream and the order of the choice options could be significantly not useful. I ran into this when working with the sql parser, which started off with the outer choice of (by memory): ^ selectStatement / insertStatement / updateStatement / deleteStatement If I was trying to part a select statement that had an error at the very end of the statement, the parser would return an error talking about how the incoming stream failed in deleteStatement. Not useful. I would be saddened if this further failure was not available. -cbc

June 10, 2015