How to produce a fixed version?
Locked
 
|
I'm using an older version of the xml parser for gemstone in my project. I wrote a mail about the problem already to the gemstone list. The problem was that incompatible versions of the xml parser got sucked into the dependency graph and produced problems. But now the situation is the same and there are no incompatible versions.
As far as I can see I depend on xml parser 1.0.5 and no other component depends on a newer version. But metacello seems to peek for the newest release version and introduces new dependencies. In the meantime a new xml parser for gemstone is available with a new baseline. This baseline depends on another component: xml writer 1.0.4. My problem is special because a class moved from the old xml parser to the new dependent package. That is not the problem. I'm just trying to understand how to define a fixed version in metacello. A fixed version in my sense is a fixed definition of a software package over time. That means if I load my software version today and one year later it will load the same packages as long as the definition was tight enough. But I got the impression that isn't easy doable (or doable at all) and the progress in dependent packages will produce side effects in the build of my own project. I would be glad to hear some words about me missing the point or how metacello can provide this. Norbert |
Re: How to produce a fixed version?
|
|
Norbert,
Metacello is intended to work the way that you expect ... From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... Dale On Mar 5, 2011, at 9:11 AM, Norbert Hartl wrote: > I'm using an older version of the xml parser for gemstone in my project. I wrote a mail about the problem already to the gemstone list. The problem was that incompatible versions of the xml parser got sucked into the dependency graph and produced problems. But now the situation is the same and there are no incompatible versions. > > As far as I can see I depend on xml parser 1.0.5 and no other component depends on a newer version. But metacello seems to peek for the newest release version and introduces new dependencies. In the meantime a new xml parser for gemstone is available with a new baseline. This baseline depends on another component: xml writer 1.0.4. My problem is special because a class moved from the old xml parser to the new dependent package. That is not the problem. I'm just trying to understand how to define a fixed version in metacello. A fixed version in my sense is a fixed definition of a software package over time. That means if I load my software version today and one year later it will load the same packages as long as the definition was tight enough. But I got the impression that isn't easy doable (or doable at all) and the progress in dependent packages will produce side effects in the build of my own project. > > I would be glad to hear some words about me missing the point or how metacello can provide this. > > Norbert > |
Re: How to produce a fixed version?
|
|
On 05.03.2011, at 19:52, Dale Henrichs wrote: Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: ConfigurationOfXMLSupport defines baseline105 - no dependency to ConfigurationOfXMLWriter version105 - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 baseline119 - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) version119 - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 When I load ConfigurationOfXMLSupport version 1.0.5 than the files XML-Parser.g-DaleHenrichs.93 and XML Writer 1.0.4 are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. Maybe it is just the case that newly introduced dependencies are added and get active. Norbert
|
test22-build-log.txt (65K)
Re: How to produce a fixed version?
|
|
Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:(
XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) Dale On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: On 05.03.2011, at 19:52, Dale Henrichs wrote: Norbert, Metacello is intended to work the way that you expect ... Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: ConfigurationOfXMLSupport defines baseline105 - no dependency to ConfigurationOfXMLWriter version105 - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 baseline119 - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) version119 - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 When I load ConfigurationOfXMLSupport version 1.0.5 than the files XML-Parser.g-DaleHenrichs.93 and XML Writer 1.0.4 are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. Maybe it is just the case that newly introduced dependencies are added and get active. Norbert <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> |
Re: How to produce a fixed version?
|
|
On 05.03.2011, at 21:49, Dale Henrichs wrote: > Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( > I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. > XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... > Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). > I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) > Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. Norbert > Dale > > On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: > > > On 05.03.2011, at 19:52, Dale Henrichs wrote: > > Norbert, > > Metacello is intended to work the way that you expect ... > > Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. > > From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. > > If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... > > I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 > for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. > The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. > > If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. > > You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) > > Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... > > The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: > > ConfigurationOfXMLSupport defines > > baseline105 > - no dependency to ConfigurationOfXMLWriter > > version105 > - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 > > baseline119 > - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) > > version119 > - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 > > When I load ConfigurationOfXMLSupport version 1.0.5 than the files > > XML-Parser.g-DaleHenrichs.93 > and > XML Writer 1.0.4 > > are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. > Maybe it is just the case that newly introduced dependencies are added and get active. > > Norbert > > <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> > |
Re: How to produce a fixed version?
|
|
The issue stems from the fact that Metacello needs to determine the currently loaded version of the project:
if the current version is later than the one requested, nothing is loaded if the current version is less than the one requiested, the requested version is loaded To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... It sounds as though XML is already loaded in your system? Is that correct? If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... Dale On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: > > On 05.03.2011, at 21:49, Dale Henrichs wrote: > >> Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( >> > I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. > >> XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... >> > Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). > >> I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) >> > Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. > > I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. > > Norbert > >> Dale >> >> On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: >> >> >> On 05.03.2011, at 19:52, Dale Henrichs wrote: >> >> Norbert, >> >> Metacello is intended to work the way that you expect ... >> >> Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. >> >> From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. >> >> If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... >> >> I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 >> for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. >> The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. >> >> If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. >> >> You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) >> >> Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... >> >> The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: >> >> ConfigurationOfXMLSupport defines >> >> baseline105 >> - no dependency to ConfigurationOfXMLWriter >> >> version105 >> - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 >> >> baseline119 >> - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) >> >> version119 >> - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 >> >> When I load ConfigurationOfXMLSupport version 1.0.5 than the files >> >> XML-Parser.g-DaleHenrichs.93 >> and >> XML Writer 1.0.4 >> >> are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. >> Maybe it is just the case that newly introduced dependencies are added and get active. >> >> Norbert >> >> <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> >> > |
Re: How to produce a fixed version?
|
|
On 06.03.2011, at 00:00, Dale Henrichs wrote: ok No, it is just loaded before seaside which triggers the problem. Do you need anything more detailed than you can see in the log? It is pretty much detailed. In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) <CUT> ---loading glass--- topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' ... --transcript--'...finished 1.0-beta.8.6' ---loading metacello--- topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' --transcript--'...finished 1.0-beta.28.3.1' ---loading magritte--- topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' ... --transcript--'...finished 2.0.6' ---loading xml parser 1.0.5--- topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' --transcript--'...finished 1.0.5' topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' ---- loading seaside30 --- topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' ... --transcript--'Project: XML Parser 1.0.5' --> here 1.0.5 is loaded but the dependency from a later baseline activated --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' --transcript--'Project: XML-Writer 1.0.4' --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' --transcript--'Project: Grease Core 1.0-rc' --transcript--'Project: System-Digital-Signatures 0.238' --transcript--'Project: XML Parser 1.0.5' --transcript--'Project: XML-Writer 1.0.4' --transcript--'Project: Grease Core 1.0-rc' ... --transcript--'...finished 3.0.4' Hope this helps. If you need anything more or prepared than what you see in the log please let me know. Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. thanks, Norbert
|
Re: How to produce a fixed version?
|
|
Okay...so in the end the the question that you are actually asking is "Why is XMLWriter loaded?"... or am I missing something else?
printing the result of a fetch command should answer that question ... the linear listing in the log file doesn't give you the answer to "which configuration caused XMLWriter to be loaded?" just the order in which they are loaded ... I'll see if I can figure that out a bit later... Dale On Mar 5, 2011, at 5:06 PM, Norbert Hartl wrote: On 06.03.2011, at 00:00, Dale Henrichs wrote: The issue stems from the fact that Metacello needs to determine the currently loaded version of the project: if the current version is later than the one requested, nothing is loaded if the current version is less than the one requiested, the requested version is loaded ok To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... It sounds as though XML is already loaded in your system? Is that correct? No, it is just loaded before seaside which triggers the problem. If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. Do you need anything more detailed than you can see in the log? It is pretty much detailed. In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) <CUT> ---loading glass--- topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' ... --transcript--'...finished 1.0-beta.8.6' ---loading metacello--- topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' --transcript--'...finished 1.0-beta.28.3.1' ---loading magritte--- topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' ... --transcript--'...finished 2.0.6' ---loading xml parser 1.0.5--- topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' --transcript--'...finished 1.0.5' topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' ---- loading seaside30 --- topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' ... --transcript--'Project: XML Parser 1.0.5' --> here 1.0.5 is loaded but the dependency from a later baseline activated --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' --transcript--'Project: XML-Writer 1.0.4' --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' --transcript--'Project: Grease Core 1.0-rc' --transcript--'Project: System-Digital-Signatures 0.238' --transcript--'Project: XML Parser 1.0.5' --transcript--'Project: XML-Writer 1.0.4' --transcript--'Project: Grease Core 1.0-rc' ... --transcript--'...finished 3.0.4' Hope this helps. If you need anything more or prepared than what you see in the log please let me know. As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. thanks, Norbert On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: On 05.03.2011, at 21:49, Dale Henrichs wrote: Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. Norbert Dale On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: On 05.03.2011, at 19:52, Dale Henrichs wrote: Norbert, Metacello is intended to work the way that you expect ... Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: ConfigurationOfXMLSupport defines baseline105 - no dependency to ConfigurationOfXMLWriter version105 - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 baseline119 - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) version119 - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 When I load ConfigurationOfXMLSupport version 1.0.5 than the files XML-Parser.g-DaleHenrichs.93 and XML Writer 1.0.4 are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. Maybe it is just the case that newly introduced dependencies are added and get active. Norbert <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> |
Re: How to produce a fixed version?
|
|
On 06.03.2011, at 02:25, Dale Henrichs wrote: > Okay...so in the end the the question that you are actually asking is "Why is XMLWriter loaded?"... or am I missing something else? > Yep, I want to know why xml writer is loaded. > printing the result of a fetch command should answer that question ... the linear listing in the log file doesn't give you the answer to "which configuration caused XMLWriter to be loaded?" just the order in which they are loaded ... > I'll try tomorrow. As you can see I'm loading a few things one after the other. Should I expect a big difference if I would provide a configuration for the same things? > I'll see if I can figure that out a bit later... > thanks, Norbert > Dale > > On Mar 5, 2011, at 5:06 PM, Norbert Hartl wrote: > > > On 06.03.2011, at 00:00, Dale Henrichs wrote: > > The issue stems from the fact that Metacello needs to determine the currently loaded version of the project: > > if the current version is later than the one requested, nothing is loaded > if the current version is less than the one requiested, the requested version is loaded > > ok > > To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... > > It sounds as though XML is already loaded in your system? Is that correct? > > No, it is just loaded before seaside which triggers the problem. > > If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). > > If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. > > Do you need anything more detailed than you can see in the log? It is pretty much detailed. > In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) > > <CUT> > ---loading glass--- > topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' > --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' > --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' > ... > --transcript--'...finished 1.0-beta.8.6' > > ---loading metacello--- > topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' > --transcript--'...finished 1.0-beta.28.3.1' > > ---loading magritte--- > topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' > ... > --transcript--'...finished 2.0.6' > > ---loading xml parser 1.0.5--- > topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' > --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' > --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' > --transcript--'...finished 1.0.5' > > topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' > > ---- loading seaside30 --- > topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' > ... > --transcript--'Project: XML Parser 1.0.5' > --> here 1.0.5 is loaded but the dependency from a later baseline activated > --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' > --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' > --transcript--'Project: XML-Writer 1.0.4' > --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' > --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' > --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' > --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' > --transcript--'Project: Grease Core 1.0-rc' > --transcript--'Project: System-Digital-Signatures 0.238' > --transcript--'Project: XML Parser 1.0.5' > --transcript--'Project: XML-Writer 1.0.4' > --transcript--'Project: Grease Core 1.0-rc' > ... > --transcript--'...finished 3.0.4' > > Hope this helps. If you need anything more or prepared than what you see in the log please let me know. > > As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... > > The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... > > Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. > > thanks, > > Norbert > > On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: > > > On 05.03.2011, at 21:49, Dale Henrichs wrote: > > Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( > > I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. > > XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... > > Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). > > I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) > > Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. > > I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. > > Norbert > > Dale > > On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: > > > On 05.03.2011, at 19:52, Dale Henrichs wrote: > > Norbert, > > Metacello is intended to work the way that you expect ... > > Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. > > From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. > > If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... > > I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 > for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. > The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. > > If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. > > You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) > > Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... > > The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: > > ConfigurationOfXMLSupport defines > > baseline105 > - no dependency to ConfigurationOfXMLWriter > > version105 > - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 > > baseline119 > - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) > > version119 > - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 > > When I load ConfigurationOfXMLSupport version 1.0.5 than the files > > XML-Parser.g-DaleHenrichs.93 > and > XML Writer 1.0.4 > > are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. > Maybe it is just the case that newly introduced dependencies are added and get active. > > Norbert > > <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> > > > > > |
Re: How to produce a fixed version?
|
|
Now that I know the problem, I was able to fix the config ... when I made my pass fixing the xml support config in January, I missed version 1.1.7 and that would explain the why XMLWriter was coming in ...
Dale On Mar 5, 2011, at 5:45 PM, Norbert Hartl wrote: > > On 06.03.2011, at 02:25, Dale Henrichs wrote: > >> Okay...so in the end the the question that you are actually asking is "Why is XMLWriter loaded?"... or am I missing something else? >> > Yep, I want to know why xml writer is loaded. > >> printing the result of a fetch command should answer that question ... the linear listing in the log file doesn't give you the answer to "which configuration caused XMLWriter to be loaded?" just the order in which they are loaded ... >> > I'll try tomorrow. As you can see I'm loading a few things one after the other. Should I expect a big difference if I would provide a configuration for the same things? > >> I'll see if I can figure that out a bit later... >> > thanks, > > Norbert > >> Dale >> >> On Mar 5, 2011, at 5:06 PM, Norbert Hartl wrote: >> >> >> On 06.03.2011, at 00:00, Dale Henrichs wrote: >> >> The issue stems from the fact that Metacello needs to determine the currently loaded version of the project: >> >> if the current version is later than the one requested, nothing is loaded >> if the current version is less than the one requiested, the requested version is loaded >> >> ok >> >> To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... >> >> It sounds as though XML is already loaded in your system? Is that correct? >> >> No, it is just loaded before seaside which triggers the problem. >> >> If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). >> >> If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. >> >> Do you need anything more detailed than you can see in the log? It is pretty much detailed. >> In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) >> >> <CUT> >> ---loading glass--- >> topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >> --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >> --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' >> ... >> --transcript--'...finished 1.0-beta.8.6' >> >> ---loading metacello--- >> topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' >> --transcript--'...finished 1.0-beta.28.3.1' >> >> ---loading magritte--- >> topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' >> ... >> --transcript--'...finished 2.0.6' >> >> ---loading xml parser 1.0.5--- >> topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' >> --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' >> --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' >> --transcript--'...finished 1.0.5' >> >> topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' >> >> ---- loading seaside30 --- >> topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' >> ... >> --transcript--'Project: XML Parser 1.0.5' >> --> here 1.0.5 is loaded but the dependency from a later baseline activated >> --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >> --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' >> --transcript--'Project: XML-Writer 1.0.4' >> --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' >> --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >> --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >> --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' >> --transcript--'Project: Grease Core 1.0-rc' >> --transcript--'Project: System-Digital-Signatures 0.238' >> --transcript--'Project: XML Parser 1.0.5' >> --transcript--'Project: XML-Writer 1.0.4' >> --transcript--'Project: Grease Core 1.0-rc' >> ... >> --transcript--'...finished 3.0.4' >> >> Hope this helps. If you need anything more or prepared than what you see in the log please let me know. >> >> As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... >> >> The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... >> >> Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. >> >> thanks, >> >> Norbert >> >> On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: >> >> >> On 05.03.2011, at 21:49, Dale Henrichs wrote: >> >> Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( >> >> I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. >> >> XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... >> >> Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). >> >> I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) >> >> Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. >> >> I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. >> >> Norbert >> >> Dale >> >> On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: >> >> >> On 05.03.2011, at 19:52, Dale Henrichs wrote: >> >> Norbert, >> >> Metacello is intended to work the way that you expect ... >> >> Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. >> >> From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. >> >> If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... >> >> I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 >> for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. >> The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. >> >> If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. >> >> You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) >> >> Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... >> >> The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: >> >> ConfigurationOfXMLSupport defines >> >> baseline105 >> - no dependency to ConfigurationOfXMLWriter >> >> version105 >> - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 >> >> baseline119 >> - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) >> >> version119 >> - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 >> >> When I load ConfigurationOfXMLSupport version 1.0.5 than the files >> >> XML-Parser.g-DaleHenrichs.93 >> and >> XML Writer 1.0.4 >> >> are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. >> Maybe it is just the case that newly introduced dependencies are added and get active. >> >> Norbert >> >> <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> >> >> >> >> >> > |
Re: How to produce a fixed version?
|
|
On 06.03.2011, at 05:02, Dale Henrichs wrote: > Now that I know the problem, I was able to fix the config ... when I made my pass fixing the xml support config in January, I missed version 1.1.7 and that would explain the why XMLWriter was coming in ... > Can you elaborate on this? What went wrong with 1.1.7? I changed the load order for testing. I first loaded seaside30 which pulled in xml parser 1.0.5 without xml writer. The later attempt to load 1.0.5 just did nothing. Everything's fine as far as I can see. So I assume that providing a configuration for all my manual loads would have led to the right loading because there would be only one load attempt to an image not containing the xml parser. Norbert > Dale > > On Mar 5, 2011, at 5:45 PM, Norbert Hartl wrote: > >> >> On 06.03.2011, at 02:25, Dale Henrichs wrote: >> >>> Okay...so in the end the the question that you are actually asking is "Why is XMLWriter loaded?"... or am I missing something else? >>> >> Yep, I want to know why xml writer is loaded. >> >>> printing the result of a fetch command should answer that question ... the linear listing in the log file doesn't give you the answer to "which configuration caused XMLWriter to be loaded?" just the order in which they are loaded ... >>> >> I'll try tomorrow. As you can see I'm loading a few things one after the other. Should I expect a big difference if I would provide a configuration for the same things? >> >>> I'll see if I can figure that out a bit later... >>> >> thanks, >> >> Norbert >> >>> Dale >>> >>> On Mar 5, 2011, at 5:06 PM, Norbert Hartl wrote: >>> >>> >>> On 06.03.2011, at 00:00, Dale Henrichs wrote: >>> >>> The issue stems from the fact that Metacello needs to determine the currently loaded version of the project: >>> >>> if the current version is later than the one requested, nothing is loaded >>> if the current version is less than the one requiested, the requested version is loaded >>> >>> ok >>> >>> To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... >>> >>> It sounds as though XML is already loaded in your system? Is that correct? >>> >>> No, it is just loaded before seaside which triggers the problem. >>> >>> If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). >>> >>> If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. >>> >>> Do you need anything more detailed than you can see in the log? It is pretty much detailed. >>> In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) >>> >>> <CUT> >>> ---loading glass--- >>> topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>> --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>> --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' >>> ... >>> --transcript--'...finished 1.0-beta.8.6' >>> >>> ---loading metacello--- >>> topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' >>> --transcript--'...finished 1.0-beta.28.3.1' >>> >>> ---loading magritte--- >>> topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' >>> ... >>> --transcript--'...finished 2.0.6' >>> >>> ---loading xml parser 1.0.5--- >>> topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' >>> --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' >>> --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' >>> --transcript--'...finished 1.0.5' >>> >>> topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' >>> >>> ---- loading seaside30 --- >>> topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' >>> ... >>> --transcript--'Project: XML Parser 1.0.5' >>> --> here 1.0.5 is loaded but the dependency from a later baseline activated >>> --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>> --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' >>> --transcript--'Project: XML-Writer 1.0.4' >>> --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' >>> --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>> --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>> --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' >>> --transcript--'Project: Grease Core 1.0-rc' >>> --transcript--'Project: System-Digital-Signatures 0.238' >>> --transcript--'Project: XML Parser 1.0.5' >>> --transcript--'Project: XML-Writer 1.0.4' >>> --transcript--'Project: Grease Core 1.0-rc' >>> ... >>> --transcript--'...finished 3.0.4' >>> >>> Hope this helps. If you need anything more or prepared than what you see in the log please let me know. >>> >>> As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... >>> >>> The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... >>> >>> Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. >>> >>> thanks, >>> >>> Norbert >>> >>> On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: >>> >>> >>> On 05.03.2011, at 21:49, Dale Henrichs wrote: >>> >>> Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( >>> >>> I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. >>> >>> XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... >>> >>> Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). >>> >>> I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) >>> >>> Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. >>> >>> I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. >>> >>> Norbert >>> >>> Dale >>> >>> On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: >>> >>> >>> On 05.03.2011, at 19:52, Dale Henrichs wrote: >>> >>> Norbert, >>> >>> Metacello is intended to work the way that you expect ... >>> >>> Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. >>> >>> From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. >>> >>> If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... >>> >>> I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 >>> for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. >>> The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. >>> >>> If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. >>> >>> You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) >>> >>> Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... >>> >>> The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: >>> >>> ConfigurationOfXMLSupport defines >>> >>> baseline105 >>> - no dependency to ConfigurationOfXMLWriter >>> >>> version105 >>> - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 >>> >>> baseline119 >>> - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) >>> >>> version119 >>> - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 >>> >>> When I load ConfigurationOfXMLSupport version 1.0.5 than the files >>> >>> XML-Parser.g-DaleHenrichs.93 >>> and >>> XML Writer 1.0.4 >>> >>> are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. >>> Maybe it is just the case that newly introduced dependencies are added and get active. >>> >>> Norbert >>> >>> <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> >>> >>> >>> >>> >>> >> > |
Re: How to produce a fixed version?
|
|
Norbert,
In the #gemstone section of ConfigurationOfXMLSupport for 1.1.7, XML-Parser.g-DaleHenrichs.93 was specified. That is the same package that is specified in version 1.0.5, so according to the current version algorithm if XML-Parser.g-DaleHenrichs.93 is present in the image then the 1.1.7 is the current version (latest version). Unfortunately in the baseline for 1.1.7 in the #common section, it is specified that XML-Parser requires: #('XML-Writer' 'Collections-OrderPreservingDictionary' 'Collections-BitmapCharacterSet'), so once the image state changed, the current version changed and once the current version changed, Metacello recognized that XML-Writer and friends needed to be loaded into the image and did so ... My fix was to declare version 1.1.7 #broken for GemStone ... The correct fix would have been to move the XML-Writer requires clause down to the #pharo or #squeakCommon section, but I would do that at the risk of making a typing error and breaking version 1.1.7 Dale On Mar 6, 2011, at 2:01 AM, Norbert Hartl wrote: > > On 06.03.2011, at 05:02, Dale Henrichs wrote: > >> Now that I know the problem, I was able to fix the config ... when I made my pass fixing the xml support config in January, I missed version 1.1.7 and that would explain the why XMLWriter was coming in ... >> > Can you elaborate on this? What went wrong with 1.1.7? > > I changed the load order for testing. I first loaded seaside30 which pulled in xml parser 1.0.5 without xml writer. The later attempt to load 1.0.5 just did nothing. Everything's fine as far as I can see. So I assume that providing a configuration for all my manual loads would have led to the right loading because there would be only one load attempt to an image not containing the xml parser. > > Norbert > >> Dale >> >> On Mar 5, 2011, at 5:45 PM, Norbert Hartl wrote: >> >>> >>> On 06.03.2011, at 02:25, Dale Henrichs wrote: >>> >>>> Okay...so in the end the the question that you are actually asking is "Why is XMLWriter loaded?"... or am I missing something else? >>>> >>> Yep, I want to know why xml writer is loaded. >>> >>>> printing the result of a fetch command should answer that question ... the linear listing in the log file doesn't give you the answer to "which configuration caused XMLWriter to be loaded?" just the order in which they are loaded ... >>>> >>> I'll try tomorrow. As you can see I'm loading a few things one after the other. Should I expect a big difference if I would provide a configuration for the same things? >>> >>>> I'll see if I can figure that out a bit later... >>>> >>> thanks, >>> >>> Norbert >>> >>>> Dale >>>> >>>> On Mar 5, 2011, at 5:06 PM, Norbert Hartl wrote: >>>> >>>> >>>> On 06.03.2011, at 00:00, Dale Henrichs wrote: >>>> >>>> The issue stems from the fact that Metacello needs to determine the currently loaded version of the project: >>>> >>>> if the current version is later than the one requested, nothing is loaded >>>> if the current version is less than the one requiested, the requested version is loaded >>>> >>>> ok >>>> >>>> To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... >>>> >>>> It sounds as though XML is already loaded in your system? Is that correct? >>>> >>>> No, it is just loaded before seaside which triggers the problem. >>>> >>>> If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). >>>> >>>> If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. >>>> >>>> Do you need anything more detailed than you can see in the log? It is pretty much detailed. >>>> In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) >>>> >>>> <CUT> >>>> ---loading glass--- >>>> topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>>> --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>>> --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' >>>> ... >>>> --transcript--'...finished 1.0-beta.8.6' >>>> >>>> ---loading metacello--- >>>> topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' >>>> --transcript--'...finished 1.0-beta.28.3.1' >>>> >>>> ---loading magritte--- >>>> topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' >>>> ... >>>> --transcript--'...finished 2.0.6' >>>> >>>> ---loading xml parser 1.0.5--- >>>> topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' >>>> --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' >>>> --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' >>>> --transcript--'...finished 1.0.5' >>>> >>>> topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' >>>> >>>> ---- loading seaside30 --- >>>> topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' >>>> ... >>>> --transcript--'Project: XML Parser 1.0.5' >>>> --> here 1.0.5 is loaded but the dependency from a later baseline activated >>>> --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>> --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' >>>> --transcript--'Project: XML-Writer 1.0.4' >>>> --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' >>>> --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>> --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>> --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' >>>> --transcript--'Project: Grease Core 1.0-rc' >>>> --transcript--'Project: System-Digital-Signatures 0.238' >>>> --transcript--'Project: XML Parser 1.0.5' >>>> --transcript--'Project: XML-Writer 1.0.4' >>>> --transcript--'Project: Grease Core 1.0-rc' >>>> ... >>>> --transcript--'...finished 3.0.4' >>>> >>>> Hope this helps. If you need anything more or prepared than what you see in the log please let me know. >>>> >>>> As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... >>>> >>>> The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... >>>> >>>> Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: >>>> >>>> >>>> On 05.03.2011, at 21:49, Dale Henrichs wrote: >>>> >>>> Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( >>>> >>>> I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. >>>> >>>> XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... >>>> >>>> Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). >>>> >>>> I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) >>>> >>>> Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. >>>> >>>> I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. >>>> >>>> Norbert >>>> >>>> Dale >>>> >>>> On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: >>>> >>>> >>>> On 05.03.2011, at 19:52, Dale Henrichs wrote: >>>> >>>> Norbert, >>>> >>>> Metacello is intended to work the way that you expect ... >>>> >>>> Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. >>>> >>>> From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. >>>> >>>> If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... >>>> >>>> I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 >>>> for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. >>>> The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. >>>> >>>> If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. >>>> >>>> You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) >>>> >>>> Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... >>>> >>>> The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: >>>> >>>> ConfigurationOfXMLSupport defines >>>> >>>> baseline105 >>>> - no dependency to ConfigurationOfXMLWriter >>>> >>>> version105 >>>> - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 >>>> >>>> baseline119 >>>> - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) >>>> >>>> version119 >>>> - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 >>>> >>>> When I load ConfigurationOfXMLSupport version 1.0.5 than the files >>>> >>>> XML-Parser.g-DaleHenrichs.93 >>>> and >>>> XML Writer 1.0.4 >>>> >>>> are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. >>>> Maybe it is just the case that newly introduced dependencies are added and get active. >>>> >>>> Norbert >>>> >>>> <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> >>>> >>>> >>>> >>>> >>>> >>> >> > |
Re: How to produce a fixed version?
|
|
On 06.03.2011, at 17:48, Dale Henrichs wrote: > Norbert, > > In the #gemstone section of ConfigurationOfXMLSupport for 1.1.7, XML-Parser.g-DaleHenrichs.93 was specified. That is the same package that is specified in version 1.0.5, so according to the current version algorithm if XML-Parser.g-DaleHenrichs.93 is present in the image then the 1.1.7 is the current version (latest version). Unfortunately in the baseline for 1.1.7 in the #common section, it is specified that XML-Parser requires: #('XML-Writer' 'Collections-OrderPreservingDictionary' 'Collections-BitmapCharacterSet'), so once the image state changed, the current version changed and once the current version changed, Metacello recognized that XML-Writer and friends needed to be loaded into the image and did so ... > Ok, now it is clear. I'm really glad there is a good explanation for the behaviour. > My fix was to declare version 1.1.7 #broken for GemStone ... The correct fix would have been to move the XML-Writer requires clause down to the #pharo or #squeakCommon section, but I would do that at the risk of making a typing error and breaking version 1.1.7 > Agreed. As there is 1.1.9 I guess 1.1.7 isn't that important to change a lot. Norbert > Dale > > On Mar 6, 2011, at 2:01 AM, Norbert Hartl wrote: > >> >> On 06.03.2011, at 05:02, Dale Henrichs wrote: >> >>> Now that I know the problem, I was able to fix the config ... when I made my pass fixing the xml support config in January, I missed version 1.1.7 and that would explain the why XMLWriter was coming in ... >>> >> Can you elaborate on this? What went wrong with 1.1.7? >> >> I changed the load order for testing. I first loaded seaside30 which pulled in xml parser 1.0.5 without xml writer. The later attempt to load 1.0.5 just did nothing. Everything's fine as far as I can see. So I assume that providing a configuration for all my manual loads would have led to the right loading because there would be only one load attempt to an image not containing the xml parser. >> >> Norbert >> >>> Dale >>> >>> On Mar 5, 2011, at 5:45 PM, Norbert Hartl wrote: >>> >>>> >>>> On 06.03.2011, at 02:25, Dale Henrichs wrote: >>>> >>>>> Okay...so in the end the the question that you are actually asking is "Why is XMLWriter loaded?"... or am I missing something else? >>>>> >>>> Yep, I want to know why xml writer is loaded. >>>> >>>>> printing the result of a fetch command should answer that question ... the linear listing in the log file doesn't give you the answer to "which configuration caused XMLWriter to be loaded?" just the order in which they are loaded ... >>>>> >>>> I'll try tomorrow. As you can see I'm loading a few things one after the other. Should I expect a big difference if I would provide a configuration for the same things? >>>> >>>>> I'll see if I can figure that out a bit later... >>>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>>> Dale >>>>> >>>>> On Mar 5, 2011, at 5:06 PM, Norbert Hartl wrote: >>>>> >>>>> >>>>> On 06.03.2011, at 00:00, Dale Henrichs wrote: >>>>> >>>>> The issue stems from the fact that Metacello needs to determine the currently loaded version of the project: >>>>> >>>>> if the current version is later than the one requested, nothing is loaded >>>>> if the current version is less than the one requiested, the requested version is loaded >>>>> >>>>> ok >>>>> >>>>> To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... >>>>> >>>>> It sounds as though XML is already loaded in your system? Is that correct? >>>>> >>>>> No, it is just loaded before seaside which triggers the problem. >>>>> >>>>> If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). >>>>> >>>>> If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. >>>>> >>>>> Do you need anything more detailed than you can see in the log? It is pretty much detailed. >>>>> In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) >>>>> >>>>> <CUT> >>>>> ---loading glass--- >>>>> topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>>>> --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>>>> --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' >>>>> ... >>>>> --transcript--'...finished 1.0-beta.8.6' >>>>> >>>>> ---loading metacello--- >>>>> topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' >>>>> --transcript--'...finished 1.0-beta.28.3.1' >>>>> >>>>> ---loading magritte--- >>>>> topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' >>>>> ... >>>>> --transcript--'...finished 2.0.6' >>>>> >>>>> ---loading xml parser 1.0.5--- >>>>> topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' >>>>> --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' >>>>> --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' >>>>> --transcript--'...finished 1.0.5' >>>>> >>>>> topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' >>>>> >>>>> ---- loading seaside30 --- >>>>> topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' >>>>> ... >>>>> --transcript--'Project: XML Parser 1.0.5' >>>>> --> here 1.0.5 is loaded but the dependency from a later baseline activated >>>>> --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>>> --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' >>>>> --transcript--'Project: XML-Writer 1.0.4' >>>>> --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' >>>>> --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>>> --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>>> --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' >>>>> --transcript--'Project: Grease Core 1.0-rc' >>>>> --transcript--'Project: System-Digital-Signatures 0.238' >>>>> --transcript--'Project: XML Parser 1.0.5' >>>>> --transcript--'Project: XML-Writer 1.0.4' >>>>> --transcript--'Project: Grease Core 1.0-rc' >>>>> ... >>>>> --transcript--'...finished 3.0.4' >>>>> >>>>> Hope this helps. If you need anything more or prepared than what you see in the log please let me know. >>>>> >>>>> As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... >>>>> >>>>> The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... >>>>> >>>>> Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. >>>>> >>>>> thanks, >>>>> >>>>> Norbert >>>>> >>>>> On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: >>>>> >>>>> >>>>> On 05.03.2011, at 21:49, Dale Henrichs wrote: >>>>> >>>>> Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( >>>>> >>>>> I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. >>>>> >>>>> XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... >>>>> >>>>> Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). >>>>> >>>>> I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) >>>>> >>>>> Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. >>>>> >>>>> I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. >>>>> >>>>> Norbert >>>>> >>>>> Dale >>>>> >>>>> On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: >>>>> >>>>> >>>>> On 05.03.2011, at 19:52, Dale Henrichs wrote: >>>>> >>>>> Norbert, >>>>> >>>>> Metacello is intended to work the way that you expect ... >>>>> >>>>> Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. >>>>> >>>>> From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. >>>>> >>>>> If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... >>>>> >>>>> I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 >>>>> for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. >>>>> The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. >>>>> >>>>> If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. >>>>> >>>>> You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) >>>>> >>>>> Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... >>>>> >>>>> The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: >>>>> >>>>> ConfigurationOfXMLSupport defines >>>>> >>>>> baseline105 >>>>> - no dependency to ConfigurationOfXMLWriter >>>>> >>>>> version105 >>>>> - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 >>>>> >>>>> baseline119 >>>>> - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) >>>>> >>>>> version119 >>>>> - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 >>>>> >>>>> When I load ConfigurationOfXMLSupport version 1.0.5 than the files >>>>> >>>>> XML-Parser.g-DaleHenrichs.93 >>>>> and >>>>> XML Writer 1.0.4 >>>>> >>>>> are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. >>>>> Maybe it is just the case that newly introduced dependencies are added and get active. >>>>> >>>>> Norbert >>>>> >>>>> <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > |
Re: How to produce a fixed version?
|
|
Exactly, and 1.1.9 was created correctly for GemStone...
Dale On Mar 6, 2011, at 8:55 AM, Norbert Hartl wrote: > > On 06.03.2011, at 17:48, Dale Henrichs wrote: > >> Norbert, >> >> In the #gemstone section of ConfigurationOfXMLSupport for 1.1.7, XML-Parser.g-DaleHenrichs.93 was specified. That is the same package that is specified in version 1.0.5, so according to the current version algorithm if XML-Parser.g-DaleHenrichs.93 is present in the image then the 1.1.7 is the current version (latest version). Unfortunately in the baseline for 1.1.7 in the #common section, it is specified that XML-Parser requires: #('XML-Writer' 'Collections-OrderPreservingDictionary' 'Collections-BitmapCharacterSet'), so once the image state changed, the current version changed and once the current version changed, Metacello recognized that XML-Writer and friends needed to be loaded into the image and did so ... >> > Ok, now it is clear. I'm really glad there is a good explanation for the behaviour. > >> My fix was to declare version 1.1.7 #broken for GemStone ... The correct fix would have been to move the XML-Writer requires clause down to the #pharo or #squeakCommon section, but I would do that at the risk of making a typing error and breaking version 1.1.7 >> > Agreed. As there is 1.1.9 I guess 1.1.7 isn't that important to change a lot. > > Norbert > >> Dale >> >> On Mar 6, 2011, at 2:01 AM, Norbert Hartl wrote: >> >>> >>> On 06.03.2011, at 05:02, Dale Henrichs wrote: >>> >>>> Now that I know the problem, I was able to fix the config ... when I made my pass fixing the xml support config in January, I missed version 1.1.7 and that would explain the why XMLWriter was coming in ... >>>> >>> Can you elaborate on this? What went wrong with 1.1.7? >>> >>> I changed the load order for testing. I first loaded seaside30 which pulled in xml parser 1.0.5 without xml writer. The later attempt to load 1.0.5 just did nothing. Everything's fine as far as I can see. So I assume that providing a configuration for all my manual loads would have led to the right loading because there would be only one load attempt to an image not containing the xml parser. >>> >>> Norbert >>> >>>> Dale >>>> >>>> On Mar 5, 2011, at 5:45 PM, Norbert Hartl wrote: >>>> >>>>> >>>>> On 06.03.2011, at 02:25, Dale Henrichs wrote: >>>>> >>>>>> Okay...so in the end the the question that you are actually asking is "Why is XMLWriter loaded?"... or am I missing something else? >>>>>> >>>>> Yep, I want to know why xml writer is loaded. >>>>> >>>>>> printing the result of a fetch command should answer that question ... the linear listing in the log file doesn't give you the answer to "which configuration caused XMLWriter to be loaded?" just the order in which they are loaded ... >>>>>> >>>>> I'll try tomorrow. As you can see I'm loading a few things one after the other. Should I expect a big difference if I would provide a configuration for the same things? >>>>> >>>>>> I'll see if I can figure that out a bit later... >>>>>> >>>>> thanks, >>>>> >>>>> Norbert >>>>> >>>>>> Dale >>>>>> >>>>>> On Mar 5, 2011, at 5:06 PM, Norbert Hartl wrote: >>>>>> >>>>>> >>>>>> On 06.03.2011, at 00:00, Dale Henrichs wrote: >>>>>> >>>>>> The issue stems from the fact that Metacello needs to determine the currently loaded version of the project: >>>>>> >>>>>> if the current version is later than the one requested, nothing is loaded >>>>>> if the current version is less than the one requiested, the requested version is loaded >>>>>> >>>>>> ok >>>>>> >>>>>> To determine the current version, Metacello traverse all versions in reverse order until it finds a match ... nothing magical ... >>>>>> >>>>>> It sounds as though XML is already loaded in your system? Is that correct? >>>>>> >>>>>> No, it is just loaded before seaside which triggers the problem. >>>>>> >>>>>> If xml is not loaded, a perusal of the load directives should tell you exactly why a later version is being loaded (likely because of the requirements of another project). >>>>>> >>>>>> If xml is already loaded (what's the #currentVersion of XMLSupport before doing your load), then I would like to understand what is leading to the incorrect end result ... sending me a list of the mcz files that are loaded in you image should be enough for me to analyze. >>>>>> >>>>>> Do you need anything more detailed than you can see in the log? It is pretty much detailed. >>>>>> In short this is the excerpt from the log (starting from a virgin 2.4.4.1 extent) >>>>>> >>>>>> <CUT> >>>>>> ---loading glass--- >>>>>> topaz 1> --transcript--'Fetched -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>>>>> --transcript--'Loaded -> ConfigurationOfGLASS-DaleHenrichs.172 --- http://seaside.gemstone.com/ss/MetacelloRepository --- http://seaside.gemstone.com/ss/MetacelloRepository' >>>>>> --transcript--'Loading 1.0-beta.8.6 of ConfigurationOfGLASS...' >>>>>> ... >>>>>> --transcript--'...finished 1.0-beta.8.6' >>>>>> >>>>>> ---loading metacello--- >>>>>> topaz 1> --transcript--'Loading 1.0-beta.28.3.1 of ConfigurationOfMetacello...' >>>>>> --transcript--'...finished 1.0-beta.28.3.1' >>>>>> >>>>>> ---loading magritte--- >>>>>> topaz 1> --transcript--'Loading 2.0.6 of ConfigurationOfMagritte2...' >>>>>> ... >>>>>> --transcript--'...finished 2.0.6' >>>>>> >>>>>> ---loading xml parser 1.0.5--- >>>>>> topaz 1> --transcript--'Loading 1.0.5 of ConfigurationOfXMLSupport...' >>>>>> --transcript--'Fetched -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- http://seaside.gemstone.com/ss/XMLSupport' >>>>>> --transcript--'Loaded -> XML-Parser.g-DaleHenrichs.93 --- http://seaside.gemstone.com/ss/XMLSupport --- cache' >>>>>> --transcript--'...finished 1.0.5' >>>>>> >>>>>> topaz 1> --transcript--'loaded packageMagritte-XMLBinding-NorbertHartl.63' >>>>>> >>>>>> ---- loading seaside30 --- >>>>>> topaz 1> --transcript--'Loading 3.0.4 of ConfigurationOfSeaside30...' >>>>>> ... >>>>>> --transcript--'Project: XML Parser 1.0.5' >>>>>> --> here 1.0.5 is loaded but the dependency from a later baseline activated >>>>>> --transcript--'Fetched -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>>>> --transcript--'Loaded -> ConfigurationOfXMLWriter-dkh.19 --- http://www.squeaksource.com/XMLWriter --- cache' >>>>>> --transcript--'Project: XML-Writer 1.0.4' >>>>>> --transcript--'Fetched -> Collections-OrderPreservingDictionary-JAAyer.6 --- http://www.squeaksource.com/OrderPreservingDict --- http://www.squeaksource.com/OrderPreservingDict' >>>>>> --transcript--'Fetched -> Collections-CharacterSet-JohanBrichau.1 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>>>> --transcript--'Fetched -> XML-Writer-JAAyer.5 --- http://www.squeaksource.com/XMLWriter --- http://www.squeaksource.com/XMLWriter' >>>>>> --transcript--'Fetched -> Collections-BitmapCharacterSet-JAAyer.1 --- http://www.squeaksource.com/BitmapCharacterSet --- http://www.squeaksource.com/BitmapCharacterSet' >>>>>> --transcript--'Project: Grease Core 1.0-rc' >>>>>> --transcript--'Project: System-Digital-Signatures 0.238' >>>>>> --transcript--'Project: XML Parser 1.0.5' >>>>>> --transcript--'Project: XML-Writer 1.0.4' >>>>>> --transcript--'Project: Grease Core 1.0-rc' >>>>>> ... >>>>>> --transcript--'...finished 3.0.4' >>>>>> >>>>>> Hope this helps. If you need anything more or prepared than what you see in the log please let me know. >>>>>> >>>>>> As an aside, just like I have added validation rules to Metacello for every incorrect validation condition that I've seen or heard about, I am now in the process of adding support to the MetacelloBrowser for doing the kinds of analysis that I do manually today ... >>>>>> >>>>>> The thing that makes people think "magic" is involved is that it is difficult to get a good picture of just what Metacello thinks is loaded in the image so I'm hoping to make it possible for folks to see what Metacello thinks is loaded ... and identify the suspicious cases ... if nothing else it is making my life easier, but I need a version of MetacelloBrowser that works in GemStone... >>>>>> >>>>>> Agreed. It is not an easy task and we all appreciate you care ;) If I can provide you with anything that might help than just ask. Otherwise it might be feasible to postpone these things if the MetacelloBrowser is available if you think that helps. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Norbert >>>>>> >>>>>> On Mar 5, 2011, at 1:42 PM, Norbert Hartl wrote: >>>>>> >>>>>> >>>>>> On 05.03.2011, at 21:49, Dale Henrichs wrote: >>>>>> >>>>>> Okay this is enough information for me to try to reproduce ... I didn't realize that you were marking things #broken to get past the problem you were having:( >>>>>> >>>>>> I didn't do. I think you changed that. It appeared to me to be a valid step. Because versions just have been copied advancing every new version of xml parser to be valid for gemstone. And therefor pulling in the new baseline would have been right. Now it is even more clear that there is an old version that was valid and a new version which is also valid. It is just that I want to load the old version and it doesn't do what I expect it to do. The weird case with xml writer just makes a problem visible which cause subtle bugs to be introduced. >>>>>> >>>>>> XML and GemStone is pretty nasty when it comes to the dependency graphs ... XML was in GsMisc, then migrated to a separate XMLSupport configuration then Grease requirements got added (to support a version of XML?) but Grease required other projects in the GsMisc project ... that revealed a loop bug in Metacello that was fixed ... and apparently we aren't done yet ... >>>>>> >>>>>> Yes, I'm guilty, that is right. My first attempt was to make Sixx working with a grease streams to handle encoding issues. The lack of Stream>>cr et al. made me think it is a good idea to change everything to be handled with grease. That lead to make Sixx grease dependent. As we discussed in barcelona we decided that Sixx is best to "just" handle encoding issues internally. But then grease was already introduced as dependency. So it isn't needed when using "normal" streams (whatever that might be). >>>>>> >>>>>> I haven't been able to look at auto detection of "real" dependency loops, but if this isn't a dependency loop, then it might be straightforward to untangle (if my dog would quit whining about my wife being gone:) >>>>>> >>>>>> Pure dog, pure Dale :) I'm just trying to understand the rationale that causes metacello to look for the newest version (if my assumption is right). It appears it could be a case of "too much magic" :) The problem could be solved if a specific version of the configuration could be nailed to the floor. That probably defeats the purpose. But if that's not possible it would be good to be able to detect that any project in between requires something newer that I want. I would consider that a conflict that needs to be solved by a developer. But then I'm lacking serious know how about the whole thing. >>>>>> >>>>>> I could make my life easier by upgrading my project to the newest xml parser. But I like to understand the problem because that appears to me to be an important one. And you won't discover this if you only working with people that only act on the hottest and newest source available. >>>>>> >>>>>> Norbert >>>>>> >>>>>> Dale >>>>>> >>>>>> On Mar 5, 2011, at 11:57 AM, Norbert Hartl wrote: >>>>>> >>>>>> >>>>>> On 05.03.2011, at 19:52, Dale Henrichs wrote: >>>>>> >>>>>> Norbert, >>>>>> >>>>>> Metacello is intended to work the way that you expect ... >>>>>> >>>>>> Ok, I'm glad to here that. And sorry for the lack of information. I was just clueless ans so I asked generally at first. >>>>>> >>>>>> From your explanation this is either a known bug that is fixed (you're using an older version of Metacello) or a new bug (no explicit dependency loop?) that I'd like to examine. >>>>>> >>>>>> If I could have a few more details: which version of Pharo or GemStone(?) are using, which version of Metacello, the mcz package version of xml that you are starting with and what you are trying to load ... >>>>>> >>>>>> I'm using gemstone 2.4.4.1. My build script fetches the latest stuff when being run. So it is 1.0-beta.8.6 for glass and 1.0-beta.28.3.1 >>>>>> for metacello. The script I used to create the image (based on a virgin extent) is attached as script.st. The log of hudson is also attached. From there the transcript log lines are visible. >>>>>> The most important question to me is why is XML-Writer 1.0.4 being loaded. I think all of my problems are rooted there. >>>>>> >>>>>> If you want to insulate yourself from unknown errors being triggered by innocent (or not so innocent) changes to configurations (or even mcz files disappearing from projects or entire servers disappearing) in the future, your best bet is to use git or svn to archive known sets of mcz files including configurations from which you can always be guarantted to build your product. >>>>>> >>>>>> You are right. That would be a safe bet but also a cumbersome one. I think we all are heading for the soft safe bet :) I like metacello for being able to specify product main versions as dependencies to my own project. That means I like to work on seaside3 for my product but I want to have automatic updates from 3.0.3 to 3.0.4. The frozen approach (copying all mczs ...) does not make this possible. I did this the last years in generating images from a fixed set of individual software versions. It works. The biggest problem is that I have to know the (internal) dependencies of that software project I'm using. Otherwise I couldn't upgrade reliably all of the affected packages. Exactly this is it what I don't like from my prior approach. Ok, I know metacello will ease this even in the frozen approach (providing the increments) >>>>>> >>>>>> Also could you refresh my memory about which gemstone email you are referring to? I went back over the mailing list and I it seems to me that the last messages and it looked to me that all of your issues were resolved ... >>>>>> >>>>>> The thread is called "Problems generating images automatically". The issue was solved temporarily. I wasn't sure about that last time. In both cases it looked like I depend on an older version and it works as long as there is no new release/stable version. The last fix was to mark all gemstone versions broken. In the meantime Otto and Johan provided a new release version of xml parser and the problem is back. Again, it appears that I depend on xml parser 1.0.5 but metacello looks itself for a newer version. If there is a new version with an updated baseline those new dependencies (from the new baseline) get activated. I don't know this exactly but the case to me is at least this one: >>>>>> >>>>>> ConfigurationOfXMLSupport defines >>>>>> >>>>>> baseline105 >>>>>> - no dependency to ConfigurationOfXMLWriter >>>>>> >>>>>> version105 >>>>>> - depends on baseline105. Depends on XML-Parser.g-DaleHenrichs.93 >>>>>> >>>>>> baseline119 >>>>>> - depends on ConfigurationOfXMLWriter (leads to XML Writer 1.0.4 being loaded) >>>>>> >>>>>> version119 >>>>>> - depends on baseline119. Depends on XML-Parser-OttoBehrens.134 >>>>>> >>>>>> When I load ConfigurationOfXMLSupport version 1.0.5 than the files >>>>>> >>>>>> XML-Parser.g-DaleHenrichs.93 >>>>>> and >>>>>> XML Writer 1.0.4 >>>>>> >>>>>> are being loaded. Well, it is not loaded if I do the ConfigurationOfXMLSupport step manually. At the point I load seaside it is activated through some dependeny in (I think) GsCore or GsMisc. You can see it in the log. >>>>>> Maybe it is just the case that newly introduced dependencies are added and get active. >>>>>> >>>>>> Norbert >>>>>> >>>>>> <test22-build-log.txt><ATT00001..htm><script.st><ATT00002..htm> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |