Having better version numbers

Question

Having better version numbers

francoisthire opened this issue 6 years ago · comments

I just got an issue with a tool that uses Dedukti with the master version: we change the intern representation of tree without changing the version number, hence the serialization with the Marshal module can do a segmentation fault. We should bump something in version number when we make such modifications.

Rodolphe Lepigre · Answer 1 · Sun Apr 22 2018 04:00:34 GMT+0800 (China Standard Time)

There is no real need to do that. A good option is to marshal with the Closures flag, and starting every file with a dummy closure (e.g., fun x -> x). This way, only the binary that wrote a given .dko is able to load it.

Guillaume Bury · Answer 2 · Sun Apr 22 2018 08:03:30 GMT+0800 (China Standard Time)

It seems a lot like a hack, which could very well not work under some circumstances...

On Sat, Apr 21, 2018, 22:00 Rodolphe Lepigre ***@***.***> wrote: There is no real need to do that. A good option is to marshal with the Closures flag, and starting every file with a dummy closure (e.g., fun x -> x). This way, only the binary that wrote a given .dko is able to load it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#78 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABaNExWKLQKEVTTPnALocRrU-j_edfH0ks5tq4_jgaJpZM4Tejvw> .

-- Guillaume Bury - PhD Student Université Paris Diderot Deducteam - Inria Saclay LSV - ENS Cachan

Rodolphe Lepigre · Answer 3 · Sun Apr 22 2018 16:33:04 GMT+0800 (China Standard Time)

Well, if it does not work then the Marshal module must be bugged... I don't see how this qualifies as a hack.

Guillaume Bury · Answer 4 · Sun Apr 22 2018 16:52:01 GMT+0800 (China Standard Time)

I'm not saying it wouldn't work, but rather than it might work across different binaries if by some coincidence some memory offset in the programs match up (well, and some hash colludes, which would be a pretty unlucky coincidence, but still).
Also, what I meant by hack is that is is using the closure marshalling specificities (which exist primarily because of technical reasons iirc) to replace a real versioning of output files. It isn't really hard to just add a version number (or a magic number), and it would have the very nive property that instead of simply failing on other versions, dedukti could produce a helpful error message saying which version produced the file.
All in all, I fell the closure trick is a small, quick hack which shouldn't belong in a serious long term project.

Raphaël Cauderlier · Answer 5 · Sun May 06 2018 18:16:13 GMT+0800 (China Standard Time)

This way, only the binary that wrote a given .dko is able to load it.

I am not sure this is what we want. Currently the .dko format is shared between several forks of Dedukti. It is used by dkmeta and skcheck in particular.

In the case of skcheck, it is usually possible to replace skcheck foo.sk by skindent foo.sk | dkcheck and this gives some fexibility with respect to versions (skindent and dkcheck do not need to have exactly the same version) but nothing similar seems possible for dkmeta: we need to load .dko files to know their rewrite rules.