On 20 Jan 2014, at 19:47, Johan Fabry <[email protected]> wrote: > > Stef, are you asking for aspects? :-P
No just managing mess :) > > On Jan 20, 2014, at 12:48 PM, Pharo4Stef <[email protected]> wrote: > >> this is not only loading the challenges. we should handle cross cutting >> changes. >> >> Stef >> >> On 20 Jan 2014, at 11:05, Tudor Girba <[email protected]> wrote: >> >>> I think I understand the implications. >>> >>> Moose comes with these tools out of the box, so for people that work with >>> Moose it makes perfect sense to work with tools from the future :). Btw, >>> you can work with the bare GToolkit (only the components needed for Pharo) >>> from here: >>> https://ci.inria.fr/moose/job/gtoolkit/lastSuccessfulBuild/artifact/gtoolkit.zip >>> >>> I also think that the dependency problem is an important one, but it is >>> orthogonal with the work on producing the IDE. I want to get these tools in >>> Pharo, and I want to spend the energy in ensuring modularity, too. The >>> components of the GToolkit are modular now. If at some point we decide to >>> integrate them, the simplest thing we can do is to create the job that >>> ensures their unloadability before the integration. >>> >>> Another option is to go back to a Core image and build the working image. I >>> think we should reevaluate this option in the light of the latest >>> Monticello speedups. For example, the current build time for a GToolkit >>> image is 1.5 mins (loads Glamour, Roassal, Graph-ET, GToolkit) which is not >>> a lot. >>> >>> Doru > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Moose-dev mailing list > [email protected] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
