Re: [etoys-dev] Packaging Etoys

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

Re: [etoys-dev] Packaging Etoys

David T. Lewis
On Sun, Feb 28, 2010 at 06:47:58PM +0100, Karl Ramberg wrote:
> Hi,
> I have worked on packaging the Etoys image and saved them to
> source.squeak.org/etoys.
> I'm new to Monticello and hope I did not screw up too badly.

Folks,

Efforts are under way to synchronize Etoys with Squeak trunk.
The Etoys developers have taken some first steps to save the
Etoys image in Monticello archives (http://source.squeak.org/etoys).

Since Monticello is being used to support this work, and since
package naming conventions are important in Monticello, it will
be helpful to all involved if the package names in trunk conform
to the correct spelling of Etoys:
  http://lists.squeakland.org/pipermail/etoys-dev/2010-February/004397.html

For this reason, I am about to post an update to Squeak trunk that
changes all package names to from "EToys" to "Etoys" and changes all
package overrides from "*eToys", "*EToys" and so forth to "*Etoys".

As far as I know, this update requires no special changes to the
trunk update stream. However, I've been wrong about this sort of
thing before so if any problems appear in the update process, you
can reasonably assume that it is my fault. Also, apologies in
advance for the rather large update notification that may result
from this change.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: [etoys-dev] Packaging Etoys

Edgar J. De Cleene



On 2/28/10 11:01 PM, "David T. Lewis" <[hidden email]> wrote:

> On Sun, Feb 28, 2010 at 06:47:58PM +0100, Karl Ramberg wrote:
>> Hi,
>> I have worked on packaging the Etoys image and saved them to
>> source.squeak.org/etoys.
>> I'm new to Monticello and hope I did not screw up too badly.
>
> Folks,
>
> Efforts are under way to synchronize Etoys with Squeak trunk.
> The Etoys developers have taken some first steps to save the
> Etoys image in Monticello archives (http://source.squeak.org/etoys).
>
> Since Monticello is being used to support this work, and since
> package naming conventions are important in Monticello, it will
> be helpful to all involved if the package names in trunk conform
> to the correct spelling of Etoys:
>   http://lists.squeakland.org/pipermail/etoys-dev/2010-February/004397.html
>
> For this reason, I am about to post an update to Squeak trunk that
> changes all package names to from "EToys" to "Etoys" and changes all
> package overrides from "*eToys", "*EToys" and so forth to "*Etoys".
>
> As far as I know, this update requires no special changes to the
> trunk update stream. However, I've been wrong about this sort of
> thing before so if any problems appear in the update process, you
> can reasonably assume that it is my fault. Also, apologies in
> advance for the rather large update notification that may result
> from this change.
>
> Dave


IMHO the right thing to do is:

In the trunk image we do Smalltalk unloadAllKnownPackages.

>From the Etoys repositories we load Etoys, so we have the right and the
last.

And we also have differences in Project and maybe some other classes , which
should be solved if we wish trunk .image load Etoys 4 project.

Edgar




Reply | Threaded
Open this post in threaded view
|

Re: [etoys-dev] Packaging Etoys

Karl Ramberg
On Mon, Mar 1, 2010 at 9:59 AM, Edgar J. De Cleene
<[hidden email]> wrote:

>
>
>
> On 2/28/10 11:01 PM, "David T. Lewis" <[hidden email]> wrote:
>
>> On Sun, Feb 28, 2010 at 06:47:58PM +0100, Karl Ramberg wrote:
>>> Hi,
>>> I have worked on packaging the Etoys image and saved them to
>>> source.squeak.org/etoys.
>>> I'm new to Monticello and hope I did not screw up too badly.
>>
>> Folks,
>>
>> Efforts are under way to synchronize Etoys with Squeak trunk.
>> The Etoys developers have taken some first steps to save the
>> Etoys image in Monticello archives (http://source.squeak.org/etoys).
>>
>> Since Monticello is being used to support this work, and since
>> package naming conventions are important in Monticello, it will
>> be helpful to all involved if the package names in trunk conform
>> to the correct spelling of Etoys:
>>   http://lists.squeakland.org/pipermail/etoys-dev/2010-February/004397.html
>>
>> For this reason, I am about to post an update to Squeak trunk that
>> changes all package names to from "EToys" to "Etoys" and changes all
>> package overrides from "*eToys", "*EToys" and so forth to "*Etoys".
>>
>> As far as I know, this update requires no special changes to the
>> trunk update stream. However, I've been wrong about this sort of
>> thing before so if any problems appear in the update process, you
>> can reasonably assume that it is my fault. Also, apologies in
>> advance for the rather large update notification that may result
>> from this change.
>>
>> Dave
>
>
> IMHO the right thing to do is:
>
> In the trunk image we do Smalltalk unloadAllKnownPackages.
>
> >From the Etoys repositories we load Etoys, so we have the right and the
> last.
>
> And we also have differences in Project and maybe some other classes , which
> should be solved if we wish trunk .image load Etoys 4 project.
>
> Edgar
>
>
>
>
>
Hi.
This is a start to get to be able to merge with trunk.

There is much more than the Etoys package in the images that must be
worked out before we can merge.

But hopefully trough some effort we can bring the two together. Etoys
image is 3.8 based so there are quite a few changes to account for...


Karl

Reply | Threaded
Open this post in threaded view
|

Re: [etoys-dev] Packaging Etoys

Stéphane Rollandin

> There is much more than the Etoys package in the images that must be
> worked out before we can merge.
>
> But hopefully trough some effort we can bring the two together. Etoys
> image is 3.8 based so there are quite a few changes to account for...

In the case where this effort would take the shape of some sort of a 3.8
compatibility layer, I think it would be very useful to make it
available by itself, since I guess there are many Squeak projects
currently based on 3.8 that would benefit from it (one of which being
mine, muO...)


Stef