You guys are moving so fast. I went to review it but it is already integrated :P Anyway I tried it and it worked well, load Stef's 15646 slice no problem. Well done Nicolai. cheers -ben
On Wed, Jun 3, 2015 at 5:41 PM, Nicolai Hess <nicolaih...@web.de> wrote: > > > 2015-06-03 8:22 GMT+02:00 Marcus Denker <marcus.den...@inria.fr>: >> >> 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. > > > here is a minimal change to the way it uses the cache, or omitting the cache > after the correct version > wasn't find in the cache. > > What do you think, may this work? > > nicolai > > > >> >> >> Maybe we could for real put (part of) the UID in the filename? >> >> 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. >> >> Marcus >> >> > On 02 Jun 2015, at 22:37, stepharo <steph...@free.fr> 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 <b...@openinworld.com> 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 <steph...@free.fr> 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 >> >>>> >> >> >> > >> > >> >> >
