To be able to work without GT-Playground

It open an inspector embedded within the debugger. this is ultra cool, seriously.

I made a contrived example here:

https://dl.dropboxusercontent.com/u/31543901/TMP/InspectorInTheDebugger.mov

There is really something great in the GT tools. At the very beginning I was not convinced of it. Now I am fully. 

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Jun 26, 2014, at 10:40 AM, stepharo <[hidden email]> wrote:

What is cmd-o

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I've always viewed Moose as closer to an end-user tool.  I want to open the tool up and be able to start using it, not digging around trying to remember what arcane names I need to load to get the parts I need to do analysis.  (Is it Arki? EyeSee? GraphET?  GraphET3?  which XML?) Bah, jsut ahve the right tools loaded so I, an end user, can start using them.

As a non-end-user, isn't that what Pharo gives you - the starting point that you can just load the parts of Moose that you want into your image?  Make the stuff loadable from there that you want.

On Thu, Jun 26, 2014 at 8:32 AM, stepharo <[hidden email]> wrote:

Ok so I'm sad because you miss my point, so reread my mail.
    Why should these tools be loaded?
    Why can't they be loaded on demand?

Hi Stef,

Of course the image is a cache, but I do not understand what you are referring to.

We do not develop Moose by copying images around. We load lots of configurations. I agree that we should refactor some of them, and we should remove some of them. Hismo is indeed a good candidate for removing.

But, still the goal of a distribution is to pack together code that brings enough value for a certain audience. And, XML is so pervasive, at least in the projects I was exposed to, that it does not make much sense to claim easy data analysis without supporting it out of the box. Btw, JSON starts to be a candidate as well :).

Btw, from a pragmatic point of view, why do you necessarily need to ignoreImage?

Cheers,

Doru

On Thu, Jun 26, 2014 at 4:50 PM, stepharo <[hidden email]> wrote:

Moose is right now bloated because it has two versions of Roassal and two of Graph-ET.

But, XML is a prerequisite in the business of analysis. I am still to encounter a serious analysis project that did not involve some XML. Actually, at this point, as Moose gets to be used in all sorts of non-code related projects, I feel more that FAMIX makes the system bloated.

This is plain wrong.
Load a package when you need it. I would unload Hismo, FAMIX-C, and keep the minimum and not a kitchen sink.
Else you should load also
    JSON
    and many others.
Even the moose Algos should be loaded on demand.

You are not lucid on the problem. You are like these old smalltalkers that do not understand anything to modularity.
We can have a small moose image where we test that a given list of EXTERNAL packages loads correctly
and run well the tests but are not shipped by default but loadable in one click.

You confuse the system and its cache. Repeat after me: an image is a cache.
Why there is not a metacello browser just for loading moose certified packages?
Because this is the way to go for Pharo and also for Moose.
Moose is becoming untractable. I spent the day trying to find why we cannot snapshot a version of each package
and it I do not find how to make it work with MC. I will go back to my ugly solution (but this is raging because snapshotcello
was an important element) to me it should be part of metacello. But metacello is probably far too complex too.

Stef

Cheers,

Doru

On Thu, Jun 26, 2014 at 4:30 PM, stepharo <[hidden email]> wrote:

For me I think that Moose is bloated.
There are far too many packages loaded by default
    XML
    NeoCSV
    ....

Stef

On 26/6/14 12:49, Yuriy Tymchuk wrote:

It's on the original Moose job, just another archive called moose-less.zip

The problem is not in Moose. It's even not in the tools, but for now Pharo doesn't provide a good configuration mechanics. I would prefer to be asked when I start the image for the first time if I want to use the alternative theme or tools. And if I don't, I'd prefer to stay with my own setup. We don't have this, and Moose job configures the image for everyone (without asking of course). That's I archive the image before the script is being run, so I can download it and set it up for myself.

For example I use dark theme and apple fonts, but I can't force others to use my configuration.

Uko 

Sent from my iPhone

On 26 Jun 2014, at 12:03, stepharo <[hidden email]> wrote:

Where is your ci?
Because
Hi yuri

where is your ci?
Because moose is becoming bloated and I think that we should rethink it.

Stef

The thing is that after loading all packages current build job runs magical script that sets up theme, tools and so on. Now moose-less image is archived before this script is being run. So then I can set up the inspector and so on by myself, while everything other remains like in vanilla pharo.

Uko

Stef

Uko

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Moose has a VERY steep learning curve. And I cannot call it end-user tool. I can call it high-skilled-shaman-tool.

Uko

On 26 Jun 2014, at 17:47, Chris Cunningham <[hidden email]> wrote:

I've always viewed Moose as closer to an end-user tool.  I want to open the tool up and be able to start using it, not digging around trying to remember what arcane names I need to load to get the parts I need to do analysis.  (Is it Arki? EyeSee? GraphET?  GraphET3?  which XML?) Bah, jsut ahve the right tools loaded so I, an end user, can start using them.

As a non-end-user, isn't that what Pharo gives you - the starting point that you can just load the parts of Moose that you want into your image?  Make the stuff loadable from there that you want.

On Thu, Jun 26, 2014 at 8:32 AM, stepharo <[hidden email]> wrote:

Ok so I'm sad because you miss my point, so reread my mail.
    Why should these tools be loaded?
    Why can't they be loaded on demand?

Hi Stef,

Of course the image is a cache, but I do not understand what you are referring to.

We do not develop Moose by copying images around. We load lots of configurations. I agree that we should refactor some of them, and we should remove some of them. Hismo is indeed a good candidate for removing.

But, still the goal of a distribution is to pack together code that brings enough value for a certain audience. And, XML is so pervasive, at least in the projects I was exposed to, that it does not make much sense to claim easy data analysis without supporting it out of the box. Btw, JSON starts to be a candidate as well :).

Btw, from a pragmatic point of view, why do you necessarily need to ignoreImage?

Cheers,

Doru

On Thu, Jun 26, 2014 at 4:50 PM, stepharo <[hidden email]> wrote:

Moose is right now bloated because it has two versions of Roassal and two of Graph-ET.

But, XML is a prerequisite in the business of analysis. I am still to encounter a serious analysis project that did not involve some XML. Actually, at this point, as Moose gets to be used in all sorts of non-code related projects, I feel more that FAMIX makes the system bloated.

This is plain wrong.
Load a package when you need it. I would unload Hismo, FAMIX-C, and keep the minimum and not a kitchen sink.
Else you should load also
    JSON
    and many others.
Even the moose Algos should be loaded on demand.

You are not lucid on the problem. You are like these old smalltalkers that do not understand anything to modularity.
We can have a small moose image where we test that a given list of EXTERNAL packages loads correctly
and run well the tests but are not shipped by default but loadable in one click.

You confuse the system and its cache. Repeat after me: an image is a cache.
Why there is not a metacello browser just for loading moose certified packages?
Because this is the way to go for Pharo and also for Moose.
Moose is becoming untractable. I spent the day trying to find why we cannot snapshot a version of each package
and it I do not find how to make it work with MC. I will go back to my ugly solution (but this is raging because snapshotcello
was an important element) to me it should be part of metacello. But metacello is probably far too complex too.

Stef

Cheers,

Doru

On Thu, Jun 26, 2014 at 4:30 PM, stepharo <[hidden email]> wrote:

For me I think that Moose is bloated.
There are far too many packages loaded by default
    XML
    NeoCSV
    ....

Stef

On 26/6/14 12:49, Yuriy Tymchuk wrote:

It's on the original Moose job, just another archive called moose-less.zip

The problem is not in Moose. It's even not in the tools, but for now Pharo doesn't provide a good configuration mechanics. I would prefer to be asked when I start the image for the first time if I want to use the alternative theme or tools. And if I don't, I'd prefer to stay with my own setup. We don't have this, and Moose job configures the image for everyone (without asking of course). That's I archive the image before the script is being run, so I can download it and set it up for myself.

For example I use dark theme and apple fonts, but I can't force others to use my configuration.

Uko 

Sent from my iPhone

On 26 Jun 2014, at 12:03, stepharo <[hidden email]> wrote:

Where is your ci?
Because
Hi yuri

where is your ci?
Because moose is becoming bloated and I think that we should rethink it.

Stef

The thing is that after loading all packages current build job runs magical script that sets up theme, tools and so on. Now moose-less image is archived before this script is being run. So then I can set up the inspector and so on by myself, while everything other remains like in vanilla pharo.

Uko

Stef

Uko

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev