* [Caml-list] [ANN] Omod 0.0.1
@ 2018-06-13 18:07 Daniel Bünzli
2018-06-19 18:36 ` [Caml-list] [ANN] Omod 0.0.2 Daniel Bünzli
0 siblings, 1 reply; 2+ messages in thread
From: Daniel Bünzli @ 2018-06-13 18:07 UTC (permalink / raw)
To: caml-list
Hello,
I'd like to announce `omod` which provides data-driven module toplevel loaders.
Like `ocamlfind` it allows to load compilation objects and their dependencies in the toplevel. However `omod` works without additional metadata files and with top level (compilation unit) module names rather than ocamlfind package or archive names.
This means you only need to know the name of the module you want to load rather than having to remember in which `ocamlfind` package or archive it lives.
It should work well in `ocaml`, `ocamlnat`[0] and `utop`. To get started type:
```
opam install omod
```
and follow the [tutorial][1]. More information on how `omod` came to be is given below [2].
omod is ISC licensed and can be found at http://erratique.ch/software/omod
Best,
Daniel
P.S. Currently `omod` doesn't work with opam system compilers.
[0]
One issue with `ocamlnat` is that some libraries lack their `cmxs` files. E.g. the lack of `threads.cmxs` prevents the `Core` module from loading. But other ones like `Irmin`, `Containers` or `Base` do however load in `ocamlnat` via `omod`.
[1]: http://erratique.ch/software/omod/doc/Omod.html#tutorial
[2]
This is basically a dependency-less rewrite of `odig`'s toplevel loaders which will be removed from `odig`. It solves the following problems they had:
1. Too many dependencies. They brought too many dependencies in
the toplevel including `compiler-libs` which are problematic in
`ocamlnat`. `omod` has no dependency, so using it limits toplevel
scope pollution to the `Omod` module only which loads fine in `ocamlnat`.
2. Resolution for multiple load sequences. `odig` had no support for
choosing between multiple load solutions (e.g. for library
variants). `omod` has both a variant specification syntax and an
interactive mode to resolve them.
3. Slow. They were too slow on large libraries as resolution was done in
the (bytecode) toplevel itself, `omod`s performance (and API) should be
improved for scripting however it is reasonably fast for your toplevel
interactive usage.
4. Outdated information in long running toplevel sessions. They
provided no mecanism to update the package information whenever
the package install base changed.
To solve 1., 3. and 4. the `Omod` API invokes the `omod` binary with
the `load` sub-command (whose textual output you can check when you
suspect there's a problem) to find out the load sequences.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Caml-list] [ANN] Omod 0.0.2
2018-06-13 18:07 [Caml-list] [ANN] Omod 0.0.1 Daniel Bünzli
@ 2018-06-19 18:36 ` Daniel Bünzli
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Bünzli @ 2018-06-19 18:36 UTC (permalink / raw)
To: caml-list
On 13 June 2018 at 20:07:11, Daniel Bünzli (daniel.buenzli@erratique.ch) wrote:
> P.S. Currently `omod` doesn't work with opam system compilers.
omod 0.0.2 has been released and solves this problem.
See [0] for all the changes.
Best,
Daniel
[0]: https://github.com/dbuenzli/omod/blob/master/CHANGES.md#v002-2018-06-19-zagreb
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-06-19 18:36 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-13 18:07 [Caml-list] [ANN] Omod 0.0.1 Daniel Bünzli
2018-06-19 18:36 ` [Caml-list] [ANN] Omod 0.0.2 Daniel Bünzli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox