Hello
Here is the latest OCaml Weekly News, for the week of April 10 to 17, 2018.
Archive: https://discuss.ocaml.org/t/lwt-4-0-0-a-major-cleanup-of-the-repo/1838/1
Anton Bachin announced:
We are glad to announce release **4.0.0** of **Lwt**, the library providing
promises and asynchronous I/O. It is now installable from opam:
```text
opam update && opam upgrade lwt
```
Lwt faithfully follows [semantic versioning][semver], so 4.0.0 does not come
with big *new* features. Instead, the purpose of 4.0.0 is to make several
breaking changes, each relatively minor, but which add up to a major,
much-needed cleanup of the Lwt packaging and codebase. See the [full
changelog][changelog]. There are also focused summaries of each breaking change,
with instructions on how to adapt if your code is affected [[1]][summary-1]
[[2]][summary-2].
In short:
- `lwt.ppx`, `lwt.syntax`, `lwt.log` are now factored out into `lwt_ppx`,
`lwt_camlp4`, `lwt_log`.
- `lwt.preemptive` has been merged into `lwt.unix`.
- `lwt.simple-top` and `Lwt_chan` had no users and were deleted.
During Lwt 3.x.y, we also moved `lwt_ssl` and `lwt_glib` into separate repos,
substantially [clarified][ccode] Lwt's C code, and [documented][coredocs] the
Lwt core.
The result of all these changes is a much simpler, stock Dune build setup, fewer
system dependencies, and a straightforward repo structure that can be visualized
by human beings :) We hope this helps with Lwt development in the long term.
We are also announcing several breaking changes planned for Lwt 5.0.0. Most of
these will affect very few users, but one is worth mentioning here:
- `Lwt.pick`, `choose`, and similar functions [will raise
`Invalid_argument`][pick] if called with an empty list of promises. Before, they
would return a promise that was pending forever.
Again, see the [full changelog][changelog]. Please let us know if you object to
any of the breaking changes. We announce them both to warn users, and so that
users can warn *us* :)
Lwt announces all breaking changes three months ahead of time in minor (`x.Y.0`)
releases. We try to proactively find affected code in opam and [cc the
maintainers][cc]. If your code is not in opam, we recommend either reading the
changelogs of each release, announced here on `discuss.ocaml.org`, or
subscribing to the [Lwt announcements issue][announcements].
Thanks to all the contributors, listed in the 4.0.0 and 3.x.y changelogs! In
addition, the opam repository maintainers deserve thanks, as merging this
release took quite a bit of work. In particular, thanks to at least @hcarty,
@hannes, @kit-ty-kate, and @avsm.
Happy concurrent programming!
https://github.com/ocsigen/lwt
[semver]: https://semver.org/
[changelog]: https://github.com/ocsigen/lwt/releases/tag/4.0.0
[summary-1]: https://github.com/ocsigen/lwt/issues/453#issuecomment-352897664
[summary-2]: https://github.com/ocsigen/lwt/issues/453#issue-243842061
[cc]: https://github.com/ocsigen/lwt/issues/453#issuecomment-353804967
[announcements]: https://github.com/ocsigen/lwt/issues/309#issue-199212847
[pick]: https://github.com/ocsigen/lwt/pull/552#issuecomment-369740467
[ccode]: https://github.com/ocsigen/lwt/issues/407
[coredocs]:
https://github.com/ocsigen/lwt/blob/d4090b74285b937cfccb98a8e4eff295ea0d1c4d/src/core/lwt.ml#L27
Archive: https://discuss.ocaml.org/t/ocaml-port-of-js-cuid-library/1840/1
Marco Aurélio da Silva announced:
I'm happy and proud to announce the OCaml port of the famous CUID library. I've
also implemented a stressing test to ensure the _collision-resistance property_
(and also another one covering the _monotonically increasing nature_ of CUIDs).
CUIDs are quite excellent replacements for UUIDs. They're ordered by the
timestamp/counter prefix, it can improve a lot databases lookup on CUIDs as
custom primary keys.
**IMPORTANT NOTES:** This library is not thread-safe 'cause I have not
implemented a lock around the internal counter yet.
This OCaml port: https://github.com/marcoonroad/ocaml-cuid
Original (JS) library: https://github.com/ericelliott/cuid
The installation is through the following package name:
`$ opam install cuid`
For the next releases, I'm planning to implement slugs (short & weak CUIDs) and
a testing covering a _"next-CUIDs" guessing/prediction attack_ (and thus, prove
that the implementation is somehow secure while being hard to break/attack). If
such test fails, it's a signal to search out a better random generation API,
tho.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00028.html
Mukesh Tiwari asked and Gabriel Scherer replied:
> I am trying to call some Java functions from OCaml (Extracted from Coq if
> it matters). I am familiar with ocamljava [1], but it says that "*The
> generated code usually runs faster than OCaml bytecode but slower than
> native code. Memory consumption and startup time are also higher, but
> leveraging the multiple cores of a machine can help reaching the
> performance level of native code.*", and I don't want to leave the OCaml
> native code. One suggestion I got on #ocaml channel is using RPC and a
> quick Google search leads to ocaml-rpc [2]. I am wondering if experts from
> OCaml community could please give me some suggestions.
>
> [1] http://www.ocamljava.org/
> [2] https://github.com/mirage/ocaml-rpc
Remote procedure calls are a generic solution to cross-language
computations that works in many settings. It is a perfectly reasonable
thing to do.
Another option is to use Foreign Function Interfaces on both sides to do
cross-language computation in a single system process (instead of RPCs and
communicating processes). For Java, the FFI layer in the JNI (Java Native
Interface), and there exists a library to make OCaml and Java functions
communicate through the JNI (without changing the OCaml compilation
backend):
https://github.com/xavierleroy/camljava
That said, this library seems to currently lack active users, and in
particular nobody did the work of packaging it on opam (
https://github.com/ocaml/opam-repository/issues/7519 ). If you are willing
to give this library a try, it could be a useful thing to contribute.
In either cases, I would recommend being very careful in designing the
interface between Coq code and untrusted code (pure OCaml, or OCaml+Java
code using whichever coordination system). It is easy to shoot yourself in
the foot by exporting untrusted functions with an optimistic type (eg.
using the Coq function type for the untrusted functions that may not be
total / strongly terminating). If you can design the interface between Coq
and untrusted code as primarily based on exchanging ground *data* (events,
queries reified as algebraic datatypes...), with an explicit loop
orchestrating the coordination between both, you can get a system where the
correctness guarantees (or lack thereof) are much easier to reason about.
Incidentally, this design also makes the in-process data exchange more
similar to what an inter-process communication system would look like, so
it allows implement both solutions (in-process or remote communication)
against a single Coq codebase, with minimal changes.
(As an aside: the #ocaml channel is also populated by experts from the
OCaml community, so its advice is probably as good as the list.)
Xavier Clerc also replied:
For the record, the performance of ocamljava-compiled code
heavily depends on the programming style. Numerical imperative
or i/o-bound code can be on par with ocamlopt-compiled code,
while code based on exceptions for control flow or abundant indirect
calls can be slower than ocamlc-compiled code. I am afraid
extracted code is likely to fall in the second category.
It is also noteworthy that you can run into problems with extracted
code. I suspect extracted code might contain call to "Obj.magic",
as the type system of Coq is slightly more powerful than the one
of OCaml. The issue is that that OCaml-Java uses a different
memory layout, so that "Obj.magic" might not yield the same result
as in vanilla OCaml.
Best regards,
Xavier Clerc
PS: if you are able to share your code, I might be able to give you
a less generic assessment.
Mukesh Tiwari then said:
Hi Xavier, and Gabriel,
Thank you very much for reply. Let me give me general understanding of my
project. I am trying to count encrypted ballots (Additive Elgamal) which is
matrix of ciphertext. We multiply these ballots (matrices) point wise and
decrypt it to get additive final value in plaintext [2]. For encryption,
decryption and zero knowledge proof, we are using unicrypt library [3]. You
can see the encryption part in Coq as Axiom [4] and will be realized by
java functions from unicrypt library in extracted OCaml code [5]. We will
replace the Z [6] with big_int in OCaml.
I am also wondering if these things (unicrypt functionality of encryption,
decryption and zero knowledge proof) can be realized by CertiCrypt [7] ?
Best regards,
Mukesh Tiwari
[1]
https://github.com/mukeshtiwari/EncryptionSchulze/blob/master/code/ballot_mat.txt
[2] https://nvotes.com/multiplicative-vs-additive-homomorphic-elgamal/
[3] https://github.com/bfh-evg/unicrypt
[4]
https://github.com/mukeshtiwari/EncryptionSchulze/blob/master/code/EncryptionSchulze.v#L713
[5]
https://github.com/mukeshtiwari/EncryptionSchulze/blob/master/code/lib.ml
[6]
https://github.com/mukeshtiwari/EncryptionSchulze/blob/master/code/lib.ml#L74
[7] https://github.com/EasyCrypt
Xavier Clerc replied:
Thanks for sharing the details.
I am afraid OCaml-Java might not be a good fit, for at least two
(related) reasons:
- the implementation of `big_int` that ships with OCaml-Java
has been very lightly tested, and I would not be surprised if
it turned out to be buggy;
- if you do not replace type `z` with `big_int` your code will be
unbearably slow (it, of course, applies to both ocamlopt- and
ocamljava-compiled code, but the price of allocating short-lived
object is significantly higher on the JVM).
Obviously, another possibility would be to use BigIntegers from
the JDK [1]. It looks like the class contains all the primitives you
need (I only skimmed over `lib.ml`, though).
Best regards,
Xavier Clerc
[1] https://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00030.html
Richard Jones announced:
Previously ...
https://inbox.ocaml.org/caml-list/20180226142050.r5bautl4orekd3rf@annexia.org/T/
The Fedora project recently received the HiFive Unleashed U540 board,
courtesy of SiFive Inc. I thought I'd follow up the thread with
observations on how OCaml (with nojb's patch) works on the real
hardware.
From a development point of view the board is a mixed bag. It's quite
fast, but because it has no I/O ports except ethernet (no SATA for
example) it requires an awkward installation where you have a second
machine next to it acting as a file server and use NFS/NBD/iSCSI/etc
root support.
I built and tested OCaml from source on the board. There are some
test failures which I need to investigate. (See also attachments.)
I also rebuilt a selection of OCaml packages from Fedora on the board
using Fedora's ocaml 4.06 (which has nojb's patch). These rebuilt
fine so I guess the test failures don't affect real world jobs much.
Archive: https://discuss.ocaml.org/t/ann-camomile-1-0-0-is-released/1825/6
Yoriyuki Yamagata announced:
There is a bug fix release 1.0.1. You can get it from opam or
https://github.com/yoriyuki/Camomile/releases/tag/1.0.1
Archive: https://discuss.ocaml.org/t/ocaml-documentation-open-thread/1841/17
Deep in this thread, Metin Akat asked and Daniel Bünzli replied:
> Why is this not linked at: https://ocaml.org/docs/ ?
It is. The standard library documentation is part of the manual which is linked
from there.
Regarding the URL that's the old OCaml website. Regarding the `caml` name you
might want to read a bit of [history](http://ocaml.org/learn/history.html).
> Why can’t we have the docs for the various standard libraries on the same website
There are projects on the way to provide this on `docs.ocaml.org`. Note that if
you are only interested in the documentation of the libraries you install in
your opam switch, I suggest using [`odig`](http://erratique.ch/software/odig)
this will provide you the docsets for your opam install base for your offline
reading pleasure (to see a sample output of the tool head to
http://docs.mirage.io/)
Aside, it is a wonderful source of amusement to me to see people (rightly) bitch
when there's no documentation and still (unrightly) bitch when it exists because
they can't be bothered to actually make the effort to look it up. The number of
instances where I get questions about my libraries while the answers are a click
away in the API docs is astonishingly high.
Gabriel Radanne then added:
On documentation searching: in the spirit of odig's local documentation, you can
also use [ocp-browser](https://www.typerex.org/ocp-index.html#ocp-browser) which
is a small CLI tool to search your locally installed modules.
Jared Forsyth said:
I've wanted to take a whack at ocaml documentation generation for a while, and
I've come up with [docre](https://github.com/jaredly/docre). You can check out
[the example documentation
site](https://jaredforsyth.com/reprocessing//index.html) for Reprocessing to get
a feel for what it does.
Things that y'all might find interesting:
- you can have examples that run in-browser (compiled with bucklescript) & are
editable too! The [Getting
Started](https://jaredforsyth.com/reprocessing//Getting%20started.html) page has
a few of these to play with
- also, all code example blocks are compiled & run as doctests by default (you
can opt-out per-block) so they never get stale
- [out-of-the-box
search](https://jaredforsyth.com/reprocessing//search.html?search=font) w/o
relying on an external server
- you can write documentation pages that aren't connected to a module (as a
markdown file) and they are processed (the Getting Started page is one such)
- inspired by [Elm's
documentation](http://package.elm-lang.org/help/documentation-format), you have
full control over the order & placement of items within a module's documentation
page. See how the [main module for
Reprocessing](https://jaredforsyth.com/reprocessing//api/Reprocessing.html) has
the values split up into sections. (see [the
source](https://github.com/schmavery/reprocessing/blob/master/src/Reprocessing.rei#L2))
I know ocamldoc & odoc are there & powerful, but I wanted to see what I could
come up with, and I'm quite happy with the result.
Stephen Bleazard said and Bobby Priambodo replied:
> A guide to creating library documentation and interacting with the various tools
> would be great
As a response to this (and other replies on this thread) and still in the spirit
of DocJam, I came up with this:
https://github.com/bobbypriambodo/ocaml-documentation-guideline
It touches the topic of how to write docs, how to write _good_ docs, tools for
generating docs, and how to put documentations online. I'm not sure how well
this would be received but I agree that to reach a consensus, a written document
is necessary.
The intention is that this document can be referred to when you're writing or
reviewing docs, or asking contributors to write or review docs.
Note that there may be mistakes and misguided recommendations on those guide at
its current state because it's mostly my own limited knowledge, but I figured
I'd put it up anyway to give us something to improve upon. I'd love to invite
folks here to improve it by opening issues/discussions and contributing PRs to
that repo.
Archive: https://discuss.ocaml.org/t/ann-dune-jbuilder-1-0-beta20/1846/1
Rudi Grinberg announced:
On behalf of the dune team, I'd like to announce the 20th beta of dune. This
release features much improved support for odoc. The generated documentation
more closely reflects the docs generated by the
[odig](https://github.com/dbuenzli/odig) tool, and there's a new `documentation`
stanza used to attach documentation files to packages. For details, refer to the
[manual](http://dune.readthedocs.io/en/latest/documentation.html).
This release also features other goodies such as the `universe` (similar to
phony rules in make) and `package` dependency types, and quite a few bug fixes.
There are no known regressions and all users are encouraged to upgrade.
Changelog:
1.0+beta20 (10/04/2018)
-----------------------
- Add a `documentation` stanza. This stanza allows one to attach .mld files to
opam packages. (#570 @rgrinberg)
- Execute all actions (defined using `(action ..)`) in the context's
environment. (#623 @rgrinberg)
- Add a `(universe)` special dependency to specify that an action depend on
everything in the universe. Jbuilder cannot cache the result of an action that
depend on the universe (#603, fixes #255 @diml)
- Add a `(package <package>)` dependency specification to indicate
dependency on a whole package. Rules depending on whole pacakge will
be executed in an environment similar to the one we get once the
package is installed (#624, @rgrinberg and @diml)
- Don't pass `-runtime-variant _pic` on Windows (#635, fixes #573 @diml)
- Display documentation in alphabetical order. This is relevant to packages,
libraries, and modules. (#647, fixes #606 @rgrinberg)
- Missing asm in ocaml -config on bytecode only architecture is no longer fatal.
The same kind of fix is preemptively applied to C compilers being absent.
(#646, fixes $637 @rgrinberg)
- Use the host's PATH variable when running actions during cross compilation
(#649, fixes #625 @rgrinberg)
- Fix incorrect include (`-I`) flags being passed to odoc. These flags should be
directories that include .odoc files, rather than the include flags of the
libraries. (#652 fixes #651 @rgrinberg)
- Fix a regression introduced by beta19 where the generated merlin
files didn't include the right `-ppx` flags in some cases (#658
fixes #657 @diml)
- Fix error messaage when a public library is defined twice. Before
jbuilder would raise an uncaught exception (Fixes #661, @diml)
- Fix several cases where `external-lib-deps` was returning too little
dependencies (#667, fixes #644 @diml)
- Place module list on own line in generated entry point mld (#670 @antron)
- Cosmetic improvements to generated entry point mld (#653 @trefis)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00039.html
Jaap Boender announced:
Just in case it helps anyone else: I wrote a lightweight OPAM installer that
avoids the circular dependencies that opam-installer has - it depends only on
ocaml, ocamlbuild and opam-file-format.
It's a fairly rough piece of software and not very (end-)user-friendly, but I've
incorporated it into pkgsrc and it does work with all of the .install files I've
encountered there, so I'd say it works for distribution editor purposes.
Available at http://github.com/jaapb/opaline.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00040.html
Damien Doligez announced:
The release of OCaml 4.07.0 will take place in a few weeks. We have created a
beta version to help you adapt your software to the new features ahead of the
release.
The source code is available at this address:
https://github.com/ocaml/ocaml/archive/4.07.tar.gz
and the compiler is also available as the 4.07.0+beta2* set of OPAM switches.
We want to know about all bugs. Please report them here:
http://caml.inria.fr/mantis/bug_report_page.php
At about the same time as the release, we will also have the pleasure of
officially announcing the creation of the OCaml Software Foundation, a
non-profit organization dedicated to supporting OCaml, its ecosystem, and its
community. You can already enter a pledge at http://ocaml-sf.org/donate/
Happy hacking,
-- Damien Doligez for the OCaml team.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00041.html
Fabrice Le Fessant announced:
OCamlPro is a French company, located in Paris, born in 2011.
Today, OCamlPro is working mostly on three topics:
* OCaml tooling : design of development tools for OCaml (open-source
most of the time). Such tools range from command-line tools (such as
OPAM or ocp-build), tools with graphical interfaces (the OCaml
Memory Profiler) and web-based tools (TryOCaml, the OCaml MOOC).
* Formal methods : OCamlPro is involved in collaborative projects with
academia and industry to develop tools for software verification, such
the Alt-Ergo SMT Solver (from LRI).
* Blockchains : OCamlPro has been involved in the design and
implementation of the Tezos ledger. OCamlPro is now working on
tooling for Tezos (such as http://tzscan.io) and other blockchain
projects.
We are looking for passionate OCaml developers, with different levels
of skills and experience, from master to PhD++. Every developer at
OCamlPro is usually working on both long-term projects, and shorter
customer-driven projects, in many different areas of industry.
If you want to join Fabrice, Çagdas, Pierre, Louis, Mohamed, Thomas,
Pierrick, Michael, Vincent, Raja and Muriel, email your resume or
C.V. and a description of some of your accomplishments to:
contact@ocamlpro.com
http://www.ocamlpro.com/
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00042.html
moosotc announced:
Releases of muPDF 1.13.0 and ocaml 4.07.0 are right around the
corner. Monkey see monkey do - so here's a release candidate (sort-of)
for llpp.
New version of llpp is almost released and can be found at:
* http://repo.or.cz/w/llpp.git
* https://github.com/moosotc/llpp/
============================================================================
Blurb
llpp is a graphical PDF viewer, which aims to superficially resemble
less(1)
============================================================================
Changes (relative to v26b)
* unified build-system
https://groups.google.com/forum/#!msg/shake-build-system/2gQM0YDyDNs/DOKYnkWwCAAJ
* man pages (Hendrik Rosendahl, big thanks to him)
* improved font viewer via llppac
* new videos
https://www.youtube.com/watch?v=qNszKpCUXhQ&list=PLLAukRknwSgFhpYsDKHY0oWpvV03Qj4AE
* bootstrap script (not yet fully operational) that will automagically
fetch and build everything that is needed (ocaml, mupdf)
* bugfixes
Summary v26b..HEAD
1 Florian Stecker
2 Hendrik R
1 Nicolas Ojeda Bar
2 Nicolás Ojeda Bär
280 malc
Diffstat v26b..HEAD
.dir-locals.el | 2 +-
.gitignore | 3 +
BUILDING | 39 +-
KEYS | 7 +-
Shakefile.hs | 228 --------
Thanks | 3 +-
build.sh | 326 ++++++++---
config.ml | 102 +++-
diag.h | 8 +
glfont.c | 51 +-
link.c | 1062 +++++++++++++++---------------------
main.ml | 363 ++++++------
main_osx.m | 100 ++--
man/asciidoc.conf | 17 +
man/llpp.man | 136 +++++
man/llppac.man | 41 ++
man/llpphtml.man | 32 ++
misc/{Info.plist => Info.plist.sh} | 6 +-
misc/bootstrap.sh | 36 ++
misc/completions/llpp.in | 2 +
misc/llppac | 246 ++++++---
misc/llpphtml | 28 +
misc/prince.css | 14 +-
misc/wikipedia/wiki2.css | 21 +-
mkhelp.sh | 15 -
todo.org | 20 +-
utils.ml | 23 +-
wsi/x11/wsi.mli => wsi.mli | 1 -
wsi/osx/wsi.ml | 1 -
wsi/osx/wsi.mli | 64 ---
wsi/x11/wsi.ml | 24 +-
31 files changed, 1631 insertions(+), 1390 deletions(-)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00043.html
careers announced:
Tezos is a self-governing blockchain and smart-contract platform written in
OCaml. Tezos' self-governance allows it to evolve in a decentralised manner
by enabling collective decision making.
The development of the project is centred around different areas, such as
distributed systems, peer to peer systems, theory of programming languages,
cryptography and formal methods.
We are currently filling 40 open positions world-wide, including 25 in
France and are looking for a range of profiles, with a preference towards
PhD holders.
Possibility of PhD funding for Master students in France.
Mastering of a functional language such as OCaml (obviously), Haskell or
Closure is particularly desirable, as are proven skills in one or more of
the following topics: algorithmics, compilers, design of programming
languages, cryptography, p2p, web programming / UI in OCaml, SAT / SMT, or
formal verification.
Attractive compensation.
If you are interested, please send your CV (resumé) to careers@tezos.com!
Archive: https://discuss.ocaml.org/t/sightings-of-ocaml-around-the-web/1867/1
Yotam Barnoy announced:
I thought it would be nice to have a list of sightings of OCaml blog postings,
social media, video and such around the web. This way, we can show proper
support and appreciation to people who create this content, and make sure they
get an audience.
Feel free to add whenever you come across something. Reason posts are ok too, I
think, as long as they're not too javascript-oriented, since that would prevent
average OCamlers from following.
I'll start off with a neat medium post I found by @bobbypriambodo via reddit:
[Starting an OCaml app project using
Dune](https://medium.com/@bobbypriambodo/starting-an-ocaml-app-project-using-dune-d4f74e291de8).
Nice post, Bobby!
Yotam Barnoy then added:
I should also include Bobby's earlier medium articles, [Getting Your Feet Wet
With
OCaml](https://medium.com/@bobbypriambodo/getting-your-feet-wet-with-ocaml-ea1045b6efbc)
and [Lightweight OCaml Docker Images with Multi-Stage
Builds](https://medium.com/@bobbypriambodo/lightweight-ocaml-docker-images-with-multi-stage-builds-f7a060c7fce4),
which mixes some OCaml setup with Docker-fu.
Sorry for posting these out of order -- keep it up!
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00047.html
Gerd Stolpmann announced:
a new version of findlib is available:
- Fix build with upcoming OCaml-4.07.
- The installation of graphics/META is now optional.
- Fix "ocamlfind query -d".
- The environment variable OCAMLFIND_IGNORE_DUPS_IN is now interpreted as a
list of directories.
- Packages for "ocamlfind query" may now be separated by commas, too.
- New "warning" property for packages.
- Forgetting to pass -thread/-vmthread only prints a warning now, but doesn't
stop the build.
- For dealing with case-sensitive filesystems it is now only tried to match
ASCII characters, but not encoding-dependent characters.
As usual, the details are available here:
http://projects.camlcity.org/projects/findlib.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-04/msg00051.html
Deep in this thread, Bruno Blanchet said:
I implemented a stack allocator for OCaml 1.05 during my PhD (a long time
ago). If you want to have a look it is available at:
http://prosecco.gforge.inria.fr/personal/bblanche/escape-eng.html
Stack allocation can be considered as a particular case of
region allocation.
I can give a bit of feedback on this topic:
- There is sometimes a gain in using stack allocation,
but a very small one (<5%). It comes from reduced GC time and better
data locality (so better cache behavior).
This is because the OCaml GC is very good at dealing with
short lived data: they have almost no cost, since they are
already dead when collecting the young generation, so they
do not need to be copied.
This point might be a bit different with region allocation,
because you might hope to allocate long lived data in regions.
- The analysis required to do stack allocation is non trivial.
Doing that represents a lot of investment.
This is certainly also true for region allocation.
- If you want the analysis to be fully automatic, you
would certainly need to keep a GC: it is unlikely that
an automatic analyzer would manage to allocate all data
in regions, without having memory leaks.
- As already said before, there is no hope to have the whole
GC time go away.
If your goal is just performance, given the small gain and the effort
required to make the static analysis, my feeling is that in practice,
it is not worth it. You have more to gain by optimizing
other aspects of your algorithm.
There are situations in which you do not want to have GC at all
(e.g. hard real time software). In that case, using other
allocation techniques makes sense, but an automatic region
analysis may not be sufficient: you would probably need
annotations to help the analyzer, so that the GC is not
needed at all.
Oleg also said:
I believe no discussion of region memory can proceed without
mentioning the following paper:
author = {Tofte, Mads and Birkedal, Lars and Elsman, Martin and Hallenberg, Niels},
title = {A Retrospective on Region-Based Memory Management},
journal = j_hosc,
year = 2004,
volume = 17,
number = 3,
pages = {245--265},
https://www.semanticscholar.org/paper/A-Retrospective-on-Region-Based-Memory-Management-Tofte-Birkedal/0f091484790fc7a4807c3bf4d6019db63d1d4097
I have nothing more to say about this paper except that it is a must
read. See specifically ``Things we believe work well'' and ``Things
that have disappointed'' near the end of the paper.
Here is a sneak peek at some potential future features of the Ocaml
compiler, discussed by their implementers in these Github Pull Requests.
- Multi-indices for extended indexing operators
https://github.com/ocaml/ocaml/pull/1726
Here are links from many OCaml blogs aggregated at OCaml Planet,
http://ocaml.org/community/planet/.
Taskforce on the Tezos Protocol, and Tzscan evolution
http://www.ocamlpro.com/2018/04/13/taskforce-on-the-tezos-protocol-and-tzscan-evolution/
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.