2015-06-03 8:22 GMT+02:00 Marcus Denker <[email protected]>: > Indeed... this has to do something with caching: when looking a .mcz the > system just takes the one it finds, which might be > one with the same name but different. >
Unless the mcz searched for is a dependency, in which case it checks the uuid as well (not only the name). > > Maybe we could for real put (part of) the UID in the filename? > Would that be backward compatible with existing repositories? > > In a disconnected system the case that the filename is the same for > different files will always happen if the name is contructed > as it is now. > Thierry > > Marcus > > > On 02 Jun 2015, at 22:37, stepharo <[email protected]> wrote: > > > > I hate so much this bug.... > > > > > > Le 1/6/15 15:04, Ben Coman a écrit : > >> 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 > >>>> > >> > > > > > > >
