- Pharo-dev - lists.pharo.org

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

by Toon Verwaest

Yes, I read those two things too... but it doesn't seem like a giant leap of an improvement :) On 04/05/2011 02:34 PM, Alexandre Bergel wrote: > 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 >>> >>

April 5, 2011

Re: [Pharo-project] Issue 3105 in pharo: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3105 by marcus.d...(a)gmail.com: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet http://code.google.com/p/pharo/issues/detail?id=3105 in 13133

April 5, 2011

Re: [Pharo-project] Issue 3964 in pharo: Enabling double click on PluggableListMorphOfMany

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #1 on issue 3964 by marcus.d...(a)gmail.com: Enabling double click on PluggableListMorphOfMany http://code.google.com/p/pharo/issues/detail?id=3964 in 13133

April 5, 2011

[Pharo-project] [update 1.3] #13133

by Marcus Denker

13133 ----- Issue 3955: Better implementation of the MorphTreeMorph auto select Issue 3956: Better implementation of the PluggableListMorphs auto select Issue 3964: Enabling double click on PluggableListMorphOfMany Issue 3105: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 5, 2011

Re: [Pharo-project] Issue 3956 in pharo: Better implementation of the PluggableListMorphs auto select

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3956 by marcus.d...(a)gmail.com: Better implementation of the PluggableListMorphs auto select http://code.google.com/p/pharo/issues/detail?id=3956 in 13133

April 5, 2011

Re: [Pharo-project] Issue 3955 in pharo: Better implementation of the MorphTreeMorph auto select

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3955 by marcus.d...(a)gmail.com: Better implementation of the MorphTreeMorph auto select http://code.google.com/p/pharo/issues/detail?id=3955 in 13133

April 5, 2011

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

by Stefan Marr

On 05 Apr 2011, at 15:11, Igor Stasenko wrote: > I don't care :) *sigh* then just flip a coin and you have the same amount of insight with less effort. It is always astonishing how few people know about the basics when it comes to empirical experiments. I disagree with Camillo's demand for 100x repetition, but it should be definitely run at least a few times. And then you have to look at the results and see how they vary. Otherwise you don't know anything and are just wasting your own time. I will try at the next sprint to make some progress on the framework front. Perhaps, someone could trow together something like the unit-test runner to make at least the basics fool-proof. And at the same time the message to measure the execution time of a block should become deprecated or raise a warning that you are about to fool yourself... It does not have to be statistically rigorous for small experiments, but at the very least you have to convince yourself that your measurements are actually of any value. The computer in front of you is just to complex to make an educated guess. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 5, 2011

Re: [Pharo-project] Issue 3957 in pharo: MethodWrappers left method after uninstall

by pharo＠googlecode.com

Updates: Status: Accepted Comment #3 on issue 3957 by marianopeck: MethodWrappers left method after uninstall http://code.google.com/p/pharo/issues/detail?id=3957 "I think that's ok to follow the lookup, because the inherited selectors are part of the behavior of the class, but i think it's a good idea to have a form to restrict that." yes, because the user can do a mess with that. The easiest way is to trhow an error. Then the user can always do the method lookup by himself and do a installOn: with the correct class and selector. "Anyway, in any of the two cases, after the uninstall process, the class should be clean" I agree. I will try to provide a solution (taking int account yours). I will let you know. Daniel...BTW, which is your particular use for MethodWrappers? I mean, why are you using them for? I am just curious...

April 5, 2011

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

by pharo＠googlecode.com

Updates: Status: Accepted Mergedinto: Comment #2 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] Issue 3963 in pharo: RPackageOrganizer and announcements

by pharo＠googlecode.com

Comment #2 on issue 3963 by Benjamin...(a)gmail.com: RPackageOrganizer and announcements http://code.google.com/p/pharo/issues/detail?id=3963 Issue 3937 is about another issue not fixed here ...

April 5, 2011