- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

> Oh yes.. I am :) cool How are you dealing with the fact that the application of trait with state may change the layout of the class user and that you should recompile all the class method to deal with that. And if you have two traits having state you should do the same but for the traits themselves. So this means that the method in the traits cannot be reused (ok now we do not reuse them anymore sniff it was a nice model - reuse without cost of duplication). How your layout object helps you for that? This is why I want first class slot :) Stef > > http://pinocchio.unibe.ch/~tverwaes/slots.tar.gz gives you an image with an example of a stateful trait open. The state is always private to the class / trait at the moment and it already seems to work pretty well. I modified the NewInspector slightly to show you the proper data (although this needs to be cleaned up, and state should be sorted per trait), and the OB to compile and syntax highlight in the right context. > > I didn't test more complex examples yet than what's open, but it's designed generically enough that I'm confident it does ... euhm ... ;) > > cheers, > Toon > > On 04/03/2011 10:44 AM, StÃ©phane Ducasse wrote: >> On Apr 2, 2011, at 9:10 PM, Toon Verwaest wrote: >> >>> Hi all, >>> >>> as you know I'm working on stateful traits using my new classbuilder >> no >> Are you? >> >> >>> etc... Now I noticed that methods are highlighted always inside of the context of the class that's active in the class browser. How can I change this? There is already a useful method around to figure out which object it belongs to: >>> >>> SomeClass traitOrClassOfSelector: #aMethod >>> >>> This actually will tell me which trait it comes from. So now I could apply syntax coloring in the context of the trait rather than the class. Since in my implementation state is all private to the trait / class, they should be able to access their own state but not see the state of the other class. This obviously also means that coloring should happen in the correct scope, rather than always in the scope of the class. >>> >>> At the moment the coloring doesn't really make sense ... but then it didn't really matter that much until now. Although if you try to access state in a method coming from a trait, while coding in your IDE you'll probably have the impression you can access your local instvars. I don't really know what the semantics are there... but it seems a bit broken :) >>> >>> cheers, >>> Toon >>> >> > >

April 3, 2011

[Pharo-project] Issue 3948 in pharo: Transcript and ThreadedTranscript needs to be merged

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3948 by marcus.d...(a)gmail.com: Transcript and ThreadedTranscript needs to be merged http://code.google.com/p/pharo/issues/detail?id=3948 Transcript is now not a Stream subclass anymore. ThreadedTranscript's install method now destroys the Transcript class. Transcript now has a semaphore, so maybe it is thread safe? merge needed.

April 3, 2011

Re: [Pharo-project] Issue 3942 in pharo: Transcript missing compatibility method ensureCr

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3942 by marcus.d...(a)gmail.com: Transcript missing compatibility method ensureCr http://code.google.com/p/pharo/issues/detail?id=3942 fix attached Attachments: EnsureCr.1.cs 360 bytes

April 3, 2011

Re: [Pharo-project] Issue 3944 in pharo: ClassHierarchyTest needs to be moved to KernelTests package

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3944 by marcus.d...(a)gmail.com: ClassHierarchyTest needs to be moved to KernelTests package http://code.google.com/p/pharo/issues/detail?id=3944 fix attached Attachments: ClassHierarchyTest.1.cs 242 bytes

April 3, 2011

[Pharo-project] Issue 3947 in pharo: remove #floodFill:

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3947 by marcus.d...(a)gmail.com: remove #floodFill: http://code.google.com/p/pharo/issues/detail?id=3947 Form removeSelector: #floodFill:at:! Form removeSelector: #floodFill:at:tolerance:! ... references non-existing class. Not called. Attachments: FloodFill.1.cs 180 bytes

April 3, 2011

[Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3946 by marcus.d...(a)gmail.com: remove some more uniclasses/player related code http://code.google.com/p/pharo/issues/detail?id=3946 remove some more uniclasses/player related dead code Attachments: Clean.1.cs 615 bytes

April 3, 2011

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

by Toon Verwaest

Oh yes.. I am :) http://pinocchio.unibe.ch/~tverwaes/slots.tar.gz gives you an image with an example of a stateful trait open. The state is always private to the class / trait at the moment and it already seems to work pretty well. I modified the NewInspector slightly to show you the proper data (although this needs to be cleaned up, and state should be sorted per trait), and the OB to compile and syntax highlight in the right context. I didn't test more complex examples yet than what's open, but it's designed generically enough that I'm confident it does ... euhm ... ;) cheers, Toon On 04/03/2011 10:44 AM, StÃ©phane Ducasse wrote: > On Apr 2, 2011, at 9:10 PM, Toon Verwaest wrote: > >> Hi all, >> >> as you know I'm working on stateful traits using my new classbuilder > no > Are you? > > >> etc... Now I noticed that methods are highlighted always inside of the context of the class that's active in the class browser. How can I change this? There is already a useful method around to figure out which object it belongs to: >> >> SomeClass traitOrClassOfSelector: #aMethod >> >> This actually will tell me which trait it comes from. So now I could apply syntax coloring in the context of the trait rather than the class. Since in my implementation state is all private to the trait / class, they should be able to access their own state but not see the state of the other class. This obviously also means that coloring should happen in the correct scope, rather than always in the scope of the class. >> >> At the moment the coloring doesn't really make sense ... but then it didn't really matter that much until now. Although if you try to access state in a method coming from a trait, while coding in your IDE you'll probably have the impression you can access your local instvars. I don't really know what the semantics are there... but it seems a bit broken :) >> >> cheers, >> Toon >> >

April 3, 2011

[Pharo-project] Issue 3945 in pharo: Remove squeakland plugin methods from SystemVersion

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3945 by marcus.d...(a)gmail.com: Remove squeakland plugin methods from SystemVersion http://code.google.com/p/pharo/issues/detail?id=3945 Remove squeakland plugin methods from SystemVersion Attachments: CleanPlugin.1.cs 507 bytes

April 3, 2011

[Pharo-project] Issue 3944 in pharo: ClassHierarchyTest needs to be moved to KernelTests package

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3944 by marcus.d...(a)gmail.com: ClassHierarchyTest needs to be moved to KernelTests package http://code.google.com/p/pharo/issues/detail?id=3944 ClassHierarchyTest needs to be moved to KernelTests package

April 3, 2011

[Pharo-project] Issue 3943 in pharo: remove ExternalSettings from MC

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3943 by marcus.d...(a)gmail.com: remove ExternalSettings from MC http://code.google.com/p/pharo/issues/detail?id=3943 ExternalSettings... this changeset removes ExternalSettings from it's last client. In the preamble, this code needs to be called: ExternalSettings registeredClients remove: MCRepository. removal changeset attached. Attachments: MCRemoveExternalSettings.1.cs 1.3 KB

April 3, 2011