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
Comments
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 |
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. |
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. |
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. |
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? |
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. |
Comment author: Loup Vaillant
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.
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.
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 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. |
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... |
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). |
Comment author: @dra27 .ocamlinit is documented in the manual (http://caml.inria.fr/pub/docs/manual-ocaml/toplevel.html) before ocamlmktop! |
Comment author: Loup Vaillant Oops. |
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. |
I'm not convinced that using |
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. |
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. |
Did you try using the solution mentioned above? Namely, link an extra module to your custom toplevel that calls
|
Oops, probably I misinterpreted what this issue was for, nevermind. |
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:
Here's an example session:
Most frustrating.
The text was updated successfully, but these errors were encountered: