... And for C) I suggest we call the monster Phreak ;)


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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131025/d297bb1c/attachment.htm