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

[Alan Schmitt <alan.schmitt@polytechnique.org>]

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

Hello

Here is the latest OCaml Weekly News, for the week of June 07 to 14,
2022.

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

Lwt informal user survey
Tutorial: Full-Stack Web Dev in OCaml w/ Dream, Bonsai, and GraphQL
dkml-c-probe: Cross-compiler friendly definitions for C compiling
Htmx/hc web development approach
Engineer and postdoc positions in France (various labs) to work on a proof assistant for crypto protocols
Yojson 2.0.0
opentelemetry 0.2
omake-0.10.5
findlib-1.9.5
Old CWN


Lwt informal user survey
════════════════════════

  Archive: <https://discuss.ocaml.org/t/lwt-informal-user-survey/9666/3>


Continuing this thread, Raphaël Proust said
───────────────────────────────────────────

  Thanks to everyone who took the time to answer the polls above. I've
  now closed them.

  The first pull-request to come out of this poll is
  [<https://github.com/ocsigen/lwt/pull/947>](removing support for
  OCaml<=4.07). This was the cutoff in the poll. It removes a lot of
  `#if' preprocessing statements and a few workarounds to stay
  compatible with old Stdlib interfaces. Thanks to @hannes for
  contributing most of the commits on this pull-request.  If support for
  OCaml<=4.07 is important to you, please participate in the
  pull-request's discussion or on this thread.

  Stay tuned for more. (But also be patient.)


Tutorial: Full-Stack Web Dev in OCaml w/ Dream, Bonsai, and GraphQL
═══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/tutorial-full-stack-web-dev-in-ocaml-w-dream-bonsai-and-graphql/9963/20>


Continuing this thread, jerben asked and Daniel Bünzli replied
──────────────────────────────────────────────────────────────

        Very interesting, did you write somewhere about how it
        compares to htmx?

  Not really.

  As far as I can remember I liked the ideas but found their execution
  to be a bit lacking, sometimes ad-hoc in their attribute DSL, focusing
  more on the show off to convince single page application proponents of
  the approach than on a clear conceptual model (which `hc' tries to
  detail in the manual [here]).

  Two other things that come to mind are:

  1. AFAIR their examples relied a lot on unique `id' attributes for
     targeting request results. Unless you find a principled and
     automated way to generate these that's not compositional and
     brittle. In `hc' I [extended the CSS selector syntax] to allow to
     address your ancestors (peace be upon them). That's more
     compositional but now you become sensitive to structural changes in
     your markup – pick your poison[^1].
  2. I'm no longer sure about that, i.e. don't take my word for it, but
     I think their DSL allowed to spread the definition of an
     interaction among many elements which made it more difficult to
     understand what is happening. In `hc' all attributes defining the
     effects of an interaction are always located on a single element,
     the element that performs the request.

  Finally when things go wrong I prefer to have to understand [700 lines
  of ml] rather than [2800 lines of JavaScript] (note that they likely
  have better legacy browser support and more functionality).

  In any case there's a long list of todos in `hc' and it likely needs
  one or two more design rounds before getting to something decent – if
  that's even remotely possible on the web.

        Dang it @dbuenzli one day you’ll run out of letters and
        need to come up with an actual name for your libraries.

  Mind you I tried to use three letters once, but the whole experience
  turned out to be [extremely unpleasant] :–)

  [^1]: Using unique ids reifed in an OCaml EDSL could be a better idea.


[here] <https://erratique.ch/software/hc/doc/manual.html#request>

[extended the CSS selector syntax]
<https://erratique.ch/software/hc/doc/manual.html#selector>

[700 lines of ml]
<https://github.com/dbuenzli/hc/blob/master/src/hc_page.ml>

[2800 lines of JavaScript]
<https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js>

[extremely unpleasant]
<https://github.com/dbuenzli/rel/commit/f95b6bad02a8080eb64f8d0123cd63d40b528e33>


dkml-c-probe: Cross-compiler friendly definitions for C compiling
═════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-dkml-c-probe-cross-compiler-friendly-definitions-for-c-compiling/9950/8>


jbeckford announced
───────────────────

  V3 is available. Its `C_abi' module has some big enhancements:
  • cleaner API (thanks @mseri!)
  • recognizes the BSD family: OpenBSD, FreeBSD, NetBSD and DragonFly on
    x86_64 hardware
  • integration testing now includes OpenBSD, FreeBSD and one
    cross-compiling toolchain (macOS x86_64 host that targets arm64)

  V3 also has a new module `C_conf' which occupies the same problem
  space as `findlib / ocamlfind' and `pkg-config':
  • Unlike `findlib' which is a specification+tool for 3rd party OCaml
    libraries, `C_conf' is a specification+tool for foreign C libraries
  • Unlike `pkg-config' which is a specification+tool for system (host
    ABI) C libraries, `C_conf' is a specification+tool for the multiple
    ABIs that are present when you cross-compile OCaml or C code
  • Unlike `pkg-config' which is designed for Unix, `C_conf' is designed
    for Windows and Unix where paths may have spaces, backslashes and
    colons
  • For now the specification is based on environment variables. If it
    proves useful the specification can be extended.

  Examples and doc links for V3 are available at
  [https://github.com/diskuv/dkml-c-probe#dkml-c-probe]


[https://github.com/diskuv/dkml-c-probe#dkml-c-probe]
<https://github.com/diskuv/dkml-c-probe#dkml-c-probe>


Marcello Seri asked and jbeckford replied
─────────────────────────────────────────

        Thanks a lot for the update! Can you say a bit more about
        how `C_conf' works?

  C_conf has a detailed problem statement and spec at
  <https://diskuv.github.io/dkml-c-probe/dkml-c-probe/Dkml_c_probe/C_conf/index.html>
  (which is linked to on the dkml-c-probe README).

  I probably shouldn't regurgitate the doc here, so I'll take a few key
  pieces from the doc and then post some things here that I didn't put
  on that doc page …

  1. Here is my configuration for locating the "gmp" library on my Apple
     Silicon host machine that cross-compiles to x86_64:

     ┌────
     │ CP_GMP_CC_DEFAULT                 = -IZ:/build/darwin_arm64/vcpkg_installed/arm64-osx/include
     │ CP_GMP_CC_DEFAULT_DARWIN_X86_64   = -IZ:/build/darwin_x86_64/vcpkg_installed/x64-osx/include
     │ CP_GMP_LINK_DEFAULT               = -LZ:/build/darwin_arm64/vcpkg_installed/arm64-osx/lib;-lgmp
     │ CP_GMP_LINK_DEFAULT_DARWIN_X86_64 = -LZ:/build/darwin_x86_64/vcpkg_installed/x64-osx/lib;-lgmp
     └────

     • The other direction may be more interesting, since the free
       GitHub Actions only supports x86_64. The scenario of taking a
       macOS x86_64 GitHub host and cross-compiling to Apple Silicon is
       [implemented and partially tested].
  2. I am using a C package manager (vcpkg) to give me cross-compiled
     libraries and the flags for the target ABI (in this case
     darwin_x86_64 is the target ABI). In general it doesn't matter
     where you get your target ABI compatible libraries from. Example:
     When I'm cross-compiling to Android on a Windows x86_64 host, the
     Android Studio environment gives me some libraries for an Android
     Emulator (host ABI) and also prebuilt libraries for 4 Android
     device ABIs:

     ┌────
     │ Directory: C:\Users\xxx\AppData\Local\Android\Sdk\ndk\23.1.7779620\prebuilt
     │ 
     │ Mode                 LastWriteTime         Length Name
     │ ----                 -------------         ------ ----
     │ d-----        10/20/2021   8:27 PM                android-arm
     │ d-----        10/20/2021   8:27 PM                android-arm64
     │ d-----        10/20/2021   8:27 PM                android-x86
     │ d-----        10/20/2021   8:26 PM                android-x86_64
     │ d-----        10/20/2021   8:27 PM                windows-x86_64
     └────
  3. The `CP_clibrary_CC_DEFAULT_abi' configuration relies on `abi' (the
     ocamlfind toolchain name) being standardized. The `gmp' library,
     for example, is used by many OCaml packages; I wanted one
     configuration for `gmp', not one configuration for each `(gmp,
     OCaml package)' combination. In fact, getting a consistent `abi'
     naming was one of my motivations for releasing `dkml-c-probe'. I
     don't think the prior art got this right … the very stale
     [opam-cross-android] project uses [`abi = "android"'] which is
     insufficient to differentiate the 5+ sets of libraries available in
     Android Studio.
  4. The "gmp" (etc.) configuration is done once in a familiar syntax
     (`-L, -I, -l'). However the `C_conf' library will parse and print
     the configuration in the appropriate C compiler syntax. When the
     MSVC compiler is used you get MSVC style linking:
     ┌────
     │ [
     │   "-LIBPATH:Z:/build/darwin_x86_64/vcpkg_installed/x64-osx/lib";
     │   "gmp.lib"
     │ ]
     └────
     MSVC and GCC conventions are supported today in `C_conf'.
  5. A real example of using `C_conf' is in my customization of [zarith
     library]. It checks `C_conf' first to see whether the user has the
     host/target ABI configuration; if it doesn't it falls back to
     pkg-config.

  The trend of using `pkg-config' in OCaml packages makes both native
  Windows and cross-compilation difficult. At the moment *we
  unintentionally shoot ourselves in the foot* because [Dune
  documentation encourages `pkg-config'] for understandable reasons. I
  hope `dkml-c-probe' can break that trend.


[implemented and partially tested]
<https://github.com/diskuv/dkml-c-probe/blob/2c1e90b4eea119348d6dae37d64949041ef9eaeb/.github/workflows/test.yml#L299-L379>

[opam-cross-android] <https://github.com/ocaml-cross/opam-cross-android>

[`abi = "android"']
<https://github.com/ocaml-cross/opam-cross-android#porting-packages>

[zarith library]
<https://github.com/jonahbeckford/Zarith/blob/a1bf6d55cd3c4b91dee0afb2309ef11271e9729b/discover.ml>

[Dune documentation encourages `pkg-config']
<https://dune.readthedocs.io/en/stable/dune-libs.html#configurator-1>


Htmx/hc web development approach
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/htmx-hc-web-development-approach/9993/11>


Vladimir Keleshev announced asked
─────────────────────────────────

  @cemerick, @yawaramin, @dbuenzli, and others who've used htmx/hc with
  OCaml back-end: what is your experience with templating? It seems that
  htmx/hc puts high requirements on a flexible HTML templating/DSL. What
  did you choose and is it working out for you?


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

  I'm using OCaml and an absolutely [trivial HTML generation
  library]. If you want to see a real world example head to the
  `*_html.{ml,mli}' files in [this directory] (more on the structure
  found there [here])

  Works quite well for me but I'd say the problem is not really
  templating it's rather non-brittle URL management. For that I use
  [this module] which while I'm not entirely convinced by it yet, allows
  me to type them and avoid the stringly unchecked dependendencies so
  characteristic of the web development world.


[trivial HTML generation library]
<https://erratique.ch/software/webs/doc/Webs_html/index.html>

[this directory]
<https://github.com/dbuenzli/hyperbib/tree/master/src/service>

[here]
<https://github.com/dbuenzli/hyperbib/blob/master/DEVEL.md#cli-tool-and-backend>

[this module]
<https://erratique.ch/software/webs/doc/Webs_kit/Kurl/index.html>


Chas Emerick also replied
─────────────────────────

  Yeah, you're right on that point.

  I'm using tyxml for 99% of my HTML generation, specifically its jsx
  ppx. I am judicious about keeping the main logics of the project in
  OCaml proper; `.re' files exist exclusively to hold markup. The end
  result is a _very_ pleasant environment IMO. In the end, I dearly wish
  there was a way to get actual HTML syntax into `.ml' files (I am no
  fan of reason syntax outside of jsx, and I suspect the sorta-legacy
  jsx toolchain leftover from reasonml will end up being a tech risk
  over time), but as things stand, it's the best option I've found.


Yawar Amin also replied
───────────────────────

  I'm just using Dream's 'built-in' templating, 'Embedded ML (.eml)', it
  works reasonably well–each template or partial is just a function that
  you define to take some arguments and return some markup. It even
  auto-escapes to prevent injection attacks. E.g.,

  ┌────
  │ let card name =
  │   <div class="card"><%s name %></div>
  └────

  There are a couple of tricks to be aware of with the EML syntax but in
  general it works well.


Simon Cruanes also replied
──────────────────────────

  For the little webdev I do (internal tools mostly for myself), I've
  also been using server side html generation, with my own `wheels'
  tools and a bit of htmx.

  Here's an excerpt from a personal project, with my own httpd and html
  combinators; it adds a root to handle `/thy/<some string>':

  ┌────
  │ let h_thy (self:state) : unit =
  │   H.add_route_handler self.server
  │     H.Route.(exact "thy" @/ string_urlencoded @/ return) @@ fun thy_name req ->
  │   let@ () = top_wrap_ req in
  │   let thy = Idx.find_thy self.st.idx thy_name in
  │   let res =
  │     let open Html in
  │     [
  │       div[cls "container"][
  │ 	h3[][txtf "Theory %s" thy_name];
  │ 	Thy_file.to_html thy;
  │ 	div [
  │ 	  "hx-trigger", "load";
  │ 	  "hx-get", (spf "/eval/%s" @@ H.Util.percent_encode thy_name);
  │ 	  "hx-swap", "innerHtml"] [
  │ 	  span[cls "htmx-indicator"; A.id "ind"][
  │ 	    txt "[evaluating…]";
  │ 	  ]
  │ 	];
  │       ]
  │     ]
  │   in
  │   reply_page ~title:(spf "theory %s" thy_name) req res
  └────


Engineer and postdoc positions in France (various labs) to work on a proof assistant for crypto protocols
═════════════════════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/engineer-and-postdoc-positions-in-france-various-labs-to-work-on-a-proof-assistant-for-crypto-protocols/9999/1>


David Baelde announced
──────────────────────

  We are looking for engineers and postdocs to work on Squirrel, a proof
  assistant dedicated to proving cryptographic protocols. We have a
  broad range of projects in mind, ranging from pure OCaml development
  to involved protocol formalizations, with several theoretical
  questions in between. If you'd like to work on some of these aspects
  for one or more years, please get in touch with us!

  More details can be found here:

  <https://squirrel-prover.github.io/positions.pdf>


Yojson 2.0.0
════════════

  Archive: <https://discuss.ocaml.org/t/ann-yojson-2-0-0/10003/1>


Marek Kubica announced
──────────────────────

  This Friday, it is my pleasure to announce the release of Yojson
  2.0.0. You can get it [in your local OPAM repository].

  Key highlights include:

  • Fewer dependencies: Given Yojson is a common dependency we cut down
    on its dependencies so you have to install less and have less
    transitive dependencies
  • `Seq' interface: Since OCaml 4.14 deprecates `Stream' and 5.0
    removes it, this was a good time to change to this interface
  • `Buffer' interface: coming along with #1, we changed Yojson to use
    `Buffer' wherever it was using `Biniou' types before

  Thanks to everybody involved in this release!

  If Yojson sounds like an interesting project for you to contribute,
  [join us].

  Full changelog follows:


[in your local OPAM repository]
<https://opam.ocaml.org/packages/yojson/>

[join us] <https://github.com/ocaml-community/yojson>

2.0.0
╌╌╌╌╌

  *2022-06-02*


Removed
┄┄┄┄┄┄┄

  • Removed dependency on easy-format and removed `pretty_format' from
    `Yojson', `Yojson.Basic', `Yojson.Safe' and `Yojson.Raw'. (@c-cube,
    #90)
  • Removed dependency on `biniou', simplifying the chain of
    dependencies. This changes some APIs:
    ‣ `Bi_outbuf.t' in signatures is replaced with `Buffer.t'
    ‣ `to_outbuf' becomes `to_buffer' and `stream_to_outbuf' becomes
      `stream_to_buffer'
    (@Leonidas, #74, and @gasche, #132)
  • Removed `yojson-biniou' library
  • Removed deprecated `json' type aliasing type `t' which has been
    available since 1.6.0 (@Leonidas, #100).
  • Removed `json_max' type (@Leonidas, #103)
  • Removed constraint that the "root" value being rendered (via either
    `pretty_print' or `to_string') must be an object or
    array. (@cemerick, #121)
  • Removed `validate_json' as it only made sense if the type was called
    `json'.  (@Leonidas, #137)


Add
┄┄┄

  • Add an opam package `yojson-bench' to deal with benchmarks
    dependency (@tmcgilchrist, #117)
  • Add a benchmark to judge the respective performance of providing a
    buffer vs letting Yojson create an internal (#134, @Leonidas)
  • Add an optional `suf' keyword argument was added to functions that
    write serialized JSON, thus allowing NDJSON output. Most functions
    default to not adding any suffix except for `to_file' (#124,
    @panglesd) and functions writing sequences of values where the
    default is `\n' (#135, @Leonidas)


Change
┄┄┄┄┄┄

  • The `stream_from_*' and `stream_to_*' functions now use a `Seq.t'
    instead of a `Stream.t', and they are renamed into `seq_from_*' and
    `seq_to_*' (@gasche, #131).


Fix
┄┄┄

  • Avoid copying unnecessarily large amounts of strings when parsing
    (#85, #108, @Leonidas)
  • Fix `stream_to_file' (#133, @tcoopman and @gasche)


opentelemetry 0.2
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-opentelemetry-0-2/10005/1>


Simon Cruanes announced
───────────────────────

  It is my pleasure to announce the release of [ocaml-opentelemetry]
  0.2. This library provides a core instrumentation library, as well as
  exporters, for the [opentelemetry] standard for observability; it
  encompasses distributed tracing, metrics, and (more recently) log
  export. A lot of tools are compatible with opentelemetry these days,
  including Grafana, DataDog, jaeger, etc.

  This is still very early days for ocaml-opentelemetry, feedback and
  contributions are welcome.


[ocaml-opentelemetry]
<https://github.com/imandra-ai/ocaml-opentelemetry>

[opentelemetry] <https://opentelemetry.io/>


omake-0.10.5
════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2022-06/msg00012.html>


Gerd Stolpmann announced
────────────────────────

  I just released omake-0.10.5, the build utility, which fixes the
  broken installation of version 0.10.4 from last week.

  For docs and the download link see
  <http://projects.camlcity.org/projects/omake.html>. opam is underway.


findlib-1.9.5
═════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2022-06/msg00012.html>


Gerd Stolpmann announced
────────────────────────

  findlib-1.9.5 is out, fixing some scripting errors in the version
  1.9.4 from last week.

  For manual, download, manuals, etc. see here:

  <http://projects.camlcity.org/projects/findlib.html>

  An updated OPAM package will follow soon.


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] <https://alan.petitepomme.net/cwn/>

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

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

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


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