I think the problem is that, some of the packages like Kernel-StephaneDucasse.2042 DebuggerActions-StephaneDucasse.75 are in both repositories (main/inbox) but with different UUIDs.
2015-06-01 15:04 GMT+02:00 Ben Coman <[email protected]>: > Stef, I can now see all the dependent packages for the new slice, but > I still have a strange error. However I'm not sure if its a bug or > something unique at my end. > > Can someone try merging > > SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1 > > What I see at top of stack is two calls to MCVersionMerger>>addVersion: > > MCVersionMerger>>addVersion: aVersion > records add: (MCMergeRecord version: aVersion). > aVersion dependencies > do: [:ea | | dep satisfied | > dep := ea resolve. > satisfied := (records anySatisfy: [:r | r version = dep]). > satisfied ifFalse: [self addVersion: dep]] "<<< race? " > displayingProgress: [ :ea| 'Searching dependency: ', ea > package name] > "15646Note: variable /satisfied/ added for reporting/debugging" > > One level down from where the error occurs the debugger shows... > > /aVersion/ --> a > > MCVersion(SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1) > > /ea/ --> a MCVersionInfo(DebuggerActions-StephaneDucasse.75) > > /dep/ --> nil > > /satisfied/ --> false > > and the following which contradicts the value in /satisfied/ > > (records anySatisfy: [:r | r version = dep]) --> true. > > so there seems to be a race such that the ifFalse block is improperly > executed, such that the recursive call on top of stack has... > > /aVersion/-->nil > > hence MNU receiver of "dependencies" is nil. > > cheers -ben > > > On Mon, Jun 1, 2015 at 10:36 AM, Ben Coman <[email protected]> wrote: > > I tried, but it seems some packages are missing from the inbox. > > cheers -ben > > > > On Sun, May 31, 2015 at 2:19 PM, stepharo <[email protected]> wrote: > >> Hi > >> > >> I continued to clean that classes have categories and method protocols > >> because it was not finished. > >> This entry is just adding protocol in the classes that were missing it, > >> adding comments, and fixing some local senders > >> It does not remove the category API but puts it in a accessing-backward > >> protocol and in a second step I will fix all the senders I can (ie not > >> Metacello for example). > >> Category is really overloaded and we get lost when trying to understand > >> code. > >> I want to rename RBRule 'category' into 'kind' for this reason. > >> > >> Stef > >> > >
