help wanted :)
Locked
 
|
Hi,
I have troubles understanding recent behavior in Metacello. I am using the version that ships with the latest Pharo dev. The trouble appears when trying to load Moose. It hangs probably because of circular dependencies between SmallDude and Moose. The reason for the cyclic dependency is the following: - Moose Suite needs to include SmallDude - SmallDude needs Moose Core Originally, I created a 'Core' group in the default version of Moose and had SmallDude depend on it. It worked for a while, but then it stopped working. I then created a coreDefault version in Moose that only loads the Core packages, and made SmallDude default depend on Moose coreDefault. I tried loading only SmallDude, and it still hangs and I have no idea why. If you want to try you can do it via: Gofer new squeaksource: 'SmallDude'; package: 'ConfigurationOfSmallDude'; load. (Smalltalk at: #ConfigurationOfSmallDude) perform: #loadDefault. The curious thing is that when debugging, the stack shows me versions it should not. I am trying to load the default version, but when I try to debug where it hangs the stack shows me version numbers other than default. Is it possible that Metacello tries to reify all versions before getting to the one specified? Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." |
|
|
On 02/21/2011 12:50 AM, Tudor Girba wrote:
> Hi, > > I have troubles understanding recent behavior in Metacello. I am > using the version that ships with the latest Pharo dev. > > The trouble appears when trying to load Moose. It hangs probably > because of circular dependencies between SmallDude and Moose. The > reason for the cyclic dependency is the following: - Moose Suite > needs to include SmallDude - SmallDude needs Moose Core > > Originally, I created a 'Core' group in the default version of Moose > and had SmallDude depend on it. It worked for a while, but then it > stopped working. > > I then created a coreDefault version in Moose that only loads the > Core packages, and made SmallDude default depend on Moose > coreDefault. > > I tried loading only SmallDude, and it still hangs and I have no idea > why. > > If you want to try you can do it via: Gofer new squeaksource: > 'SmallDude'; package: 'ConfigurationOfSmallDude'; load. (Smalltalk > at: #ConfigurationOfSmallDude) perform: #loadDefault. > > The curious thing is that when debugging, the stack shows me versions > it should not. I am trying to load the default version, but when I > try to debug where it hangs the stack shows me version numbers other > than default. > > Is it possible that Metacello tries to reify all versions before > getting to the one specified? > > Cheers, Doru > > > -- www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > Doru, This sounds similar a bug that I've seen before (and fixed in earlier versions), so I'd like to know exactly which version of Pharo you are using .... also to reproduce the problem it helps to know the exact version involved ... It's possible that you are seeing a different strain of the same bug ... I'm just guessing at this point, but the bug is probably related to the fact that while you expect the scope of the dependency to be limited to a particular group of mcz files, Metacello doesn't share that scoping definition, so your attempt to reduce the scope of the cyclic dependency by using a group doesn't eliminate the potential for the cyclic dependency ... The "workaround" in this case would be to try defining a 'Moose Core' configuration ... this would allow you to break the dependency cycle and get things loaded ... I'd want to study this in detail (unfortunately I'm really slammed at the moment), so a reproducable test case would be really useful ... the longer term solution (if a separate configuration is not acceptable) would be to propogate groups as first class objects into the load process, so that cycles are detected/bypassed at a finer level than is currently implemented... Dale |
|
|
Hi Dale,
Here is how to reproduce: 1. download pharo: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/149/artifact/Pharo-1.2/*zip*/Pharo-1.2.zip 2. execute: Gofer new squeaksource: 'SmallDude'; package: 'ConfigurationOfSmallDude'; load. (Smalltalk at: #ConfigurationOfSmallDude) perform: #loadDefault. Here is how it gets even more interesting: - I added ConfigurationOfMoose>>coreDefault: - made SmallDude depend on this one, rather than on default - even commented out the rest of ConfigurationOfMoose>>default so that it does not load SmallDude anymore. - and it still ends up looping. Cheers, Doru On 22 Feb 2011, at 19:08, Dale Henrichs wrote: > On 02/21/2011 12:50 AM, Tudor Girba wrote: >> Hi, >> >> I have troubles understanding recent behavior in Metacello. I am >> using the version that ships with the latest Pharo dev. >> >> The trouble appears when trying to load Moose. It hangs probably >> because of circular dependencies between SmallDude and Moose. The >> reason for the cyclic dependency is the following: - Moose Suite >> needs to include SmallDude - SmallDude needs Moose Core >> >> Originally, I created a 'Core' group in the default version of Moose >> and had SmallDude depend on it. It worked for a while, but then it >> stopped working. >> >> I then created a coreDefault version in Moose that only loads the >> Core packages, and made SmallDude default depend on Moose >> coreDefault. >> >> I tried loading only SmallDude, and it still hangs and I have no idea >> why. >> >> If you want to try you can do it via: Gofer new squeaksource: >> 'SmallDude'; package: 'ConfigurationOfSmallDude'; load. (Smalltalk >> at: #ConfigurationOfSmallDude) perform: #loadDefault. >> >> The curious thing is that when debugging, the stack shows me versions >> it should not. I am trying to load the default version, but when I >> try to debug where it hangs the stack shows me version numbers other >> than default. >> >> Is it possible that Metacello tries to reify all versions before >> getting to the one specified? >> >> Cheers, Doru >> >> >> -- www.tudorgirba.com >> >> "It's not what we do that matters most, it's how we do it." >> > > Doru, > > This sounds similar a bug that I've seen before (and fixed in earlier > versions), so I'd like to know exactly which version of Pharo you are > using .... also to reproduce the problem it helps to know the exact > version involved ... It's possible that you are seeing a different strain of the same bug ... > > I'm just guessing at this point, but the bug is probably related to the fact that while you expect the scope of the dependency to be limited to a particular group of mcz files, Metacello doesn't share that scoping definition, so your attempt to reduce the scope of the cyclic dependency by using a group doesn't eliminate the potential for the cyclic dependency ... > > The "workaround" in this case would be to try defining a 'Moose Core' configuration ... this would allow you to break the dependency cycle and get things loaded ... > > I'd want to study this in detail (unfortunately I'm really slammed at the moment), so a reproducable test case would be really useful ... the longer term solution (if a separate configuration is not acceptable) would be to propogate groups as first class objects into the load process, so that cycles are detected/bypassed at a finer level than is currently implemented... > > Dale -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." |
|
|
Doru,
When you say it ends up looping, do you mean a load loop (like I thought you meant) or do you mean a hard, uninterruptible loop of some kind ... When I try to reproduce your problem, I get a hard uninterruptible loop ... if this is what you are asking about, then my response would be ... does it reproduce on Pharo1.1.1 or Pharo1.0? I can't even get a stack trace... Dale On 02/22/2011 12:35 PM, Tudor Girba wrote: > Hi Dale, > > Here is how to reproduce: > > 1. download pharo: > https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/149/artifact/Pharo-1.2/*zip*/Pharo-1.2.zip > > 2. execute: > Gofer new > squeaksource: 'SmallDude'; > package: 'ConfigurationOfSmallDude'; > load. > > (Smalltalk at: #ConfigurationOfSmallDude) perform: #loadDefault. > > > Here is how it gets even more interesting: > - I added ConfigurationOfMoose>>coreDefault: > - made SmallDude depend on this one, rather than on default > - even commented out the rest of ConfigurationOfMoose>>default so that it does not load SmallDude anymore. > - and it still ends up looping. > > Cheers, > Doru > > > On 22 Feb 2011, at 19:08, Dale Henrichs wrote: > >> On 02/21/2011 12:50 AM, Tudor Girba wrote: >>> Hi, >>> >>> I have troubles understanding recent behavior in Metacello. I am >>> using the version that ships with the latest Pharo dev. >>> >>> The trouble appears when trying to load Moose. It hangs probably >>> because of circular dependencies between SmallDude and Moose. The >>> reason for the cyclic dependency is the following: - Moose Suite >>> needs to include SmallDude - SmallDude needs Moose Core >>> >>> Originally, I created a 'Core' group in the default version of Moose >>> and had SmallDude depend on it. It worked for a while, but then it >>> stopped working. >>> >>> I then created a coreDefault version in Moose that only loads the >>> Core packages, and made SmallDude default depend on Moose >>> coreDefault. >>> >>> I tried loading only SmallDude, and it still hangs and I have no idea >>> why. >>> >>> If you want to try you can do it via: Gofer new squeaksource: >>> 'SmallDude'; package: 'ConfigurationOfSmallDude'; load. (Smalltalk >>> at: #ConfigurationOfSmallDude) perform: #loadDefault. >>> >>> The curious thing is that when debugging, the stack shows me versions >>> it should not. I am trying to load the default version, but when I >>> try to debug where it hangs the stack shows me version numbers other >>> than default. >>> >>> Is it possible that Metacello tries to reify all versions before >>> getting to the one specified? >>> >>> Cheers, Doru >>> >>> >>> -- www.tudorgirba.com >>> >>> "It's not what we do that matters most, it's how we do it." >>> >> >> Doru, >> >> This sounds similar a bug that I've seen before (and fixed in earlier >> versions), so I'd like to know exactly which version of Pharo you are >> using .... also to reproduce the problem it helps to know the exact >> version involved ... It's possible that you are seeing a different strain of the same bug ... >> >> I'm just guessing at this point, but the bug is probably related to the fact that while you expect the scope of the dependency to be limited to a particular group of mcz files, Metacello doesn't share that scoping definition, so your attempt to reduce the scope of the cyclic dependency by using a group doesn't eliminate the potential for the cyclic dependency ... >> >> The "workaround" in this case would be to try defining a 'Moose Core' configuration ... this would allow you to break the dependency cycle and get things loaded ... >> >> I'd want to study this in detail (unfortunately I'm really slammed at the moment), so a reproducable test case would be really useful ... the longer term solution (if a separate configuration is not acceptable) would be to propogate groups as first class objects into the load process, so that cycles are detected/bypassed at a finer level than is currently implemented... >> >> Dale > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > |
|
|
On 02/22/2011 02:48 PM, Dale Henrichs wrote:
> Doru, > > When you say it ends up looping, do you mean a load loop (like I thought > you meant) or do you mean a hard, uninterruptible loop of some kind ... > When I try to reproduce your problem, I get a hard uninterruptible loop > ... if this is what you are asking about, then my response would be ... > does it reproduce on Pharo1.1.1 or Pharo1.0? > > I can't even get a stack trace... > > Dale I guess I will answer my own questions: 1. it goes into a very tight loop 2. in Pharo1.0 I am able to get a stack trace This is obviously a non-detected loop ... not the load loop that I am familiar with ... At least I have it under a debugger ... Pharo1.2 goes into infinite debugger hell when I try to interrupt the process ... Dale |
|
|
In reply to this post by Tudor Girba
Hi haven't tracked it all down or tried very much, and I definitely
don't have a way to prevent future loops, but I used this expression to trigger the tight loop: ConfigurationOfSmallDude project currentVersion. and was able to determine that version 4.3.2 was causing the problem In #version432: if you change project: 'SmallDude for Moose' with: 'default'; to: project: 'SmallDude for Moose' with: '2.0-beta.7'; the loop terminates (quickly) ... I assume that anything but 'default' (or any of the baseline versions that have a SmallDude loop) will work ... presumably you added the 'Moose Core' stuff to break the loop in default but version 4.3.2 explicitly referenced 'default' so when you eventually changed 'default' to be something different version 4.3.2 was a time bomb ready to go off:) So eventually I expect to have a loop detector and possibly a validator rule to try to detect and provide detailed loop info ... Dale On 02/22/2011 12:35 PM, Tudor Girba wrote: > Hi Dale, > > Here is how to reproduce: > > 1. download pharo: > https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/149/artifact/Pharo-1.2/*zip*/Pharo-1.2.zip > > 2. execute: > Gofer new > squeaksource: 'SmallDude'; > package: 'ConfigurationOfSmallDude'; > load. > > (Smalltalk at: #ConfigurationOfSmallDude) perform: #loadDefault. > > > Here is how it gets even more interesting: > - I added ConfigurationOfMoose>>coreDefault: > - made SmallDude depend on this one, rather than on default > - even commented out the rest of ConfigurationOfMoose>>default so that it does not load SmallDude anymore. > - and it still ends up looping. > > Cheers, > Doru > > > On 22 Feb 2011, at 19:08, Dale Henrichs wrote: > >> On 02/21/2011 12:50 AM, Tudor Girba wrote: >>> Hi, >>> >>> I have troubles understanding recent behavior in Metacello. I am >>> using the version that ships with the latest Pharo dev. >>> >>> The trouble appears when trying to load Moose. It hangs probably >>> because of circular dependencies between SmallDude and Moose. The >>> reason for the cyclic dependency is the following: - Moose Suite >>> needs to include SmallDude - SmallDude needs Moose Core >>> >>> Originally, I created a 'Core' group in the default version of Moose >>> and had SmallDude depend on it. It worked for a while, but then it >>> stopped working. >>> >>> I then created a coreDefault version in Moose that only loads the >>> Core packages, and made SmallDude default depend on Moose >>> coreDefault. >>> >>> I tried loading only SmallDude, and it still hangs and I have no idea >>> why. >>> >>> If you want to try you can do it via: Gofer new squeaksource: >>> 'SmallDude'; package: 'ConfigurationOfSmallDude'; load. (Smalltalk >>> at: #ConfigurationOfSmallDude) perform: #loadDefault. >>> >>> The curious thing is that when debugging, the stack shows me versions >>> it should not. I am trying to load the default version, but when I >>> try to debug where it hangs the stack shows me version numbers other >>> than default. >>> >>> Is it possible that Metacello tries to reify all versions before >>> getting to the one specified? >>> >>> Cheers, Doru >>> >>> >>> -- www.tudorgirba.com >>> >>> "It's not what we do that matters most, it's how we do it." >>> >> >> Doru, >> >> This sounds similar a bug that I've seen before (and fixed in earlier >> versions), so I'd like to know exactly which version of Pharo you are >> using .... also to reproduce the problem it helps to know the exact >> version involved ... It's possible that you are seeing a different strain of the same bug ... >> >> I'm just guessing at this point, but the bug is probably related to the fact that while you expect the scope of the dependency to be limited to a particular group of mcz files, Metacello doesn't share that scoping definition, so your attempt to reduce the scope of the cyclic dependency by using a group doesn't eliminate the potential for the cyclic dependency ... >> >> The "workaround" in this case would be to try defining a 'Moose Core' configuration ... this would allow you to break the dependency cycle and get things loaded ... >> >> I'd want to study this in detail (unfortunately I'm really slammed at the moment), so a reproducable test case would be really useful ... the longer term solution (if a separate configuration is not acceptable) would be to propogate groups as first class objects into the load process, so that cycles are detected/bypassed at a finer level than is currently implemented... >> >> Dale > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > |
|
|
Hi Dale,
I am sorry for the lack of reply, but I was a bit pressed on time. Thanks a lot for trying this. I thought of something like this happening. Now, I have two issues I do not understand: - In SmallDude, default only references ConfigurationOfMoose coreDefault but not the ConfigurationOfMoose default, so I do not understand where the loop comes from. In ConfigurationOfMoose default everything is commented except for forwarding to coreDefault, so I still do not understand where the problem is :) - Why is it that if I refer to 'default' I have problems in another version 4.3.2? It looks like this means that somehow all(?) versions in a configuration get reified by simply referring to one version. Is this not dangerous? Cheers, Doru On 25 Feb 2011, at 01:25, Dale Henrichs wrote: > Hi haven't tracked it all down or tried very much, and I definitely don't have a way to prevent future loops, but I used this expression to trigger the tight loop: > > ConfigurationOfSmallDude project currentVersion. > > and was able to determine that version 4.3.2 was causing the problem > > In #version432: if you change > > project: 'SmallDude for Moose' with: 'default'; > > to: > > project: 'SmallDude for Moose' with: '2.0-beta.7'; > > the loop terminates (quickly) ... I assume that anything but 'default' (or any of the baseline versions that have a SmallDude loop) will work ... presumably you added the 'Moose Core' stuff to break the loop in default but version 4.3.2 explicitly referenced 'default' so when you eventually changed 'default' to be something different version 4.3.2 was a time bomb ready to go off:) > > So eventually I expect to have a loop detector and possibly a validator rule to try to detect and provide detailed loop info ... > > Dale > > On 02/22/2011 12:35 PM, Tudor Girba wrote: >> Hi Dale, >> >> Here is how to reproduce: >> >> 1. download pharo: >> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/149/artifact/Pharo-1.2/*zip*/Pharo-1.2.zip >> >> 2. execute: >> Gofer new >> squeaksource: 'SmallDude'; >> package: 'ConfigurationOfSmallDude'; >> load. >> >> (Smalltalk at: #ConfigurationOfSmallDude) perform: #loadDefault. >> >> >> Here is how it gets even more interesting: >> - I added ConfigurationOfMoose>>coreDefault: >> - made SmallDude depend on this one, rather than on default >> - even commented out the rest of ConfigurationOfMoose>>default so that it does not load SmallDude anymore. >> - and it still ends up looping. >> >> Cheers, >> Doru >> >> >> On 22 Feb 2011, at 19:08, Dale Henrichs wrote: >> >>> On 02/21/2011 12:50 AM, Tudor Girba wrote: >>>> Hi, >>>> >>>> I have troubles understanding recent behavior in Metacello. I am >>>> using the version that ships with the latest Pharo dev. >>>> >>>> The trouble appears when trying to load Moose. It hangs probably >>>> because of circular dependencies between SmallDude and Moose. The >>>> reason for the cyclic dependency is the following: - Moose Suite >>>> needs to include SmallDude - SmallDude needs Moose Core >>>> >>>> Originally, I created a 'Core' group in the default version of Moose >>>> and had SmallDude depend on it. It worked for a while, but then it >>>> stopped working. >>>> >>>> I then created a coreDefault version in Moose that only loads the >>>> Core packages, and made SmallDude default depend on Moose >>>> coreDefault. >>>> >>>> I tried loading only SmallDude, and it still hangs and I have no idea >>>> why. >>>> >>>> If you want to try you can do it via: Gofer new squeaksource: >>>> 'SmallDude'; package: 'ConfigurationOfSmallDude'; load. (Smalltalk >>>> at: #ConfigurationOfSmallDude) perform: #loadDefault. >>>> >>>> The curious thing is that when debugging, the stack shows me versions >>>> it should not. I am trying to load the default version, but when I >>>> try to debug where it hangs the stack shows me version numbers other >>>> than default. >>>> >>>> Is it possible that Metacello tries to reify all versions before >>>> getting to the one specified? >>>> >>>> Cheers, Doru >>>> >>>> >>>> -- www.tudorgirba.com >>>> >>>> "It's not what we do that matters most, it's how we do it." >>>> >>> >>> Doru, >>> >>> This sounds similar a bug that I've seen before (and fixed in earlier >>> versions), so I'd like to know exactly which version of Pharo you are >>> using .... also to reproduce the problem it helps to know the exact >>> version involved ... It's possible that you are seeing a different strain of the same bug ... >>> >>> I'm just guessing at this point, but the bug is probably related to the fact that while you expect the scope of the dependency to be limited to a particular group of mcz files, Metacello doesn't share that scoping definition, so your attempt to reduce the scope of the cyclic dependency by using a group doesn't eliminate the potential for the cyclic dependency ... >>> >>> The "workaround" in this case would be to try defining a 'Moose Core' configuration ... this would allow you to break the dependency cycle and get things loaded ... >>> >>> I'd want to study this in detail (unfortunately I'm really slammed at the moment), so a reproducable test case would be really useful ... the longer term solution (if a separate configuration is not acceptable) would be to propogate groups as first class objects into the load process, so that cycles are detected/bypassed at a finer level than is currently implemented... >>> >>> Dale >> >> -- >> www.tudorgirba.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> > -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." |
|
|
Hey Doru,
I'm busy too, but I interpreted the lack of response as "ah we figured it out" until Alexandre mentioned that you guys were still nailed by the problem... "I do not understand where the loop comes from" I've already mentioned that Metacello considers dependencies between configurations, so as far as Metacello is consider you have a dependency loop.... I understand that you have tried to define things to work around the dependency loop. if it's any consolation, setting the blessing of Moose 4.3.2 to #broken causes `ConfigurationOfSmallDude project currentVersion` terminates without looping...so this is probably your best bet at moving forward again. If it helps, I _am_ sorry. "Is this not dangerous" I don't think so. Sending the message #project to a configuration happens to instantiate all of the version specifications in the configuration so all of the versions in a configuration are reified from the get go ... reifying the versions is not the source of the bug. There _is_ a dependency loop between version Moose 4.3.2 and SmallDude default (upon further analysis it looks like Moose 4.2 might have a dependency loop, too). So this version is a trap waiting to be sprung. I consider a dependency loop in a configuration to be a configuration error and my expectations are that the validator would detect loops. It is also my expectation that Metacello not go into infinite loops when an invalid configuration is encountered and I've submitted a bug (see Issue 114: http://code.google.com/p/metacello/issues/detail?id=114). Soooo if you consider bugs, "dangerous" then I will have to agree. The bug is actually occurring while an attempt is made to determine what version of SmallDude is currently installed and that is done by looking at each version defined within the configuration and then seeing if the specification in the version matches the packages and projects that are loaded in the image. This is a perfectly reasonable thing to do and in the absence of bugs is not dangerous. In the case where the project is not loaded, all version specs in a configuration will be traversed. _The state of the image is not being affected._ There's nothing dangerous going on. It is going to take a bit of work to characterize this puppy as my initial attempts at loop detection aren't making the grade:) Dale On 02/25/2011 09:49 AM, Tudor Girba wrote: > Hi Dale, > > I am sorry for the lack of reply, but I was a bit pressed on time. > > Thanks a lot for trying this. > > I thought of something like this happening. Now, I have two issues I > do not understand: - In SmallDude, default only references > ConfigurationOfMoose coreDefault but not the ConfigurationOfMoose > default, so I do not understand where the loop comes from. In > ConfigurationOfMoose default everything is commented except for > forwarding to coreDefault, so I still do not understand where the > problem is :) - Why is it that if I refer to 'default' I have > problems in another version 4.3.2? It looks like this means that > somehow all(?) versions in a configuration get reified by simply > referring to one version. Is this not dangerous? > > Cheers, Doru |
|
|
Hi Dale,
On 25 Feb 2011, at 22:33, Dale Henrichs wrote: > Hey Doru, > > I'm busy too, but I interpreted the lack of response as "ah we figured it out" until Alexandre mentioned that you guys were still nailed by the problem... Sorry for this. There were just a couple of crazy days and I needed to focus on something else. I should be more responsive now :) > "I do not understand where the loop comes from" > > I've already mentioned that Metacello considers dependencies between configurations, so as far as Metacello is consider you have a dependency loop.... I understand, but ... I follow below :) > I understand that you have tried to define things to work around the dependency loop. if it's any consolation, setting the blessing of Moose 4.3.2 to #broken causes `ConfigurationOfSmallDude project currentVersion` terminates without looping...so this is probably your best bet at moving forward again. > If it helps, I _am_ sorry. Why are you sorry? You are doing a great job :) > "Is this not dangerous" > > I don't think so. > > Sending the message #project to a configuration happens to instantiate all of the version specifications in the configuration so all of the versions in a configuration are reified from the get go ... reifying the versions is not the source of the bug. > > There _is_ a dependency loop between version Moose 4.3.2 and SmallDude default (upon further analysis it looks like Moose 4.2 might have a dependency loop, too). So this version is a trap waiting to be sprung. > > I consider a dependency loop in a configuration to be a configuration error and my expectations are that the validator would detect loops. It is also my expectation that Metacello not go into infinite loops when an invalid configuration is encountered and I've submitted a bug (see Issue 114: http://code.google.com/p/metacello/issues/detail?id=114). > Soooo if you consider bugs, "dangerous" then I will have to agree. > > The bug is actually occurring while an attempt is made to determine what version of SmallDude is currently installed and that is done by looking at each version defined within the configuration and then seeing if the specification in the version matches the packages and projects that are loaded in the image. This is a perfectly reasonable thing to do and in the absence of bugs is not dangerous. In the case where the project is not loaded, all version specs in a configuration will be traversed. > > _The state of the image is not being affected._ > > There's nothing dangerous going on. Let me explain a bit what I wanted to say. As I see it, we have distinct expectations. There is definitely a problem in our configuration and that needs fixing. No question about it. Actually, thanks a lot for finding where the problem is. It looks like the problem actually was generated by the MetacelloBrowser :) However, when I write something like this: ((Smalltalk at: #ConfigurationOfSmallDude) project version: 'default') load. I expect it to load that exact version, and not raise issues with other unrelated versions. This is similar to the expectation related to loading a version of a package from a versioning system: it should raise only errors related to that version, and not to the rest of them. So, when I said "dangerous" I meant it is dangerous because things might become unloadable because of unrelated versions even if they are perfectly ok in themselves. I find this difficult to handle. Now a couple questions: - Why do we need the project to reify all these versions at creation time? Is it not possible (and even better?) to reify the versions only on demand? - Or, if creating a project "happens to instantiate all of the version specifications", is there a way to get and depend on the version I want without going through the fully reified project? Cheers, Doru > It is going to take a bit of work to characterize this puppy as my initial attempts at loop detection aren't making the grade:) > > Dale > > > On 02/25/2011 09:49 AM, Tudor Girba wrote: >> Hi Dale, >> >> I am sorry for the lack of reply, but I was a bit pressed on time. >> >> Thanks a lot for trying this. >> >> I thought of something like this happening. Now, I have two issues I >> do not understand: - In SmallDude, default only references >> ConfigurationOfMoose coreDefault but not the ConfigurationOfMoose >> default, so I do not understand where the loop comes from. In >> ConfigurationOfMoose default everything is commented except for >> forwarding to coreDefault, so I still do not understand where the >> problem is :) - Why is it that if I refer to 'default' I have >> problems in another version 4.3.2? It looks like this means that >> somehow all(?) versions in a configuration get reified by simply >> referring to one version. Is this not dangerous? >> >> Cheers, Doru > -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef." |
|
|
Hi again,
I just wanted to let you know that marked as broken the 4.3* versions of Moose and 2.* versions of SmallDude and Moose default loads just fine now. Nevertheless, I still maintain that instantiating all versions when creating a project is not a desired behavior :) Cheers, Doru On 25 Feb 2011, at 22:55, Tudor Girba wrote: > Hi Dale, > > On 25 Feb 2011, at 22:33, Dale Henrichs wrote: > >> Hey Doru, >> >> I'm busy too, but I interpreted the lack of response as "ah we figured it out" until Alexandre mentioned that you guys were still nailed by the problem... > > Sorry for this. There were just a couple of crazy days and I needed to focus on something else. I should be more responsive now :) > >> "I do not understand where the loop comes from" >> >> I've already mentioned that Metacello considers dependencies between configurations, so as far as Metacello is consider you have a dependency loop.... > > I understand, but ... I follow below :) > >> I understand that you have tried to define things to work around the dependency loop. if it's any consolation, setting the blessing of Moose 4.3.2 to #broken causes `ConfigurationOfSmallDude project currentVersion` terminates without looping...so this is probably your best bet at moving forward again. > > > >> If it helps, I _am_ sorry. > > Why are you sorry? You are doing a great job :) > >> "Is this not dangerous" >> >> I don't think so. >> >> Sending the message #project to a configuration happens to instantiate all of the version specifications in the configuration so all of the versions in a configuration are reified from the get go ... reifying the versions is not the source of the bug. >> >> There _is_ a dependency loop between version Moose 4.3.2 and SmallDude default (upon further analysis it looks like Moose 4.2 might have a dependency loop, too). So this version is a trap waiting to be sprung. >> >> I consider a dependency loop in a configuration to be a configuration error and my expectations are that the validator would detect loops. It is also my expectation that Metacello not go into infinite loops when an invalid configuration is encountered and I've submitted a bug (see Issue 114: http://code.google.com/p/metacello/issues/detail?id=114). >> Soooo if you consider bugs, "dangerous" then I will have to agree. >> >> The bug is actually occurring while an attempt is made to determine what version of SmallDude is currently installed and that is done by looking at each version defined within the configuration and then seeing if the specification in the version matches the packages and projects that are loaded in the image. This is a perfectly reasonable thing to do and in the absence of bugs is not dangerous. In the case where the project is not loaded, all version specs in a configuration will be traversed. >> >> _The state of the image is not being affected._ >> >> There's nothing dangerous going on. > > Let me explain a bit what I wanted to say. As I see it, we have distinct expectations. There is definitely a problem in our configuration and that needs fixing. No question about it. Actually, thanks a lot for finding where the problem is. It looks like the problem actually was generated by the MetacelloBrowser :) > > However, when I write something like this: > ((Smalltalk at: #ConfigurationOfSmallDude) project version: 'default') load. > > I expect it to load that exact version, and not raise issues with other unrelated versions. This is similar to the expectation related to loading a version of a package from a versioning system: it should raise only errors related to that version, and not to the rest of them. > > So, when I said "dangerous" I meant it is dangerous because things might become unloadable because of unrelated versions even if they are perfectly ok in themselves. I find this difficult to handle. > > Now a couple questions: > - Why do we need the project to reify all these versions at creation time? Is it not possible (and even better?) to reify the versions only on demand? > - Or, if creating a project "happens to instantiate all of the version specifications", is there a way to get and depend on the version I want without going through the fully reified project? > > Cheers, > Doru > > >> It is going to take a bit of work to characterize this puppy as my initial attempts at loop detection aren't making the grade:) >> >> Dale >> >> >> On 02/25/2011 09:49 AM, Tudor Girba wrote: >>> Hi Dale, >>> >>> I am sorry for the lack of reply, but I was a bit pressed on time. >>> >>> Thanks a lot for trying this. >>> >>> I thought of something like this happening. Now, I have two issues I >>> do not understand: - In SmallDude, default only references >>> ConfigurationOfMoose coreDefault but not the ConfigurationOfMoose >>> default, so I do not understand where the loop comes from. In >>> ConfigurationOfMoose default everything is commented except for >>> forwarding to coreDefault, so I still do not understand where the >>> problem is :) - Why is it that if I refer to 'default' I have >>> problems in another version 4.3.2? It looks like this means that >>> somehow all(?) versions in a configuration get reified by simply >>> referring to one version. Is this not dangerous? >>> >>> Cheers, Doru >> > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > -- www.tudorgirba.com "Some battles are better lost than fought." |
|
|
In reply to this post by Tudor Girba
On 02/25/2011 01:55 PM, Tudor Girba wrote:
> > Let me explain a bit what I wanted to say. As I see it, we have > distinct expectations. There is definitely a problem in our > configuration and that needs fixing. No question about it. Actually, > thanks a lot for finding where the problem is. It looks like the > problem actually was generated by the MetacelloBrowser :) > > However, when I write something like this: ((Smalltalk at: > #ConfigurationOfSmallDude) project version: 'default') load. > > I expect it to load that exact version, and not raise issues with > other unrelated versions. This is similar to the expectation related > to loading a version of a package from a versioning system: it should > raise only errors related to that version, and not to the rest of > them. Agree 100% > > So, when I said "dangerous" I meant it is dangerous because things > might become unloadable because of unrelated versions even if they > are perfectly ok in themselves. I find this difficult to handle. Agree 100%. I understand that you are frustrated that due to a bug in Metacello your work came to a screeching halt ... I said I am sorry... I realize that every time I make a release I could cause trouble for a whole lot of folks out there, so I try to be as diligent as possible to keep Metacello stable. > > Now a couple questions: > - Why do we need the project to reify all these versions at creation > time? Is it not possible (and even better?) to reify the versions > only on demand? First, the error that you were seeing was not caused by the reification of the versions. Second, when running a #currentVersion calculation in an image in which nothing has been installed, all of the versions will have been reified "on demand". > - Or, if creating a project "happens to instantiate all of the version >specifications", is there a way to get and depend on the version I >want without going through the fully reified project? I don't quite understand why you have such a thing about the 'reified project'. In my mind the information encoded in the ConfigurationOf class is nothing more than a dumb XML file ... okay a smart XML file, one that knows how to reify itself, almost. The process of reifying the project and the versions is simply the act of converting an xml file into objects ... incorrectly formatted xml files can wreak havoc with an xml parser just as errors in the configuration can wreak havoc with metacello ... Nearly everything that is done with configurations can be done with XML files and I have been intentional on that point ... If the XML can't be parsed end of story ... sorry Charlie. I agree 100% with you until you say "if you didn't reify the project you wouldn't have this bug"... I don't agree, but I'll agree to disagree. Metacello will reify the project for the forseeable future, because the whole code base is based on reifying the versions in a project. So there is "no way to get and depend on the version I want without going through the fully reified project" without rewriting large chunks of Metacello ... which could be done: Wrap a different "reader" around ye olde ConfigurationOfXXX and you can be free to reify or not to reify to your hearts content:... If that was the question:) But going back to what we agree on ... I do intend to continue to attempt to insulate you from specification errors to the fullest extent that is possible ... The #currentVersion calculation is one of the algorithms that has the potential to touch a whole pile of specifications in a virgin image. Of course the #currentVersion algorithm happens to be central to Metacello being able to load the correct code in the first place so this puppy has to be sound ... in the past I've spent a fair amount of time fixing bugs, rewriting and devising test cases to ensure that the #currentVersion algorithm is correct ... now I guess it is time to focus on making it robust as well:) I've got your dependency loop under the microscope so I expect several improvements to Metacello to result from this investigation:) Dale |
|
|
In reply to this post by Tudor Girba
On 02/25/2011 02:25 PM, Tudor Girba wrote:
> Hi again, > > I just wanted to let you know that marked as broken the 4.3* versions > of Moose and 2.* versions of SmallDude and Moose default loads just > fine now. > Phew ... I'm glad you were able to get past this without waiting for me to find and fix the underlying bug. > Nevertheless, I still maintain that instantiating all versions when > creating a project is not a desired behavior :) I don't quite understand what difference it makes, but that's okay with me:) Dale |
|
|
In reply to this post by Dale Henrichs
Hi Dale,
On 26 Feb 2011, at 00:41, Dale Henrichs wrote: > On 02/25/2011 01:55 PM, Tudor Girba wrote: > >> >> Let me explain a bit what I wanted to say. As I see it, we have >> distinct expectations. There is definitely a problem in our >> configuration and that needs fixing. No question about it. Actually, >> thanks a lot for finding where the problem is. It looks like the >> problem actually was generated by the MetacelloBrowser :) >> >> However, when I write something like this: ((Smalltalk at: >> #ConfigurationOfSmallDude) project version: 'default') load. >> >> I expect it to load that exact version, and not raise issues with >> other unrelated versions. This is similar to the expectation related >> to loading a version of a package from a versioning system: it should >> raise only errors related to that version, and not to the rest of >> them. > > Agree 100% > >> >> So, when I said "dangerous" I meant it is dangerous because things >> might become unloadable because of unrelated versions even if they >> are perfectly ok in themselves. I find this difficult to handle. > > Agree 100%. > > I understand that you are frustrated that due to a bug in Metacello your work came to a screeching halt ... I said I am sorry... I realize that every time I make a release I could cause trouble for a whole lot of folks out there, so I try to be as diligent as possible to keep Metacello stable. I am really not frustrated, and you should not be sorry either. I just believe that I discovered something and I expressed my opinion. In the end, you, as a leader of the project, take the decision. This is simply a debate on opinions, not a cry of anger :) >> Now a couple questions: >> - Why do we need the project to reify all these versions at creation >> time? Is it not possible (and even better?) to reify the versions > > only on demand? > > First, the error that you were seeing was not caused by the reification of the versions. As I understood it, it definitely was caused by this reification :). Let's take a look at what you found out in http://code.google.com/p/metacello/issues/detail?id=114: Moose 4.2 Core ----> SmallDude default nil SmallDude default nil ----> Moose coreDefault nil Moose 4.2 Core ----> SmallDude default nil SmallDude 2.3 ALL ----> Moose 4.2 Core I tried to load SmallDude default. This depended only Moose coreDefault. With this single action, I should have not reached Moose 4.2 or SmallDude 2.3. The logic should have simply read the labels of the versions without creating deeply version. To my mind, this only happens because you are reifying all these versions deeply (meaning by traversing everything) when you are creating the project. If this would happen lazily, the error would not happen. The other benefit of lazy in this case would be the speed of loading. When I will have 500 versions with a tone of dependencies, it might take a long time to reify everything just to load one of them. > Second, when running a #currentVersion calculation in an image in which nothing has been installed, all of the versions will have been reified "on demand". This is totally fine. When I do want to have currentVersion, I do expect to run over all versions to see which one is the current one. >> - Or, if creating a project "happens to instantiate all of the version >> specifications", is there a way to get and depend on the version I >> want without going through the fully reified project? > > I don't quite understand why you have such a thing about the 'reified project'. In my mind the information encoded in the ConfigurationOf class is nothing more than a dumb XML file ... okay a smart XML file, one that knows how to reify itself, almost. > > The process of reifying the project and the versions is simply the act of converting an xml file into objects ... incorrectly formatted xml files can wreak havoc with an xml parser just as errors in the configuration can wreak havoc with metacello ... > > Nearly everything that is done with configurations can be done with XML files and I have been intentional on that point ... Absolutely agreed :) > If the XML can't be parsed end of story ... sorry Charlie. Not agreed. When the syntax is correct, and this should be enough to produce an Abstract Syntax Tree that does not reify the connections, and only interpret the needed connections. > I agree 100% with you until you say "if you didn't reify the project you wouldn't have this bug"... It's not "reifying the project", it is "reifying the project on creation". This is a big problem, because if you tie the two, there is no way to only cherry pick what I need. Why would it be so wrong to do it lazily? > I don't agree, but I'll agree to disagree. > > Metacello will reify the project for the forseeable future, because the whole code base is based on reifying the versions in a project. So there is "no way to get and depend on the version I want without going through the fully reified project" without rewriting large chunks of Metacello ... which could be done: > > Wrap a different "reader" around ye olde ConfigurationOfXXX and you > can be free to reify or not to reify to your hearts content:... If > that was the question:) I am really curious to see why would it be so much to change. What is the class that should be subclassed for this? > But going back to what we agree on ... I do intend to continue to attempt to insulate you from specification errors to the fullest extent that is possible ... > > The #currentVersion calculation is one of the algorithms that has the potential to touch a whole pile of specifications in a virgin image. Of course the #currentVersion algorithm happens to be central to Metacello being able to load the correct code in the first place so this puppy has to be sound ... in the past I've spent a fair amount of time fixing bugs, rewriting and devising test cases to ensure that the #currentVersion algorithm is correct ... now I guess it is time to focus on making it robust as well:) > > I've got your dependency loop under the microscope so I expect several improvements to Metacello to result from this investigation:) Thanks :) Cheers, Doru > Dale > > > -- www.tudorgirba.com "Being happy is a matter of choice." |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |