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

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

by stepharo

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 > <mailto:stepharo@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. 16, 2015

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

by Dimitris Chloupis

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. 16, 2015

Re: [Pharo-dev] 16216 Default values in NECPreferences are not initilized right

by Merwan Ouddane

On 16/08/2015 16:26, Nicolai Hess wrote: > > > 2015-08-16 15:38 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com > <mailto:merwanouddane@gmail.com>>: > > Was the NECPreferences>>defaultPopupDelay in the post script ? > > > > No, but your class initialization uses the default popup delay, it > should work if we now just call the postcript. > (better solution would be to add the enable/smart char/..../ settings > in the class init. They were already in the class initialization before my modification. Set to false. I made a bug entry to change it like it was before. https://pharo.fogbugz.com/f/cases/16237/Values-in-the-class-init-of-NECPref… > > On 16/08/2015 14:25, Merwan Ouddane wrote: > > This is really weird, in the initialization the NEC was > disabled by default, I did not changed that .... > > And even if the default value for the pop-up to appear was > 200, in a fresh image it was at 500, coming from hell U.u > > Merwan > > On 16/08/2015 10:55, stepharo wrote: > > Thanks. Can you open a new issue? > Merwan you will have to revisit your code. > > Stef > > Le 15/8/15 22:53, Nicolai Hess a Ã©crit : > > This is not good. Somehow this disables NEC. > And resets many other NEC settings, for example > if you just enables code complation again, you still > don't have > the smart characters (-> inserting matchin "or ) or } ...) > > > > > > >

Aug. 16, 2015

[pharo-project/pharo-core] 35e462: 50238

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 35e4624ef05687ec9630be362887a30a711478ea https://github.com/pharo-project/pharo-core/commit/35e4624ef05687ec9630be36… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-16 (Sun, 16 Aug 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50237.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50238.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50237.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50238.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50238 16229 NEC is disabled and prior default values are unset https://pharo.fogbugz.com/f/cases/16229 http://files.pharo.org/image/50/50238.zip

Aug. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 16, 2015

Re: [Pharo-dev] Mongo - find object by id

by stepharo

> Hi Stephane, > > I have collected my points to add to the book. > > Can you give me an entry point how to do a pull request on the paper > please? > Pillar? Editor? Script? Sounds complicated for the first time. > If you can use pillar this is better, else we will do a pass and convert it to pillar Since the chapter is for the book that should be out I'm not that editing it directly is a good. Now what we can do is to work on on a separate file that Johan or Esteban can merge to the chapter once it is finished. What I was thinking about is to have a series of extras section with for example some of the problems and solutions you encountered. How to handle loop within your domain? How to find an object by id? ... The original file is here: https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Voya… I created a VoyageAdditionalText.pier that you can edit. And this is easy - you can go to the page - fork the folder - edit in the web the file and send a pull request. if this is not working, we will add you to the project and you can directly edit this file. > Regards > Sabine > > > > 2015-08-13 16:17 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > >> Hi Stephane, >> >> sure, I am happy to give something back to the community. I dont >> have so much time because of my baby but I will try my best. >> >> Where shall I put it in? > > You can do pull requests in the paper. This way they will be close > to the original version. > > >> Sabina >> >> you know what I would really love from you .... >> this is that you reread the Voyage chapter and make a list of >> the problems you faced and that are not described in the chapter. >> You can write it in any bad ways and we can do a edit phase >> after, >> >> Why do I ask that? Because I'm stupid in Mongo and I would >> love to have a good doc. >> And only the people facing the problems can spot them nicely. >> I often write doc on things that I do not know but this is >> not working well because I'm slow in that case and .... I >> could be much better >> doing something else where I'm good at. >> >> Stef >> >> Le 12/8/15 09:40, Sabine Manaa a Ã©crit : >> >> Hi, >> >> on mongo console, this brings me a persons information >> from mongo db >> db.Persons.find({"_id" : >> ObjectId("75b900000000000000000000")}) >> >> I try to query the same person from pharo and I do not >> succeed. >> >> This makes my image hanging: >> RKAPerson selectMany: {('_id' -> (OID >> value:'75b900000000000000000000'))} >> >> also other variations e.g. >> RKAPerson selectMany: {('_id' -> >> ('75b900000000000000000000')). } >> asDictionary. >> >> do not work >> >> Other queries like >> RKAPerson selectMany:{('lastName' -> ('Maier')).} >> asDictionary. >> or >> RKAPerson selectMany:{('nextTripNumber' -> (57)).} >> asDictionary. >> >> work fine. >> >> How can I query for an object with the object id? >> >> Regards >> Sabine >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Mongo-find-object-by-id-tp4842231.html >> Sent from the Pharo Smalltalk Developers mailing list >> archive at Nabble.com. >> >> >> >> > >

Aug. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 16, 2015

[pharo-project/pharo-core] 35230a: 50237

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 35230a5bb4425978db09458904241766c558d9bb https://github.com/pharo-project/pharo-core/commit/35230a5bb4425978db094589… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-16 (Sun, 16 Aug 2015) Changed paths: M Polymorph-Widgets.package/UITheme.class/instance/services/fileSaveIn_title_extensions_path_.st A Polymorph-Widgets.package/UITheme.class/instance/services/fileSaveIn_title_initialAnswer_extensions_path_.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - variables/testSetLinkOnInstanceVariable.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - variables/testSetLinkOnInstanceVariableAndUninstall.st R Reflectivity.package/LinkWrapper.class/README.md R Reflectivity.package/LinkWrapper.class/definition.st R Reflectivity.package/LinkWrapper.class/instance/accessing/link.st R Reflectivity.package/LinkWrapper.class/instance/accessing/links.st R Reflectivity.package/LinkWrapper.class/instance/accessing/setClass_.st R Reflectivity.package/LinkWrapper.class/instance/accessing/setLink_.st R Reflectivity.package/LinkWrapper.class/instance/accessing/slot.st R Reflectivity.package/LinkWrapper.class/instance/accessing/slot_.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/=.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/doesNotUnderstand_.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/hash.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/index.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/index_.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/isSpecial.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/isVirtual.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/isVisible.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/name.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/name_.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/parentScopeFor_.st R Reflectivity.package/LinkWrapper.class/instance/forwarded/size.st R Reflectivity.package/LinkWrapper.class/instance/installation/removeLink_.st R Reflectivity.package/LinkWrapper.class/instance/installation/uninstall.st A Reflectivity.package/extension/Slot/instance/clearReflectivityAnnotations.st M Reflectivity.package/extension/Slot/instance/link_.st A Reflectivity.package/extension/Slot/instance/links.st A Reflectivity.package/extension/Slot/instance/removeLink_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50236.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50237.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50236.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50237.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/PointerLayout.class/instance/reshaping/replaceSlot_with_.st A Slot.package/Slot.class/instance/properties/propertyAt_ifAbsentPut_.st R Traits.package/TClass.class/instance/initialize-release/replaceClassVariable_.st Log Message: ----------- 50237 16235 New method in UITheme for saving files https://pharo.fogbugz.com/f/cases/16235 16230 Use Property API to set a MetaLink on Slots https://pharo.fogbugz.com/f/cases/16230 http://files.pharo.org/image/50/50237.zip

Aug. 16, 2015

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

by stepharo

Hi holger At ESUG Jan showed that he is working on a kind of PetitParser compiler. Le 16/8/15 17:58, Holger Freyther a Ã©crit : > 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. What thierry will tell you is that if you do not need to compose your grammars and the grammar is not evolving and you need speed then a SmaCC approache with LGR, LALR or something else is probably faster. Stef > > > 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. 16, 2015

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

by stepharo

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. 16, 2015