On 20 Jan 2014, at 19:47, Johan Fabry <jfabry@dcc.uchile.cl> wrote:

Stef, are you asking for aspects? :-P

No just managing mess :)

On Jan 20, 2014, at 12:48 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:

...

this is not only loading the challenges. we should handle cross cutting changes.

Stef

On 20 Jan 2014, at 11:05, Tudor Girba <tudor@tudorgirba.com> 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...

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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev