2015-06-03 11:41 GMT+02:00 Nicolai Hess <[email protected]>: > > > 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. >> > > 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? >
I'm not sure the problem is there. Often, in configurations, you don't have the full version info, just the mcz name :( And I would expect that a given repo has a single mcz with a given name (i.e. the repo cache should be working properly)... Nice find that each file based repository has a cache in addition to the main package cache.... Package loads with version info happens in two cases: - dependency loading (i.e. slices) - history loading (i.e. browsing history and merges). Anything else is loading by name, since this is what is recorded in Configurations and Gofer scripts. Thierry > > 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 <[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 >> >>>> >> >> >> > >> > >> >> >> >
