Smalltalk › Squeak › Squeak - Dev

Package unload status

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

40 messages Options

Andreas.Raab

Package unload status

Folks -

I've been going through various packages, and we're actually capable of
unloading quite a bit of them cleanly by now. I've attached my unload
script which (on a most recent updated trunk image with no additional
packages loaded) will be able to unload the following packages:
- ReleaseBuilder, ScriptLoader
- 311Deprecated, 39Deprecated
- Universes, SMLoader, SMBase, Installer-Core
- VersionNumberTests, VersionNumber
- Services-Base, PreferenceBrowser, Nebraska
- CollectionsTests, GraphicsTests, KernelTests, MorphicTests
- MultilingualTests, NetworkTests, ToolsTests, TraitsTests
- XML-Parser, Traits
After these packages been unloaded there are no Undeclared references or
obsolete behaviors or modified MC packages. There are several more
candidate packages, some of which I could use some help with:

* Tests: The tests package is currently not unloadable because it
includes ClassTestCase which is used from several other places. There is
a fundamental question here whether we should aim for making all tests
as well as SUnit unloadable or not. If the former, then we need to move
tests out of packages like Files, System or MC in order to make them
unloadable. If we're not shooting for making SUnit unloadable it may be
worthwhile to promote ClassTestCase up to SUnit so that the Tests
package becomes unloadable. Comments?

* Morphic-Extras: I don't understand the intent of this package. The
name implies to me that it includes "extras" which I'd expect to be
optional content that should be unloadable at will but the reality is
that even attempting to unload it (I foolishly tried) blows up left and
right. Question: Is the intention of Morphic-Extras to contain
unloadable content? If so, it's not doing its job currently. If that's
not the intention of Morphic-Extras, I'd appreciate a heads-up of what
the rationale for the structure is.

* ST80: This is still a bit off but we're getting there. It can actually
be unloaded but there are still several Undeclared variables and
obsolete behaviors after unloading MVC. But the good news is that the
system is still functioning (!) instead of horribly dying as it used to
be. We could use a bit of additional help from people with an interest
in this area.

Cheers,
- Andreas

unloadall.st (2K) Download Attachment

Mariano Martinez Peck

Re: Package unload status

As a "repeater offender" you will probably don't answer be. But anyway... we were discussing a couple of days ago with the Pharo guys about unloading and the biggest problem we found were the overrides of the packages. Do you handle this situation?

Thanks

Mariano

On Sun, Jan 3, 2010 at 3:09 PM, Andreas Raab <[hidden email]> wrote:

Folks -

I've been going through various packages, and we're actually capable of unloading quite a bit of them cleanly by now. I've attached my unload script which (on a most recent updated trunk image with no additional packages loaded) will be able to unload the following packages:
- ReleaseBuilder, ScriptLoader
- 311Deprecated, 39Deprecated
- Universes, SMLoader, SMBase, Installer-Core
- VersionNumberTests, VersionNumber
- Services-Base, PreferenceBrowser, Nebraska
- CollectionsTests, GraphicsTests, KernelTests, MorphicTests
- MultilingualTests, NetworkTests, ToolsTests, TraitsTests
- XML-Parser, Traits
After these packages been unloaded there are no Undeclared references or obsolete behaviors or modified MC packages. There are several more candidate packages, some of which I could use some help with:

* Tests: The tests package is currently not unloadable because it includes ClassTestCase which is used from several other places. There is a fundamental question here whether we should aim for making all tests as well as SUnit unloadable or not. If the former, then we need to move tests out of packages like Files, System or MC in order to make them unloadable. If we're not shooting for making SUnit unloadable it may be worthwhile to promote ClassTestCase up to SUnit so that the Tests package becomes unloadable. Comments?

* Morphic-Extras: I don't understand the intent of this package. The name implies to me that it includes "extras" which I'd expect to be optional content that should be unloadable at will but the reality is that even attempting to unload it (I foolishly tried) blows up left and right. Question: Is the intention of Morphic-Extras to contain unloadable content? If so, it's not doing its job currently. If that's not the intention of Morphic-Extras, I'd appreciate a heads-up of what the rationale for the structure is.

* ST80: This is still a bit off but we're getting there. It can actually be unloaded but there are still several Undeclared variables and obsolete behaviors after unloading MVC. But the good news is that the system is still functioning (!) instead of horribly dying as it used to be. We could use a bit of additional help from people with an interest in this area.

Cheers,
- Andreas

Andreas.Raab

Re: Package unload status

Mariano Martinez Peck wrote:
> As a "repeater offender" you will probably don't answer be. But
> anyway... we were discussing a couple of days ago with the Pharo guys
> about unloading and the biggest problem we found were the overrides of
> the packages. Do you handle this situation?

Sure: Don't use overrides. Overrides are a necessary evil when you can't
change the underlying system to use proper means of composing the
desired behavior. However, if you are in control it's plain insanity to
use overrides. Why in the lord's name would you use overrides unless you
absolutely, positively had to?

Cheers,
- Andreas

> On Sun, Jan 3, 2010 at 3:09 PM, Andreas Raab <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Folks -
>
> I've been going through various packages, and we're actually capable
> of unloading quite a bit of them cleanly by now. I've attached my
> unload script which (on a most recent updated trunk image with no
> additional packages loaded) will be able to unload the following
> packages:
> - ReleaseBuilder, ScriptLoader
> - 311Deprecated, 39Deprecated
> - Universes, SMLoader, SMBase, Installer-Core
> - VersionNumberTests, VersionNumber
> - Services-Base, PreferenceBrowser, Nebraska
> - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
> - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
> - XML-Parser, Traits
> After these packages been unloaded there are no Undeclared
> references or obsolete behaviors or modified MC packages. There are
> several more candidate packages, some of which I could use some help
> with:
>
> * Tests: The tests package is currently not unloadable because it
> includes ClassTestCase which is used from several other places.
> There is a fundamental question here whether we should aim for
> making all tests as well as SUnit unloadable or not. If the former,
> then we need to move tests out of packages like Files, System or MC
> in order to make them unloadable. If we're not shooting for making
> SUnit unloadable it may be worthwhile to promote ClassTestCase up to
> SUnit so that the Tests package becomes unloadable. Comments?
>
> * Morphic-Extras: I don't understand the intent of this package. The
> name implies to me that it includes "extras" which I'd expect to be
> optional content that should be unloadable at will but the reality
> is that even attempting to unload it (I foolishly tried) blows up
> left and right. Question: Is the intention of Morphic-Extras to
> contain unloadable content? If so, it's not doing its job currently.
> If that's not the intention of Morphic-Extras, I'd appreciate a
> heads-up of what the rationale for the structure is.
>
> * ST80: This is still a bit off but we're getting there. It can
> actually be unloaded but there are still several Undeclared
> variables and obsolete behaviors after unloading MVC. But the good
> news is that the system is still functioning (!) instead of horribly
> dying as it used to be. We could use a bit of additional help from
> people with an interest in this area.
>
> Cheers,
> - Andreas
>
>
>
>
>
> ------------------------------------------------------------------------
>
>

Igor Stasenko

Re: Package unload status

In reply to this post by Andreas.Raab

2010/1/3 Andreas Raab <[hidden email]>:

> Folks -
>
> I've been going through various packages, and we're actually capable of
> unloading quite a bit of them cleanly by now. I've attached my unload script
> which (on a most recent updated trunk image with no additional packages
> loaded) will be able to unload the following packages:
> - ReleaseBuilder, ScriptLoader
> - 311Deprecated, 39Deprecated
> - Universes, SMLoader, SMBase, Installer-Core
> - VersionNumberTests, VersionNumber
> - Services-Base, PreferenceBrowser, Nebraska
> - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
> - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
> - XML-Parser, Traits
> After these packages been unloaded there are no Undeclared references or
> obsolete behaviors or modified MC packages. There are several more candidate
> packages, some of which I could use some help with:
>
> * Tests: The tests package is currently not unloadable because it includes
> ClassTestCase which is used from several other places. There is a
> fundamental question here whether we should aim for making all tests as well
> as SUnit unloadable or not. If the former, then we need to move tests out of
> packages like Files, System or MC in order to make them unloadable. If we're
> not shooting for making SUnit unloadable it may be worthwhile to promote
> ClassTestCase up to SUnit so that the Tests package becomes unloadable.
> Comments?
>

If that helps to cut the knot, why not?
Alternatively, we could make SUnit-Squeak package, where this class will reside,
or even move all test into such package. Tests should be unloadable,
without alternatives :)

> * Morphic-Extras: I don't understand the intent of this package. The name
> implies to me that it includes "extras" which I'd expect to be optional
> content that should be unloadable at will but the reality is that even
> attempting to unload it (I foolishly tried) blows up left and right.
> Question: Is the intention of Morphic-Extras to contain unloadable content?
> If so, it's not doing its job currently. If that's not the intention of
> Morphic-Extras, I'd appreciate a heads-up of what the rationale for the
> structure is.
>
> * ST80: This is still a bit off but we're getting there. It can actually be
> unloaded but there are still several Undeclared variables and obsolete
> behaviors after unloading MVC. But the good news is that the system is still
> functioning (!) instead of horribly dying as it used to be. We could use a
> bit of additional help from people with an interest in this area.
>
> Cheers,
> - Andreas
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Edgar J. De Cleene

Re: Package unload status

In reply to this post by Andreas.Raab

On 1/3/10 12:09 PM, "Andreas Raab" <[hidden email]> wrote:

> Folks -
>
> I've been going through various packages, and we're actually capable of
> unloading quite a bit of them cleanly by now. I've attached my unload
> script which (on a most recent updated trunk image with no additional
> packages loaded) will be able to unload the following packages:
> - ReleaseBuilder, ScriptLoader
> - 311Deprecated, 39Deprecated
> - Universes, SMLoader, SMBase, Installer-Core
> - VersionNumberTests, VersionNumber
> - Services-Base, PreferenceBrowser, Nebraska
> - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
> - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
> - XML-Parser, Traits
> After these packages been unloaded there are no Undeclared references or
> obsolete behaviors or modified MC packages. There are several more
> candidate packages, some of which I could use some help with:
>
> * Tests: The tests package is currently not unloadable because it
> includes ClassTestCase which is used from several other places. There is
> a fundamental question here whether we should aim for making all tests
> as well as SUnit unloadable or not.

If you keep part of actual SUnit and modify Monticello , Test could be
unloaded safely

> tests out of packages like Files, System or MC in order to make them
> unloadable. If we're not shooting for making SUnit unloadable it may be
> worthwhile to promote ClassTestCase up to SUnit so that the Tests
> package becomes unloadable. Comments?
>
> * Morphic-Extras: I don't understand the intent of this package. The
> name implies to me that it includes "extras" which I'd expect to be
> optional content that should be unloadable at will but the reality is
> that even attempting to unload it (I foolishly tried) blows up left and
> right. Question: Is the intention of Morphic-Extras to contain
> unloadable content? If so, it's not doing its job currently. If that's
> not the intention of Morphic-Extras, I'd appreciate a heads-up of what
> the rationale for the structure is.
>
> * ST80: This is still a bit off but we're getting there. It can actually
> be unloaded but there are still several Undeclared variables and
> obsolete behaviors after unloading MVC. But the good news is that the
> system is still functioning (!) instead of horribly dying as it used to
> be. We could use a bit of additional help from people with an interest
> in this area.
>
> Cheers,
> - Andreas

Finally Squeak3.11 could be closer to what I dream but fail to have
consensus and help for my ideas.
I said you should unload all NOW.
Or you prefer I work on TrunkLight and also on FunSqueak ?

Edgar

Edgar J. De Cleene

Re: Package unload status

In reply to this post by Igor Stasenko

On 1/3/10 2:00 PM, "Igor Stasenko" <[hidden email]> wrote:

> If that helps to cut the knot, why not?
> Alternatively, we could make SUnit-Squeak package, where this class will
> reside,
> or even move all test into such package. Tests should be unloadable,
> without alternatives :)

Unload all NOW !!!

Edgar

P.S Well, belonging to SqueakRos finally give me this Board member saying
yes to this I beg for two years.
Thanks Igor

Eliot Miranda-2

Re: Re: Package unload status

In reply to this post by Andreas.Raab

On Sun, Jan 3, 2010 at 7:49 AM, Andreas Raab <[hidden email]> wrote:

Mariano Martinez Peck wrote:

As a "repeater offender" you will probably don't answer be. But anyway... we were discussing a couple of days ago with the Pharo guys about unloading and the biggest problem we found were the overrides of the packages. Do you handle this situation?

Sure: Don't use overrides. Overrides are a necessary evil when you can't change the underlying system to use proper means of composing the desired behavior. However, if you are in control it's plain insanity to use overrides. Why in the lord's name would you use overrides unless you absolutely, positively had to?

Because one is experimenting. I agree with you Andreas that overrides are evil and that in a well-designed system they can be eliminated by well-designed extensibility conventions. However, in experimentation phases before such extensibility schemes have been engineered or been justified economically, good support for overrides are a reasonable substitute, and as you admit, necessary. The problem with Monticello's overrides is simply with their implementation above method versions. As we've discussed recently an alternative implementation of a dictionary from overridden item (method reference or class definition reference) to a dictionary from package name to version in that package, along with a global package load order, would allow the system to compute all the overridden items reliably at any time, and compute the most recent previous version when unloading a package that overrides. The modifications to Monticello would be minimal - maintain a global load order, enter overridden definitions into the override map on load, and remove entries from the override map on unload.

I know, code speaks louder than words. I'll see what I can do in my copious spare time ;)

Cheers,
- Andreas

On Sun, Jan 3, 2010 at 3:09 PM, Andreas Raab <[hidden email] <mailto:[hidden email]>> wrote:

Folks -

I've been going through various packages, and we're actually capable
of unloading quite a bit of them cleanly by now. I've attached my
unload script which (on a most recent updated trunk image with no
additional packages loaded) will be able to unload the following
packages:
- ReleaseBuilder, ScriptLoader
- 311Deprecated, 39Deprecated
- Universes, SMLoader, SMBase, Installer-Core
- VersionNumberTests, VersionNumber
- Services-Base, PreferenceBrowser, Nebraska
- CollectionsTests, GraphicsTests, KernelTests, MorphicTests
- MultilingualTests, NetworkTests, ToolsTests, TraitsTests
- XML-Parser, Traits
After these packages been unloaded there are no Undeclared
references or obsolete behaviors or modified MC packages. There are
several more candidate packages, some of which I could use some help
with:

* Tests: The tests package is currently not unloadable because it
includes ClassTestCase which is used from several other places.
There is a fundamental question here whether we should aim for
making all tests as well as SUnit unloadable or not. If the former,
then we need to move tests out of packages like Files, System or MC
in order to make them unloadable. If we're not shooting for making
SUnit unloadable it may be worthwhile to promote ClassTestCase up to
SUnit so that the Tests package becomes unloadable. Comments?

* Morphic-Extras: I don't understand the intent of this package. The
name implies to me that it includes "extras" which I'd expect to be
optional content that should be unloadable at will but the reality
is that even attempting to unload it (I foolishly tried) blows up
left and right. Question: Is the intention of Morphic-Extras to
contain unloadable content? If so, it's not doing its job currently.
If that's not the intention of Morphic-Extras, I'd appreciate a
heads-up of what the rationale for the structure is.

* ST80: This is still a bit off but we're getting there. It can
actually be unloaded but there are still several Undeclared
variables and obsolete behaviors after unloading MVC. But the good
news is that the system is still functioning (!) instead of horribly
dying as it used to be. We could use a bit of additional help from
people with an interest in this area.

Cheers,
- Andreas

------------------------------------------------------------------------

Tobias Pape

Re: Package unload status

In reply to this post by Andreas.Raab

Am 2010-01-03 um 15:09 schrieb Andreas Raab:

> * Morphic-Extras: I don't understand the intent of this package. The name implies to me that it includes "extras" which I'd expect to be optional content that should be unloadable at will but the reality is that even attempting to unload it (I foolishly tried) blows up left and right. Question: Is the intention of Morphic-Extras to contain unloadable content? If so, it's not doing its job currently. If that's not the intention of Morphic-Extras, I'd appreciate a heads-up of what the rationale for the structure is.

Perhaps the naming confuison led to the fact that
Morphic-Extras was named Polymorph in some system
configurations (mainly Pharo, but 3.10.2 may have
polymorph, too).

so long,
-Tobias

Sean Glazier-3

Re: Re: Package unload status

In reply to this post by Eliot Miranda-2

Hey,

Happy new year. I hope all is well with you and yours :-)

Sent from my iPhone

Sean Glazier

Live with Passion

On Jan 3, 2010, at 7:58 PM, Eliot Miranda <[hidden email]> wrote:

On Sun, Jan 3, 2010 at 7:49 AM, Andreas Raab <[hidden email]> wrote:

Mariano Martinez Peck wrote:

As a "repeater offender" you will probably don't answer be. But anyway... we were discussing a couple of days ago with the Pharo guys about unloading and the biggest problem we found were the overrides of the packages. Do you handle this situation?

Sure: Don't use overrides. Overrides are a necessary evil when you can't change the underlying system to use proper means of composing the desired behavior. However, if you are in control it's plain insanity to use overrides. Why in the lord's name would you use overrides unless you absolutely, positively had to?

Because one is experimenting. I agree with you Andreas that overrides are evil and that in a well-designed system they can be eliminated by well-designed extensibility conventions. However, in experimentation phases before such extensibility schemes have been engineered or been justified economically, good support for overrides are a reasonable substitute, and as you admit, necessary. The problem with Monticello's overrides is simply with their implementation above method versions. As we've discussed recently an alternative implementation of a dictionary from overridden item (method reference or class definition reference) to a dictionary from package name to version in that package, along with a global package load order, would allow the system to compute all the overridden items reliably at any time, and compute the most recent previous version when unloading a package that overrides. The modifications to Monticello would be minimal - maintain a global load order, enter overridden definitions into the override map on load, and remove entries from the override map on unload.

I know, code speaks louder than words. I'll see what I can do in my copious spare time ;)

Cheers,
- Andreas

On Sun, Jan 3, 2010 at 3:09 PM, Andreas Raab <[hidden email] <mailto:[hidden email]>> wrote:

Folks -

I've been going through various packages, and we're actually capable
of unloading quite a bit of them cleanly by now. I've attached my
unload script which (on a most recent updated trunk image with no
additional packages loaded) will be able to unload the following
packages:
- ReleaseBuilder, ScriptLoader
- 311Deprecated, 39Deprecated
- Universes, SMLoader, SMBase, Installer-Core
- VersionNumberTests, VersionNumber
- Services-Base, PreferenceBrowser, Nebraska
- CollectionsTests, GraphicsTests, KernelTests, MorphicTests
- MultilingualTests, NetworkTests, ToolsTests, TraitsTests
- XML-Parser, Traits
After these packages been unloaded there are no Undeclared
references or obsolete behaviors or modified MC packages. There are
several more candidate packages, some of which I could use some help
with:

* Tests: The tests package is currently not unloadable because it
includes ClassTestCase which is used from several other places.
There is a fundamental question here whether we should aim for
making all tests as well as SUnit unloadable or not. If the former,
then we need to move tests out of packages like Files, System or MC
in order to make them unloadable. If we're not shooting for making
SUnit unloadable it may be worthwhile to promote ClassTestCase up to
SUnit so that the Tests package becomes unloadable. Comments?

* Morphic-Extras: I don't understand the intent of this package. The
name implies to me that it includes "extras" which I'd expect to be
optional content that should be unloadable at will but the reality
is that even attempting to unload it (I foolishly tried) blows up
left and right. Question: Is the intention of Morphic-Extras to
contain unloadable content? If so, it's not doing its job currently.
If that's not the intention of Morphic-Extras, I'd appreciate a
heads-up of what the rationale for the structure is.

* ST80: This is still a bit off but we're getting there. It can
actually be unloaded but there are still several Undeclared
variables and obsolete behaviors after unloading MVC. But the good
news is that the system is still functioning (!) instead of horribly
dying as it used to be. We could use a bit of additional help from
people with an interest in this area.

Cheers,
- Andreas

------------------------------------------------------------------------

Andreas.Raab

Re: Package unload status

In reply to this post by Andreas.Raab

Folks -

Here is the latest from the unloading front. In addition to the packages
that could be un- and reloaded the last time around, namely:

> - ReleaseBuilder, ScriptLoader
> - 311Deprecated, 39Deprecated
> - Universes, SMLoader, SMBase, Installer-Core
> - VersionNumberTests, VersionNumber
> - Services-Base, PreferenceBrowser, Nebraska
> - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
> - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
> - XML-Parser, Traits

we can now also un- and reload:
- SystemChangeNotification-Tests, FlexibleVocabularies
- EToys, Protocols
- Tests, SUnitGUI

I decided on an intermediate approach for Tests namely to move all of
Files-Tests, Compiler-Tests, System-Tests, Monticello-Tests etc. into
the Tests package which removed the ClassTestCase dependency.

With the amount of packages removed, we're also starting to get into
"more interesting" ranges for the size of the resulting images. Compare
these numbers for example:

Image Version Classes Methods
Cuis 2.0 644 17442
Squeak Unloaded 1330 33564
Squeak Regular 1951 43906

The great news is that we're roughly halfways on our way towards a
kernel the size of Cuis. I'm hoping that as things get smaller we can
find common ground such that Cuis + MC + M17N = SqueakCore (or something
close to that). FWIW, here are the largest packages after removal:

Package Classes Methods
Morphic 185 6925
Kernel 86 3509
System 120 3204
MorphicExtras 126 2856
Graphics 57 2257
Collections 89 2196
Tools 50 1724
ST80 66 1509
Monticello 97 1439
Network 61 1360
Sound 54 1234
Compiler 53 1151
Multilingual 92 1051
Files 18 509
Balloon 22 462
Compression 28 436
ToolBuilder-Kernel 20 317
SUnit 16 311
TrueType 9 209
ToolBuilder-Morphic 12 173
ShoutCore 4 143
Exceptions 40 141
PackageInfo-Base 4 133
MonticelloConfigurations 6 122
ToolBuilder-SUnit 12 80
ToolBuilder-MVC 3 57

Cheers,
- Andreas

unloadall.st (1K) Download Attachment

Juan Vuletich-4

Re: Package unload status

In reply to this post by Andreas.Raab

Andreas Raab wrote:

> ...
>
> * Morphic-Extras: I don't understand the intent of this package. The
> name implies to me that it includes "extras" which I'd expect to be
> optional content that should be unloadable at will but the reality is
> that even attempting to unload it (I foolishly tried) blows up left
> and right. Question: Is the intention of Morphic-Extras to contain
> unloadable content? If so, it's not doing its job currently. If that's
> not the intention of Morphic-Extras, I'd appreciate a heads-up of what
> the rationale for the structure is.
>

Hi Andreas,

I did the original split of Morphic into Morphic, Morphic-Extras and
Etoys, loooong time ago. You're right. The intent was to include there
morphic stuff that is non-core and non-Etoys. The long term objective
was to make those packages unloadable. However, I never got past that
initial split. I have not been the team leader for Morphic for several
years nos. Feel free to restructure those packages as you see fit.

Cheers,
Juan Vuletich

Juan Vuletich-4

Re: Re: Package unload status

In reply to this post by Andreas.Raab

Hi...

Andreas Raab wrote:

> Folks -
>
> Here is the latest from the unloading front. In addition to the
> packages that could be un- and reloaded the last time around, namely:
>
>> - ReleaseBuilder, ScriptLoader
>> - 311Deprecated, 39Deprecated
>> - Universes, SMLoader, SMBase, Installer-Core
>> - VersionNumberTests, VersionNumber
>> - Services-Base, PreferenceBrowser, Nebraska
>> - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
>> - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
>> - XML-Parser, Traits
>
> we can now also un- and reload:
> - SystemChangeNotification-Tests, FlexibleVocabularies
> - EToys, Protocols
> - Tests, SUnitGUI
>
> I decided on an intermediate approach for Tests namely to move all of
> Files-Tests, Compiler-Tests, System-Tests, Monticello-Tests etc. into
> the Tests package which removed the ClassTestCase dependency.
>
> With the amount of packages removed, we're also starting to get into
> "more interesting" ranges for the size of the resulting images.
> Compare these numbers for example:
>
> Image Version Classes Methods
> Cuis 2.0 644 17442
> Squeak Unloaded 1330 33564
> Squeak Regular 1951 43906
>
> The great news is that we're roughly halfways on our way towards a
> kernel the size of Cuis. I'm hoping that as things get smaller we can
> find common ground such that Cuis + MC + M17N = SqueakCore (or
> something close to that).

Great job, Andreas!

Using Cuis as the base for Squeak would be fantastic. I'll be happy to
help from the Cuis side.

> FWIW, here are the largest packages after removal:
>
> Package Classes Methods
> Morphic 185 6925
> Kernel 86 3509
> System 120 3204
> MorphicExtras 126 2856
> Graphics 57 2257
> Collections 89 2196
> Tools 50 1724
> ST80 66 1509
> Monticello 97 1439
> Network 61 1360
> Sound 54 1234
> Compiler 53 1151
> Multilingual 92 1051
> Files 18 509
> Balloon 22 462
> Compression 28 436
> ToolBuilder-Kernel 20 317
> SUnit 16 311
> TrueType 9 209
> ToolBuilder-Morphic 12 173
> ShoutCore 4 143
> Exceptions 40 141
> PackageInfo-Base 4 133
> MonticelloConfigurations 6 122
> ToolBuilder-SUnit 12 80
> ToolBuilder-MVC 3 57
>
> Cheers,
> - Andreas
>

Cheers,
Juan Vuletich

Edgar J. De Cleene

Re: Re: Package unload status

In reply to this post by Andreas.Raab

On 1/5/10 11:22 AM, "Andreas Raab" <[hidden email]> wrote:

> Folks -
>
> Here is the latest from the unloading front. In addition to the packages
> that could be un- and reloaded the last time around, namely:
>
>> - ReleaseBuilder, ScriptLoader
>> - 311Deprecated, 39Deprecated
>> - Universes, SMLoader, SMBase, Installer-Core
>> - VersionNumberTests, VersionNumber
>> - Services-Base, PreferenceBrowser, Nebraska
>> - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
>> - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
>> - XML-Parser, Traits
>
> we can now also un- and reload:
> - SystemChangeNotification-Tests, FlexibleVocabularies
> - EToys, Protocols
> - Tests, SUnitGUI
>
> I decided on an intermediate approach for Tests namely to move all of
> Files-Tests, Compiler-Tests, System-Tests, Monticello-Tests etc. into
> the Tests package which removed the ClassTestCase dependency.
>
> With the amount of packages removed, we're also starting to get into
> "more interesting" ranges for the size of the resulting images. Compare
> these numbers for example:
>
> Image Version Classes Methods
> Cuis 2.0 644 17442
> Squeak Unloaded 1330 33564
> Squeak Regular 1951 43906
>
> The great news is that we're roughly halfways on our way towards a
> kernel the size of Cuis. I'm hoping that as things get smaller we can
> find common ground such that Cuis + MC + M17N = SqueakCore (or something
> close to that). FWIW, here are the largest packages after removal:
>
> Package Classes Methods
> Morphic 185 6925
> Kernel 86 3509
> System 120 3204
> MorphicExtras 126 2856
> Graphics 57 2257
> Collections 89 2196
> Tools 50 1724
> ST80 66 1509
> Monticello 97 1439
> Network 61 1360
> Sound 54 1234
> Compiler 53 1151
> Multilingual 92 1051
> Files 18 509
> Balloon 22 462
> Compression 28 436
> ToolBuilder-Kernel 20 317
> SUnit 16 311
> TrueType 9 209
> ToolBuilder-Morphic 12 173
> ShoutCore 4 143
> Exceptions 40 141
> PackageInfo-Base 4 133
> MonticelloConfigurations 6 122
> ToolBuilder-SUnit 12 80
> ToolBuilder-MVC 3 57
>
> Cheers,
> - Andreas
>
> ?
>

This is GREAT news.
I like help with any Cuis + MC + M17N = SqueakCore , starting with
3.11Unloaded.

Edgar

Igor Stasenko

Re: Re: Package unload status

2010/1/5 Edgar J. De Cleene <[hidden email]>:
>
>
>
> This is GREAT news.
> I like help with any Cuis + MC + M17N = SqueakCore , starting with
> 3.11Unloaded.
>

And what to do with all changes to Kernel being added recently to trunk?
Or you want to deal with them later, in same fashion as Juan
backported closure compiler?

> Edgar
>
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Levente Uzonyi-2

Re: Re: Package unload status

On Wed, 6 Jan 2010, Igor Stasenko wrote:

> 2010/1/5 Edgar J. De Cleene <[hidden email]>:
>>
>>
>>
>> This is GREAT news.
>> I like help with any Cuis + MC + M17N = SqueakCore , starting with
>> 3.11Unloaded.
>>
>
> And what to do with all changes to Kernel being added recently to trunk?
> Or you want to deal with them later, in same fashion as Juan
> backported closure compiler?

That's going to be a lot of work. AFAIK Cuis is built on top of 3.7, so
it probably doesn't have the changes from 3.8, 3.9 and 3.10 besides the
trunk changes. Another issue with this approach is licensing.

Levente

>
>> Edgar
>>
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Andreas.Raab

Re: Package unload status

In reply to this post by Igor Stasenko

Igor Stasenko wrote:

> 2010/1/5 Edgar J. De Cleene <[hidden email]>:
>>
>>
>> This is GREAT news.
>> I like help with any Cuis + MC + M17N = SqueakCore , starting with
>> 3.11Unloaded.
>>
>
> And what to do with all changes to Kernel being added recently to trunk?
> Or you want to deal with them later, in same fashion as Juan
> backported closure compiler?

It's too early to answer these questions, but what I'm thinking goes
roughly along the lines of using Cuis to define the scope of the image
but use the implementation from the trunk. In other words, I'm more
interested to use Cuis to cut down on the number of classes and methods
in the image rather than their specific implementations. It's quite
clear that given the difference in number of methods, for example, in
class Morph (500 vs. 1000) there is a lot of room for moving things into
unloadable parts.

However, at this point, the goal still needs to be getting more packages
un- and reloadable. There is a learning process involved in that which
very useful to understand how to slice and dice the system to make more
self-contained entities.

Cheers,
- Andreas

Juan Vuletich-4

Re: Re: Package unload status

In reply to this post by Levente Uzonyi-2

Levente Uzonyi wrote:

> On Wed, 6 Jan 2010, Igor Stasenko wrote:
>
>> 2010/1/5 Edgar J. De Cleene <[hidden email]>:
>>>
>>>
>>>
>>> This is GREAT news.
>>> I like help with any Cuis + MC + M17N = SqueakCore , starting with
>>> 3.11Unloaded.
>>>
>>
>> And what to do with all changes to Kernel being added recently to trunk?
>> Or you want to deal with them later, in same fashion as Juan
>> backported closure compiler?
>
> That's going to be a lot of work. AFAIK Cuis is built on top of 3.7,
> so it probably doesn't have the changes from 3.8, 3.9 and 3.10 besides
> the trunk changes.

Cuis is not "built on top" of 3.7 but derived from it, in the same way
as 3.8, 3.9, etc. Cuis does include many changes from later Squeak
versions, especially bugfixes to kernel. If I could get Closures working
on it, porting anything else will be much easier than that. Besides,
Squeak trunk is actually closer to 3.7 than Cuis is. I mean, I really
modified lots of stuff there.

Anyway, after stripping a lof of stuff from Cuis, I can tell that the
biggest work of all will be to turn packages into well factored units
that can be unloaded and reloaded. I avoided that. I just removed them.
That's why I believe Andreas is right: the best way is to work in
Squeak, using Cuis as a reference.

> Another issue with this approach is licensing.

There are no licensing issues. Cuis is MIT.

> Levente

Cheers,
Juan Vuletich

Igor Stasenko

Re: Re: Package unload status

In reply to this post by Andreas.Raab

2010/1/6 Andreas Raab <[hidden email]>:

> Igor Stasenko wrote:
>>
>> 2010/1/5 Edgar J. De Cleene <[hidden email]>:
>>>
>>>
>>> This is GREAT news.
>>> I like help with any Cuis + MC + M17N = SqueakCore , starting with
>>> 3.11Unloaded.
>>>
>>
>> And what to do with all changes to Kernel being added recently to trunk?
>> Or you want to deal with them later, in same fashion as Juan
>> backported closure compiler?
>
> It's too early to answer these questions, but what I'm thinking goes roughly
> along the lines of using Cuis to define the scope of the image but use the
> implementation from the trunk. In other words, I'm more interested to use
> Cuis to cut down on the number of classes and methods in the image rather
> than their specific implementations. It's quite clear that given the
> difference in number of methods, for example, in class Morph (500 vs. 1000)
> there is a lot of room for moving things into unloadable parts.
>

+1
I suppose, Edgar had same thought in mind, but didn't expressed it well :)
I just asked to be sure.

> However, at this point, the goal still needs to be getting more packages un-
> and reloadable. There is a learning process involved in that which very
> useful to understand how to slice and dice the system to make more
> self-contained entities.
>

+100. Lets follow that road.

> Cheers,
> - Andreas

--
Best regards,
Igor Stasenko AKA sig.

Juan Vuletich-4

Re: Re: Package unload status

In reply to this post by Andreas.Raab

Andreas Raab wrote:

> Igor Stasenko wrote:
>> 2010/1/5 Edgar J. De Cleene <[hidden email]>:
>>>
>>>
>>> This is GREAT news.
>>> I like help with any Cuis + MC + M17N = SqueakCore , starting with
>>> 3.11Unloaded.
>>>
>>
>> And what to do with all changes to Kernel being added recently to trunk?
>> Or you want to deal with them later, in same fashion as Juan
>> backported closure compiler?
>
> It's too early to answer these questions, but what I'm thinking goes
> roughly along the lines of using Cuis to define the scope of the image
> but use the implementation from the trunk. In other words, I'm more
> interested to use Cuis to cut down on the number of classes and
> methods in the image rather than their specific implementations. It's
> quite clear that given the difference in number of methods, for
> example, in class Morph (500 vs. 1000) there is a lot of room for
> moving things into unloadable parts.
>
> However, at this point, the goal still needs to be getting more
> packages un- and reloadable. There is a learning process involved in
> that which very useful to understand how to slice and dice the system
> to make more self-contained entities.
>
> Cheers,
> - Andreas

I fully agree.

BTW, in Cuis, Morph will eventually have a lot less than 500 methods. I
hope to get to about 200.

Cheers,
Juan Vuletich

Andreas.Raab

Re: Package unload status

Juan Vuletich wrote:
> BTW, in Cuis, Morph will eventually have a lot less than 500 methods. I
> hope to get to about 200.

Very nice. It's extremely valuable to have someone with a real interest
in making things smaller. Coincidentally, I'm quite okay with the idea
that Cuis will always have a smaller image than a core Squeak image
would be. I think the important part is to have reasonable compatibility
betweeen the two. I want compatible kernel interfaces, compatible
collection libraries, compatible morph protocols. In other words,
anything built for Cuis should run on top of Squeak without changes.

Cheers,
- Andreas