<div dir="ltr"><div>Ah, that reminds me that our MC configuration map store the UUID, so Squeak should rock...<br>Alas, we do not use this UUID to enforce correctness at load time !!!<br></div>If it's a feature, it's rather a bad one ;)<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-03 15:46 GMT+02:00 Thierry Goubier <span dir="ltr"><<a href="mailto:thierry.goubier@gmail.com" target="_blank">thierry.goubier@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-06-03 15:09 GMT+02:00 Nicolai Hess <span dir="ltr"><<a href="mailto:nicolaihess@web.de" target="_blank">nicolaihess@web.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div><span style="color:rgb(34,34,34)">self versionFromFileNamed: fileName</span><br></div></div><div>is called after it isn't found in the MCCacheRepository<br></div><div>and if it is not found in its own special repository cache , it is loaded with<br>self loadVersionFromFileNamed:<br></div><div>and this again looks up in the MCCacheRepostory:<br><br>loadVersionFromFileNamed: aString<br>(MCCacheRepository uniqueInstance includesFileNamed: aString)<br> ifTrue: [ ^ MCCacheRepository uniqueInstance loadVersionFromFileNamed: aString].<br> <br> ^ self versionReaderForFileNamed: aString do: [:r | r version]<br></div><div><br></div><div>but this time it searches the package in the MCCacheRepitory by its name only and load<br></div><div>the version info from that file.<br></div></div></div></div></blockquote><div><br></div></span><div>Thanks for finding that. Interesting, that semantic missmatch ... which amounts to loosing the version info in places during the loading process.</div><div><br></div><div>Notes for documentation :</div><div><br></div><div>- FileTree changes versionFromFileNamed: to disable the internal repository cache (but cache is still an instance variable because of inheritance, and it goes through PackageCache).</div><div><br></div><div>- GitFileTree avoids the PackageCache altogether and is the only type of repo not to have that bug in Pharo4 (Yes! But I had no idea why :)).</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>We need to build test repositories to have correct coverage of those issues, because at the moment I'm not sure I understand the case you are describing :(</div></div></div></div></blockquote><div><br><br></div></span><div>Try to load <br>SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1<br>from pharo 5.0 inbox repository.<br></div><div>This slice has dependencies to packages <br>DebuggerActions-StephaneDucasse.75, Kernel-StephaneDucasse.2042<br></div><div>which are both in pharo 5.0 main and inbox repository but with different uuids<br></div></div></div></div></blockquote><div><br></div></span><div>Yuck :(</div><div><br></div><div>So, if I understood well, what is happening is:</div><div><br></div><div>- Reading from Pharo5Main, DebuggerActions-StephaneDucasse.75 is loaded in PackageCache (and in the cache of Pharo5Main).</div><div>- Comparing UUIDs say that this is not the right one.</div><div>- Reading from Pharo5Inbox, DebuggerActions-StephaneDucasse.75 is loaded in the cache of Pharo5Inbox</div><div>- First read inside package cache say that the file exist but has the wrong UUID</div><div>- Second read has matching file name inside Pharo5Inbox</div><div>- So it loads the version from Pharo5Inbox</div><div> - which test PackageCache for DebuggerActions-StephaneDucasse.75 ... which is true</div><div> - But uuids don't match</div><div> - so it fails....</div><div><br></div><div>I hate package-cache.</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br>If pharo 5.0 main repository is searched first, it will only find packages with the wrong version info, <br>even if the packages in the 5.0 inbox have the correct version info.<br></div></div></div></div></blockquote><div><br></div></span><div>You're right.</div><div><br></div><div>So your fix should work. I would not hesitate however:</div><div><br></div><div>- to move the version reading line inside versionWithInfo:ifAbsent:</div><div>- to factor the cache update into an #updateCacheWith: v (so that it can also be called from versionFromFileNamed:) called from versionWithInfo:ifAbsent:</div><div><br></div><div>Thierry</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br><br></div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>Thierry</div></font></span><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br><br></div><div><div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Package loads with version info happens in two cases:</div><div>- dependency loading (i.e. slices)</div><div>- history loading (i.e. browsing history and merges).</div><div><br></div><div>Anything else is loading by name, since this is what is recorded in Configurations and Gofer scripts.</div><span><font color="#888888"><div><br></div><div>Thierry</div></font></span><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>nicolai<br></div></font></span><div><div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Maybe we could for real put (part of) the UID in the filename?<br>
<br>
In a disconnected system the case that the filename is the same for different files will always happen if the name is contructed<br>
as it is now.<br>
<span><font color="#888888"><br>
Marcus<br>
</font></span><div><div><br>
> On 02 Jun 2015, at 22:37, stepharo <<a href="mailto:stepharo@free.fr" target="_blank">stepharo@free.fr</a>> wrote:<br>
><br>
> I hate so much this bug....<br>
><br>
><br>
> Le 1/6/15 15:04, Ben Coman a écrit :<br>
>> Stef, I can now see all the dependent packages for the new slice, but<br>
>> I still have a strange error. However I'm not sure if its a bug or<br>
>> something unique at my end.<br>
>><br>
>> Can someone try merging<br>
>> SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1<br>
>><br>
>> What I see at top of stack is two calls to MCVersionMerger>>addVersion:<br>
>><br>
>> MCVersionMerger>>addVersion: aVersion<br>
>> records add: (MCMergeRecord version: aVersion).<br>
>> aVersion dependencies<br>
>> do: [:ea | | dep satisfied |<br>
>> dep := ea resolve.<br>
>> satisfied := (records anySatisfy: [:r | r version = dep]).<br>
>> satisfied ifFalse: [self addVersion: dep]] "<<< race? "<br>
>> displayingProgress: [ :ea| 'Searching dependency: ', ea<br>
>> package name]<br>
>> "15646Note: variable /satisfied/ added for reporting/debugging"<br>
>><br>
>> One level down from where the error occurs the debugger shows...<br>
>><br>
>> /aVersion/ --> a<br>
>> MCVersion(SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1)<br>
>><br>
>> /ea/ --> a MCVersionInfo(DebuggerActions-StephaneDucasse.75)<br>
>><br>
>> /dep/ --> nil<br>
>><br>
>> /satisfied/ --> false<br>
>><br>
>> and the following which contradicts the value in /satisfied/<br>
>><br>
>> (records anySatisfy: [:r | r version = dep]) --> true.<br>
>><br>
>> so there seems to be a race such that the ifFalse block is improperly<br>
>> executed, such that the recursive call on top of stack has...<br>
>><br>
>> /aVersion/-->nil<br>
>><br>
>> hence MNU receiver of "dependencies" is nil.<br>
>><br>
>> cheers -ben<br>
>><br>
>><br>
>> On Mon, Jun 1, 2015 at 10:36 AM, Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> wrote:<br>
>>> I tried, but it seems some packages are missing from the inbox.<br>
>>> cheers -ben<br>
>>><br>
>>> On Sun, May 31, 2015 at 2:19 PM, stepharo <<a href="mailto:stepharo@free.fr" target="_blank">stepharo@free.fr</a>> wrote:<br>
>>>> Hi<br>
>>>><br>
>>>> I continued to clean that classes have categories and method protocols<br>
>>>> because it was not finished.<br>
>>>> This entry is just adding protocol in the classes that were missing it,<br>
>>>> adding comments, and fixing some local senders<br>
>>>> It does not remove the category API but puts it in a accessing-backward<br>
>>>> protocol and in a second step I will fix all the senders I can (ie not<br>
>>>> Metacello for example).<br>
>>>> Category is really overloaded and we get lost when trying to understand<br>
>>>> code.<br>
>>>> I want to rename RBRule 'category' into 'kind' for this reason.<br>
>>>><br>
>>>> Stef<br>
>>>><br>
>><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div></div>