On 17 July 2013 19:26, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-fbs.791.mcz
==================== Summary ====================
Name: Kernel-fbs.791 Author: fbs Time: 11 July 2013, 8:58:41.496 pm UUID: a70ef892-e4ef-1a46-9aed-c95fd0ee4cd5 Ancestors: Kernel-fbs.790
Allow the loading of classes with nil environment. (This indicates that a class tracks its superclass' environment.)
=============== Diff against Kernel-fbs.790 ===============
Item was changed: ----- Method: Class>>declare: (in category 'initialize-release') -----
So I had expected that this would be sufficient to fix the update stream. It's not. I issued a new config map specifying this version, and it loads Kernel before Morphic (the problem package), and as far as I can see we still have update stream problems. Someone help, please?
frank
On 17-07-2013, at 2:15 PM, Frank Shearar frank.shearar@gmail.com wrote:
So I had expected that this would be sufficient to fix the update stream. It's not. I issued a new config map specifying this version, and it loads Kernel before Morphic (the problem package), and as far as I can see we still have update stream problems. Someone help, please?
Wish I could - but it puzzles me, too. We may have to wait until Colin is available again
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim bicycle - a double headed corn cutter
On 17 July 2013 23:00, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 2:15 PM, Frank Shearar frank.shearar@gmail.com wrote:
So I had expected that this would be sufficient to fix the update stream. It's not. I issued a new config map specifying this version, and it loads Kernel before Morphic (the problem package), and as far as I can see we still have update stream problems. Someone help, please?
Wish I could - but it puzzles me, too. We may have to wait until Colin is available again
I'm taking the image that's in the squeak-ci repository and updating it. That's not _terribly_ old. Maybe a few weeks out of date. (I could go check, but it's all the way in the other tab...)
The problem arises when loading Morphic-fbs.663 from update-fbs.239. At this point you get a walkback because Kernel-fbs.791 isn't loaded. This contains the bugfix that lets you load a class with a nil Environment, but of course it also includes all the changes between Kernel-fbs.779 and -791. By the time you've started loading Morphic-fbs.663 it's too late to try load Kernel-fbs.791. But you also can't just load Kernel-fbs.791 before you start the update, because the image hangs doing _something_, presumably because the other stuff in the diff between Kernel-fbs.779 Kernel-fbs.791 requires other packages to be loaded.
So what's next? One hack might be to quietly reissue update-fbs.239, but (a) that's disgusting and (b) I'd always understood config maps to be immutable and (c) it sounds like a recipe for disaster.
I don't think I need an Environments expert, but I do need a Monticello expert. Takers? Volunteers?
frank
tim
Maybe you could try the other way around, roll back Morphic-fbs.663 from update-fbs.239, and introduce it in a later update AFTER Kernel-fbs.791. Not sure if possible, because moving elements between package necessarily create intricated changes, but worth trying...
Otherwise, we could have to backport the Environment change to an older Kernel version, and iteratively on any intermediate Kernel version necessary to the update chain.
2013/7/18 Frank Shearar frank.shearar@gmail.com
On 17 July 2013 23:00, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 2:15 PM, Frank Shearar frank.shearar@gmail.com
wrote:
So I had expected that this would be sufficient to fix the update stream. It's not. I issued a new config map specifying this version, and it loads Kernel before Morphic (the problem package), and as far as I can see we still have update stream problems. Someone help, please?
Wish I could - but it puzzles me, too. We may have to wait until Colin
is available again
I'm taking the image that's in the squeak-ci repository and updating it. That's not _terribly_ old. Maybe a few weeks out of date. (I could go check, but it's all the way in the other tab...)
The problem arises when loading Morphic-fbs.663 from update-fbs.239. At this point you get a walkback because Kernel-fbs.791 isn't loaded. This contains the bugfix that lets you load a class with a nil Environment, but of course it also includes all the changes between Kernel-fbs.779 and -791. By the time you've started loading Morphic-fbs.663 it's too late to try load Kernel-fbs.791. But you also can't just load Kernel-fbs.791 before you start the update, because the image hangs doing _something_, presumably because the other stuff in the diff between Kernel-fbs.779 Kernel-fbs.791 requires other packages to be loaded.
So what's next? One hack might be to quietly reissue update-fbs.239, but (a) that's disgusting and (b) I'd always understood config maps to be immutable and (c) it sounds like a recipe for disaster.
I don't think I need an Environments expert, but I do need a Monticello expert. Takers? Volunteers?
frank
tim
I wish I could figure out the last config map applied to an image. Or, given an image, figure out some semblance of a version. (I haven't gotten to the bottom of why images based off the Squeak4.5.image in the squeak-ci repository have version numbers out by around about 100 from those of others.)
At any rate, given a _relatively_ recent image (no more than a few weeks old), I can navigate past the update stream problems by loading the affected packages in this order:
Kernel-fbs.791 Morphic-dtl.688 Files-fbs.125 System-fbs.569
But how to apply that to trunk, I don't know. I _think_ we need to remove several update maps and add a new one with the above order. I keep hoping Bert or Levente will pop up and go "tsk tsk, here let me fix that for you".
frank
On 18 July 2013 11:54, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Maybe you could try the other way around, roll back Morphic-fbs.663 from update-fbs.239, and introduce it in a later update AFTER Kernel-fbs.791. Not sure if possible, because moving elements between package necessarily create intricated changes, but worth trying...
Otherwise, we could have to backport the Environment change to an older Kernel version, and iteratively on any intermediate Kernel version necessary to the update chain.
2013/7/18 Frank Shearar frank.shearar@gmail.com
On 17 July 2013 23:00, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 2:15 PM, Frank Shearar frank.shearar@gmail.com wrote:
So I had expected that this would be sufficient to fix the update stream. It's not. I issued a new config map specifying this version, and it loads Kernel before Morphic (the problem package), and as far as I can see we still have update stream problems. Someone help, please?
Wish I could - but it puzzles me, too. We may have to wait until Colin is available again
I'm taking the image that's in the squeak-ci repository and updating it. That's not _terribly_ old. Maybe a few weeks out of date. (I could go check, but it's all the way in the other tab...)
The problem arises when loading Morphic-fbs.663 from update-fbs.239. At this point you get a walkback because Kernel-fbs.791 isn't loaded. This contains the bugfix that lets you load a class with a nil Environment, but of course it also includes all the changes between Kernel-fbs.779 and -791. By the time you've started loading Morphic-fbs.663 it's too late to try load Kernel-fbs.791. But you also can't just load Kernel-fbs.791 before you start the update, because the image hangs doing _something_, presumably because the other stuff in the diff between Kernel-fbs.779 Kernel-fbs.791 requires other packages to be loaded.
So what's next? One hack might be to quietly reissue update-fbs.239, but (a) that's disgusting and (b) I'd always understood config maps to be immutable and (c) it sounds like a recipe for disaster.
I don't think I need an Environments expert, but I do need a Monticello expert. Takers? Volunteers?
frank
tim
On 2013-07-18, at 11:16, Frank Shearar frank.shearar@gmail.com wrote:
One hack might be to quietly reissue update-fbs.239, but (a) that's disgusting and (b) I'd always understood config maps to be immutable and (c) it sounds like a recipe for disaster.
Modifying (by recommitting) the latest update map is okay-ish because it is referenced in the image only by its number and is reloaded every time you update. You still have to be aware what the purpose of that update map was, to make sure it still does that. Modifying an older update map is a Very Bad Idea.
- Bert -
squeak-dev@lists.squeakfoundation.org