Browse thread
[Caml-list] Big executables from ocamlopt; dynamic libraries again
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Johan_Georg_Granström <georg.g@h...> |
| Subject: | Re: [Caml-list] Big executables from ocamlopt; dynamic libraries again |
> As a fall-back solution, there is MD5 hashing. The problem is that > you're then mixing information for all the contents of a module. > Any change will produce a new incompatible hash value. > For instance, every time you add a function to a library, it becomes > incompatible. And there are new functions in every release of ocaml. > > Note that for C, compatibility policies generally allow adding extra > functions to a library without changing the version number, since the > problem, should it arise, can be detected at link time. IMHO this a perfect research problem: Find a mapping H:S->B where S is the set of module signatures and B is the set of binary (arbitrary length) strings. Such that if and only if s_1 is a subset of s_2 then there is some relation between H(s_1) and H(s_2), thus s_1<s_2 iff H(s_1) R H(s_2). Perhaps you could drop "and only if" and let H(s_1) R H(s_2) imply s_1 < s_2 with 99.9...% certainty. Finding an efficient pair H and R would really make life easier for software maintainers. I guess reasonable demands on H and R are that H(s) should have a binary length that is a fraction of the size of the corresponding .cmi and that b_1 R b_2 is big ordo the size of b_1 plus b_2. In any case R must be significantly faster than big ordo size of b_1 times b_2. Does this make since? Is it possible? Is it already done? Yours, - Johan Granström Ps. Using hashes of modules for compability checks is a pain in the ass. Microsoft .NET framework does it - and it doesn't work in real life. I know from personal experience... ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners