19 Jan
2014
19 Jan
'14
12:29 a.m.
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).
[image: Inline image 1]
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"
10:15 a.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
On 19 Jan 2014, at 00:30, Tudor Girba <tudor(a)tudorgirba.com> wrote:
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).
Very nice… using visualisation everywhere in the IDE could be extremely
interesting…
Does graphET already have support for Sparklines?
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&topic…
This could be interesting to embed small visuals like that everywhere (not just for time
related
things…).
Of course I have no idea for what for real… ;-)
Marcus
2:16 p.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
Currently we do not have a proper support of sparklines. But this is in our roadmap.
Cheers,
Alexandre
On Jan 19, 2014, at 6:15 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote:
On 19 Jan 2014, at 00:30, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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).
Very nice… using visualisation everywhere in the IDE could be extremely
interesting…
Does graphET already have support for Sparklines?
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&topic…
This could be interesting to embed small visuals like that everywhere (not just for time
related
things…).
Of course I have no idea for what for real… ;-)
Marcus
10:58 p.m.
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.
Alexandre
On Jan 18, 2014, at 8:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11:04 p.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
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.
Keep in mind that we need to take care: the problem back than was that we had
actually not a good situation: we developed one image, but then people used other tools
when they downloaded the final version.
This means that details never got fixed and improved: why put a lot of effort into getting
the details in the browser correct if everyone will use another browser?
And that other browser did not see a lot of work, either, because it was not part of the
development effort of Pharo itself.
It was actually quite bad. We need to really take care to not have that again.
And we do *not* have the manpower to manage two sets of tools anyway.
Marcus
20 Jan
20 Jan
10:51 a.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
Hi,
First, I am happy to see that these efforts get noticed :). This is just
the most visible part of the tremendous work happening in Moose.
Then, I think it is indeed important to start approaching the problem of
the direction of the IDE explicitly. Ideally, we should indeed have one
strong and novel IDE. I think there is great potential there.
Cheers,
Doru
On Sun, Jan 19, 2014 at 11:04 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote;wrote:
On 19 Jan 2014, at 22:58, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
Keep in mind that we need to take care:
the problem back than was that we
had actually not a good situation: we developed one image, but then people
used other tools
when they downloaded the final version.
This means that details never got fixed and improved: why put a lot of
effort into getting the details in the browser correct if everyone will use
another browser?
And that other browser did not see a lot of work, either, because it was
not part of the development effort of Pharo itself.
It was actually quite bad. We need to really take care to not have that
again.
And we do *not* have the manpower to manage two sets of tools anyway.
Marcus
--
www.tudorgirba.com
"Every thing has its own flow"
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.
8:53 a.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
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:
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11:05 a.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
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:
> >
> >> 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
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
>
>
--
www.tudorgirba.com
"Every thing has its own flow"
4:48 p.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7:47 p.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
Stef, are you asking for aspects? :-P
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
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
9 p.m.
New subject: [Pharo-dev] [ANN] MessageTally in GTInspector
On 20 Jan 2014, at 19:47, Johan Fabry <jfabry(a)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(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
---> 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3989
days inactive
3991
days old
11 comments
7 participants
participants (7)
-
Alexandre Bergel -
Ben Coman -
Johan Fabry -
Marcus Denker -
Pharo4Stef -
Stéphane Ducasse -
Tudor Girba