[V3dot9] Re: UUID fix

[Marcus Denker]

On 13.07.2006, at 20:30, goran at krampe.se wrote:

> Hi guys!
>
> =?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
>> On 12 juil. 06, at 21:50, David Shaffer wrote:
>>> is SMFileCache.  There has been a bug in #asString36 since 3.8 which
>>> causes it to chop of the first three characters of the string 36
>>> representation.  SMFileCache uses this string representation to form
>>> directory names and so any directory created prior to my fix will  
>>> have
>>> an incorrect name and might cause problems when trying to load from
>>> the
>>> cache (although I think it shouldn't).
>>>
>>> If SqueakMap isn't the problem then my advice would be to look for
>>> other
>>> senders of #asString36 in your image and let me know who they are  
>>> so I
>>> can load those packages and see if I can bridge them over to the
>>> correct
>>> version.  Leaving the current incorrect version in place isn't  
>>> the end
>>> of the world, as I mentioned before.  It is just troublesome for  
>>> those
>>> who count on UUID>>asString36 to be consistent between Squeak  
>>> versions
>>> or who rely on it actually producing distinct strings for distinct
>>> UUID's.
>
> Ok, now I may be wrong (haven't fired up the absolutely latest 3.9)  
> but
> that method is in package SMBase - right? I fixed the method in the
> later SMBase release(s).

So we just need to get the latest SMBase package into 3.9 and the  
problem
is solved.

Can you merge the trivial fix in
http://bugs.impara.de/view.php?id=4249

And then we sync with the latest package?

> Now, the method in question belongs better in
> the base image and not in SMBase - so we can move it there, no  
> problem.
>
> I just wish we all could start being aware of the package boundaries.
>
Of course... the only problem is that it makes sometimes everything  
extremely
complicated (and for some packages, it means that even trivial things  
do not
get done... IO is a good example).

    Marcus