what makes moose

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

what makes moose

Tudor Girba-2
Hi Stef,


On Sun, Aug 11, 2013 at 3:19 PM, Stéphane Ducasse <[hidden email]> wrote:
...
To me I think that it would be good to have a Moosedev and a MooseDeployment part because we have many differnt frameworks in the system

This is certainly an important topic and it warrants its own discussion.

I think we should not distinguish between MooseDev and MooseDeployment :).

My vision goes like this:
- Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions.
- Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo.
- We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them. So we want all the Pharo specific tools in the large distribution, too.

All in all, we now go towards:
- GToolkit for everyone that wants to develop in Pharo only.
- Moose for every other language (and it includes GToolkit).

Cheers,
Doru

--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: what makes moose

Stéphane Ducasse
...
To me I think that it would be good to have a Moosedev and a MooseDeployment part because we have many differnt frameworks in the system

This is certainly an important topic and it warrants its own discussion.

I think we should not distinguish between MooseDev and MooseDeployment :).

I know but now Moose is a large kitchen sink.

I will discuss with the synectique guys because I think that when we deploy a tool we do not need half of Moose and after we
cry for space. So we will see what we will do. Right now I do not want to manage my own Moose but if the company needs it, then I will do it
because I'm not spending my week-ends and more just for the fun of it. I have better things to do. 

With your vision Pharo would be the sum of all its projects and I want exactly the inverse: a small core and 
a modular infrastructure so that people can load what they need. 
Now you know like me that this is not in opposition with the other scenario ;)
I think that learning how to deploy is the best way to get the best of both scenario: (1) customed under control deployement (2) full Moose. 

My vision goes like this:
- Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions.
- Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo.
- We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them.

We just want clients using our tools because this is even more difficult to find the other clients.
If we encounter clients that can accept to understand that they can script their own tools 
this will be a different story but a modular infrastructure support both. 

So we want all the Pharo specific tools in the large distribution, too.

All in all, we now go towards:
- GToolkit for everyone that wants to develop in Pharo only.
- Moose for every other language (and it includes GToolkit).

Cheers,
Doru

--

"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
Reply | Threaded
Open this post in threaded view
|

Re: what makes moose

Tudor Girba-2
Hi,


On Sun, Aug 11, 2013 at 9:34 PM, Stéphane Ducasse <[hidden email]> wrote:
...
To me I think that it would be good to have a Moosedev and a MooseDeployment part because we have many differnt frameworks in the system

This is certainly an important topic and it warrants its own discussion.

I think we should not distinguish between MooseDev and MooseDeployment :).

I know but now Moose is a large kitchen sink.

It could be a sink, but it's actually not large. With everything included, you get around 2200 classes (if you take Mondrian out, it's about 2000). Pharo 2.0 has something like 10'000 classes.


I will discuss with the synectique guys because I think that when we deploy a tool we do not need half of Moose and after we
cry for space.

I think you are mixing arguments. The Moose image is somewhere around 50 MB right now, but that is without any cleaning. It's true that it would be cool to have it smaller. Your space problems start when you run into 1GB or so, so the initial space is not really the issue.


So we will see what we will do. Right now I do not want to manage my own Moose but if the company needs it, then I will do it
because I'm not spending my week-ends and more just for the fun of it. I have better things to do. 

This does not sound constructive. It seems to me that all the issue was generated by the loading problem. However, this has almost nothing to do with Moose, but with the support that comes with the underlying infrastructure. Every significant Pharo project is likely to have the same loading problems, and I was thinking that we are working towards a solution that will benefit everyone. And yes, we need better tool support but I think that finally we start to see the road.

So, let's have a dialogue. You make explicit what you need and then we see what the real issue is. But, I think you know that :).


With your vision Pharo would be the sum of all its projects and I want exactly the inverse: a small core and 
a modular infrastructure so that people can load what they need. 

But, Moose is modular. We have build jobs for every important component to ensure that each of them is loadable separately. All you have to do is pick the components you want, and assemble your own image. It's just that we release one image for simplicity of communication, not of deployment.

I am sure we can get more modular (for example, FAMIX and Finder could be modularized), but we need the use cases to figure out what is the most useful way to cut.


Now you know like me that this is not in opposition with the other scenario ;)
I think that learning how to deploy is the best way to get the best of both scenario: (1) customed under control deployement (2) full Moose. 

I really see no problem with deploying, but perhaps I do not understand what you refer to.

My vision goes like this:
- Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions.
- Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo.
- We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them.

We just want clients using our tools because this is even more difficult to find the other clients. 
If we encounter clients that can accept to understand that they can script their own tools 
this will be a different story but a modular infrastructure support both. 

Let's get more concrete. What part of the current Moose Suite would you not need in your image? Or better yet, what are parts that you need in your image?

Cheers,
Doru


So we want all the Pharo specific tools in the large distribution, too.

All in all, we now go towards:
- GToolkit for everyone that wants to develop in Pharo only.
- Moose for every other language (and it includes GToolkit).

Cheers,
Doru

--

"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




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: what makes moose

Stéphane Ducasse

It could be a sink, but it's actually not large. With everything included, you get around 2200 classes (if you take Mondrian out, it's about 2000). Pharo 2.0 has something like 10'000 classes.


I will discuss with the synectique guys because I think that when we deploy a tool we do not need half of Moose and after we
cry for space.

I think you are mixing arguments. The Moose image is somewhere around 50 MB right now, but that is without any cleaning. It's true that it would be cool to have it smaller. Your space problems start when you run into 1GB or so, so the initial space is not really the issue.


So we will see what we will do. Right now I do not want to manage my own Moose but if the company needs it, then I will do it
because I'm not spending my week-ends and more just for the fun of it. I have better things to do. 

This does not sound constructive. It seems to me that all the issue was generated by the loading problem. However, this has almost nothing to do with Moose, but with the support that comes with the underlying infrastructure. Every significant Pharo project is likely to have the same loading problems, and I was thinking that we are working towards a solution that will benefit everyone. And yes, we need better tool support but I think that finally we start to see the road.

My remark is not that I was raging about loading. I worked to improve Moose and this was fun (just long feedback loop - I will see if I can start to build a
configuration validator but I want to finish my open tasks). It just took me friday full day and sunday full day. 
I wonder why I got all the problems showing up in my face.

My remark is that if a business reason led me to think that we should not ship half of moose then
- either the current config support it
- or it does not and we can modify
- or I will do it in my corner.
No more. 
In particular yesterday I was happy to find the bug in the dependencies because else I was thinking that I would have to use reloader because
I do not want to have to deal with Metacello internals. 

So, let's have a dialogue. You make explicit what you need and then we see what the real issue is. But, I think you know that :).

my concern is that Moose is large and more important: there is no real experience to create working subsets nicely working together
so it means that when we will need it we will face problems (i'm not talking about mondrian, glamour, GTtoolkit here) more Moose.

But, Moose is modular. We have build jobs for every important component to ensure that each of them is loadable separately. All you have to do is pick the components you want, and assemble your own image. It's just that we release one image for simplicity of communication, not of deployment.

I am sure we can get more modular (for example, FAMIX and Finder could be modularized), but we need the use cases to figure out what is the most useful way to cut.

I'm not thinking that we should over optimise. Just exercise modularity
And right now I see a lot of cherry picking to build a smaller Moose.

Now you know like me that this is not in opposition with the other scenario ;)
I think that learning how to deploy is the best way to get the best of both scenario: (1) customed under control deployement (2) full Moose. 

I really see no problem with deploying, but perhaps I do not understand what you refer to.

For me the fact that I found in one try around more than 10 dependency problems made me think that we do not exercise the modular aspects
of the infrastructure. Else we would have discovered them long time ago.

My vision goes like this:
- Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions.
- Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo.
- We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them.

We just want clients using our tools because this is even more difficult to find the other clients. 
If we encounter clients that can accept to understand that they can script their own tools 
this will be a different story but a modular infrastructure support both. 

Let's get more concrete. What part of the current Moose Suite would you not need in your image? Or better yet, what are parts that you need in your image?

So far I do not know. I was just making sure I can reload everything and looking at the list I was a bit skeptical that we need all that. 
I will discuss with usman and guillaume when they are back from holidays because like that we can try to have a small moose to find dependency problems.



Cheers,
Doru


So we want all the Pharo specific tools in the large distribution, too.

All in all, we now go towards:
- GToolkit for everyone that wants to develop in Pharo only.
- Moose for every other language (and it includes GToolkit).

Cheers,
Doru

--

"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




--

"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
Reply | Threaded
Open this post in threaded view
|

Re: what makes moose

Tudor Girba-2
Hi,


On Mon, Aug 12, 2013 at 9:32 AM, Stéphane Ducasse <[hidden email]> wrote:

It could be a sink, but it's actually not large. With everything included, you get around 2200 classes (if you take Mondrian out, it's about 2000). Pharo 2.0 has something like 10'000 classes.


I will discuss with the synectique guys because I think that when we deploy a tool we do not need half of Moose and after we
cry for space.

I think you are mixing arguments. The Moose image is somewhere around 50 MB right now, but that is without any cleaning. It's true that it would be cool to have it smaller. Your space problems start when you run into 1GB or so, so the initial space is not really the issue.


So we will see what we will do. Right now I do not want to manage my own Moose but if the company needs it, then I will do it
because I'm not spending my week-ends and more just for the fun of it. I have better things to do. 

This does not sound constructive. It seems to me that all the issue was generated by the loading problem. However, this has almost nothing to do with Moose, but with the support that comes with the underlying infrastructure. Every significant Pharo project is likely to have the same loading problems, and I was thinking that we are working towards a solution that will benefit everyone. And yes, we need better tool support but I think that finally we start to see the road.

My remark is not that I was raging about loading. I worked to improve Moose and this was fun (just long feedback loop - I will see if I can start to build a
configuration validator but I want to finish my open tasks). It just took me friday full day and sunday full day. 
I wonder why I got all the problems showing up in my face.

Actually, I do not understand how you got the problems, and I did not. For example, you can load the existing 4.8.1-snapshot from ConfigurationOfMoose and it loads in Pharo 2.0 (this was before your effort).

 
My remark is that if a business reason led me to think that we should not ship half of moose then
- either the current config support it
- or it does not and we can modify
- or I will do it in my corner. 
No more. 

Fair enough. Let's make sure that we end up doing option 1 or 2 :)
 
In particular yesterday I was happy to find the bug in the dependencies because else I was thinking that I would have to use reloader because
I do not want to have to deal with Metacello internals. 
So, let's have a dialogue. You make explicit what you need and then we see what the real issue is. But, I think you know that :).

my concern is that Moose is large and more important: there is no real experience to create working subsets nicely working together
so it means that when we will need it we will face problems (i'm not talking about mondrian, glamour, GTtoolkit here) more Moose.

Agreed. But, for that we need use cases.
 
But, Moose is modular. We have build jobs for every important component to ensure that each of them is loadable separately. All you have to do is pick the components you want, and assemble your own image. It's just that we release one image for simplicity of communication, not of deployment.

I am sure we can get more modular (for example, FAMIX and Finder could be modularized), but we need the use cases to figure out what is the most useful way to cut.

I'm not thinking that we should over optimise. Just exercise modularity
And right now I see a lot of cherry picking to build a smaller Moose.

Let's start with one and we go from there. I have a hard time choosing because I am too involved. 
 
Now you know like me that this is not in opposition with the other scenario ;)
I think that learning how to deploy is the best way to get the best of both scenario: (1) customed under control deployement (2) full Moose. 

I really see no problem with deploying, but perhaps I do not understand what you refer to.

For me the fact that I found in one try around more than 10 dependency problems made me think that we do not exercise the modular aspects
of the infrastructure. Else we would have discovered them long time ago.

Actually, the real problem is that the loading order of Metacello is not reliable in all cases. I mean, we are loading Moose using those dependencies all the time, but we did not get into your problems. I even released a temporary 4.8.1 and it still loads properly. So, our problem is that we have no bell ringer. And now I think this problem exists in most Metacello configurations.
 
My vision goes like this:
- Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions.
- Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo.
- We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them.

We just want clients using our tools because this is even more difficult to find the other clients. 
If we encounter clients that can accept to understand that they can script their own tools 
this will be a different story but a modular infrastructure support both. 

Let's get more concrete. What part of the current Moose Suite would you not need in your image? Or better yet, what are parts that you need in your image?

So far I do not know. I was just making sure I can reload everything and looking at the list I was a bit skeptical that we need all that. 
I will discuss with usman and guillaume when they are back from holidays because like that we can try to have a small moose to find dependency problems.

Great. Let's do that.

Doru

 


Cheers,
Doru


So we want all the Pharo specific tools in the large distribution, too.

All in all, we now go towards:
- GToolkit for everyone that wants to develop in Pharo only.
- Moose for every other language (and it includes GToolkit).

Cheers,
Doru

--

"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




--

"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




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: what makes moose

Stéphane Ducasse

On Aug 12, 2013, at 9:49 AM, Tudor Girba <[hidden email]> wrote:

Hi,


On Mon, Aug 12, 2013 at 9:32 AM, Stéphane Ducasse <[hidden email]> wrote:

It could be a sink, but it's actually not large. With everything included, you get around 2200 classes (if you take Mondrian out, it's about 2000). Pharo 2.0 has something like 10'000 classes.


I will discuss with the synectique guys because I think that when we deploy a tool we do not need half of Moose and after we
cry for space.

I think you are mixing arguments. The Moose image is somewhere around 50 MB right now, but that is without any cleaning. It's true that it would be cool to have it smaller. Your space problems start when you run into 1GB or so, so the initial space is not really the issue.


So we will see what we will do. Right now I do not want to manage my own Moose but if the company needs it, then I will do it
because I'm not spending my week-ends and more just for the fun of it. I have better things to do. 

This does not sound constructive. It seems to me that all the issue was generated by the loading problem. However, this has almost nothing to do with Moose, but with the support that comes with the underlying infrastructure. Every significant Pharo project is likely to have the same loading problems, and I was thinking that we are working towards a solution that will benefit everyone. And yes, we need better tool support but I think that finally we start to see the road.

My remark is not that I was raging about loading. I worked to improve Moose and this was fun (just long feedback loop - I will see if I can start to build a
configuration validator but I want to finish my open tasks). It just took me friday full day and sunday full day. 
I wonder why I got all the problems showing up in my face.

Actually, I do not understand how you got the problems, and I did not. For example, you can load the existing 4.8.1-snapshot from ConfigurationOfMoose and it loads in Pharo 2.0 (this was before your effort).

this is probably because it is a graph traversal and just getting in a dependent inside a project (vs the complete project) 
can lead to a really different traversal when the dependencies are lose. 
What is quite strange is that synectique just depends on Moose and does not do any cherry picking of potential subpackages right now.

So I was thinking that I would not find errors since you could reload it when I started but when I saw that he had so many missing dependencies it was good 
because it was not a problem in snapshotcello (beside the bug I found) and metacello. 


My remark is that if a business reason led me to think that we should not ship half of moose then
- either the current config support it
- or it does not and we can modify
- or I will do it in my corner. 
No more. 

Fair enough. Let's make sure that we end up doing option 1 or 2 :)

:)
The first step I would do is to go over the configurations and perform some extract methods (for projects dependencies).
Second I should find some times to build a validator.
May be looking at the group could be also a point.
Also the examples could be an clear group (may be there are)

"Core" not sure what it measn
With Example 
With Test
 
In particular yesterday I was happy to find the bug in the dependencies because else I was thinking that I would have to use reloader because
I do not want to have to deal with Metacello internals. 
So, let's have a dialogue. You make explicit what you need and then we see what the real issue is. But, I think you know that :).

my concern is that Moose is large and more important: there is no real experience to create working subsets nicely working together
so it means that when we will need it we will face problems (i'm not talking about mondrian, glamour, GTtoolkit here) more Moose.

Agreed. But, for that we need use cases.

Yes and this is what I want to see if synectique wants to invest there. We will see.
Now I will systematically rebuilt the shipped versions with snapshotcello.

 
But, Moose is modular. We have build jobs for every important component to ensure that each of them is loadable separately. All you have to do is pick the components you want, and assemble your own image. It's just that we release one image for simplicity of communication, not of deployment.

I am sure we can get more modular (for example, FAMIX and Finder could be modularized), but we need the use cases to figure out what is the most useful way to cut.

I'm not thinking that we should over optimise. Just exercise modularity
And right now I see a lot of cherry picking to build a smaller Moose.

Let's start with one and we go from there. I have a hard time choosing because I am too involved. 

We could go over the list and check if we want that.
- May be an easy one would be tests
- then Pharo development

 
Now you know like me that this is not in opposition with the other scenario ;)
I think that learning how to deploy is the best way to get the best of both scenario: (1) customed under control deployement (2) full Moose. 

I really see no problem with deploying, but perhaps I do not understand what you refer to.

For me the fact that I found in one try around more than 10 dependency problems made me think that we do not exercise the modular aspects
of the infrastructure. Else we would have discovered them long time ago.

Actually, the real problem is that the loading order of Metacello is not reliable in all cases. I mean, we are loading Moose using those dependencies all the time, but we did not get into your problems. I even released a temporary 4.8.1 and it still loads properly. So, our problem is that we have no bell ringer. And now I think this problem exists in most Metacello configurations.

I agree. :)
Especially if synectique config would be tricky I would understand but there are trivial.
 
My vision goes like this:
- Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions.
- Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo.
- We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them.

We just want clients using our tools because this is even more difficult to find the other clients. 
If we encounter clients that can accept to understand that they can script their own tools 
this will be a different story but a modular infrastructure support both. 

Let's get more concrete. What part of the current Moose Suite would you not need in your image? Or better yet, what are parts that you need in your image?

So far I do not know. I was just making sure I can reload everything and looking at the list I was a bit skeptical that we need all that. 
I will discuss with usman and guillaume when they are back from holidays because like that we can try to have a small moose to find dependency problems.

First I will redo the process with the latest moose and synectique.
To see if all the changes got absorbed.
And since I have the mails and my old image I should be able to track the changes.

Stef




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