Towards SqueakCore
Locked
123
123
 
|
Great
where can I see what the script is doing for example for XML-Parser? Which script does the job? http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ --Hannes On 2/14/13, Frank Shearar <[hidden email]> wrote: > 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 >>>>> >>>>> >>>> >>> >>> >> > > |
|
|
I.e. an updated README.md is very welcome :-)
On 2/14/13, H. Hirzel <[hidden email]> wrote: > Great > > where can I see what the script is doing for example for XML-Parser? > > Which script does the job? > > http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ > > --Hannes > > On 2/14/13, Frank Shearar <[hidden email]> wrote: >> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > |
|
|
In reply to this post by Hannes Hirzel
https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st
They all get triggered by this guy, who I aim to replace with some Ruby (because I'd really, really, REALLY rather write Ruby than shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh So the jobs only differ in their command: `./run-test.sh Control`, `./run-test.sh XML-Parser`, and so on. frank On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: > Great > > where can I see what the script is doing for example for XML-Parser? > > Which script does the job? > > http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ > > --Hannes > > On 2/14/13, Frank Shearar <[hidden email]> wrote: >> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > |
|
|
OK
https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh executes XML-Parser.st which contains Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'. HDTestReport runPackage: 'XML-Parser'. "Throw away the dirty image." WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: false andQuit: true ]. I assume this operates on a trunk image which has the XML-Parser removed? In which script does that happen? --Hannes On 2/14/13, Frank Shearar <[hidden email]> wrote: > https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st > > They all get triggered by this guy, who I aim to replace with some > Ruby (because I'd really, really, REALLY rather write Ruby than > shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh > > So the jobs only differ in their command: `./run-test.sh Control`, > `./run-test.sh XML-Parser`, and so on. > > frank > > On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: >> Great >> >> where can I see what the script is doing for example for XML-Parser? >> >> Which script does the job? >> >> http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ >> >> --Hannes >> >> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > |
|
|
No, this takes the Trunk image as is and runs the job. No stripping
has occurred. Noone's actually said "oh, that's a sane idea someone should do that" yet (except possibly for you, by virtue of not saying "are you crazy?" :) ), so I haven't done it yet. So the installation is essentially a no-op. With green lights on these builds, we can now verify that removing these packages won't break anything. At least, to the limit of the tests, which isn't much at all. So if we _do_ actually strip these guys out of Trunk, the builds should stay green. If they don't, we'll need to roll back the change and investigate. But I don't actually know how to strip them out of Trunk. I _suspect_ it'll be via a Monticello config map of some description. frank On 14 February 2013 16:44, H. Hirzel <[hidden email]> wrote: > OK > > https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh > > executes > XML-Parser.st > > which contains > > Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'. > > HDTestReport runPackage: 'XML-Parser'. > > "Throw away the dirty image." > WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: > false andQuit: true ]. > > > I assume this operates on a trunk image which has the XML-Parser removed? > > In which script does that happen? > > --Hannes > > On 2/14/13, Frank Shearar <[hidden email]> wrote: >> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st >> >> They all get triggered by this guy, who I aim to replace with some >> Ruby (because I'd really, really, REALLY rather write Ruby than >> shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >> >> So the jobs only differ in their command: `./run-test.sh Control`, >> `./run-test.sh XML-Parser`, and so on. >> >> frank >> >> On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: >>> Great >>> >>> where can I see what the script is doing for example for XML-Parser? >>> >>> Which script does the job? >>> >>> http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ >>> >>> --Hannes >>> >>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > |
re: Toward SqueakCore (including alternative plan)
|
|
In reply to this post by Colin Putney-3
Hi-- Hannes writes: > Thank you for your mail which gives a lot of useful detailed > explanations. Sure thing. > Is the garbage collector available as a loadable package? No, I haven't separated that from the rest of the Spoon VM changes, which are in the mainstream image included in recent Spoon releases. > > 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? I'm using "memory" as shorthand for "object memory". I avoid using the word "image" as much as I can, because it often confuses newcomers when I explain Smalltalk to them. They think it has something to do with graphics. It's especially problematic when I'm explaining my object memory visualization work, which is heavily graphical. I've had better results by evoking the model of a virtual processor with its own memory, especially now that many people are familiar with things like VMWare. > > [After a minimal imprinting unit test] we can move onto more > > interesting things, like graphics (or WebDAV, or...). > > With graphics you mean an [object memory] which executes graphics > commands? Sure, I mean the library support for a GUI. The minimal memory is headless. > Yes, what other candidates do you propose as a test? I think the minimal echo-server unit test is the only test we need, then we should get on to doing real work. We'll probably want some sort of user interface as a top priority, so I imagine support for a simplified Morphic, or MVC, or wxWidgets would be likely, as would remote text-editor access via WebDAV (and I've already written that code). Beyond that, as now, it's up to all us motivated people to decide the priorities and do the work. I think I would work on the VM simulator next, and I'd like to get all the vm-making stuff installing, generating, and executing this way. Frank writes: > 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. But that's fine if your goal is a minimal object memory, yes? > ...we have discussed Spoon's tech before - last time was, IIRC, "how > can you diff two arbitrary binary blobs?" Sorry, I don't recall the context. Can you point me to messages in the squeak-dev archives, or summarize with a bit more detail? Colin writes: > The system is too big to look at all the class-level dependencies all > at once. Okay, I think we disagree here. After my experience with interactively visualizing and exploring the entire reference graph of an object memory in 3D (even though it was a relatively small memory), I don't think the problem is too big. For those reading along who may not have seen my visualization work, please check out: http://tinyurl.com/aky2gwa (thiscontext.wordpress.com) > 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. That makes sense. > Also, note that PackageInfo and class categories aren't the same > thing. I know they aren't identical. My understanding was that PackageInfo has its basis in class categories, with some important elaborations. This understanding was reinforced when I saw Tobias's graphs full of familiar class category names. I hadn't looked at the implementation since it first came out, I'm reading it now. Regardless of the subtleties, I do use Monticello (although more to install things, VMMaker in particular :). thanks again, -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)
|
|
On 15 February 2013 10:52, Craig Latta <[hidden email]> wrote:
> > Hi-- > > Hannes writes: > >> Thank you for your mail which gives a lot of useful detailed >> explanations. > > Sure thing. > >> Is the garbage collector available as a loadable package? > > No, I haven't separated that from the rest of the Spoon VM changes, > which are in the mainstream image included in recent Spoon releases. > >> > 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? > > I'm using "memory" as shorthand for "object memory". I avoid using > the word "image" as much as I can, because it often confuses newcomers > when I explain Smalltalk to them. They think it has something to do with > graphics. It's especially problematic when I'm explaining my object > memory visualization work, which is heavily graphical. > > I've had better results by evoking the model of a virtual processor > with its own memory, especially now that many people are familiar with > things like VMWare. > >> > [After a minimal imprinting unit test] we can move onto more >> > interesting things, like graphics (or WebDAV, or...). >> >> With graphics you mean an [object memory] which executes graphics >> commands? > > Sure, I mean the library support for a GUI. The minimal memory is > headless. > >> Yes, what other candidates do you propose as a test? > > I think the minimal echo-server unit test is the only test we need, > then we should get on to doing real work. We'll probably want some sort > of user interface as a top priority, so I imagine support for a > simplified Morphic, or MVC, or wxWidgets would be likely, as would > remote text-editor access via WebDAV (and I've already written that code). > > Beyond that, as now, it's up to all us motivated people to decide > the priorities and do the work. I think I would work on the VM simulator > next, and I'd like to get all the vm-making stuff installing, > generating, and executing this way. > > > Frank writes: > >> 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. > > But that's fine if your goal is a minimal object memory, yes? > >> ...we have discussed Spoon's tech before - last time was, IIRC, "how >> can you diff two arbitrary binary blobs?" > > Sorry, I don't recall the context. Can you point me to messages in > the squeak-dev archives, or summarize with a bit more detail? This is in the middle of the thread: http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-February/163033.html It's a conversation that I paused, because I wanted to mull over Spoon (and then of course I got distracted by other stuff). I'll reread the Spoon docs and see what happens in my hindbrain. frank > Colin writes: > >> The system is too big to look at all the class-level dependencies all >> at once. > > Okay, I think we disagree here. After my experience with > interactively visualizing and exploring the entire reference graph of an > object memory in 3D (even though it was a relatively small memory), I > don't think the problem is too big. For those reading along who may not > have seen my visualization work, please check out: > > http://tinyurl.com/aky2gwa (thiscontext.wordpress.com) > >> 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. > > That makes sense. > >> Also, note that PackageInfo and class categories aren't the same >> thing. > > I know they aren't identical. My understanding was that PackageInfo > has its basis in class categories, with some important elaborations. > This understanding was reinforced when I saw Tobias's graphs full of > familiar class category names. I hadn't looked at the implementation > since it first came out, I'm reading it now. > > Regardless of the subtleties, I do use Monticello (although more to > install things, VMMaker in particular :). > > > thanks again, > > -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 Frank Shearar-3
On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote:
> No, this takes the Trunk image as is and runs the job. No stripping > has occurred. Noone's actually said "oh, that's a sane idea someone > should do that" yet (except possibly for you, by virtue of not saying > "are you crazy?" :) ), so I haven't done it yet. > > So the installation is essentially a no-op. > > With green lights on these builds, we can now verify that removing > these packages won't break anything. At least, to the limit of the > tests, which isn't much at all. So if we _do_ actually strip these > guys out of Trunk, the builds should stay green. If they don't, we'll > need to roll back the change and investigate. > > But I don't actually know how to strip them out of Trunk. I _suspect_ > it'll be via a Monticello config map of some description. Anyone? Bert? How do we strip packages out of Trunk? > frank > > On 14 February 2013 16:44, H. Hirzel <[hidden email]> wrote: >> OK >> >> https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >> >> executes >> XML-Parser.st >> >> which contains >> >> Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'. >> >> HDTestReport runPackage: 'XML-Parser'. >> >> "Throw away the dirty image." >> WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: >> false andQuit: true ]. >> >> >> I assume this operates on a trunk image which has the XML-Parser removed? >> >> In which script does that happen? >> >> --Hannes >> >> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st >>> >>> They all get triggered by this guy, who I aim to replace with some >>> Ruby (because I'd really, really, REALLY rather write Ruby than >>> shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >>> >>> So the jobs only differ in their command: `./run-test.sh Control`, >>> `./run-test.sh XML-Parser`, and so on. >>> >>> frank >>> >>> On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: >>>> Great >>>> >>>> where can I see what the script is doing for example for XML-Parser? >>>> >>>> Which script does the job? >>>> >>>> http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ >>>> >>>> --Hannes >>>> >>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> |
|
|
On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: > On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: >> No, this takes the Trunk image as is and runs the job. No stripping >> has occurred. Noone's actually said "oh, that's a sane idea someone >> should do that" yet (except possibly for you, by virtue of not saying >> "are you crazy?" :) ), so I haven't done it yet. >> >> So the installation is essentially a no-op. >> >> With green lights on these builds, we can now verify that removing >> these packages won't break anything. At least, to the limit of the >> tests, which isn't much at all. So if we _do_ actually strip these >> guys out of Trunk, the builds should stay green. If they don't, we'll >> need to roll back the change and investigate. >> >> But I don't actually know how to strip them out of Trunk. I _suspect_ >> it'll be via a Monticello config map of some description. > > Anyone? Bert? How do we strip packages out of Trunk? Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. - Bert - >> frank >> >> On 14 February 2013 16:44, H. Hirzel <[hidden email]> wrote: >>> OK >>> >>> https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >>> >>> executes >>> XML-Parser.st >>> >>> which contains >>> >>> Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'. >>> >>> HDTestReport runPackage: 'XML-Parser'. >>> >>> "Throw away the dirty image." >>> WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: >>> false andQuit: true ]. >>> >>> >>> I assume this operates on a trunk image which has the XML-Parser removed? >>> >>> In which script does that happen? >>> >>> --Hannes >>> >>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>>> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st >>>> >>>> They all get triggered by this guy, who I aim to replace with some >>>> Ruby (because I'd really, really, REALLY rather write Ruby than >>>> shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >>>> >>>> So the jobs only differ in their command: `./run-test.sh Control`, >>>> `./run-test.sh XML-Parser`, and so on. >>>> >>>> frank >>>> >>>> On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: >>>>> Great >>>>> >>>>> where can I see what the script is doing for example for XML-Parser? >>>>> >>>>> Which script does the job? >>>>> >>>>> http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ >>>>> >>>>> --Hannes >>>>> >>>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> |
|
|
On 25 February 2013 14:49, Bert Freudenberg <[hidden email]> wrote:
> > On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: > >> On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: >>> No, this takes the Trunk image as is and runs the job. No stripping >>> has occurred. Noone's actually said "oh, that's a sane idea someone >>> should do that" yet (except possibly for you, by virtue of not saying >>> "are you crazy?" :) ), so I haven't done it yet. >>> >>> So the installation is essentially a no-op. >>> >>> With green lights on these builds, we can now verify that removing >>> these packages won't break anything. At least, to the limit of the >>> tests, which isn't much at all. So if we _do_ actually strip these >>> guys out of Trunk, the builds should stay green. If they don't, we'll >>> need to roll back the change and investigate. >>> >>> But I don't actually know how to strip them out of Trunk. I _suspect_ >>> it'll be via a Monticello config map of some description. >> >> Anyone? Bert? How do we strip packages out of Trunk? > > Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. Given that we're early in 4.5's release cycle, if we do this kind of thing - stripping unnecessary things out of trunk - we ought to do it now rather than later. And announce loudly what we're doing, why, and how people can load in their favourite not-Core packages. We have CI tests for the packages (well, the packages I chose as the first victims) showing that they can be loaded into a Trunk image, and while the test coverage is dismal, that just means we don't know whether they work while in Trunk. I'm _not_ about to go and start unloading packages without significant buy-in, but I really do think we ought to actually start working towards a lean, minimal, modular core. That will, of necessity, cause disruption to people updating from trunk. The ReleaseBuilder script or CI job can re-add these packages so that people downloading an image see no change. frank > - Bert - >>> frank >>> >>> On 14 February 2013 16:44, H. Hirzel <[hidden email]> wrote: >>>> OK >>>> >>>> https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >>>> >>>> executes >>>> XML-Parser.st >>>> >>>> which contains >>>> >>>> Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'. >>>> >>>> HDTestReport runPackage: 'XML-Parser'. >>>> >>>> "Throw away the dirty image." >>>> WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: >>>> false andQuit: true ]. >>>> >>>> >>>> I assume this operates on a trunk image which has the XML-Parser removed? >>>> >>>> In which script does that happen? >>>> >>>> --Hannes >>>> >>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>>>> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st >>>>> >>>>> They all get triggered by this guy, who I aim to replace with some >>>>> Ruby (because I'd really, really, REALLY rather write Ruby than >>>>> shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >>>>> >>>>> So the jobs only differ in their command: `./run-test.sh Control`, >>>>> `./run-test.sh XML-Parser`, and so on. >>>>> >>>>> frank >>>>> >>>>> On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: >>>>>> Great >>>>>> >>>>>> where can I see what the script is doing for example for XML-Parser? >>>>>> >>>>>> Which script does the job? >>>>>> >>>>>> http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ >>>>>> >>>>>> --Hannes >>>>>> >>>>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> > > |
|
|
On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote:
> On 25 February 2013 14:49, Bert Freudenberg <[hidden email]> wrote: > > > > On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: > > > >> On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: > >>> No, this takes the Trunk image as is and runs the job. No stripping > >>> has occurred. Noone's actually said "oh, that's a sane idea someone > >>> should do that" yet (except possibly for you, by virtue of not saying > >>> "are you crazy?" :) ), so I haven't done it yet. > >>> > >>> So the installation is essentially a no-op. > >>> > >>> With green lights on these builds, we can now verify that removing > >>> these packages won't break anything. At least, to the limit of the > >>> tests, which isn't much at all. So if we _do_ actually strip these > >>> guys out of Trunk, the builds should stay green. If they don't, we'll > >>> need to roll back the change and investigate. > >>> > >>> But I don't actually know how to strip them out of Trunk. I _suspect_ > >>> it'll be via a Monticello config map of some description. > >> > >> Anyone? Bert? How do we strip packages out of Trunk? > > > > Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. > > Given that we're early in 4.5's release cycle, if we do this kind of > thing - stripping unnecessary things out of trunk - we ought to do it > now rather than later. And announce loudly what we're doing, why, and > how people can load in their favourite not-Core packages. NO. If Squeak developers work with images that contain just "their favourite non-Core packages" then none of the non-Core packages get maintained. It is important to work on making packages loadable and unloadable, but you do not need to break the trunk image in order to accomplish this. Also, please recognize that not everybody wants to do all their work in a clean image built by a robot. I for example do most of my work in a Squeak3.11alpha image that has been continuously updated from the update stream for quite a while. I also periodically check things against a fresh 4.4 image, but my usual pattern is to use one image over a long period of time with the trunk update stream, and most of my updates to trunk come from that old image. Dave > > We have CI tests for the packages (well, the packages I chose as the > first victims) showing that they can be loaded into a Trunk image, and > while the test coverage is dismal, that just means we don't know > whether they work while in Trunk. > > I'm _not_ about to go and start unloading packages without significant > buy-in, but I really do think we ought to actually start working > towards a lean, minimal, modular core. That will, of necessity, cause > disruption to people updating from trunk. The ReleaseBuilder script or > CI job can re-add these packages so that people downloading an image > see no change. > > frank > > > - Bert - > >>> frank > >>> > >>> On 14 February 2013 16:44, H. Hirzel <[hidden email]> wrote: > >>>> OK > >>>> > >>>> https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh > >>>> > >>>> executes > >>>> XML-Parser.st > >>>> > >>>> which contains > >>>> > >>>> Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'. > >>>> > >>>> HDTestReport runPackage: 'XML-Parser'. > >>>> > >>>> "Throw away the dirty image." > >>>> WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: > >>>> false andQuit: true ]. > >>>> > >>>> > >>>> I assume this operates on a trunk image which has the XML-Parser removed? > >>>> > >>>> In which script does that happen? > >>>> > >>>> --Hannes > >>>> > >>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: > >>>>> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st > >>>>> > >>>>> They all get triggered by this guy, who I aim to replace with some > >>>>> Ruby (because I'd really, really, REALLY rather write Ruby than > >>>>> shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh > >>>>> > >>>>> So the jobs only differ in their command: `./run-test.sh Control`, > >>>>> `./run-test.sh XML-Parser`, and so on. > >>>>> > >>>>> frank > >>>>> > >>>>> On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: > >>>>>> Great > >>>>>> > >>>>>> where can I see what the script is doing for example for XML-Parser? > >>>>>> > >>>>>> Which script does the job? > >>>>>> > >>>>>> http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ > >>>>>> > >>>>>> --Hannes > >>>>>> > >>>>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: > >>>>>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > > > > |
|
|
On 25 February 2013 15:35, David T. Lewis <[hidden email]> wrote:
> On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote: >> On 25 February 2013 14:49, Bert Freudenberg <[hidden email]> wrote: >> > >> > On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: >> > >> >> On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: >> >>> No, this takes the Trunk image as is and runs the job. No stripping >> >>> has occurred. Noone's actually said "oh, that's a sane idea someone >> >>> should do that" yet (except possibly for you, by virtue of not saying >> >>> "are you crazy?" :) ), so I haven't done it yet. >> >>> >> >>> So the installation is essentially a no-op. >> >>> >> >>> With green lights on these builds, we can now verify that removing >> >>> these packages won't break anything. At least, to the limit of the >> >>> tests, which isn't much at all. So if we _do_ actually strip these >> >>> guys out of Trunk, the builds should stay green. If they don't, we'll >> >>> need to roll back the change and investigate. >> >>> >> >>> But I don't actually know how to strip them out of Trunk. I _suspect_ >> >>> it'll be via a Monticello config map of some description. >> >> >> >> Anyone? Bert? How do we strip packages out of Trunk? >> > >> > Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. >> >> Given that we're early in 4.5's release cycle, if we do this kind of >> thing - stripping unnecessary things out of trunk - we ought to do it >> now rather than later. And announce loudly what we're doing, why, and >> how people can load in their favourite not-Core packages. > > NO. > > If Squeak developers work with images that contain just "their favourite > non-Core packages" then none of the non-Core packages get maintained. Clearly we disagree quite a bit on this, but I don't think anyone should actually _work_ on a Core image. _Noone_ should be able to work effectively in a minimal image because such a thing wouldn't even have a Browser! > It is important to work on making packages loadable and unloadable, but > you do not need to break the trunk image in order to accomplish this. Who's breaking trunk? I want to remove packages that are already unloadable, and have CI jobs that run every time Trunk updates that verifies that the packages can (a) reload and (b) run as well as we already know now (which is not very). To be precise: Universes (for example) might be smashed beyond recognition, and there is no way to know, because it has something like 23% method coverage. Removing these packages from Trunk _will_ affect people updating from Trunk, I agree. How else do we make Trunk simpler, if not by removing stuff? (It's also simple enough to reinstall your favourite packages: Installer squeakmap update; install: 'WhateverItIs (someVersion)'.) > Also, please recognize that not everybody wants to do all their work in > a clean image built by a robot. I for example do most of my work in a > Squeak3.11alpha image that has been continuously updated from the update > stream for quite a while. I also periodically check things against a > fresh 4.4 image, but my usual pattern is to use one image over a long > period of time with the trunk update stream, and most of my updates to > trunk come from that old image. OK, but then we can't have a minimal core without an entire reboot. I mean, seriously, making a minimal core by unloading packages is an order of magnitude harder when you cannot ever actually unload the packages! So, given the resistance to my slow, gradual unwinding of the tangle, what's your counterproposal? frank > Dave > > >> >> We have CI tests for the packages (well, the packages I chose as the >> first victims) showing that they can be loaded into a Trunk image, and >> while the test coverage is dismal, that just means we don't know >> whether they work while in Trunk. >> >> I'm _not_ about to go and start unloading packages without significant >> buy-in, but I really do think we ought to actually start working >> towards a lean, minimal, modular core. That will, of necessity, cause >> disruption to people updating from trunk. The ReleaseBuilder script or >> CI job can re-add these packages so that people downloading an image >> see no change. >> >> frank >> >> > - Bert - >> >>> frank >> >>> >> >>> On 14 February 2013 16:44, H. Hirzel <[hidden email]> wrote: >> >>>> OK >> >>>> >> >>>> https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >> >>>> >> >>>> executes >> >>>> XML-Parser.st >> >>>> >> >>>> which contains >> >>>> >> >>>> Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'. >> >>>> >> >>>> HDTestReport runPackage: 'XML-Parser'. >> >>>> >> >>>> "Throw away the dirty image." >> >>>> WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: >> >>>> false andQuit: true ]. >> >>>> >> >>>> >> >>>> I assume this operates on a trunk image which has the XML-Parser removed? >> >>>> >> >>>> In which script does that happen? >> >>>> >> >>>> --Hannes >> >>>> >> >>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >> >>>>> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st >> >>>>> >> >>>>> They all get triggered by this guy, who I aim to replace with some >> >>>>> Ruby (because I'd really, really, REALLY rather write Ruby than >> >>>>> shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh >> >>>>> >> >>>>> So the jobs only differ in their command: `./run-test.sh Control`, >> >>>>> `./run-test.sh XML-Parser`, and so on. >> >>>>> >> >>>>> frank >> >>>>> >> >>>>> On 14 February 2013 16:34, H. Hirzel <[hidden email]> wrote: >> >>>>>> Great >> >>>>>> >> >>>>>> where can I see what the script is doing for example for XML-Parser? >> >>>>>> >> >>>>>> Which script does the job? >> >>>>>> >> >>>>>> http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/ >> >>>>>> >> >>>>>> --Hannes >> >>>>>> >> >>>>>> On 2/14/13, Frank Shearar <[hidden email]> wrote: >> >>>>>>> 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 >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> > >> > > |
|
|
On 2013-02-25, at 17:07, Frank Shearar <[hidden email]> wrote:
> On 25 February 2013 15:35, David T. Lewis <[hidden email]> wrote: >> On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote: >>> On 25 February 2013 14:49, Bert Freudenberg <[hidden email]> wrote: >>>> >>>> On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: >>>> >>>>> On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: >>>>>> No, this takes the Trunk image as is and runs the job. No stripping >>>>>> has occurred. Noone's actually said "oh, that's a sane idea someone >>>>>> should do that" yet (except possibly for you, by virtue of not saying >>>>>> "are you crazy?" :) ), so I haven't done it yet. >>>>>> >>>>>> So the installation is essentially a no-op. >>>>>> >>>>>> With green lights on these builds, we can now verify that removing >>>>>> these packages won't break anything. At least, to the limit of the >>>>>> tests, which isn't much at all. So if we _do_ actually strip these >>>>>> guys out of Trunk, the builds should stay green. If they don't, we'll >>>>>> need to roll back the change and investigate. >>>>>> >>>>>> But I don't actually know how to strip them out of Trunk. I _suspect_ >>>>>> it'll be via a Monticello config map of some description. >>>>> >>>>> Anyone? Bert? How do we strip packages out of Trunk? >>>> >>>> Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. >>> >>> Given that we're early in 4.5's release cycle, if we do this kind of >>> thing - stripping unnecessary things out of trunk - we ought to do it >>> now rather than later. And announce loudly what we're doing, why, and >>> how people can load in their favourite not-Core packages. >> >> NO. >> >> If Squeak developers work with images that contain just "their favourite >> non-Core packages" then none of the non-Core packages get maintained. > > Clearly we disagree quite a bit on this, but I don't think anyone > should actually _work_ on a Core image. _Noone_ should be able to work > effectively in a minimal image because such a thing wouldn't even have > a Browser! We don't disagree on this at all. People should be working in a full image. >> It is important to work on making packages loadable and unloadable, but >> you do not need to break the trunk image in order to accomplish this. > > Who's breaking trunk? I want to remove packages that are already > unloadable, Yes, but not from *user's* images, from the *core* image that is only used by the CI to build a full image. > and have CI jobs that run every time Trunk updates that > verifies that the packages can (a) reload and (b) run as well as we > already know now (which is not very). To be precise: Universes (for > example) might be smashed beyond recognition, and there is no way to > know, because it has something like 23% method coverage. Right. > Removing these packages from Trunk _will_ affect people updating from > Trunk, I agree. How else do we make Trunk simpler, if not by removing > stuff? I think we may be talking past each other. There are two types of packages we want to "remove from trunk": full = core packages + unloadable packages + deprecated packages So there are unloadable packages which should still exist in a full image that everyone is using. And there are deprecated packages which should not exist in a full image. Both core packages and unloadable packages are in Trunk. The only packages that we actually want to remove for good are the deprecated ones. The mechanics of unloading a deprecated package is by committing an empty version (which will remove all the classes and methods from user's images when updating), and eventually removing the now empty package from the update map (and bumping the squeak-version package to keep update numbers continuous). Maybe that's what you were asking about? > (It's also simple enough to reinstall your favourite packages: > Installer squeakmap update; install: 'WhateverItIs (someVersion)'.) Sure, that's how you would re-install a deprecated package. >> Also, please recognize that not everybody wants to do all their work in >> a clean image built by a robot. I for example do most of my work in a >> Squeak3.11alpha image that has been continuously updated from the update >> stream for quite a while. I also periodically check things against a >> fresh 4.4 image, but my usual pattern is to use one image over a long >> period of time with the trunk update stream, and most of my updates to >> trunk come from that old image. > > OK, but then we can't have a minimal core without an entire reboot. I > mean, seriously, making a minimal core by unloading packages is an > order of magnitude harder when you cannot ever actually unload the > packages! > > So, given the resistance to my slow, gradual unwinding of the tangle, > what's your counterproposal? > > frank I still fail to see the problem. For purposes of the build server, you once make a Core image by unloading all possible packages. This becomes the new "master image" from which all subsequent releases are built. Then you use that as the base to run tests, build full images, etc. Does that sound reasonable? - Bert - |
|
|
On Mon, Feb 25, 2013 at 05:37:38PM +0100, Bert Freudenberg wrote:
> > I still fail to see the problem. For purposes of the build server, you once make a Core image by unloading all possible packages. This becomes the new "master image" from which all subsequent releases are built. Then you use that as the base to run tests, build full images, etc. > > Does that sound reasonable? > Yes. This provides a mechanism for creating and maintaining a core image, and for verifying on an ongoing basis that the full image built from core matches a full image that is tracking the trunk update stream. At image release time, two should be essentially the same. Meanwhile the full trunk image remains in the update stream so that all developers can see the impact of their changes on all packages. Dave |
|
|
In reply to this post by Bert Freudenberg
On 25 February 2013 16:37, Bert Freudenberg <[hidden email]> wrote:
> On 2013-02-25, at 17:07, Frank Shearar <[hidden email]> wrote: > >> On 25 February 2013 15:35, David T. Lewis <[hidden email]> wrote: >>> On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote: >>>> On 25 February 2013 14:49, Bert Freudenberg <[hidden email]> wrote: >>>>> >>>>> On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: >>>>> >>>>>> On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: >>>>>>> No, this takes the Trunk image as is and runs the job. No stripping >>>>>>> has occurred. Noone's actually said "oh, that's a sane idea someone >>>>>>> should do that" yet (except possibly for you, by virtue of not saying >>>>>>> "are you crazy?" :) ), so I haven't done it yet. >>>>>>> >>>>>>> So the installation is essentially a no-op. >>>>>>> >>>>>>> With green lights on these builds, we can now verify that removing >>>>>>> these packages won't break anything. At least, to the limit of the >>>>>>> tests, which isn't much at all. So if we _do_ actually strip these >>>>>>> guys out of Trunk, the builds should stay green. If they don't, we'll >>>>>>> need to roll back the change and investigate. >>>>>>> >>>>>>> But I don't actually know how to strip them out of Trunk. I _suspect_ >>>>>>> it'll be via a Monticello config map of some description. >>>>>> >>>>>> Anyone? Bert? How do we strip packages out of Trunk? >>>>> >>>>> Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. >>>> >>>> Given that we're early in 4.5's release cycle, if we do this kind of >>>> thing - stripping unnecessary things out of trunk - we ought to do it >>>> now rather than later. And announce loudly what we're doing, why, and >>>> how people can load in their favourite not-Core packages. >>> >>> NO. >>> >>> If Squeak developers work with images that contain just "their favourite >>> non-Core packages" then none of the non-Core packages get maintained. >> >> Clearly we disagree quite a bit on this, but I don't think anyone >> should actually _work_ on a Core image. _Noone_ should be able to work >> effectively in a minimal image because such a thing wouldn't even have >> a Browser! > > We don't disagree on this at all. People should be working in a full image. OK, cool. Finding out points of agreement helps in finding out where we disagree :) >>> It is important to work on making packages loadable and unloadable, but >>> you do not need to break the trunk image in order to accomplish this. >> >> Who's breaking trunk? I want to remove packages that are already >> unloadable, > > Yes, but not from *user's* images, from the *core* image that is only used by the CI to build a full image. > >> and have CI jobs that run every time Trunk updates that >> verifies that the packages can (a) reload and (b) run as well as we >> already know now (which is not very). To be precise: Universes (for >> example) might be smashed beyond recognition, and there is no way to >> know, because it has something like 23% method coverage. > > Right. > >> Removing these packages from Trunk _will_ affect people updating from >> Trunk, I agree. How else do we make Trunk simpler, if not by removing >> stuff? > > I think we may be talking past each other. There are two types of packages we want to "remove from trunk": > > full = core packages + unloadable packages + deprecated packages > > So there are unloadable packages which should still exist in a full image that everyone is using. And there are deprecated packages which should not exist in a full image. > > Both core packages and unloadable packages are in Trunk. The only packages that we actually want to remove for good are the deprecated ones. The mechanics of unloading a deprecated package is by committing an empty version (which will remove all the classes and methods from user's images when updating), and eventually removing the now empty package from the update map (and bumping the squeak-version package to keep update numbers continuous). > > Maybe that's what you were asking about? > >> (It's also simple enough to reinstall your favourite packages: >> Installer squeakmap update; install: 'WhateverItIs (someVersion)'.) > > Sure, that's how you would re-install a deprecated package. > >>> Also, please recognize that not everybody wants to do all their work in >>> a clean image built by a robot. I for example do most of my work in a >>> Squeak3.11alpha image that has been continuously updated from the update >>> stream for quite a while. I also periodically check things against a >>> fresh 4.4 image, but my usual pattern is to use one image over a long >>> period of time with the trunk update stream, and most of my updates to >>> trunk come from that old image. >> >> OK, but then we can't have a minimal core without an entire reboot. I >> mean, seriously, making a minimal core by unloading packages is an >> order of magnitude harder when you cannot ever actually unload the >> packages! >> >> So, given the resistance to my slow, gradual unwinding of the tangle, >> what's your counterproposal? >> >> frank > > > I still fail to see the problem. For purposes of the build server, you once make a Core image by unloading all possible packages. This becomes the new "master image" from which all subsequent releases are built. Then you use that as the base to run tests, build full images, etc. > > Does that sound reasonable? Ah! OK, right. So, to see if I understand correctly: * We _don't_ issue an empty version for the packages we're interested in unloading. (Just for argument's sake, I'll talk about Universes.) * If at some point in the future we decide to deprecate Universes, _then_ we commit the empty version, and update the map. That decision may be deferred for an arbitrary period after unloading it from Core. * We take a clean Trunk image from CI, unload all unloadable packages, and store that as our new master 4.5 image. (This will likely be a manual step, and the clean image committed to the squeak-ci script repository.) * The stripped master remains stripped, and the existing SqueakTrunk job publishes updated copies of the core image as per normal. * We adjust the ReleaseSqueakTrunk CI job to, via ReleaseBuilderForSqueak4dot5, loads the unloadable packages from SqueakTrunk's output to create a "full fat" version. Dave, sound good? frank > - Bert - > > |
|
|
On Mon, Feb 25, 2013 at 04:57:54PM +0000, Frank Shearar wrote:
> On 25 February 2013 16:37, Bert Freudenberg <[hidden email]> wrote: > > On 2013-02-25, at 17:07, Frank Shearar <[hidden email]> wrote: > > > >> On 25 February 2013 15:35, David T. Lewis <[hidden email]> wrote: > >>> On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote: > >>>> On 25 February 2013 14:49, Bert Freudenberg <[hidden email]> wrote: > >>>>> > >>>>> On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: > >>>>> > >>>>>> On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: > >>>>>>> No, this takes the Trunk image as is and runs the job. No stripping > >>>>>>> has occurred. Noone's actually said "oh, that's a sane idea someone > >>>>>>> should do that" yet (except possibly for you, by virtue of not saying > >>>>>>> "are you crazy?" :) ), so I haven't done it yet. > >>>>>>> > >>>>>>> So the installation is essentially a no-op. > >>>>>>> > >>>>>>> With green lights on these builds, we can now verify that removing > >>>>>>> these packages won't break anything. At least, to the limit of the > >>>>>>> tests, which isn't much at all. So if we _do_ actually strip these > >>>>>>> guys out of Trunk, the builds should stay green. If they don't, we'll > >>>>>>> need to roll back the change and investigate. > >>>>>>> > >>>>>>> But I don't actually know how to strip them out of Trunk. I _suspect_ > >>>>>>> it'll be via a Monticello config map of some description. > >>>>>> > >>>>>> Anyone? Bert? How do we strip packages out of Trunk? > >>>>> > >>>>> Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. > >>>> > >>>> Given that we're early in 4.5's release cycle, if we do this kind of > >>>> thing - stripping unnecessary things out of trunk - we ought to do it > >>>> now rather than later. And announce loudly what we're doing, why, and > >>>> how people can load in their favourite not-Core packages. > >>> > >>> NO. > >>> > >>> If Squeak developers work with images that contain just "their favourite > >>> non-Core packages" then none of the non-Core packages get maintained. > >> > >> Clearly we disagree quite a bit on this, but I don't think anyone > >> should actually _work_ on a Core image. _Noone_ should be able to work > >> effectively in a minimal image because such a thing wouldn't even have > >> a Browser! > > > > We don't disagree on this at all. People should be working in a full image. > > OK, cool. Finding out points of agreement helps in finding out where > we disagree :) > > >>> It is important to work on making packages loadable and unloadable, but > >>> you do not need to break the trunk image in order to accomplish this. > >> > >> Who's breaking trunk? I want to remove packages that are already > >> unloadable, > > > > Yes, but not from *user's* images, from the *core* image that is only used by the CI to build a full image. > > > >> and have CI jobs that run every time Trunk updates that > >> verifies that the packages can (a) reload and (b) run as well as we > >> already know now (which is not very). To be precise: Universes (for > >> example) might be smashed beyond recognition, and there is no way to > >> know, because it has something like 23% method coverage. > > > > Right. > > > >> Removing these packages from Trunk _will_ affect people updating from > >> Trunk, I agree. How else do we make Trunk simpler, if not by removing > >> stuff? > > > > I think we may be talking past each other. There are two types of packages we want to "remove from trunk": > > > > full = core packages + unloadable packages + deprecated packages > > > > So there are unloadable packages which should still exist in a full image that everyone is using. And there are deprecated packages which should not exist in a full image. > > > > Both core packages and unloadable packages are in Trunk. The only packages that we actually want to remove for good are the deprecated ones. The mechanics of unloading a deprecated package is by committing an empty version (which will remove all the classes and methods from user's images when updating), and eventually removing the now empty package from the update map (and bumping the squeak-version package to keep update numbers continuous). > > > > Maybe that's what you were asking about? > > > >> (It's also simple enough to reinstall your favourite packages: > >> Installer squeakmap update; install: 'WhateverItIs (someVersion)'.) > > > > Sure, that's how you would re-install a deprecated package. > > > >>> Also, please recognize that not everybody wants to do all their work in > >>> a clean image built by a robot. I for example do most of my work in a > >>> Squeak3.11alpha image that has been continuously updated from the update > >>> stream for quite a while. I also periodically check things against a > >>> fresh 4.4 image, but my usual pattern is to use one image over a long > >>> period of time with the trunk update stream, and most of my updates to > >>> trunk come from that old image. > >> > >> OK, but then we can't have a minimal core without an entire reboot. I > >> mean, seriously, making a minimal core by unloading packages is an > >> order of magnitude harder when you cannot ever actually unload the > >> packages! > >> > >> So, given the resistance to my slow, gradual unwinding of the tangle, > >> what's your counterproposal? > >> > >> frank > > > > > > I still fail to see the problem. For purposes of the build server, you once make a Core image by unloading all possible packages. This becomes the new "master image" from which all subsequent releases are built. Then you use that as the base to run tests, build full images, etc. > > > > Does that sound reasonable? > > Ah! OK, right. So, to see if I understand correctly: > * We _don't_ issue an empty version for the packages we're interested > in unloading. (Just for argument's sake, I'll talk about Universes.) > * If at some point in the future we decide to deprecate Universes, > _then_ we commit the empty version, and update the map. That decision > may be deferred for an arbitrary period after unloading it from Core. > * We take a clean Trunk image from CI, unload all unloadable packages, > and store that as our new master 4.5 image. (This will likely be a > manual step, and the clean image committed to the squeak-ci script > repository.) > * The stripped master remains stripped, and the existing SqueakTrunk > job publishes updated copies of the core image as per normal. > * We adjust the ReleaseSqueakTrunk CI job to, via > ReleaseBuilderForSqueak4dot5, loads the unloadable packages from > SqueakTrunk's output to create a "full fat" version. > > Dave, sound good? > Yes :) Dave > frank > > > - Bert - > > > > |
|
|
On 25 February 2013 18:51, David T. Lewis <[hidden email]> wrote:
> On Mon, Feb 25, 2013 at 04:57:54PM +0000, Frank Shearar wrote: >> On 25 February 2013 16:37, Bert Freudenberg <[hidden email]> wrote: >> > On 2013-02-25, at 17:07, Frank Shearar <[hidden email]> wrote: >> > >> >> On 25 February 2013 15:35, David T. Lewis <[hidden email]> wrote: >> >>> On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote: >> >>>> On 25 February 2013 14:49, Bert Freudenberg <[hidden email]> wrote: >> >>>>> >> >>>>> On 2013-02-25, at 15:33, Frank Shearar <[hidden email]> wrote: >> >>>>> >> >>>>>> On 14 February 2013 16:50, Frank Shearar <[hidden email]> wrote: >> >>>>>>> No, this takes the Trunk image as is and runs the job. No stripping >> >>>>>>> has occurred. Noone's actually said "oh, that's a sane idea someone >> >>>>>>> should do that" yet (except possibly for you, by virtue of not saying >> >>>>>>> "are you crazy?" :) ), so I haven't done it yet. >> >>>>>>> >> >>>>>>> So the installation is essentially a no-op. >> >>>>>>> >> >>>>>>> With green lights on these builds, we can now verify that removing >> >>>>>>> these packages won't break anything. At least, to the limit of the >> >>>>>>> tests, which isn't much at all. So if we _do_ actually strip these >> >>>>>>> guys out of Trunk, the builds should stay green. If they don't, we'll >> >>>>>>> need to roll back the change and investigate. >> >>>>>>> >> >>>>>>> But I don't actually know how to strip them out of Trunk. I _suspect_ >> >>>>>>> it'll be via a Monticello config map of some description. >> >>>>>> >> >>>>>> Anyone? Bert? How do we strip packages out of Trunk? >> >>>>> >> >>>>> Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating. >> >>>> >> >>>> Given that we're early in 4.5's release cycle, if we do this kind of >> >>>> thing - stripping unnecessary things out of trunk - we ought to do it >> >>>> now rather than later. And announce loudly what we're doing, why, and >> >>>> how people can load in their favourite not-Core packages. >> >>> >> >>> NO. >> >>> >> >>> If Squeak developers work with images that contain just "their favourite >> >>> non-Core packages" then none of the non-Core packages get maintained. >> >> >> >> Clearly we disagree quite a bit on this, but I don't think anyone >> >> should actually _work_ on a Core image. _Noone_ should be able to work >> >> effectively in a minimal image because such a thing wouldn't even have >> >> a Browser! >> > >> > We don't disagree on this at all. People should be working in a full image. >> >> OK, cool. Finding out points of agreement helps in finding out where >> we disagree :) >> >> >>> It is important to work on making packages loadable and unloadable, but >> >>> you do not need to break the trunk image in order to accomplish this. >> >> >> >> Who's breaking trunk? I want to remove packages that are already >> >> unloadable, >> > >> > Yes, but not from *user's* images, from the *core* image that is only used by the CI to build a full image. >> > >> >> and have CI jobs that run every time Trunk updates that >> >> verifies that the packages can (a) reload and (b) run as well as we >> >> already know now (which is not very). To be precise: Universes (for >> >> example) might be smashed beyond recognition, and there is no way to >> >> know, because it has something like 23% method coverage. >> > >> > Right. >> > >> >> Removing these packages from Trunk _will_ affect people updating from >> >> Trunk, I agree. How else do we make Trunk simpler, if not by removing >> >> stuff? >> > >> > I think we may be talking past each other. There are two types of packages we want to "remove from trunk": >> > >> > full = core packages + unloadable packages + deprecated packages >> > >> > So there are unloadable packages which should still exist in a full image that everyone is using. And there are deprecated packages which should not exist in a full image. >> > >> > Both core packages and unloadable packages are in Trunk. The only packages that we actually want to remove for good are the deprecated ones. The mechanics of unloading a deprecated package is by committing an empty version (which will remove all the classes and methods from user's images when updating), and eventually removing the now empty package from the update map (and bumping the squeak-version package to keep update numbers continuous). >> > >> > Maybe that's what you were asking about? >> > >> >> (It's also simple enough to reinstall your favourite packages: >> >> Installer squeakmap update; install: 'WhateverItIs (someVersion)'.) >> > >> > Sure, that's how you would re-install a deprecated package. >> > >> >>> Also, please recognize that not everybody wants to do all their work in >> >>> a clean image built by a robot. I for example do most of my work in a >> >>> Squeak3.11alpha image that has been continuously updated from the update >> >>> stream for quite a while. I also periodically check things against a >> >>> fresh 4.4 image, but my usual pattern is to use one image over a long >> >>> period of time with the trunk update stream, and most of my updates to >> >>> trunk come from that old image. >> >> >> >> OK, but then we can't have a minimal core without an entire reboot. I >> >> mean, seriously, making a minimal core by unloading packages is an >> >> order of magnitude harder when you cannot ever actually unload the >> >> packages! >> >> >> >> So, given the resistance to my slow, gradual unwinding of the tangle, >> >> what's your counterproposal? >> >> >> >> frank >> > >> > >> > I still fail to see the problem. For purposes of the build server, you once make a Core image by unloading all possible packages. This becomes the new "master image" from which all subsequent releases are built. Then you use that as the base to run tests, build full images, etc. >> > >> > Does that sound reasonable? >> >> Ah! OK, right. So, to see if I understand correctly: >> * We _don't_ issue an empty version for the packages we're interested >> in unloading. (Just for argument's sake, I'll talk about Universes.) >> * If at some point in the future we decide to deprecate Universes, >> _then_ we commit the empty version, and update the map. That decision >> may be deferred for an arbitrary period after unloading it from Core. >> * We take a clean Trunk image from CI, unload all unloadable packages, >> and store that as our new master 4.5 image. (This will likely be a >> manual step, and the clean image committed to the squeak-ci script >> repository.) >> * The stripped master remains stripped, and the existing SqueakTrunk >> job publishes updated copies of the core image as per normal. >> * We adjust the ReleaseSqueakTrunk CI job to, via >> ReleaseBuilderForSqueak4dot5, loads the unloadable packages from >> SqueakTrunk's output to create a "full fat" version. >> >> Dave, sound good? >> > > Yes :) OK, so I thought I'd start the ball rolling with inspiration from SmalltalkImage >> #unloadAllKnownPackages - #('Nebraska' 'Universes' 'XML-Parser') do: [:pkgName| (MCPackage named: pkgName) unload. MCMcmUpdater disableUpdatesOfPackage: pkgName]. I've stored this as Squeak4.5.image in the squeak-ci repository. This is the new base that we update from trunk. ReleaseSqueakTrunk then loads these packages back into the image. That's the theory. In practice, the above is insufficient because it leaves obsolete classes lying around. So I added MCWorkingCopy flushObsoletePackageInfos. MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Behavior flushObsoleteSubclasses. ChangeSet current clear. ChangeSet current name: 'Unnamed1'. Smalltalk flushClassNameCache. This too is insufficient: The SqueakCI-Benchmarking package happens to depend on XML-Parser, so I reload the latest version of that package... and things break because there are AnObsoleteXMLWriter instances. What have I missed? frank > Dave > >> frank >> >> > - Bert - >> > >> > > |
|
|
On Sat, Mar 30, 2013 at 4:52 AM, Frank Shearar <[hidden email]> wrote: On 25 February 2013 18:51, David T. Lewis <[hidden email]> wrote: This is when the tedium starts. Use PointerFinder to track down the reference path to the obsolete XMLWriter, then determine (e.g. find or invent) the initialization(s) that eliminate that path (either by deleting the thing because it shouldn't be referred to, or evaluating something that replaces it).
best, Eliot
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |