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

Re: [Pharo-dev] RBFutureDeprecationWarningRule: remove?

by Yuriy Tymchuk

Maybe we can have a superclass for that? Because for example selection (highlight) of the problematic code was not implemented some time ago for RBFutureDeprecationWarningRule. And itâs not trivial to do. So maybe having a superclass that implements this functionality can be useful. Uko > On 17 Aug 2015, at 14:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The idea behind RBFutureDeprecationWarningRule is very good, but I think we should not have one > Rule for all selectors, but if a rule makes sense, just add a new class for each. This way they are much > betterâ¦ to e.g. back port. And can be transformation rules in most cases. > > https://pharo.fogbugz.com/f/cases/16241 > > Marcus >

Aug. 17, 2015

Re: [Pharo-dev] Two new critique rules: RBRuleIfNotEmptyDo and RBRuleIfNotNilDo

by Marcus Denker

> On 17 Aug 2015, at 13:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >> We kept the Do: variants for compatibility, but the problem is that people >> nevertheless >> use them > > This seems inevitable with things that are loaded by default. Can we extract > the compatibility methods into a Grease-like library that can be loaded only > when needed? Yes, that would be nice. Marcus

Aug. 17, 2015

Re: [Pharo-dev] Two new critique rules: RBRuleIfNotEmptyDo and RBRuleIfNotNilDo

by Sean P. DeNigris

Marcus Denker-4 wrote > We kept the Do: variants for compatibility, but the problem is that people > nevertheless > use them This seems inevitable with things that are loaded by default. Can we extract the compatibility methods into a Grease-like library that can be loaded only when needed? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Two-new-critique-rules-RBRuleIfNotEmptyDo-and-RBRuleI… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 17, 2015

Re: [Pharo-dev] Error in plugin AddSubscribers (View)

by Sean P. DeNigris

Ben Coman wrote > Anyone else getting this error when viewing a case in Fogbugz Yes. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Error-in-plugin-AddSubscribers-View-tp4843427p4843450… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 17, 2015

RBFutureDeprecationWarningRule: remove?

by Marcus Denker

Hi, The idea behind RBFutureDeprecationWarningRule is very good, but I think we should not have one Rule for all selectors, but if a rule makes sense, just add a new class for each. This way they are much betterâ¦ to e.g. back port. And can be transformation rules in most cases. https://pharo.fogbugz.com/f/cases/16241 Marcus

Aug. 17, 2015

Properties for Packages

by Marcus Denker

Hi, 16243 add property API to RPackage https://pharo.fogbugz.com/f/cases/16243 testPropertyAtPut | testValue package | testValue := Date today. package := self class package. package propertyAt: #testKeySelector put: testValue. self assert: (package propertyAt: #testKeySelector) equals: testValue. package removeProperty: #testKeySelector. self assert: package properties isNil. (and yes, the property API should be a traitâ¦)

Aug. 17, 2015

Re: [Pharo-dev] PetitParser speed and cost of PPFailure

by Jan KurÅ¡

Hi Holger, Thank you for bringing this. In the first case, I suggest to create a specialised parser, that fills in the classification as you desire. In the second case, the left refactoring of the common prefix is the way to go. As you are speaking about general solution, there is a PetitParser rewriter, that can do what you mentioned. Unfortunately I cannot provide more details as I never really got into this. The other approach, as the first Jan already mentioned, is a compiler that takes PetitParser as an input and produces a class representing a parser that recognizes equivalent language and that should resemble hand-written top-down parser. During the compilation, we do many optimizations and I believe we can get decent performance. As the compiler is not production ready and as we are looking for a use cases, I can import your grammar and let you know how to make it working with our tool and what would be the performance gain. In that case, I would need some test cases and benchmark inputs from you. Cheers Jan On Mon, 17 Aug 2015 08:30 Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi Holger, > > Jan and me are working on a PetitCompiler [1,2], a tool whose aim > is to compile PetitParsers to Smalltalk to gain performance and > allow for hand-tuning. In short, we try to generate a tokenizer > and LL(1) parser on top of it. In general case, given the flexibility > of PetitParser, this is rather tricky :-) > > The results are - performance wise - not bad, IMO [3]. > As long as your grammar is sort of LL(1) it should not backtrack > (but Jan would give you more details, this is his domain) > > Now, the whole thing is work-in-progress and by no means > is - as of today - production-ready tool. I'd like to give it > a try and benchmark it as it would make nice case-study for us. > But - no promises time-wise. I'm bloody busy now and this is > a sort of spare time-project for me. > > Best, Jan > > [1] https://bitbucket.org/janvrany/stx-goodies-petitparser > [2] http://smalltalkhub.com/#!/~JanKurs/PetitParser/ > [3] http://bit.ly/1IXnz0c > > > On Sun, 2015-08-16 at 17:58 +0200, Holger Freyther wrote: > > Hi, > > > > once again I am not sure if this is the right list. The first parser > > I wrote using > > PetitParser was a SIP (and then MGCP) parser. I have recently > > ported[1] the > > code to Pharo and with Pharo it is very tempting to Use > > BlockClosure>>#bench > > to get an idea of the speed. > > > > > > I have two performance âissuesâ and wonder if others hand similar > > issues with > > PetitParser and if there is a general approach to this. > > > > > > > > 1.) Combining two PPCharsetPredicates does not combine the > > âclassificationâ > > table it had. One could create a PPPredicateObjectParser subclass > > that is > > special casing >>#/ to build a combined classification table. > > > > > > 2.) When blindly following a BNF enumeration of "A or B or C or D or > > E > > or CatchAllâ and each âA, Bâ follow common pattern (e.g. token COLON > > value) > > one pays a high cost in the backtracking and constructing the > > PPFailure for > > each failed case. > > > > In my SIPGrammar I have action parsers for To ==>.. From ==> and > > would > > like to keep that. At the same time I would be happy if the token in > > front of the > > colon is only consumed once and then delegated to the right parser > > and if that > > one failed use the âcatch allâ one. > > > > I donât know which abstraction would be needed to allow creating > > optimized > > PetitParsers for such grammars. > > > > sorry for the long mail, long details and context is below. > > > > > > kind regards > > holger > > > > > > > > > > > > > > Full details: > > > > > > 1.) CharSetPredicate > > > > > aParser bParser combinedParser aTime bTime cTime | > > > > aParser := #digit asParser. > > bParser := #letter asParser. > > combinedParser := aParser / bParser. > > > > aTime := [ aParser parse: 'b'] bench. > > bTime := [ bParser parse: 'b'] bench. > > cTime := [ combinedParser parse: 'b'] bench. > > { aTime. bTime. cTime } > > > > cTime is bounded by the time execution time of of the slowest > > of these parsers + overhead (e.g. PPFailure creation). > > > > e.g. > > > > #('559,000 per second.' '1,010,000 per second.' '429,000 per > > second.') > > > > With a proof of concept PPPredicateCharSetParser > > > > #('1,330,000 per second.' '1,550,000 per second.' '1,580,000 per > > second.â) > > > > The noise is pretty string here but what is important is that bParser > > and the > > combinedParser are in the same ballpark. > > > > 2.) Choice Parser > > > > > > > > The BNF grammar of the parser is roughly: > > > > Request = Request-Line > > *( message-header ) > > CRLF > > [ message-body ] > > > > message-header = (Accept > > â¦ > > / To > > / From > > / Via > > / extension-header) CRLF > > > > Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) > > Accept = "Accept" HCOLON > > [ accept-range *(COMMA accept-range) ] > > > > > > So there can be several lines of âmessage-headerâ. And each method > > header > > starts with a token/word, a colon and then the parameter. âextension > > -headerâ > > is kind of a catch all if no other rule matched. E.g. if a client > > sends a To which is > > wrongly encoded it would end up with the extension-header. > > > > I transferred the above naively to PetitParser and end up with > > something like > > parsing ~500 messages a second. The main cost appears to come from > > the > > choice parser that needs to create a PetitFailure all the time. E.g. > > if you have a > > line like this: > > > > âFrom: âHolger Freytherâ <sip:323234@foo.de>â > > > > The choice parser will start with the âAcceptâ rule, parse the token > > (âFromâ and > > then create a PPFailure, then â¦ rules, then âToâ, parse the token.. > > So we have > > parsing the same token more than once and creating PPFailures all the > > time. I > > ended up creating a custom parser that will peek the token, have a > > horrible chain > > of token = âXYZâ ifTrue and then dispatch to the other rule. > > > > It would be nice if PetitParser could be taught to only parse the > > token once and > > then delegate to the param rule. E.g. a PPAnyOfParser that allows to > > specify the > > token to match, the parser to continue with and a fallback parser? > > > > > > > > [1] > > http://smalltalkhub.com/#!/~osmocom/SIP > > http://smalltalkhub.com/#!/~osmocom/MGCP > > >

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Sean P. DeNigris

Ben Coman wrote > 'ConfigurationOf' is currently a fairly strong convention. I think > its okay to build such conventions into our tools. +1. This seems in line with duck typing, an oft touted advantage of dynamic languages like Smalltalk. Although, for new projects you can subclass ConfigurationOf (an actual class). The problem is that when Metacello was brand new, one could not depend on any support classes preloaded into all supported platforms, so it made no assumptions and bootstrapped the entire library if necessary. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Ben Coman

'ConfigurationOf' is currently a fairly strong convention. I think its okay to build such conventions into our tools. Maybe by default there can be a "smart folder" (i.e. having some filter) and a smart folder configuration option could be to hide any contained package from the top-level list. cheers -ben On Mon, Aug 17, 2015 at 5:16 PM, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > It could be easily done, but in a ugly way to me. The only thing you know > about a configuration package is that its name begins with > 'ConfigurationOf', or it has some specific methods. There is no data above a > package to know if it is a regular one or a configuration. Am I wrong ? If > there is, it can be done in a better way. > > Franck > > ________________________________ > From: kilon.alios(a)gmail.com > Date: Mon, 17 Aug 2015 09:04:09 +0000 > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Projects are slowly getting to live... and > > > impressive you guys are busy non stop, I am feel so glad Pharo move forward > so fast. > > No I did not mean to remove configurations but rather hide them, or group > them together so they dont display together with other packages. > > On Mon, Aug 17, 2015 at 12:01 AM stepharo <stepharo(a)free.fr> wrote: > > First it could be worse :) We cannot build a full ecosystem without > capturing dependencies. > > Second we are (christophe) working since a year on the Cargo Package > Manager. > [Christophe knows many package manager (Java ruby and others).] > With Cargo every single package expresses its dependencies instead of using > external packages such as a Configuration. > So we will see how it goes. > > Stef > > > One of the things that annoy me is how many Configurations and Baselines > pollute the package space that are of little interest to the user. It would > be nice to group them and filter them out of Nautilus unless user asks for > them. > > I really like this new approach great work. > > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr> wrote: > > > > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : >> stepharo wrote >>> you get a project (group) with all your packages together ready to work >>> ;) >> Cool! I feel more and more that the standard "Package" pane is only useful >> for... packaging, and when one takes off the dependency management hat and >> puts the user hat on (i.e. most of the time), what you really want there >> is >> a logical view of the system. So I see three use cases: >> - Logical view of the system - I guess this was the original intention of >> Categories, but has been hijacked by Monticello >> - By project - which, as you just showed, we have now, yay! >> - By package - the least useful, but primary (up til now), view > > Indeed. > We will see what we get at the end but may be something like > > MyProject > AnotherProject > System > LowLevel > > And people will not be overwhelmed by hundreds of nice packages. :) > > I think that touching package contents under the assumption that the > package list is too long in the UI > is the wrong way to look at the problem. > Packages are unit of deployment and we need Projects - unit of > knowledge. And the UI should shows both > depending on the view we want to get. > > Stef >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> > > >

Aug. 17, 2015

Error in plugin AddSubscribers (View)

by Ben Coman

Anyone else getting this error when viewing a case in Fogbugz "Error in plugin AddSubscribers (View)" e.g. https://pharo.fogbugz.com/default.asp?16192 cheer s-ben

Aug. 17, 2015