Re: [Pharo-project] Issue 1328 in pharo: Remove old input sensor classes
Updates: Status: Closed Comment #7 on issue 1328 by marcus.d...@gmail.com: Remove old input sensor classes http://code.google.com/p/pharo/issues/detail?id=1328 It seems the old classes are already removed
Re: [Pharo-project] Issue 3741 in pharo: Decompiler hangs
Updates: Status: Closed Comment #2 on issue 3741 by marcus.d...@gmail.com: Decompiler hangs http://code.google.com/p/pharo/issues/detail?id=3741 Hello, Can you check in the latest 1.3? I can not as there is not enough information to re-create the bug.
Re: [Pharo-project] Issue 3005 in pharo: Support for SCIM on Linux
Updates: Status: Duplicate Mergedinto: 1405 Comment #2 on issue 3005 by marcus.d...@gmail.com: Support for SCIM on Linux http://code.google.com/p/pharo/issues/detail?id=3005 (No comment was entered for this change.)
Re: [Pharo-project] Issue 1405 in pharo: Ubuntu vm : inputting return character on belgian keyboard layout is different in pharo than in other programs
Comment #5 on issue 1405 by marcus.d...@gmail.com: Ubuntu vm : inputting return character on belgian keyboard layout is different in pharo than in other programs http://code.google.com/p/pharo/issues/detail?id=1405 Issue 3005 has been merged into this issue.
[Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
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.
Re: [Pharo-project] Issue 3911 in pharo: Change updater to allow updating a release image
Updates: Labels: -Milestone-1.2 Milestone-1.2.2 Comment #4 on issue 3911 by marcus.d...@gmail.com: Change updater to allow updating a release image http://code.google.com/p/pharo/issues/detail?id=3911 (No comment was entered for this change.)
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
Excellent! 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. Exactly. 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 Why still work on 1.2.2. Why not moving them to 1.3? Cheers, Doru -- www.tudorgirba.com No matter how many recipes we know, we still value a chef.
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
Thanks Markus Hil Le 03/04/2011 09:35, Marcus Denker a écrit : https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- Education 0.2 -- http://blog.ofset.org/hilaire
Re: [Pharo-project] Issue 3912 in pharo: Circular dependency with GLMOrangeUITheme
Updates: Labels: -Milestone-1.2 Milestone-1.2.2 Milestone-1.3 Comment #1 on issue 3912 by marcus.d...@gmail.com: Circular dependency with GLMOrangeUITheme http://code.google.com/p/pharo/issues/detail?id=3912 (No comment was entered for this change.)
Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar
Updates: Labels: -Milestone-1.2-DevImage Milestone-1.2.2-DevImage Milestone-1.3-DevImage Comment #7 on issue 3754 by marcus.d...@gmail.com: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 (No comment was entered for this change.)
Re: [Pharo-project] Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting
Updates: Labels: -Milestone-1.2-DevImage Milestone-1.2.2-DevImage Comment #23 on issue 3706 by marcus.d...@gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 (No comment was entered for this change.)
Re: [Pharo-project] Issue 3842 in pharo: 1.2 Config needs to load latest code from OB Repository
Updates: Labels: -Milestone-1.2-DevImage Milestone-1.2.2-DevImage Comment #1 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load latest code from OB Repository http://code.google.com/p/pharo/issues/detail?id=3842 (No comment was entered for this change.)
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
On Apr 3, 2011, at 9:41 AM, Tudor Girba wrote: Excellent! 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. Exactly. 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 Why still work on 1.2.2. Why not moving them to 1.3? Yes, you are right... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar
Comment #8 on issue 3754 by renggli: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 FYI: I cannot reproduce this problem in Pharo 1.2
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
A pity that broken OB code is used, nevertheless it is quite usable. Lukas On 3 April 2011 09:58, Marcus Denker marcus.den...@inria.fr wrote: On Apr 3, 2011, at 9:41 AM, Tudor Girba wrote: Excellent! 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. Exactly. 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 Why still work on 1.2.2. Why not moving them to 1.3? Yes, you are right... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
On Apr 3, 2011, at 10:22 AM, Lukas Renggli wrote: A pity that broken OB code is used, nevertheless it is quite usable. Yes, and I added a bug report on March 22: http://code.google.com/p/pharo/issues/detail?id=3842 But nobody cared to react. So how important can it be? There are two possibilities: - Postponing the release because it's not perfect. (We are doing this for *3 Months* already) - Not release and wait another 3 Months. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Announcement real problems - please read and comment.
On Apr 2, 2011, at 5:14 PM, Henrik Sperre Johansen wrote: On 02.04.2011 09:16, Stéphane Ducasse wrote: Henrik what is your answer to problem 1 Problem 1 - the second announcement was never sent, because the first one broke the second was blocked. we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass Because we can get the system down just because one guy can register a bug. http://forum.world.st/Another-finalization-concern-error-handling-td2989615.html It's basically the same. ?? Cheers, Henry
Re: [Pharo-project] Issue 3709 in pharo: Clean OB**WithShout in omnibrowser
Comment #1 on issue 3709 by renggli: Clean OB**WithShout in omnibrowser http://code.google.com/p/pharo/issues/detail?id=3709 This is pretty much cleaned up in http://source.lukas-renggli.ch/omnibrowser/ and http://source.lukas-renggli.ch/unsorted/.
Re: [Pharo-project] Announcement real problems - please read and comment.
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? 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. 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. 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
Re: [Pharo-project] Participating to a cool project
tx hilaire keep pushing. stef On Apr 2, 2011, at 8:55 PM, Hilaire Fernandes wrote: Dr. Geo (http://www.ofset.org/drgeo) is becoming better release after release. It is proposed for all three major systems and the XO OLPC laptop for kid. It has been downloaded several thousand of times, it is used in several place in the world, we even get a TV show only for DrGeo http://www.youtube.com/watch?v=wdx7vJwPmcA Yet it is a neat way to promote Smalltalk as DrGeo scripting feature expose the user to the Smalltalk language and environment. Far beyond my expectation, teachers are exploring DrGeo to use it as an environment to teach programming, see this nice French article: http://revue.sesamath.net/spip.php?article330 I hope more will come. If you are interested to participate to a cool project, for coding, documenting, testing, promoting; come and join, there are many stuff to do: * test * report defects * translate the user interface of the software * document and translate the documentation * design DrGeo courses * design graphics * learn from DrGeo design and fix bugs * learn from DrGeo design and implement new features More to read at http://community.ofset.org/index.php/Community_DrGeo#Participating_to_the_Project -- Education 0.2 -- http://blog.ofset.org/hilaire
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
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
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
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.
Re: [Pharo-project] Issue 3786 in pharo: Debug test .. (d) menu option in OBSystenBrowser gives SystemGuardException in Pharo 1.2
Comment #3 on issue 3786 by jvdsa...@gmail.com: Debug test .. (d) menu option in OBSystenBrowser gives SystemGuardException in Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3786 This bug is still present in the 1.2.1 development image.
Re: [Pharo-project] Issue 3709 in pharo: Clean OB**WithShout in omnibrowser
Updates: Status: Duplicate Mergedinto: 3842 Comment #2 on issue 3709 by marcus.d...@gmail.com: Clean OB**WithShout in omnibrowser http://code.google.com/p/pharo/issues/detail?id=3709 So this will be fixed with a merge
Re: [Pharo-project] Issue 3842 in pharo: 1.2 Config needs to load latest code from OB Repository
Comment #2 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load latest code from OB Repository http://code.google.com/p/pharo/issues/detail?id=3842 Issue 3709 has been merged into this issue.
Re: [Pharo-project] Issue 3842 in pharo: 1.2 Config needs to load latest code from OB Repository
Comment #3 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load latest code from OB Repository http://code.google.com/p/pharo/issues/detail?id=3842 Issue 3786 has been merged into this issue.
Re: [Pharo-project] Issue 3786 in pharo: Debug test .. (d) menu option in OBSystenBrowser gives SystemGuardException in Pharo 1.2
Updates: Status: Duplicate Mergedinto: 3842 Comment #4 on issue 3786 by marcus.d...@gmail.com: Debug test .. (d) menu option in OBSystenBrowser gives SystemGuardException in Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3786 So then this code is in the other branch... will be fixed with a merge
Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar
Updates: Status: Closed Comment #9 on issue 3754 by marcus.d...@gmail.com: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 (No comment was entered for this change.)
[Pharo-project] Issue 3943 in pharo: remove ExternalSettings from MC
Status: FixProposed Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3943 by marcus.d...@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
[Pharo-project] Issue 3944 in pharo: ClassHierarchyTest needs to be moved to KernelTests package
Status: Accepted Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3944 by marcus.d...@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
[Pharo-project] Issue 3945 in pharo: Remove squeakland plugin methods from SystemVersion
Status: FixProposed Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3945 by marcus.d...@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
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
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
[Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code
Status: FixProposed Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3946 by marcus.d...@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
[Pharo-project] Issue 3947 in pharo: remove #floodFill:
Status: FixProposed Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3947 by marcus.d...@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
Re: [Pharo-project] Issue 3944 in pharo: ClassHierarchyTest needs to be moved to KernelTests package
Updates: Status: FixProposed Comment #1 on issue 3944 by marcus.d...@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
Re: [Pharo-project] Issue 3942 in pharo: Transcript missing compatibility method ensureCr
Updates: Status: FixProposed Comment #1 on issue 3942 by marcus.d...@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
[Pharo-project] Issue 3948 in pharo: Transcript and ThreadedTranscript needs to be merged
Status: Accepted Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3948 by marcus.d...@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.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
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
Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image
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.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
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
Re: [Pharo-project] Announcement real problems - please read and comment.
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.
[Pharo-project] Issue 3949 in pharo: Coverage for Cog
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
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
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. I obviously meant, the compiler will compile methods by following the public path.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
So now I could apply syntax coloring in the context of the trait rather than the class. Do you mean coloring message sends in a trait's method? For self call that is not specified in the requirement? 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. Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x and methods of C will use C.x? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] Announcement real problems - please read and comment.
On Apr 3, 2011, at 12:30 PM, Tudor Girba wrote: 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 Yes this was the problem number 1 of my original mail. What I do not understand is why a ifCurtailed: [ emit and process next announcement does not solve the problem] Now we also have the problem number 2. 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. Yes this is what I think. 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. ok 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. Yes I thought about that too. So I will try to see with ben that nautilus register to RPackageOrganizer instaed of SystemAnnouncer. 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.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
Do you mean coloring message sends in a trait's method? For self call that is not specified in the requirement? I meant that if you look at a method coming from a trait inside of the class browser; while your browser is pointing at a class. Instance variables were colored red since they weren't found on the class. However, they came from the trait, so should have been colored in the scope of the trait. Now that's fixed. All methods are being colored in the scope where they are defined. Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x and methods of C will use C.x? Alexandre At the moment you can't, but in our slot library we have alias slots. So that we could use to do the same tricks as with methods: required slots, provided slots, defrosted slots, ... So yes, at the moment C.x using T.x will have completely separate uses in methods, only dependent on where they are compiled. Traits related methods see the trait state, class related methods see the class state. I think it's more important to get that part working first; and to then start providing access, which is why I did it in this order. cheers, Toon
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
I tried the image. I hadn't seen such a look for years :-)
StatefulTrait named: #TStatefulTest
layout: PointerLayout
slots: {
#tfirst = Slot.
#tsecond = Slot.
}
uses: {}
category: #'Slot-Traits-Test'
I checked what layout: is about. StatefulTrait is a dry in terms of comments :-)
Why do you have = Slot ? What can tfirst be else, if not a slot? Can you
specialize the slots to use a particular layout?
I played a bit with your image. I cannot access tfirst in MyFirstTest. Your
implementation is conform to the policy you defined above.
Your image is a bit unstable. I tried to press the tab key for autocompletion,
and got some debuggers that I couldn't close. I misspelled aMethod with
aMethdo, and got plenty of debuggers related to QQParser
Cheers,
Alexandre
On 3 Apr 2011, at 05:34, Toon Verwaest wrote:
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
I just finished building a new image based on the helvetia image.
http://pinocchio.unibe.ch/~tverwaes/PlayOut.tar.gz
The previous image is what I've been developing in, and yes, it's pretty
annoying... I hope that the new image will perform better. But since I
already noticed that the new inspector isn't loaded, you don't get a
proper view on the trait-related objects.
Coloring is still done properly though.
Yes I see, I did forget to implement all the tools to make it work. You
know... I started the stateful traits implementation on Friday... I'm
glad that I'm as far as I am ;) However, in the new image I can close
it. Exceptions are just very slow for some reason.
There are not many comments around, and not enough tests. After I finish
my paperwriting I'll go over it and document everything! It's a sneak
preview ... did I mention that? ;)
For the slots, yes there are subclasses of the standard Slot class; and
they can provide non-standard access.
You might notice that changing a class' layout is a lot faster thanks to
bytecode level method updates :) Or not, hence I mention it again.
That's all part of this particular image.
cheers,
Toon
On 04/03/2011 02:19 PM, Alexandre Bergel wrote:
I tried the image. I hadn't seen such a look for years :-)
StatefulTrait named: #TStatefulTest
layout: PointerLayout
slots: {
#tfirst = Slot.
#tsecond = Slot.
}
uses: {}
category: #'Slot-Traits-Test'
I checked what layout: is about. StatefulTrait is a dry in terms of comments :-)
Why do you have = Slot ? What can tfirst be else, if not a slot? Can you
specialize the slots to use a particular layout?
I played a bit with your image. I cannot access tfirst in MyFirstTest. Your
implementation is conform to the policy you defined above.
Your image is a bit unstable. I tried to press the tab key for autocompletion,
and got some debuggers that I couldn't close. I misspelled aMethod with
aMethdo, and got plenty of debuggers related to QQParser
Cheers,
Alexandre
On 3 Apr 2011, at 05:34, Toon Verwaest wrote:
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
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf)
We have T.y and C.x
T has a method #getY, for which its bytecode returns the first slot (i.e., y).
If C uses T, the #getY needs to be adapted to return the second slot right?
Cheers,
Alexandre
On 3 Apr 2011, at 06:23, Toon Verwaest wrote:
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x and methods of C will use C.x? At the moment you can't, but in our slot library we have alias slots. So that we could use to do the same tricks as with methods: required slots, provided slots, defrosted slots, ... I am lost. I understand that a trait have a class have a different scope of slots. But you cannot define C.x and T.x? Why? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On 04/03/2011 02:29 PM, Alexandre Bergel wrote:
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf)
We have T.y and C.x
T has a method #getY, for which its bytecode returns the first slot (i.e., y).
If C uses T, the #getY needs to be adapted to return the second slot right?
Cheers,
Alexandre
Indeed. And this is not different from changing a layout of a class
having as impact that you have to update the methods.
The default traits implementation already recompiles all methods anyway
whenever it installs the trait. What I do is, I just let the trait
compile itself on the subpart of the class that originally defined the
trait.
Since this subpart is a copy of the original trait (just like the
default traits does), it also has a COPY of the original layout. In this
copy, the indices of the slots are updated when they are mixed with the
class that is going to use the trait. So it's being compiled in the
scope of the installed version of the trait-layout. So that easily works.
cheers
On 3 Apr 2011, at 06:23, Toon Verwaest wrote:
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
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On 04/03/2011 02:31 PM, Alexandre Bergel wrote: Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x and methods of C will use C.x? At the moment you can't, but in our slot library we have alias slots. So that we could use to do the same tricks as with methods: required slots, provided slots, defrosted slots, ... I am lost. I understand that a trait have a class have a different scope of slots. But you cannot define C.x and T.x? Why? Cheers, Alexandre T.x and C.x will be different slots. That's all. Go ahead and try it out ;) Install some uniquely named accessor methods on the trait and class that use the same instance variable. cheers
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
Yes I see, I did forget to implement all the tools to make it work. You
know... I started the stateful traits implementation on Friday... I'm glad
that I'm as far as I am ;) However, in the new image I can close it.
Exceptions are just very slow for some reason.
This is cool that you're working on this topic.
There are not many comments around, and not enough tests. After I finish my
paperwriting I'll go over it and document everything! It's a sneak preview
... did I mention that? ;)
Yes, papers are important. Papers are often more used than implementations.
Cheers,
Alexandre
For the slots, yes there are subclasses of the standard Slot class; and they
can provide non-standard access.
You might notice that changing a class' layout is a lot faster thanks to
bytecode level method updates :) Or not, hence I mention it again. That's all
part of this particular image.
cheers,
Toon
On 04/03/2011 02:19 PM, Alexandre Bergel wrote:
I tried the image. I hadn't seen such a look for years :-)
StatefulTrait named: #TStatefulTest
layout: PointerLayout
slots: {
#tfirst = Slot.
#tsecond = Slot.
}
uses: {}
category: #'Slot-Traits-Test'
I checked what layout: is about. StatefulTrait is a dry in terms of comments
:-)
Why do you have = Slot ? What can tfirst be else, if not a slot? Can you
specialize the slots to use a particular layout?
I played a bit with your image. I cannot access tfirst in MyFirstTest. Your
implementation is conform to the policy you defined above.
Your image is a bit unstable. I tried to press the tab key for
autocompletion, and got some debuggers that I couldn't close. I misspelled
aMethod with aMethdo, and got plenty of debuggers related to QQParser
Cheers,
Alexandre
On 3 Apr 2011, at 05:34, Toon Verwaest wrote:
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On 04/03/2011 02:31 PM, Alexandre Bergel wrote: Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x and methods of C will use C.x? At the moment you can't, but in our slot library we have alias slots. So that we could use to do the same tricks as with methods: required slots, provided slots, defrosted slots, ... I am lost. I understand that a trait have a class have a different scope of slots. But you cannot define C.x and T.x? Why? Cheers, Alexandre Doh, I see. There's a stupid test that raises a conflict cause it finds slots that are conflicting. While actually they are not conflicting. Let me fix that ;) cheers, Toon
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
Indeed. And this is not different from changing a layout of a class having as
impact that you have to update the methods.
The default traits implementation already recompiles all methods anyway
whenever it installs the trait. What I do is, I just let the trait compile
itself on the subpart of the class that originally defined the trait.
allMethods from where?
Since this subpart is a copy of the original trait (just like the default
traits does), it also has a COPY of the original layout. In this copy, the
indices of the slots are updated when they are mixed with the class that is
going to use the trait. So it's being compiled in the scope of the installed
version of the trait-layout. So that easily works.
Yes, no big challenge to make it work. I agree.
Put a ref to copydown, from strongtalk.
Cheers,
Alexandre
cheers
On 3 Apr 2011, at 06:23, Toon Verwaest wrote:
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On Apr 3, 2011, at 1:29 PM, Alexandre Bergel wrote: I guess that what Stef meant is the following: One of the problems when sharing code among mixin and stateful-trait application is that the physical layout of instances varies between mixin applications. (Section 6.5 of Yes, and the physical layout is now modeled as objects. (See Hierarchy of AbstractLayout). We have T.y and C.x T has a method #getY, for which its bytecode returns the first slot (i.e., y). If C uses T, the #getY needs to be adapted to return the second slot right? Yes. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On 04/03/2011 02:37 PM, Alexandre Bergel wrote: Indeed. And this is not different from changing a layout of a class having as impact that you have to update the methods. The default traits implementation already recompiles all methods anyway whenever it installs the trait. What I do is, I just let the trait compile itself on the subpart of the class that originally defined the trait. allMethods from where? The methods coming from the trait are recompiled on the class when they are installed. Actually this should just do bytecode rewriting... but I don't have time to completely rewrite the traits just yet. I'll do that in May I guess ;) Put a ref to copydown, from strongtalk. Will do ;) Now I fixed the bug in MC, the PlayOut project. Now it works; you can define an instance variable from a trait also on the class and they will not overlap. cheers, Toon
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On 04/03/2011 02:29 PM, Alexandre Bergel wrote: I guess that what Stef meant is the following: One of the problems when sharing code among mixin and stateful-trait application is that the physical layout of instances varies between mixin applications. (Section 6.5 of http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf) So as your paper states ... methods may have to be copied down if the layout is different. In the case of traits you always flatten out methods; and the default traits implementation for Pharo ALWAYS recompiles the methods when copying them. I just make sure they get recompiled in the installed trait's scope. Of course in our case there is no such thing as copying down, since traits are flattened, and not part of the hierarchy, such as is the case for mixins. So no difficult transformations are required, recompiling is good enough. It would be faster to just update the bytecode indices by decompiling and recompiling; but as said before ... that's just work I can't really afford at this very moment. cheers, Toon
Re: [Pharo-project] Issue 3911 in pharo: Change updater to allow updating a release image
Updates: Status: Closed Comment #5 on issue 3911 by marcus.d...@gmail.com: Change updater to allow updating a release image http://code.google.com/p/pharo/issues/detail?id=3911 in 12346
Re: [Pharo-project] Issue 3949 in pharo: Coverage for Cog
Updates: Labels: -Milestone-1.1.2 Milestone-1.2.2 Milestone-1.3 Comment #1 on issue 3949 by marcus.d...@gmail.com: Coverage for Cog http://code.google.com/p/pharo/issues/detail?id=3949 in 1.2.2a TODO: 1.3
Re: [Pharo-project] Issue 3912 in pharo: Circular dependency with GLMOrangeUITheme
Updates: Labels: -Milestone-1.2.2 Comment #2 on issue 3912 by marcus.d...@gmail.com: Circular dependency with GLMOrangeUITheme http://code.google.com/p/pharo/issues/detail?id=3912 This is the same in 1.3 I propose, as this is a purely cosmetic problem, to postpone this to 1.3 and keep 1.2 as it is.
Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar
Comment #10 on issue 3754 by thereluc...@fastmail.fm: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 I just tried it with: 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.52] 21.0‘ and with 'Squeak4.1 of 17 April 2010 [latest update: #9957] Squeak VM 4.2.5b1‘ with a fresh Pharo1.2.2a Latest update: #12345 image on MacOS 10.6.6 - Start the image. - Open a Browser via the World Menu. - A browser with an ‚extra scrollbar‘ appears. - See the screenshot at comment 2. - the extra scrollbar disappears when it is single clicked. it happens every single time.
Re: [Pharo-project] who is using softSqueak and standard Squeak
On Sat, Apr 2, 2011 at 10:38 AM, laurent laffont laurent.laff...@gmail.comwrote: On Sat, Apr 2, 2011 at 10:14 AM, Marcus Denker marcus.den...@inria.frwrote: On Apr 2, 2011, at 9:55 AM, laurent laffont wrote: Patrick, I think we should have a ConfigurationOfPharoThemes with all the themes you have made + current ones. I can help (may be a good subject for a our weekly coding-dojo) PharoCore should have only one theme I think. And in turn this means that pharo full has *all* of them? Nonono... it has already *far* too much stuff nobody cares about. I'm not saying that Pharo should have all of them. We can have: - ConfigurationOfPharoThemes project latestVersion load:#default = load the most used themes (ex: Glamour + Watery2) - for Pharo Full - ConfigurationOfPharoThemes project latestVersion load:#softSqueak for the few (?) people who want to use softSqueak for example. So ConfigurationOfPharoThemes will be an easy way to reference all working themes Laurent. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. Marcus, I totally agree with you, my target is to find a mean to have a default theme in Pharo core and other easy to load themes in Pharo full. A theme in itself should be self contained and should only depend on UITheme/UIThemeIcons. Thus a simple repository called PharoTheme could suffice for officially supported ones. What is loaded by default in Pharo full is up to the Pharo team, IMHO there is currently to many themes by default. -- Patrick Barroca
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
- the initialization is not modular so you end up write a lot of
pattern initializeTrait and calling it.
How you model deal with initialization beside using initform a la clos (because
you have first class slots ... that I want in pharo -- see the subliminal
message).
Stef
On Apr 3, 2011, at 12:23 PM, Toon Verwaest wrote:
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
Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar
Updates: Status: Started Comment #11 on issue 3754 by marcus.d...@gmail.com: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 (No comment was entered for this change.)
[Pharo-project] [ANN] For testing: 1.2.1 One-Click
As with 1.2 in general, I gave up on auto build... as we will move to the VMs we build ourselfes in 1.3, the idea is to keep 1.2 as simple as possible. - I added the windows vm that Torsten send me - I did not update the mac or unix vm from 1.1.1... https://gforge.inria.fr/frs/download.php/28437/Pharo-1.2.1-OneClick.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Issue 3645 in pharo: Update Hudson One-Click build files for 1.2
Updates: Status: Closed Comment #5 on issue 3645 by marcus.d...@gmail.com: Update Hudson One-Click build files for 1.2 http://code.google.com/p/pharo/issues/detail?id=3645 I did a 1.2 oneclick. We will use our own builds for 1.3 soon, for 1.2 we don't bother to configure hudson as everything would change for 1.3 again.
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On 04/03/2011 04:58 PM, Stéphane Ducasse wrote:
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
I'm not sure if it changes smalltalk too much! I'd rather say that it
stays very much the same. When you weave in a stateful trait it's like
weaving in a stateless trait, only behavior is added (from the point of
view of the class). As for the extra operators, I'm not sure how weighty
the aliasing of state from traits will be... I hope we can limit it.
- the initialization is not modular so you end up write a lot of
pattern initializeTrait and calling it.
How you model deal with initialization beside using initform a la clos (because
you have first class slots ... that I want in pharo -- see the subliminal
message).
Stef
The idea is that slots define how they should be initialized. This could
be just a value like in CLOS, but is preferably something a lot more
elaborate.
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
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
On Apr 3, 2011, at 12:23 PM, Toon Verwaest wrote:
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
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
At least, Toon will avoid all the problems we had with the renaming and
unwanted name clashed. Trait's accessors and mutators should then do their job.
Alexandre
I'm not sure if it changes smalltalk too much! I'd rather say that it stays
very much the same. When you weave in a stateful trait it's like weaving in a
stateless trait, only behavior is added (from the point of view of the
class). As for the extra operators, I'm not sure how weighty the aliasing of
state from traits will be... I hope we can limit it.
- the initialization is not modular so you end up write a lot of
pattern initializeTrait and calling it.
How you model deal with initialization beside using initform a la clos
(because you have first class slots ... that I want in pharo -- see the
subliminal message).
Stef
The idea is that slots define how they should be initialized. This could be
just a value like in CLOS, but is preferably something a lot more elaborate.
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
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
On Apr 3, 2011, at 12:23 PM, Toon Verwaest wrote:
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
Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
On 04/03/2011 06:46 PM, Alexandre Bergel wrote: Thanks I should digest it. Now what I did not like in our stateful model was that - in introduced too many operators - I'm not sure I like trait state to be private because it changes a lot the smalltalk model At least, Toon will avoid all the problems we had with the renaming and unwanted name clashed. Trait's accessors and mutators should then do their job. Alexandre And since we would apply slot aliasing, we only need to provide the alias to the users. It's an extra way of weaving traits, not just getter+setter anymore. This means that they don't become public accessors! The slots are used for private access. Toon
Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click
Out of the box, system browsers are opening with a scroll bar between the lists and code pane. Click on it, and the bar disappears. Curious which vm was in use, I tried: SmalltalkImage current vmVersion 'Squeak3.10.2 of ''5 June 2008'' [latest update: #7179]' Looks weird?? Ask the vm itself. In a terminal (I think in the correct place): ./squeakvm -version 4.0.3-2202 #1 XShm Tue Apr 13 11:56:47 PDT 2010 gcc 4.3.2 Linux vps2.piumarta.com 2.6.18-028stab053.10-ent #1 SMP Thu Feb 28 20:34:08 MSK 2008 i686 GNU/Linux plugin path: /somewhere/Contents/Linux/ [default: /somewhere/Pharo-1.2.1/Contents/Linux/] Ubuntu Lucid. oCompletion is not going away easily. No denigration of the hard work that went into it, I want to simply turn it off, read what it otherwise can't help covering, and type myself. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Marcus Denker [marcus.den...@inria.fr] Sent: Sunday, April 03, 2011 11:31 AM To: Pharo Development Subject: [Pharo-project] [ANN] For testing: 1.2.1 One-Click As with 1.2 in general, I gave up on auto build... as we will move to the VMs we build ourselfes in 1.3, the idea is to keep 1.2 as simple as possible. - I added the windows vm that Torsten send me - I did not update the mac or unix vm from 1.1.1... https://gforge.inria.fr/frs/download.php/28437/Pharo-1.2.1-OneClick.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click
The thing is that all things, even the smallest tiniest triviality, happens if someone *does* it. Nothing happens by itself. I'm probably very naive here; and also a bit lazy and so on... So: could you point me at a short text that describes exactly what I have to do to get any line of code into a new Pharo? Like I figured out that these syntax coloring and compiling of traits happens in a strange scope... how can I push this immediately back? I just got used to always including these changes in my own repos since I didn't know how to get access to such changes immediately; nor how to properly publish them. My own main goal isn't Pharo, although I really like Pharo and would like to contribute whatever I do back to Pharo. So knowing about the streamlined process will help me push the small changes I do back. And yes, sorry, I'm lazy ;-) cheers, Toon
Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click
On Sun, Apr 3, 2011 at 6:31 PM, Toon Verwaest toon.verwa...@gmail.comwrote: The thing is that all things, even the smallest tiniest triviality, happens if someone *does* it. Nothing happens by itself. I'm probably very naive here; and also a bit lazy and so on... So: could you point me at a short text that describes exactly what I have to do to get any line of code into a new Pharo? It is explained in the Pharo FAQ http://www.pharo-project.org/documentation/faq How can I contribute to Pharo? Check out the wiki page HowToContributehttp://code.google.com/p/pharo/wiki/HowToContributefor a detailed description of how to submit code. There is also a screencasthttp://pharocasts.blogspot.com/2010/03/how-to-contribute-to-pharo.htmldemonstrating the process. Like I figured out that these syntax coloring and compiling of traits happens in a strange scope... how can I push this immediately back? I just got used to always including these changes in my own repos since I didn't know how to get access to such changes immediately; nor how to properly publish them. My own main goal isn't Pharo, although I really like Pharo and would like to contribute whatever I do back to Pharo. So knowing about the streamlined process will help me push the small changes I do back. And yes, sorry, I'm lazy ;-) cheers, Toon
Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click
On Apr 3, 2011, at 5:31 PM, Marcus Denker wrote: As with 1.2 in general, I gave up on auto build... as we will move to the VMs we build ourselfes in 1.3, the idea is to keep 1.2 as simple as possible. - I added the windows vm that Torsten send me - I did not update the mac or unix vm from 1.1.1... https://gforge.inria.fr/frs/download.php/28437/Pharo-1.2.1-OneClick.zip And a Cog version: https://gforge.inria.fr/frs/download.php/28439/Pharo-1.2.1-CogOneClick.zip This is the 1.1.1 OneClick where I replaced the image and moved in all the files of Eliot's latest Cog release (sometimes renamed). Tested just for MacOS. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
[Pharo-project] Pharo 1.3 process
Hi, as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't seen 1.2.0, no big party, no 1 million download contest, BBC announcement... :) I wonder how we can improve the process for 1.3. I'm thinking about: - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo 1.3. - freezing early to have shorter release and have less stuff to fix with maximum energy (it seems energy go down quickly in the fixing period) - a failing test should be highest priority: it's easier to fix a broken feature/test as soon as it appears - one guy should drive the release (I feel that Mariano did this for Pharo 1.1 and we know who we should talk to). Any idea ? Laurent.
Re: [Pharo-project] Pharo 1.3 process
On Apr 3, 2011, at 7:13 PM, laurent laffont wrote: Hi, as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't seen 1.2.0, no big party, no 1 million download contest, BBC announcement... :) I wonder how we can improve the process for 1.3. Yes, that is why I did not want to decouple the release of Core from Full. Because is drags out the release so far that we can not announce it But we could not, as people (inkluding those maintaining packages of Full) only look at released core images... And so I did a Core 1.2. And people looked at it. Finally. So I did a 1.2.1, and only after releasing that, people looked at it, so I even started a 1.2.2 today.. and now I am dead. I'm thinking about: - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo 1.3. - freezing early to have shorter release and have less stuff to fix with maximum energy (it seems energy go down quickly in the fixing period) - a failing test should be highest priority: it's easier to fix a broken feature/test as soon as it appears - one guy should drive the release (I feel that Mariano did this for Pharo 1.1 and we know who we should talk to). - Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
[Pharo-project] Let's get rid of Core vs. Full
Hi, So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. 1) We don't develop the system using the tools that we tell people to use. - bugs don't get fixed - there is no pressure on improving the tools - we can't use the advanced tools while developing the Core. 2) We integrate *far* too late. - merging in the tools of Dev a week before the big release *will* fail, as they are not tested. 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. - People even expect to be able to shrink it more, which in turn we do not test. 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible. 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working. So I vote for abandoning Core vs. Dev for 1.3. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Pharo 1.3 process
On Sun, Apr 3, 2011 at 7:18 PM, Marcus Denker marcus.den...@inria.frwrote: On Apr 3, 2011, at 7:13 PM, laurent laffont wrote: Hi, as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't seen 1.2.0, no big party, no 1 million download contest, BBC announcement... :) I wonder how we can improve the process for 1.3. Yes, that is why I did not want to decouple the release of Core from Full. Because is drags out the release so far that we can not announce it But we could not, as people (inkluding those maintaining packages of Full) only look at released core images... And so I did a Core 1.2. And people looked at it. Finally. So I did a 1.2.1, and only after releasing that, people looked at it, so I even started a 1.2.2 today.. and now I am dead. Time for a big real good fresh beer ;) I'm thinking about: - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo 1.3. - freezing early to have shorter release and have less stuff to fix with maximum energy (it seems energy go down quickly in the fixing period) - a failing test should be highest priority: it's easier to fix a broken feature/test as soon as it appears - one guy should drive the release (I feel that Mariano did this for Pharo 1.1 and we know who we should talk to). - Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. Yes, 2 images seems hard to maintain and hard to understand for newcomers. May be we can have: - Metacello configurations tested separately in Pharo-Clients in Hudson (like PetitParser, Seaside, ...) - drop the ones that don't have tests - drop actual Pharo, rename PharoCore = Pharo. - GUI tool in Pharo to easy load Metacello configurations (some stuff must be easy to load for newbies, especially help) Laurent. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Let's get rid of Core vs. Full
Rather than abandon core vs full, here's a thought on a slightly different approach... Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ... Use the build server to run tests against the CORE and the set of CORE tools... You'll be dragging along more code as you do new development on the CORE, but at least the work of keeping the FULL version in synch will be spread across the whole CORE development cycle rather than concentrated at the end ... Just some ideas:) Dale On Apr 3, 2011, at 10:31 AM, Marcus Denker wrote: Hi, So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. 1) We don't develop the system using the tools that we tell people to use. - bugs don't get fixed - there is no pressure on improving the tools - we can't use the advanced tools while developing the Core. 2) We integrate *far* too late. - merging in the tools of Dev a week before the big release *will* fail, as they are not tested. 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. - People even expect to be able to shrink it more, which in turn we do not test. 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible. 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working. So I vote for abandoning Core vs. Dev for 1.3. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Pharo 1.3 process
On Apr 3, 2011, at 7:12 PM, laurent laffont wrote: Hi, as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't seen 1.2.0, no big party, no 1 million download contest, BBC announcement... :) I wonder how we can improve the process for 1.3. I'm thinking about: - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo 1.3. we will not start 1.4 before 1.3 is at least one month in beta. - freezing early to have shorter release and have less stuff to fix with maximum energy (it seems energy go down quickly in the fixing period) this is what we did. We got now 3 months of beta and result: nobody look at it - a failing test should be highest priority: it's easier to fix a broken feature/test as soon as it appears yes but if nobody look at them, does it make a difference? - one guy should drive the release (I feel that Mariano did this for Pharo 1.1 and we know who we should talk to). marcus did that and this is not the problem. Any idea ? We should no have pharo-dev just pharo-core + RB + oCompletion + shout in the core. Laurent.
Re: [Pharo-project] Pharo 1.3 process
as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't seen 1.2.0, no big party, no 1 million download contest, BBC announcement... :) I wonder how we can improve the process for 1.3. Yes, that is why I did not want to decouple the release of Core from Full. Because is drags out the release so far that we can not announce it But we could not, as people (inkluding those maintaining packages of Full) only look at released core images... And so I did a Core 1.2. And people looked at it. Finally. So I did a 1.2.1, and only after releasing that, people looked at it, This is not your fault. so I even started a 1.2.2 today.. and now I am dead. Let 1.2.2 for in a couple of months. I'm thinking about: - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo 1.3. - freezing early to have shorter release and have less stuff to fix with maximum energy (it seems energy go down quickly in the fixing period) - a failing test should be highest priority: it's easier to fix a broken feature/test as soon as it appears - one guy should drive the release (I feel that Mariano did this for Pharo 1.1 and we know who we should talk to). - Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. Yes we are working on that. The missing pieces of the puzzle are coming along. Stef
Re: [Pharo-project] Pharo 1.3 process
- Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. Yes but for that we need a good browser that we can maintain. Yes, 2 images seems hard to maintain and hard to understand for newcomers. May be we can have: - Metacello configurations tested separately in Pharo-Clients in Hudson (like PetitParser, Seaside, ...) - drop the ones that don't have tests - drop actual Pharo, rename PharoCore = Pharo. - GUI tool in Pharo to easy load Metacello configurations (some stuff must be easy to load for newbies, especially help This is the idea. This is why I asked people (mariano in particular) to focus on helping metacello taking off the ground and to focus on metacello distributions. Once this is up and running. we can have Pharo and hudson loads and certifies the distributions. Stef
Re: [Pharo-project] Let's get rid of Core vs. Full
On Apr 3, 2011, at 7:31 PM, Marcus Denker wrote: Hi, So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. 1) We don't develop the system using the tools that we tell people to use. - bugs don't get fixed - there is no pressure on improving the tools - we can't use the advanced tools while developing the Core. Yes 2) We integrate *far* too late. - merging in the tools of Dev a week before the big release *will* fail, as they are not tested. yes but this is not our fault 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. - People even expect to be able to shrink it more, which in turn we do not test. 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible. 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. But marcus you should also read the metacello chapter. Did you read it? 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working. So I vote for abandoning Core vs. Dev for 1.3. Yes but we need good tool. Stef
Re: [Pharo-project] Let's get rid of Core vs. Full
I really agree with you Marcus. It sounds to me that core/dev is a black and white approach. I know there are no resources, but what do you think of starting with a minimum image and the build over more sophisticated images? -Kernel image -Core image -Image with really basic browsing/scm tools (OB, Script Manager, Shout, etc) - or developer basic -developer standard (the current dev) -developer scientific -developer web ... etc. that wouldn't result in more easier integrations? Cheers, 2011/4/3 Marcus Denker marcus.den...@inria.fr: Hi, So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. 1) We don't develop the system using the tools that we tell people to use. - bugs don't get fixed - there is no pressure on improving the tools - we can't use the advanced tools while developing the Core. 2) We integrate *far* too late. - merging in the tools of Dev a week before the big release *will* fail, as they are not tested. 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. - People even expect to be able to shrink it more, which in turn we do not test. 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible. 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working. So I vote for abandoning Core vs. Dev for 1.3. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
[Pharo-project] Odd FFI problms with Mac vms...
Norbert, Today I have found that I can get GemTools to work on the mac using Squeak 4.2.4beta1U. Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a Space is low error, because the size comes back as 1330942246849085449, instead of a reasonable number). The image is identical and the gci library file is identical in both cases, I've just switched the vm that I'm using. Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first FFI call into the library. Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call that returns the unreasonable number in 4.2.5beta1U...the argument to the function is a SmallInteger (343552513) ... at least this error gives me hope that I can figure out what's wrong with this call sooner or later ... Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the moment on the Mac for running GemTools ... Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works gives me an incentive to try getting GemTools running on PharoCore.1.2... If any of the vm or FFI guys have some insight to these problems I'd appreciate some pointers to what may be going on... Dale On Mar 30, 2011, at 10:09 AM, Norbert Hartl wrote: Am 30.03.2011 um 19:02 schrieb Johan Brichau: well... it only works with a VM up to version 4.2.2 well, right! Something I forgot to tell. That is the reason I start it from the command line :) Norbert everything beyond that ended up in a strange login error, indeed On 30 Mar 2011, at 18:19, Dale Henrichs wrote: Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem... I am glad to hear that some folks are not having trouble ... which only deepens the mystery:) Dale
Re: [Pharo-project] Odd FFI problms with Mac vms...
On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote: Norbert, Today I have found that I can get GemTools to work on the mac using Squeak 4.2.4beta1U. Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a Space is low error, because the size comes back as 1330942246849085449, instead of a reasonable number). The image is identical and the gci library file is identical in both cases, I've just switched the vm that I'm using. Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first FFI call into the library. Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call that returns the unreasonable number in 4.2.5beta1U...the argument to the function is a SmallInteger (343552513) ... at least this error gives me hope that I can figure out what's wrong with this call sooner or later ... Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the moment on the Mac for running GemTools ... Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works gives me an incentive to try getting GemTools running on PharoCore.1.2... If any of the vm or FFI guys have some insight to these problems I'd appreciate some pointers to what may be going on... Here's the FFI call: apiGciFetchObjImpl: anOopType apicall: ulong 'GciFetchObjImpl' (OopType64) ^self externalCallFailed and OopType64 is a subclass of ExternalStructure with the following fields declaration: fields (OopType64 defineFields) ^#(asOop 'ulonglong'). and the function declaration from the header file: int GciFetchObjImpl(OopType theObject); Dale
Re: [Pharo-project] Odd FFI problms with Mac vms...
On Apr 3, 2011, at 12:48 PM, Dale Henrichs wrote: On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote: Norbert, Today I have found that I can get GemTools to work on the mac using Squeak 4.2.4beta1U. Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a Space is low error, because the size comes back as 1330942246849085449, instead of a reasonable number). The image is identical and the gci library file is identical in both cases, I've just switched the vm that I'm using. Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first FFI call into the library. Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call that returns the unreasonable number in 4.2.5beta1U...the argument to the function is a SmallInteger (343552513) ... at least this error gives me hope that I can figure out what's wrong with this call sooner or later ... Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the moment on the Mac for running GemTools ... Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works gives me an incentive to try getting GemTools running on PharoCore.1.2... If any of the vm or FFI guys have some insight to these problems I'd appreciate some pointers to what may be going on... Here's the FFI call: apiGciFetchObjImpl: anOopType apicall: ulong 'GciFetchObjImpl' (OopType64) ^self externalCallFailed and OopType64 is a subclass of ExternalStructure with the following fields declaration: fields (OopType64 defineFields) ^#(asOop 'ulonglong'). and the function declaration from the header file: int GciFetchObjImpl(OopType theObject); I thought it might be suspicious that a SmallInteger was being passed in when the argument type should have been OopType, so in the Cog vm, I traced the source of the argument back to the _result_ another FFI call: apicall: OopType64 'GciNbPerform' (OopType64 char* ulong long) The result is declared as OopType64 so it looks like the result was not converted to the correct type on return...which ends up with the incorrect argument coming in .. When the Squeak 4.2.5beta1U runs through the same sequence of calls, the result of GciNbPerform gets correctly converted to OopType64, so that seems to be the ulitmate source of the error ... Not sure whether this is a VM issue or an FFI issue, in either case I assume that the bug exists in some C code floating around somewhere.. Dale
Re: [Pharo-project] Announcement real problems - please read and comment.
On 03.04.2011 10:35, Stéphane Ducasse wrote: On Apr 2, 2011, at 5:14 PM, Henrik Sperre Johansen wrote: On 02.04.2011 09:16, Stéphane Ducasse wrote: Henrik what is your answer to problem 1 Problem 1 - the second announcement was never sent, because the first one broke the second was blocked. we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass Because we can get the system down just because one guy can register a bug. http://forum.world.st/Another-finalization-concern-error-handling-td2989615.html It's basically the same. ?? Same basic problem, same solutions apply. I'd rather not repeat the exact same discussion. Just exchange finalization with announcement delivery when reading the thread. Cheers, Henry
Re: [Pharo-project] Let's get rid of Core vs. Full
On Apr 3, 2011, at 9:34 PM, Hernán Morales Durand wrote: I really agree with you Marcus. It sounds to me that core/dev is a black and white approach. I know there are no resources, but what do you think of starting with a minimum image and the build over more sophisticated images? -Kernel image -Core image -Image with really basic browsing/scm tools (OB, Script Manager, Shout, etc) - or developer basic -developer standard (the current dev) -developer scientific -developer web ... etc. that wouldn't result in more easier integrations? I'm not sure that you want a lot of different setups because it means checking problems due to interactions. So far we cannot maintain 2 so I do not see why more would help. a core + packages + a dsitribution browser to load certified distributions we want a mini-core + a set of maintained pharo packages + a configuration files When we work on them - new mini core + automatic publication of new packages + new configuration files Right now this process does not work so this is a ***pain*** I spent 2 hours one sunday to fix some stupid problem with shout in OB just because we do not have good tools on top of metacello and because loading packages is slow. Stef
Re: [Pharo-project] Issue 3949 in pharo: Coverage for Cog
Updates: Status: Closed Comment #2 on issue 3949 by stephane...@gmail.com: Coverage for Cog http://code.google.com/p/pharo/issues/detail?id=3949 Tx lukas in 12131
Re: [Pharo-project] Issue 3947 in pharo: remove #floodFill:
Updates: Status: Closed Comment #1 on issue 3947 by stephane...@gmail.com: remove #floodFill: http://code.google.com/p/pharo/issues/detail?id=3947 in 13131
Re: [Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code
Comment #1 on issue 3946 by stephane...@gmail.com: remove some more uniclasses/player related code http://code.google.com/p/pharo/issues/detail?id=3946 Argh! Terrible design add yours to the list no comment.
Re: [Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code
Comment #2 on issue 3946 by stephane...@gmail.com: remove some more uniclasses/player related code http://code.google.com/p/pharo/issues/detail?id=3946 in 13131
Re: [Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code
Updates: Status: closed Comment #3 on issue 3946 by stephane...@gmail.com: remove some more uniclasses/player related code http://code.google.com/p/pharo/issues/detail?id=3946 (No comment was entered for this change.)
Re: [Pharo-project] Issue 3945 in pharo: Remove squeakland plugin methods from SystemVersion
Updates: Status: Closed Comment #1 on issue 3945 by stephane...@gmail.com: Remove squeakland plugin methods from SystemVersion http://code.google.com/p/pharo/issues/detail?id=3945 in 13131
Re: [Pharo-project] Issue 3944 in pharo: ClassHierarchyTest needs to be moved to KernelTests package
Updates: Status: Closed Comment #2 on issue 3944 by stephane...@gmail.com: ClassHierarchyTest needs to be moved to KernelTests package http://code.google.com/p/pharo/issues/detail?id=3944 in 13131
[Pharo-project] [update 1.3] #13131
13131 - - Issue 3949: Coverage for Cog. Thanks Lukas Renggli. - Issue 3947: remove #floodFill:. Thanks Marcus Denker. - Issue 3946: remove some more uniclasses/player related code. Thanks Marcus Denker. - Issue 3945: Remove squeakland plugin methods from SystemVersion. Thanks Marcus Denker. - Issue 3944: ClassHierarchyTest needs to be moved to KernelTests package. Thanks Marcus Denker. - Removed SoftSqueak Theme. Repackage GLMTheme - Rename them. Stef
Re: [Pharo-project] Issue 3877 in pharo: Check reduced complexity for UI themes
Comment #2 on issue 3877 by stephane...@gmail.com: Check reduced complexity for UI themes http://code.google.com/p/pharo/issues/detail?id=3877 first step in that direction done: repackaged theme, rename Glamour ones, removed soft squeak
Re: [Pharo-project] Issue 3912 in pharo: Circular dependency with GLMOrangeUITheme
Updates: Status: Closed Comment #3 on issue 3912 by stephane...@gmail.com: Circular dependency with GLMOrangeUITheme http://code.google.com/p/pharo/issues/detail?id=3912 So far I move all the themes into Polymorph. Removed SoftSqueak, started to rename Glamour (should rename the classes). So I will close this issue since the circular dependency should be over now. In 13131
