OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of October 15 to 29, 2019.

Sorry for the hiatus last week, I was away with no internet access.

Table of Contents

MirageOS 3.6.0 released

Archive: https://discuss.ocaml.org/t/mirageos-3-6-0-released/4554/1

Martin Lucina announced

We are pleased to announce the release of MirageOS 3.6.0. This release updates MirageOS to support Solo5 0.6.0 and later.

New features:

  • Support for the Solo5 spt (sandboxed process tender) target via mirage configure -t spt. The spt target runs MirageOS unikernels in a minimal strict seccomp sandbox on Linux x86_64, aarch64 and ppc64le hosts.
  • Support for the Solo5 application manifest, enabling support for multiple network and block storage devices on the hvt, spt and muen targets. The genode and virtio targets are still limited to using a single network or block storage device.
  • Several notable security enhancements to Solo5 targets, such as enabling stack smashing protection throughout the toolchain by default and improved page protections on some targets. For details, please refer to the Solo5 0.6.0 release notes.

Additional user-visible changes:

  • Solo5 0.6.0 has removed the compile-time specialization of the solo5-hvt tender. As a result, a solo5-hvt binary is no longer built at mirage build time. Use the solo5-hvt binary installed in your $PATH by OPAM to run the unikernel.
  • mirage build now produces silent ocamlbuild output by default. To get the old behaviour, run with --verbose or set the log level to info or debug.
  • New functions Mirage_key.is_solo5 and Mirage_key.is_xen, analogous to Mirage_key.is_unix.

Thanks to @hannes for help with the release engineering for MirageOS 3.6.0.

Is it possible to use Machine Learning and Deep Learning frameworks through OCaml?

Archive: https://discuss.ocaml.org/t/is-it-possible-to-use-machine-learning-and-deep-learning-frameworks-through-ocaml/4570/1

Brando90 asked

I was wondering if this was possible at all?

The reason I am asking is because there has been some attempts at doing this but from Python to OCaml like languages. Outlined here: https://coq.discourse.group/t/machine-learning-and-hammers-for-coq/303

Anton Kochkov replied

Yes it is totally possible, see these resources:

If you are interested in improving the OCaml capabilites in this area, I think joining Owl development is the way to go, you can see their repositories here: https://github.com/owlbarn/

They have some ideas on possible improvements of the library at Proposed Projects page.

Yaron Minsky added

There's also a couple of followup posts to that first one:

Category theory for Programmers book - OCaml flavor

Archive: https://discuss.ocaml.org/t/category-theory-for-programmers-book-ocaml-flavor/3905/3

Arul announced

Hello, I've been working on translating this book in OCaml for few months now. @mseri has been kind enough to review all of my OCaml snippets and provide feedback. As we approach the final stages of this book(I'm currently translating snippets in Chapter21) and the book shows some advanced code, we were wondering if it'd be better to get more eyes on the OCaml snippets. Would anyone else be interested in reviewing the OCaml snippets of this book, atleast from Chapter 20 and out?

If so, you could join the conversation here - https://github.com/ArulselvanMadhavan/ocaml-ctfp/pull/22 and I will add you as reviewer to all future chapter releases.

Finally, Thanks @XVilka for posting about the book on here, before I even knew that it existed, and getting more traction for the book.

Ocaml-lxc (binding to Linux Containers) - progress report, looking for feedback and contributors

Archive: https://discuss.ocaml.org/t/ocaml-lxc-binding-to-linux-containers-progress-report-looking-for-feedback-and-contributors/4581/1

Darren announced

I'm writing to share the progress on ocaml-lxc, check if anyone's interested, and also looking for feedback or potential contributions

Description

ocaml-lxc is an OCaml binding to Linux Containers C API

The high level exposed design aims to largely match the one of go-lxc, but with adjustments to make it more ergonomic and closer to idiomatic OCaml

Progress

  • Low level API
    • Low level internal API (lxc_c.ml, lxc_c.mli) which matches closely with C API has been completed, and offers (almost) complete coverage of the C API
  • High level API
    • Core parts of the high level exposed API (`lxc.ml`, `lxc.mli`) have been completed, you can see here for feature set comparison to go-lxc
  • Documentation
    • You can see here for the documentation of the high level API. I have not actually written the documention yet, so this is only useful for examining the library structure atm.

Architecture

This section is more useful if you're planning to contribute. Feel free to skip.

  • Code generation
    • Cinaps is used to generate glue code for both C and OCaml side to access lxc_container C struct function pointer fields. See code_gen/gen.cinaps for all the core code generation code.
  • Stubs generation
    • Stubs generation via Ctypes is used to offer high confidence that things are done correctly at compile time. See code_gen/ffi_bindings.ml, code_gen/ffi_types.ml, code_gen/types.ml, and code_gen/stubs_gen.ml.
  • C glue code
    • Additional glue code is added to handle things like conditional compilation based on LXC version, working around anonymous struct (not supported by Ctypes), etc. See code_gen/lxc_glue.c and code_gen/lxc_glue.h.
  • Low level API
    • Low level API ties all the loose ends together, provides a fairly direct mapping to the C API, and is the main abstraction layer used by the higher level API. See src/lxc_c.ml and src/lxc_c.mli.
  • High level API
    • High level API introduces more abstraction, masking C objects, and has a more hierarchical structure compared to the flat structure used by lower level API. See src/lxc.ml and src/lxc.mli.

What I'm looking for

  • If you're interested in using the library, please feel free to provide feedback on the API design
    • e.g. what can be improved, what you don't like, what's missing
  • If you're interested in contributing, please feel free to reach out to me to coordinate etc. Following is the rough todo list I have atm
    • Add test code (copy go-lxc's test suite)
    • Add examples
    • API documentation
    • Document build flow architecture (specifically how dune fits into it maybe)
    • Document code architecture

TL;DR

A lot of the core bits of ocaml-lxc are done and took way too much time, looking for people to help out with the remaining really tedious yet crucial parts. And get sanity checks from people who may become users of ocaml-lxc.

Links

This is just a aggregated list of the links above

ocaml-lxc repo
https://github.com/darrenldl/ocaml-lxc
go-lxc repo
https://github.com/lxc/go-lxc
Comparison to go-lxc
https://github.com/darrenldl/ocaml-lxc/blob/master/doc/GO_LXC_COMPARISON.md
API Documentation
https://darrenldl.github.io/ocaml-lxc/

Ocaml-protoc-plugin 2.0.0

Archive: https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-2-0-0/4582/1

Anders Fugmann announced

It is my pleasure to announce release of 2.0.0 of ocaml-protoc-plugin.

Highlights for this release

  • Moved to a new name: The main module have been renamed to Ocaml_protoc_plugin (from Protobuf), to avoid conflicts with projects still using ocaml-protoc
  • Messages with only one field are not wrapped in a record by default. This can be controlled by the option singleton_record.
  • Oneof structures with only one field are not wrapped in a Polymorphic variant (controlled by option singleton_record)
  • Added googles well known types

The release is available through opam: opam install ocaml-protoc-plugin.2.0.0, or from github

Full changelog

  • Add examples
  • (*) Oneofs with only one element should not be a variant type
  • Add test when including proto files which defines the same package
  • Add google well know types (library ocaml-protoc-plugin.google_types).
  • (*) Move module to ocaml-protoc-plugin
  • Optimize deserialization of large nested structures
  • Provide pretty_printers aka deriving_show for Result.error and Field.t
  • Fix stack overflow when deserializing big nested structures
  • (*) Add option to not wrap single field type in records
  • Refactor type emitter to closely follow spec (refactor)

(*) indicates breaking change

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