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

[Pharo-project] The System Package
by Alexandre Bergel April 16, 2009

April 16, 2009

Dear All, It seems that the class category 'System' is registered as a package and each System-XXX category is both a package and a class category. As a consequence, System is a package that contains sub-packages, and 'System-Object Storage' is listed as a package. I suggest that package name should never contain a '-'. This require quite some discipline to not mess up the thing. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4

[Pharo-project] Arg assignement [Fwd: how can we sync]
by StÃ©phane Ducasse April 16, 2009

April 16, 2009

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

2 8

[Pharo-project] New event Sensor
by StÃ©phane Ducasse April 16, 2009

April 16, 2009

Mike is it safe to use System-Support (what will happen to inputSensor). Stef

2 2

[Pharo-project] Fonts working great
by Damien Cassou April 16, 2009

April 16, 2009

Hi, I've set-up the following script (based on a previous message in this list) for people using a recent VM and having DejaVu: |font codeFont| font := LogicalFont familyName: 'DejaVu Serif' pointSize: 10. codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. Preferences setListFontTo: font. Preferences setMenuFontTo: font. Preferences setCodeFontTo: codeFont. Preferences setButtonFontTo: font. Preferences setSystemFontTo: font. font := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. Preferences setWindowTitleFontTo: font. -- Damien Cassou http://damiencassou.seasidehosting.st

9 19

[Pharo-project] Issue 722: some methods missing in BlockClosure
by Nicolas Cellier April 15, 2009

April 15, 2009

I added missing methods for issue http://code.google.com/p/pharo/issues/detail?id=722 in PhaoInbox/Services-Base-nice.48 and PharoInbox/Kernel-nice.renggli.289 (I did not make a SLICE) These two preserve author name and date from BlockContext since they are pure copies of code. PharoInbox/Kernel-nice.renggli.289 also merge PharoInbox/Kernel-nice.renggli.288 which solve http://code.google.com/p/pharo/issues/detail?id=726 (missing BlockClosure>>#sender) It does not merge Michael changes about events. Nicolas

2 1

[Pharo-project] #decompileBlock: eats names of block arguments
by Dennis Schetinin April 15, 2009

April 15, 2009

*[:a :b | a+b] decompile decompileString * gives *'[:t1 :t2 | t1 + t2]'* (The same thing when I decompile block defined in method) (In *#decompileBlock:*) the branch *method fileIndex ~~ 0 ifTrue: [...]* finds all tempVar names including block's arguments but then they are eaten by *self initSymbols: homeClass* where only tempVars defined by method itself survive... ... and I don't know how to fix it... -- Dennis Schetinin

3 3

[Pharo-project] Compiler class>>closureParserClass
by Alexandr Batalshikov April 15, 2009

April 15, 2009

Hi, I see in pharo0.1-10268dev09.04.1.image: Compiler class>>closureParserClass ^self error: 'not installed'. That is right? How to install "closureParserClass"? Alexander.

5 4

April 15, 2009

Hi gary It seems that I already fixed SystemProgressMorph>>label:min:max: so that the bloack argument is not written. Can you check because if I redo it and it gets overridden I will have the smae problem. stef

2 2

April 15, 2009

who is now fixed as well as asiignemtn stef

1 0

[Pharo-project] question on traits
by Alexandre Bergel April 14, 2009

April 14, 2009

Hi All, Apparently, the way a conflict may be triggered is slightly different from what is described in the toplas paper. in the paper, it is said that a compiled method that is inherited from more than one path does not trigger a conflict. With the current implementation this trigger a conflict. For example: T1 defines foo T2 uses T1 T3 uses T1 T23 uses T2 + T3 C uses T23 C new foo => conflict error. One would expect no conflict since there is only one definition of foo Just wondering... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 9