2015-06-03 13:22 GMT+02:00 Thierry Goubier <[email protected]>:
> > > 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.... > The problem is that the package "loading" again searches the cache, without the version id: search for package with name+id -> search cache for package with name+id -> "not found -> search other repos -> other repo: -> search again the cache for package with name+id -> "not found" -> load version with name -> search cache for package with *name only* -> "Found" "other" repo thinks it has loaded its package with that name -> compare name+id -> "not found" <- nothing found, even if it is (online) in other repo. > > 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 >>> >>>> >>> >> >>> > >>> > >>> >>> >>> >> >
