The Trunk: Kernel-fbs.791.mcz
Locked
 
|
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') ----- declare: varString "Declare class variables common to all instances. Answer whether recompilation is advisable." | newVars conflicts | newVars := (Scanner new scanFieldNames: varString) collect: [:x | x asSymbol]. newVars do: [:var | var first canBeGlobalVarInitial ifFalse: [self error: var, ' class variable name should be capitalized; proceed to include anyway.']]. conflicts := false. classPool == nil ifFalse: [(classPool keys reject: [:x | newVars includes: x]) do: [:var | self removeClassVarName: var]]. (newVars reject: [:var | self classPool includesKey: var]) do: [:var | "adding" "check if new vars defined elsewhere" (self canFindWithoutEnvironment: var) ifTrue: [ (DuplicateVariableError new) superclass: superclass; "fake!!!!!!" variable: var; signal: var, ' is already defined'. conflicts := true]]. newVars size > 0 ifTrue: [classPool := self classPool. "in case it was nil" + newVars do: [:var | classPool declare: var from: self environment undeclared]]. - newVars do: [:var | classPool declare: var from: environment undeclared]]. ^conflicts! |
Re: The Trunk: Kernel-fbs.791.mcz
|
|
On 17 July 2013 19:26, <[hidden email]> 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 |
Re: The Trunk: Kernel-fbs.791.mcz
|
|
On 17-07-2013, at 2:15 PM, Frank Shearar <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim bicycle - a double headed corn cutter |
Re: The Trunk: Kernel-fbs.791.mcz
|
|
On 17 July 2013 23:00, tim Rowledge <[hidden email]> wrote:
> > On 17-07-2013, at 2:15 PM, Frank Shearar <[hidden email]> 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 |
Re: The Trunk: Kernel-fbs.791.mcz
|
|
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...2013/7/18 Frank Shearar <[hidden email]>
|
Re: The Trunk: Kernel-fbs.791.mcz
|
|
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 <[hidden email]> 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 <[hidden email]> >> >> On 17 July 2013 23:00, tim Rowledge <[hidden email]> wrote: >> > >> > On 17-07-2013, at 2:15 PM, Frank Shearar <[hidden email]> >> > 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 >> > > > > |
Re: The Trunk: Kernel-fbs.791.mcz
|
|
In reply to this post by Frank Shearar-3
On 2013-07-18, at 11:16, Frank Shearar <[hidden email]> 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 - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |