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

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

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

Hello

Here is the latest OCaml Weekly News, for the week of April 23 to 30,
2024.

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

OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
I roughly translated Real World OCaml's Async concurrency chapter to eio
Using Property-Based Testing to Test OCaml 5
OCaml Backtraces on Uncaught Exceptions, by OCamlPro
OCaml Users on Windows: Please share your insights on our user survey
Graphql_jsoo_client 0.1.0 - library for GraphQL clients using WebSockts
dream-html 3.0.0
DkCoder 0.2 - Scripting in OCaml
Ocaml-protoc-plugin 6.1.0
Other OCaml News
Old CWN


OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
═════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocannl-0-3-1-a-from-scratch-deep-learning-i-e-dense-tensor-optimization-framework/14492/8>


Lukasz Stafiniak announced
──────────────────────────

  Third time the charm. OCANNL 0.3.3 is out now. I might need to change
  the name of the project, because of the lint warnings: Possible name
  collision with packages 'OCADml', 'ocal', 'ocaml'?


I roughly translated Real World OCaml's Async concurrency chapter to eio
════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/i-roughly-translated-real-world-ocamls-async-concurrency-chapter-to-eio/14548/1>


Dennis Dang announced
─────────────────────

  Repo at
  <https://github.com/dangdennis/rwo-eio/blob/main/lib/rwo_eio.ml>

  I was inspired by Taride's [Make an Eio version of the Async examples
  in Real World OCaml] to translate the Async examples to eio to test
  out eio's concurrency story.  Warning, it's a rough translation. I
  hardly know OCaml and eio as well as I know my day-job languages
  :smile: .

  There are still a few examples I haven't figured out.
  1. I don't know how to implement [`copy_blocks']. In [this section],
     the example uses an intermediate buffer of some sorts to then copy
     from reader to writer. For now, I've left that intermediate buffer
     out.
  2. I can't find an `interrupt' option in `cohttp-eio' as well as
     `choice' and `choose'. The book explains that cohttp-async can
     cancel http requests via an `interrupt' ([see section]).
  3. For [`log_delays'], I have yet to solve how to await my own `every'
     ticker such that I can await its completion and then log the timer
     at the end.


[Make an Eio version of the Async examples in Real World OCaml]
<https://github.com/tarides/hackocaml/issues/9>

[`copy_blocks']
<https://github.com/dangdennis/rwo-eio/blob/a666d8aaaed0884218d706f94b6babeed85debea/lib/rwo_eio.ml#L88>

[this section]
<https://dev.realworldocaml.org/concurrent-programming.html>

[see section]
<https://dev.realworldocaml.org/concurrent-programming.html>

[`log_delays']
<https://github.com/dangdennis/rwo-eio/blob/a666d8aaaed0884218d706f94b6babeed85debea/lib/rwo_eio.ml#L348>


Using Property-Based Testing to Test OCaml 5
════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/blog-using-property-based-testing-to-test-ocaml-5/14550/1>


Jan Midtgaard announced
───────────────────────

  Here's a blog post about how we have been using property-based testing
  to test OCaml 5:
  <https://tarides.com/blog/2024-04-24-under-the-hood-developing-multicore-property-based-tests-for-ocaml-5/>


OCaml Backtraces on Uncaught Exceptions, by OCamlPro
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/blog-ocaml-backtraces-on-uncaught-exceptions-by-ocamlpro/14551/1>


OCamlPro announced
──────────────────

  Here's another one of our heads up about our latest blog release!

  Today's topic is about an unintentionally hidden feature of the OCaml
  dev environmment: [backtraces on uncaught exception]!

  We believe this will be old news to the veteran OCaml devs but could
  be of much use to the newer Cameleers out there!

  Hopefully, you will learn a thing or two from reading this short
  article, we welcome all feedback in this very thread, thank you for
  reading!


[backtraces on uncaught exception]
<https://ocamlpro.com/blog/2024_04_25_ocaml_backtraces_on_uncaught_exceptions/>


OCaml Users on Windows: Please share your insights on our user survey
═════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-users-on-windows-please-share-your-insights-on-our-user-survey/14554/1>


Sudha Parimala announced
────────────────────────

  Do you use OCaml on Windows? We want to hear from you! Participate in
  our user survey to share your experiences with the OCaml development
  environment on Windows. Your feedback is important in helping us
  understand the current pain points and identify areas for
  improvement. Whether you're a seasoned OCaml developer or just
  starting out, your input can make a significant difference.

  Please sign up here <https://forms.gle/SxRvNaEZXgedxrnR9>, and we'll
  reach out to you.


Graphql_jsoo_client 0.1.0 - library for GraphQL clients using WebSockts
═══════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/graphql-jsoo-client-0-1-0-library-for-graphql-clients-using-websockts/14557/1>


Hans Ole Rafaelsen announced
────────────────────────────

  I'm glad to announce the release of graphql_jsoo_client.

  This is the client side implementation of the [GraphQL over WebSocket
  Protocol]. It is mainly intended for use with Dream, which implements
  the server side. This library supports writing client code in Ocaml,
  that will run in the browser.

  It can be found [here].


[GraphQL over WebSocket Protocol]
<https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md>

[here] <https://github.com/hansole/graphql_jsoo_client>


dream-html 3.0.0
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-dream-html-3-0-0/14013/8>


Yawar Amin announced
────────────────────

  [ANN] dream-html 3.4.1

  Add 'livereload' support ie automatically reloading the page in the
  browser when the Dream server restarts. Useful to run with dune's
  watch mode for a fast dev cycle.

  This is adapted from Dream's own livereload middleware but with a
  slightly different approach. Full details in the module documentation:
  <https://yawaramin.github.io/dream-html/dream-html/Dream_html/Livereload/>

  Why reimplement this? It seems that Dream's built-in livereload needs
  to parse the HTML markup, find its `head' tag, and dynamically inject
  the reloader `script' inside. Since parsing HTML can be pretty tricky
  and potentially buggy, I decided to manually add the script in the
  `head' tag as a strong-typed dream-html `node':

  ┌────
  │ head [] [
  │   ...
  │   Livereload.script;
  │   ...
  │ ]
  └────


DkCoder 0.2 - Scripting in OCaml
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/dkcoder-0-2-scripting-in-ocaml/14560/1>


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

  I'm happy to announce the second release of DkCoder, an OCaml
  scripting tool.

  The first release was about /install ease/: a couple clicks and four
  (4) minutes later you and your Windows and macOS users can start
  scripting. All users, including glibc-based Linux desktop users, can
  also use their Unix shells or Windows PowerShell. OCaml does *not*
  need to be pre-installed. Just copy and paste two lines (you'll see
  some in this post) and your script is running and your project is
  editable with OCaml LSP.

  This second release is about /technical ease/. The three "big" ideas
  in this release are:

  • You don't write build files. If that sounds like `/bin/sh' that is
    intentional.
  • Almost every OCaml file is a script you can run. If that sounds like
    how Python scripts are almost indistinguishable from Python modules,
    that is intentional.
  • Almost every OCaml file can be referenced with a fully-qualified
    name. If that sounds like Java packages that is intentional.

  Here are some examples:

  1. (*one of my own scripts*) The incomplete but growing DkCoder
     documentation is written in a script:
     <https://diskuv.com/dksdk/coder/2024-intro-scripting/>. /The
     documentation is a side-effect of running tests./

     In a Unix shell or in PowerShell, the following will a) run tests
     using [tezt], b) collect outputs, c) generate HTML documentation,
     and then d) serve the doc page on a [tiny_httpd] webserver for a
     quick preview:

     ┌────
     │ git clone --branch V0_2 https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git
     │ 
     │ ./DkHelloScript/dk DkRun_V0_2.Run -- DkHelloScript_Std.Y33Article --serve
     └────

     The following will print mixed Markdown/HTML that I can render and
     publish with a static site generator to a website:

     ┌────
     │ ./DkHelloScript/dk DkRun_V0_2.Run -- DkHelloScript_Std.Y33Article --doc --doc-format markdown
     └────

  2. (*someone else's*) The Bogue demo game Snoke written by @sanette
     was "ported" to DkCoder. /The port did not change a single line of
     the original code/. I did re-arrange the directory structure
     (recall that there is a Java-like package mechanism underneath
     DkCoder) and I did add an extra `.ml' file. Run:

     ┌────
     │ git clone --branch V0_2 https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git
     │ 
     │ ./SanetteBogue/dk DkRun_V0_2.Run -- SanetteBogue_Snoke.Snoke
     └────

  The remaining items for DkCoder before a 1.x release: auto-downloading
  remote libraries (mostly done), meta/codegen tools (in progress),
  conditional compilation (in design), and a security policy (in
  design).

  But right now DkCoder is at a reasonable enough point that I can now
  recommend using it for your own scripts. With the usual caveats that
  this is a 0.x release.

  /I'd like some feedback, especially on pain points and missing
  must-have features./


[tezt] <https://v3.ocaml.org/p/tezt/latest>

[tiny_httpd] <https://v3.ocaml.org/p/tiny_httpd/latest>

Tech Details (if interested)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Very simplistically, DkCoder is a high-level build system that
  transparently manages lower-level build systems (today that is Dune).
  I think (?) DkCoder is the first build system to use [the `codept'
  OCaml dependency analyzer]. Huge huge thanks to @octachron for that
  tool.

  The rather boring driver pipeline is:

  1. Seed a "universe" of modules with the single `.ml' file the user
     wants to run from the `./dk' CLI, or seed with all the `.ml' files
     if run through OCaml LSP.
  2. Let `codept' analyse any module references inside the current
     universe. Any *missing modules* are located and added to the
     universe. Rinse and repeat until there is a closed universe with no
     more missing module references.
  3. Generate and/or incrementally update the build files. Each `.ml'
     file is mapped to a single OCaml `.cma' library.
  4. Run the chosen build tool (ie. Dune) and execute the code.

  What does that pipeline give us? Even in this early 0.2 release you
  get some unusual benefits:

  • Step 2: The *missing modules* can be created implicitly. The Snoke
    game has font, image and sound assets. By using `Tr1Assets.LocalDir'
    in the code DkCoder automatically creates a module that has all the
    assets (think [ocaml-crunch]). If a script does not need the assets,
    the `codept' analysis knows it doesn't use `Tr1Assets', and the
    assets won't waste time getting built.
  • Step 3: The *one-to-one .ml/.cma correspondence* means DkCoder can
    apply a unique set of compiler flags to each `.ml' file. You get the
    Java-like package structure by opening a unique set of modules per
    `.ml' with `-open' flags (nit: I also used implicitly created
    directory modules to let you navigate the packages in your source
    code).
  • Step 4: You can take the generated `dune-project' and `dune' files,
    tweak them and run them outside of DkCoder. /That means you are not
    locked into DkCoder!/ You can alternatively do what I did with
    Snoke: make your project compatible with both regular dune
    (/ocamlbuild/etc.) and DkCoder. Either way, you only need to deal
    with two issues that arise from DkCoder's bytecode compilation and
    prebuilt C libraries: a) build C dependencies yourself, and b) tell
    Dune to switch from bytecode mode to native code mode. If you are a
    mildly experienced Linux/OCaml user who understands the terms
    "opam", "pkg-config", "depexts", and "dune-configurator", this is a
    low bar.

  Script references:
  • [https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git]
  • [https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git]


[the `codept' OCaml dependency analyzer]
<https://discuss.ocaml.org/t/local-open-seems-to-confuse-dunes-dependency-cycle-detector/9529/2?u=jbeckford>

[ocaml-crunch] <https://v3.ocaml.org/p/crunch/latest>

[https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git]
<https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git>

[https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git]
<https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git>


Ocaml-protoc-plugin 6.1.0
═════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-6-1-0/14566/1>


Anders Fugmann announced
────────────────────────

  I'm happy to announce the release of [Ocaml-protoc-plugin] version
  6.1.0 Ocaml-protoc-pluginis a plugin for google's protobuf compiler
  (`protoc') that generates an idomatic ocaml mapping and
  (de-)serialization functions based on .proto files. The library aims
  to be 100% compliant implementation of the protobuf specification.

  The 6.1.0 (and 6.0.0) release introduces Json serialization and
  deserialization based on protobuffers guidelines and the ability to
  copy comments from .proto into ocaml generated code for improved
  documentation as well as numerous bug fixes and other improvements.

  *Full changelog since release 5.0.0*


[Ocaml-protoc-plugin]
<https://github.com/andersfugmann/ocaml-protoc-plugin>

6.1.0: 2024-04-25
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Fix name resolution leading to wrongly mapped names
  • Fix codegen bug causing the plugin to reject valid protobuf
  • Add preliminary support for melange though disabling eager
    evaluation of serialize and deserialize functions when not using
    native or bytecode backends
  • Fix missing cflags when compiling test c stub
  • Make Map tests compatible with older versions of protoc
  • Fix negative integer test failues due to a bug in older versions of
    protobuf (google) c lib


6.0.0: 2024-04-13
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ New features

  • Implement json serialization and deserialization (#5)
  • Support special json mapping for google types (#9)
  • Add deprecation annotations for deprecated fields, services etc (#8)
  • Add option to prefix generated files with their package name
  • Copy documentation from proto files into generated ocaml bindings


◊ Bug fixes

  • Fix file output name if files contains a '-'
  • Resolve bug for Request/Response module aliases leading to
    generating uncompilable code. (#21)
  • Fix codegen bug for messages without fields and setting
    singleton_records = true (#20)
  • In Services, the package field is now correctly set to None if the
    service if not defined in a package scope (#24)


◊ Misc changes

  • Unify serialization and deserialization spec and optimize oneof
    handling
  • Simplify types used in code generation to improve readaility
  • *Replace `val name': unit -> string' with `val name: unit -> string'
     which will only return the full protobuf name
  • Optimize merge functions by applying eager evaluation
  • Change signature of `to_proto'' to return unit and not a writer

  (`*' indicates breaking change)


◊ Notes

  `Message.name': unit -> string' has been renamed to `Message.name:
    unit -> string', and is now contains the fully qualified protobuf
    message name. Before the name was the ocaml module name of the
    message.

  `Service.Message' signature has been deprecated and replaced with
  `Spec.Message' signature. `Service.Message' is now an alias for
  `Spec.Message' and will be removed in future releases.


Other OCaml News
════════════════

From the ocaml.org blog
───────────────────────

  Here are links from many OCaml blogs aggregated at [the ocaml.org
  blog].

  • [OCaml Backtraces on Uncaught Exceptions]
  • [Under the Hood: Developing Multicore Property-Based Tests for OCaml
    5]


[the ocaml.org blog] <https://ocaml.org/blog/>

[OCaml Backtraces on Uncaught Exceptions]
<https://ocamlpro.com/blog/2024_04_25_ocaml_backtraces_on_uncaught_exceptions>

[Under the Hood: Developing Multicore Property-Based Tests for OCaml 5]
<https://tarides.com/blog/2024-04-24-under-the-hood-developing-multicore-property-based-tests-for-ocaml-5>


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
  to the [caml-list].

  [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>

[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>

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


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