Squeak wants to be a platform with support for legacy applications, and slow and smooth progress. Pharo explicitely cannot afford that (too expensive). It could also be the platform for rebasing Etoys, but I don't know what's up on this front.
2013/10/29 Pavel Krivanek squeak1@continentalbrno.cz
Hi Frank,
spending few minutes on it, I was able to produce very very dirty image (4.6MB). I did only few small changes. Use patch002.st, I attach patch001.st only for diff purposes. I only tried to make it work somehow and made the resultant image responsive. I was not able to recompile all the classes so I simply used ifError: statement so many of methods is still not recompiled. That's one reason why the resultant image is so dirty. The script works on my Linux machine, no clue what will it do on Mac or Win. You should look at the patch002.st, compare patched methods with recent versions. Maybe some currently do not need any change. The patch does not provide good or final solutions, it only shows the most creaking places.
I can help but you should understand that for me it's time I steal from Pharo that has much higher priority for me. I do not understand what Squeak is now and what it wants to be and I do not know last changes in it.
-- Pavel
2013/10/29 Frank Shearar frank.shearar@gmail.com:
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 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@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@gmail.com:
The problems you are going to face are:
- 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@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.orgbroken?
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