On Jan 20, 2014, at 12:48 PM, Pharo4Stef <pharo4Stef(a)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(a)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/gtoolki…
>
> 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
PLEIAD lab - Computer Science Department (DCC) - University of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch