Smalltalk › Squeak › Squeak - Dev

CogVM binaries as per VMMaker.oscog-eem.302/r2749

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

33 messages Options

Nicolas Cellier

Re: SqueakTrunk image on build.squeak.org broken?

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 <[hidden email]>

De: Nicolas Cellier <[hidden email]>
Responder a: The general-purpose Squeak developers list <[hidden email]>
Fecha: Fri, 25 Oct 2013 14:06:43 +0200
Para: The general-purpose Squeak developers list <[hidden email]>
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

Nicolas Cellier

Re: SqueakTrunk image on build.squeak.org broken?

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

2013/10/25 Nicolas Cellier <[hidden email]>

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 <[hidden email]>

De: Nicolas Cellier <[hidden email]>
Responder a: The general-purpose Squeak developers list <[hidden email]>
Fecha: Fri, 25 Oct 2013 14:06:43 +0200
Para: The general-purpose Squeak developers list <[hidden email]>
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

Pavel Krivanek

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Nicolas Cellier

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 <[hidden email]>:

> 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 <[hidden email]>
>>
>>
>>
>> De: Nicolas Cellier <[hidden email]>
>> Responder a: The general-purpose Squeak developers list
>> <[hidden email]>
>> Fecha: Fri, 25 Oct 2013 14:06:43 +0200
>> Para: The general-purpose Squeak developers list
>> <[hidden email]>
>> 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
>>
>>
>>
>
>
>
>

Frank Shearar-3

Re: SqueakTrunk image on build.squeak.org broken?

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 <[hidden email]> 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 <[hidden email]>:
>> 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 <[hidden email]>
>>>
>>>
>>>
>>> De: Nicolas Cellier <[hidden email]>
>>> Responder a: The general-purpose Squeak developers list
>>> <[hidden email]>
>>> Fecha: Fri, 25 Oct 2013 14:06:43 +0200
>>> Para: The general-purpose Squeak developers list
>>> <[hidden email]>
>>> 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
>>>
>>>
>>>
>>
>>
>>
>>
>

Edgar De Cleene

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Pavel Krivanek

On 10/29/13, 5:42 AM, "Pavel Krivanek" <[hidden email]> 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

I take your mail for say MUCHAS GRACIAS for your work of all this years.
Extend to Guillermo and other people working on Hazelnut, Seed and related.
Wish know if you have a special list for this, Pharo list this days send too
many mails and los my focus.

To Nicolas, maybe I'm Dr. Frankenstein and like to build a Creature of best
parts of Squeak , Pharo and Cuis.

What I wish.

Kind of backwards compatibility which Pharo and Cuis lack now.
That do not means you must have a bad system.
Juan have a beautiful system and if I'm was younger stick to Cuis

Pharo seems the most serious, but again, change too fast to my taste.

This Wednesday we start Smalltalks 2013 here in Rosario

http://www.fast.org.ar/smalltalks2013

So I take the opportunity to talk face to face with bright people.

Edgar

Frank Shearar-3

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Frank Shearar-3

On 29 October 2013 09:51, Frank Shearar <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>> 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 <[hidden email]>
>>>>
>>>>
>>>>
>>>> De: Nicolas Cellier <[hidden email]>
>>>> Responder a: The general-purpose Squeak developers list
>>>> <[hidden email]>
>>>> Fecha: Fri, 25 Oct 2013 14:06:43 +0200
>>>> Para: The general-purpose Squeak developers list
>>>> <[hidden email]>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>

Nicolas Cellier

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Edgar De Cleene

I don't say it's not possible, especially if you stay concentrated on one distribution,
It's perfectly do-able, and I wish success to the 3 main branches, Cuis Pharo Squeak.

What I say is that transporting packages from one distribution to another is a tremendous work.

Even if we have cleaned inter-package dependencies (most of this hardwork effectively comes from Pavel in Squeak/Pharo branches), we have to suffer from

- different choices for some basic API (includeSubstring: as example)

- different delimitation of packages (Take Pharo Text-Scanning as example)

- total lack of support from Monticello

I sometimes tries to port some low level code (Kernel, Graphics, Morphic, Collection) from one distribution to another, and often resort to using change sets, MC just do not work.

Even if we would improve tools, the first two points depend on a minimum of coordination, and it's not in the mood of Pharo developers.

Pharo want to be free of these chains, because it has to win a sprint:

- clean up the maximum of dust before the system is frozen by large user base...

It's not a critic, I perfectly understand this position, it's a deliberate choice.

Nicolas

2013/10/29 Edgar J. De Cleene <[hidden email]>

On 10/29/13, 5:42 AM, "Pavel Krivanek" <[hidden email]> 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

I take your mail for say MUCHAS GRACIAS for your work of all this years.
Extend to Guillermo and other people working on Hazelnut, Seed and related.
Wish know if you have a special list for this, Pharo list this days send too
many mails and los my focus.

To Nicolas, maybe I'm Dr. Frankenstein and like to build a Creature of best
parts of Squeak , Pharo and Cuis.

What I wish.

Kind of backwards compatibility which Pharo and Cuis lack now.
That do not means you must have a bad system.
Juan have a beautiful system and if I'm was younger stick to Cuis

Pharo seems the most serious, but again, change too fast to my taste.

This Wednesday we start Smalltalks 2013 here in Rosario

http://www.fast.org.ar/smalltalks2013

So I take the opportunity to talk face to face with bright people.

Edgar

Pavel Krivanek

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Frank Shearar-3

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 <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]>:
>>> 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 <[hidden email]>
>>>>
>>>>
>>>>
>>>> De: Nicolas Cellier <[hidden email]>
>>>> Responder a: The general-purpose Squeak developers list
>>>> <[hidden email]>
>>>> Fecha: Fri, 25 Oct 2013 14:06:43 +0200
>>>> Para: The general-purpose Squeak developers list
>>>> <[hidden email]>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>

patch.zip (29K) Download Attachment

Edgar De Cleene

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Nicolas Cellier

De: Nicolas Cellier <[hidden email]>
Responder a: The general-purpose Squeak developers list <[hidden email]>
Fecha: Tue, 29 Oct 2013 11:38:56 +0100
Para: The general-purpose Squeak developers list <[hidden email]>
Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?

What I say is that transporting packages from one distribution to another is a tremendous work.

Yes. This is my point also.

If you wish port old Squeak packages (and some not too old) to Cuis or Pharo, take long time and lot of work.

I sometimes tries to port some low level code (Kernel, Graphics, Morphic, Collection) from one distribution to another, and often resort to using change sets, MC just do not work.

Well, back in the 3.10 times also think some things could not be made with MC.

Andreas prove me was wrong and you could do difficult things with MC.

But maybe we should try resurrect DeltaStreams or MC2 and see if works better.

I not against ChangeSets, in fact when I have time try to make all change sets from Trunk era and put somewhere for Bob collect in his system

Edgar

Nicolas Cellier

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Pavel Krivanek

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 <[hidden email]>

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 <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]>:
>>> 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 <[hidden email]>
>>>>
>>>>
>>>>
>>>> De: Nicolas Cellier <[hidden email]>
>>>> Responder a: The general-purpose Squeak developers list
>>>> <[hidden email]>
>>>> Fecha: Fri, 25 Oct 2013 14:06:43 +0200
>>>> Para: The general-purpose Squeak developers list
>>>> <[hidden email]>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>

Casey Ransberger-2

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Frank Shearar-3

And the work you're doing is absolutely stellar in this respect, but your metaphors are grotesque. I have a small amount of experience with marketing, do hit me up please?

:D

On Jul 28, 2013, at 11:22 AM, Frank Shearar <[hidden email]> wrote:

> It's a term I picked up from work: SqueakTrunk is like a dessicated,
> dried out thing that's quite small, like a dessicated pea. But
> ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
>
> As the package layering work proceeds, and more packages become
> unloadable, I unload them from SqueakTrunk. ReleaseSqueakTrunk takes
> that small SqueakTrunk artifact and reloads all those unloadable
> packages.
>
> The idea is that people just keep on using the ReleaseSqueakTrunk
> image, and without even realising it, are using a _constructed_ image,
> built up from some small core.
>
> frank
>
> On 28 July 2013 18:58, H. Hirzel <[hidden email]> wrote:
>> Question of clarification:
>>
>> What do you mean by a 'rehydrated image'?
>>
>> --HH
>>
>> On 7/28/13, David T. Lewis <[hidden email]> wrote:
>>> On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
>>>> On 28 July 2013 07:24, David T. Lewis <[hidden email]> wrote:
>>>>> I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM
>>>>> and
>>>>> CogVM jobs) have been failing for some time. These jobs use the latest
>>>>> trunk
>>>>> image from the SqueakTrunk job, which is supposed to be a base Squeak
>>>>> image
>>>>> updated from the trunk stream (see
>>>>> http://build.squeak.org/job/SqueakTrunk/).
>>>>> However, that image is missing the ST80 package entirely (which
>>>>> indirectly
>>>>> causes the VM tarball job failures).
>>>>>
>>>>> I tried to update the image (world menu -> help... -> update code from
>>>>> server) in hopes that this would load the missing packages, but this
>>>>> fails
>>>>> due to some other problem.
>>>>>
>>>>> The project comment for the SqueakTrunk job says:
>>>>>
>>>>> * Take a base image (currently 4.5-12565), update it, archive the
>>>>> result.
>>>>> * Run the entire suite of in-image tests.
>>>>>
>>>>> I think that I had mistakenly assumed that the "SqueakTrunk" job was a
>>>>> release
>>>>> image updated from the trunk stream, but actually it must be a stripped
>>>>> "base"
>>>>> image with packages reloaded, and maybe the reloading part has forgotten
>>>>> to
>>>>> install ST80. Is that right?
>>>>
>>>> Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image
>>>> _with_ ST80 and friends loaded.
>>>>
>>>> Sorry! I should have noticed the failing builds and connected that
>>>> with the recent stripping of ST80.
>>>>
>>>
>>> Not at all, it was not obvious that this was connected to the problem.
>>>
>>> I guess that once the package reorganizing settles down, it would be
>>> good to have some kind of sanity-check test to ensure that a rehydrated
>>> image contains the expected set of packages.
>>>
>>> Dave
>>>
>>>
>>>
>>
>

Casey Ransberger-2

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Nicolas Cellier

Inline one time

On Oct 25, 2013, at 6:21 AM, Nicolas Cellier <[hidden email]> wrote:

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

:D Phreak out! Which is admittedly a bit of a juxtaposition. All the same...

http://www.youtube.com/watch?v=xblSHz3Ugiw&feature=youtube_gdata_player

2013/10/25 Nicolas Cellier <[hidden email]>

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 <[hidden email]>

De: Nicolas Cellier <[hidden email]>
Responder a: The general-purpose Squeak developers list <[hidden email]>
Fecha: Fri, 25 Oct 2013 14:06:43 +0200
Para: The general-purpose Squeak developers list <[hidden email]>
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

Frank Shearar-3

Re: SqueakTrunk image on build.squeak.org broken?

In reply to this post by Pavel Krivanek

Hi Pavel,

Thanks for that! I'll definitely dig into this.

frank

On 29 October 2013 11:11, Pavel Krivanek <[hidden email]> wrote:

> 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 <[hidden email]>:
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>> 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 <[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>> De: Nicolas Cellier <[hidden email]>
>>>>> Responder a: The general-purpose Squeak developers list
>>>>> <[hidden email]>
>>>>> Fecha: Fri, 25 Oct 2013 14:06:43 +0200
>>>>> Para: The general-purpose Squeak developers list
>>>>> <[hidden email]>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>