|Anonymous | Login | Signup for a new account||2018-01-17 10:28 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005540||OCaml||toplevel||public||2012-03-14 22:15||2017-03-03 15:35|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0005540: Installing more modules + separate Dynlink from Toplevellib|
|Description||Would it be possible to:|
- install the following modules: Errors, Location
These are used by Toploop and Topdirs and it would be useful to be able to access the functions in them from third party tools. Moreover, PR 0005507 suggest using Location.t through ocamldoc; I would do so if it was possible to access the Location module from custom generators' code.
- separate dynlink from toplevellib, requiring to link with dynlink.cma when linking with toplevellib.cma ? As it is now, it's impossible to use toplevellib and dynlink in the same executable (core dump or strange behaviour after load through dynlink).
That's all :)
|Tags||No tags attached.|
Installing more of / all of the compiler interfaces is being considered.
For your second wish (dynlink / toplevel compatibility), this raises some non trivial issues. Could you please tell us more about the usage scenario(s) that you have in mind?
In GODI we install the compiler interfaces in a separate directory. This turned out as very helpful - some packages interacting deeply with the compiler can now be built without requiring the full ocaml sources.
I'd suggest to put them simply into a subdir of the stdlib.
About dynlink/toplevel compatibility, I encountered the problem twice:
1. In Chamo: this is a source code editor in ocaml, able to evaluate ocaml code to perform some operations (à la emacs) and able to load plugins, too.
2. In Stog, a static web site generator, able to evaluate ocaml code and display (or not) the toplevel result, for example to show real examples, tested when the site is compiled; Stog also offers the possibilty to load plugins to define new callbacks associated to some tags.
A workaround exists: in bytecode version, rather than linking with dynlink, I load plugins with Topdirs.load_file. But it complicates the build process.
In native code versions, no problem since toplevellib.cmxa does not exist. Would it be hard to have a native version of the toplevel ?
|Moving to acknowledged since we probably want to package the compiler modules somehow.|
First wish (install more of the compiler internals) granted in 4.00.
Second wish (toplevel & dynlink that work together well) needs more work.
edited on: 2012-07-10 01:44
another use case for mixing dynlink with toplevellib, is that you can do some compile-time evaluation like D language, that's to say the user can specify which part of the program should be evaluated at compile time.
|2012-03-14 22:15||guesdon||New Issue|
|2012-03-26 15:03||xleroy||Note Added: 0007164|
|2012-03-26 15:03||xleroy||Severity||trivial => feature|
|2012-03-26 15:03||xleroy||Status||new => feedback|
|2012-03-26 22:46||gerd||Note Added: 0007177|
|2012-03-27 08:45||guesdon||Note Added: 0007180|
|2012-03-27 08:45||guesdon||Status||feedback => new|
|2012-03-29 10:49||protz||Note Added: 0007227|
|2012-03-29 10:49||protz||Status||new => acknowledged|
|2012-07-04 20:01||xleroy||Note Added: 0007637|
|2012-07-04 20:02||xleroy||Target Version||4.00.0+dev =>|
|2012-07-06 16:16||doligez||Target Version||=> 4.01.0+dev|
|2012-07-10 01:43||hongboz||Note Added: 0007673|
|2012-07-10 01:44||hongboz||Note Edited: 0007673||View Revisions|
|2012-07-31 13:36||doligez||Target Version||4.01.0+dev => 4.00.1+dev|
|2012-09-06 19:32||frisch||Target Version||4.00.1+dev => 4.00.2+dev|
|2013-07-12 17:41||doligez||Target Version||4.00.2+dev =>|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-03-03 15:34||doligez||Description Updated||View Revisions|
|2017-03-03 15:35||doligez||Category||-OCaml general => toplevel|
|Copyright © 2000 - 2011 MantisBT Group|