April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

On 15 April 2013 16:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 15 April 2013 16:32, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> On Apr 15, 2013, at 3:25 PM, Igor Stasenko wrote: >> >>> On 15 April 2013 12:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>> On Apr 13, 2013, at 12:16 AM, Igor Stasenko wrote: >>>> >>>>> >>>>> But that's fine.. now look at >>>>> >>>>> secondsWhenClockTicks >>>>> >>>>> "waits for the moment when a new second begins" >>>>> >>>>> | lastSecond | >>>>> >>>>> lastSecond := self primSecondsClock. >>>>> [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay >>>>> forMilliseconds: 1) wait ]. >>>>> >>>>> ^ lastSecond + 1 >>>>> >>>>> that is complete nonsense. Sorry. >>>>> >>>>> This code relying on primSecondsClock resolution, which is..... (drum >>>>> roll..... ) >>>>> 1 second.. >>>>> >>>>> then it is combined with millisecondClockValue , as you see later to get >>>>> system time with millisecond precision.. >>>>> >>>>> I am not genius in math and physics.. but even i understand that if >>>>> you measurement has error X >>>>> you cannot get more precision than X, even if you combine it with >>>>> another measurement with higher precision. >>>>> >>>>> (But i can be wrong with that.. if so, please explain why) >>>> >>>> Because, as Levente said in code, resolution != accuracy. >>>> When you measure a single sample, sure, that value has an error of max resolution / 2. >>>> But when you measure when that value _changes_, you have an error of the underlying accuracy / 2. >>>> Clock s value: 1 2 >>>> resolution: |_______|_______| >>>> accuracy: ||||||||||||||||||||||||||||||||||| >>>> ^ >>>> Here's to hoping the above ascii art(?) worked! >>>> >>>> So no, that method is not complete nonsense. >>>> >>> Okay. >>> Now i rewriting the code which uses new primitive (primUTCMicrosecondClock), >>> and then we will no longer need this startup logic nor wrap around >>> check & other gory details... >>> just use a primitive. >> >> Sounds clearer, yes. >> >> However, be aware, at least on my VM: >> [Time millisecondClockValue] bench '34,600,000 per second.' >> [Time primUTCMicrosecondClock] bench '12,400,000 per second.' >> >> Which in my case translated to that in a Time2 class with #now defined: >> now >> >> | microSecondsToday | >> microSecondsToday := self primUTCMicrosecondClock \\ 86400000000. >> ^ self seconds: microSecondsToday // 1000000 nanoSeconds: microSecondsToday * 1000 >> >> and changing the relatively low-hanging fruit in standard Time (removing Duration creation and other crap): >> >> seconds: seconds nanoSeconds: nanoCount >> "Answer a Time from midnight." >> >> ^ self basicNew >> seconds: seconds nanoSeconds: nanoCount >> >> To benchmarks that looked like this: >> "Old code" >> [Time now ] bench '7,330,000 per second.' '7,280,000 per second.' '7,170,000 per second.' >> "Using microsecondClock every call" >> [Time2 now ] bench '2,280,000 per second.''2,300,000 per second.' '2,180,000 per second.' >> >> Also note, Time2 lacked translation to Local time, which would be needed for consistency with Time now. >> > > Well, i am not started modifying Time now, (will start in couple minutes ;) > but here results of DateAndTime now > before and after: > > before: > > > [ DateAndTime now ] bench '316,000 per second.' > > after: > > [ DateAndTime now ] bench '414,000 per second.' > > > with Time now, i think even if it will be "2,300,000" answers per second, > it is fairly acceptable , when accuracy of primitive is 1 microsecond, > you actually don't need more than 1 million answers per second, or you > will receive same answers. > > But aside of it, may i ask, why performance is so important/critical > for those? What is use case? > everything is good in comparison: [ self yourself ] bench '58,800,000 per second.' does nothing and just 25 times faster.. than Time now, so what is the point? :) -- Best regards, Igor Stasenko.

April 15, 2013

Re: [Pharo-project] SelectPackageBrowser

by stephane ducasse

So we should extract it :) No duplication. Stef > +1 > I needed the selectPackageBrowser for the Tree coverage tool and I had to duplicate code because it was in code critics browser and not external. > > > 2013/4/15 stephane ducasse <stephane.ducasse(a)free.fr> > Indeed Merlin would be useful. > I cleaned it a bit when migrating to smalltalkhub. > > Stef > > > I want to extract SelectPackageBrowser as a general PackagePicker widget. > > It's part of the CriticsBrowser setup wizard, in which there is no wizard > > object, but rather each page deletes itself and opens the next one in the > > world. Could Merlin be helpful here? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/SelectPackageBrowser-tp4681590.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

April 15, 2013

Re: [Pharo-project] Versionner in 2.0 again

by stephane ducasse

On Apr 15, 2013, at 4:30 PM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi Norbert, > > I just add a look at your changes. > In my opinion, all stuff related to ConfigurationBaseName shouldn't be changed. The root of the problem is the Metacello ToolBox version. > I added a new configuration for Versionner (in ss3) for Pharo2. I tested it a bit and it looks fine. Thanks for your time. We should produce a bug fix for Pharo 20. > What you need : > 1/ Load (don't merge) Metacello-ToolBox-dkh.130 from http://seaside.gemstone.com/ss/metacello in your Pharo2 image. > 2/ Load ConfigurationOfVersionner from http://ss3.gemstone.com/ss/Versionner > 3/ ConfigurationOfVersionner load > > Let me know if it solves your issues. > > Regards, > Christophe. > > > Le 11 avr. 2013 Ã 17:40, Christophe Demarey a Ã©crit : > >> Hi Norbert, >> >> Sorry, I don't read Pharo ML every day else I will never have time to work on Versionner... I only have a part time to do that. >> What I'm doing on Versionner is to add the possibility to update your configurations at a very fine grained (add/remove projects/packages/groups). This version is a WIP and not yet usable. I'm not so far to have one version open for beta-test but I now face issues with Metacello on Pharo2 and some missing API in the toolbox. >> >> That's why I'm now working to have Metacello tests green on Pharo2. >> What I'm doing: >> update builderCi (used by Dale to test Metacello on Travis) to support Pharo2/3 : almost done >> be able to load MetacelloPreview on Pharo2/3 >> have green tests. >> >> With a clean and up to date metacello environment for Pharo, I will be able to focus on Versionner and have a result soon. >> >> I also did not take time to port the "old" Versionner on Pharo2 since I will face the same issues with Metacello/Pharo2. >> The problem is not really Versionner itself but the fact that it relies on libraries not tested and not fully working on Pharo2. >> >> I will take a look at your work. (some comments below). >> >> Thanks for your contribution. >> >> Regards, >> Christophe. >> >> >> Le 11 avr. 2013 Ã 13:18, Norbert Hartl a Ã©crit : >> >>> Huh, I find it strange that nobody cares. Does anybody use Versionner? >>> >>> Norbert >>> >>> >>> Am 09.04.2013 um 11:31 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>>> Yesterday I tried again to use Versionner in 2.0 but did have much success. So I tried myself (because I think Versionner is important) and could final generate a new version of my project using versionner. >>>> >>>> Following things I noticed (I'm writing this because I'm not sure which issue to open for what package. I'm just want opinions and after that I can open/upload whatever): >>>> >>>> I loaded Versionner from Metacello (taken from [1]) >>>> >>>> Gofer new >>>> url: 'http://ss3.gemstone.com/ss/Versionner'; >>>> package: 'ConfigurationOfVersionner'; >>>> load. >>>> (Smalltalk at: #ConfigurationOfVersionner) perform: #load >>>> >>>> monticello issues >>>> ============= >>>> >>>> While updating the rest of the packages to the newest I saw that >>>> >>>> Versionner-Core-Model-ChristopheDemarey.19 >>>> >>>> has an older ancestor for fixing something for pharo 1.4. The package >>>> >>>> Versionner-Core-Model-ChristopheDemarey.20 >>>> >>>> merged the packages back to HEAD but reverted some things like SystemAnnouncer back to SystemChangeNotifier. >> >> I tried to switch at a time to Pharo2 but too many issues. So I switched back to Pharo1.4 to be able to work on Versionner. >> >>>> So I'm using >>>> >>>> Versionner-Core-Model-ChristopheDemarey.18 >>>> and >>>> Versionner-Core-Commands-ChristopheDemarey.17 >>>> >>>> as older packages. Any other package is the newest in the repository. >> >> I will check that you don't have useless parts of the new Versionner. >> As it is difficult to maintain branches with Monticello, I moved new Versionner developments to Smalltalkhub. >> >>>> metacello toolbox issues >>>> ================== >>>> >>>> I don't know much about metacello toolbox but the separation of files into ConfigurationOf and Baseline seems to have potential for confusion. >> >> ConfigurationOf and Baseline are introduced by newest version of Metacello that the one shipped with Pharo2. >> >>>> There is a notion of a basename so it can build ConfigurationOfMyProject as well as BaselineOfMyProject (MyProject being the basename). But in the MetacelloToolbox in the pharo2.0 repository it does not seem right. I had to change the code to use (MBToolbox baseNameOf: â¦) at a few places. I took orientation from the message signature. If a method expects a configurationBaseName and the sender used the configuration class I changed it. I'll attach the mcz for now to this mail until it is clear what to do. >> >> What is the version of Metacello and Metacello Toolbox you loaded? >> >>>> versionner issues >>>> ============= >>>> >>>> At one place I added a metacello toolbox name conversion because it made sense to make it there. The other thing I had to fix is a method notification that takes the wrong entity from an announcement. >> >> I also fixed that for the new version. >> >>>> Both packages attached as I don't have commit rights and don't know where the issue tracker for versionner is if there is any) >>>> >>>> I would be glad if any of you guys that know about that stuff could drop me a note if this is ok or where I've gone wrong. >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> >>>> [1] http://users.dcc.uchile.cl/~jsandova/versionner/ >>>> >>>> <Metacello-ToolBox-NorbertHartl.136.mcz> >>>> <Versionner-Core-Commands-NorbertHartl.18.mcz> >>>> <Versionner-Core-Model-NorbertHartl.19.mcz> >>> >> >

April 15, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

On 15 April 2013 16:32, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 15, 2013, at 3:25 PM, Igor Stasenko wrote: > >> On 15 April 2013 12:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On Apr 13, 2013, at 12:16 AM, Igor Stasenko wrote: >>> >>>> >>>> But that's fine.. now look at >>>> >>>> secondsWhenClockTicks >>>> >>>> "waits for the moment when a new second begins" >>>> >>>> | lastSecond | >>>> >>>> lastSecond := self primSecondsClock. >>>> [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay >>>> forMilliseconds: 1) wait ]. >>>> >>>> ^ lastSecond + 1 >>>> >>>> that is complete nonsense. Sorry. >>>> >>>> This code relying on primSecondsClock resolution, which is..... (drum >>>> roll..... ) >>>> 1 second.. >>>> >>>> then it is combined with millisecondClockValue , as you see later to get >>>> system time with millisecond precision.. >>>> >>>> I am not genius in math and physics.. but even i understand that if >>>> you measurement has error X >>>> you cannot get more precision than X, even if you combine it with >>>> another measurement with higher precision. >>>> >>>> (But i can be wrong with that.. if so, please explain why) >>> >>> Because, as Levente said in code, resolution != accuracy. >>> When you measure a single sample, sure, that value has an error of max resolution / 2. >>> But when you measure when that value _changes_, you have an error of the underlying accuracy / 2. >>> Clock s value: 1 2 >>> resolution: |_______|_______| >>> accuracy: ||||||||||||||||||||||||||||||||||| >>> ^ >>> Here's to hoping the above ascii art(?) worked! >>> >>> So no, that method is not complete nonsense. >>> >> Okay. >> Now i rewriting the code which uses new primitive (primUTCMicrosecondClock), >> and then we will no longer need this startup logic nor wrap around >> check & other gory details... >> just use a primitive. > > Sounds clearer, yes. > > However, be aware, at least on my VM: > [Time millisecondClockValue] bench '34,600,000 per second.' > [Time primUTCMicrosecondClock] bench '12,400,000 per second.' > > Which in my case translated to that in a Time2 class with #now defined: > now > > | microSecondsToday | > microSecondsToday := self primUTCMicrosecondClock \\ 86400000000. > ^ self seconds: microSecondsToday // 1000000 nanoSeconds: microSecondsToday * 1000 > > and changing the relatively low-hanging fruit in standard Time (removing Duration creation and other crap): > > seconds: seconds nanoSeconds: nanoCount > "Answer a Time from midnight." > > ^ self basicNew > seconds: seconds nanoSeconds: nanoCount > > To benchmarks that looked like this: > "Old code" > [Time now ] bench '7,330,000 per second.' '7,280,000 per second.' '7,170,000 per second.' > "Using microsecondClock every call" > [Time2 now ] bench '2,280,000 per second.''2,300,000 per second.' '2,180,000 per second.' > > Also note, Time2 lacked translation to Local time, which would be needed for consistency with Time now. > Well, i am not started modifying Time now, (will start in couple minutes ;) but here results of DateAndTime now before and after: before: [ DateAndTime now ] bench '316,000 per second.' after: [ DateAndTime now ] bench '414,000 per second.' with Time now, i think even if it will be "2,300,000" answers per second, it is fairly acceptable , when accuracy of primitive is 1 microsecond, you actually don't need more than 1 million answers per second, or you will receive same answers. But aside of it, may i ask, why performance is so important/critical for those? What is use case? > Cheers, > Henry -- Best regards, Igor Stasenko.

April 15, 2013

Re: [Pharo-project] SelectPackageBrowser

by ClÃ©ment Bera

+1 I needed the selectPackageBrowser for the Tree coverage tool and I had to duplicate code because it was in code critics browser and not external. 2013/4/15 stephane ducasse <stephane.ducasse(a)free.fr> > Indeed Merlin would be useful. > I cleaned it a bit when migrating to smalltalkhub. > > Stef > > > I want to extract SelectPackageBrowser as a general PackagePicker widget. > > It's part of the CriticsBrowser setup wizard, in which there is no wizard > > object, but rather each page deletes itself and opens the next one in the > > world. Could Merlin be helpful here? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/SelectPackageBrowser-tp4681590.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 15, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Henrik Johansen

On Apr 15, 2013, at 3:25 PM, Igor Stasenko wrote: > On 15 April 2013 12:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> On Apr 13, 2013, at 12:16 AM, Igor Stasenko wrote: >> >>> >>> But that's fine.. now look at >>> >>> secondsWhenClockTicks >>> >>> "waits for the moment when a new second begins" >>> >>> | lastSecond | >>> >>> lastSecond := self primSecondsClock. >>> [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay >>> forMilliseconds: 1) wait ]. >>> >>> ^ lastSecond + 1 >>> >>> that is complete nonsense. Sorry. >>> >>> This code relying on primSecondsClock resolution, which is..... (drum >>> roll..... ) >>> 1 second.. >>> >>> then it is combined with millisecondClockValue , as you see later to get >>> system time with millisecond precision.. >>> >>> I am not genius in math and physics.. but even i understand that if >>> you measurement has error X >>> you cannot get more precision than X, even if you combine it with >>> another measurement with higher precision. >>> >>> (But i can be wrong with that.. if so, please explain why) >> >> Because, as Levente said in code, resolution != accuracy. >> When you measure a single sample, sure, that value has an error of max resolution / 2. >> But when you measure when that value _changes_, you have an error of the underlying accuracy / 2. >> Clock s value: 1 2 >> resolution: |_______|_______| >> accuracy: ||||||||||||||||||||||||||||||||||| >> ^ >> Here's to hoping the above ascii art(?) worked! >> >> So no, that method is not complete nonsense. >> > Okay. > Now i rewriting the code which uses new primitive (primUTCMicrosecondClock), > and then we will no longer need this startup logic nor wrap around > check & other gory details... > just use a primitive. Sounds clearer, yes. However, be aware, at least on my VM: [Time millisecondClockValue] bench '34,600,000 per second.' [Time primUTCMicrosecondClock] bench '12,400,000 per second.' Which in my case translated to that in a Time2 class with #now defined: now | microSecondsToday | microSecondsToday := self primUTCMicrosecondClock \\ 86400000000. ^ self seconds: microSecondsToday // 1000000 nanoSeconds: microSecondsToday * 1000 and changing the relatively low-hanging fruit in standard Time (removing Duration creation and other crap): seconds: seconds nanoSeconds: nanoCount "Answer a Time from midnight." ^ self basicNew seconds: seconds nanoSeconds: nanoCount To benchmarks that looked like this: "Old code" [Time now ] bench '7,330,000 per second.' '7,280,000 per second.' '7,170,000 per second.' "Using microsecondClock every call" [Time2 now ] bench '2,280,000 per second.''2,300,000 per second.' '2,180,000 per second.' Also note, Time2 lacked translation to Local time, which would be needed for consistency with Time now. Cheers, Henry

April 15, 2013

Re: [Pharo-project] Versionner in 2.0 again

by Christophe Demarey

Hi Norbert, I just add a look at your changes. In my opinion, all stuff related to ConfigurationBaseName shouldn't be changed. The root of the problem is the Metacello ToolBox version. I added a new configuration for Versionner (in ss3) for Pharo2. I tested it a bit and it looks fine. What you need : 1/ Load (don't merge) Metacello-ToolBox-dkh.130 from http://seaside.gemstone.com/ss/metacello in your Pharo2 image. 2/ Load ConfigurationOfVersionner from http://ss3.gemstone.com/ss/Versionner 3/ ConfigurationOfVersionner load Let me know if it solves your issues. Regards, Christophe. Le 11 avr. 2013 Ã 17:40, Christophe Demarey a Ã©crit : > Hi Norbert, > > Sorry, I don't read Pharo ML every day else I will never have time to work on Versionner... I only have a part time to do that. > What I'm doing on Versionner is to add the possibility to update your configurations at a very fine grained (add/remove projects/packages/groups). This version is a WIP and not yet usable. I'm not so far to have one version open for beta-test but I now face issues with Metacello on Pharo2 and some missing API in the toolbox. > > That's why I'm now working to have Metacello tests green on Pharo2. > What I'm doing: > update builderCi (used by Dale to test Metacello on Travis) to support Pharo2/3 : almost done > be able to load MetacelloPreview on Pharo2/3 > have green tests. > > With a clean and up to date metacello environment for Pharo, I will be able to focus on Versionner and have a result soon. > > I also did not take time to port the "old" Versionner on Pharo2 since I will face the same issues with Metacello/Pharo2. > The problem is not really Versionner itself but the fact that it relies on libraries not tested and not fully working on Pharo2. > > I will take a look at your work. (some comments below). > > Thanks for your contribution. > > Regards, > Christophe. > > > Le 11 avr. 2013 Ã 13:18, Norbert Hartl a Ã©crit : > >> Huh, I find it strange that nobody cares. Does anybody use Versionner? >> >> Norbert >> >> >> Am 09.04.2013 um 11:31 schrieb Norbert Hartl <norbert(a)hartl.name>: >> >>> Yesterday I tried again to use Versionner in 2.0 but did have much success. So I tried myself (because I think Versionner is important) and could final generate a new version of my project using versionner. >>> >>> Following things I noticed (I'm writing this because I'm not sure which issue to open for what package. I'm just want opinions and after that I can open/upload whatever): >>> >>> I loaded Versionner from Metacello (taken from [1]) >>> >>> Gofer new >>> url: 'http://ss3.gemstone.com/ss/Versionner'; >>> package: 'ConfigurationOfVersionner'; >>> load. >>> (Smalltalk at: #ConfigurationOfVersionner) perform: #load >>> >>> monticello issues >>> ============= >>> >>> While updating the rest of the packages to the newest I saw that >>> >>> Versionner-Core-Model-ChristopheDemarey.19 >>> >>> has an older ancestor for fixing something for pharo 1.4. The package >>> >>> Versionner-Core-Model-ChristopheDemarey.20 >>> >>> merged the packages back to HEAD but reverted some things like SystemAnnouncer back to SystemChangeNotifier. > > I tried to switch at a time to Pharo2 but too many issues. So I switched back to Pharo1.4 to be able to work on Versionner. > >>> So I'm using >>> >>> Versionner-Core-Model-ChristopheDemarey.18 >>> and >>> Versionner-Core-Commands-ChristopheDemarey.17 >>> >>> as older packages. Any other package is the newest in the repository. > > I will check that you don't have useless parts of the new Versionner. > As it is difficult to maintain branches with Monticello, I moved new Versionner developments to Smalltalkhub. > >>> metacello toolbox issues >>> ================== >>> >>> I don't know much about metacello toolbox but the separation of files into ConfigurationOf and Baseline seems to have potential for confusion. > > ConfigurationOf and Baseline are introduced by newest version of Metacello that the one shipped with Pharo2. > >>> There is a notion of a basename so it can build ConfigurationOfMyProject as well as BaselineOfMyProject (MyProject being the basename). But in the MetacelloToolbox in the pharo2.0 repository it does not seem right. I had to change the code to use (MBToolbox baseNameOf: â¦) at a few places. I took orientation from the message signature. If a method expects a configurationBaseName and the sender used the configuration class I changed it. I'll attach the mcz for now to this mail until it is clear what to do. > > What is the version of Metacello and Metacello Toolbox you loaded? > >>> versionner issues >>> ============= >>> >>> At one place I added a metacello toolbox name conversion because it made sense to make it there. The other thing I had to fix is a method notification that takes the wrong entity from an announcement. > > I also fixed that for the new version. > >>> Both packages attached as I don't have commit rights and don't know where the issue tracker for versionner is if there is any) >>> >>> I would be glad if any of you guys that know about that stuff could drop me a note if this is ok or where I've gone wrong. >>> >>> thanks, >>> >>> Norbert >>> >>> >>> [1] http://users.dcc.uchile.cl/~jsandova/versionner/ >>> >>> <Metacello-ToolBox-NorbertHartl.136.mcz> >>> <Versionner-Core-Commands-NorbertHartl.18.mcz> >>> <Versionner-Core-Model-NorbertHartl.19.mcz> >> >

April 15, 2013

Re: [Pharo-project] WhatsUp from: 2013-04-15 until: 2013-04-30

by Frank Shearar

On 15 April 2013 15:15, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 15/04/2013 15:57, Frank Shearar a Ã©crit : > >> On 15 April 2013 14:44, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>> Le 15/04/2013 15:30, stephane ducasse a Ã©crit : >>> >>>>>> >>>>> >>>>> Porting SmaCC on 2.0 >>>> >>>> >>>> nice. If you need an integration server. >>>> >>>>> Writing configurations for AltBrowser and Jejak. >>>> >>>> >>>> nice too >>>> >>>>> Started looking at Marpa >>>> >>>> >>>> what is it? >>> >>> >>> >>> A nice, more general way of parsing Context Free Grammars with a better >>> algorithm not restricted to LR(k) grammars (see >>> http://jeffreykegler.github.io/Marpa-web-site/) >>> >>> I'd really like to make it a pure Smalltalk parser, to be able to study >>> the >>> underlying algorithm. And SmaCC already has some infrastructure to handle >>> that, like a grammar parser (as well as the Scanner infrastructure). >>> >>> The promise of parsing with any CFG grammar (and all LR(k) grammars in >>> linear time) is convincing. >> >> >> There are several algorithms that can do this (handling all CFGs, >> including ambiguous grammars): Marpa uses a derivative of the Earley >> parser, and there's GLL [1] and parsing with derivatives [2][3]. > > > Cool. We'll have a look to see which one will make it (or simply works). All > of them seems to be a fair and interesting step above the usual... > > >> frank >> >> [1] https://github.com/djspiewak/gll-combinators >> [2] http://matt.might.net/articles/parsing-with-derivatives/ >> [3] http://ss3.gemstone.com/ss/ParsingDerivatives.html (still a while >> to go before it's production ready!) > > > I'll have a look at the last one in particular :) I'd be grateful for any feedback. One thing that's sorely lacking is documentation. I am also experimenting with some... non-standard approaches to writing Smalltalk. But the affected portions (DerivingParser class >> #deriverBlock, #parseNullBlock, #isEmptyBlock) could pretty easily be rewritten to be more standard, but at the loss of concentrating the various algorithms together in one place. frank > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

April 15, 2013

Re: [Pharo-project] WhatsUp from: 2013-04-15 until: 2013-04-30

by Goubier Thierry

Le 15/04/2013 15:57, Frank Shearar a Ã©crit : > On 15 April 2013 14:44, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> Le 15/04/2013 15:30, stephane ducasse a Ã©crit : >> >>>>> >>>> >>>> Porting SmaCC on 2.0 >>> >>> nice. If you need an integration server. >>> >>>> Writing configurations for AltBrowser and Jejak. >>> >>> nice too >>> >>>> Started looking at Marpa >>> >>> what is it? >> >> >> A nice, more general way of parsing Context Free Grammars with a better >> algorithm not restricted to LR(k) grammars (see >> http://jeffreykegler.github.io/Marpa-web-site/) >> >> I'd really like to make it a pure Smalltalk parser, to be able to study the >> underlying algorithm. And SmaCC already has some infrastructure to handle >> that, like a grammar parser (as well as the Scanner infrastructure). >> >> The promise of parsing with any CFG grammar (and all LR(k) grammars in >> linear time) is convincing. > > There are several algorithms that can do this (handling all CFGs, > including ambiguous grammars): Marpa uses a derivative of the Earley > parser, and there's GLL [1] and parsing with derivatives [2][3]. Cool. We'll have a look to see which one will make it (or simply works). All of them seems to be a fair and interesting step above the usual... > frank > > [1] https://github.com/djspiewak/gll-combinators > [2] http://matt.might.net/articles/parsing-with-derivatives/ > [3] http://ss3.gemstone.com/ss/ParsingDerivatives.html (still a while > to go before it's production ready!) I'll have a look at the last one in particular :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 15, 2013

Re: [Pharo-project] Stroke of genius

by Sven Van Caekenberghe

On 15 Apr 2013, at 15:58, Norbert Hartl <norbert(a)hartl.name> wrote: > Am 15.04.2013 um 15:46 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >> >>> Sven Van Caekenberghe-2 wrote >>>> the little fact that it is incremental - it updates and saves the same >>>> image based on 1 metacello configuration - is really a stroke of genius. >>>> It saves an enormous amount of time as in the past I always did a complete >>>> build from scratch. Updating servers is now really a joy. >>> >>> Sounds great! And, I don't exactly understand ;) Can you say more about that feature? >> >> Building a new image goes like this >> >> $ ./vm.sh Pharo.image save test >> >> $ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX >> >> The Pharo.image is 'empty' as far as your own code is concerned, the config loads lots of dependencies. A build takes 10 minutes or so. >> >> But the next time, you can do only the second part >> >> $ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX >> >> The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds. >> >> It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around. >> > This is less reliable than building from scratch. If you only build your own packages without a lot of external packages that might go well. If there are external dependencies it can even be that not loading it from scratch will get you a different package set installed in your image afterwards. So you should build from scratch from time to time anyway. > > For the config handler I don't see a reason why a config option should overwrite the existing image by default. Without extra options I don't even see why the image should shutdown after loading the config. Is it how it is? That looks like there are too many assumptions taken from the commandline handlers. > > Norbert Yes, of course, sometimes, especially when you suspect strange loading problems, it is a good idea to start from scratch. But in general that is not needed, IMHO. Hence the default is good. Using the 'save' command handler you can easily and quickly mimic the other behaviour. Note also that normally, the external dependencies will change much more slowly than your own code. Sven

April 15, 2013