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

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Francisco Garau

Hi Camile > On 11 Jun 2015, at 10:47, Camille <camille.teruel(a)gmail.com> wrote: > > >> On 11 Jun 2015, at 09:30, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: >> >> That sounds really cool and useful extension. >> > Thank you Jan! >> Regarding the furthest failure, the core of the problem is the distinction between an error and a failure. Error reports on a problem in the input, while failure is information for choice parser combinator. In general, the furthest failure is a better approximation of an error than the last failure, so we use it. >> >> I am not sure what exactly is the problem in case of PrattParser. I guess the last failure gives better results for a user? >> > Yes, with furthest failure I get errors from tokenization instead of my errors. > For exemple with the calculator grammar I gave in my first mail when I parse â1+â the furthestFailure is â$- expected at 2â whereas I return âexpression expected at 2â because there's a whole expression missing. Same thing with â(1+2â that returns âdigit expected at 4â instead of â$) expected at 4â. > > But furthest failure gives wrong messages in other cases to. > Consider this sequence parser: > > keyword := #letter asParser plus , $: asParser. > keyword parse: âfoo' > > This returns 'letter expected at 3â, but no matter how many letters I add to the end Iâll still get âletter expectedâ. > I want to get what is really missing: '$: expected at 3â. Any of those error messages wouldn't be too bad if the failing production rule were also mentioned. Something like "keyword rule failed with xx expected at 3" But yeah, that would require annotating the production rules which can pollute the clarity of the grammar definition... > Maybe returning the âlatest furthest failureâ instead of the âfirst furthest failureâ could solves the problem here (i.e. replacing > with >= in PPContext>>#noteFailure:)? >> One has to consider a pratt parser included in the normal parser, e. g. Expressions parsed by pratt in a Java Grammar. Depending where an error occurs, different strategy for choosing the proper failure is necessary :-/ >> > Indeed, my hack (redefining #parseWithContext:) works only when the Pratt parser is the top parser, but a soon as I compose it Iâm screwed because only parseOn: is sent to the Pratt parser. > Thatâs why I wonder if letting the parser decide what to return wouldnât solve the problem: by default the furthest failure but special parsers can still decide. >> Regarding tokenization, there is a message token, that returns PPTokenParser, which transforms a parsed input into the PPToken object. Perhaps this might be helpful? >> > The Pratt tokens are special: a token points back to the parser that generated it (its âkindâ). > PPTokenKind subclasses PPFlatteningParser and generates instances of PPPrattToken. > A PPTokenKind stores the precedence, the action to be executed when a token of this kind is met at the start of an expression (for terminals and prefixes) and the action to be executed when a token is met in the middle of an expression (for postfixes and infixes). > > Cheers, > Camille >> Cheers Jan >> >> >>> On Wed, Jun 10, 2015, 20:52 Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: >>> 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 12, 2015

What CodeImport is all about?

by Alexandre Bergel

Hi! I cannot figure out what this package is about. Looks like a kind of change set? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 12, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Igor Stasenko

Absence of Metacello won't help you dealing with dependencies and loading stuff by using hand-made scripts by dozens of people written at different points in time and not maintained by anyone. It may be too complicated to use, especially at earlier stages of development, and in situations, when all you need is to use latest versions of everything available (aka #bleedingedge). But always staying on bleeding edge hurts a lot (that's why it called so) and it is conscious choice of many professional developers to base own development on latest but stable versions of dependencies. Simply because then you have more time focusing on what you want to do, instead of fighting with various bugs and drastic changes and updates in numerous dependencies. And this is where tools like Metacello helping a lot. Because once you define stable point, you can always be sure that you can reproduce it at any moment and load without problems. And no, script on which you spent 1 minute and placed on pastebin doesn't helps in such situation. It just contributes even more mess to what is already there. -- Best regards, Igor Stasenko.

June 12, 2015

Re: [Pharo-dev] Pharo 4, format on accept/display

by Paul DeBruicker

Format on display does horrible things to the Playground for the version I uploaded yesterday. A new version is in the inbox that does not do them. Marcus Denker-4 wrote > Thanks, I will have a look. > >> On 11 Jun 2015, at 16:39, Paul DeBruicker < > pdebruic@ > > wrote: >> >> The 'fix' for Pharo40 is in the Pharo40Inbox as Slice-14387. >> >> It formats code on accept and/or display using the >> RBConfigurableFormatter. >> >> >> >> Marcus Denker-4 wrote >>>> On 11 Jun 2015, at 08:16, Peter UhnÃ¡k < >> >>> i.uhnak@ >> >>> > wrote: >>>> >>>> If my understanding of Pharo's release management is correct, then no >>>> new >>>> features are added after a release, only bugfixes. >>>> >>> >>> Yes, but we do make exceptionsâ¦ >>> >>> e.g. I added format on display and accept to Pharo3 after the release, >>> because it is indeed a nice thing to have. >>> >>> So in that sense not having it in Pharo4 is kind of a bug. >>> >>> The version we get in Pharo5 will come with a new pretty printer, we >>> will >>> not back port that, >>> so doing a âminimally intrusiveâ version for Pharo4 makes sense. >>> >>> >>> Marcus >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831720.ht… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> -- View this message in context: http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831805.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by James Foster

> On Jun 11, 2015, at 2:47 AM, Camille <camille.teruel(a)gmail.com> wrote: > > But furthest failure gives wrong messages in other cases to. > Consider this sequence parser: > > keyword := #letter asParser plus , $: asParser. > keyword parse: âfoo' > > This returns 'letter expected at 3â, but no matter how many letters I add to the end Iâll still get âletter expectedâ. > I want to get what is really missing: '$: expected at 3â. Indeed. I recently submitted an update to the parser and tests (based on code from Dale Henrichs) for a problem in which trim would cause the error to always be âseparator expectedâ when there was something after the separator that was expected. Better error reporting would certainly be helpful. The âletter expectedâ explanation is quite wrong. James Foster

June 11, 2015

Re: [Pharo-dev] Pharo PPA doesn't seem to work on ubuntu vivid (15.04)

by Javier PimÃ¡s

Thanks! I now installs just fine, and everything works correctly after also installing pharo-source-files On Thu, Jun 11, 2015 at 4:08 PM, Markus Fritsche <mfritsche(a)reauktion.de> wrote: > Hello Javier, > > I copied the packages to Vivid, can you try again? Please also install > pharo-sources > > Best regards, > Markus > > Am 11.06.2015 um 15:54 schrieb Javier PimÃ¡s: > >> Hi there, after adding the ppa to the system I cannot install the vm. >> Only pharo-launcher is available but it can't be installed because the >> pharo-vm-core-i386 is not installable. >> >> What I tried was this: >> >> sudo apt-add-repository ppa:pharo/stable >> sudo dpkg --add-architecture i386 >> sudo apt-get update >> sudo apt-get install pharo-launcher >> >> looking at https://launchpad.net/~pharo/+archive/ubuntu/stable < >> https://launchpad.net/%7Epharo/+archive/ubuntu/stable> it seems like >> packages are too old (before 15.04 came out), maybe they need to be updated? >> >> cheers, >> Javier >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > -- Javier PimÃ¡s Ciudad de Buenos Aires

June 11, 2015

Re: [Pharo-dev] Pharo PPA doesn't seem to work on ubuntu vivid (15.04)

by Markus Fritsche

Hello Javier, I copied the packages to Vivid, can you try again? Please also install pharo-sources Best regards, Markus Am 11.06.2015 um 15:54 schrieb Javier PimÃ¡s: > Hi there, after adding the ppa to the system I cannot install the vm. > Only pharo-launcher is available but it can't be installed because the > pharo-vm-core-i386 is not installable. > > What I tried was this: > > sudo apt-add-repository ppa:pharo/stable > sudo dpkg --add-architecture i386 > sudo apt-get update > sudo apt-get install pharo-launcher > > looking at https://launchpad.net/~pharo/+archive/ubuntu/stable > <https://launchpad.net/%7Epharo/+archive/ubuntu/stable> it seems like > packages are too old (before 15.04 came out), maybe they need to be > updated? > > cheers, > Javier > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires

June 11, 2015

Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Ben Coman

On Thu, Jun 11, 2015 at 11:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 11 Jun 2015, at 16:42, Ben Coman <btc(a)openInWorld.com> wrote: > > On Thu, Jun 11, 2015 at 2:55 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > maybe you already noticed. The latest update for Pharo 5 which is 50103 (see > [1]). > includes a new tool called "Catalog Browser". > > Where to go > =========== > > You will find it under "Tools" -> "Catalog Browser" and it will display the > configs together with the catalog metadata like project description. > > The code is managed with a configuration similar to what we have for > a few other packages/projects. The tool was written by Esteban Lorenzano > with small > improvements like spotter integration from my side. Feel free to contribute > more features. > > The repository can be found on SmalltalkHub [2]. > > This new tool basically gives you access to all available configurations > aggregated at [3]. You can use a small UI to search and load the configs > (see world menu -> "Tools" -> "Catalog Browser". > > But you can also use Spotter to load a config. > > Example on how to load ScriptManager config: > ============================================ > - open Spotter (SHIFT + ENTER on Windows, ...) > - type in "Script" and you will find a spotter category "Catalog Projects" > with "ScriptManager" in it > - just hit enter and the config is loaded > > > Just had a quick try. Its nice to get descriptions, like for > "TaskIT". However I think there should be a confirmation dialog > before actually loading a Configuration, which is a potentially > destructive/undoable action. Its too easy that habits pressing > <enter> for other functions assert themselves and load a configuration > accidentally. Perhaps an alternative is to open a window with more > information from the other fields of the catalog that has a button to > load the Configuration. > > > > Same for all others, so try with "Seaside", "MongoTalk", ... > > In the short/mid-term this new tool should replace the existing config > browser as it > gives more informations about the projects. > > > I don't think its a total replacement for the Configuration Browser. > The new function suits the case of searching for a configuration you > already know about, bu tmany times I like catalog browsers when I'm > not searching for something. That is, when I don't know what is there > and I'm *browsing*. Indeed, if you are searching for a particular > configuration then you probably already know what it is and the > additional info is then not needed. > > > But is a superset. > We do not want to keep two tools with same functionality (we already did > this a lot in the past, but we are like alcoholics in recovery nowâ¦ :P) > > Esteban > > ps: when you already know what you want, most probably you just load through > a command line (or a script)â¦ at least thatâs what I do :) > I worked out that typing #cat gave me what I wanted. However when I down-arrow from GraphViz, it cycles back to the top to A4BP. I can't believe there are no configurations after GraphViz :) cheers -ben

June 11, 2015

Re: [Pharo-dev] Pharo 4, format on accept/display

by Marcus Denker

Thanks, I will have a look. > On 11 Jun 2015, at 16:39, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > The 'fix' for Pharo40 is in the Pharo40Inbox as Slice-14387. > > It formats code on accept and/or display using the RBConfigurableFormatter. > > > > Marcus Denker-4 wrote >>> On 11 Jun 2015, at 08:16, Peter UhnÃ¡k < > >> i.uhnak@ > >> > wrote: >>> >>> If my understanding of Pharo's release management is correct, then no new >>> features are added after a release, only bugfixes. >>> >> >> Yes, but we do make exceptionsâ¦ >> >> e.g. I added format on display and accept to Pharo3 after the release, >> because it is indeed a nice thing to have. >> >> So in that sense not having it in Pharo4 is kind of a bug. >> >> The version we get in Pharo5 will come with a new pretty printer, we will >> not back port that, >> so doing a âminimally intrusiveâ version for Pharo4 makes sense. >> >> >> Marcus > > > > > > -- > View this message in context: http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831720.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 11, 2015

[pharo-project/pharo-core]

by GitHub

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

June 11, 2015