Why not having NeoCSV and NeoJSON in the image?

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

Why not having NeoCSV and NeoJSON in the image?

abergel
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




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

Re: Why not having NeoCSV and NeoJSON in the image?

Juraj Kubelka-5
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Why not having NeoCSV and NeoJSON in the image?

Juraj Kubelka-5
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Why not having NeoCSV and NeoJSON in the image?

abergel
Yes, more about Moose.

Alexandre


> On Feb 27, 2015, at 4:42 PM, Juraj Kubelka <[hidden email]> wrote:
>
> I am sorry, I have missed the mailing list. You are likely talking about Moose…
>
> Cheers,
> Juraj
>
>> 27. 2. 2015 v 16:41, Juraj Kubelka <[hidden email]>:
>>
>> Well, I have asked Sven the same question about WebSocket and STON. The general answer is that we want to keep the default image as small as possible and having simple possibility to load anything we need (from Configuration Browser).
>>
>> Remembering Eclipse download page, were you can choose from about 5 prepackaged distributions, we may have the same. Actually we already have: we have Pharo and Moose image, and likely much more…
>>
>> Cheers,
>> Juraj
>>
>>> 27. 2. 2015 v 16:30, Alexandre Bergel <[hidden email]>:
>>>
>>> … if we have XML, why not CSV and JSON? This is all wide-spread standard
>>>
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

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




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

Re: Why not having NeoCSV and NeoJSON in the image?

Tudor Girba-2
In reply to this post by abergel
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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: Why not having NeoCSV and NeoJSON in the image?

stepharo
Guys

Do not do that. You can load them in one click.
Moose is already bloated. Each time I try to make moose reloading correctly
I have to fight with dependencies badly expressed.

Alex if you need CSV and JSON just load them.
The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.


Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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: Why not having NeoCSV and NeoJSON in the image?

Tudor Girba-2
Hi,

On Mon, Mar 2, 2015 at 9:08 AM, stepharo <[hidden email]> wrote:
Guys

Do not do that. You can load them in one click.
Moose is already bloated.
Each time I try to make moose reloading correctly
I have to fight with dependencies badly expressed.

So do I. But, that is because we do not have proper tool support for sanitizing configurations. Seeing the issue when we have small and modular dependencies is a symptom, not a cause. We have to build proper analysis tools. I am actually upset at myself for not having done that already. I started with the support in the inspector for easier browsing, but we need more.

First, I would want to try to achieve to move all packages from ConfigurationOfMoose into Units and make ConfigurationOfMoose be an Assembly. Then, I would like to reach the state in which one command to be able to trigger a full Moose release including nested configurations. Once we have that, we are in a manageable situation.


Alex if you need CSV and JSON just load them.

It's not just Alex. I needed that quite regularly, too, but that does not mean anything either. I would rather want to look at the problem from a principle point of view.

Moose is a distribution for data analysis, and having support for basic data formats is a basic requirement for such a platform. There are other components that are less needed, such as Magritte (which is used only in Metanool and could be made simpler) or even the PharoImporter which is likely not used in many places.

I do agree that Moose can slim down, but keep this in mind: the lines of code of Moose remained basically constant since 4 years (around 180k) even though the functionality increased dramatically. That is a good sign, and I think we can do more to keep things slim but powerful.


The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.


You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.

Unfortunately, I actually do not see. These kind of dialogues are held behind close doors and we should not guide an open-source project by wishes that are never expressed.


Cheers,
Doru


 

Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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: Why not having NeoCSV and NeoJSON in the image?

philippeback

Reading CSV is a basic feature in R for reading data. Moose/ Roassal / GT combo should have that out of the box.

Phil

Le 2 mars 2015 12:34, "Tudor Girba" <[hidden email]> a écrit :
Hi,

On Mon, Mar 2, 2015 at 9:08 AM, stepharo <[hidden email]> wrote:
Guys

Do not do that. You can load them in one click.
Moose is already bloated.
Each time I try to make moose reloading correctly
I have to fight with dependencies badly expressed.

So do I. But, that is because we do not have proper tool support for sanitizing configurations. Seeing the issue when we have small and modular dependencies is a symptom, not a cause. We have to build proper analysis tools. I am actually upset at myself for not having done that already. I started with the support in the inspector for easier browsing, but we need more.

First, I would want to try to achieve to move all packages from ConfigurationOfMoose into Units and make ConfigurationOfMoose be an Assembly. Then, I would like to reach the state in which one command to be able to trigger a full Moose release including nested configurations. Once we have that, we are in a manageable situation.


Alex if you need CSV and JSON just load them.

It's not just Alex. I needed that quite regularly, too, but that does not mean anything either. I would rather want to look at the problem from a principle point of view.

Moose is a distribution for data analysis, and having support for basic data formats is a basic requirement for such a platform. There are other components that are less needed, such as Magritte (which is used only in Metanool and could be made simpler) or even the PharoImporter which is likely not used in many places.

I do agree that Moose can slim down, but keep this in mind: the lines of code of Moose remained basically constant since 4 years (around 180k) even though the functionality increased dramatically. That is a good sign, and I think we can do more to keep things slim but powerful.


The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.


You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.

Unfortunately, I actually do not see. These kind of dialogues are held behind close doors and we should not guide an open-source project by wishes that are never expressed.


Cheers,
Doru


 

Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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


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

Re: Why not having NeoCSV and NeoJSON in the image?

Usman Bhatti
In reply to this post by Tudor Girba-2


On Mon, Mar 2, 2015 at 12:34 PM, Tudor Girba <[hidden email]> wrote:
Hi,

On Mon, Mar 2, 2015 at 9:08 AM, stepharo <[hidden email]> wrote:
Guys

Do not do that. You can load them in one click.
Moose is already bloated.
Each time I try to make moose reloading correctly
I have to fight with dependencies badly expressed.

So do I. But, that is because we do not have proper tool support for sanitizing configurations. Seeing the issue when we have small and modular dependencies is a symptom, not a cause. We have to build proper analysis tools. I am actually upset at myself for not having done that already. I started with the support in the inspector for easier browsing, but we need more.

First, I would want to try to achieve to move all packages from ConfigurationOfMoose into Units and make ConfigurationOfMoose be an Assembly. Then, I would like to reach the state in which one command to be able to trigger a full Moose release including nested configurations. Once we have that, we are in a manageable situation.


Alex if you need CSV and JSON just load them.

It's not just Alex. I needed that quite regularly, too, but that does not mean anything either. I would rather want to look at the problem from a principle point of view.

Moose is a distribution for data analysis, and having support for basic data formats is a basic requirement for such a platform. There are other components that are less needed, such as Magritte (which is used only in Metanool and could be made simpler) or even the PharoImporter which is likely not used in many places.

I do agree that Moose can slim down, but keep this in mind: the lines of code of Moose remained basically constant since 4 years (around 180k) even though the functionality increased dramatically. That is a good sign, and I think we can do more to keep things slim but powerful.


The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.

Not entirely. We have been sharing info on the mailing list and the others related to Pharo regarding different needs/impediments. The latest being performance of PP and I wrote that we have to rely on PP v.1.51 because of the performance issues with the latest version. I tried to load PP 1.51 in Moose but reverting to an older version is not possible with Metacello (API allows it but it wasn't actually happening because of some bug). Hence, I had to fork the config of Moose to load PP 1.51 cleanly without any config in the parts of Moose loading the latest version of PP. I can publish it somewhere if people are interested.

And I agree that having assemblies and units would make things a lot easier.

regards.
usman
 


You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.

Unfortunately, I actually do not see. These kind of dialogues are held behind close doors and we should not guide an open-source project by wishes that are never expressed.


Cheers,
Doru


 

Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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



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

Re: Why not having NeoCSV and NeoJSON in the image?

Tudor Girba-2
Hi,

On Mon, Mar 2, 2015 at 2:19 PM, Usman Bhatti <[hidden email]> wrote:


On Mon, Mar 2, 2015 at 12:34 PM, Tudor Girba <[hidden email]> wrote:
Hi,

On Mon, Mar 2, 2015 at 9:08 AM, stepharo <[hidden email]> wrote:
Guys

Do not do that. You can load them in one click.
Moose is already bloated.
Each time I try to make moose reloading correctly
I have to fight with dependencies badly expressed.

So do I. But, that is because we do not have proper tool support for sanitizing configurations. Seeing the issue when we have small and modular dependencies is a symptom, not a cause. We have to build proper analysis tools. I am actually upset at myself for not having done that already. I started with the support in the inspector for easier browsing, but we need more.

First, I would want to try to achieve to move all packages from ConfigurationOfMoose into Units and make ConfigurationOfMoose be an Assembly. Then, I would like to reach the state in which one command to be able to trigger a full Moose release including nested configurations. Once we have that, we are in a manageable situation.


Alex if you need CSV and JSON just load them.

It's not just Alex. I needed that quite regularly, too, but that does not mean anything either. I would rather want to look at the problem from a principle point of view.

Moose is a distribution for data analysis, and having support for basic data formats is a basic requirement for such a platform. There are other components that are less needed, such as Magritte (which is used only in Metanool and could be made simpler) or even the PharoImporter which is likely not used in many places.

I do agree that Moose can slim down, but keep this in mind: the lines of code of Moose remained basically constant since 4 years (around 180k) even though the functionality increased dramatically. That is a good sign, and I think we can do more to keep things slim but powerful.


The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.

Not entirely. We have been sharing info on the mailing list and the others related to Pharo regarding different needs/impediments. The latest being performance of PP and I wrote that we have to rely on PP v.1.51 because of the performance issues with the latest version. I tried to load PP 1.51 in Moose but reverting to an older version is not possible with Metacello (API allows it but it wasn't actually happening because of some bug). Hence, I had to fork the config of Moose to load PP 1.51 cleanly without any config in the parts of Moose loading the latest version of PP. I can publish it somewhere if people are interested.

My message came as a reply to the one of Stef and I wanted to say that if people fork without saying what caused the issue, it's a perfectly fine, but we cannot react to that and we won't even try. In your case, I think the issue was treated quite seriously and Jan provided a reasonable solution. I think there are still things to improve, but it's not because of lack of reaction. In any case, the PetitParser issue is not because of the issue of size invoked before.

 
And I agree that having assemblies and units would make things a lot easier.

Great. That means we are in sync.

Cheers,
Doru


 
regards.
usman
 


You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.

Unfortunately, I actually do not see. These kind of dialogues are held behind close doors and we should not guide an open-source project by wishes that are never expressed.


Cheers,
Doru


 

Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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



_______________________________________________
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: Why not having NeoCSV and NeoJSON in the image?

stepharo
In reply to this post by Tudor Girba-2

So do I. But, that is because we do not have proper tool support for sanitizing configurations.

Not only
When we introduce more and more packages we end up with a mess.
Seeing the issue when we have small and modular dependencies is a symptom, not a cause. We have to build proper analysis tools. I am actually upset at myself for not having done that already. I started with the support in the inspector for easier browsing, but we need more.

First, I would want to try to achieve to move all packages from ConfigurationOfMoose into Units and make ConfigurationOfMoose be an Assembly.

Normally we will be able to start for real doing that with Christophe. He has the dependencies expressed per package (so like that people will not show that they do not want one configuration per package :).

Then, I would like to reach the state in which one command to be able to trigger a full Moose release including nested configurations. Once we have that, we are in a manageable situation.
Indeed. I would love that for Pharo too.

Alex if you need CSV and JSON just load them.

It's not just Alex. I needed that quite regularly, too, but that does not mean anything either. I would rather want to look at the problem from a principle point of view.

Get a ready to load in one click set of packages.
Load them when you need them.
Build easy configuration for each of your project.
Keep the core of Moose nice and lean.

BTW we got rejected for a request for an engineer to work on improving the Metamodeling and merging with Platypus :(
Moose is a distribution for data analysis, and having support for basic data formats is a basic requirement for such a platform. There are other components that are less needed, such as Magritte (which is used only in Metanool and could be made simpler) or even the PharoImporter which is likely not used in many places.

I do agree that Moose can slim down, but keep this in mind: the lines of code of Moose remained basically constant since 4 years (around 180k) even though the functionality increased dramatically. That is a good sign, and I think we can do more to keep things slim but powerful.

For me when I see that Alex uts everything in a single package because he is afraid of having configurations
then I'm worried. Sorry alex but only blind people do not see that.
I do not like the example with loading manually one package (spy whaeter) to load Hapao. This is not good.
It does not scale. And I fixed a lot of wrong dependencies in the past.




The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok.
What are you talking about?
Guillaume was working with anne to produce a dotty like graph algo and we were planning to give it to roassal.
We did telescope and it is public.

I have no access either to the ways decisions are being made inside or even to the needs the company has.
Better metamodels and combination (remember the discussion nicolas and anne got on traits, inverse relationships at the meta model)
so this will not be fixed in one day.
And right now Synectique is focusing on clients and when possible pushing elements to the community.

And I won't spend much time guessing either.


You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.

Unfortunately, I actually do not see. These kind of dialogues are held behind close doors and we should not guide an open-source project by wishes that are never expressed.


Cheers,
Doru


 

Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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


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

Re: Why not having NeoCSV and NeoJSON in the image?

stepharo
In reply to this post by philippeback

Reading CSV is a basic feature in R for reading data. Moose/ Roassal / GT combo should have that out of the box.


It depends what is the goal of Moose is. I worked 16 years with Moose and I never ever needed CSV to analysis languages.
Now if I would need it then it takes me less than a min to load it.
I maintain also XMLWriter, XMLReader (nice that monty really pushed there) and again I would load it
when I need it. Less than a minute to load.

For me Moose can still focus on meta modeling and we could have "agile visualization" but for that
we do not need FAME, FAMIX and all the Moose related business.

What I was suggesting to alex I told him more than a year ago was:
    Build an image with
        Roassal
        CSV
        JSON
        XML
        + some math packages

No need to do that in the Moose Image: no need to have DSM, FCA, Metrics, FAME, MooseModel.

Stef

Phil

Le 2 mars 2015 12:34, "Tudor Girba" <[hidden email]> a écrit :
Hi,

On Mon, Mar 2, 2015 at 9:08 AM, stepharo <[hidden email]> wrote:
Guys

Do not do that. You can load them in one click.
Moose is already bloated.
Each time I try to make moose reloading correctly
I have to fight with dependencies badly expressed.

So do I. But, that is because we do not have proper tool support for sanitizing configurations. Seeing the issue when we have small and modular dependencies is a symptom, not a cause. We have to build proper analysis tools. I am actually upset at myself for not having done that already. I started with the support in the inspector for easier browsing, but we need more.

First, I would want to try to achieve to move all packages from ConfigurationOfMoose into Units and make ConfigurationOfMoose be an Assembly. Then, I would like to reach the state in which one command to be able to trigger a full Moose release including nested configurations. Once we have that, we are in a manageable situation.


Alex if you need CSV and JSON just load them.

It's not just Alex. I needed that quite regularly, too, but that does not mean anything either. I would rather want to look at the problem from a principle point of view.

Moose is a distribution for data analysis, and having support for basic data formats is a basic requirement for such a platform. There are other components that are less needed, such as Magritte (which is used only in Metanool and could be made simpler) or even the PharoImporter which is likely not used in many places.

I do agree that Moose can slim down, but keep this in mind: the lines of code of Moose remained basically constant since 4 years (around 180k) even though the functionality increased dramatically. That is a good sign, and I think we can do more to keep things slim but powerful.


The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.


You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.

Unfortunately, I actually do not see. These kind of dialogues are held behind close doors and we should not guide an open-source project by wishes that are never expressed.


Cheers,
Doru


 

Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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



_______________________________________________
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: Why not having NeoCSV and NeoJSON in the image?

Offray
Hi,

El 03/03/15 a las 15:34, stepharo escribió:

[...]

>
> For me Moose can still focus on meta modeling and we could have "agile
> visualization" but for that
> we do not need FAME, FAMIX and all the Moose related business.
>
> What I was suggesting to alex I told him more than a year ago was:
>       Build an image with
>           Roassal
>           CSV
>           JSON
>           XML
>           + some math packages
>
> No need to do that in the Moose Image: no need to have DSM, FCA, Metrics, FAME,
> MooseModel.
>
> Stef
>


That would be an image I would be interested in. I don't know how this
affect the Agile Visualization book. We have used it in some hackathons
and workshops here. Most of the people like the visuals and easiness of
the platform, but having the data taken from the software itself (the
classes and methods in Smalltalk for example) is far from what most
people want. Taking external data from cvs, json, xml, data bases and
making it computable/visualizable is the biggest concern. Seeing how
Smalltalk or other software looks inside accounts for the roots of Moose
as a software analysis tool, but in my experience, for Agile
Visualization, examples need to be more general and external.

Cheers,

Offray

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

Re: Why not having NeoCSV and NeoJSON in the image?

philippeback


Le 4 mars 2015 23:39, "Offray Vladimir Luna Cárdenas" <[hidden email]> a écrit :
>
> Hi,
>
> El 03/03/15 a las 15:34, stepharo escribió:
>
> [...]
>
>>
>> For me Moose can still focus on meta modeling and we could have "agile
>> visualization" but for that
>> we do not need FAME, FAMIX and all the Moose related business.
>>
>> What I was suggesting to alex I told him more than a year ago was:
>>       Build an image with
>>           Roassal
>>           CSV
>>           JSON
>>           XML
>>           + some math packages
>>
>> No need to do that in the Moose Image: no need to have DSM, FCA, Metrics, FAME,
>> MooseModel.
>>
>> Stef
>>
>
>
> That would be an image I would be interested in. I don't know how this affect the Agile Visualization book. We have used it in some hackathons and workshops here. Most of the people like the visuals and easiness of the platform, but having the data taken from the software itself (the classes and methods in Smalltalk for example) is far from what most people want. Taking external data from cvs, json, xml, data bases and making it computable/visualizable is the biggest concern.

Yes, faced that too.
Sqlite is important here as some datasets are in that format.
I've got one with 70K parliament questions for example.

Seeing how Smalltalk or other software looks inside accounts for the roots of Moose as a software analysis tool, but in my experience, for Agile Visualization, examples need to be more general and external.
>
> Cheers,
>
> Offray
>
>
> _______________________________________________
> 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: Why not having NeoCSV and NeoJSON in the image?

Nicolas Anquetil
In reply to this post by Tudor Girba-2

On 02/03/2015 12:34, Tudor Girba wrote:
I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.

Tudor,

it seems to me an unfair comment to make about us.
As far as I know, companies do not routinely allow people outside of the company, to have access to the decisions being made.

But I actually believe you would find this rather uninteresting, as  discussions are currently about whether we should we call back prospect X or try to meet with potential prospect Y ?
There is no technical discussion in our meetings because this is not where the heart of the problem.
This year "running"(somehow) the company taught me that it is very little about how you do things, but rather how you present it.
Our problems are not what we could or should do with Moose, but rather how we are going to pay the salaries until the end of the year, which means how we are going to find clients.

nicolas

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

Re: Why not having NeoCSV and NeoJSON in the image?

Tudor Girba-2
Hi Nicolas,

On Fri, Mar 6, 2015 at 10:22 PM, Nicolas Anquetil <[hidden email]> wrote:

On 02/03/2015 12:34, Tudor Girba wrote:
I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.

Tudor,

it seems to me an unfair comment to make about us.
As far as I know, companies do not routinely allow people outside of the company, to have access to the decisions being made.

I just stated a simple fact as a reply to a request to take into consideration something that is internal in the mentioned company. That is all. And I also explicitly said that I have no problem with this. Also, anyway, the context of the discussion was about technical decisions, such as forking, and not of other nature.

 
But I actually believe you would find this rather uninteresting, as  discussions are currently about whether we should we call back prospect X or try to meet with potential prospect Y ?
There is no technical discussion in our meetings because this is not where the heart of the problem.
This year "running"(somehow) the company taught me that it is very little about how you do things, but rather how you present it.
Our problems are not what we could or should do with Moose, but rather how we are going to pay the salaries until the end of the year, which means how we are going to find clients.

Good luck.

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: Why not having NeoCSV and NeoJSON in the image?

Tudor Girba-2
In reply to this post by stepharo
Hi,

This is an important discussion that we need to have every now and then.

I work on solving concrete software problems all day long and I have yet to see a system for which I do not need to reason about XML, JSON or CSV (typically it's all of them). It's often that I find myself working on these data formats than on actual code. But, again this is just my personal experience.

Moose is targeted to software developers to help them deal with things around their software systems and around data. I announced two years ago that Moose will not center itself around FAMIX only, but go towards other kinds of data. Essentially, Moose should be a single-stop-tool that developers would want to have around. It should replace grep, Excel when used for developer data and other kinds of data inspectors (such as JSON).

FAMIX is relevant, but not at all the most important source of value we can reach with Moose. Interestingly, I have more success getting people to look into Moose when it's about files or the DB than when it's about code only.

Cheers,
Doru



On Tue, Mar 3, 2015 at 9:34 PM, stepharo <[hidden email]> wrote:

Reading CSV is a basic feature in R for reading data. Moose/ Roassal / GT combo should have that out of the box.


It depends what is the goal of Moose is. I worked 16 years with Moose and I never ever needed CSV to analysis languages.
Now if I would need it then it takes me less than a min to load it.
I maintain also XMLWriter, XMLReader (nice that monty really pushed there) and again I would load it
when I need it. Less than a minute to load.

For me Moose can still focus on meta modeling and we could have "agile visualization" but for that
we do not need FAME, FAMIX and all the Moose related business.

What I was suggesting to alex I told him more than a year ago was:
    Build an image with
        Roassal
        CSV
        JSON
        XML
        + some math packages

No need to do that in the Moose Image: no need to have DSM, FCA, Metrics, FAME, MooseModel.

Stef


Phil

Le 2 mars 2015 12:34, "Tudor Girba" <[hidden email]> a écrit :
Hi,

On Mon, Mar 2, 2015 at 9:08 AM, stepharo <[hidden email]> wrote:
Guys

Do not do that. You can load them in one click.
Moose is already bloated.
Each time I try to make moose reloading correctly
I have to fight with dependencies badly expressed.

So do I. But, that is because we do not have proper tool support for sanitizing configurations. Seeing the issue when we have small and modular dependencies is a symptom, not a cause. We have to build proper analysis tools. I am actually upset at myself for not having done that already. I started with the support in the inspector for easier browsing, but we need more.

First, I would want to try to achieve to move all packages from ConfigurationOfMoose into Units and make ConfigurationOfMoose be an Assembly. Then, I would like to reach the state in which one command to be able to trigger a full Moose release including nested configurations. Once we have that, we are in a manageable situation.


Alex if you need CSV and JSON just load them.

It's not just Alex. I needed that quite regularly, too, but that does not mean anything either. I would rather want to look at the problem from a principle point of view.

Moose is a distribution for data analysis, and having support for basic data formats is a basic requirement for such a platform. There are other components that are less needed, such as Magritte (which is used only in Metanool and could be made simpler) or even the PharoImporter which is likely not used in many places.

I do agree that Moose can slim down, but keep this in mind: the lines of code of Moose remained basically constant since 4 years (around 180k) even though the functionality increased dramatically. That is a good sign, and I think we can do more to keep things slim but powerful.


The problem is that you prefer to let us manage dependency else.
I really do not like that.
I wrote a full chapter and it is working. To create a configuration it
takes less than 5 min.
So if you have a project just create a configuration and you get done.

I really think that going that road companies like synectique will simply
have to fork (in fact they probably already have) and we will all lose.

Synectique chooses to play an opaque game, which is Ok. I have no access either to the ways decisions are being made inside or even to the needs the company has. And I won't spend much time guessing either.


You see when one guy is telling me that Group is not well done because it uses
too much nil or whatever and that I encourage the guy to fix and offer it to moose
then if this guy is coding in another "branch" then we all lose.

Unfortunately, I actually do not see. These kind of dialogues are held behind close doors and we should not guide an open-source project by wishes that are never expressed.


Cheers,
Doru


 

Stef

Le 27/2/15 23:18, Tudor Girba a écrit :
Yes, we should add those as well to the main Moose distribution.

Doru

On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel <[hidden email]> wrote:
… if we have XML, why not CSV and JSON? This is all wide-spread standard

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




_______________________________________________
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



_______________________________________________
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: Why not having NeoCSV and NeoJSON in the image?

Stephan Eggermont-3
Ahem, this is exactly why we have groups. They work very well for this.
I agree of course that we need to further clean up Moose configurations,
there are still lots of badly expressed dependencies and missing groups.

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

Re: Why not having NeoCSV and NeoJSON in the image?

Tudor Girba-2
To which email did you reply?

Doru

On Mon, Mar 9, 2015 at 10:25 AM, Stephan Eggermont <[hidden email]> wrote:
Ahem, this is exactly why we have groups. They work very well for this.
I agree of course that we need to further clean up Moose configurations,
there are still lots of badly expressed dependencies and missing groups.

Stephan

_______________________________________________
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: Why not having NeoCSV and NeoJSON in the image?

Hannes Hirzel
In reply to this post by stepharo
On 3/3/15, stepharo <[hidden email]> wrote:

>
>> Reading CSV is a basic feature in R for reading data. Moose/ Roassal /
>> GT combo should have that out of the box.
>>
>
> It depends what is the goal of Moose is. I worked 16 years with Moose
> and I never ever needed CSV to analysis languages.
> Now if I would need it then it takes me less than a min to load it.
> I maintain also XMLWriter, XMLReader (nice that monty really pushed
> there) and again I would load it
> when I need it. Less than a minute to load.
>
> For me Moose can still focus on meta modeling and we could have "agile
> visualization" but for that
> we do not need FAME, FAMIX and all the Moose related business.
>
> What I was suggesting to alex I told him more than a year ago was:
>      Build an image with
>          Roassal
>          CSV
>          JSON
>          XML
>          + some math packages

It would be very useful to have such an image pre-built by the
integration server. Has this been done in the meantime?

--Hannes


> No need to do that in the Moose Image: no need to have DSM, FCA,
> Metrics, FAME, MooseModel.
>
> Stef
>
>> Phil
>>
>> Le 2 mars 2015 12:34, "Tudor Girba" <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>>
>>     Hi,
>>
>>     On Mon, Mar 2, 2015 at 9:08 AM, stepharo <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>
>>         Guys
>>
>>         Do not do that. You can load them in one click.
>>         Moose is already bloated.
>>
>>         Each time I try to make moose reloading correctly
>>         I have to fight with dependencies badly expressed.
>>
>>
>>     So do I. But, that is because we do not have proper tool support
>>     for sanitizing configurations. Seeing the issue when we have small
>>     and modular dependencies is a symptom, not a cause. We have to
>>     build proper analysis tools. I am actually upset at myself for not
>>     having done that already. I started with the support in the
>>     inspector for easier browsing, but we need more.
>>
>>     First, I would want to try to achieve to move all packages from
>>     ConfigurationOfMoose into Units and make ConfigurationOfMoose be
>>     an Assembly. Then, I would like to reach the state in which one
>>     command to be able to trigger a full Moose release including
>>     nested configurations. Once we have that, we are in a manageable
>>     situation.
>>
>>
>>         Alex if you need CSV and JSON just load them.
>>
>>
>>     It's not just Alex. I needed that quite regularly, too, but that
>>     does not mean anything either. I would rather want to look at the
>>     problem from a principle point of view.
>>
>>     Moose is a distribution for data analysis, and having support for
>>     basic data formats is a basic requirement for such a platform.
>>     There are other components that are less needed, such as Magritte
>>     (which is used only in Metanool and could be made simpler) or even
>>     the PharoImporter which is likely not used in many places.
>>
>>     I do agree that Moose can slim down, but keep this in mind: the
>>     lines of code of Moose remained basically constant since 4 years
>>     (around 180k) even though the functionality increased
>>     dramatically. That is a good sign, and I think we can do more to
>>     keep things slim but powerful.
>>
>>
>>         The problem is that you prefer to let us manage dependency else.
>>         I really do not like that.
>>         I wrote a full chapter and it is working. To create a
>>         configuration it
>>         takes less than 5 min.
>>         So if you have a project just create a configuration and you
>>         get done.
>>
>>         I really think that going that road companies like synectique
>>         will simply
>>         have to fork (in fact they probably already have) and we will
>>         all lose.
>>
>>
>>     Synectique chooses to play an opaque game, which is Ok. I have no
>>     access either to the ways decisions are being made inside or even
>>     to the needs the company has. And I won't spend much time guessing
>>     either.
>>
>>
>>         You see when one guy is telling me that Group is not well done
>>         because it uses
>>         too much nil or whatever and that I encourage the guy to fix
>>         and offer it to moose
>>         then if this guy is coding in another "branch" then we all lose.
>>
>>
>>     Unfortunately, I actually do not see. These kind of dialogues are
>>     held behind close doors and we should not guide an open-source
>>     project by wishes that are never expressed.
>>
>>
>>     Cheers,
>>     Doru
>>
>>
>>
>>         Stef
>>
>>         Le 27/2/15 23:18, Tudor Girba a écrit :
>>>         Yes, we should add those as well to the main Moose distribution.
>>>
>>>         Doru
>>>
>>>         On Fri, Feb 27, 2015 at 8:30 PM, Alexandre Bergel
>>>         <[hidden email] <mailto:[hidden email]>>
>>> wrote:
>>>
>>>             … if we have XML, why not CSV and JSON? This is all
>>>             wide-spread standard
>>>
>>>             Alexandre
>>>             --
>>>             _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>             Alexandre Bergel http://www.bergel.eu
>>>             ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>             _______________________________________________
>>>             Moose-dev mailing list
>>>             [hidden email] <mailto:[hidden email]>
>>>             https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>>
>>>         --
>>>         www.tudorgirba.com <http://www.tudorgirba.com>
>>>
>>>         "Every thing has its own flow"
>>>
>>>
>>>         _______________________________________________
>>>         Moose-dev mailing list
>>>         [hidden email]  <mailto:[hidden email]>
>>>         https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>         _______________________________________________
>>         Moose-dev mailing list
>>         [hidden email] <mailto:[hidden email]>
>>         https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>>
>>     --
>>     www.tudorgirba.com <http://www.tudorgirba.com>
>>
>>     "Every thing has its own flow"
>>
>>     _______________________________________________
>>     Moose-dev mailing list
>>     [hidden email] <mailto:[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