- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3961 in pharo: Fix order of worlmenu

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3961 by marcus.d...(a)gmail.com: Fix order of worlmenu http://code.google.com/p/pharo/issues/detail?id=3961 in 13132

April 5, 2011

Re: [Pharo-project] Issue 3963 in pharo: RPackageOrganizer and announcements

by pharo＠googlecode.com

Comment #1 on issue 3963 by marcus.d...(a)gmail.com: RPackageOrganizer and announcements http://code.google.com/p/pharo/issues/detail?id=3963 Issue 3937 has been merged into this issue.

April 5, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Camillo Bruni

This is exactly why you have to provide some confidence interval / deviation, otherwise it is hard to make any reasonable conclusion. run it 100 times and take the average and provide the standard deviation. I am not a big fan of relying on incomplete benchmarking results: Please read: http://portal.acm.org/citation.cfm?id=1297033 http://www.squeaksource.com/p.html provides a basic benchmarking framework under the NBenchmark package. You subclass from PBenchmarkSuite implement a method #benchXXX and run it. r := PBFloat run: 100. r asString which will give decent results back :). This way it is much easier to make sense out of the numbers. So here again to remember: - number of samples - average run times - standard deviation If one of these results is missing the benchmark results are incomplete. best regards, camillo On 2011-04-05, at 13:56, Igor Stasenko wrote: > VariableNode initialize. > Compiler recompileAll. > > [ > TestCase allSubclasses do: [ :cls| > cls isAbstract > ifFalse: [cls suite run]]. > ] timeToRun > > 178938 > 183963 > > > > (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: []. > Compiler recompileAll. > > [ > TestCase allSubclasses do: [ :cls| > cls isAbstract > ifFalse: [cls suite run]]. > ] timeToRun > > 187168 > 184992 > > the deviation is too big to see if its really so big overhead. > > if you compare worst , you got 187/178 ~ 5% > and if you compare the best you got > 184/183 ~ 0.5% > > > -- > Best regards, > Igor Stasenko AKA sig. >

April 5, 2011

Re: [Pharo-project] Issue 3937 in pharo: Breaking Announcement system

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 3963 Comment #1 on issue 3937 by marcus.d...(a)gmail.com: Breaking Announcement system http://code.google.com/p/pharo/issues/detail?id=3937 (No comment was entered for this change.)

April 5, 2011

Re: [Pharo-project] Draft Pharo 1.2.1 Release Announcement

by StÃ©phane Ducasse

I ill have a look when I get a little moment. Stef On Apr 5, 2011, at 9:19 AM, Sven Van Caekenberghe wrote: > > On 05 Apr 2011, at 07:09, laurent laffont wrote: > >> Remarks: >> - group changed by categories: Morphic/Polymorph, Tools, Under the hood, ... >> - Mocketry is not included in Pharo 1.2 > > > Thanks for the feedback, I applied your suggestions. And uploaded a newer version. > > More comments ? > > Sven

April 5, 2011

[Pharo-project] Issue 3963 in pharo: RPackageOrganizer and announcements

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus Milestone-1.3 New issue 3963 by Benjamin...(a)gmail.com: RPackageOrganizer and announcements http://code.google.com/p/pharo/issues/detail?id=3963 I propose a workable solution in PharoTaskForces: Name: SystemAnnouncements-BenjaminVanRyseghem.38 Author: BenjaminVanRyseghem Time: 5 April 2011, 2:41:14 pm UUID: 157eabfb-9f1c-4986-8006-fb961e2414d2 Ancestors: SystemAnnouncements-cyrilledelaunay.37 New version with InternalAnnouncement for RPackage ------------------------------------------------ Name: RPackage-Core-BenjaminVanRyseghem.70 Author: BenjaminVanRyseghem Time: 5 April 2011, 2:42:04 pm UUID: 7a56fce7-ef8d-491a-8746-aede3e9e22c4 Ancestors: RPackage-Core-BenjaminVanRyseghem.69 Announcements are sent when RPackages are modified ------------------------------------------------ Name: RPackage-SystemIntegration-BenjaminVanRyseghem.52 Author: BenjaminVanRyseghem Time: 5 April 2011, 2:44:19 pm UUID: 78b4ec5e-742b-45b5-8f2e-56886c5f2f8e Ancestors: RPackage-SystemIntegration-cyrilledelaunay.51 Now registered to InternalAnnouncements to execute during integration: Pre: RPackageOrganizer allInstances do: [:each | SystemAnnouncer announcer unsubscribe: each]. Post: RPackageOrganizer allInstances do: [:each | each RPackageOrganizer default registerInterestToSystemAnnouncement]

April 5, 2011

Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

by Alexandre Bergel

I remember Fred has lazy initialization of variable. All variables are lazy initialized. This means that variables set to nil when you change the class are lazy initialized. It has been a long time I looked at it. Alexandre On 4 Apr 2011, at 16:32, StÃ©phane Ducasse wrote: > In fact he got a better changeClassToThatOf: implementation and got kind of initform for slots. > > Stef > > >> I do read French too, no problem. >> >> I'm having a look at >> >> http://fredrivard.ifrance.com/fredrivard/pub/dicl/dicl.ps >> >> That seems related. >> >> On 04/04/2011 09:20 PM, Alexandre Bergel wrote: >>> he he. I am not sure Fred wrote in English. >>> http://scg.unibe.ch/scgbib?_k=qQPhJdNf&query=rivard >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 4 Apr 2011, at 14:15, Toon Verwaest wrote: >>> >>>> Do you have an exact reference on this? >>>> >>>> On 04/04/2011 05:55 PM, StÃ©phane Ducasse wrote: >>>>>> Another very cool thing that we can do now (which would require 3 lines of change in my system though), is that the slot can also be responsible for instance migration. There are four cases: >>>>>> 1- the instance variable didn't exist and now it does >>>>>> 2- the instance variable existed but disappeared >>>>>> 3- the metaobject changed (new semantics) >>>>>> 4- the metaobject stayed the same >>>>>> >>>>> Did you check the work of fred rivard because he was managing the dynamic change of class and managing slot reinitialization? >>>>> >>>>> >>>>>> Basically the only case that is "handled" by standard Pharo is case 1; and what you do there is putting nil in the field. In our model the slot could do something more interesting when it's migrating the instances. And we could tackle the other cases too. I think it's starting to get ideal to implement an active context on top ;-) >>>>>> >>>>>> cheers, >>>>>> Toon >>>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 5, 2011

[Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy

by Fernando Olivero

Hi Ben, i was thinking about the discussion of the menus: Since you are using menu pragma builder, and have explicit views for each tool, then the CodeHolder hierarchy is no longer needed. Because the specialized views get the behavior for answering the actions in the menus (which currently is spread across the StringHolder hierarchy). So this is the main reason why you simple need a pluggable text model, for the model of the views. And a pluggable TextModel (or StringHolder in Pharo) would suffice? Is this correct? Thanks, Fernando

April 5, 2011

Re: [Pharo-project] Issue 3953 in pharo: add #ensureCr to new transcript

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3953 by stephane...(a)gmail.com: add #ensureCr to new transcript http://code.google.com/p/pharo/issues/detail?id=3953 in 13132

April 5, 2011

[Pharo-project] [update 1.3] #13132

by StÃ©phane Ducasse

13132 ----- - Issue 3953: add #ensureCr to new transcript - fix world menu

April 5, 2011