Frank, this is so great. Everyone wants a smaller image for server processing but keeping "rich" images for clients and development. I love the methodical way you've come about to producing both, leaning on the systems own tests to ensure quality is maintained every step of the way. Kudos!
... snip ... Sure! Questions are always welcome!
Chris Cunningham posed an excellent question -- does anyone know whether we could take a SqueakTrunk (core) image, load selective packages into it but still keep up-to-date with trunk?
From what we've learned from Levente about the update-#; it's the sum
total of all version numbers across all loaded packages and the trunk update uses that number to determine what updates are needed to move the image forward.
With packages unloaded the trunk update process would seem to break down for that image, is that right?
If we can't update a core/custom images, it creates a trade-off situation right off the bat. A smaller image, yes, but one that can only be manually patched. Is there any way to maintain the best of both worlds?
On 31 July 2013 03:18, Chris Muller asqueaker@gmail.com wrote:
Frank, this is so great. Everyone wants a smaller image for server processing but keeping "rich" images for clients and development. I love the methodical way you've come about to producing both, leaning on the systems own tests to ensure quality is maintained every step of the way. Kudos!
Thank you kindly, Chris! I'm working very hard at keeping the stripping-down as painless as possible for consumers, because historically this has been the biggest stumbling blocks to minimalism.
... snip ... Sure! Questions are always welcome!
Chris Cunningham posed an excellent question -- does anyone know whether we could take a SqueakTrunk (core) image, load selective packages into it but still keep up-to-date with trunk?
Yes. Unless you say say `MCMcmUpdater updateMissingPackages: true`, you _won't_ receive updates for stripped packages (see the (*) below), but you _will_ receive updates for all the packages you have in your image.
From what we've learned from Levente about the update-#; it's the sum
total of all version numbers across all loaded packages and the trunk update uses that number to determine what updates are needed to move the image forward.
The system version - the update number - is calculated in Utilities class >> #setSystemVersionFromConfig: (+). Given the MC configuration parameter, it sums the version numbers in that configuration to yield the update number.
I might be completely wrong, but _as I understand it_ this means that the Squeak4.5.image in the squeak-ci repo (in other words, the semi-hand-rolled "minimal" base from which we work) will _under-report_ its update number. It doesn't have, say, the Nebraska package. Let's say Nebraska's currently at version 10, and the update number's 100. If someone pushes a new Nebraska package with version 11 to trunk (*), the configuration remains unchanged. The minimal image says "don't update stripped packages" so won't update Nebraska, and its update number stays at 100. Someone running a "full fat" image updates, and pulls in Nebraska 11. Her image is now at update number 101.
frank
(+) I've submitted a pair of commits to the Inbox to move this stuff to MCMcmUpdater. Critiques welcome, even if they're just "+1". (*) They really shouldn't. In Frank's Happy Land the versions of Nebraska already present in the trunk update stream stay there, but new versions go to the Nebraska repository, and you treat Nebraska like any 3rd party application: it should have its own SM entry, ConfigurationOf/Installer script, and so on.
With packages unloaded the trunk update process would seem to break down for that image, is that right?
If we can't update a core/custom images, it creates a trade-off situation right off the bat. A smaller image, yes, but one that can only be manually patched. Is there any way to maintain the best of both worlds?
On Wed, Jul 31, 2013 at 12:26 AM, Frank Shearar frank.shearar@gmail.comwrote:
On 31 July 2013 03:18, Chris Muller asqueaker@gmail.com wrote:
Frank, this is so great. Everyone wants a smaller image for server processing but keeping "rich" images for clients and development. I love the methodical way you've come about to producing both, leaning on the systems own tests to ensure quality is maintained every step of the way. Kudos!
Yes!
Thank you kindly, Chris! I'm working very hard at keeping the stripping-down as painless as possible for consumers, because historically this has been the biggest stumbling blocks to minimalism.
... snip ... Sure! Questions are always welcome!
Chris Cunningham posed an excellent question -- does anyone know whether we could take a SqueakTrunk (core) image, load selective packages into it but still keep up-to-date with trunk?
Just for the record, I LIKE the way Frank has it working. I like the idea
that when someone is changing some core part of the system, it is able to immediately give feedback that it might impact an unloadable part, and give you a chance to fix it right then and there. I do see the point of getting a more stripped down version and just updating it as well, it's just not what I'd want by default.
Yes. Unless you say say `MCMcmUpdater updateMissingPackages: true`, you _won't_ receive updates for stripped packages (see the (*) below), but you _will_ receive updates for all the packages you have in your image.
If this is set and you rename a package (say, rename ST-80 to be MVC), will this keep the new MVC from updating as well? I would assume so.
From what we've learned from Levente about the update-#; it's the sum
total of all version numbers across all loaded packages and the trunk update uses that number to determine what updates are needed to move the image forward.
The system version - the update number - is calculated in Utilities class >> #setSystemVersionFromConfig: (+). Given the MC configuration parameter, it sums the version numbers in that configuration to yield the update number.
I might be completely wrong, but _as I understand it_ this means that the Squeak4.5.image in the squeak-ci repo (in other words, the semi-hand-rolled "minimal" base from which we work) will _under-report_ its update number. It doesn't have, say, the Nebraska package. Let's say Nebraska's currently at version 10, and the update number's 100. If someone pushes a new Nebraska package with version 11 to trunk (*), the configuration remains unchanged. The minimal image says "don't update stripped packages" so won't update Nebraska, and its update number stays at 100. Someone running a "full fat" image updates, and pulls in Nebraska 11. Her image is now at update number 101.
frank
(+) I've submitted a pair of commits to the Inbox to move this stuff to MCMcmUpdater. Critiques welcome, even if they're just "+1". (*) They really shouldn't. In Frank's Happy Land the versions of Nebraska already present in the trunk update stream stay there, but new versions go to the Nebraska repository, and you treat Nebraska like any 3rd party application: it should have its own SM entry, ConfigurationOf/Installer script, and so on.
Crazy thought - would it be possible to distribute Trunk out to other repositories as well? We have the core trunk repository, + a repository for unloadable parts (such as Nebraska) in it's own repository, but it would still fall under the Trunk umbrella (that is, and update from Trunk would also include updates in that repository as well - if the package is currently loaded)? Or is that too big a nest of worms?
With packages unloaded the trunk update process would seem to break down for that image, is that right?
If we can't update a core/custom images, it creates a trade-off situation right off the bat. A smaller image, yes, but one that can only be manually patched. Is there any way to maintain the best of both worlds?
On 7/30/13 11:18 PM, "Chris Muller" asqueaker@gmail.com wrote:
Chris Cunningham posed an excellent question -- does anyone know whether we could take a SqueakTrunk (core) image, load selective packages into it but still keep up-to-date with trunk?
Yes, I have this. Try http://squeakros.org/Core/SqueakRosCore4dot5-12545.zip
Currently I start to rebuild again from http://ftp.squeak.org/Experiments/SqueakCore4.2-10382-alpha.zip
When I have time summarize the differences with Trunk
You could see in action here http://190.193.248.6:9090/welcome http://190.193.248.6:9090/showWikiLastYear
User: visita Pass: "in blank here"
The system is SqueakRosCore4dot5 + HV2 + JavaScript + Css = HTML rendered in your browser (Firefox endorsed)
I like feedback
Edgar
P.S. And do nor forget this year http://www.fast.org.ar/smalltalks2013. So I pay beers to far away friends
squeak-dev@lists.squeakfoundation.org
-
Chris Cunningham -
Chris Muller -
Edgar J. De Cleene -
Frank Shearar