Issue 114 in metacello: tight #currentVersion loop

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...

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

It looks like MetacelloPlatform>>stackCacheFor:at:doing: can catch the loop  
with the following implementation:

stackCacheFor: cacheName at: key doing: aBlock
   self
     useStackCacheDuring: [:dict | | cache hasEntry |
       hasEntry := true.
       cache := dict at: cacheName ifAbsent: [].
       cache ~~ nil
         ifTrue: [ | value |
           value := cache
             at: key
             ifAbsent: [
               cache at: key put: #inProgress.
               hasEntry := false ].
           hasEntry
             ifTrue: [
               value == #inProgress ifTrue: [ self error: 'LOOP' ].
               ^value ]]
         ifFalse: [
           cache := Dictionary new.
           dict at: cacheName put: cache.
           cache at: key put: #inProgress.
           hasEntry := false ].
       ^[ aBlock value: cache ] ensure: [
         (hasEntry not and: [ (cache at: key) == #inProgress ])
           ifTrue: [ cache removeKey: key ]]]
     defaultDictionary: nil

Need to build some test cases to verify...

Updates:
        Labels: Product-Core

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

Upon further review, the above algorithm does detect a cycle while  
calculating the current version, but the cycle it detects does not involve  
Moose '4.3.2'. On the other hand, there certainly appears to be a similar  
cycle here as well:

Moose 4.2 Core ----> SmallDude default nil
SmallDude default nil ----> Moose coreDefault nil
Moose 4.2 Core ----> SmallDude default nil

so more study of the problem is needed

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

The root of the cycle is SmallDude 2.3. Here's the full cycle that was  
detected:

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

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

Interestingly enough the validator does not go into a infinite loop when  
run against ConfigurationOfSmallDude, there are a slug of  
#noVersionSpecified complaints against 2.2 and 2.3, but that's all

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

instead of changing the version of SmallDude in Moose 4.3.2, you can set  
the blessing of Moose 4.3.2 to #broken and the dependency loop is also  
broken ... the biggest news here is my first cut at a loop detector is  
wrong so now I'll have to understand why traversing Moose 4.2 for the  
currentVersion terminates and Moose 4.3.2 does not...FWIW, Moose 4.2  
specifies '2.0-beta.7' as the version for SmallDude.

Updates:
        Labels: -Milestone-1.0-beta.4 Milestone-1.0-beta.28.4

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

(No comment was entered for this change.)

Updates:
        Labels: -Milestone-1.0-beta.28.4 Milestone-1.0-beta.32

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

(No comment was entered for this change.)