Package unload status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Package unload status

Andreas.Raab
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
Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Mariano Martinez Peck
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






Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Andreas.Raab
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
>
>
>
>
>
> ------------------------------------------------------------------------
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Edgar J. De Cleene
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






Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Edgar J. De Cleene
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






Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Eliot Miranda-2
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





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







Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Tobias Pape
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Sean Glazier-3
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





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








Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Andreas.Raab
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
Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Edgar J. De Cleene
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




Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Levente Uzonyi-2
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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Package unload status

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Package unload status

Andreas.Raab
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

12