20 Jan
2014
20 Jan
'14
4:48 p.m.
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
On Mon, Jan 20, 2014 at 8:53 AM, Stéphane Ducasse <stephane.ducasse(a)inria.fr>
wrote:
On 19 Jan 2014, at 22:58, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
This is gorgeous.
The Moose distribution of Pharo looks like to be better suitable for code development
than the vanilla one. This makes me remember the Development image of Damien.
Do you really ***understand*** the implications?
Because once people will start to put dependencies everytwhere on roassal and start to
run smalllint on your code and ….
that you will have to follow it and merge and ….
you will look at the problem.
Without unload process that is systematically exercised, tools to manage dependencies
and a process to build and support modular images we will end up with a monolithic
system.
I just tried to unload ProfStef and it was full of left instance behind. I tried to
unload Nautilus for example and RB.
Stef
Alexandre
On Jan 18, 2014, at 8:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow" Hi,
The GTInspector just became a performance analysis tool, too. You can simply inspect a
MessageTally and you get several useful views that help you identify performance
problems.
You can read a more detailed description here:
http://www.humane-assessment.com/blog/assessing-pharo-performance-with-gtin…
As an appetizer, I attached a screenshot with a Graph-ET chart (thank you Daniel Aviv for
developing this engine).
<MessageTally-chart.png>
To play with the code, you can just work in the latest Moose 5.0 image:
https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-…
Please let me know what you think.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.