[M3devel] Fwd: Re: Pickles, TextLiterals, and word size

[Rodney Bates]

This is more complicated than I thought, but fortunately, more 
manageable.  

When a fingerprint derives from the components of its type, it uses the
fingerprints of the declared static types of the fields (or elements). 
A pickled object, accessible through such a field gets the fingerprint
of its allocated type.  In the case I have, the field is declared as
TEXT, while its value is an object of (sub)type TextLiteral.T, the 
problematic
type.  

So recognizing both fingerprints for TextLiteral.T will work fine, 
unless there 
is an old stored pickle with a field/element of type TextLiteral.T  Not 
a likely
way to code things, I would expect.  

-Rodney Bates

--- Begin forwarded message:

From: "Rodney M. Bates" <rodney_bates at lcwb.coop>
To: m3devel at elegosoft.com
Subject: Re: [M3devel] Pickles, TextLiterals, and word size
Date: Wed, 24 Jul 2013 15:59:12 -0500



On 07/24/2013 12:14 PM, Rodney M. Bates wrote:
>
>
> On 07/24/2013 10:34 AM, Hendrik Boom wrote:
>> On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote:
>>> There is what I would call a bug in TextLiteral.i3 whose effect is that a
>>> TextLiteral.T has a different fingerprint on 32- and 64-bit machines.
>>> So you can't pickle a Text literal on one word-sized machine and unpickle
>>> it on the other.
>>>
>>> But fixing this will have the effect of invalidating any existing pickles
>>> written on a 64-bit machine before the fix, so they can't be read after
>>> the fix, even on a 64-bit machine.  They would have to be rewritten after
>>> the fix.
>>
>> Ah!  The problems of long-term compatibility!
>>
>> Is there any way of looking at a a pickle and determining whether it
>> comes from a 32- of 64- bit machine?
>
> Yes, the pickle contains word size, LONGINT/LONGCARD size, floating
> point representation, endianness, lazy alignment, maximum alignment,
> record alignment, and now, widechar size, all for the system it was
> written on.
>
>
>>
>> It there a way of special-casing the specific fingerprint that's about
>> to be invalidated, so as to convert it properly on input only, while
>> generating the new one on output?
>>
>
> Yes, I thought about this.  It would not be hard to find out what the
> two fingerprints are and test one read from a pickle against these values.
>
> But the problem is, there is an unbounded set of types that would depend
> indirectly on this, and they can't all be accounted for.  Using, e.g.,
> BITSIZE(INTEGER) as a bound in a range is the way this is happening
> it the subject case.
>
> Hmm, maybe I could just do the specific derived fingerprints for a
> TextLiteral.T, and that would be good enough.  Let the programmer be
> responsible for other types.  I think it would fix the immediate
> problem without undermining anything existing.

No, that won't work either.  That would only fix the case where the
TextLiteral is the top-level, and thus only, "object" in a pickle.
Not very likely.  When the TextLiteral is a field/element of some
containing object, it is the topmost object in the entire pickle
whose fingerprint is used to find the type in the reading program.

Actually, pickling a TextLiteral might not be very common at all.



>
> I already have file dumps I can dig the values out of.  I'll look
> into that.  Thanks!
>
>
>>>
>>> Is anybody doing the latter?  Would having to recreate your pickles be a
>>> problem?  Apparently, nobody is going cross-word-size, or we'd have heard
>>> about it.
>>>
>>> I would like to fix it properly, but don't want to undermine anybody's
>>> working system.
>>>
>>
>
>