Posted by metacello on Feb 25, 2011; 1:01am
URL: https://forum.world.st/Issue-114-in-metacello-tight-currentVersion-loop-tp3323714.html

Status: Accepted
Owner: [hidden email]
Labels: Type-Defect Priority-Medium Milestone-1.0-beta.4

New issue 114 by [hidden email]: tight #currentVersion loop
http://code.google.com/p/metacello/issues/detail?id=114

I reproduced the problem reported here:

   http://forum.world.st/help-wanted-tp3316992p3319997.html

by loading ConfigurationOfMoose-cyrilledelaunay.212 and  
ConfigurationOfSmallDude-TudorGirba.26 into a PharoCore1.0 image where  
Metacello 1.0-beta28.3 had been loaded (default load). The trying to  
execute the following expression:

   ConfigurationOfSmallDude project currentVersion.

The system immediately went into a very tight loop ...

In #version432: of ConfigurationOfMoose if you change

    project: 'SmallDude for Moose' with: 'default';

to:

    project: 'SmallDude for Moose' with: '2.0-beta.7';

the loop terminates (quickly).

Here's the loop (it's pretty tight):

   'Moose Core' '4.2'
   'SmallDude for Moose' 'default'
   'Moose Core' '4.2'
   'SmallDude for Moose' 'default'

By changing 'SmallDude for Moose' to reference '2.0-beta.7' (which does not  
reference back to Moose) the loop is broken.

with nothing loaded Metacello will traverse the versions in reverse order  
looking for a version that matches the existing image, so as long as there  
is a loopy version specification in the configuration a currentVersion  
traversal will run into it (in an empty image) ... presumably the  
configuration worked fine in an image in which Moose had been loaded and  
only showed up when trying to load the version into an "empty image" ...

One scheme for loop detection might be to use the stackCache to collect  
in_progress calculations ... there are identical stackCache keys, but since  
the calculation hasn't finished yet we go ahead and valuate the block which  
loops back around again ... the hasEntry temp just might hold all the info  
we want...