Previous week Up Next week

Hello

Here is the latest OCaml Weekly News, for the week of September 29 to October 06, 2015.

  1. User Report: Cygwin32 OPAM for MinGW OCaml 64
  2. Pijul 0.1
  3. Post-doctoral position available at ENSTA-ParisTech - Secure-OCaml project
  4. Jane Street's ppx rewriters
  5. Other OCaml News

User Report: Cygwin32 OPAM for MinGW OCaml 64

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-09/msg00226.html

Jun Furuse announced:
I have played a bit with Cygwin OPAM to install packages for MinGW
64bit OCaml system, and finally got succeeded to install core_kernel
by `opam install core_kernel`.  It required several fixes of
OCaml+OPAM configurations and patching to packages but now I think I
got enough know-how and share it with the community.

To use Cygwin32 OPAM smoothly for MinGW64 OCaml you need:

* /usr/bin/ar of Cygwin32 did not work for MinGW OCaml 64. I had to
use a special ar command for MinGW64.
* Many build scripts assume Unix commands.  You need to add Cygwin's
/bin directory to Windows PATH
* global-config.config and system.comp must be fixed so that directory
and paths can be understandable by MinGW OCaml, a Windows app

Many packages can be installed without any modification to them.
Therefore Cygwin OPAM is already very useful for MinGW OCaml package
installation.  However, some packages required fixes and here are some
tips:

* Use "mixed path" obtained by cygpath -m, so that the paths can be
understandable both for Cygwin and for MinGW
* Build systems like Oasis executes commands not using /bin/sh but
cmd.exe in MinGW.  _oasis or setup.ml contains lots of Unix shell
phrases like   mkdir $dir; build something  which are wrongly executed
by cmd.exe.  You need to fix them so that they can be interpreted by
sh, i.e.  sh -c "mkdir $dir; build something"
* In Unix, files in xxx.install are ignored by OPAM when they are
already installed by OPAM's install section.  However, in Cygwin, it
sometimes fails.  It is due to Cygwin's special handling of files with
.exe extension.  You need remove entries from xxx.install if they are
installed by the install section.

I hope this information helps you.  More details or work log can be
found here: https://bitbucket.org/camlspotter/opamingw
      

Pijul 0.1

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-10/msg00002.html

Pierre-Étienne Meunier announced:
Florend Becker and myself are honoured to present version 0.1 of
Pijul. Pijul is a draft of a prototype of an implementation of Samuel
Mimram and Cinzia Di Giusto's theory of patches.

Where can I learn more? Where can I find this pijul?
====================================================

Pijul's homepage is http://pijul.org ; its sources are found at "darcs
get http://pijul.org". Both are a bit rough at the moment, but should
improve rapidly, maybe with your help…

There is a mailing list (pijul@pijul.org), and an irc channel should
be setup Real Soon Now™.

Currently, pijul has a preliminary implementation of darcs' basic
commands.

What is a pijul, and how do I pronounce it?
===========================================

A pijul is a south american bird (Crotophaga sulcirostris), a relative
of the cuckoo. In contrast with its parasitic cousin, the pijul lays
her eggs in a communal nest, where they are incubated by the whole
community.

Pijul is thus pronounced as in spanish, IPA [pijul], or aproximately
pee-hhOOl (the hh is the sound at the end of scottish 'loch').

What is the Di Giusto-Mimram Patch Theory?
==========================================

Pijul's patch theory originates in this paper:
http://arxiv.org/abs/1311.3903 .

Darcs' patch theory is centered around patches, with two primitive
operations, /commutation/ and /inversion/. Compared to this, pijul's
theory revolves around files (i.e., states of the working directory at a
given point in time) as well as patches, with a /merge/ operation
between patches. In contrast with git, this merge operation is
well-defined and has all expected properties: in technical terms, it is
a /pushout/ in a category where files are the objects, and patches are
the arrows. As a consequence of this, to ensure all diverging pairs of
patches have a merge, the set of files is extended to contain normal
files as well as /files in a conflicted state/. These conflicted files
are /rendered/ into the working directory by pijul as files with
conflict markings.

Thanks to this categorical construction, the Pijul version of most
algorithms used in darcs is conceptually simple and efficient.

What colour should the bikeshed be?
===================================

Blanquiceleste
      

Post-doctoral position available at ENSTA-ParisTech - Secure-OCaml project

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-10/msg00019.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.

Sorry for multiple postings and don't hesitate to transfer this announce to
whom could be interested.

(*****************************************************************************
 *
 * Secure-OCaml - Checking safety and security properties of OCaml programs
 *
 ******************************************************************************)

Offer: postdoc
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.
      

Jane Street's ppx rewriters

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-10/msg00020.html

Jeremie Dimino announced:
I am pleased to announce the initial release of the Jane Street's ppx
rewirters. They are now all in opam, and the next release of Core will
be using them.

They are using a specific framework that we developed to ensure our
rewriters are robust against misuses of new syntaxes. However all
packages export regular ppx executables or ppx_deriving plugins, than
can be used the standard way with ocamlfind.

This is the list of ppx rewriters that we released so far:

- ppx_assert (replaces pa_test)
- ppx_bench
- ppx_bin_prot
- ppx_compare
- ppx_csv_conv
- ppx_custom_printf
- ppx_enumerate
- ppx_fail
- ppx_fields_conv
- ppx_here
- ppx_inline_test (replaces pa_ounit)
- ppx_pipebang
- ppx_sexp_conv
- ppx_sexp_value (replaces pa_structural_sexp)
- ppx_typerep_conv
- ppx_variants_conv
- ppx_xml_conv

In addition we are releasing a few libraries:

# ppx_core

This is our PPX standard library. Amongst other things it contains:

- Various open recursion classes to traverse the OCaml AST:
  Ast_traverse.{map,fold,fold_map,...}. This work extends the
  Ast_mapper.mapper record of the OCaml compiler libraries. However it
  uses names that are closer to the ones in parsetree.mli, so that is
  is easier to infer them by just knowing the parsetree. We found that
  was helpful when writing ppx related code.
- A framework for attributes and extension points. It deals with
  namespacing and make it easier to describe the expected payload.
  When used in combination with ppx_driver, it provides helpful error
  messages for users.
- Helpers for building and matching the OCaml AST. The building part
  is similar to the Ast_helper module of OCaml but with a different
  naming convention and no use of a global variable: a functor is provided
  to factorize the [~loc] argument.

# ppx_driver

This is what we use to handle all of our code rewriting. Instead of
running one process per code transformation, we crunch them all into
one executable. This has several advantages:

- probably speed, although this hasn't been benchmarked
- a simple way to see the transformed code: no need to build a complex
  command line, just run "./ppx file.ml"
- some helpers to debug code transformations

But more importantly, since the driver has knowledge of all
transformations and all supported attributes and extensions, it can:

- check that no attribute accidentally ends up being dead code
- give helpful error messages for unused attributes

For instance:

    # type t = int [@@derivin sexp]
    Attribute `derivin' was not used
    Hint: Did you mean deriving?

    # type t = int [@deriving sexp]
    Attribute `deriving' was not used
    Hint: `deriving' is available for type declarations, type extensions
    and extension constructors but is used here in the context of a core type.
    Did you put it at the wrong level?"

    # type t = { x : int [@default 42] } [@@deriving sexp_of];;
    Attribute `default' was not used

    # let%test ("name" [@foo]) = f x = 42;;
    Attributes not allowed here

This is important to us as we don't want people to waste time because
of a misspelled/misplaced attribute. Also when developing rewriters,
we found that it was quite easy to accidentally drop attributes, and
sometimes it is hard to avoid. ppx_driver notifies the user when this
happens.

# ppx_type_conv

This is the base library for all our type-driven code generators. It
is similar to ppx_deriving, but with similar requirements as
ppx_driver. Unless used with ppx_driver, ppx_type_conv will just use
ppx_deriving.

# ppx_optcomp

This is what we use for when we need conditional compilation. It's has
a cpp-like syntax, which is nice for this kind of things, and works at
the lexer level, which make it possible to use it in pattern matchings
for instance.

It is used by the lexer fronted of ppx_driver. So if used as a -pp
instead of -ppx, a ppx driver will have optcomp enabled.
      
Gabriel Scherer asked and Jeremie Dimino replied:
> Do you plan provide any backward-compatibility guarantees for
> ppx-core, or do you plan the helpers there to mirror changes to
> upstream parsetree?

Good question. Currently most of the helpers are auto-generated from
the signature of Parsetree. Using names that closely matches the ones
in parsetree.mli. These will surely change as Parsetree changes. Then
we have additional helpers with different names for common use, these
will probably be backward compatible. Going forward we'll add more
such helpers to improve compatibility between versions of the
parsetree.

You can see the interface for these helpers here:

  https://github.com/janestreet/ppx_core/blob/master/src/ast_builder.ml
  https://github.com/janestreet/ppx_core/blob/master/src/ast_builder_intf.ml

And for patterns:

  https://github.com/janestreet/ppx_core/blob/master/src/ast_pattern.ml
  https://github.com/janestreet/ppx_core/blob/master/src/ast_pattern_intf.ml

> (I think there would be a place in the ppx ecosystem for a library
> that allows users to write rewriters on their current OCaml version,
> and know that they will still compile and be useable to preprocess
> OCaml code for future versions. This may require an API with explicit
> versioning.)

Sure. But having backward-compatible helpers for building the AST
is not enough as your patterns will still break. We have [Ast_pattern]
which is often enough for matching the payload of attributes and
extensions, but it doesn't conveniently replace all pattern matchings.
      

Other OCaml News

From the ocamlcore planet blog:
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/.

Github OCaml jobs: Full Time: Software Developer (Functional Programming) at Jane Street in New York, NY; London, UK; Hong Kong
  http://jobs.github.com/positions/0a9333c4-71da-11e0-9ac7-692793c00b45

Shayne Fletcher: List comprehensions in C++ via the list monad
  http://blog.shaynefletcher.org/2015/10/list-comprehensions-in-c-via-list-monad.html
      

Old cwn

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.


Alan Schmitt