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

[Pharo-project] Issue 3949 in pharo: Coverage for Cog

by pharo＠googlecode.com

Status: FixProposed Owner: renggli Labels: Milestone-1.1.2 New issue 3949 by renggli: Coverage for Cog http://code.google.com/p/pharo/issues/detail?id=3949 The fix below makes sure that the coverage method is properly flushed from the method cache. It doesn't seem to yet fix all problems of the coverage tool on Cog but it definitely works better: Name: SUnitGUI-lr.71 Author: lr Time: 3 April 2011, 11:02:41 am UUID: 8098bb1d-fd66-49a3-810c-7e536fff05c7 Ancestors: SUnitGUI-StephaneDucasse.70 - make sure that the coverage tools properly flushes the method cache

April 3, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by Tudor Girba

Hi, I think that this dialogue goes in too many directions, so I will try to provide a summary. Maybe this helps. As I understand, Stef has the following problem: - there is one announcer with two listeners - the problem is that if the first listener raises an error, the second listener is not announced anymore - thus, the base system can be broken simply by creating an extra listener that raises an error As a solution, he proposed the idea of introducing the order of announcements. Igor and Henrik had strong arguments against this solution. I agree with them. They suggested to either decompose the announcements more fine grained, or as you are pointing out now to layer them. I think this is the best solution, and like that we can have the basic announcements to be private. However, the original question still remains valid. I am not quite sure what the solution is, but the idea of Denis of using asynchronous announcements sounds interesting. On the other hand, if I mess up something in the private workings of the kernel, my image will be broken, and that is expected. More inside On 3 Apr 2011, at 10:40, StÃ©phane Ducasse wrote: >> >>>> PPS. There's a neat method called #on:send:to:, which would be perfect for the different actions in RPackage-SystemIntegration. >>> I'm trying to understand how this on:send:to: would help us. >>> Because >>> Nautilus registered to system announcer >>> Now I do not understand why RPackageOrganizer should not register to systemAnnouncer too. >>> And even if we use on:send:to: who can garantee that the on:send:to: will notify first the RPackageOrganizer and >>> not that an announcement will reach the browser before. >>> >>> What was your idea? >>> >>> Stef >> It has nothing to do with registration ordering, but using the proper API. >> If you look at the RPackageOrganizer registrations in RPackage-SystemIntegration, all they do in the action block is send self a message. >> Instead of: >> anAnnouncer >> when: SystemCategoryAddedAnnouncement do: [ :ann | self systemCategoryAddedActionFrom: ann ]; >> you write: >> announcer on: SystemCategoryAddedAnnouncement send: #systemCategoryAddedActionFrom: to: self > > I do not get what is the difference. Can you explain how this would solve my problem? This does not fix your problem. Henrik simply looked at the code and he saw that it would be better to use the message passing instead of the block. > I was discussing with luc and noury yesterday and we thought about the following: > The system should be layered in two layers > > system (Rename) should emit annoucement to system objects (like RPakcageOrganizer) > > UI tools should register not to system but to RPackageOrganizer. Exactly! > So this is probably the solution but I'm thinking that in the long turn may be pushing packages inside the system wiuthout annoucement > would be better. That could be the case, but I think the solution we have now is Ok to bootstrap. Cheers, Doru >> It also has the added benefit you can make them weak if you want :) >> >> Cheers, >> Henry >> >> And ugh, why the Announcement at the end of the Announcement names? :/ > > Who cares for now we have a system on its knees if one annoucnement breaks so to me this is totally useless. > > Stef -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

April 3, 2011

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

by Toon Verwaest

> 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 I don't think I fully understand what you are saying... The model is like this at the moment: Every class has a layout attached to it. Layouts that have slots have LayoutScopes. For example, if you have Class A super: Object slots: #(a b c) Class B super: A slots: #(d e) Then you get Class A <-> PointerLayout -> LayoutClassScope #(a b c) -> LayoutClassScope #() -> LayoutEmptyScope Class B <-> PointerLayout -> LayoutClassScope #(d e) -> LayoutClassScope #(a b c) -> LayoutClassScope #() -> LayoutEmptyScope where LayoutClassScope #(a b c) is shared between the scope of B and the layout of A. The empty LayoutClassScope comes from Object and is shared as well. Now if you get a stateful trait, a stateful trait C with slots #(f) looks like this: StatefulTrait C <-> PointerLayout -> LayoutTraitScope #(f) -> LayoutEmptyScope If you were to install the trait C on B, it would become: Class B <-> PointerLayout -> LayoutClassScope #(d e) -> LayoutForkScope -> LayoutClassScope #(a b c) -> LayoutClassScope #() -> LayoutEmptyScope where the LayoutForkScope would have sidescopes: LayoutForkScope sideScopes: { LayoutTraitScope #(f) -> LayoutEmptyScope } Then the classbuilder will build classes by always following the public path. Sidescopes aren't public. When you compile methods on the trait, its scopes are public; but when they are installed, they aren't public since they are sidescopes. However, every method is compiled on the trait or class that provided the selector, so when you install the trait-related method, it will see the state related to the trait. And when the trait is installed, the sidescopes are actually copies of the original traitscope, so the actual fieldindices are updated in the LayoutTraitScope when it's installed. Then how methods get updated based on state changes is at the moment completely unrelated to the trait implementation, since methods are already updated in my class builder based on a MethodModificationModel that knows how the fields have changed. This will use the decompiler/bytecode modification/recompiler to update the methods in place. The only thing that I forgot to do until now is to actually modify all the classes that use a trait, every time the state of a trait changes... But that's straightforward. We just have to ask for the users of the stateful trait and reapply their class modification. That's all nicely modeled already. As for overlapping state from multiple stateful traits.... there is no overlapping state since all state is private to the trait! You can use 2 traits with same slot names. This is no problem at all since the state is only seen by that trait. And their methods are only compiled on that trait, so the methods will always know exactly which of the slots you are referring to. I hope this helps somehow :) Otherwise ... wait for the paper ;) cheers, Toon

April 3, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Tudor Girba

Hi, The Moose build uses 1.2.1 now: http://hudson.moosetechnology.org/job/moose-latest-dev/ Cheers, Doru On 3 Apr 2011, at 10:45, StÃ©phane Ducasse wrote: > tx! > and yes we should continue > > On Apr 3, 2011, at 9:36 AM, Marcus Denker wrote: > >> >> On Apr 3, 2011, at 9:35 AM, Marcus Denker wrote: >> >>> >>> https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip >>> >> >> >> .. the all green image of today from Hudson. Yes, this is not repeatable and tomorrow >> the hudson one might be different. But we need to move on. 1.1 was build just once, too. >> So we can continue to build the perfect fully automatic process for 1.3... >> >> Next: >> -> Make a one-click. >> -> Make a cog one-click. >> -> push all open reports in the tracker to 1.2.2 >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

April 3, 2011

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