caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alan Schmitt <>
To: "lwn" <>, "cwn"  <>,
Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
Date: Tue, 03 Dec 2019 16:42:51 +0100	[thread overview]
Message-ID: <> (raw)

[-- Attachment #1.1.1: Type: text/plain, Size: 22620 bytes --]


Here is the latest OCaml Weekly News, for the week of November 26 
December 03, 2019.

Table of Contents

Irmin 2.0.0 release
How viable is delivering binaries linked to Cygwin to Windows 
Dune 2.0.0
Advanced C binding using ocaml-ctypes and dune
Upcoming breaking change in Base/Core v0.14
CI/CD Pipelines: Monad, Arrow or Dart?
Use of functors to approximate F# statically resolved type 

Irmin 2.0.0 release


Continuing this thread, samoht announced

  And there is now a follow-up blog post, explaining how to use 
  the new
  GraphQL API available in Irmin2:

How viable is delivering binaries linked to Cygwin to Windows 


mbacarella asked

  I’m in the early stages of planning a deliverable binary product 
  will run on Linux, Mac and Windows.

  My brief sniff of the air around the OCaml ecosystem says I 
  expect to target Cygwin to get Windows going (although there’s
  impressive work to get native Windows stuff done that can become 
  preferred approach in a few years).

  My experience using Cygwin as an operating environment is that 
  pretty darn sluggish compared to Linux on the same computer.

  Why is this? There’s an anecdote that says Cygwin can only fork 
  about 30-50x a second on Windows, due to how it has to adapt it 
  work within Windows’ task spawning model. (For contrast, Linux 
  achieve thousands of forks per second if you play around with 

  I understand from another product developer that when they build
  binaries to deliver to Windows/Cygwin, they actually 
  cross-compile on
  Linux because of how slowly the toolchain runs on Cygwin.

  That sounds like bad news if you want to do UNIXy things, but 
  for a
  single standalone application this might not be so bad? I assume 
  if I
  ship a deliverable to Windows/Cygwin, the end user may enjoy 
  performance, so long as I’m not spawning tons of processes or 
  on fork for multi-programming. Is this a safe assumptions?

  Any other gotchas when it comes to OCaml on Cygwin w.r.t. 

  The app pretty much has real-time gaming requirements (though 
  it’s not
  a game so can side-step worrying about access to GPUs and
  what-not). Stated another way, although my application will 
  depend on
  the POSIX layer offered by Cygwin, I expect it not to crunch 
  related stuff in the main loop.

  How has your experience gone?

John Whitington replied

  I have been shipping commercial binaries for Linux (32 and 64 
  Windows (32 and 64bit) and OS X for years. For example:

  And even static or shared libraries in binary form:

  On OS X, you need to use MACOSX_DEPLOYMENT_TARGET or similar to 
  sure your builds will run on older systems. And, in fact, you 
  need to
  use MACOSX_DEPLOYMENT_TARGET when asking OPAM to compile the 
  compiler itself. And, you will need to deal with codesigning and
  notarization. But it’s all doable.

  For linux, you may need to build under older linux versions, to 
  sure that the glibc in use is old enough. This is not an
  ocaml-specific problem. I have a 64 bit and 32 bit VM with 
  glibc versions for this purpose.

  Under Windows, there are no such backward-compatibility 
  problems. I
  use the new OCaml for windows system, which comes with OPAM, and 
  mingw-based. No cygwin remains in the final binary.

  For more obscure systems (AIX, HPUX, Sparc etc) customers 
  compile from
  source (with help from me). Not once in more than ten years has 
  cared that it was written in OCaml.

dbuenzli also replied

  remember that on the Windows native port, the Unix module 
  with OCaml is your POSIX compatibility layer. There are a few 
  points to avoid though, the list is at the bottom of [this 

[this page] 

nojb also replied

  At LexiFi our main application is developed and shipped on 
  Windows. We
  use the msvc port of OCaml. This means that you need Cygwin to
  develop, but the resulting application is fully native and does 
  depend on the Cygwin DLL. As @dbuenzli mentioned, the Unix 
  module *is*
  the POSIX compatibility layer.

  Compilation speed is slower on Windows because process creation 
  slower on Windows as a general rule, but it is manageable (our
  application has around 2000 modules + Js_of_ocaml + C bindings + 

  We don’t have any issues with runtime performance. The `Unix' 
  mentioned above implements Windows support directly without 
  through any compatibility layer and is quite efficient.

BikalGurung also replied

  There is an editor being built in ocaml/reasonml which currently
  targets windows, linux and macos -
  <>. However, the binary is native
  windows rather than cygwin derivative. So if you don’t have to 
  cygwin dependencies then native windows binary could be the way 
  to go.

  Also esy - <> makes developing
  ocaml/reasonml on windows viable.

keleshev also replied

  *TLDR*: Install the [Mingw port of OCaml 4], freely use most 
   libraries, and compile to native Windows binaries, without 

  I recommend you read the “Release notes for Windows”:

  To summarise, there are three Windows ports:

  • Native Microsoft port,
  • Native Mingw port,
  • Cygwin port.

  All three require Cygwin for development purposes. I recommend 
  the Native Mingw, as:

  • it *doesn’t* require Visual Studio (it uses a mingw fork of 
  GCC that
    “cross-compiles” native Windows executables),
  • it *doesn’t* rely on the dreaded cygwin.dll
  • it has good opam support with opam-repository-mingw:
  • it has a convenient installer:
    <> 5.

  To contrast, Native Microsoft requires Visual Studio, and 
  doesn’t have
  opam. You can still vendor pure OCaml packages, but as soon as 
  want to use some C bindings you’re in trouble, because of the 
  differences between Visual C and GCC. And everything assumes GCC

  Cygwin port is the one I don’t have experience with, but 
  the “Release notes for Windows” above it strikes me that it 
  that Cygwin was re-licensed from GPL to LGPL with static linking
  exception. So it looks like the Cygwin port could be viable for
  commercial use, but I never tried to statically linked 
  and I’m not sure what are the benefits of Cygwin port over the 

[Mingw port of OCaml 4]

dmbaturin also replied

  With [soupault 4], I decided to ship prebuilt binaries for all
  platforms including Windows. Mostly to see if I can, all its 
  users I
  know of are on UNIX-like systems and know how to build from 
  but that’s beside the point. :wink:

  I can confirm everything @keleshev says: fdopen’s package just 
  opam works exactly like it does on UNIX, pure OCaml libraries 
  trivial to install, and the binaries don’t depend on cygwin. 
  that “opam switch create” also just works, you can install 
  MinGW or MSVC compiler versions as opam switches.  I only ever 
  the Windows VM to make release builds, and the workflow is 
  exactly the
  same as on Linux where I’m actually writing code.

  My only obstacle on that path was that FileUtils lost its 
  compatibility, but I wanted to use it, so I worked with 
  @gildor478 to
  make it cross-platform again. Uncovered a bug in the 
  implementation of
  Unix.utimes in the process, but it’s hardly a commonly used 

  You can also setup AppVeyor builds. It’s not as simple as I wish 
  would be, but there are projects doing it that you can steal the 

  There’s also opam-cross-windows, but it’s very incomplete and 
  work to be practical. There are no big obstacles, it just needs
  work. While files in opam-repository-mingw are normally 
  identical to
  the default opam repository, the cross one needs small 
  adjustments in
  every package to specify the toolchain to use, so the required 
  work is
  mostly a lot of trivial but manual actions. I hope eventually it
  reaches parity with fdopen’s one and we’ll be able to easily 
  build for
  Windows without ever touching Windows.

  As of static Linux builds, @JohnWhitington’s approach can work, 
  there’s a better option if you don’t need anything from glibc
  specifically and don’t link against any C libs: build statically 
  musl. There’s a `+musl+static+flambda' compiler flavour. You 
  need musl
  and gcc-musl to install it, but after that, just build with 
  -static' flag and you get a binary that doesn’t depend on 

[soupault 4] <>

Dune 2.0.0

  Archive: <>

rgrinberg announced

  On behalf of the dune team, I’m delighted to announce the 
  release of
  dune 2.0. This release is the culmination of 4 months of hard 
  work by
  the dune team and contains new features, bug fixes, and 
  improvements . Here’s a selection of new features that I 
  find interesting:

  • New boostrap procedure that works in low memory environments
  • (`deprecated_library_name' ..) stanza to properly deprecate 
    library names
  • (`foreign_library' ..) stanza to define C/C++ libraries.
  • C stubs directly in OCaml executables

  Refer to the change log for an exhaustive list.

  We strive for a good out of the box experience that requires no
  configuration, so we’ve also tweaked a few defaults. In 
  particular, `$
  dune build' will now build `@all' instead of `@install', and
  ocamlformat rules are setup by default.

  Lastly, dune 2.0 sheds all the legacy related to jbuilder and 
  will no
  longer build jbuilder projects. This change is necessary to ease
  maintenance and make it easier to add new features down the
  line. There are a few other minor breaking changes. Refer to the
  change log for the full list. We apologize in advance for any
  convenience this might cause.


[Changelog] <>

Advanced C binding using ocaml-ctypes and dune


toots announced

  I worked on a socket.h binding last summer and had a great 
  integrating ocaml-ctypes with dune, I thought that might be of
  interest to other developers so I wrote about it:

rgrinberg replied

  This is a good article. I encourage anyone who writes C bindings 
  ctypes to study it carefully.

  A little bit of advice to shorten your dune files:

  │ (deps    (:gen ./gen_constants_c.exe))

  This line isn’t necessary. Dune is smart enough to know that 
  running a
  binary in a rule incurs a dependency on it.

        dune has a truly amazing [support for cross-compiling],
        which we do not cover here, but, unfortunately, its
        primitives for building and executing binaries do not yet
        cover this use case.

  Indeed, we don’t have any primitives for running binaries on the
  target platform. Perhaps we should add some. However, we do in 
  have some features in dune to solve this concrete cross 
  problem. As far as I understand, the goal is to obtain some 
  time values such as #define constants and field offsets for the 
  platform. This does not in fact require to run anything on the 
  compilation target. In configurator, we have a primitive
  `C_define.import' to extract this information. The end result is 
  these configurator scripts are completely compatible with cross

  Perhaps this could be generalized to work with ctypes generators 

  Funny bit of trivia: The hack in configurator required to do 
  this is
  in fact something I extracted from ctypes itself. The original 
  is [whitequark], who in turn wrote it to make ctypes itself 
  to cross compilation.

[support for cross-compiling]

[whitequark] <>

emillon then added

        This does not in fact require to run anything on the cross
        compilation target. In configurator, we have a primitive
        `C_define.import' to extract this information. The end
        result is that these configurator scripts are completely
        compatible with cross compilation.

  If anybody wants to know more about this bit, I wrote an article 
  this last year: 

Upcoming breaking change in Base/Core v0.14


bcc32 announced

  We’re changing functions in Base that used to use the 
  variant type `[ `Fst of 'a | `Snd of 'b ]' to use `('a, 'b) 
  instead. As well as enabling the use of all of the functions in 
  Either module, this makes the functions consistent with other
  functions that already use `Either.t', (currently just

  The following functions’ types will change:
  • `Result.ok_fst'
  • `List.partition_map'
  • `Map.partition_map', `Map.partition_mapi'
  • `Hashtbl.partition_map', `Hashtbl.partition_mapi'

  The type of List.partition3_map will not change:

  │ val partition3_map
  │   :  'a t
  │   -> f:('a -> [ `Fst of 'b | `Snd of 'c | `Trd of 'd ])
  │   -> 'b t * 'c t * 'd t

  We don’t have a generic ternary variant, and it doesn’t seem 
  worth it
  to mint one just for this purpose.

  Since this change is pretty straightforward, we expect that a 
  find/replace will be sufficient to update any affected call 

CI/CD Pipelines: Monad, Arrow or Dart?


Thomas Leonard announced

  In this post I describe three approaches to building a language 
  writing CI/CD pipelines. My first attempt used a monad, but this
  prevented static analysis of the pipelines. I then tried using 
  arrow, but found the syntax very difficult to use. Finally, I 
  ended up
  using a light-weight alternative to arrows that I will refer to 
  as a dart (I don’t know if this has a name already). This allows 
  static analysis like an arrow, but has a syntax even simpler 
  than a


Use of functors to approximate F# statically resolved type 


cmxa asked

  I am learning OCaml coming from F#. In F#, to calculate the 
  average of
  an array whose element type supports addition and division, one 

  │ let inline average (arr: 'a[]) : 'a
  │     when ^a : (static member DivideByInt : ^a * int -> ^a)
  │     and  ^a : (static member (+) : ^a * ^a -> ^a)
  │     and  ^a : (static member Zero : ^a)
  │     =
  │     if Array.length arr = 0 then 
  (LanguagePrimitives.GenericZero) else
  │     LanguagePrimitives.DivideByInt (Array.fold (+) 
  (LanguagePrimitives.GenericZero) arr) (Array.length arr)

  My understanding is that in OCaml, one would have a module type 

  │ module type Averagable = sig
  │   type 'a t
  │   val divide_by_int : 'a -> int -> 'a
  │   val plus : 'a -> 'a -> 'a
  │   val zero : 'a
  │ end

  My question is how the corresponding function would be written:

  │ let average arr =
  │   ???

smolkaj replied

  First, `Averagable' should look like this:

  │ module type Averagable = sig
  │   type t
  │   val divide_by_int : t -> int -> t
  │   val plus : t -> t -> t
  │   val zero : t
  │ end

  Then average will look something like this:

  │ let average (type t) (module A : Averagable with type t = t) 
  (arr : t array) : t =
  │   Array.fold arr

  (The code above uses Jane Street’s Base/Core library.)

ivg then added

  While @smolkaj’s answer is a correct and direct implementation 
  of your
  F# code, it might be nicer if your code can interplay with 
  abstractions in the OCaml infrastructure. For example,

  │ open Base
  │ let average (type a) (module T : Floatable.S with type t = a) 
  xs =
  │   Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
  │   Float.of_int (Array.length xs)

  and now it could be used with any existing numeric data in 

  │ average (module Int) [|1;2;3;4|];;
  │ - : Base.Float.t = 2.5

  and even adapted to non-numbers,

  │ let average_length = average (module struct
  │     include String
  │     let to_float x = Float.of_int (String.length x)
  │     let of_float _ = assert false
  │   end)

  The latter example shows that we requested more interface than 
  need, a
  cost that we have to pay for using an existing definition. In 
  when it matters, you can specify the specific interface, e.g.,

  │ module type Floatable = sig
  │   type t
  │   val to_float : t -> float
  │ end
  │ let average (type a) (module T : Floatable with type t = a) xs 
  │   Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
  │   Float.of_int (Array.length xs)

  But we reached the point where using first class modules is 
  unnecessary. Our interface has only one function, so the 
  definition of average, is much more natural

  │ let average xs ~f =
  │   Array.fold ~init:0. ~f:(fun s x -> s +. f x) xs /.
  │   Float.of_int (Array.length xs)

  it has type `'a array -> f:('a -> float) -> float' and computes 
  average of `f x_i' for all elements in the array.


  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

  If you also wish to receive it every week by mail, you may 

  [Alan Schmitt]

[send me a message] <>

[the archive] <>

[RSS feed of the archives] 

[online] <>

[Alan Schmitt] <>

[-- Attachment #1.1.2: Type: text/html, Size: 41191 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

             reply	other threads:[~2019-12-03 15:43 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 15:42 Alan Schmitt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-07-26 17:54 Alan Schmitt
2022-07-19  8:58 Alan Schmitt
2022-07-12  7:59 Alan Schmitt
2022-07-05  7:42 Alan Schmitt
2022-06-28  7:37 Alan Schmitt
2022-06-21  8:06 Alan Schmitt
2022-06-14  9:29 Alan Schmitt
2022-06-07 10:15 Alan Schmitt
2022-05-31 12:29 Alan Schmitt
2022-05-24  8:04 Alan Schmitt
2022-05-17  7:12 Alan Schmitt
2022-05-10 12:30 Alan Schmitt
2022-05-03  9:11 Alan Schmitt
2022-04-26  6:44 Alan Schmitt
2022-04-19  5:34 Alan Schmitt
2022-04-12  8:10 Alan Schmitt
2022-04-05 11:50 Alan Schmitt
2022-03-29  7:42 Alan Schmitt
2022-03-22 13:01 Alan Schmitt
2022-03-15  9:59 Alan Schmitt
2022-03-01 13:54 Alan Schmitt
2022-02-22 12:43 Alan Schmitt
2022-02-08 13:16 Alan Schmitt
2022-02-01 13:00 Alan Schmitt
2022-01-25 12:44 Alan Schmitt
2022-01-11  8:20 Alan Schmitt
2022-01-04  7:56 Alan Schmitt
2021-12-28  8:59 Alan Schmitt
2021-12-21  9:11 Alan Schmitt
2021-12-14 11:02 Alan Schmitt
2021-11-30 10:51 Alan Schmitt
2021-11-16  8:41 Alan Schmitt
2021-11-09 10:08 Alan Schmitt
2021-11-02  8:50 Alan Schmitt
2021-10-19  8:23 Alan Schmitt
2021-09-28  6:37 Alan Schmitt
2021-09-21  9:09 Alan Schmitt
2021-09-07 13:23 Alan Schmitt
2021-08-24 13:44 Alan Schmitt
2021-08-17  6:24 Alan Schmitt
2021-08-10 16:47 Alan Schmitt
2021-07-27  8:54 Alan Schmitt
2021-07-20 12:58 Alan Schmitt
2021-07-06 12:33 Alan Schmitt
2021-06-29 12:24 Alan Schmitt
2021-06-22  9:04 Alan Schmitt
2021-06-01  9:23 Alan Schmitt
2021-05-25  7:30 Alan Schmitt
2021-05-11 14:47 Alan Schmitt
2021-05-04  8:57 Alan Schmitt
2021-04-27 14:26 Alan Schmitt
2021-04-20  9:07 Alan Schmitt
2021-04-06  9:42 Alan Schmitt
2021-03-30 14:55 Alan Schmitt
2021-03-23  9:05 Alan Schmitt
2021-03-16 10:31 Alan Schmitt
2021-03-09 10:58 Alan Schmitt
2021-02-23  9:51 Alan Schmitt
2021-02-16 13:53 Alan Schmitt
2021-02-02 13:56 Alan Schmitt
2021-01-26 13:25 Alan Schmitt
2021-01-19 14:28 Alan Schmitt
2021-01-12  9:47 Alan Schmitt
2021-01-05 11:22 Alan Schmitt
2020-12-29  9:59 Alan Schmitt
2020-12-22  8:48 Alan Schmitt
2020-12-15  9:51 Alan Schmitt
2020-12-01  8:54 Alan Schmitt
2020-11-03 15:15 Alan Schmitt
2020-10-27  8:43 Alan Schmitt
2020-10-20  8:15 Alan Schmitt
2020-10-06  7:22 Alan Schmitt
2020-09-29  7:02 Alan Schmitt
2020-09-22  7:27 Alan Schmitt
2020-09-08 13:11 Alan Schmitt
2020-09-01  7:55 Alan Schmitt
2020-08-18  7:25 Alan Schmitt
2020-07-28 16:57 Alan Schmitt
2020-07-21 14:42 Alan Schmitt
2020-07-14  9:54 Alan Schmitt
2020-07-07 10:04 Alan Schmitt
2020-06-30  7:00 Alan Schmitt
2020-06-16  8:36 Alan Schmitt
2020-06-09  8:28 Alan Schmitt
2020-05-19  9:52 Alan Schmitt
2020-05-12  7:45 Alan Schmitt
2020-05-05  7:45 Alan Schmitt
2020-04-28 12:44 Alan Schmitt
2020-04-21  8:58 Alan Schmitt
2020-04-14  7:28 Alan Schmitt
2020-04-07  7:51 Alan Schmitt
2020-03-31  9:54 Alan Schmitt
2020-03-24  9:31 Alan Schmitt
2020-03-17 11:04 Alan Schmitt
2020-03-10 14:28 Alan Schmitt
2020-03-03  8:00 Alan Schmitt
2020-02-25  8:51 Alan Schmitt
2020-02-18  8:18 Alan Schmitt
2020-02-04  8:47 Alan Schmitt
2020-01-28 10:53 Alan Schmitt
2020-01-21 14:08 Alan Schmitt
2020-01-14 14:16 Alan Schmitt
2020-01-07 13:43 Alan Schmitt
2019-12-31  9:18 Alan Schmitt
2019-12-17  8:52 Alan Schmitt
2019-12-10  8:21 Alan Schmitt
2019-11-26  8:33 Alan Schmitt
2019-11-12 13:21 Alan Schmitt
2019-11-05  6:55 Alan Schmitt
2019-10-15  7:28 Alan Schmitt
2019-09-03  7:35 Alan Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).