[squeak-dev] SqueakTrunk image on build.squeak.org broken?

Frank Shearar frank.shearar at gmail.com
Tue Oct 29 10:35:20 UTC 2013


On 29 October 2013 09:51, Frank Shearar <frank.shearar at gmail.com> wrote:
> I know, Pavel.
>
> If you want to see Squeak shrink faster, and finally catch up with
> your sterling work from ages ago, please take the image in
> http://build.squeak.org/job/SqueakTrunk/573/artifact/*zip*/archive.zip

And now with the correct URL:
http://build.squeak.org/job/SqueakTrunk/lastSuccessfulBuild/artifact/target/*zip*/target.zip

frank

> and see if I haven't broken anything. In particular, poke around the
> Parser, because Nicolas and I saw some problems in the update stream a
> while ago concerning Parser.
>
> Because one of the most serious non-technical problems that Squeak has
> is lack of people.
>
> frank
>
> On 29 October 2013 08:42, Pavel Krivanek <squeak1 at continentalbrno.cz> wrote:
>> Hi Nicolas,
>>
>> for Squeak we were able to shrink the system to a small kernel and
>> reload and initialize the Morphic back long ago. In 2006. Two years
>> before Pharo started to exist. The reason why Pharo can do it now and
>> Squeak not is not technical.
>>
>> Cheers,
>> -- Pavel
>>
>> 2013/10/25 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>> The problems you are going to face are:
>>> 1) you need a good package delimitation, with clear contracts (on which
>>> package/API do I depend?) both in the Squeak image (to save the package that
>>> you want to see reloaded) and in Pharo
>>> 2) the package delimitation has to be in good agreement, because the MC
>>> tools do not deal with package refactoring
>>> 3) since API are not in agreement, you gonna need plenty of glue for working
>>> around changes like trimBoth, includesSubstring: etc...
>>>
>>> What are your goals exactly?
>>>
>>> A) you want to build on top of smaller kernel?
>>> Then once you have 1), why should you go into Pharo rather than building on
>>> top of your Squeak kernel?
>>>
>>> B) you want to profit by clean-ups and refactorings and shiny new
>>> architecture made in Pharo?
>>> Then yes, porting some interesting Squeak bits to Pharo has some value.
>>> But that means you spend a lot of efforts for maintaining those bits alive.
>>> That means switching from old file system to new one, switching from old
>>> text system to (yet future) new one, switching to Spec, switching to
>>> Settings, Announcements etc...
>>>
>>> C) You have no specific goals, just want to follow the momentum, but keep
>>> your confortable Squeak slippers?
>>> If you end up with hacks for loading all the old Squeak mud, then you'll end
>>> up with Squeak, just a different Squeak, and unless you enjoy jumping many
>>> hurdles, I don't see the point.
>>>
>>>
>>> 2013/10/25 Edgar De Cleene <edgardec2005 at gmail.com>
>>>>
>>>>
>>>>
>>>> De: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>>>> Responder a: The general-purpose Squeak developers list
>>>> <squeak-dev at lists.squeakfoundation.org>
>>>> Fecha: Fri, 25 Oct 2013 14:06:43 +0200
>>>> Para: The general-purpose Squeak developers list
>>>> <squeak-dev at lists.squeakfoundation.org>
>>>> Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
>>>>
>>>> Yes, Pharo is doing a great work of simplification.
>>>> On the other hand, it deliberately has zero requirements to make removed
>>>> parts reloadable, so the task is a bit easier...
>>>>
>>>>
>>>> Still exploring and understanding his system, but reporting
>>>> ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working
>>>> on it, a long time work could be put our view of Morphic on top of his
>>>> kernel.
>>>>
>>>> Or Cuis Morph hierarchy.
>>>>
>>>> Edgar
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>


More information about the Squeak-dev mailing list