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

Re: [Pharo-dev] Morphic layoutInset: Rectangle vs Margin

by stepharo

Hi stefan We introduced Margin because it encapsulates the logic of a amount specified as one, two or four numbers. I think that it works really nicely with Rectangle. It avoids isKindOf: Point and other ugly checks. Now about the layoutInset: I do not know. Do you have tests and code? Stef Le 16/8/15 17:48, Stephan Eggermont a Ã©crit : > I only today found out why I couldn't get > layoutInset: to work like in older examples: > Rectangles are now forced to have normalized > origin and corner. The result is that the > inset tends to be at an unexpected side. > Replacing the Rectangle by a Margin (and > switching argument order) helps. > > Stephan > > > >

Aug. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 16, 2015

[pharo-project/pharo-core] 900fab: 50236

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 900fabfab3d789f2aadb33d02bf91c1649461ba0 https://github.com/pharo-project/pharo-core/commit/900fabfab3d789f2aadb33d0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-16 (Sun, 16 Aug 2015) Changed paths: R CodeImport.package/ChunkWriteStream.class/instance/accessing/contents.st A CodeImport.package/ChunkWriteStream.class/instance/accessing/nextChunkPut_.st A CodeImport.package/ChunkWriteStream.class/instance/accessing/nextPut_.st A CodeImport.package/ChunkWriteStream.class/instance/accessing/terminatorMark.st R CodeImport.package/ChunkWriteStream.class/instance/decorating/reset.st R CodeImport.package/ChunkWriteStream.class/instance/helpers/cr.st R CodeImport.package/ChunkWriteStream.class/instance/helpers/tab.st A CodeImport.package/ChunkWriteStream.class/instance/reflective operations/doesNotUnderstand_.st R CodeImport.package/ChunkWriteStream.class/instance/writing/nextChunkPut_.st R CodeImport.package/ChunkWriteStream.class/instance/writing/nextPut_.st R CodeImport.package/ChunkWriteStream.class/instance/writing/terminatorMark.st M MonticelloGUI.package/MCTool.class/instance/morphic ui/textMorph_.st A NautilusGroupAutoBuilder.package/extension/CatalogBrowser/instance/installAndCreateGroupButton_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50235.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50236.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50235.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50236.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Catalog.package/CatalogBrowser.class/README.md A Tool-Catalog.package/CatalogBrowser.class/instance/actions/defineAllRepositoriesInMCBrowser.st A Tool-Catalog.package/CatalogBrowser.class/instance/actions/defineCurrentVersionRepositoryInMCBrowser.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/installStableVersionButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/installStableVersionMenuItem_.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/loadConfigurationButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/loadConfigurationMenuItem_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineAllRepositoriesInMCBrowserButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineCurrentVersionRepositoryButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionMenuItem_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationMenuItem_.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/availableRepositoryURLStrings.st M Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/buildContextMenuOn_.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/repositoryObjectFromURLString_.st M Tool-Catalog.package/CatalogProject.class/README.md R Tool-Catalog.package/CatalogProject.class/class/accessing/repositoryNames.st A Tool-Catalog.package/CatalogProject.class/class/accessing/repositoryURLToNameMappings.st A Tool-Catalog.package/CatalogProject.class/class/private/availableRepositoryURLStrings.st R Tool-Catalog.package/CatalogProject.class/class/private/createRepositoryNames.st A Tool-Catalog.package/CatalogProject.class/class/private/createRepositoryURLtoNameMappings.st A Tool-Catalog.package/CatalogProject.class/class/private/pharoCurrentDottedName.st A Tool-Catalog.package/CatalogProject.class/class/private/pharoCurrentMajorName.st A Tool-Catalog.package/CatalogProject.class/class/private/pharoDistributionRepository.st M Tool-Catalog.package/CatalogProject.class/instance/accessing/allKeywords.st R Tool-Catalog.package/CatalogProject.class/instance/accessing/repository.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/repositoryName.st M Tool-Catalog.package/CatalogProject.class/instance/testing/isAvailableForCurrentPharo.st M Tool-Catalog.package/CatalogProvider.class/README.md Log Message: ----------- 50236 16214 Reput the shortcuts for browsing etc in Monticello https://pharo.fogbugz.com/f/cases/16214 16212 ChunkWriteStream doesnt understand many messages... https://pharo.fogbugz.com/f/cases/16212 16225 Adding facilities to define repositories to publish in the catalog browser https://pharo.fogbugz.com/f/cases/16225 16234 Add a button to load and create a group in Catalog Browser https://pharo.fogbugz.com/f/cases/16234 http://files.pharo.org/image/50/50236.zip

Aug. 16, 2015

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

by Tudor Girba

You will probably have more chances to get a response on the Moose mailing list. Cheers, Doru On Sun, Aug 16, 2015 at 5:58 PM, Holger Freyther <holger(a)freyther.de> 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 > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 16, 2015

PetitParser speed and cost of PPFailure

by Holger Freyther

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

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

by Sabine Manaa

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. Regards Sabine 2015-08-13 16:17 GMT+02:00 stepharo <stepharo(a)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

Morphic layoutInset: Rectangle vs Margin

by Stephan Eggermont

I only today found out why I couldn't get layoutInset: to work like in older examples: Rectangles are now forced to have normalized origin and corner. The result is that the inset tends to be at an unexpected side. Replacing the Rectangle by a Margin (and switching argument order) helps. Stephan

Aug. 16, 2015

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

by Sean P. DeNigris

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 ----- 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 Franck Warlouzet

There is also the verbose way : (ConfigurationOfXXX project version: aVersion) loadAndCreateGroupInNautilus for people who does not like to clic everywhere. Franck Date: Sun, 16 Aug 2015 16:30:18 +0200 From: stepharo(a)free.fr To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] Projects are slowly getting to live... and they will change our lifes. In latest Pharo50 when you load a configuration from versionner or from the catalog and that you say to the system to create a group in nautilus (we should add a commandline handler too) you get a project (group) with all your packages together ready to work ;) Here I loaded the ConfigurationOfMetaBoardBoard and I got the following... There are certainly improvements to do but this is a nice rethinking of groups (in fact I always wanted them like that but nautilus got them differently). So when you are a nice guy using configuration you will automatically get your nice projects at the top and you can work fast. We can imagine that the groups could also get smarter and do a lot of automatic things for us. Stef

Aug. 16, 2015

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

by stepharo

Le 16/8/15 16:26, Nicolai Hess a Ã©crit : > > > 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. this is what I thought we discussed. > > 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