Here is the latest Caml Weekly News, for the week of May 24 to 31, 2011.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-05/msg00147.htmlGregory Bellier announced:
I'm pleased to announce this new release of Fdinfo version 0.2.1. Fdinfo is a small library to get the current offset and flags of files opened by another process. Feel free to review, comment or participate if you like, I would appreciate it: https://github.com/gbe/FDinfo
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-05/msg00154.htmlDaniel Bünzli announced:
I grew tired of the Arg module. For a quick and easy way to make your functions available from the command line you may be interested in Cmdliner : Cmdliner is a module for the declarative definition of command line interfaces. It provides a simple and compositional mechanism to convert command line arguments to OCaml values and pass them to your functions. The module automatically handles syntax errors, help messages and UNIX man page generation. It supports programs with single or multiple commands (like darcs or git) and respect most of the POSIX and GNU conventions. Cmdliner is made of a single, independent, module and distributed under the BSD3 license. Project home page : http://erratique.ch/software/cmdliner The basics section of the documentation can be read as tutorial introduction: http://erratique.ch/software/cmdliner/doc/Cmdliner#basics Your feedback is welcome. Daniel P.S. The examples use syntactic constructs only available in 3.12 however I took care not to use them in the implementation of Cmdliner itself.Gabriel Scherer asked and Daniel Bünzli replied:
> - I'm not sure the presentation "oh it's just an applicative functor" is the > most accessible to the wider OCaml community. That said, your examples do a > rather good job at explaining how it's used, so maybe the scary words > upfront are not so much of a problem. As you saw, no knowledge of this is needed. Maybe you are right that this info doesn't belong here but OTOH I may help programmers who know what it means. It was also an opportunity to link to an interesting paper. > - I wasn't able to understand why you specifically chose an applicative > functor. Me neither. I realized after thought that this was an applicative functor. Although I can now hint why I turned that way (see below). > Intuitively I would see this rather as a Reader (or Env) monad over > the (parsed, typed) "parameter state" of the program. I didn't want to see this interaction as reading from an environment. I wanted to see that as follows. When I invoke a command on the command line I invoke a function and the command line arguments are the arguments to the function. In my function I don't want to work with special types representing command line arguments, if my function needs an int then it should be a regular int, not something from which I can extract an int. So the idea was that to turn the problem inside-out. Instead of working with special types representing command line arguments, lift your bare function in an applicative functor that handles and hides the extraction of OCaml values from the command line arguments. > Given that monads are > more popular and widely used, and that the monadic interface is richer than > the applicative functor one, I'm wondering why you made that choice. It > would be ok if this is not a monad (I think only structures that are > explicitely *not* monads should be presented as applicative functors), but I > don't see why your type isn't. Maybe this should be documented. First I always try to work with the weakest assumptions and applicative was enough. Second monad is just applicative + bind and I don't see for what you would like bind here. In cmdliner terms are just a way to hide the command line parsing machinery to our function that need regular OCaml values. It turns out that this is exactly Applicative's domain, embed pure computations in an effectful world (the parsing machinery). > - Term.eval_choice use a (info * 'a) associative list, while varg_* use ('a > * info) lists. I'm not sure why you made different choices. Not sure either. Can't remember. Maybe because of the order of arguments in Term.eval. > Actually I don't understand what "vflag" is. It's a single value that can be defined by different flags. Maybe have a look at the rm example. http://erratique.ch/software/cmdliner/doc/Cmdliner.html#examples It uses vflag_all which is like vflag except that the flags are allowed to repeat. > - I think the "predefined converters" are mostly orthogonal to the rest of > the interface, and would possibly benefit of being factored out as a > separate module, or even an external "extra" library; they should certainly > be in any reasonable "extra standard library" (Extlib, Core, Batteries, > whichever you like) and you could/should propose them upstream to those > libraries if they are not. I think it would defeat the "quick and easy" way intended by the library. Besides having them in the Arg module allows more concise definitions if you program in OCaml 3.12, e.g. : let count = Arg.(value & opt int 10 & info ["c"; "count"] ~docv:"COUNT" ~doc) > - The converter interface seems a bit simplistic and unsatisfying. In > particular, parsers being (string -> 'a) functions, The converter interface is certainly simplistic but I didn't find it unsatisfying in practice. Take that as a stance to keep your command line interfaces simple and reasonable. > compose different parsers. I just had a look at the implementation and, for > pairs for example, if I understand correctly you split the input string on > "," beforehand, then call the parser on both parts. Yes. Note that you don't have to look at the implementation. You can just read the documentation : http://erratique.ch/software/cmdliner/doc/Cmdliner.Arg.html#VALpair > This seems wrong: > Â - there seems to be an associativity issue, if I build (pair (pair int > int) int) and pass "1,2,3", it will try to parse "1" with (pair int int); so > we would need delimiters here > Â - what if I pass a quoted string that contains a comma? Implement a better parser... Given the generality of the parser interface you are allowed to invoke whatever parsing technology suits you. > - Your build system (handcoded make-like script) is a bit unusual. Maybe it > be better for the principle-of-least-surprise if you had a Makefile just > redirecting the obvious actions to your funny build script. I first tried > (yes, I should read the README first) to run "oasis", but this failed as the > _oasis file is syntactically invalid due to the %%FOO%% configuration > variables. I'm unsure what is the benefit of having those configuration > variables in your build script rather than in the _oasis, but I understand > this is a highly subjective thing. I do proper software releases (yes I'm old fashioned I don't just push a repo on github). If you see the %%FOO%% variables it means that you are trying to use the repository version and you shouldn't; use the tarballs. These variables are here so that I don't have to repeat myself. That said the _oasis file in the distribution 0.9.0 has a syntax error. If you download from oasis-db you will get one without the syntax error (I know that you should not publish two tar balls pretending to be the same thing that differ in content, I permitted myself this misstep because the current ocaml-db is "experimental" and will be destroyed). Regarding the "funny" build script, it may eventually disappear if I finally get serious about using oasis. > On a more open-ended side, I wanted to report that I have done a related > thing for a prototype, with a slightly different twist: I needed a > description of configuration options that would support both a command-line > interface (for which I reused the Arg module), and configuration directives > in an interactive toplevel: "#set +debug;;". I don't suppose you would or > should be interested in extending your interface to support such a thing, > but this is food for thought anyway. Without thinking too much about it I don't think it would *need* to be extended. > Finally, I had a different approach wrt. option/commands spelling. If I > understand correctly, you accept an input if and only if it is a valid > prefix of only one valid option/command. Yes. > It may still be useful to suggest the correct option when rejecting the > spelling, à la git "Did you mean this ?". That could be nice. But I have to admit, I spent far too much time on solving (for me) the mundane problem of command line argument parsing so don't expect that anytime soon. Well written patches are, however, welcome.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-05/msg00161.htmlJoel Reymont said and Sylvain Le Gall announced:
> We have 13 executables in _oasis and some libraries. That's 14 > invocations of ocamlbuild, loading of the dependency graph. > > That's also 14 checks to see if the target binary has changed by > manually reading and comparing both binaries, plus 14 copies if source > (built by ocamlbuild) changed. > > Our top-level project makefile runs 'make' to build and then 'make > test' to run the unit tests. This is 28 invocations of ocamlbuild and > a pain in the rear during development. > > After applying the patch and making sure that 'Executable foo' matches > 'MainIs: foo.ml', we now have 1 and 2 invocations of ocamlbuild > respectively. Needless to say, we are very happy. > I just release oasis 0.2.1~alpha1: https://forge.ocamlcore.org/frs/download.php/626/oasis-0.2.1~alpha1.tar.gz It contains quite a few bug fixes, especially a version of the speed up you describe.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-05/msg00163.htmlJun Furuse announced:
I've released a small monadic parser combinator library for OCaml, Planck version 1.0.0, available at: https://bitbucket.org/camlspotter/planck/get/v1.0.0.tar.gz It is firstly just for my fun to learn what is Parsec/parser combinators, but it is now elaborated to something useful: - input positions by lines and columns - char specialized stream for better performance - operator precedence/associativity resolver - memoization module for efficient backtracks For example I could implement OCaml syntax lexer and parser using Planck. REQUIREMENTS: unfortunately Planck depends on many things: - ocaml 3.12.0 or higher - findlib - omake - type-conv 2.3.0 and sexplib 5.2.1 (available from http://ocaml.janestreet.com/?q=node/13) - spotlib (my small utility functions, available at http://bitbucket.org/camlspotter/spotlib/) The followings are required to compiler ocaml syntax parser example: - pa_monad_custom (http://bitbucket.org/camlspotter/pa_monad_custom/) - ocaml 3.12.0 source tree and lablgtk-2.14.2 source code tree for testing The combinators in Planck are implemented simply as functional monadic combinators over streams (lazy lists). Unfortunately, it is very slow with the current OCaml compiler (3.12.0) due to its huge closure constructions: it is about x100 slower than the traditional ocamllex+ocamlyacc. I hope more aggressive in-lining optimizations in the compiler might speed up the performance of Planck greatly. You can read some of my rough considerations in this topic at: http://camlspotter.blogspot.com/2011/05/planck-small-parser-combinator-library.html
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/. ocaml-iteratees 0.3 released: https://forge.ocamlcore.org/forum/forum.php?forum_id=794 Stone Duality for Skew Boolean Algebras with Intersections: http://math.andrej.com/2011/05/30/stone-duality-for-skew-boolean-algebras-with-intersections/ Crowdsourcing the syntax: http://dutherenverseauborddelatable.wordpress.com/2011/05/30/crowdsourcing-the-syntax/ OCI*ML: Minor updates: http://gaiustech.wordpress.com/2011/05/28/ociml-minor-updates/ Cmdliner 0.9.0: http://erratique.ch/software/cmdliner Cairo: https://forge.ocamlcore.org/projects/cairo/ OCI*ML new feature: AQ: http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-aq/ L-BFGS: https://forge.ocamlcore.org/projects/lbfgs/ A few Opa applications: http://dutherenverseauborddelatable.wordpress.com/2011/05/24/a-few-opa-applications/
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.