[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

Alan Schmitt
2020-10-20T08:15:58Z

[-- Attachment #1: Type: text/plain, Size: 22169 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of October 13 to 20,
2020.

Table of Contents
─────────────────

Dialo is hiring frontend and backend OCaml developers (Remote)
Progress 0.1.0
Brr 0.0.1, a toolkit for programming browsers
New release of Conduit
Easy cross compilation using esy
OCaml User Survey 2020
Old CWN

Dialo is hiring frontend and backend OCaml developers (Remote)
══════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/dialo-is-hiring-frontend-and-backend-ocaml-developers-remote/6604/1>

Wojtek Czekalski announced
──────────────────────────

[Dialo] is an early stage company with an experienced founding
team. Assembling a team that consists of the best and brightest is our
top priority. In the immediate term we are building a visual
programming language for conversational AI. Our long term vision is
that personalized contact we are enabling will cause deeper
relationships between users and businesses and turn all interactions
into a unified long term customer journey.

The work is quite demanding when it comes to both ideation and
implementation. We are aiming to provide a room for growth both
technically and/or as a leader. For current open source maintainers we
are willing to sponsor your work on OSS for 20% of time.

We use OCaml for frontend and backend (along with Python for machine
learning, natural language processing). We are hiring people for
different positions. Both people with extensive experience and
newcomers are encouraged to apply. We try to find the sharpest people
rather than checking boxes with particular skills.

The official job posting:
<https://dialo.recruitee.com/o/software-developer-ocamlreason> We are
also hiring for two other (related) positions:
• <https://dialo.recruitee.com/o/software-developer-frontend>
• <https://dialo.recruitee.com/o/software-developer-backend>

[Dialo] <https://dialo.ai>

Progress 0.1.0
══════════════

Archive: <https://discuss.ocaml.org/t/ann-progress-0-1-0/6607/1>

Craig Ferguson announced
────────────────────────

I'm pleased to announce the first release of [`Progress'], now
available on Opam.

<https://raw.githubusercontent.com/CraigFe/progress/main/.meta/example.svg>

`Progress' is a small library for quickly defining and using progress
bars in OCaml programs. It aims to provide the following:

• support for rendering multiple progress bars simultaneously;
• responds dynamically to changes in terminal size;
• allows user-defined progress bar layouts.

[`Progress'] <https://github.com/CraigFe/progress/>

Defining your own progress bars
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

The example animation above uses a pre-provided progress bar layout
that should meet many needs ([`Progress_unix.counter']), but it's
fairly easy to re-define it ourselves using the low-level
[`Progress.Segment'] API:

┌────
│ let counter filename =
│ let proportion i = Int64.to_float i /. 1_000_000. in
│ let open Progress in
│ Segment.(
│ list
│ [
│ const filename;
│ Units.bytes of_pp;
│ Progress_unix.stopwatch ();
│ bar ~mode:`ASCII proportion;
│ using proportion (Units.percentage of_pp);
│ ]
│ |> box_winsize ~fallback:80 (* Dynamically scale to window size *)
│ |> periodic 100 (* Re-render once every 100 updates *)
│ |> accumulator Int64.add 0L (* Accumulate progress updates *))
│ |> make ~init:0L
└────

The `Segment' combinators are similar to those of general-purpose
pretty-printing libraries (e.g. [`pp'] and [`fmt']), but are equipped
with extra logic for "stateful" segments and segments that can have
dynamic width. Together, these make for a convenient way to express
common patterns when pretty-printing progress bars. For instance, the
stateful segment `periodic' seen above can be used to ensure that very
frequent updates from a hot-loop do not result in too much time spent
re-rendering the output.

The library is not yet feature-complete, but should still be
reasonably useful :slightly_smiling_face: Happy hacking!

[`Progress_unix.counter']
<https://craigfe.github.io/progress/progress/Progress_unix/index.html#val-counter>

[`Progress.Segment']
<https://craigfe.github.io/progress/progress/Progress/Segment/index.html>

[`pp'] <https://github.com/ocaml-dune/pp>

[`fmt'] <https://erratique.ch/software/fmt>

Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/1>

Daniel Bünzli announced
───────────────────────

I'd like to announce the first release of Brr.

The TL; DR is:
If you are looking for a productive way to program
browsers with js_of_ocaml but without ppx and ghost OCaml
objects, give Brr a try.

The details:

Brr is a toolkit for programming browsers in OCaml with
the [`js_of_ocaml'] compiler. It provides:
• Interfaces to a [selection] of browser APIs.
• Note based reactive support (optional and experimental).
• An [OCaml console] developer tool for live interaction
with programs running in web pages.
• A JavaScript FFI for idiomatic OCaml programming.

Brr is distributed under the ISC license. It depends on
[Note] and on the `js_of_ocaml' compiler and runtime – but
not on its libraries or syntax extension.

• Homepage: <https://erratique.ch/software/brr>
• API Docs & manuals: <https://erratique.ch/software/brr/doc/> or
`odig doc brr'
• Install: `opam install brr'

Brr is essentially what I need to be productive for browser
programming with js_of_ocaml: an obvious FFI with JavaScript objects
as abstract data types without OCaml object phantom types and binding
documentation precisely linking into MDN.

The OCaml console is the hack on the cake. In the past I often found
it frustrating to have OCaml programs running in my webpages and be
greeted with a JavaScript prompt in the browser dev tools. Quite a
bit of polishing could be done on that though. Some of which should
likely directly be done upstream in the toplevel machinery
(e.g. identifier completion, a better toploop API and support for easy
pretty printer installation). It would also be nice if we could cut
down on `js_of_ocaml''s toplevel compilation times ;–)

Parts of Brr have been seriously dogfooded in the past but that new
incarnation is largely untested for now and certain APIs might need
adjustements. Early adopters should study actual binding coverage,
expect glitches and little breakages in the future.

The Note reactive functionality was also seriously used in the past
but Note itself needs a new design round and I don't have the
ressources to do it right now, expect breakage, don't pay too much
attention to it for now.

My thanks to the `js_of_ocaml' developers for the nice ocaml to
javascript compiler and a special shootout to Hugo Heuzard for not
getting mad at me when pinging him directly for questions.

Happy browser compatibility bug hunting,

[`js_of_ocaml'] <https://ocsigen.org/js_of_ocaml>

[selection]
<https://erratique.ch/software/brr/doc/index.html#supported_apis>

[OCaml console]
<https://erratique.ch/software/brr/doc/ocaml_console.html>

[Note] <https://erratique.ch/software/note>

gasche asked
────────────

It's not really released, but I'm curious about [Note] now: this is a
new FRP library from you, the author of [React] (the FRP library for
OCaml, not the Javascript framework of the same name).

Would you say a few words on why you went for a different library? My
guess would be that React depends on runtime mechanisms (weak
pointers) that are not well-supported in Javascript-lang; but even if
the guess is right, I'm not sure what would be the impact on the API
or properties of the library.

[Note] <https://erratique.ch/software/note>

[React] <https://erratique.ch/software/react>

Daniel Bünzli replied
─────────────────────

Would you say a few words on why you went for a different
library?

`Note' is the result from seeing people (and myself) struggling to use
~React~/FRP "correctly" over the years.

Some of this, I largely attribute to ergonomic problems with the
API. It's my hope for `Note' to address most of these points (one
thing that still needs to be done is replace fix points by a simple
lazy infinitesimal delay combinator).

I don't think I could have made all these changes in `React' itself so
I found it better to start a new library. Also I lost the trademark on
the name :–)

`Note' also tries to provide a much simpler implementation. `React''s
implementation was based on the [FrTime Phd thesis]. It's quite subtle
and involved and, as you suggested, uses weak pointer. `Note' tries to
avoid them since those are not available in the browser (but you have
things like [MutationObservers] which I use as gc in Brr's Note-based
[reactive dom support]).

However not using weak pointers has a semantic uncleanness cost whose
impact I'm unsure yet – without discipline from the programmer it may
lead to subtle and hard to track bugs when the reactive graph changes
dynamically, which I'm a bit wary of.

When my brain dumped `Note' I wrote a few more technical points in the
readme you can read them [here].

[FrTime Phd thesis] <http://cs.brown.edu/people/ghcooper/thesis.pdf>

[MutationObservers]
<https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver>

[reactive dom support]
<https://erratique.ch/software/brr/doc/Brr_note/Elr/index.html>

[here] <https://github.com/dbuenzli/note#history>

New release of Conduit
══════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-conduit/6611/1>

Calascibetta Romain announced
─────────────────────────────

*Conduit 3.0.0*

Hello everyone,

We're glad to announce the new release of [`conduit'], a framework
that allows to _abstract_ over transfer protocols. One of its main
advantages is allowing the implemententation of _free-dependencies_
protocols.

[`conduit'] <https://github.com/mirage/ocaml-conduit>

Introduction
╌╌╌╌╌╌╌╌╌╌╌╌

There are several ways to abstract over an implementation in
OCaml. However, those solutions are often lost deep in the stack of
protocols and allowing the user to choose the implementations of the
sub-procotols implies growing complexity as we move up through the
stack. (For example, allowing to abstract over the implementation of
the TLS protocol from the implementation of the HTTP protocol)

One of those solutions, the _functors_, can rapidly become a hellish
nightmare for the end-user. This is especially true in the case of
MirageOS, which literally wants to abstract over everything!

This is why Conduit was implemented: it aims to provide to the user a
cleaner abstraction mechanism which would allow the protocol
developers to get rid of most of the responsibilities concerning the
choice of sub-protocols (Like which TLS implementation use between
OpenSSL or our great [ocaml-tls] library), while giving the end-users
an easy way to compose the protocols of their choice and inject them
in the stack via conduit.

[ocaml-tls] <https://github.com/mirleft/ocaml-tls>

Usage of Conduit
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Such a framework allows us to separate the logic of a protocol from
underlying implementation needed to communicate with a peer. The
distribution of Conduit comes with [a simple tutorial] which explains
step by step how to implement a _ping-pong_ client & server and, most
importantly, how to upgrade them with TLS.

With Conduit, we ensure the compatibility with MirageOS (and specially
[mirage-tcpip]) while being useful for others. Of course, Conduit is
not mandatory to ensure this compatibility, but it helps us for
_higher_ libraries such as [ocaml-git]/[Irmin] or [Cohttp].

[a simple tutorial]
<https://mirage.github.io/ocaml-conduit/conduit/howto.html>

[mirage-tcpip] <https://github.com/mirage/mirage-tcpip>

[ocaml-git] <https://github.com/mirage/ocaml-git>

[Irmin] <https://github.com/mirage/irmin>

[Cohttp] <https://github.com/mirage/ocaml-cohttp>

Specific improvements
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Abstract and destruct it!

The most requested feature on the new version of Conduit is the
ability to _destruct_ the [Conduit.flow][conduit-flow]. The ability to
abstract the protocol comes with the _abstract_ type
`Conduit.flow'. The new version permits to _destruct_ it to a
well-known value (such as an UNIX socket):

┌────
│ let handler flow = match flow with
│ | Conduit_lwt.TCP.T (Value file_descr) ->
│ let peer = Lwt_unix.getpeername file_descr in
│ ...
│ | flow -> ... (* other kind of protocol *)
│
│ let run =
│ Cohttp_lwt_unix.serve ~handler
│ { sockaddr= Unix.inet_addr_loopback }
└────

◊ The dispatch of the protocol

The second most interesting feature of Conduit is the full control
over the dispatch between protocols by the end-user. From a concrete
information such as an `Uri.t', the end-user is able to describe how
Conduit should choose the protocol (and with which value it should try
to initiate the connection):

┌────
│ let my_tls_config = Tls.Config.client ...
│
│ let connect uri =
│ let edn = Conduit.Endpoint.of_string
│ (Uri.host_with_default ~default:"localhost" uri) in
│ let resolvers = match Uri.scheme uri with
│ | Some "https" ->
│ let port = Option.value ~default:443 (Uri.port uri) in
│ Conduit_lwt.add
│ Conduit_lwt_tls.TCP.protocol
│ (Conduit_lwt_tls.TCP.resolve ~port ~config:my_tls_config)
│ Conduit.empty
│ | Some "http" | None ->
│ let port = Option.value ~default:80 (Uri.port uri) in
│ Conduit_lwt.add
│ Conduit_lwt.TCP.protocol
│ (Conduit_lwt.TCP.resolve ~port)
│ Conduit.empty in
│ Conduit_lwt.resolve ~resolvers edn >>= fun flow ->
│ ...
└────

◊ An explicit way to launch a server

Conduit comes with a new API for the server-side, where everything
becomes explicit: no dispatch, no hidden choice. It proposes now a
simple function to start the usual server loop:

┌────
│ let run handler =
│ Conduit_lwt.serve ~handler
│ Conduit_lwt.TCP.service
│ { Conduit_lwt.TCP.sockaddr= Unix.(ADDR_INET (inet_addr_loopback, 8080)
│ ; capacity= 40 }
└────

Reverse-dependencies
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Conduit is used by many libraries (~150 packages) and we spend 2
months to track this breaking-change. Currently, it's mostly about
[Cohttp] and [Irmin] and both have a PR according the new version of
Conduit. These packages will be released as soon as we can with the
new version of Conduit.

[Cohttp] <https://github.com/mirage/ocaml-cohttp>

[Irmin] <https://github.com/mirage/irmin>

Conclusion
╌╌╌╌╌╌╌╌╌╌

Conduit is a piece required by many libraries but nobody really uses
it. This new version wants to replace and redefine more concretely
what Conduit is. The update is [huge] for us but small for people
where we tried to keep the same global idea of the abstraction.

I would like to thank many people (MirageOS core team, Cohttp peoples,
some not so famous guys of the Reason/OCaml eco-system) who followed
us on this deep development (and tried and iterated on our
version). It does not change too much our world, but it paves the way
for a better MirageOS/OCaml eco-system.

As a french guy, I just would like to say: Conduit est mort, Vive
Conduit!

[huge] <https://github.com/mirage/ocaml-conduit/pull/311>

Easy cross compilation using esy
════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-easy-cross-compilation-using-esy/6612/1>

EduardoRFS announced
────────────────────

I've been working on this for a couple of months now, and now it is
ready for an initial announcement of my tools to cross compiling OCaml
and ReasonML Native.

<https://github.com/EduardoRFS/reason-mobile>

What it can do
╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Out of box it can cross compile most dune and topkg, packages
available on opam for a couple of platforms, there is also patches for
popular packages.

You can also compile opam packages by making an wrapper, like

<https://github.com/mirage/mirage-crypto/pull/84/files>

Limitations
╌╌╌╌╌╌╌╌╌╌╌

Your package should build with OCaml 4.10, and all the packages that
are built for the `host' will also be build for the `target', so
sometimes you need to fix a package that you will not use directly.

Some packages you will need to pin to a `dune-universe' fork version

How to use it
╌╌╌╌╌╌╌╌╌╌╌╌╌

┌────
│ ## compile your project
│ esy
│
│ ## generate the wrapper
│ esy add -D generate@EduardoRFS/reason-mobile:generate.json
│ esy generate android.arm64
│
│ ## build for android.arm64
│ esy @android.arm64
└────

Platforms
╌╌╌╌╌╌╌╌╌

All of the following are tested from Linux and macOS, but I would
suppose that FreeBSD should be also working as a build system.

━━━━━━━━━━━━━━━━━━━━━━
Targets
──────────────────────
android.arm64
android.x86_64
ios.arm64
ios.simulator.x86_64
linux.musl.arm64
linux.musl.x86_64
━━━━━━━━━━━━━━━━━━━━━━

What I tested
╌╌╌╌╌╌╌╌╌╌╌╌╌

In the past I was able to build `Revery' the UI framework for
`Android' and `iOS'

But recently I did compile `esy' the package manager itself for all of
the following platforms above from an `Arch Linux x86_64' and `macOS
Catalina x86_64'. Including `iOS', with the right version of OCaml it
will run inside of the new `macOS ARM64' and inside of a jailbroken
iPhone.

OCaml User Survey 2020
══════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624/1>

gasche announced
────────────────

We are happy to announce the [OCaml User Survey 2020]. We are trying
to get a better picture of the OCaml community and its needs. It would
be very useful if you could fill the survey (10-15 minutes), and share
it widely with other OCaml programmers!

The survey is run by the [OCaml Software Foundation]. Thanks in
particular to our sponsors OCamlPro (@MuSSF) for preparing many of the
questions, Jane Street (@Yaron_Minsky) for excellent feedback, and to
Kim @K_N Nguyễn for his technical help.

This is our first year running the survey, we hope to continue in
following years. There are many things to improve; please feel free to
give us feedback! (There is a feedback question at the end of the
survey, or you can post here, or send me a message/email.)

The survey was inspired by programming-language surveys ran by other
communities. See for example past survey results for [Go], [Haskell],
[Rust], and [Scala].

[OCaml User Survey 2020] <https://forms.gle/MAT7ZE7RtxTWuNgK7>

[OCaml Software Foundation] <https://ocaml-sf.org/>

[Go] <https://blog.golang.org/survey2019-results>

[Haskell] <https://taylor.fausak.me/2019/11/16/haskell-survey-results/>

[Rust] <https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html>

[Scala] <https://scalacenter.github.io/scala-developer-survey-2019/>

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]

[send me a message] <mailto:alan.schmitt@polytechnique.org>

[the archive] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>

[-- Attachment #2: Type: text/html, Size: 41767 bytes --]