From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA28957; Mon, 18 Mar 2002 11:11:55 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA29829 for ; Mon, 18 Mar 2002 11:11:54 +0100 (MET) Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g2IABsH07669 for ; Mon, 18 Mar 2002 11:11:54 +0100 (MET) Received: from warp (lns03v-12-89.w.club-internet.fr [212.194.47.89]) by relay-4v.club-internet.fr (Postfix) with SMTP id D149C171E for ; Mon, 18 Mar 2002 11:11:50 +0100 (CET) Message-ID: <005c01c1ce65$259030f0$be00a8c0@warp> From: "Warp" Cc: References: <9601-Sat16Mar2002094255-0800-tim@fungible.com><20020318101225C.garrigue@kurims.kyoto-u.ac.jp><1191-Sun17Mar2002193326-0800-tim@fungible.com> <20020318142017J.garrigue@kurims.kyoto-u.ac.jp> Subject: Re: [Caml-list] Big executables from ocamlopt; dynamic librariesagain Date: Mon, 18 Mar 2002 11:10:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > If you want to have both security and allow linking everytime it's > safe, then you would need to do lots of type-checking at link-time > (runtime for dynamic linking). Basically that every module you depend > on has an interface at least as good as what you need, checking type > by type. If you've got a look at the size of some .cmi's, you may > realize that including required types in executables may require > potentially huge sizes. And type-checking is sometimes too slow. > > 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. Is the speed really an issue ? I mean... the ocaml compiler is doing that job, and even more, right ? and its speed looks quite good. Or perhaps this is an inv-NP problem where checking against a given signature takes exp. time when producing a valid one is easy :) Of course, that's true the size of CMI is turning big quite fast. But including the CMI will be better then including the CMA ( if there is no C dll behind, in that case, the CMI is bigger than the CMA ) > 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. > > And, even worse than that, the current MD5 computation scheme is > algorithm dependent: it is not based on a normalized view of types, > but just on a dump of an internal tree structure, which is extremely > sensitive to any change in the type checking algorithm. This means > that compatibility can be broken as often as once a week for the CVS > version! That MD5 choice is of course well justified , but if that mean breaking backward compatibily , distribuing ocaml precompiled binaries become impossible, and then you're closing the ocaml door to many commercial usages of ocaml, which could greatly improve the size of the community and so the speed of ocaml development. > So probably the real answer is that dynamic linking of caml native > code is possible, but that it would be a lot of work, not so much at > the compilation level, but more at improving compatibility checking. > One could argue that the benefits would not be limited to dynamic > linking alone, but also easier upgrading bewteen ocaml versions, so > this might be worth it. Do you mean dynlink of native code from bytecode ? Whithout a CMI to ensure the type checking ? Nicolas Cannasse ------------------- 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