[Caml-list] any way to "clear" the toplevel?

[Caml-list] any way to "clear" the toplevel?

[Chris Hecker]

I'm working on a multimodule project, and I use the toplevel a lot.  I
have my makefile output a file from the list of bytecode objects
(the file's named "top") which looks like this:

#load "math2d.cmo";;
#load "pointers.cmo";;
#load "ccd.cmo";;
#load "armparse.cmo";;

Then, when I load the toplevel, I type #use "top";; and voila, my
project's in the toplevel.  When I edit the main file and exec it in
the toplevel, it uses the modules above just fine.

The problem is, if I edit any of the files loaded, and then try to
#use "top";; again, I get 

File armparse.cmo is not up-to-date with respect to interface Armparse

And my new stuff doesn't load.  Is there anything I can do about this?
The optimal solution would be to be able to flush a specific interface
and reload it (I tried #load "foo.cmi";; but it errors), but it'd be
acceptable to simply reinit the toplevel as well.   I currently have
to kill the process and start it over.

Am I missing something?

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] any way to "clear" the toplevel?

[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.

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] any way to "clear" the toplevel?

[Jacques Garrigue]

From: Chris Hecker <checker@d6.com>

> 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 = <abstr>
# 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

Re: [Caml-list] any way to "clear" the toplevel?

[Chris Hecker]

>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.

Right, but since I just have my makefile output a "top" file that looks like this now:

#init;;
#load "blah.cmo";;
...

It just works for me.  Restarting the toplevel inside emacs was a big pain, not to mention that doing it too many times on Win98 would crash the OS :).  I just have to #use "top";; whenever I change a library.  It's not too bad...the 80/20 rule applies here.  :)

I'm really getting into the toplevel for development.  We'll see how that opinion evolves as my project gets bigger.  

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] any way to "clear" the toplevel?

[Marcin 'Qrczak' Kowalczyk]

Thu, 26 Apr 2001 10:05:02 +0900, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> pisze:

> 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.

Glasgow Haskell Compiler 5.00 does this in its interactive toplevel.
It maintains the dependency graph of loaded modules. Reloading
checks time stamps and recompiles to in-memory bytecode or reloads
object code of modules which changed or which depend on modules whose
interface changed (or something like that).

http://www.haskell.org/ghc/docs/latest/set/ghci-compiled.html
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/compMan/CompManager.lhs?rev=1.69&content-type=text/x-cvsweb-markup

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] any way to "clear" the toplevel?

[Jacques Garrigue]

From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
> Thu, 26 Apr 2001 10:05:02 +0900, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> pisze:
> 
> > 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.
> 
> Glasgow Haskell Compiler 5.00 does this in its interactive toplevel.
> It maintains the dependency graph of loaded modules. Reloading
> checks time stamps and recompiles to in-memory bytecode or reloads
> object code of modules which changed or which depend on modules whose
> interface changed (or something like that).

As you have probably got to know by now, doing things automatically
for the user is very uncamlish. What I was talking about is in fact
even simpler than that: just trash modules that do not match their
signature anymore, and force the user to reload by hand all depending
code. It is not that hard, but of rather limited interest if you don't
go the full way to have automatic reloading also, like in GHC as you
say, and with SML/NJ's compilation manager also I suppose.

My next point was pointing at a more concrete problem, that you may
have to solve even if signatures did not change: values in ADT's.
Either you force ADT's to be different types everytime you reload a
module, which basically means all values whose type is related to an
ADT in the environment cannot be used anymore, or you need some very
clever tracing at the value level this time, and some way to know
whether the representation of an ADT changed or not. Hairy.
What is GHC doing about that? I suppose there is a way to represent
ADT's in Haskell. But I'm not sure whether you can define values at
toplevel, in the way you do in ML.
On this point Caml's policy at toplvel is unsafe: you can still use
all your values, and happily get core dumps. But this is much more
comfortable than flushing all values even when nothing was modified.

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] any way to "clear" the toplevel?

[Marcin 'Qrczak' Kowalczyk]

Fri, 27 Apr 2001 09:50:33 +0900, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> pisze:

> My next point was pointing at a more concrete problem, that you may
> have to solve even if signatures did not change: values in ADT's.

> What is GHC doing about that?

"Interface" is a compiler-generated file. It changes when some
part relevant for compilation of other modules changes, e.g. the
representation of an ADT or the body of an inlined function.

The compiler cares to not overwrite this file if it's the same as
the previous version, to avoid unnecessary recompilation of dependent
modules.

> But I'm not sure whether you can define values at toplevel, in the
> way you do in ML.

You can, but they are forgotten on reloading modules, even if nothing
changed.

Perhaps it would make sense to improve this behavior, but they should
be flushed at some time, because in Haskell, as opposed to OCaml,
later bindings don't normally cover previous bindings of the same
name. They do cover when defined at the toplevel (the toplevel mimics
the body of an imperative function rather than a set of module-level
declarations). It's not obvious how to keep this covering policy on
reloading modules which logically sit behind toplevel-defined names.

It's not really that inconvenient to have these names flushed, because
all changed modules can be reloaded by issuing one command, so the user
can define values intended to last longer in a module rather than on
the toplevel - the compiler remembers how the environment was created
and recreates it as needed. You can't define types on the toplevel,
so it's sometimes necessary anyway.

GHC's interactive toplevel is new: the first version which includes
it was released less than a month ago. Details are likely to change.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr