English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Exception Unix_error problem in toplevel
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-02-06 (07:31)
From: Bob Williams <a6b37331@t...>
Subject: Re: [Caml-list] Exception Unix_error problem in toplevel
On Sun, Feb 04, 2007 at 11:46:55AM +0100, ls-ocaml-developer-2006@m-e-leypold.de wrote:
> > They are all obscure, Markus.  A careful developer finds and fixes
> > most of the obvious bugs; the ones left over are nearly always
> > unusual.
> >
> > I did something stupid to trigger the exception-renumbering bug, but
> But if I understood it right, it's not a bug, but rather a user
> error. There is AFAIR a FAQ for a similar situation if people
> interactively load byte code files several times and define functions
> in between. Your problem is similar, only that you're not redefining
> functions but rather execptions.
> I also think redefining an exception should not trigger an error or
> warning message.
> Rather reloading a byte code file of the same name and at the same
> time having still loaded byte code files that refer to another version
> of the first byte code file -- this should trigger an error or a
> warning. Reloading a byte code file to which no other definitions
> refer is not a problem and indeed wanted when you do debugging.

It can be very useful to reload a cmo file into a running toplevel,
especially if the application is huge (thousands of compilation

I have done some preliminary spelunking into the OCaml sources, and I
think I see an almost general fix for this.  One restriction is that
the replacement cmo file would necessarily need to have the same
interface as the original, but that can be verified by comparing the
interface's MD5 sums.

The idea is to allow any number of #loads or #uses at any time.  You
would be free to replace any compilation unit at any time, or to load
new ones.  Just before evaluating a toplevel expression, toplevel
would check whether there have been any intervening #loads or #uses;
if there have been, toplevel would reapply all the global relocations
(Reloc_setglobal and Reloc_getglobal) and rerun the initialization
code for all the compilation units present in memory, in the order in
which they were loaded.  The repatching and reinitialization should
fix up all the inter-compilation-unit references (including all

What do you all think of this?  Have I missed anything?  The patch
will probably be on the order of 50 lines long; if nobody predicts any
show stoppers, I will start on this in a few days.