Here is the latest OCaml Weekly News, for the week of March 03 to 10, 2015.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-03/msg00016.htmlFrançois Bobot asked:
I'm wondering how people are handling dependencies between libraries dynamically linked. Even if many libraries compile a cmxs and have in their META file `archive(plugin,native)=...`. I know only one tool that uses this information: the ocsigen server. The code to gather all the cmxs or cma is not hard to write, thanks to findlib: https://github.com/ocsigen/ocsigenserver/blob/master/src/baselib/ocsigen_loader.ml#L165 Does someone wrote a library that does that? Gerd, do you think that something that does that could be added to ocamlfind? One tricky thing is to know the library statically linked (ie. `Ocsigen_config.builtin_packages`), perhaps ocamlfind can during linking add this information.Gabriel Scherer replied:
Maxence Guesdon's static blog/website generator Stog ( https://zoggy.github.io/stog/index.html ) supports dynamic plugins, and its loading code is available at https://github.com/zoggy/stog/blob/e83c363c83465a7bfd1595816b3d9bc8331af560/stog_dyn.ml#L119-L146 It also uses ocamlfind, but through the command-line rather than the Findlib library.François Bobot then said and Maxence Guesdon replied:
> Thank you for the pointer. His code is even able to create cmxs from > cmxa if needed! Warning, as you see according to the name: it's a hack :) This discussion is an opportunity to call every library developer to compile and install .cmxs files, *please*.Gerd Stolpmann replied to the OP and François Bobot then said:
(please see the archive link for the patch) >> Gerd, do you think that something that does that could be added to ocamlfind? One tricky thing is to >> know the library statically linked (ie. `Ocsigen_config.builtin_packages`), perhaps ocamlfind can >> during linking add this information. > > I think so. For toploops, there is already code that tracks libraries > already linked into the executable (i.e. if you ocamlmktop your > toploop). All was already in place indeed! It was easy to add. I kept caml-list in CC for discussing the big picture in order to get comments from people. Is mail still your preferred way of receiving patch? I kept it simple, no hack (no automatic: cmxa -> cmxs) because I prefer problems in library META to be found than to be paper over. The first patch adds: - A library `findlib.dynlink` that depends on `findlib` and `dynlink` - During linking (using `ocamlfind ocaml*`) if `-package findlib.dynlink` and `-linkpkg` are used then a module `Findlib_initl...` is linked after all packages and it stores the names of packages linked in `Findlib.linked_packages`. - In the main program `Fl_dynlink.load_packages ["yojson"]` can be used to dynlink packages The second patch forbids to run `Fl_dynlink.load_packages` during the initialization of packages (statically or dynamically linked), because `Findlib_initl...` is not yet run and because if you want to load a package that depend on a statically linked package not yet initialized, there is no sane semantic. Problems: - The package is named `findlib.dynlink`, the archive `findlib_dynlink.cm*` and the module `Fl_dynlink` ... - If you don't use `-linkall` static packages could only be partially linked, and you can't link the remaining part later. So perhaps `-linkall` must be automatically added if `findlib.dynlink` is used. - If you define `archive(native)` and not `archive(native,plugin)` the error is not nice (in Dynlink.Error). Perhaps I should add a `Package_not_dynamically_loadable of string` error, that should catch the loading of something else than `*.cmxs`. - Often you link your binary with your own library without using `-package` (the library is not yet installed), and plugins for your tools depend on your library. Currently you should do before any `Fl_dynlink.load_packages`: `Findlib.linked_packages := "mylib"::Findlib.linked_packages`. For simplicity, I don't know if I should add a function `Fl_dynlink.add_linked_packages`, or an option to ocamlfind `-additional-package-statically-linked `. - During the initialization of your own library (linked without -package) you should not use `Fl_dynlink.load_packages`, but the library doesn't protect you against this error. Choices: - If you don't link with `findlib.dynlink` or use `create_toploop`, the variables `Findlib.linked_packages` and `Findlib.linked_predicates` are empty because I don't wanted to add backward change by adding `Findlib_initl...` when `findlib` is linked. Remains to do: - Fix problems - Documentations (add `plugin` in the list of standard predicates, ...) Gerg, what do you think of this first version of the patch? Of the way to fix the problems?Sebastien Mondet also replied to the OP:
We have also some code doing that there: https://github.com/hammerlab/ketrew/blob/master/src/lib/pure/ketrew_plugin.ml#L52 One of the tricks used is that, at configure time, the list of findlib packages already linked is given to the library itself to avoid double loading.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-03/msg00029.htmlDamien Doligez announced:
============================================================================== OCAML 2015 The OCaml Users and Developers Workshop http://ocaml.org/meetings/ocaml/2015/ Vancouver, British Columbia, Canada September 4, 2015 CALL FOR PRESENTATIONS Co-located with ICFP 2015 Sponsored by SIGPLAN Talk Proposal Submission Deadline: May 18, 2015 ============================================================================== The OCaml Users and Developers Workshop brings together industrial users of OCaml with academics and hackers who are working on extending the language, type system and tools. Previous editions have been colocated with ICFP 2012 in Copenhagen, ICFP 2013 in Boston, ICFP 2014 in Gothenburg, following the OCaml Meetings in Paris in 2010 and 2011. OCaml 2015 will be held on September 4, 2015 in Vancouver, colocated with ICFP 2015. Scope ===== Discussions will focus on the practical aspects of OCaml programming and the nitty gritty of the tool-chain and upcoming improvements and changes. Thus, we aim to solicit talks on all aspects related to improving the use or development of the language and of its programming environment, including, for example: - compiler developments, new backends, runtime and architectures - practical type system improvements, such as (but not limited to) GADTs, first-class modules, generic programming, or dependent types - new library or application releases, and their design rationales - tools and infrastructure services, and their enhancements - prominent industrial uses of OCaml, or deployments in unusual situations. Submission ========== It will be an informal meeting, with an online scribe report of the meeting, but no formal proceedings. Slides of presentations will be available online from the workshop homepage. The presentations will likely be recorded, and made available at a later time. To submit a talk, please register a description of the talk (about 2 pages long) at https://www.easychair.org/conferences/?conf=ocaml2015, providing a clear statement of what will be brought by the talk: the problems that are addressed, the technical solutions or methods that are proposed. If you wish to perform a demo or require any special setup, we will do our best to accommodate you. Schedule ======== Monday 18th May (any time zone) Abstract submission deadline Monday 29th June Author notification Friday 4th September 2015 OCaml Workshop ML family workshop and post-proceedings ======================================= The ML family workshop, held on the previous day, deals with general issues of the ML-style programming and type systems, and is seen as more research- oriented. Yet there is an overlap with the OCaml workshop, which we are keen to explore, for instance by having a common session. The authors who feel their submission fits both workshops are encouraged to mention it at submission time and/or contact the Program Chairs. As another form of cooperation, we are considering combined post-conference proceedings of selected papers from the two workshops. The Program Committees shall invite interested authors of selected presentations to expand their abstract for inclusion in the proceedings. The submissions would be reviewed according to the standards of the publication. Program Committee ================= The program committee will be announced very soon. If you have any questions, please e-mail: Damien Doligez <ocaml2015 AT easychair DOT org>
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-03/msg00032.htmlSébastien Hinderer asked:
Does anybody here know about pycaml's maintainance status, please? Being involved in a project that depends on it, I'd be happy to participate to its maintainance but am not sure how to do since it's not clear to me who maintains the project currently, if there is someone maintaining it at all. More generally speaking, is there interest in bridging OCaml and Python? Are other solutions (perhaps more maintained) than pycaml arond?Drup replied:
Are we talking about http://sourceforge.net/projects/pycaml/ ? I'm surprised the project actually works at all. The last version is from 2004, and iirc, it was already not working 4 years ago. I'm pretty sure you can adopt it. The work to update it may be significant. As far as I (and opam) knows, there are no other choices currently. I think Jeremy Yallop had plans for pytypes, similar to https://github.com/ocamllabs/ocaml-ctypes but for python.John Whitington also replied:
Unmaintained, and entirely special-purpose, but this vector graphics renderer, which I wrote a long time ago, links an OCaml binary to a wxpython GUI, sending ocaml-rendered fragments over a pipe, and mouse clicks etc back. It seemed to work fine, but it didn't have a general purpose ocaml-python data bridge. https://github.com/johnwhitington/coherence-renderer Screenshot: http://coherentpdf.com/renderer.png See the camlpy.ml and mltalk.py files. It can be started either by running the OCaml or the Python part... You need camlgpc and camlpdf OPAM packages to build.Nils Becker also replied:
there is also this: https://sites.google.com/a/furuse.info/jun/hacks/opycaml which seems to be a reworked version of pycaml, last updated 01-2014. i'm interested but have not used it.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-03/msg00066.htmlAlain Frisch asked:
Following a feature request by whitequark and a pull request by Jérémie Dimino, we're considering two related changes to attributes: - Their precedence on type expressions, so that "int * int [@foo]" is parsed as "(int * int) [@foo]" instead of "int * (int [@foo])". - Their placement on constructor/field declaration, so that one would write "A of int [@foo]" or "a : int [@foo]" instead of "A [@foo] of int" or "a [@foo] : int". References: - http://caml.inria.fr/mantis/view.php?id=6612 - https://github.com/ocaml/ocaml/pull/152 There seems to be a strong support in favor of the change (at least, nobody objected to it on principle). But it can clearly break or change the interpretation of existing code. I'm still in favor of doing the change as soon as possible. So my question is: would anyone be negatively impacted (or just shocked) if the change was done as part of the next bug fix release (4.02.2)?Maxence Guesdon replied and Alain Frisch then said:
> I'm quite "shocked" as it becomes inconsistent with other precedences > in type definitions. By now > int * int list > is parsed as > int * (int list) > and not as > (int * int) list > > I would expect attributes to be associated the same way. Attributes really don't behave as type constructors; for instance, (int, int) [@foo] is not allowed in type expressions. I'd be more concerned about how attributes behave across various syntactic categories for similarly looking fragments. For instance, in expressions x * y [@foo] is already currently parsed as (x * y) [@foo] But - "x, y [@foo]" is parsed as "x, (y [@foo])" - "x * y [@foo] * z" is accepted as an expression, and parsed as "(x * y)[@foo] * z". > How would be parsed the following: > int * int [@foo] * int > ? This would be rejected. Doing the same as for expression would be weird, since * is a n-ary construction in types, not a binary operator. (Note: Jérémie prepared a nice table in his pull request 152 on Github; it shows how various forms are interpreted currently and after the change.)Maxence Guesdon then said and Leo White replied:
> If I understand, you mean that > type t = int * int [@foo] * int > would be rejected and we use instead: > type t = int * (int [@foo]) * int > > Again, it's really not natural to me. I haven't looked at the patch closely, but it seems roughly consistent with how "as 'a" is handled. This makes sense to me, since in both cases you are attaching additional information to the type.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-03/msg00074.htmlLeonardo Laguna Ruiz announced:
I would like to share the initial release of my Firmata library for Ocaml. You can find the source code in: https://github.com/modlfo/firmata The Firmata library allows you to connect to any board supporting the Firmata protocol (for example Arduinos) and use them as data acquisition board. You can, for example, read values of sensors, control servo motors and read and write digital values directly from you favorite programming language (Ocaml). I have tested this library not only in Arduinos but ChipKit and Teensy boards. You can find more information about the Firmata protocol in http://firmata.org I’m currently using this library in the Raspberry Pi to control small robots and other educational projects.
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/. Heap sort: http://shayne-fletcher.blogspot.com/2015/03/heap-sort.html Centralizing distributed version control, revisited: https://blogs.janestreet.com/centralizing-distributed-version-control-revisited/ Hacker (Node.js, NOSQL, Data Science) at Mobitrans (Full-time): http://functionaljobs.com/jobs/8793-hacker-nodejs-nosql-data-science-at-mobitrans Cumulus and ocp-memprof, a love story: http://www.ocamlpro.com/blog/2015/03/04/ocp-memprof-cumulus.html Full-Stack Senior Functional Web Engineer at Front Row Education (Full-time): http://functionaljobs.com/jobs/8792-full-stack-senior-functional-web-engineer-at-front-row-education
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.