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

Re: [Pharo-project] Fonts working great

by Geert

disaser seems a strong word. Nothing bad intended here, I thought the "bit of" would have softened the "user experience disaster" :) I was only referring to the fact that how system (or should they be called image?) preferences are currently managed is far from intuitive or user-friendly. The Pharo team's priorities are understandably elsewhere at the moment and it probably is more an issue which will be tackled by the Hermion project I assume? -- View this message in context: http://n2.nabble.com/Fonts-working-great-tp2466458p2641284.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 15, 2009

Re: [Pharo-project] WeakArray class>>#finalizationProcess

by Markus Fritsche

StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Strange I fixed those ones. Can you check if you have the same problem > in the latest? It could have happened that I did overwrite those by loading new PolyMorph packages. > See the other email :) Merci! > Torsten sent us a loadFFI now available in scriptLoader in one the > latest updates. > Can you check? Seems to work well. Thanks for the pointer. > If you can reproduce that with the latest (updated image). > Let us know. We are chasing bugs now. Nope, working now I think.

April 15, 2009

Re: [Pharo-project] New Pharo-dev based on 10277

by Schwab,Wilhelm K

Damien, It's nice to not be the only one nagging you for updates of Pharo-web :) However, I'm the first to admit that if comes down to running a script or two on top of Pharo-dev, that should do the job. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Cassou Sent: Wednesday, April 15, 2009 3:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] New Pharo-dev based on 10277 On Wed, Apr 15, 2009 at 7:03 AM, Geert <geert.wl.claes(a)gmail.com> wrote: > http://pharo-project.org/download > Will there be pharo-web version too? I've built a pharo-web last week. I'll build a new one beginning of May. > What is actually the planned naming scheme for the various Pharo image versions? > - Pharo-Core Pharo-Core is a coherent small set of packages on which pharo-code developers can work and which will be used for web servers. > - Pharo (Pharo-Core + IDE?) Pharo is the current pharo-dev > - Pharo-Dev (Pharo-Core + IDE + Dev tools?) pharo-dev won't exist anymore and will be renamed Pharo. > - Pharo-Web (Pharo-Core + IDE + Dev tools? + Web tools?) Is there > really a need to have both Pharo-Dev and Pharo-Web or just a Pharo-Web? I don't know what we want to do with pharo-web. -- Damien Cassou http://damiencassou.seasidehosting.st _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 15, 2009

Re: [Pharo-project] Arg assignement [Fwd: how can we sync]

by Nicolas Cellier

I published very trivials cleanups from Eliots abount Sounds package in PharoInbox I will continue reviewing tomorrow. Bye 2009/4/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Oops, I just miss the attachments :( > > 2009/4/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> >> Is there a more recent version? >> >> Nicolas >> >

April 15, 2009

[Pharo-project] About literalsDo: deprecation

by Nicolas Cellier

I notice while scanning Eliot changes that #literalsDo: is a deprecated message... But (literals do:) replacement is not neutral concerning speed. It creates an Array where literalsDo: did not. This is not a detail because this is called on each and every method when scanning code: For example, I tried this in Pharo image: Time millisecondsToRun: [SystemNavigation default allGlobalRefs] ->5356 with Eliot's literalsDo: ->8947 pharo version calling literals do: This change spoils a few minutes out of our every day work ;) Nicolas

April 15, 2009

Re: [Pharo-project] Arg assignement [Fwd: how can we sync]

by Nicolas Cellier

Oops, I just miss the attachments :( 2009/4/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > Is there a more recent version? > > Nicolas >

April 15, 2009

Re: [Pharo-project] Arg assignement [Fwd: how can we sync]

by Nicolas Cellier

I was just reviewing http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/changesets/ ...and focusing on Closure_Usage_Fix.1.cs which has not been loaded in Pharo. At first glance, I did not see changes about not writing blocks own arguments... Only changes moving some temporaries inside blocks or removing some useless ones, so as to get clean blocks. (Clean blocks which don't write into outside temps should execute faster) Is there a more recent version? Nicolas 2009/4/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > Begin forwarded message: > > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: April 2, 2009 11:09:14 PM CEDT > To: Lukas Renggli <renggli(a)iam.unibe.ch> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, Marcus Denker > <denker(a)iam.unibe.ch>, Michael Rueger <m.rueger(a)acm.org>, Adrian Lienhard > <alienhard(a)netstyle.ch>, John McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: how can we sync > > > On Thu, Mar 26, 2009 at 1:24 AM, Lukas Renggli <renggli(a)iam.unibe.ch> wrote: >> >> Something related ... >> >> In noticed that there are numerous places in the Pharo code that cannot be >> re-compiled anymore, because they assign to block parameters. There are two >> cases: >> >> 1. Things along the following example were a bug in the first place >> anyway, and can be easily fixed: >> >> aCollection inject: 0 into: [ :s :e | s := s + e ] >> >> 2. Then there are also various places where code seems to nil temps to >> avoid garbage collection issues, such as in WeakArray>>#finalizationProcess. >> >> FinalizationDependents do: >> [:weakDependent | >> weakDependent ifNotNil: >> [weakDependent finalizeValues. >> "***Following statement is required to keep >> weakDependent >> from holding onto its value as garbage.***" >> weakDependent := nil]] >> >> I think this is no longer necessary and can be fixed by simply removing >> that assignment as well, however I wanted to get a confirmation by Eliot >> before submitting a batch of fixes in various places of Pharo. > > First of all there is a preference for backward-compatibility (see > preferences category compiler). Turn on allowBlockArgumentAssignment and > the old code can still be compiled (and I believe wrks as it did (yuck)). > The bootstrap enables this preference while it is bootstrapping and then > turns it off once done so that one is discouraged from assigning to block > arguments in new code. At least that's the intent. But since we tend to > load more code than we write I guedss the intent isn't that helpful :) > Second, yes you can get rid of a number of redundant assignments that nil > arguments to prevent retention. Find attached a change set (Closure Usage > Fixes) that includes a few from my image. These either move temporaries > local to a block inside the block (useful for performance) or delete > unnecessary assignments. But beware; these changes should be compared > carefully against the Pharo image as they apply to the current state of the > Qwaq code base which could easily be incompatible. Best to compare > carefully, so to this end... > Third, I wrote a tool to automatically edit methods with method-level temps > that are only used at block level. There's a rather stupid blog post on > developing this. Stupid, because it tries to illustrate programming in the > debugger at the same time and I think it ends up beng confused. Anyway, > find the tool attached. Unsupervised usage is "TempScopeEditor edit". > There is an instance side method editNoCompile that you can use to look at > the output without applying the change, but you'll have to rte tool support > to make this useful. I have a hack for side-by-side method comparisons > based on MethodReference if you want it but I suspect you have more familiar > tools to hand. > Best regards > Eliot > > > >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 15, 2009

Re: [Pharo-project] WeakArray class>>#finalizationProcess

by StÃ©phane Ducasse

>>> > Was this conversation off-list? I can't find it here, on squeakvm or > squeak.general (or my eyes get old) ;-) I just forward it to the list. We were also checking how we can keep up with the changes of eliot. I should have a look carefully at them. >> Normally we should remove all the argument assignment. >> I just did not get the time to go over the next batch. > > Well, I would have made it on my own (the pharo web image I'm on only > complained about the progressbar and imagesegment methods), Strange I fixed those ones. Can you check if you have the same problem in the latest? > but this one > explicitly stated that WeakArray (and therefor anything "weak") > breaks if > the assignment is deleted (and it would be pointless to nil a temp > val, I > agree), so I'm curious. See the other email :) > Btw., Is there a Closure-FFI somewhere? I tried to load the vanilla > FFI-Kernel-ar.8.mcz (and thereafter fixing the ExternalType method) > but that > seriously killed my image (not sure if anything else interferred). Torsten sent us a loadFFI now available in scriptLoader in one the latest updates. Can you check? > And I > think it was the combination of WeakArrays not being weak and > something of > the FFI-package. But I'm not sure, so I don't want to rant (let's > say it > just happened coincidentally ;)). If you can reproduce that with the latest (updated image). Let us know. We are chasing bugs now. Stef

April 15, 2009

[Pharo-project] Arg assignement [Fwd: how can we sync]

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: April 2, 2009 11:09:14 PM CEDT > To: Lukas Renggli <renggli(a)iam.unibe.ch> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, Marcus Denker <denker(a)iam.unibe.ch > >, Michael Rueger <m.rueger(a)acm.org>, Adrian Lienhard <alienhard(a)netstyle.ch > >, John McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: how can we sync > > > > On Thu, Mar 26, 2009 at 1:24 AM, Lukas Renggli > <renggli(a)iam.unibe.ch> wrote: > Something related ... > > In noticed that there are numerous places in the Pharo code that > cannot be re-compiled anymore, because they assign to block > parameters. There are two cases: > > 1. Things along the following example were a bug in the first place > anyway, and can be easily fixed: > > aCollection inject: 0 into: [ :s :e | s := s + e ] > > 2. Then there are also various places where code seems to nil temps > to avoid garbage collection issues, such as in > WeakArray>>#finalizationProcess. > > FinalizationDependents do: > [:weakDependent | > weakDependent ifNotNil: > [weakDependent finalizeValues. > "***Following statement is required to keep > weakDependent > from holding onto its value as garbage.***" > weakDependent := nil]] > > I think this is no longer necessary and can be fixed by simply > removing that assignment as well, however I wanted to get a > confirmation by Eliot before submitting a batch of fixes in various > places of Pharo. > > First of all there is a preference for backward-compatibility (see > preferences category compiler). Turn on > allowBlockArgumentAssignment and the old code can still be compiled > (and I believe wrks as it did (yuck)). > > The bootstrap enables this preference while it is bootstrapping and > then turns it off once done so that one is discouraged from > assigning to block arguments in new code. At least that's the > intent. But since we tend to load more code than we write I guedss > the intent isn't that helpful :) > > Second, yes you can get rid of a number of redundant assignments > that nil arguments to prevent retention. Find attached a change set > (Closure Usage Fixes) that includes a few from my image. These > either move temporaries local to a block inside the block (useful > for performance) or delete unnecessary assignments. But beware; > these changes should be compared carefully against the Pharo image > as they apply to the current state of the Qwaq code base which could > easily be incompatible. Best to compare carefully, so to this end... > > Third, I wrote a tool to automatically edit methods with method- > level temps that are only used at block level. There's a rather > stupid blog post on developing this. Stupid, because it tries to > illustrate programming in the debugger at the same time and I think > it ends up beng confused. Anyway, find the tool attached. > Unsupervised usage is "TempScopeEditor edit". There is an instance > side method editNoCompile that you can use to look at the output > without applying the change, but you'll have to rte tool support to > make this useful. I have a hack for side-by-side method comparisons > based on MethodReference if you want it but I suspect you have more > familiar tools to hand. > > Best regards > Eliot > > > > > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > >

April 15, 2009

Re: [Pharo-project] WeakArray class>>#finalizationProcess

by Markus Fritsche

StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> There were some notes traded by Eliot, on >> WeakArray>>#finalizationProcess between Stephane, Marcus Denker, >> Michael Rueger, Adrian Lienhard on this topic between march 26th - >> April 2nd. Was this conversation off-list? I can't find it here, on squeakvm or squeak.general (or my eyes get old) ;-) > Normally we should remove all the argument assignment. > I just did not get the time to go over the next batch. Well, I would have made it on my own (the pharo web image I'm on only complained about the progressbar and imagesegment methods), but this one explicitly stated that WeakArray (and therefor anything "weak") breaks if the assignment is deleted (and it would be pointless to nil a temp val, I agree), so I'm curious. Btw., Is there a Closure-FFI somewhere? I tried to load the vanilla FFI-Kernel-ar.8.mcz (and thereafter fixing the ExternalType method) but that seriously killed my image (not sure if anything else interferred). And I think it was the combination of WeakArrays not being weak and something of the FFI-package. But I'm not sure, so I don't want to rant (let's say it just happened coincidentally ;)). Regards, Markus

April 15, 2009