Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocamlmktop has no way to avoid the need for the #directory directive #7873

Closed
vicuna opened this issue Nov 17, 2018 · 18 comments
Closed

ocamlmktop has no way to avoid the need for the #directory directive #7873

vicuna opened this issue Nov 17, 2018 · 18 comments

Comments

@vicuna
Copy link

vicuna commented Nov 17, 2018

Original bug ID: 7873
Reporter: Loup Vaillant
Assigned to: @dra27
Status: acknowledged (set by @dra27 on 2018-11-20T18:07:35Z)
Resolution: open
Priority: normal
Severity: feature
Platform: x86-64
OS: Ubuntu GNU/Linux
OS Version: 18/04 LTS
Version: 4.05.0
Category: toplevel

Bug description

Maybe it's a missing feature instead of a genuine bug, but it nevertheless halves the usefulness of ocamlmktop.

The -I option can be used to search named object files in various directories, but has no effect whatsoever inside the REPL itself. The user is still forced to type the relevant #directory directive.

Without a way to avoid "#directory "dir";;" all the time, ocamlmktop is rendered much less useful.

Now maybe it isn't the job of the -I option (though I wonder why it wouldn't be, considering how ocamlc works). But then it would be very nice to have a command line option to generate #directory directives directly.

Steps to reproduce

Let's assume we have an object file in another directory:

$ ls lib
utils.cmi

Here's an example session:

$ ocamlmktop -I lib utils.cmo
$ ./a.out
        OCaml version 4.05.0

# open Utils;;
Error: Unbound module Utils
# #directory "lib";;
# open Utils;;
# 

Most frustrating.

@vicuna
Copy link
Author

vicuna commented Nov 17, 2018

Comment author: @dra27

ocamlmktop's principal purpose is allow for toplevels on systems without dynamic C loading (e.g. for stubs).

What you want to accomplish should be done by linking an extra module in whose code includes Topdirs.dir_directory "utils".

However, I find on my system that this seems to have been broken since 4.06

@vicuna
Copy link
Author

vicuna commented Nov 17, 2018

Comment author: @dra27

As an aside, turning the -I options passed to ocamlmktop into #directory's for the compiled toplevel is not in general a sensible change - -I is being used there to locate .cmo and .cma files for linking.

@vicuna
Copy link
Author

vicuna commented Nov 17, 2018

Comment author: @dra27

Regression was introduced in 4.06.0 by #1041 (#1041). I have a hacky fix by replaying calls to Topdirs.dir_directory after Compmisc.init_path is called in Topmain.main (the call to that, incidentally, is in the wrong place too, since it should appear before Topmain.prepare as that calls Toploop.set_paths which is also being overridden by re-running Compmisc.init_path).

The fix I have works, but I think it would be better to revisit how Compmisc.init_path is used - it remains bad that Compmisc.init_path refers to command line arguments before they've actually been parsed.

@vicuna
Copy link
Author

vicuna commented Nov 17, 2018

Comment author: Loup Vaillant

Wrote a long reply, it got deleted by bad software. I'm getting pissed at Mantis.

I'll try to learn more about this "Topdir" thing (I have version 4.0.5, it should work). Quite a shame the ocamlmktop documentation doesn't mention it anywhere. My use case is the most common one, what you mention seems to be common knowledge, yet the documentation is utterly silent. I suggest the manual be updated.

Also, I fail to see the utility of not making modules available even though they were explicitly linked with -I. Do you know of such a use case? If there isn't, the -I option should be modified. If there is, ocamlmktop still needs a dedicated option.

I love OCaml, but stuff like his hurts adoption.

@vicuna
Copy link
Author

vicuna commented Nov 17, 2018

Comment author: Loup Vaillant

Okay, Topdir isn't a thing on the OCaml manual, or even on my search engine.

Does anyone actually use ocamlmktop?

@vicuna
Copy link
Author

vicuna commented Nov 20, 2018

Comment author: @dra27

Any chance we could tone the grumpiness down a little? Writing toplevels is I think fairly niche - what's the use case for this, out of curiosity?

Topdir won't be a thing - it's called Topdirs, but it's a compiler internal module so it won't be in the manual. However, Googling ocaml topdirs gave me loads of results. It contains the functions corresponding to the # directives in the toplevel.

Changing -I as you request is a breaking change, so I don't need a use-case; that's more than enough! Given that ocamlmktop is just a thin wrapper around calling the main compiler, I'm not personally persuaded of the need for the complexity, but I definitely agree that adding the example to the manual would be useful.

@vicuna
Copy link
Author

vicuna commented Nov 20, 2018

Comment author: @dra27

See also #2155

@vicuna
Copy link
Author

vicuna commented Nov 20, 2018

Comment author: Loup Vaillant

Writing toplevels is I think fairly niche

W- What? Are you denying the outstanding usefulness of the REPL, of automatically loading stuff into said REPL, or actually developing a toplevel? I personally believe in the first, think the second is a major convenience, and I did the third when I implemented a language for non-programmers (so they could control some testing environment) because the client asked for a REPL.

what's the use case for this, out of curiosity?

The most mundane thing: writing modules one by one, and once a module is complete add it to the list of modules to load automatically in the REPL. This automatic loading grows more useful as the projects grows bigger.

Googling ocaml topdirs gave me loads of results.

That's just you. Google has trapped you into your own bubble, and biased your search results towards your interests. Try from your relative's computers. Or try with DuckDuckGo, which usually finds what I need (and serves everyone with the same results). Or Bing, which if you never use it may not have a bubble for you yet:

https://duckduckgo.com/?q=ocaml+topdirs
https://www.bing.com/search?q=ocaml+topdirs

Google has another bubble for me, and it doesn't include Topdirs. I won't find it on my own, I need a direct link.

@vicuna
Copy link
Author

vicuna commented Nov 21, 2018

Comment author: @dra27

You could also solve it with a .ocamlinit file which would even save having to remember to rebuild the toplevel after you add a new module. Or you could even go full-hipster and use dune and utop which will do the whole thing for you (https://dune.readthedocs.io/en/latest/usage.html#launching-the-toplevel-repl).

You'll find topdirs.mli in your OCaml Standard Library directory, but you'll forgive me for not providing a URL to your computer. Incidentally, DuckDuckGo, which I've never used, has an example from ocaml.org for Gtk which shows exactly how to use it. But perhaps DuckDuckGo secretly gets my profile from Google...

@vicuna
Copy link
Author

vicuna commented Nov 21, 2018

Comment author: Loup Vaillant

OK, thanks for the tip. I'll look into my standard library.

I recall the GTK link to DuckDuckGo, I just failed to notice its relevance. An "introduction to GTK" didn't look like relevant Topdirs documentation… I something dedicated to Topdirs. I'll take a closer look.

the .ocamlinit file is yet another thing I didn't know about, and the search results are not exactly abundant (though I did find some stuff).

@vicuna
Copy link
Author

vicuna commented Nov 21, 2018

Comment author: @dra27

.ocamlinit is documented in the manual (http://caml.inria.fr/pub/docs/manual-ocaml/toplevel.html) before ocamlmktop!

@vicuna
Copy link
Author

vicuna commented Nov 22, 2018

Comment author: Loup Vaillant

Oops.

@github-actions
Copy link

github-actions bot commented May 7, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 7, 2020
@dra27 dra27 removed the Stale label May 7, 2020
@damiendoligez
Copy link
Member

I'm not convinced that using -I to preload the search path of the toplevel is a good idea. Most of the time I would expect the -I directories to be relative to where the build took place (and indeed that's the case in your example). Are you sure you always launch your toplevel from the build directory?

@github-actions
Copy link

github-actions bot commented Oct 4, 2021

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Oct 4, 2021
@github-actions github-actions bot closed this as completed Nov 3, 2021
@aqjune
Copy link

aqjune commented May 29, 2023

I think this feature would be useful because ocamlmktop is a useful tool to build a custom REPL. For the concern about giving a relative path to -I, I think raising a warning suggesting that the path must be absolute should be enough.

@nojb
Copy link
Contributor

nojb commented May 30, 2023

What you want to accomplish should be done by linking an extra module in whose code includes Topdirs.dir_directory "utils".

Did you try using the solution mentioned above? Namely, link an extra module to your custom toplevel that calls

Topdirs.dir_directory "foo"

@aqjune
Copy link

aqjune commented May 30, 2023

Oops, probably I misinterpreted what this issue was for, nevermind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants