Browse thread
Exception Unix_error problem in toplevel
[
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: | 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 units). 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 exceptions). 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.