utop icon indicating copy to clipboard operation
utop copied to clipboard

Ppx_tools not working in uTop 2.0.1

Open mseri opened this issue 8 years ago • 10 comments

As mentioned in https://discuss.ocaml.org/t/ppx-tools-not-working-in-utop/367 The new utop has a problem with ppx_tools:

$ utop -require ppx_tools
File "_none_", line 1:
Error: Reference to undefined global `Longident'

I think it's an issue with utop. The following set of packages works without problems

ocamlfind       1.7.3  A library manager for OCaml
ppx_tools  5.0+4.03.0  Tools for authors of ppx rewriters and other syntactic tools
utop           1.19.3 (pinned)  Universal toplevel for OCaml

while this other presents the issue we both saw:

ocamlfind       1.7.3  A library manager for OCaml
ppx_tools  5.0+4.03.0  Tools for authors of ppx rewriters and other syntactic tools
utop            2.0.1 (pinned)  Universal toplevel for OCaml

mseri avatar Jun 08 '17 13:06 mseri

It's because utop 2.0.1 declares its dependency on compiler-libs while the older version did not.

Technically this is a very obscure problem; the compiler libraries contain a lot of generic root modules (Misc, Path, ...) that are very likely to clash with root modules from user libraries and the OCaml toplevel uses the compiler libraries. As a result the OCaml toplevel is expunged, i.e. the modules from the compiler libraries are made hidden from what the user can use inside the toplevel. utop does the same.

ppx_tools uses the compiler libraries as well, but because utop thinks they are already available as the utop library depends on them, it doesn't try to load them again. There is probably a complicated way around this.

Alternatively, you can try utop-full which is not expunged. The only limitation is that you cannot load root modules such as Misc or Path in it.

ghost avatar Jun 09 '17 16:06 ghost

I'm seeing this issue in https://github.com/reynir/ocp-index-top/issues/9 as well. It's a toplevel directive for looking up documentation for identifiers. Do you have any advice on making it work in utop? I have an issue about inadverdently exposing compiler-libs, so I understand the motivation for the change in utop 2.0.1 https://github.com/reynir/ocp-index-top/issues/1. Thanks!

reynir avatar Jun 15 '17 08:06 reynir

Well, appart from using utop-full I'm not sure. We could restore the previous behavior that allowed to load the compiler libs in utop, but this was causing other bugs. The real solution would be to just not expunge utop, but then the name clashes might be a problem. Hopefully this will be sorted when we get namespaces in OCaml and can namespace the compiler libraries.

ghost avatar Jun 15 '17 10:06 ghost

Same problem here, reason toplevel built on top of utop stopped working.

The dependency chain is: reason -> ocaml-migrate-parsetree -> compiler-libs.common -> Misc. Resulting in Error: Reference to undefined global `Misc'.

let-def avatar Jun 19 '17 14:06 let-def

How is the reason toplevel built? If you link a custom toplevel, you should only get this error if you expunge the toplevel

ghost avatar Jun 26 '17 08:06 ghost

It's utop with a custom init that replaces parsing and printing.

let-def avatar Jun 26 '17 08:06 let-def

Maybe it should be a custom toplevel instead?

ghost avatar Jun 26 '17 10:06 ghost

Maybe. In the meantime we are happy with utop-full. Thanks.

let-def avatar Jul 28 '17 17:07 let-def

@diml is there any issue/PR to track the namespacing of the compiler libs?

XVilka avatar Nov 13 '18 05:11 XVilka

There is this ticket that's related: https://caml.inria.fr/mantis/view.php?id=6704

Namespacing the compiler libs like the stdlib would be nice, though it's likely to be a little bit painful to adapt the makefiles.

ghost avatar Nov 13 '18 09:11 ghost