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/91e71a81/attachment.htm