Does someone know why Nile is in Dev images?

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

Does someone know why Nile is in Dev images?

Mariano Martinez Peck
Does another package of the dev image depends on Nile?  If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included.

Thanks

Mariano

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Does someone know why Nile is in Dev images?

Stéphane Ducasse
Nile is in dev because it should be progressively use to replace existing streams.
For example in Moose some important collection extensions depend on it.


> Does another package of the dev image depends on Nile?  If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included.
>
> Thanks
>
> Mariano
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Does someone know why Nile is in Dev images?

Mariano Martinez Peck
Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a lot of very good people have worked and is still working in Nile project. So, I am sure it is an excellent product.

However, I don't think it should be in Dev image. Dev image is for "Developers". So, we put tools like NewInspector, RoelTyper, E and OCompletion, Refactoring, etc. But why Nile ?

I am not agree this is neither a way to push Nile to be used. It is no difference if you already have the code in the image or not, it is just one click of difference (as you have the Nile-All). Even if it where the case, I think it should be in Core image.  The way to push a project to be used is to write documentation, tutorials, show the benefits over other implementations....and so on.

If Moose use it, ok, put it as a dependency. Now you have a Metacello configuration for Moose :)
I mean, in SqueakDBX we use FFI and we don't put in the image. Seaside uses Slime and it is not in the image.

Just my opinion. I hope no one feels offended.

What others think about this ?

Cheers

Mariano

On Sun, Jan 3, 2010 at 11:02 AM, Stéphane Ducasse <[hidden email]> wrote:
Nile is in dev because it should be progressively use to replace existing streams.
For example in Moose some important collection extensions depend on it.


> Does another package of the dev image depends on Nile?  If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included.
>
> Thanks
>
> Mariano
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Does someone know why Nile is in Dev images?

Stéphane Ducasse

On Jan 3, 2010, at 1:03 PM, Mariano Martinez Peck wrote:

> Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a lot of very good people have worked and is still working in Nile project. So, I am sure it is an excellent product.
>
> However, I don't think it should be in Dev image. Dev image is for "Developers". So, we put tools like NewInspector, RoelTyper, E and OCompletion, Refactoring, etc. But why Nile ?

But mariano Nile is an alternate library it is beta. If people have to load it then better throw it away right now.


> I am not agree this is neither a way to push Nile to be used. It is no difference if you already have the code in the image or not, it is just one click of difference (as you have the Nile-All).

No there is a big difference. People do not know that they should look for it.

> Even if it where the case, I think it should be in Core image.  The way to push a project to be used is to write documentation, tutorials, show the benefits over other implementations....and so on.
>
> If Moose use it, ok, put it as a dependency. Now you have a Metacello configuration for Moose :)
> I mean, in SqueakDBX we use FFI and we don't put in the image. Seaside uses Slime and it is not in the image.

We should put FFI in the image too. Because this are infrastructural elements.
When the newCompiler will be beta it should be in. It should not take 5 min to load something to try it.



>
> Just my opinion. I hope no one feels offended.
>
> What others think about this ?
>
> Cheers
>
> Mariano
>
> On Sun, Jan 3, 2010 at 11:02 AM, Stéphane Ducasse <[hidden email]> wrote:
> Nile is in dev because it should be progressively use to replace existing streams.
> For example in Moose some important collection extensions depend on it.
>
>
> > Does another package of the dev image depends on Nile?  If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included.
> >
> > Thanks
> >
> > Mariano
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Does someone know why Nile is in Dev images?

Alexandre Bergel
In reply to this post by Mariano Martinez Peck
Hi Mariano,

I haven't got the chance yet to use Nile unfortunately. But excluding  
it from Pharo will dramatically reduce the chance that people will  
look at it.

Cheers,
Alexandre


On 3 Jan 2010, at 13:03, Mariano Martinez Peck wrote:

> Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a  
> lot of very good people have worked and is still working in Nile  
> project. So, I am sure it is an excellent product.
>
> However, I don't think it should be in Dev image. Dev image is for  
> "Developers". So, we put tools like NewInspector, RoelTyper, E and  
> OCompletion, Refactoring, etc. But why Nile ?
>
> I am not agree this is neither a way to push Nile to be used. It is  
> no difference if you already have the code in the image or not, it  
> is just one click of difference (as you have the Nile-All). Even if  
> it where the case, I think it should be in Core image.  The way to  
> push a project to be used is to write documentation, tutorials, show  
> the benefits over other implementations....and so on.
>
> If Moose use it, ok, put it as a dependency. Now you have a  
> Metacello configuration for Moose :)
> I mean, in SqueakDBX we use FFI and we don't put in the image.  
> Seaside uses Slime and it is not in the image.
>
> Just my opinion. I hope no one feels offended.
>
> What others think about this ?
>
> Cheers
>
> Mariano
>
> On Sun, Jan 3, 2010 at 11:02 AM, Stéphane Ducasse <[hidden email]
> > wrote:
> Nile is in dev because it should be progressively use to replace  
> existing streams.
> For example in Moose some important collection extensions depend on  
> it.
>
>
> > Does another package of the dev image depends on Nile?  If not, I  
> don't understand why it is part of the dev image. I see it as any  
> other external package but not a "dev tool" that should be included.
> >
> > Thanks
> >
> > Mariano
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Does someone know why Nile is in Dev images?

Schwab,Wilhelm K
In reply to this post by Mariano Martinez Peck
Mariano,
 
You _like_ the new inspector????  :)  Can't stand it myself.  If I want that kind of view, I use the explorer.  Selecting the standard toolset (so far at least) makes it "go away," so I'm happy.  One thing that I miss is the diving inspector that started in VW (IIRC) and was ported to Dolphin.
 
Nile causes me no trouble, and I am glad to see movement away from the Squeak streams.  We will not be able to rid ourselves of the latter w/o elevating Nile to being a part of the system.  Your point about putting it in the core is well-taken, but I think having it in the dev/web images is a good thing because it should help drive Moose and other groups to dev as opposed to the core.  Given our obvious need to test before releasing the dev/web images, anything that promotes their use is helpful.
 
Bill
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck
Sent: Sunday, January 03, 2010 7:03 AM
To: [hidden email]
Subject: Re: [Pharo-project] Does someone know why Nile is in Dev images?

Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a lot of very good people have worked and is still working in Nile project. So, I am sure it is an excellent product.

However, I don't think it should be in Dev image. Dev image is for "Developers". So, we put tools like NewInspector, RoelTyper, E and OCompletion, Refactoring, etc. But why Nile ?

I am not agree this is neither a way to push Nile to be used. It is no difference if you already have the code in the image or not, it is just one click of difference (as you have the Nile-All). Even if it where the case, I think it should be in Core image.  The way to push a project to be used is to write documentation, tutorials, show the benefits over other implementations....and so on.

If Moose use it, ok, put it as a dependency. Now you have a Metacello configuration for Moose :)
I mean, in SqueakDBX we use FFI and we don't put in the image. Seaside uses Slime and it is not in the image.

Just my opinion. I hope no one feels offended.

What others think about this ?

Cheers

Mariano

On Sun, Jan 3, 2010 at 11:02 AM, Stéphane Ducasse <[hidden email]> wrote:
Nile is in dev because it should be progressively use to replace existing streams.
For example in Moose some important collection extensions depend on it.


> Does another package of the dev image depends on Nile?  If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included.
>
> Thanks
>
> Mariano
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Does someone know why Nile is in Dev images?

Mariano Martinez Peck
Ok... The good news is that this is a community :)
Sometimes the community thinks as you do and sometimes not. This is life ;)

I will put it in the ConfigurationOfPharo for the Dev then.

Cheers

Mariano

2010/1/3 Schwab,Wilhelm K <[hidden email]>
Mariano,
 
You _like_ the new inspector????  :)  Can't stand it myself.  If I want that kind of view, I use the explorer.  Selecting the standard toolset (so far at least) makes it "go away," so I'm happy.  One thing that I miss is the diving inspector that started in VW (IIRC) and was ported to Dolphin.
 
Nile causes me no trouble, and I am glad to see movement away from the Squeak streams.  We will not be able to rid ourselves of the latter w/o elevating Nile to being a part of the system.  Your point about putting it in the core is well-taken, but I think having it in the dev/web images is a good thing because it should help drive Moose and other groups to dev as opposed to the core.  Given our obvious need to test before releasing the dev/web images, anything that promotes their use is helpful.
 
Bill
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck
Sent: Sunday, January 03, 2010 7:03 AM
To: [hidden email]
Subject: Re: [Pharo-project] Does someone know why Nile is in Dev images?

Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a lot of very good people have worked and is still working in Nile project. So, I am sure it is an excellent product.

However, I don't think it should be in Dev image. Dev image is for "Developers". So, we put tools like NewInspector, RoelTyper, E and OCompletion, Refactoring, etc. But why Nile ?

I am not agree this is neither a way to push Nile to be used. It is no difference if you already have the code in the image or not, it is just one click of difference (as you have the Nile-All). Even if it where the case, I think it should be in Core image.  The way to push a project to be used is to write documentation, tutorials, show the benefits over other implementations....and so on.

If Moose use it, ok, put it as a dependency. Now you have a Metacello configuration for Moose :)
I mean, in SqueakDBX we use FFI and we don't put in the image. Seaside uses Slime and it is not in the image.

Just my opinion. I hope no one feels offended.

What others think about this ?

Cheers

Mariano

On Sun, Jan 3, 2010 at 11:02 AM, Stéphane Ducasse <[hidden email]> wrote:
Nile is in dev because it should be progressively use to replace existing streams.
For example in Moose some important collection extensions depend on it.


> Does another package of the dev image depends on Nile?  If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included.
>
> Thanks
>
> Mariano
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project