Slice and others

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

Slice and others

Stéphane Ducasse
Hi guys

I would like to generalise the slice ideas so that even if you publish  
a single package change you use a slice because
I'm spending time to look for these simples changes in single packages.
What do you think?

Stef

_______________________________________________
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: Slice and others

Alexandre Bergel
I usually use .cs files to submit changes. Isn't it more convenient  
for you?

Cheers,
Alexandre


On 4 Nov 2009, at 12:05, Stéphane Ducasse wrote:

> Hi guys
>
> I would like to generalise the slice ideas so that even if you publish
> a single package change you use a slice because
> I'm spending time to look for these simples changes in single  
> packages.
> What do you think?
>
> Stef
>
> _______________________________________________
> 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: Slice and others

Stéphane Ducasse
No
Because merge does not work well.

Stef

On Nov 4, 2009, at 4:08 PM, Alexandre Bergel wrote:

> I usually use .cs files to submit changes. Isn't it more convenient
> for you?
>
> Cheers,
> Alexandre
>
>
> On 4 Nov 2009, at 12:05, Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> I would like to generalise the slice ideas so that even if you  
>> publish
>> a single package change you use a slice because
>> I'm spending time to look for these simples changes in single
>> packages.
>> What do you think?
>>
>> Stef
>>
>> _______________________________________________
>> 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


_______________________________________________
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: Slice and others

Schwab,Wilhelm K
In reply to this post by Stéphane Ducasse
Stef,

I am not sure I know enough to have an opinion.  You mentioned slices before in response to my concerns over saving individual packages.  If that is a fix, great.  I have been taking a different approach, along the lines of Migrate, which I wrote for Dolphin.  It is different for Pharo, and (so far anyway) not as slick, but some of the features that made sense in Dolphin might not be needed in Pharo.

The essential features include:

(1) search for code that I wrote and is not yet in one of my packages (meaning it is at risk of being lost in a move)

(2) allow a "global save" of all packages of interest - this is the newest feature, and I *think* it works

(3) load the saved packages into a new image; the loader is installed first and then launched to search for what it needs (it complains early when possible) and then loads the packages.

There MUST be a better way :)  I had to do something, because chasing after lost work was driving me nuts.

Bill




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Wednesday, November 04, 2009 10:06 AM
To: Pharo Development
Subject: [Pharo-project] Slice and others

Hi guys

I would like to generalise the slice ideas so that even if you publish a single package change you use a slice because I'm spending time to look for these simples changes in single packages.
What do you think?

Stef

_______________________________________________
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: Slice and others

Stéphane Ducasse
I think that we are looking at two different problem.
For me I need to know what people publish so that I can integrate that  
fast.

On Nov 4, 2009, at 4:30 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> I am not sure I know enough to have an opinion.  You mentioned  
> slices before in response to my concerns over saving individual  
> packages.  If that is a fix, great.  I have been taking a different  
> approach, along the lines of Migrate, which I wrote for Dolphin.  It  
> is different for Pharo, and (so far anyway) not as slick, but some  
> of the features that made sense in Dolphin might not be needed in  
> Pharo.
>
> The essential features include:
>
> (1) search for code that I wrote and is not yet in one of my  
> packages (meaning it is at risk of being lost in a move)
>
> (2) allow a "global save" of all packages of interest - this is the  
> newest feature, and I *think* it works
>
> (3) load the saved packages into a new image; the loader is  
> installed first and then launched to search for what it needs (it  
> complains early when possible) and then loads the packages.
>
> There MUST be a better way :)  I had to do something, because  
> chasing after lost work was driving me nuts.
>
> Bill
>
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Wednesday, November 04, 2009 10:06 AM
> To: Pharo Development
> Subject: [Pharo-project] Slice and others
>
> Hi guys
>
> I would like to generalise the slice ideas so that even if you  
> publish a single package change you use a slice because I'm spending  
> time to look for these simples changes in single packages.
> What do you think?
>
> Stef
>
> _______________________________________________
> 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: Slice and others

Nicolas Cellier
In reply to this post by Stéphane Ducasse
2009/11/4 Stéphane Ducasse <[hidden email]>:
> Hi guys
>
> I would like to generalise the slice ideas so that even if you publish
> a single package change you use a slice because
> I'm spending time to look for these simples changes in single packages.
> What do you think?
>
> Stef
>

I think it would make things easier for harvesters while not degrading
for submitters.
However, you still have to review Kernel-truc.xxx one by one to decide
if already fixed/won't fix/fix later, don't you ?

Nicolas

> _______________________________________________
> 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: Slice and others

Stéphane Ducasse
>
> I think it would make things easier for harvesters while not degrading
> for submitters.
> However, you still have to review Kernel-truc.xxx one by one to decide
> if already fixed/won't fix/fix later, don't you ?

not really because after we can use move dependencies and move the  
slice which points to
whateher and everything get moved to another repository.

We are currently checking if we can have a webdav server to be able to  
script
the folders.

Stef

>
> Nicolas
>
>> _______________________________________________
>> 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