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 |
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 - |
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 > > > > > > ------------------------------------------------------------------------ > > |
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? > 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. |
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 |
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 |
In reply to this post by Andreas.Raab
On Sun, Jan 3, 2010 at 7:49 AM, Andreas Raab <[hidden email]> wrote:
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, |
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 |
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
|
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 |
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 |
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 |
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 |
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. |
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. > > |
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 |
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 |
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. > 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. |
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 |
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 |
Free forum by Nabble | Edit this page |