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

Re: [Pharo-project] Pharo 1.3 process

by StÃ©phane Ducasse

>> >> >> 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

April 3, 2011

Re: [Pharo-project] Pharo 1.3 process

by StÃ©phane Ducasse

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.

April 3, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by Dale Henrichs

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. > >

April 3, 2011

Re: [Pharo-project] Pharo 1.3 process

by laurent laffont

On Sun, Apr 3, 2011 at 7:18 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > 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. > >

April 3, 2011

[Pharo-project] Let's get rid of Core vs. Full

by Marcus Denker

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.

April 3, 2011

Re: [Pharo-project] Pharo 1.3 process

by Marcus Denker

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.

April 3, 2011

[Pharo-project] Pharo 1.3 process

by laurent laffont

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.

April 3, 2011

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

by Marcus Denker

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.

April 3, 2011

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

by Alexandre Bergel

>> 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 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 3, 2011

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

by Mariano Martinez Peck

On Sun, Apr 3, 2011 at 6:31 PM, Toon Verwaest <toon.verwaest(a)gmail.com>wrote: > > 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 HowToContribute<http://code.google.com/p/pharo/wiki/HowToContribute>for a detailed description of how to submit code. There is also a screencast<http://pharocasts.blogspot.com/2010/03/how-to-contribute-to-pharo.html>demonstrating 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 > >

April 3, 2011