Hello
Here is the latest OCaml Weekly News, for the week of September 16 to 23, 2014.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-09/msg00168.html
Jacques Garrigue announced:
This is a combined announce for new versions of LablTk and LablGTK.
LablTk is an interface for the Tcl/Tk GUI toolkit, which allows you to
build user interfaces very fast. It comes with the OCamlBrowser
library explorer, which is not only a good demonstration of the
power of LablTk, but also a useful companion in your everyday
program development.
https://forge.ocamlcore.org/projects/labltk/
Until ocaml-4.01, LablTk and OCamlBrowser were part of the
standard distribution, but they were spun off to simplify maintenance.
This new release contains a few bug fixes, and an upgrade of
OCamlBrowser for OCaml 4.02 (as a result, ocamlbrowser will
not compile on older versions).
LablGTK is an interface for the Gtk+ toolkit, version 2. It also
wraps many extensions, such as libglade, for rapid prototyping,
or gtksourceview2, for programming editors.
https://forge.ocamlcore.org/projects/lablgtk/
This is a bug fix release.
Both libraries should also soon be available on opam.
Jacques Garrigue
LablTk 8.06.0 changelog:
* Improve configuration, and allow using findlib for installation
* Fix PR#1423: Tkvars.version() call gives Fatal error
* Fix PR#1411: some void-returning functions are wrongly declared with CAMLprim
* Fix PR#1412: wrong declaration for argument of camltk_tk_mainloop
* Add command line flags in ocamlbrowser for -safe-string and -short-paths.
* Update for 4.02.
* Modify tkcompiler to allow widgets with name containing special characters.
LablGTK 2.18.2 changelog:
* Revert old commit which broke notify signals
* Quote $(FLINSTALLDIR) in Makefile (cf PR#1342)
* Update applications/browser for 4.02
* Make Float_val an alias for Double_val, since it was used
wrongly anyway (Felix Ruess)
* Make GObj.misc_ops#add_accelerator polymorphic in the widget of
the signal (Erkki Seppala)
* Use properties in GtkAdjustment, rather than direct accessors
* fix GtkTree.IconView.get_path_at_pos (Thomas Leonard)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-09/msg00169.html
Dario Teixeira announced:
I'm happy to announce release 1.0-beta1 of Lambdoc, a library providing support
for semantically rich documents in web applications, built with Ocsigen/Eliom
integration in mind. Lambdoc supports four different input markups (Lambtex,
Lambwiki, Lambxml, and Markdown) and has the ability to output a Html5 value
compatible with Tyxml or Eliom applications. For a more comprehensive list of
features and important notes concerning this first beta version, I refer you to
the blog post that announces this release:
http://nleyten.com/post/2014/09/18/Announcing-Lambdoc-1.0-beta1
And yes, Lambdoc 1.0-beta1 is already available on OPAM.
Dario Teixeira later added:
In the meantime, Török Edwin has brought to my attention that due
to a version conflict, it is impossible to simultaneously install
Tyxml >= 3.2 and Ocsigenserver, as required by Lambdoc.
The easiest solution for now is to install the dev versions of the
Ocsigen packages, available via the Ocsigen OPAM repo. Please consult
http://ocsigen.org/install for instructions.
Dario Teixeira finally said:
In the meantime I've released the beta2 version. The Lambdoc library portions
are identical to the first beta. The sole changes pertain to the lambcmd CLI
utility: I have removed the Bookaml extension support. Consequently, the package
no longer depends on Bookaml & Ocsigenserver & Lwt, and can be installed in OPAM
without requiring the Ocsigen's dev repo. (The old version of lambcmd can now be
found in the examples directory).
This new version should be available in OPAM as soon as the OPAM elfs give it
their blessing.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-09/msg00178.html
Continuing this huge thread, Yotam Barnoy asked and Anil Madhavapeddy replied:
> BTW Anil: is assemblage supposed to be an entire build toolchain, or
> is it only supposed to write makefiles (as the description in the
> readme states)?
The README in Assemblage is accurate:
https://github.com/samoht/assemblage/blob/master/README.md
> The library can be used to describe OCaml projects with static dependencies.
>
> [...]
>
> A projects description consists of a list of libraries, binaries
> and/or toplevels. Each containing a list of compilation units with
> precise (and static) dependency relationships.
>
> Using a project description, the tools can generate:
>
> • a .merlin to help edit the project;
> • a Makefile to build the project;
> • a .install to install the project; and
> • a META file to use the project.
While none currently exist, other tools could use the same
description API to generate other targets (such as OMake or Jenga)
files. This is best done after the existing APIs stabilise, which
is ongoing.
Yaron Minsky replied and Daniel Bünzli then said:
> Generating Jenga rules or OMake rules I think is note quite the right
> approach. That's because Jenga and OMake both use general purpose
> programming languages for specifying builds, and I think you'll get
> bad behavior if you try to treat that language as a compilation
> target.
>
> For Jenga, I think it's better to write a Jenga plug-in for reading
> Assemblage files. It has the same effect, but is an easier and more
> typeful programming experience than spitting out a bunch of OCaml AST.
Yes that seems much more sensitive. I'm currently working on the API
and everything will be exposed to allow you to do that. We'll just
need to figure out a way so that you can easily take a handle on the
project description value.
Usually I don't comment or advertise unfinished things but I'd also
like to point out that the goal with assemblage is also a little bit
larger than just generating a build system. I'd like to be able to
express most of the package release and installation process inside it
(or at least provide helpers to do so) in order to replace all the
ad-hoc scripts that is use now (e.g. topkg), to make quick and
flawless releases by gathering information from the right places, tags
in the vcs for version information, synchronizing opam file with
correct package dependencies, opam-submit integration etc.
Some people do find my release process complex, I basically apply
a function on a git checkout and do ugly things like a global key
value substitution on all the files, but at least it is flawless and
traceable. For example package never lie to you about their current
version, even if you pin them. The only way to get that flawlessly is
to automate it — can't count the number of times opam lied to me about
its version because its version number needs to be bumped manually.
Last year I tried the other new build systems and to influence them in
that direction (e.g. generating .install files) without much
success. I guess most people don't understand these problem as they
only publish one package or two and can afford to spend some time to
do their releases or hack an install process. I can't. That being
said, I think we should not rush on that one, it will be ready when it
is ready, (I personally soon won't have the time to work on this as
I'll have to earn my life for the winter, I can't speak for Thomas
though).
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-09/msg00173.html
Bob Zhang announced:
I have done some work to improve omake available here:
https://github.com/bobzhang/omake-fork/tree/work
Before deciding spending some time in improving omake, I have tried
various build systems.
1. ocamlbuild
ocamlbuild is really nice for small to medium projects and I have used
it pervasively in my personal projects and corporation projects. It
works pretty well in most cases.
There are mainly three drawbacks:
a. Easy things hard to do.
Even for some very trivial things, if you don't write myocamlbuild.m
for a long time, you have to google ocamlbuild API and figure it out
how to do it correctly.
b. Error messages hard to understand
It's cool that ocamlbuild detect dependencies dynamically, when it
does not work out, in general, I would turn on -verbose and search
which part goes wrong.
c. no parallellism
This is fatal and main reason that I gave it up
2. ocp-build
I tried it for my hobby project, it's not close to maturity yet.
3. jenga
Jenga looks promising, but I don't think it would be usable inside our
company, the dependency is huge, more importantly, its dependency
chain includes Camlp4 which we can not rely on. Also, looking at the
examples, it is quite verbose even for trivial projects.
omake has its own drawbacks as well, for example, the language is
overly complex and error message is hard to understand(still better
than ocamlbuild), startup speed is slow, no easy FFI interface to
write rules in OCaml language itself, but that's all we can find a way
to fix.
Yaron Minsky replied:
This is not the main point of your post, but to reply to your concerns
on Jenga:
- I'm not sure why the dependency chain of Jenga matters much. You
need camlp4 to build it, but not to use it. In any case, I expect
that in a few months, that dependency will be gone as we migrate to
extension points.
- The examples are big, but that's mostly because it takes a lot of
code to precisely express OCaml's dependency and build rules. Other
tools either hide that code from you (ocamlbuild) or have incomplete
rules that don't quite do the right thing (omake).
Note that with our Jenga rules, we do have simple build specification
files. Here's the one for async_kernel, which emphasizes how simple
these can be.
(library
((name async_kernel)
(libraries (core))))
Here's the one for async_unix, which is a little more complicated.
(library
((name async_unix)
(libraries (async_kernel
core))
(c_names (dump_core_on_job_delay_stubs))
(preprocess (((pps (JANE pa_macro)) All)))))
And here's a much more complicated one, for core:
(rule
((targets (config.mlh config.h))
(deps (discover.sh))
(action "${<} ${OCAML} ${OCAMLC} config.mlh config.h -DLINUX_EXT
-DPOSIX_TIMERS -DWORDEXP")))
(rule
((targets (version_defaults.mlh))
(deps ())
(action "echo 'DEFINE DEFAULT_VERSION = Version_util.version'
> version_defaults.mlh
echo 'DEFINE DEFAULT_BUILDINFO =
Version_util.build_info' >> version_defaults.mlh
echo 'DEFINE BUILD_VERSION_UTIL'
>> version_defaults.mlh")))
(library
((name core)
(libraries
(core_kernel
sexplib_unix
version_util_fallback))
(interfaces (core_kernel))
(extra_cflags (-D_LARGEFILE64_SOURCE))
;; We omit [-pedantic] because
;; [bigstring_recvmmsg_assume_fd_is_nonblocking_stub] in
;; bigstring_stubs.c uses variable-length arrays rather than [alloca].
(avoid_cflags (-pedantic))
(library_flags (-cclib -lrt))
(c_names
(backtrace_stubs
bigstring_stubs
crc_stubs
iobuf_stubs
linux_ext_stubs
ocaml_utils_stubs
recvmmsg
signal_stubs
syslog_stubs
time_stamp_counter_stubs
time_stubs
timespec
unix_stubs))
(preprocess (((pps (JANE pa_macro)) All)))
(preprocessor_deps (version_defaults.mlh config.mlh))))
The point is, there is a simple DSL embedded that we use for
specifying individual projects, but it's _very_ simple, with more
complicated things done by extending the build rules, in OCaml.
Really, I think this is the right design. Build DSLs are typically
horrible programming languages, and you don't want to do anything
complicated with them.
That said, it's not ready for prime time yet, mostly in that it needs
some portability work, and some work to get good default rules that
people can use externally from Jane Street, with a good story for
interacting with ocamlfind and the like.
But we'd love to have people trying it out and helping us work out
those use cases. Indeed, we've already exported a version of our
build rules that are suitable for building with OCaml 4.02:
https://github.com/janestreet/jenga/tree/master/examples/js-build-style
After much discussion, Bob Zhang then said:
I am glad there are some people who like omake. I have a full time job
right now, but I am still very interested in improving omake, it would
be nice that some more knowledgeable people would contribute(and
particular windows developer).
Currently my fork is here : https://github.com/bobzhang/omake-fork
It's in a re-factorization status .
The main things I can think about to improve omake(long term goal):
a. remove some unused struct in the omake language, add a doc string
and reflection abilities
b. make debug easier, error messages easy to follow
c. add a new backend (for example to ninja) for faster performance
d. expose an API to allow people write rules in ocaml language itself.
The short term goal is bug fix and keep it up to date with the latest
ocaml compiler
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-09/msg00186.html
Daniel de Rauglaudre announced:
I am glad to announce you the release of Camlp5 6.12 compatible with
Ocaml 4.02.1. Downloadable at http://camlp5.gforge.inria.fr/
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-09/msg00211.html
Thomas Braibant asked and ygrek replied:
> I would like to use OPAM on Windows, but the experience I got from it
> was a mixed bag. Leaving that aside, what I really want is in fact the
> ability to get the sources of some packages, compile them, install
> them, compile a piece of software and then throw away the Windows VM.
>
> I think I heard/read about someone using opam files to generate a
> script that do contains everything needed to download/install a set of
> packages automatically. Has anyone done something like
> that, or have I been dreaming?
Have a look at https://github.com/ocaml/opam/pull/1190
The fundamental limitation is that it uses current (local) state of OPAM to generate
the script, i.e. may pick up the optional dependencies that are not strictly needed etc etc.
But the idea is that one can create a fresh switch to run the bundler in.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-09/msg00222.html
Damien Doligez announced:
The rather large amount of changes in the newly released 4.02
inevitably caused some issues in the very first minor release. We
shall have a 4.02.1 bugfix release coming soon, hopefully in early
October.
Among the few issues that have now been fixed, there are a few
regressions in the new, type-safe format implementation
(Printf/Scanf/Format) -- for advanced formatting features.
There was also a regression in the *compilation time* of the
distributed OCaml compiler, which is sensibly slower than 4.01 on
multi-module programs. This is already fixed in the development
version of the compiler and will be part of the bugfix release.
Any additional testing to find and report other regressions is more
than welcome. If you have not yet tested your programs with 4.02, now
is the time to give it a try!
Thanks to Alp Mestan, we now include in the OCaml Weekly News the links to the
recent posts from the ocamlcore planet blog at http://planet.ocaml.org/.
New alpha version:
http://www.ocamljava.org/news/index.html#alpha2
Alpha2:
http://www.ocamljava.org/2014/09/22/alpha2/
Correlation Coefficient:
http://shayne-fletcher.blogspot.com/2014/09/correlation-coefficient.html
Lambdoc 1.0-beta1 released:
https://forge.ocamlcore.org/forum/forum.php?forum_id=910
Announcing Lambdoc 1.0-beta1:
http://nleyten.com/post/2014/09/18/Announcing-Lambdoc-1.0-beta1
Simplifying the solver with functors:
http://roscidus.com/blog/blog/2014/09/17/simplifying-the-solver-with-functors/
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.