Towards SqueakCore
Locked
123
123
re: Toward SqueakCore (including alternative plan)
 
|
Hi Frank-- > Some of those circles we may never resolve. Craig Latta might have > some insight here, because he had to deal with these issues in the > creation of his micro-images. > > Craig? With the current technique[1], I don't have to deal with those issues at all to make minimal object memories. I wrote a variant of the garbage collector that collects methods not run since a certain point in time. I reset a mark on all methods, run unit tests for the stuff I want to keep, and everything else vanishes. It takes a few seconds. Before I started doing that, I was ripping things out manually with a remote browser, so I didn't have to think about most of the circularities (e.g., breaking the target's GUI was fine because I wasn't using it). Generally, I advocate creating modules by imprinting[2] unit tests onto a minimal memory. We can divide the work of rounding out the unit tests using the current class categories, and prioritize by what we miss most when using a minimal system. I expect we have lots of opinions about that, so there should be plenty of volunteers. :) I volunteer to coordinate this. I'll start by making an example of a simple "echo" network server[3]. I'll provide a package for Squeak 4.4 that installs imprinting support, and another that installs the echo server code and an imprinting unit test. You imprint the unit test's code onto a minimal memory, then get data echoed back to you from a newly-created echo server running there. We can move onto more interesting things, like graphics (or WebDAV, or...). I advocate a new all-live-objects module system as well[4], but the organizational info gleaned from this work would lead to useful artifacts with any of the other ones (e.g., Monticello). As for the DependencyBrowser data, I think it would be better to express the connections directly between classes, and ignore the class categories for now. (Actually, I'd like to drop the class categories permanently, and use tags instead[5].) Class references are the basis of the dependency graph, the categories are a distraction. Let's identify the methods causing reference circularities between classes. thanks, -C [1] http://tinyurl.com/bz3eyzq (thiscontext.wordpress.com) [2] http://tinyurl.com/ajttt52 (thiscontext.wordpress.com) [3] https://tools.ietf.org/html/rfc862 [4] http://tinyurl.com/aoudtnq (thiscontext.wordpress.com) [5] http://netjam.org/spoon/naiad (sorry, no pretty blog version yet) -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
In reply to this post by timrowledge
> ...unload them once to make the small core image and make the > packages *load* nicely. Being able to unload seems likely to require > tracking what was changed so you can restore it - and not just once > but potentially many times with odd combinations for multi layers of > loaded packages. Hear, hear. :) -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
In reply to this post by Colin Putney-3
On 12 February 2013 20:24, Colin Putney <[hidden email]> wrote:
> > > > On Tue, Feb 12, 2013 at 5:54 AM, Tobias Pape <[hidden email]> wrote: > >> >> Note the big circle from System over ST80 to Morphic and from there via >> Ballon/Collections >> back to System, or via Monticello/Kernel/Collection back to System. >> Apart from that, note a direct circl (MonticelloMocks<->Tests) but also a >> small >> indirect circles (System->Environments->Compiler->System). > > > Yes! We should especially look at System->GetText > > One thing that seems odd is that many packages depend on Tests, but very few > depend on SUnit. You would think that all those TestCase subclasses would > create dependencies on SUnit, not Tests. The arrows might be pointing in an unintuitive direction then: a TestCase subclass of course implies a dependency on SUnit, and the arrows might actually say "is used by" rather than "uses" (or the other way around; I've only just woken up). frank > Sorting out all the test packages might be an easy place to start. > > Colin > > > > |
|
|
In reply to this post by Colin Putney-3
Hey Colin
Am 12.02.2013 um 21:24 schrieb Colin Putney <[hidden email]>: > > On Tue, Feb 12, 2013 at 5:54 AM, Tobias Pape <[hidden email]> wrote: > > Note the big circle from System over ST80 to Morphic and from there via Ballon/Collections > back to System, or via Monticello/Kernel/Collection back to System. > Apart from that, note a direct circl (MonticelloMocks<->Tests) but also a small > indirect circles (System->Environments->Compiler->System). > > Yes! We should especially look at System->GetText > > One thing that seems odd is that many packages depend on Tests, but very few depend on SUnit. You would think that all those TestCase subclasses would create dependencies on SUnit, not Tests. > The point here is the Transitivity of dependencies and the *BIG* loop via Tests->Collections->System->ST80->Morphic->Monitcello->ToolBuilder-Kernel->SUnit(->Kernel->Collections) In the original deps, most of the Packages depending on Tests also directly depend on SUnit. BUT: ToolBuilder-Kernel also directly depends on SUnit but _not_ on Tests, hence SUnit “moved” in the part of the circle with Toolbuilder and Kernel. So Colin, you made me play around again. I removed the direct dependencies of ToolBuilder-Kernel Compression ST-80 EToys on SUnit and got a much cleaner picture now. (deps-simplified-reclustered-colored.pdf) We got exactly 6 Clusters now and they seem more sensible. I did not manually add clusters now. Hope there's insight with this ;) Best -Tobias [Find the new pictures at http://netshed.de/trunk-deps2.zip ] |
|
|
In reply to this post by Hannes Hirzel
On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote:
> Yanni, > > I think St??phane refers to the original Pharo manifesto which clearly > states "no backward compatibility". http://code.google.com/p/pharo/ > > However the current Pharo web page has a mission statement > http://www.pharo-project.org/about > sets a much more moderate tone. > > In any case in this thread we want to move on towards a Squeak core > and learn from the Pharo experience as much as possible. Please let us > not digress from this important topic. > > Maybe we should follow both at the same time > > Let me call it > - the Pavel Krivanek approach and > - the > SmalltalkImage unloadAllKnownPackages > approach > > BTW > #unloadAllKnownPackages > > used to work in Squeak 4.1, see > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.html > > So there is no reason why we should not manage to get it working again > in Squeak 4.5alpha. > > And Pavel's approach may be followed in parallel. Because fixing one > thing will help the other and vice-verse. > +1 Exactly so. That is what I intended when I mentioned #unloadAllKnownPackages. Thanks for stating it so clearly. Dave |
|
|
On 13 February 2013 11:22, David T. Lewis <[hidden email]> wrote:
> On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote: >> Yanni, >> >> I think St??phane refers to the original Pharo manifesto which clearly >> states "no backward compatibility". http://code.google.com/p/pharo/ >> >> However the current Pharo web page has a mission statement >> http://www.pharo-project.org/about >> sets a much more moderate tone. >> >> In any case in this thread we want to move on towards a Squeak core >> and learn from the Pharo experience as much as possible. Please let us >> not digress from this important topic. >> >> Maybe we should follow both at the same time >> >> Let me call it >> - the Pavel Krivanek approach and >> - the >> SmalltalkImage unloadAllKnownPackages >> approach >> >> BTW >> #unloadAllKnownPackages >> >> used to work in Squeak 4.1, see >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.html >> >> So there is no reason why we should not manage to get it working again >> in Squeak 4.5alpha. >> >> And Pavel's approach may be followed in parallel. Because fixing one >> thing will help the other and vice-verse. >> > > +1 > > Exactly so. That is what I intended when I mentioned #unloadAllKnownPackages. > Thanks for stating it so clearly. While we're being clear about what's clear :) I'm wanting to _lose_ #unloadAllKnownPackages, and replace it with a #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload, and add a bunch of new jobs running those unloaded packages' test suites. That way, the thing called Squeak4.5-nnnn.image still contains what Squeak4.5-${whatever_current_is}.image, only the essence of trunk - what SqueakTrunk produces - shrinks. > Dave |
|
|
Frank
If I understand you correctly you want to do the following 1) unload some once packages from trunk. The packages are taken from what is in the list in #unloadAllKnownPackages. 2) add a trunk method #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload 3) add CI build jobs which do #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload and run tests on the loaded packages. 4) People use the result of 3) for regular work. This is the "full" 4.5 image as we have of now only that we have less in trunk and the unlodable packages reside in their own repositories. Steps 2..4 are done repeatedly. Is this what you mean? --Hannes On 2/13/13, Frank Shearar <[hidden email]> wrote: > On 13 February 2013 11:22, David T. Lewis <[hidden email]> wrote: >> On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote: >>> Yanni, >>> >>> I think St??phane refers to the original Pharo manifesto which clearly >>> states "no backward compatibility". http://code.google.com/p/pharo/ >>> >>> However the current Pharo web page has a mission statement >>> http://www.pharo-project.org/about >>> sets a much more moderate tone. >>> >>> In any case in this thread we want to move on towards a Squeak core >>> and learn from the Pharo experience as much as possible. Please let us >>> not digress from this important topic. >>> >>> Maybe we should follow both at the same time >>> >>> Let me call it >>> - the Pavel Krivanek approach and >>> - the >>> SmalltalkImage unloadAllKnownPackages >>> approach >>> >>> BTW >>> #unloadAllKnownPackages >>> >>> used to work in Squeak 4.1, see >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.html >>> >>> So there is no reason why we should not manage to get it working again >>> in Squeak 4.5alpha. >>> >>> And Pavel's approach may be followed in parallel. Because fixing one >>> thing will help the other and vice-verse. >>> >> >> +1 >> >> Exactly so. That is what I intended when I mentioned >> #unloadAllKnownPackages. >> Thanks for stating it so clearly. > > While we're being clear about what's clear :) I'm wanting to _lose_ > #unloadAllKnownPackages, and replace it with a > #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload, and add a > bunch of new jobs running those unloaded packages' test suites. > > That way, the thing called Squeak4.5-nnnn.image still contains what > Squeak4.5-${whatever_current_is}.image, only the essence of trunk - > what SqueakTrunk produces - shrinks. > >> Dave > > |
|
|
In reply to this post by Colin Putney-3
On 2013-02-12, at 21:24, Colin Putney <[hidden email]> wrote:
> We should especially look at System->GetText IMHO #translated and co. should be part of the System package, because senders are necessarily sprinkled all over the place. There should be a translator registry and if no translator were registered it would return the string untranslated. GetText would hook into that. - Bert - |
|
|
In reply to this post by Hannes Hirzel
On 13 February 2013 12:45, H. Hirzel <[hidden email]> wrote:
> Frank > > If I understand you correctly you want to do the following > > 1) unload some once packages from trunk. The packages are taken from > what is in the list in #unloadAllKnownPackages. > > 2) add a trunk method #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload > > 3) add CI build jobs which do > #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload and run tests > on the loaded packages. > > 4) People use the result of 3) for regular work. This is the "full" > 4.5 image as we have of now only that we have less in trunk and the > unlodable packages reside in their own repositories. > > Steps 2..4 are done repeatedly. > > Is this what you mean? Yes. Perhaps with a nicer name than #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload. Maybe #loadBasicPackages or something. My main aim is to invert the approach we've had up until now, and _enforce_ the clean separation of these packages from the Core. I want it to be difficult to add a dependency from the Core to these packages. frank > --Hannes > > On 2/13/13, Frank Shearar <[hidden email]> wrote: >> On 13 February 2013 11:22, David T. Lewis <[hidden email]> wrote: >>> On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote: >>>> Yanni, >>>> >>>> I think St??phane refers to the original Pharo manifesto which clearly >>>> states "no backward compatibility". http://code.google.com/p/pharo/ >>>> >>>> However the current Pharo web page has a mission statement >>>> http://www.pharo-project.org/about >>>> sets a much more moderate tone. >>>> >>>> In any case in this thread we want to move on towards a Squeak core >>>> and learn from the Pharo experience as much as possible. Please let us >>>> not digress from this important topic. >>>> >>>> Maybe we should follow both at the same time >>>> >>>> Let me call it >>>> - the Pavel Krivanek approach and >>>> - the >>>> SmalltalkImage unloadAllKnownPackages >>>> approach >>>> >>>> BTW >>>> #unloadAllKnownPackages >>>> >>>> used to work in Squeak 4.1, see >>>> >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.html >>>> >>>> So there is no reason why we should not manage to get it working again >>>> in Squeak 4.5alpha. >>>> >>>> And Pavel's approach may be followed in parallel. Because fixing one >>>> thing will help the other and vice-verse. >>>> >>> >>> +1 >>> >>> Exactly so. That is what I intended when I mentioned >>> #unloadAllKnownPackages. >>> Thanks for stating it so clearly. >> >> While we're being clear about what's clear :) I'm wanting to _lose_ >> #unloadAllKnownPackages, and replace it with a >> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload, and add a >> bunch of new jobs running those unloaded packages' test suites. >> >> That way, the thing called Squeak4.5-nnnn.image still contains what >> Squeak4.5-${whatever_current_is}.image, only the essence of trunk - >> what SqueakTrunk produces - shrinks. >> >>> Dave >> >> > |
|
|
Yes, thank you for the clarification, Frank. This makes a lot of sense
to me and I hope that others follow this line of reasoning. --Hannes On 2/13/13, Frank Shearar <[hidden email]> wrote: > On 13 February 2013 12:45, H. Hirzel <[hidden email]> wrote: >> Frank >> >> If I understand you correctly you want to do the following >> >> 1) unload some once packages from trunk. The packages are taken from >> what is in the list in #unloadAllKnownPackages. >> >> 2) add a trunk method >> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload >> >> 3) add CI build jobs which do >> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload and run tests >> on the loaded packages. >> >> 4) People use the result of 3) for regular work. This is the "full" >> 4.5 image as we have of now only that we have less in trunk and the >> unlodable packages reside in their own repositories. >> >> Steps 2..4 are done repeatedly. >> >> Is this what you mean? > > Yes. Perhaps with a nicer name than > #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload. Maybe > #loadBasicPackages or something. > > My main aim is to invert the approach we've had up until now, and > _enforce_ the clean separation of these packages from the Core. I want > it to be difficult to add a dependency from the Core to these > packages. > > frank > >> --Hannes >> >> On 2/13/13, Frank Shearar <[hidden email]> wrote: >>> On 13 February 2013 11:22, David T. Lewis <[hidden email]> wrote: >>>> On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote: >>>>> Yanni, >>>>> >>>>> I think St??phane refers to the original Pharo manifesto which clearly >>>>> states "no backward compatibility". http://code.google.com/p/pharo/ >>>>> >>>>> However the current Pharo web page has a mission statement >>>>> http://www.pharo-project.org/about >>>>> sets a much more moderate tone. >>>>> >>>>> In any case in this thread we want to move on towards a Squeak core >>>>> and learn from the Pharo experience as much as possible. Please let us >>>>> not digress from this important topic. >>>>> >>>>> Maybe we should follow both at the same time >>>>> >>>>> Let me call it >>>>> - the Pavel Krivanek approach and >>>>> - the >>>>> SmalltalkImage unloadAllKnownPackages >>>>> approach >>>>> >>>>> BTW >>>>> #unloadAllKnownPackages >>>>> >>>>> used to work in Squeak 4.1, see >>>>> >>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.html >>>>> >>>>> So there is no reason why we should not manage to get it working again >>>>> in Squeak 4.5alpha. >>>>> >>>>> And Pavel's approach may be followed in parallel. Because fixing one >>>>> thing will help the other and vice-verse. >>>>> >>>> >>>> +1 >>>> >>>> Exactly so. That is what I intended when I mentioned >>>> #unloadAllKnownPackages. >>>> Thanks for stating it so clearly. >>> >>> While we're being clear about what's clear :) I'm wanting to _lose_ >>> #unloadAllKnownPackages, and replace it with a >>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload, and add a >>> bunch of new jobs running those unloaded packages' test suites. >>> >>> That way, the thing called Squeak4.5-nnnn.image still contains what >>> Squeak4.5-${whatever_current_is}.image, only the essence of trunk - >>> what SqueakTrunk produces - shrinks. >>> >>>> Dave >>> >>> >> > > |
|
|
In reply to this post by Tobias Pape
On 2013-02-12, at 11:54 PM, Tobias Pape <[hidden email]> wrote:
> In the original deps, most of the Packages depending on Tests also directly depend on SUnit. Oh right, I forgot about that detail. So that graph really shows the dependencies that would *have* to be addressed to make packages unloadable. Thanks for doing this analysis. Colin |
re: Toward SqueakCore (including alternative plan)
|
|
In reply to this post by ccrraaiigg
Hello Craig
Thank you for your mail which gives a lot of useful detailed explanations. On 2/12/13, Craig Latta <[hidden email]> wrote: > > Hi Frank-- > >> Some of those circles we may never resolve. Craig Latta might have >> some insight here, because he had to deal with these issues in the >> creation of his micro-images. >> >> Craig? > > With the current technique[1], I don't have to deal with those > issues at all to make minimal object memories. I wrote a variant of the > garbage collector that collects methods not run since a certain point in > time. I reset a mark on all methods, run unit tests for the stuff I want > to keep, and everything else vanishes. It takes a few seconds. Is thei garbage collector available as a loadable package? > Before I started doing that, I was ripping things out manually with > a remote browser, so I didn't have to think about most of the > circularities (e.g., breaking the target's GUI was fine because I wasn't > using it). > > Generally, I advocate creating modules by imprinting[2] unit tests > onto a minimal memory. We can divide the work of rounding out the unit > tests using the current class categories, and prioritize by what we miss > most when using a minimal system. I expect we have lots of opinions > about that, so there should be plenty of volunteers. :) OK, fine. > I volunteer to coordinate this. I'll start by making an example of > a simple "echo" network server[3]. I'll provide a package for Squeak 4.4 > that installs imprinting support, and another that installs the echo > server code and an imprinting unit test. Good You imprint the unit test's > code onto a minimal memory, With 'minimal memory' I assume you mean a minimal image while it is in memory? >then get data echoed back to you from a > newly-created echo server running there. We can move onto more > interesting things, like graphics (or WebDAV, or...). With graphics you mean an image which executes graphics commands? Yes, what other candidates do you propose as a test? > I advocate a new all-live-objects module system as well[4], but the > organizational info gleaned from this work would lead to useful > artifacts with any of the other ones (e.g., Monticello). > > As for the DependencyBrowser data, I think it would be better to > express the connections directly between classes, and ignore the class > categories for now. (Actually, I'd like to drop the class categories > permanently, and use tags instead[5].) Class references are the basis of > the dependency graph, the categories are a distraction. Let's identify > the methods causing reference circularities between classes. Makes sense to me Regards --Hannes > > [1] http://tinyurl.com/bz3eyzq (thiscontext.wordpress.com) > [2] http://tinyurl.com/ajttt52 (thiscontext.wordpress.com) > [3] https://tools.ietf.org/html/rfc862 > [4] http://tinyurl.com/aoudtnq (thiscontext.wordpress.com) > [5] http://netjam.org/spoon/naiad (sorry, no pretty blog version yet) > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > |
|
|
In reply to this post by timrowledge
On Tue, Feb 12, 2013 at 11:02 AM, tim Rowledge <[hidden email]> wrote: I've never yet been convinced that *un*loading packages as a general technique is a good idea; unload them once to make the small core image and make the packages *load* nicely. Being able to unload seems likely to require tracking what was changed so you can restore it - and not just once but potentially many times with odd combinations for multi layers of loaded packages. I'm not sure it is practical to have a system that avoids any possibility of interactions but I'd certainly be happy to be wrong. In the absence of a full Spoon-like remote image development facility unloadable packages give one the ability to work on the core image with the full toolset. One works on the fiul image and then unloads to get the core. Without Spoon or unloadable packaes one can;t work on the core, one must construct it.
Smalltalk can do good tools.
best, Eliot
|
|
|
On 13-02-2013, at 10:27 AM, Eliot Miranda <[hidden email]> wrote: > > > On Tue, Feb 12, 2013 at 11:02 AM, tim Rowledge <[hidden email]> wrote: > I've never yet been convinced that *un*loading packages as a general technique is a good idea; unload them once to make the small core image and make the packages *load* nicely. Being able to unload seems likely to require tracking what was changed so you can restore it - and not just once but potentially many times with odd combinations for multi layers of loaded packages. I'm not sure it is practical to have a system that avoids any possibility of interactions but I'd certainly be happy to be wrong. > > In the absence of a full Spoon-like remote image development facility unloadable packages give one the ability to work on the core image with the full toolset. One works on the fiul image and then unloads to get the core. Without Spoon or unloadable packaes one can;t work on the core, one must construct it. > Fair point; I was pretty much assuming Spoon-feeding it and failed to be clear about that. > > My suspicion is that we will need some very good tools to help make, maintain, test and care for loadable packages. It's so easy for things to slide into cruftulescense. > > Smalltalk can do good tools. All we need to do is work out what the good tools are and find the time to implement them whilst not starving in the process. Haven't we been there before ;-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Bother" said Piglet, as Pooh smeared him in honey. |
|
|
In reply to this post by Eliot Miranda-2
Hoi Eliot-- > In the absence of a full Spoon-like remote image development facility > unloadable packages give one the ability to work on the core image > with the full toolset. Have you tried the remote browsers in the Spoon releases? They include a mainstream Squeak image with remote browsers and a fully-functioning interpreter simulator with the Spoon VM changes applied. http://netjam.org/spoon/releases/current > One works on the full image and then unloads to get the core. Without > Spoon or unloadable packaes one can't work on the core, one must > construct it. But... we have Spoon, yes? :) -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Re: Toward SqueakCore (including alternative plan)
|
|
In reply to this post by ccrraaiigg
On 13 February 2013 22:01, Craig Latta <[hidden email]> wrote:
> > Hi Frank-- > > Did you mean to send this to squeak-dev, too? It only came to me. Sorry, that was a slip of the finger, and then I misread headers and thought you'd only sent it to me. Double d'oh. >> > With the current technique[1], I don't have to deal with those >> > issues at all to make minimal object memories. I wrote a variant of >> > the garbage collector that collects methods not run since a certain >> > point in time. I reset a mark on all methods, run unit tests for >> > the stuff I want to keep, and everything else vanishes. It takes a >> > few seconds. >> >> Yep, it's a very neat GC hack. It does mean you _must_ have 100% code >> coverage or you risk imprinting a broken module. > > Well, imprinting has nothing to do with making a minimal memory. > There's nothing being transferred to another memory, only garbage being > collected from a single memory. In this process (which I call > "dissolving"), if there's no unit test coverage for something, it just > goes away. Any methods that you happen to run some other way (like all > the methods involved in the system just sitting there idling, > headlessly) get retained. Er yes, you're right. I have actually read most of the Spoon literature, even if it's not that obvious :/ Yes, I half and half have a problem with dissolving, just in the sense that if you don't use it it's gone, only that might be, say, UI wiring. >> > Before I started doing that, I was ripping things out manually with >> > a remote browser, so I didn't have to think about most of the >> > circularities (e.g., breaking the target's GUI was fine because I >> > wasn't using it). >> >> Ok, which means that you didn't really care too much about breaking >> cycles either because the resulting thing didn't worry about >> breaking, say, Morphic, or because the resulting module would _eat_ >> the cycle (all things in the cycle go in the module). > > Right, making a minimal system and finding module boundaries are > two very different problems. You don't need the second for the first. Right. >> I'm sure you're aware I have difficulties :) with the all-live- >> objects approach... > > Well, I've only noticed a lack of interest. I haven't read every > message ever sent to squeak-dev, though. While you're writing up your > current thoughts, are there existing messages I can read? I'm still mulling them over, and I don't want to say something ill-formed. But I am aware that it's not very fair of me to leave you hanging! "I'm sure you're aware I have difficulties" because we have discussed Spoon's tech before - last time was, IIRC, "how can you diff two arbitrary binary blobs?" >> > Class references are the basis of the dependency graph... >> >> Class references are where the Dependency Browser gets its info. > > Aren't we saying the same thing? :) > >> > ...the categories are a distraction. Let's identify the methods >> > causing reference circularities between classes. Yes, we are: I saw "categories" and wanted to make sure we were talking about the same thing. >> I largely agree re tags, except that right now PackageInfo is the >> closest we have to something like a module. So a class reference >> causes a dependency between two clusters of classes, say Network and >> Tools. > > If we have the raw class dependency data, why do we anything else? > And we may very well find that the groupings expressed by PackageInfo > (class category) stuff are wrong anyway... Well, because PackageInfo is what we have right now. But the counterargument, for what it's worth, is "then let's correct the PackageInfo data until they do make sense as modules". frank |
Re: Toward SqueakCore (including alternative plan)
|
|
Craig wrote: > If we have the raw class dependency data, why do we anything else? Frank replied: Well, because PackageInfo is what we have right now. But the counterargument, for what it's worth, is "then let's correct the The system is too big to look at all the class-level dependencies all at once. Even just looking at package dependencies, Tobias had to simplify the graph to be able to get meaningful insights. Of course, to actually break the dependencies, yeah, we'll have to go down to the level of classes and methods. But the high-level overview can help us sort out priorities.
Also, note that PackageInfo and class categories aren't the same thing. Packages can include extension methods on classes not in the package, and exclude extensions that belong to other packages. It's true that examining the system via class category doesn't make a lot of sense, but that's not what we're doing here.
Colin |
Re: Toward SqueakCore (including alternative plan)
|
|
On 14 February 2013 01:20, Colin Putney <[hidden email]> wrote:
> > > Craig wrote: > >> > If we have the raw class dependency data, why do we anything else? >> > And we may very well find that the groupings expressed by PackageInfo >> > (class category) stuff are wrong anyway... > > > Frank replied: > >> Well, because PackageInfo is what we have right now. But the >> >> counterargument, for what it's worth, is "then let's correct the >> PackageInfo data until they do make sense as modules". > > > The system is too big to look at all the class-level dependencies all at > once. Even just looking at package dependencies, Tobias had to simplify the > graph to be able to get meaningful insights. Of course, to actually break > the dependencies, yeah, we'll have to go down to the level of classes and > methods. But the high-level overview can help us sort out priorities. > > Also, note that PackageInfo and class categories aren't the same thing. > Packages can include extension methods on classes not in the package, and > exclude extensions that belong to other packages. It's true that examining > the system via class category doesn't make a lot of sense, but that's not > what we're doing here. I'm not suggesting that PackageInfo and class categories are the same thing although, having said that, unless you know a fair bit more about Squeak than just the UI that's not clear. frank > Colin > > > |
Re: Toward SqueakCore (including alternative plan)
|
|
On Wed, Feb 13, 2013 at 11:29 PM, Frank Shearar <[hidden email]> wrote:
Yup. I was concurring with your reply to Craig. His post contained several references to "PackageInfo (class category)" and since he doesn't use Monticello I suspect he might not be aware of the subtleties.
Colin |
|
|
In reply to this post by Hannes Hirzel
We also now have builds for XML-Parser, Nebraska and Universes (for
what it's worth: the code coverage is abysmal). frank On 13 February 2013 15:23, H. Hirzel <[hidden email]> wrote: > Yes, thank you for the clarification, Frank. This makes a lot of sense > to me and I hope that others follow this line of reasoning. > > --Hannes > > On 2/13/13, Frank Shearar <[hidden email]> wrote: >> On 13 February 2013 12:45, H. Hirzel <[hidden email]> wrote: >>> Frank >>> >>> If I understand you correctly you want to do the following >>> >>> 1) unload some once packages from trunk. The packages are taken from >>> what is in the list in #unloadAllKnownPackages. >>> >>> 2) add a trunk method >>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload >>> >>> 3) add CI build jobs which do >>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload and run tests >>> on the loaded packages. >>> >>> 4) People use the result of 3) for regular work. This is the "full" >>> 4.5 image as we have of now only that we have less in trunk and the >>> unlodable packages reside in their own repositories. >>> >>> Steps 2..4 are done repeatedly. >>> >>> Is this what you mean? >> >> Yes. Perhaps with a nicer name than >> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload. Maybe >> #loadBasicPackages or something. >> >> My main aim is to invert the approach we've had up until now, and >> _enforce_ the clean separation of these packages from the Core. I want >> it to be difficult to add a dependency from the Core to these >> packages. >> >> frank >> >>> --Hannes >>> >>> On 2/13/13, Frank Shearar <[hidden email]> wrote: >>>> On 13 February 2013 11:22, David T. Lewis <[hidden email]> wrote: >>>>> On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote: >>>>>> Yanni, >>>>>> >>>>>> I think St??phane refers to the original Pharo manifesto which clearly >>>>>> states "no backward compatibility". http://code.google.com/p/pharo/ >>>>>> >>>>>> However the current Pharo web page has a mission statement >>>>>> http://www.pharo-project.org/about >>>>>> sets a much more moderate tone. >>>>>> >>>>>> In any case in this thread we want to move on towards a Squeak core >>>>>> and learn from the Pharo experience as much as possible. Please let us >>>>>> not digress from this important topic. >>>>>> >>>>>> Maybe we should follow both at the same time >>>>>> >>>>>> Let me call it >>>>>> - the Pavel Krivanek approach and >>>>>> - the >>>>>> SmalltalkImage unloadAllKnownPackages >>>>>> approach >>>>>> >>>>>> BTW >>>>>> #unloadAllKnownPackages >>>>>> >>>>>> used to work in Squeak 4.1, see >>>>>> >>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.html >>>>>> >>>>>> So there is no reason why we should not manage to get it working again >>>>>> in Squeak 4.5alpha. >>>>>> >>>>>> And Pavel's approach may be followed in parallel. Because fixing one >>>>>> thing will help the other and vice-verse. >>>>>> >>>>> >>>>> +1 >>>>> >>>>> Exactly so. That is what I intended when I mentioned >>>>> #unloadAllKnownPackages. >>>>> Thanks for stating it so clearly. >>>> >>>> While we're being clear about what's clear :) I'm wanting to _lose_ >>>> #unloadAllKnownPackages, and replace it with a >>>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload, and add a >>>> bunch of new jobs running those unloaded packages' test suites. >>>> >>>> That way, the thing called Squeak4.5-nnnn.image still contains what >>>> Squeak4.5-${whatever_current_is}.image, only the essence of trunk - >>>> what SqueakTrunk produces - shrinks. >>>> >>>>> Dave >>>> >>>> >>> >> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |