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 DAA23244; Thu, 26 Apr 2001 03:05:11 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA22890 for ; Thu, 26 Apr 2001 03:05:10 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f3Q157P25005 for ; Thu, 26 Apr 2001 03:05:08 +0200 (MET DST) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id KAA10736; Thu, 26 Apr 2001 10:05:01 +0900 (JST) To: checker@d6.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] any way to "clear" the toplevel? In-Reply-To: <4.3.2.7.2.20010425165253.00e05ba0@shell16.ba.best.com> References: <200104252035.NAA17326@smtp4-cm.mail.eni.net> <4.3.2.7.2.20010425165253.00e05ba0@shell16.ba.best.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010426100502B.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 26 Apr 2001 10:05:02 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Chris Hecker > I fixed this in my own toplevel by adding an #init. Here's the code: > > (* To init the toplevel env *) > let _ = Hashtbl.add directive_table "init" (Directive_none > (fun () -> Env.reset_cache (); > toplevel_env := Compile.initial_env())) > > Just add that somewhere in toplevel/topdirs.ml and #init;; will > clear out the environment. It turns out the Env module's hash cache > of the .cmi CRCs is what was preventing a reload of my file. Not > sure if that's a bug or not. This is not a bug: if you don't cache you would have to reload the .cmi everytime you try to access a module. Indeed, I also get bitten by the problem you describe quite frequently. Not that frequently because I mostly avoid the toplevel, and this is one of the reasons to avoid it, the other being that reloading (somehow) works only for very small projects. Unfortunately, your solution is only partial: it is almost equivalent to quitting and starting a new toplevel (which is my personal solution :-)) You do not only erase things that have changed, but just everything. But it has the advantage of being very simple. The real solution would be to analyze dependencies between modules, and only flush things that depend on a modified module. Promises to be rather hard. Finally, I think you are stuck anyway by the static scope semantics: what you probably would want to do is replace a module in the running environment by its new version, witout recompiling everything else. ML semantics do not allow that. That is, doing that would involve not only tracing types, but also values created by a module. To give you an idea of the problem, here is an example that breaks the current toplevel at the value level: test.mli: type t val put : int -> t val get : t -> int test.ml: type t =int let put x = x let get x = x test2.ml: type t = int ref let put x = ref x let get x = !x Objective Caml version 3.01+1 (2001-04-19) # #load"test.cmo";; # let a = Test.put 3;; val a : Test.t = # Test.get a;; - : int = 3 # #load"test.cmo";; # Test.get a;; - : int = 3 (* rename test2.ml to test.ml and compile it *) # #load"test.cmo";; # Test.get a;; Segmentation fault Cheers, Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr