clean-libraries issueshttps://gitlab.science.ru.nl/clean-and-itasks/clean-libraries/-/issues2020-04-26T13:55:44+02:00https://gitlab.science.ru.nl/clean-and-itasks/clean-libraries/-/issues/4GraphCopy compatibility between 32-bit and 64-bit executables2020-04-26T13:55:44+02:00Camil StapsGraphCopy compatibility between 32-bit and 64-bit executablesCurrently GraphCopy represents values as 8 bytes on 64-bit systems and as 4 bytes on 32-bit systems, so it is not possible to copy a string representation of a graph from one platform to the other (and the "with names" variant is irrelev...Currently GraphCopy represents values as 8 bytes on 64-bit systems and as 4 bytes on 32-bit systems, so it is not possible to copy a string representation of a graph from one platform to the other (and the "with names" variant is irrelevant for this, of course). It would be useful to have this for the "with names" variant.
The ABC interpreter also relies on GraphCopy to (de)serialize values, so while the interpreter now works on 32-bit and 64-bit platforms and can run 32-bit and 64-bit ABC code, it is not possible yet on a 64-bit platform to deserialize a value serialized on a 32-bit platform, or vice versa. This also impacts iTasks, which currently works on 64-bit platforms because we can share a 64-bit graph representation with WebAssembly, which is also 64-bit.
To get this fixed I see two options:
1. Functions to convert a 32-bit graph-as-a-string to a 64-bit graph-as-a-string (and vice versa). The main difficulty here is that Real constants should be 64-bit on both platforms. For `REAL` nodes that's easy; for records with unboxed Reals it is possible (through the type string) but more difficult.
2. An option to let GraphCopy on 32-bit systems give a 64-bit string as output. The main difficulty here is that this option needs to be passed everywhere, e.g. in functions like `replace_desc_numbers_by_descs` which walk through the string: `IF_INT_64_OR_32 8 4` there would become `IF_INT_64_OR_32 8 (if compat64 8 4)` or something like that. It seems this would be more work but less error-prone.
I don't have a clear preference yet. Do you see other options, @johnvg?