caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Bob Williams <a6b37331@telus.net>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Exception Unix_error problem in toplevel
Date: Mon, 5 Feb 2007 23:20:56 -0800	[thread overview]
Message-ID: <20070206072056.GB19722@telus.net> (raw)
In-Reply-To: <ylsldmurmo.fsf@hod.lan.m-e-leypold.de>

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.


  reply	other threads:[~2007-02-06  7:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-02  1:10 Bob Williams
2007-02-02 12:08 ` [Caml-list] " ls-ocaml-developer-2006
2007-02-02 13:21   ` Luc Maranget
2007-02-03  2:29   ` Bob Williams
2007-02-03  9:57     ` Gabriel Kerneis
2007-02-04  0:34       ` Bob Williams
2007-02-03 13:48     ` ls-ocaml-developer-2006
2007-02-04  0:46       ` Bob Williams
2007-02-04 10:46         ` ls-ocaml-developer-2006
2007-02-06  7:20           ` Bob Williams [this message]
2007-02-02 13:13 ` Vu Ngoc San

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070206072056.GB19722@telus.net \
    --to=a6b37331@telus.net \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).