Hello
Here is the latest OCaml Weekly News, for the week of June 23 to 30, 2015.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-06/msg00172.html
Andre Nathan announced:So this was mostly an experiment for me to learn how to work with PPX extensions. It's a hack that I'm sure will affect people's sensibilities about what should be done with PPX, though maybe someone will find it useful. It's far from complete so I didn't bother creating an OPAM package yet. https://github.com/andrenth/sequoia The idea is to have a safe query builder for MySQL. You map a database using an OCaml module like so: module MyDB = struct type my_table = { id : int [@sql]; name : string [@sql]; } [@@sql] end [@@sql] The @sql/@@sql attributes can take an extra string that will map to the real MySQL column/table/database names in case they differ from their OCaml names. With that definition you can then build a query: let%sql query = select t.name from MyDB.my_table as_ t Which will build the query below via `Sequoia.Select.to_string query`: SELECT `t`.`name` FROM `MyDB`.`my_table` AS `t` Variable substitution is supported using the ref syntax: let pat = Sequoia.string "a%" let%sql query = select t.name from MyDB.my_table as_ t where (t.name like !pat && t.id > 1) If you reference a database, table or column that isn't declared via the @sql/@@sql attributes or call a nonexistent MySQL function, you get a compile-time error: let%sql query = select (frob(t.name)) from MyDB.my_table as_ t => This expression has type [> `Frob of [> `Column of string list ] ] but an expression was expected of type Sequoia.Function.t The second variant type does not allow tag(s) `Frob If you try to select a column from a table that's not in a from or join clause, you get an error too: let%sql query = select MyDB.my_table.name => Table `my_table` not selected in query There are many problems though. Off the top of my head: * Everything must be lowercase; * Error reporting sucks; * You need parentheses around OCaml expressions that wouldn't be needed in real SQL; * Lots of MySQL functions are not defined yet so you'll get bogus errors; * Due to syntax clash you need stuff like "as_" or "in_"; * Need to find a way to make it work when the DB definitions are in separate files; * Conversion to string doesn't indent the query and is really parenthesis-happy. * Everybody hates MySQL.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-06/msg00168.html
Michel Mauny announced:We have a post-doctoral position available at ENSTA-ParisTech (Palaiseau, France), to be filled as soon as possible, on the Secure-OCaml project. See below for more information. (***************************************************************************** * * Secure-OCaml - Checking safety and security properties of OCaml programs * ******************************************************************************) (* * English (Voir plus bas pour une version française.) *) Offer: postdoc Publication date: June 23 2015 Workplace: ENSTA-ParisTech, Palaiseau (see http://www.ensta-paristech.fr/en/getting-ensta-paristech) Duration: from 12 to 24 months Starting: ASAP Salary: from 2200 € to 2400 € net per month (incl. social security) Mission: design and implement libraries for verifying safety and security properties of dynamically loaded OCaml code and data. Description: The Secure-OCaml project aims at adapting the OCaml language to the development of applications involving security issues. The project gathers the following industrial and academic partners: OCamlPro, SafeRiver, LexiFi, TrustInSoft, INRIA, ENSTA-ParisTech, CEA, and Trusted Labs. Among the objectives of the Secure-OCaml project, the safety of dynamically loaded code and data is a particularly important issue. In the same way as static typing ensures safety properties about statically linked code, applications shoould be able to have similar ensurance about dynamically loaded code and data. The postdoc's mission will be to study these problems and bring effective solutions that shall be made freely available to the OCaml community. This work will be realized in cooperation with INRIA-Paris and OCamlpro SAS. Profile sought: - skills in typing and compilation - strong capabilities and taste in functional programming in general and OCaml in particular - a knowledge of the OCaml compiler is an additional advantage Context of the job: ENSTA-ParisTech is a french (top ten) engineering schools, located at Palaiseau, on a campus shared with INRIA and Ecole Polytechnique. The research group "Software Safety and Reliability of Software" is part of ENSTA's Computer Science and System Engineering Department, and aims at improving techniques of development, analysis and verification of software. For more information, contact: - michel.mauny <at> ensta-paristech <dot> fr - +33 1 8187 2032 To apply, send the following documents to michel.mauny <at> ensta-paristech <dot> fr: - your resume, with a list of publications - a motivation letter - the name and address (e-mail) of two persons who could write a recommendation Applications will be received as long as the position remains available. Please check at: http://u2is.ensta-paristech.fr/members/mauny/postdoc-secureocaml.txt that the position is still available.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-06/msg00162.html
Xavier Deschuyteneer asked:I would like to develop in ocaml for ARM based embedded systems running custom Linux (build with yocto). My main questions are how to achieve this: - cross compilation (ARM/x86) - stack size control/analysis (valgrind massif tools for ocaml?) Do you have some pointers? experience?Markus Weißmann replied and Berke Durak added:
> I can offer experience in the following cases: > 1) If your system is powerful enough (e.g. rasperry pi), you can just > install the ocaml toolchain on your system and develop there on your target > system. Seconded. We did almost that for one of our projects and it works pretty well. The difference is that we didn't use QEmu, but two of our custom Q7 board (based on a Zynq ARM Cortex A9 with 512 MB RAM, see http://xiphos.com/products/q7-processor/ ). We use Yocto to generate two versions of a Linux system: the target system, and a much larger version that contains developer tools (C compiler, m4, etc.) The development system runs from microSD cards, and takes the better part of a gigabyte, while the target system has to run from < 64 megs of flash. The required run-time dependencies of the target system have to be manually configured in the Yocto recipes. We then manually install opam on the developer board, and use it to compile our OCaml code. The generated native ARM executables are then packaged into .ipks and transferred to the target Q7 board (connected to actual hardware: http://www.ghgsat.com/wp-content/uploads/2015/03/Payload-Selfie.jpg ) The packaging is done using a simple shell script that invokes ar and tar. We did try using QEmu but it's significantly slower, however it may come into play as automating the build process (using a virtual machine or dedicated hardware) is on our to do list, and build time isn't as important when it's a nightly automated build. Initially we looked into using a cross-compiler but we decided that being able to use Opam largely outweighs any possible benefit we could get from cross-compiling. And cross-compiling is often a source of headaches, even when compiling plain old C. We would have to write a lot of Yocto recipes to get it running. Note that Yocto is written in a progarmming language called Python and requires recipes to be expressed mostly the same language. To conclude, as powerful ARM systems are very cheap and plentiful these days, and since the convenience of Opam is immense, I'm not sure there is much incentive in using a cross-compiler. BTW, is there a maintained ARM cross-compiler? > 2) Another possibility would be to use qemu (scratchbox, deboostrap, ..) to > run a complete ARM-linux-root on your x64/x86 linux system via chroot. > I especially like the 2nd one, as you can use your powerful development CPU > but your software and toolchain behave nearly perfectly like you are on your > target system.Francois Berenger replied:
> Initially we looked into using a cross-compiler but we decided that > being able to use Opam largely outweighs any possible benefit we could > get from cross-compiling. If the feature request for opam called opam-mkbundle cf. https://github.com/ocaml/opam/issues/929 is implemented some day, this would allow people to ship ocaml software as source code without requiring end users to install opam.Gerd Stolpmann also replied:
> To conclude, as powerful ARM systems are very cheap and plentiful > these days, and since the convenience of Opam is immense, I'm not sure > there is much incentive in using a cross-compiler. There is when you develop for a closed system like iOS. Also, there is now arm64, and so far I know there are no boards yet. > BTW, is there a maintained ARM cross-compiler? It's in mainline, 4.02.2. It's still a little bit difficult to use, because IMHO some convenience targets are missing in the Makefile. Whitequark in his Android packages just generates a configuration and avoids the problems (see https://github.com/whitequark/opam-android/blob/master/packages/ocaml-android32.4.02.2/files/config/Makefile.in, it is in particular essential to set CAMLRUN to the host compiler's ocamlrun). For the iOS branch (not yet in mainline) we added cross-all and cross-opt targets to the Makefile (see https://github.com/gerdstolpmann/ocaml/tree/gs-4.02.2+ios). This might be easier to start with (this branch contains the changes required for the iOS assembler, but should also work for a GNU toolchain). See the build.sh script in this repo for an example how to configure and build.Xavier Deschuyteneer said and Pierre-Alexandre Voye replied:
> When i say embedded system, i really mean embedded system running on a > minimal Linux with low power CPU, not so much flash, same for the RAM. > It's similar to think that a raspberry pi is a IOT. It's not, it's mini > computer on ARM platform. In my case, it's really an embedded system, low > cpu, not so much ram, neither flash. > > And btw i know exactly how yocto works because i build myself our OS. And > that's not exactly python, it's a mix between python and bash. > We build two different distributions: one ARM and one x86 (for emulation > purpose, valgrind, etc.). and all tools(chains) associated. > This ocaml software needs to be integrated in this workflow. > > Right now, we use plain C, and yes cross compilation is a specific setup, > but it's not difficult to achieve. > The advantage right now to use cross compilation are: > We can use all the power of a real computer to build/debug/code. > I can use all the interfaces that my computer have and not my end > (embedded) system: multiple ethernet cards, bluetooth, usb, etc. > I have multiple projects to manage and all of them are not embedded > related. > > Thanks for your answer and the time spent for my question :-) > > TL;DR: i need to cross compile ocaml code to arm because my device is not > powerful enough and that's not possible in industrial purpose to change > that. So, maybe you could have a look on two differents projects : - Ocapic http://www.algo-prog.info/ocapic/web/index.php?id=OCAPIC (1) - Ocamlcc https://github.com/ocaml-bytes/ocamlcc (2) Ocapic (1) provide a caml virtual machine for a PIC, and tools to minimise code size. Ocamlcc (2) is a tool to generate plain C code from ocaml bytecode. There's risks that the code could be two large, but it can work. Of course, these way are slower because of bytecode.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-06/msg00209.html
Gerd Stolpmann announced:I rebased our development branch to 4.02.2, and did few quick tests, and everything seems to work. At this point I'd like to invite all iOS developers to check out our work, and help us finding the last bugs: https://github.com/gerdstolpmann/ocaml/tree/gs-4.02.2+ios What you get is a cross compiler for either armv7, armv7s, or arm64. See the instructions below how to install. This branch is based on Jeffrey Scofield's work to port ocaml to (32 bit) iOS. We (Gerd, Jeffrey and Mark) added support for armv7s and arm64, and tried to better adapt to the coding standards of the ocaml sources. There is an effort to merge this branch into mainline OCaml. So how to install: - You need a host ocaml compiler for Mac, and this compiler must also be version 4.02.2, and the word size must match the word size of the target (i.e. 64 bit for arm64, and 32 bit for armv7/armv7s). Please take these requirements seriously - they are checked. The host compiler must be in your PATH. - Clone: git clone https://github.com/gerdstolpmann/ocaml/tree/gs-4.02.2+ios - Look at the checked-out build.sh script. Modify the variables for platform, target, and SDK version. - Configure and build: ./build.sh -prefix /where/you/want/it - Install: make install What you get: - The installed compilers remain dependent on the host installation (so don't delete it after building). In particular, the "ocamlrun" executable of the host is still used. - The installed runtime is for the target, in particular all the libraries (such as libocamlrun.a, and libasmrun.a) - The native-code compiler ocamlopt generates executables, but you can also emit object files (-output-obj) that can be linked with any existing app. You'll also need libasmrun.a in this case. - For completeness, you can also use ocamlc -custom to generate stand-alone bytecode executables. I guess this is less interesting, and I'm not sure whether Apple would allow this format in the app store.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-06/msg00223.html
Thomas Braibant announced:The next OUPS meetup will take place on the 9th of July, at IRILL. We will have a few talks, followed by pizzas. The program of the talks is: - David Maison. Experience report: developing an heavy GUI in a lightweight client with js_of_ocaml - Fabrice Le Fessant. ocp-lldb: a new debugger for OCaml - Jeremy Yallop. Experiences with MetaOCaml in the classroom - Mathieu Boespflug. Cloud Haskell To register, or for more information, go here http://www.meetup.com/ocaml-paris/events/223036879/ (Registration is recommended, so that we can order enough food.) Thomas, for the organizers of the meetup
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-06/msg00231.html
Markus Weißmann announced:are there any libraries that implement/interface POSIX message queues? (mq_open(3), mq_close(3), mq_send(3), ..) I only found one [1] -- for which there is neither an opam nor debian package (probably because of it's potpourri style). And if there is no "standard" library, what would be the best library to push an implementation upstream to? (extunix, standard-lib, ..) regards -Markus [1] https://github.com/jimenezrick/ocaml-backpackGabriel Scherer then suggested:
Extunix would be a reasonable choice (I also thought of Ocamlnet). I would encourage you, however, to release a mq-specific library if you can (possibly depending on one of those libs for helper functions; you don't necessarily need to be self-contained). Many users are wary of large monolithic libraries, and being a library of its own will allow the features to be easier to search for in, say, the package manager.
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/. Cumulative moving average: http://blog.shaynefletcher.org/2015/06/cumulative-moving-average.html
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.