Hi,
On 25/05/2020 09:50, Fred Kiefer wrote:
The first "halt" I get is when loading Attributes.gorm of GWorkspace's Inspector
Looks like your archive has a value that gets encodes as an NSInteger and this
is 32 bit on your current machine but the original encoded value was actually
64 bit and uses more than the 32 bit you are able to read. The best thing to do
is to find out which value it is that causes the behaviour and encode (and
decode) it as a long.
And to answer your question, the message itself is surely not a bug, it just
shows how clever base tries to deal with different encoded values. The actual
encoding may be a bug. There it would really help to know where it is coming
from.
Yes, I understand the error is not in the Unarchiver - I have seen the
check.
But my question is why should I have an invalid number in a Gorm file.
So either a bug in it, in some archiver or in some compatibility.
From the stacktrace I couldn't undestand what exactly that value is.
I hope it is not an issue of creating a gorm file on a 64bit machine and
reading it back on a 32bit or something like that!
First thing, I will see if I can reproduce this on other machines. I do
not see this on my workstation, but it is running on 64bit, with a
different OS and with a different compiler and runtime :-P Too many
differences.
Riccardo
