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

Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click

by Toon Verwaest

> 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

April 3, 2011

Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click

by Marcus Denker

On Apr 3, 2011, at 6:17 PM, Schwab,Wilhelm K wrote: > 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. > Yes, a known bug open since Feb 24, 2011. http://code.google.com/p/pharo/issues/detail?id=3754 > 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): > Yes, we just use the same VM than in the 1.1 OneClick. If someone can do better, please do. I can not, I am exhausted.... > ./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. > Yes, the details in interaction of both ecompletion and the magical treatment of special characters ()'' should be improved... One of the first steps to do this is to actually use these things on a daily basis. With the Core vs. Full image, there is the huge problem that after the first 100 updates are in the unstable, I use the unstable. And there is no Full for unstable, bug report from Mar 20, 2011: http://code.google.com/p/pharo/issues/detail?id=3837 The thing is that all things, even the smallest tiniest triviality, happens if someone *does* it. Nothing happens by itself. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 3, 2011

Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click

by Schwab,Wilhelm K

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Marcus Denker [marcus.denker(a)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.

April 3, 2011

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

by Toon Verwaest

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

April 3, 2011

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

by Toon Verwaest

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 problem at all since the state is only seen by that trait. And their methods are only compiled on that trait, so the methods will always know exactly which of the slots you are referring to. >> >> I hope this helps somehow :) Otherwise ... wait for the paper ;) >> >> cheers, >> Toon >> >

April 3, 2011

Re: [Pharo-project] Issue 3645 in pharo: Update Hudson One-Click build files for 1.2

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 3645 by marcus.d...(a)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.

April 3, 2011

[Pharo-project] [ANN] For testing: 1.2.1 One-Click

by Marcus Denker

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.

April 3, 2011

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

by pharo＠googlecode.com

Updates: Status: Started Comment #11 on issue 3754 by marcus.d...(a)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.)

April 3, 2011

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

by StÃ©phane Ducasse

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 >

April 3, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by Patrick Barroca

On Sat, Apr 2, 2011 at 10:38 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > > On Sat, Apr 2, 2011 at 10:14 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> 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

April 3, 2011