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

Re: [Pharo-project] Who is maintaining the Grease configuration

by Dale Henrichs

Stef, The first thing that I ran into is that the attributes for Pharo2.0 need to be updated ... right now: ConfigurationOfGrease project attributes returns: an OrderedCollection(#common #squeakCommon #pharo #'pharo1.x' #'pharo1.4.x') Looks like SmalltalkImage>>metacelloPlatformAttributes needs to be updated to return: #(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, April 25, 2012 10:26:18 AM | Subject: Re: [Pharo-project] Who is maintaining the Grease configuration | | Thanks | I will start to add the pharo2.0.x to some configurations too. | | Stef | | > I'm the editor for the Grease configuration, so I'll take this on | > ... | > | > Dale | > | > ----- Original Message ----- | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" | > | <Pharo-project(a)lists.gforge.inria.fr> | > | Sent: Wednesday, April 25, 2012 7:37:14 AM | > | Subject: [Pharo-project] Who is maintaining the Grease | > | configuration | > | | > | Because we should create a symbolic version for 20 | > | | > | This package depends on the following classes: | > | BlockContext | > | You must resolve these dependencies before you will be able to | > | load | > | these definitions: | > | fixCallbackTemps | > | tempVarRefs | > | valueWithPossibleArguments: | > | | > | | > | | > | | |

April 25, 2012

Re: [Pharo-project] [update 2.0] #20011

by Tudor Girba

Hi, I am a bit puzzled by the current trend of 2.0. Are these additions part of the image, or will they be loaded continuously on top of a seed image? If it's the former, I thought that we discussed a while ago to keep the image to a minimum, and, in particular, to not load RB in it. Or did anything change in the meantime? Cheers, Doru On 25 Apr 2012, at 19:25, StÃ©phane Ducasse wrote: > Esteban > > are you sure that loading everything is the best move right now. > I would have started one by one. Now this is ok too just more stress. > > Stef > > On Apr 25, 2012, at 5:31 PM, Esteban Lorenzano wrote: > >> 20011 >> ----- >> >> introducing: >> >> -RPackage >> -Spec >> -Keymapping >> -Refactoring Engine >> -AST >> -Nautilus >> >> - Issue 5665: bug on new ecompletion/ocompletion >> http://code.google.com/p/pharo/issues/detail?id=5665 >> >> - Issue 5671: Polymorph fixes >> http://code.google.com/p/pharo/issues/detail?id=5671 >> > > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

April 25, 2012

Re: [Pharo-project] OSProcess - is process done?

by Sean P. DeNigris

Sean P. DeNigris wrote > > p upToEnd. "This hangs, even though there is output in the pipe" > I debugged this with the Stack VM from Jenkins. It's hanging in sqFileBasicPluginPrims.c on line 360: bytesRead = fread(dst, 1, count, file); This line seems to never return, although the docs suggest that it should just return an error or less data if the requested data is not available. HTH, Sean -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4587479.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 25, 2012

Re: [Pharo-project] Nautilus for Pharo 2.0?

by Gary Chambers

Ar, will switch once migrated our stuff from (early) 1.4... Regards, Gary ----- Original Message ----- From: "Dale Henrichs" <dhenrich(a)vmware.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 6:24 PM Subject: Re: [Pharo-project] Nautilus for Pharo 2.0? > And Nautilus looks and drives nicely (after a few minutes in Pharo2.0 > myself:) > > Dale > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, April 25, 2012 10:14:03 AM > | Subject: Re: [Pharo-project] Nautilus for Pharo 2.0? > | > | > | > | > | > | On Wed, Apr 25, 2012 at 6:20 PM, Benjamin < > | benjamin.vanryseghem.pharo(a)gmail.com > wrote: > | > | > | Since a couple of minutes, Nautilus is part of Nautilus 2.0 > | > | > | > | s/Nautilus 2.0/Pharo 2.0 > | > | ;) > | > | > | > | Ben > | > | > | > | On Apr 25, 2012, at 6:17 PM, Noury Bouraqadi wrote: > | > | > Any plans to have an auto-build on Jenkins? > | > > | > Noury > | > -- > | > http://twitter.com/#!/NouryBouraqadi > | > http://www.kroobe.com/profile/noury > | > > | > > | > Afin de contribuer au respect de l'environnement, > | > merci de n'imprimer ce courriel qu'en cas de necessite > | > > | > Please consider the environment before you print > | > > | > > | > > | > > | > | > | > | > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | >

April 25, 2012

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by StÃ©phane Ducasse

frank did you publish in the petitparser repo? because we should not lose that. Stef >>>> >>> Didn't check the code, just the tally, and I think that >>> PPSmalltalkNumberParser(PPSmalltalkNumberGrammar)>>digitsBase: is begging >>> for optimization. It's probably also the cause of the high amount of garbage >>> which causes significant amount of time spent with garbage collection. >>> It's also interesting is that the finalization process does so much work, >>> there may be something wrong with your image. >> >> Thanks for taking a look, Levente. >> >> I'd expect digitsBase: to dominate the running costs, given that we're >> parsing numbers. >> >> I do make a large number of throwaway "immutable" values with a >> Builder-like pattern... in PPSmalltalkNumberParser >> >> #makeNumberFrom:base:. That, I would imagine, could explain the >> garbage? >> >> If I may, what do you look for when reading the MessageTally? How do >> you tell, for instance, that there's excessive garbage production? >> That the incremental GCs take 7ms? (I'm reading Andreas' comments on >> http://wiki.squeak.org/squeak/4210 again.) > > Levente, you're quite right: #digitsBase: has now been optimised even > more, reducing the time taken to run my benchmark > > MessageTally spyOn: [Time millisecondsToRun: [100000 timesRepeat: > [PPSmalltalkNumberParser parse: '1234567890']]] > > from ~32 seconds to ~16 seconds. (Memoising was the answer: > #digitsBase: is effectively a higher-order production and, like OMeta, > PPCompositeParser doesn't memoise those. A simple class var dictionary > solves that problem. > > frank > >> frank >> >>> Levente >>> >>> >>>> >>>> frank >>>> >>>> On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>> >>>>> On 3 September 2011 19:35, Nicolas Cellier >>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>> >>>>>> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >>>>>>> >>>>>>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>>> >>>>>>>> I think it is a good idea to have the number parser separate, after >>>>>>>> all it might also make sense to use it separately. >>>>>>>> >>>>>>>> It seems that the new Smalltalk grammar is significantly slower. The >>>>>>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the >>>>>>>> source code of the collection hierarchy and does not especially target >>>>>>>> number literals runs 30% slower. >>>>>>>> >>>>>>>> Also I see that "Number readFrom: ..." is still used within the >>>>>>>> grammar. This seems to be a bit strange, no? >>>>>>> >>>>>>> >>>>>>> Yes: it's a double-parse, which is a bit lame. First, we parse the >>>>>>> literal with PPSmalltalkNumberParser, which ensures that the thing >>>>>>> given to Number class >> #readFrom: is a well-formed token (so, in >>>>>>> particular, Squeak's Number doesn't get to see anything other than a >>>>>>> well-formed token). >>>>>>> >>>>>>> It sounds like you're happy with the basic concept, so maybe I should >>>>>>> remove the Number class >> #readFrom: stuff, see if I can't remove the >>>>>>> performance issues, and resubmit the patch. >>>>>>> >>>>>>> frank >>>>>>> >>>>>> >>>>>> Yes, a NumberParser is essentially parsing, and this duplication sounds >>>>>> useless. >>>>>> The main feature of interest in NumberParser that I consider a >>>>>> requirement and should find its equivalence in a PetitNumberParser is: >>>>>> - round a decimal representation to nearest Float >>>>>> It's simple, just convert a Fraction asFloat in a single final step to >>>>>> avoid cumulating round off errors - see >>>>>> #makeFloatFromMantissa:exponent:base: >>>>>> >>>>>> The second feature of interest in NumberParser is the ability to >>>>>> parser LargeInteger efficiently by avoiding (10 * largeValue + >>>>>> digitValue) loops, and replacing them with a log(n) cost. >>>>>> This would be a simple thing to implement in a functional language. >>>>> >>>>> >>>>> Hopefully this won't offend your sensibilities too much :). It does, >>>>> in fact, use 10* loops - I wrote an experimental "front half * rear >>>>> half" recursion, which was slower in my benchmarks. >>>>> >>>>> This version has the grammar and parser doing no string->number >>>>> conversion at all. PPSmalltalkNumberMaker supplies a number of utility >>>>> methods designed to stop one from making malformed numbers. It also >>>>> supplies a builder interface that the parser uses to construct >>>>> numbers. >>>>> >>>>> frank >>>>> >>>>>> Nicolas >>>>>> >>>>>>>> Lukas >>>>>>>> >>>>>>>> >>>>>>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> On 3 September 2011 16:51, Frank Shearar <frank.shearar(a)gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Lukas, >>>>>>>>>>> >>>>>>>>>>> I haven't :) mainly because I'm unsure where to put it - is there >>>>>>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or >>>>>>>>>>> what's >>>>>>>>>>> your preference? (How about an mcd between my merge and PP's head?) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just put the .mcz at some public URL (dropbox, squeak source, ...) >>>>>>>>>> or >>>>>>>>>> attach it to a mail. >>>>>>>>> >>>>>>>>> >>>>>>>>> Ah, great - here it is. You'll see I've written the grammar as a >>>>>>>>> separate class. That was really more to make what I'd done more >>>>>>>>> obvious and to minimise the change to PPSmalltalkGrammar, but perhaps >>>>>>>>> it's not a bad idea anyway: it's easy to see the number literal >>>>>>>>> subgrammar. >>>>>>>>> >>>>>>>>> frank >>>>>>>>> >>>>>>>>>> Lukas >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lukas Renggli >>>>>>>>>> www.lukas-renggli.ch >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Lukas Renggli >>>>>>>> www.lukas-renggli.ch >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> > <PetitSmalltalk-fbs.63.mcz>

April 25, 2012

Re: [Pharo-project] Who is maintaining the Grease configuration

by StÃ©phane Ducasse

April 25, 2012

Re: [Pharo-project] [update 2.0] #20011

by StÃ©phane Ducasse

Esteban are you sure that loading everything is the best move right now. I would have started one by one. Now this is ok too just more stress. Stef On Apr 25, 2012, at 5:31 PM, Esteban Lorenzano wrote: > 20011 > ----- > > introducing: > > -RPackage > -Spec > -Keymapping > -Refactoring Engine > -AST > -Nautilus > > - Issue 5665: bug on new ecompletion/ocompletion > http://code.google.com/p/pharo/issues/detail?id=5665 > > - Issue 5671: Polymorph fixes > http://code.google.com/p/pharo/issues/detail?id=5671 >

April 25, 2012

Re: [Pharo-project] Nautilus for Pharo 2.0?

by Dale Henrichs

April 25, 2012

Re: [Pharo-project] Nautilus for Pharo 2.0?

by Mariano Martinez Peck

On Wed, Apr 25, 2012 at 6:20 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Since a couple of minutes, Nautilus is part of Nautilus 2.0 > > s/Nautilus 2.0/Pharo 2.0 ;) > > Ben > > On Apr 25, 2012, at 6:17 PM, Noury Bouraqadi wrote: > > > Any plans to have an auto-build on Jenkins? > > > > Noury > > -- > > http://twitter.com/#!/NouryBouraqadi > > http://www.kroobe.com/profile/noury > > > > > > Afin de contribuer au respect de l'environnement, > > merci de n'imprimer ce courriel qu'en cas de necessite > > > > Please consider the environment before you print > > > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 25, 2012

Re: [Pharo-project] initialize

by Benjamin

Probably a problem with the icon cache. When it happens try to close the browser and to reopen it. You can also use the DEBUG menu to flush the cache. I have experienced such bugs from time to time, but with no clear way to reproduce it :s Thanks for your feedback :) Ben On Apr 25, 2012, at 6:34 PM, blake wrote: > OK, > > So, I'm writing a class and I have an initialize method. Well, I have > two, actually, a class initialize and an instance initialize. And when > I save it, the Nautilus browser shows it with a red flag in the gutter > next to the instance method "initialize". > > And sure enough, instead of being called when I crate a new instance, > the superclass' initialize is called instead. I can't figure it out. I > have other classes that are virtually identical, structurally and they > don't have the problem. > > So I remove the instance initialize method and then paste it back in. > Red flag is gone, instance initialize is now being called. And instead > of the red flag I get a green override arrow. > > What happened? > > ===Blake=== >

April 25, 2012