Hello Here is the latest OCaml Weekly News, for the week of November 10 to 17, 2020.
Table of Contents ───────────────── latest batteries release: v3.2.0 OCaml User Survey 2020 VSCode OCaml Platform v1.4.0 Directories, an ocaml library Lwt vs System threads OCaml for ARM MacOS Introduction to the module system Getting resulting sig and struct of a complex modular program New release of ocaml-r Reflections on my first completed application in OCaml Help needed testing decimal package OCaml 4.12.0, first alpha release Experimental new layout for the ocaml-variants packages in opam-repository Messages, a library for type safe encoding and decoding Old CWN latest batteries release: v3.2.0 ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-latest-batteries-release-v3-2-0/6738/1> UnixJunkie announced ──────────────────── The batteries maintainers are pleased to announce the latest minor release of OCaml batteries-included: v3.2.0. Batteries is an open-source, community-maintained, extended standard library for OCaml. The latest version is available in opam. Thanks to all the contributors for this release! The change log follows: v3.2.0 (minor release) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • BatArray.fold_while: ('acc -> 'a -> bool) -> ('acc -> 'a -> 'acc) -> 'acc -> 'a array -> 'acc * int [#974] (Francois Berenger, review by Cedric Cellier) • Support for OCaml 4.12 [#980] (kit-ty-kate) • BatArray.fold is an alias for fold_left [#976] (Francois Berenger) • BatList.fold is an alias for fold_left [#975] (Francois Berenger) • BatArray.count_matching: ('a -> bool) -> 'a array -> int [#972] (Francois Berenger) • BatList.count_matching: ('a -> bool) -> 'a list -> int [#816] (Francois Berenger) • Provide an explicitly unthreaded package For Dune, provide an alternative batteries.unthreaded package [#970] (Jerome Vouillon) • BatList.findi: correct documentation [#967] (Francois Berenger) • BatOptParse.unprogify: bug fix (issue [#965]) '%prog' was replaced only once, now it is always replaced (in accordance with the documentation) [#966] (Francois Berenger, report by OnkV) • Expose Map.remove_exn and Set.remove_exn: 'a -> 'a t -> 'a t [#954] (Cedric Cellier) [#974] <https://github.com/ocaml-batteries-team/batteries-included/pull/974> [#980] <https://github.com/ocaml-batteries-team/batteries-included/pull/980> [#976] <https://github.com/ocaml-batteries-team/batteries-included/pull/976> [#975] <https://github.com/ocaml-batteries-team/batteries-included/pull/975> [#972] <https://github.com/ocaml-batteries-team/batteries-included/pull/972> [#816] <https://github.com/ocaml-batteries-team/batteries-included/pull/816> [#970] <https://github.com/ocaml-batteries-team/batteries-included/pull/970> [#967] <https://github.com/ocaml-batteries-team/batteries-included/pull/967> [#965] <https://github.com/ocaml-batteries-team/batteries-included/issues/965> [#966] <https://github.com/ocaml-batteries-team/batteries-included/pull/966> [#954] <https://github.com/ocaml-batteries-team/batteries-included/issues/954> OCaml User Survey 2020 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624/16> Xavier Leroy announced ────────────────────── The OCaml survey 2020 is now closed. It attracted 745 replies. Everyone should be able to see [the summary of results] and to download [the raw data]. I and a few others will try to write a summary of the replies, especially of the many free-form replies. Everyone is welcome to help sifting through the results! Short comments can be posted in this discussion thread, and longer analyses can be put somewhere else and mentioned here. [the summary of results] <https://docs.google.com/forms/d/1OZV7WCprDnouU-rIEuw-1lDTeXrH_naVlJ77ziXQJfg/viewanalytics> [the raw data] <http://cambium.inria.fr/~xleroy/tmp/OCaml-user-survey.csv.zip> VSCode OCaml Platform v1.4.0 ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-4-0/6748/1> Max LANTAS announced ──────────────────── We are happy to announce the v1.4.0 release of [VSCode OCaml Platform], a Visual Studio Code extension for OCaml. It will be available shortly on the [VSCode Marketplace]. This release has the following changes: • Stop highlighting ocaml unit/array/list literals with bold ([#416]) • Add a snippet `struct end' with prefix `struct' ([#420]) • Only restart the language server for the `ocaml.server.restart' command ([#426]) • Use highlighting for character literals which is consistent with other languages in VS Code ([#428]) • Allow using `${workspaceFolder:folder_name}' placeholder variables in sandbox configurations for portable settings.json files ([#424]) • Fix OCaml problem matcher for warning codes and error messages without characters ([#429]) The workspace folder variables in sandbox configurations should make configurations portable, a common request we've had. The extension will now use portable settings by default for local opam switches and esy configurations. Please feel free to share feedback. [VSCode OCaml Platform] <https://github.com/ocamllabs/vscode-ocaml-platform> [VSCode Marketplace] <https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform> [#416] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/416> [#420] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/420> [#426] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/426> [#428] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/428> [#424] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/424> [#429] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/429> Directories, an ocaml library ═════════════════════════════ Archive: <https://discuss.ocaml.org/t/directories-an-ocaml-library/6753/1> OCamlPro announced ────────────────── We are pleased to present [directories], which is an [OCaml] library that provides configuration, cache and data paths (and more!) following the suitable conventions on [Linux], [macOS] and [Windows]. It is inspired by similar libraries for other languages such as [directories-jvm]. The following conventions are used: • [XDG Base Directory Specification] and[xdg-user-dirs] on Linux • [Known Folders] on Windows • [Standard Directories] on macOS On Linux and macOS it has no dependency. On Windows, it depends only on [ctypes]. You will find more information here: [https:][//github.com/OCamlPro/directories] [directories] <https://github.com/OCamlPro/directories> [OCaml] <https://en.wikipedia.org/wiki/OCaml> [Linux] <https://en.wikipedia.org/wiki/Linux> [macOS] <https://en.wikipedia.org/wiki/MacOS> [Windows] <https://en.wikipedia.org/wiki/Microsoft_Windows> [directories-jvm] <https://github.com/dirs-dev/directories-jvm> [XDG Base Directory Specification] <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html> [xdg-user-dirs] <https://www.freedesktop.org/wiki/Software/xdg-user-dirs/> [Known Folders] <https://docs.microsoft.com/fr-fr/windows/win32/shell/known-folders> [Standard Directories] <https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW6> [ctypes] <https://github.com/ocamllabs/ocaml-ctypes> [https:] <https://github.com/OCamlPro/directories> [//github.com/OCamlPro/directories] <https://github.com/OCamlPro/directories> Lwt vs System threads ═════════════════════ Archive: <https://discuss.ocaml.org/t/lwt-vs-system-threads/5007/28> Continuing this thread, Robin Björklin said ─────────────────────────────────────────── The article you linked is an interesting read. This [talk on youtube] also explains the difference in an easily digestible way. Looking at [awesome-ocaml] there doesn't seem to be a web framework that relies on threading. Is there one out there somewhere? [talk on youtube] <https://www.youtube.com/watch?v=kdzL3r-yJZY> [awesome-ocaml] <https://github.com/ocaml-community/awesome-ocaml#web-development> Simon Cruanes replied ───────────────────── It's a very far cry from a framework, but my [tiny httpd] relies on threads and works pretty well for http 1.1. [tiny httpd] <https://github.com/c-cube/tiny_httpd> OCaml for ARM MacOS ═══════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-for-arm-macos/6019/15> Paolo G. Giarrusso asked ──────────────────────── News, now that M1 is out? Anil Madhavapeddy replied ───────────────────────── OCaml 4.12 will have full native code macOS/ARM support. The first alpha is due out any day now, and the ecosystem tools will be ready on the day of its release as well, thanks to the [OCaml readiness team's efforts] [OCaml readiness team's efforts] <https://github.com/ocaml/opam-repository/issues/17530> EduardoRFS also replied ─────────────────────── @Blaisorblade currently with my backport to OCaml 4.10 everything is working, a couple of months ago I did bootstrap opam using it. This one, <https://github.com/EduardoRFS/ocaml/tree/4.10+ios+esy> Introduction to the module system ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/introduction-to-the-module-system/6760/1> Christian Lindig announced ────────────────────────── Stephen Diehl has started a series of blog posts about [module systems] using OCaml as an example. This provides a nice introduction to the finer points. [module systems] <https://www.stephendiehl.com/posts/exotic01.html> Getting resulting sig and struct of a complex modular program ═════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/getting-resulting-sig-and-struct-of-a-complex-modular-program/6762/1> Luc_ML asked ──────────── The OCaml module system let create a very modular program with quite unlimited complexly nested sig and struct, while avoiding redundancy. But the resulting documentation reflects exactly that, which makes it hard to read, resulting in jumping from one sig (or struct) to another. It may give headache and especially provoke mistakes when writing an expression with illegal type. What is the straightest manner to get the *resulting* signature and structure of an OCaml program: • in its generated documentation • from the toplevel (it seems roughly to work with `#show_module module-path' but it sometimes has weird behavior/result) The error messages are also more complex, revealing the modular structure. It can even be harder to understand when polymorphic variants are used! Is there a way to limit that burden? One *simplistic* idea would be to program in a modular way, then to "flatten" the whole program in order to let him expose the resulting sig/struct. Is that idea sensible, and how to simply do that? Christian Lindig replied ──────────────────────── If you are interested in generating the documentation of such a structure - this is not an easy problem and was the topic of a talk at this year's OCaml Workshop: [The final pieces of the OCaml documentation puzzle] Rendering OCaml document is widely known as a very difficult task: The ever-evolving OCaml module system is extremely rich and can include complex set of inter-dependencies that are both difficult to compute and to render in a concise document. Its tasks are even harder than the typechecker as it also needs to keep track of documentation comments precisely and efficiently. As an example, signatures such as include F(X).T and destructive substitutions were never handled properly by any documentation generator. [The final pieces of the OCaml documentation puzzle] <https://www.youtube.com/watch?v=wVyZ-KveN-w> New release of ocaml-r ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-release-of-ocaml-r/6765/1> Philippe announced ────────────────── It is my pleasure to announce the 0.4 release of `ocaml-r', a library providing bindings to the [R statistical environment] interpreter and a few of its standard libraries. Documentation: <http://pveber.github.io/ocaml-r/index.html> Repository: <https://github.com/pveber/ocaml-r> This new release brings a big API change, where the bindings are exposed through modules and abstract types instead of types parameterized by object types. The new style is similar in spirit to what's offered in Lexify's [gen_js_api] or Daniel Bünzli's [Brr]. The result is hopefully a lot easier to read and use, and incidentally provides a condensed (although incomplete) specification of R's type system. Finally the documentation, while it's far from being exhaustive, has improved a bit. On this topic, I'd like to address a warm and loud thank you to all the good people involved in [odoc]: you're changing people's life for the better ;) [R statistical environment] <https://www.r-project.org/> [gen_js_api] <https://github.com/lexifi/gen_js_api> [Brr] <https://erratique.ch/software/brr> [odoc] <https://github.com/ocaml/odoc> Reflections on my first completed application in OCaml ══════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/reflections-on-my-first-completed-application-in-ocaml/6768/1> Christopher Dieringer told ────────────────────────── Greetings! I'm a new OCaml user. The intent of this post is simply to share my experience thus far in OCaml and hopefully generate some casual conversation about how other community users think about & use OCaml. What do I hope to get from this post? Critiques, affirmation, tips, whatever. I learned OCaml alone, in a bubble, during pandemic lockdown. Was my experience the classic OCaml learning experience, or was it unique in some way? I'm hoping to garner feedback from other community members. Talk at me! :) What's my project? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • <https://github.com/cdaringe/freshawair> tl;dr, freshawair is a system that collects and presents air quality datas from my in-home air quality monitor. Awair ships a mobile app to observe your air quality stats, but the app doesn't let you observe data more than a week old. Further, the app does not let you bin the timeseries data. I wanted to be able to see macro, seasonal trends on various air quality metrics in my home. Lucky for me, the sensor unit exposes a HTTP API, allowing me to capture data easily and get busy. Sounds like a fun COVID "time to learn OCaml project!" <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/e/eb73c493f5d7c731664c457e269d17217ac9f46f.gif> Why OCaml? ╌╌╌╌╌╌╌╌╌╌ My key interests in selecting OCaml for this project were: • Binaries. code that runs artifacts on the metal. no VM required! having a thin runtime was not inhibiting. • I was originally targeting ARM on a low powered device, so this was essential. • functional language. I'm tired of the same old problems from _other-langs_. I've been on a kick, learning languages that seem to support or tend towards correctness. • Effects. I recently worked on <https://effects.js.org>, and I wanted to experience effects, first-class, in a language. ◊ How does the project work? There are four parts: • agent - ocaml - collects data from the awair http api, forwards data to the freshawair server • server - ocaml - hosts api, hosts ui static assets • database - timescaledb - omitted from discussion • ui - react/typescript - omitted from discussion The agent and the server could have been combined into one binary. However, the original designed called for the server and DB to live in the cloud, while the agent would exist in my local network only. The design still supports this, even though I now just deploy all of the things side-by-side on my NAS. How'd it go? ╌╌╌╌╌╌╌╌╌╌╌╌ Overall, pretty good. I've grown quite affectionate towards ML. Having done a bit of Elm before, and just a nibble of recreational Haskell, OCaml _fundamentals_ were not hard to pick up. The module system, figuring out where common functionality lives (or if common functionality even existed in the core lib), & perhaps configuring builds all cumulatively took a little more time than I would have liked, but hey–that's learning. Regardless of the the hype around multicore, which I am certainly excited about, pragmatically `effects' don't exist in ocaml yet. No ARM support, ppx_tools incompat, etc in the multicore compiler. Effects was one of my primary decision drivers in selecting OCaml, so I felt a bit bamboozled as I slowly uncovered that this lack of compatibility with mainline compilers was the status-quo. Even so, I have no remorse. ◊ What was great? • discord community. thanks everyone for helping me with so many questions • docker images/infrastructure. just top tier work right there. • ocaml platform editor support for vscode • it has its quirks, but it's also new. having a clear "this is the tooling to use" directive, and having it actually work (most of the time) was quite nice. • responsive community • during the course of the project, i added comments in maybe 6-12 community GitHub projects. i got feedback in _every single one_. OCaml may be a small community, but it's real people committed to the cause ;). what a delight this was. seriously! you are nerds helping helping nerds. be proud. • Core as a std lib was easy to explore, and was a great start to hack away at an empty file. • Opium. I originally wrote my server in plain-jane cohttp, and recently refactored it to opium. Love it! ◊ What was just OK It's easier to remember recent suffering for me, so forgive the fact that the below lists are a bit longer than the "great!" list. • Real World OCaml is a good book–truly. Even so, I personally do not think that it is the right book to bootstrap newbies, nor get people excited about OCaml. It's more of a handbook, versus a guided tutorial on how to start doing productive _things™_ common to software development. It certainly beats the manual, and certainly beats nothing–100%. • Richard Feldman has words to say on the matter (<https://corecursive.com/teaching-fp-with-richard-feldman/>), where you can replace any mention of haskell with ocaml. To poorly distill his thoughts, FP pedagogy seems to focus first on underlying concepts then secondarily on application, versus focusing first on incremental, practical applications, then secondarily exploring required concepts during the ride. Having "learned" haskell and eventually ejecting from it, this interview resonated. OCaml is much more approachable than Haskell (better docs, tools, etc), but I'm still looking for "OCaml In Action". RWO didn't scratch my itch. It feels foolish to critique something that the community offered to me for free, so maybe I should just hush up :). • ReasonML. ReasonML is what exposed me to OCaml, but once I started using OCaml, my interest in ReasonML dwindled rather quickly. That is a bummer because I love building UIs and I'm a react power user. I'm sure there's an interesting history in this space (I'm totally oblivious), but I just can't help but wonder what would have happened if all of that OCaml-ish UI work was reinvested in the OCaml community vs this UI-specific fork-ish project. I prefer the ML syntax, even though reason is supposedly catering to me, a TypeScript power user. When I finally ejected reason out of my OCaml project, I lost npm as a package source, and that caused some headache as I had to move fully into opam deps, vs getting deps from both places. It was pretty cool that I could co-locate `.ml' and `.re' files together, though! Maybe I'll take some time to look at the history here (links welcomed). Anyway, I ended up doing my UI via create-react-app + typescript, to avoid the growing pains of figuring out ReScript or jsoo, while simulatenously learning OCaml :). • `json' operations. It took me much too long to just _figure out_ how to do the basics w/ JSON. I eventually landed on `yojson' & `ppx_deriving_yojson.runtime', but was distracted by `atdgen'. I understand there are cost-benefit analyses required when choosing tools, but I was hoping to have landed on a solution within minutes of research. I won't tell you how long it actually took me just to get my JSON serialization and deserialization code in place. Hint: too darn long! • regex. <https://pl-rants.net/posts/regexes-and-combinators-2/> was quite helpful • `dune' & `opam'. both are seemingly polished tools. I wish they were married, into a single OCaml project management tool. I get that they have different roles, but #opinons. • Additionally, a `.nvmrc' pattern would be nice. For instance, I alias `cd' on my system to execute `nvm/fnm use' on every cd _iff_ a .nvmrc is found, s.t. when getting to work for the day, I'm always have the right switch loaded. ◊ What wasn't great • resolving compiler errors. no surprise. • commonly, in order to try and help narrow the problem space, i'd try and add explicit types, but even figuring out what types (let alone how to access to them) was often a bit tedious • FWIW, the reasonml error message formatter was _awesome_ in improving OCaml compiler error messages. we should seriously consider baking that thing straight in. • no integrated debugger. 🤷🏻♀️. MS is doing really great work with <https://microsoft.github.io/debug-adapter-protocol/>. maybe some motivated soul will be my hero someday. • lwt promises vs core deferreds. whatever the async primitives will be in the future, we should probably dedupe this as a community. further, we should probably also bake them right into the stdlib if we are going to continue to have colored functions. i spent time studying deferreds only to later discover that most of the things I wanted to do and use were lwt-centric. RWO puts you down the deferreds path, but _actual, for real ocaml_ seems more aligned on Lwt. Disagree? Then now we know we have a problem :laughing:. I ended up refactoring a moderate amount of early code for this reason. It was a tad bit obnoxious, especially that it felt out-of-band with the learning trajectory set forth in RWO. Perhaps that's on me :). • Producing statically linked binaries proved unproductive. I can't recall all of the errors I ran into, I was just hoping to flip a switch and get statically linked everything. Nope! Terrible assumption. Surely portable software can exist again one day. :crossed_fingers: • `esy'. It sounded like `esy' it's was going to be great for bootstrapping a project, but ultimately understanding `dune' and `opam' was more productive, even as someone deeply familiar with `package.json'-isms. I used it for a while, and am glad to have removed it. • string interpolation. i want automatic toplevel sprintf-like functionality in string literals. `let str = "wah wah boo hoo I want ${featureName} yesterday!" ...' would be pretttty cool :ok_hand: ◊ What's next? • I'd eventually like to try `jsoo'. I saw that some react-bindings are in work. _Sweet_. Even if there was an Elm-like UI lib, I'd be keen on that as well. • Performance. • I'm pretty sure my postgresql cursor usage is blocking my single thread on the server. Async-ifying my postgres cursor for piping datas into my `Lwt_stream' seems worthwhile, if possible. • Request less data in the UI. Specifically, request only data that is expected to be painted. Currently I request a boat-load of data that the user may not be interested in. • Tests. :grimacing: Don't look! • De-cruft-ify some malarkey. There's some values hardcoded in there that really don't belong. There's perhaps some not-very OCamly patterns that need tidying up that suffer from beginner-isms. Anyway. _OCaml_. Great language. Will I keep using it? _Definitely!_ I'm glad to be here. Thx all! Yawar Amin then said ──────────────────── Hi, thanks for this write-up, very interesting and super valuable to hear what new users are going through. FWIW, I think you made the right call going with TypeScript; when learning something new, it's better to focus on one thing at a time. Btw, opam does support the `.nvmrc' style, see <http://opam.ocaml.org/blog/opam-local-switches/> Emile Trotignon also replied ──────────────────────────── Nice thoughts. I think I will do a library for string interpolation - it should just be a simple ppx. You can already check out this project : <https://github.com/EmileTrotignon/embedded_ocaml_templates>, that attempts to be EJS for OCaml (not every feature is here though), and provide the following syntax: ┌──── │ let name = "John" │ let john = [%eml "Name : <%-name%>"] └──── However I the `${...}' syntax in a package that would not allow control structures, just interpolation, would definitely be useful. Maybe it even already exists, I will check before I try and implement it ^^ Edit : it does exists : <https://github.com/bloomberg/ppx_string_interpolation> Patrick Ferris also replied ─────────────────────────── Thanks for the incredibly well written and useful write up, especially describing the things you like, think are okay and weren't so great. I can't speak about how to resolve all of your pain-points (e.g. no integrated debugger) but what I can say is that: guided tutorial on how to start doing productive *things™* is actively being worked on, which includes more information (amongst other things) about dune & opam The (very WIP) set of "workflows" for getting productive things done in OCaml can be found [here] and are live [here] (easier to digest full list [here]). The goal is to fill these out more but also maintain the continuous integration which helps ensure they are *working* examples of how to be productive with the OCaml Platform (and friends). As I said, it's early days but I think it is already in a position that at least one user might find something useful in there. Good luck with the rest of your very cool project! [here] <https://github.com/ocaml-explore/explore> [here] <https://ocaml-explore.netlify.app/> [here] <https://github.com/ocaml-explore/explore/tree/trunk/content/workflows> Aaron L. Zeng said ────────────────── In case you needed more options, <https://github.com/janestreet/ppx_string> is another string interpolation ppx. It's part of ppx_jane, so if you're already using that, `[%string]' is available without any further work. Help needed testing decimal package ═══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/help-needed-testing-decimal-package/6772/1> Yawar Amin announced ──────────────────── Hi, I've been working on a `decimal' package: <https://github.com/yawaramin/ocaml-decimal> (arbitrary-precision floating-point decimals). I've published a _very early preview_ on opam: <http://opam.ocaml.org/packages/decimal/> You can try it out: ┌──── │ $ opam install decimal │ $ utop │ # │ module D = Decimal │ let i = D.of_int │ let s = D.of_string;; │ # │ #install_printer D.pp;; │ # │ D.(s "0.1" + s "0.2");; │ - : D.t = 0.3 │ # (* default precision is 32 *) │ D.(i 1 / i 3);; │ - : D.t = 0.33333333333333333333333333333333 └──── The module is basically a port of the [Python decimal] module, with some simplifications like, I'm ignoring different types of NaN like negative NaN, quiet NaN, signalling NaN, and just treating them all as NaN. Otherwise I aim to have the same functionality. What I need help with mainly is porting the Python `decimal' unit tests: <https://github.com/python/cpython/tree/23831a7a90956e38b7d70304bb6afe30d37936de/Lib/test/decimaltestdata> . They are written in a plain-text DSL consisting of test cases like: ┌──── │ addx6324 add 0.12 0.01 -> 0.13 └──── And I assume they have an interpreter somewhere that parses and runs these tests as standard Python unit tests. What I would like to do is to port these tests into plain OCaml. The above test case could look like (e.g. Alcotest): ┌──── │ check string "addx6324" "0.13" D.(to_string (s "0.12" + s "0.01")) └──── The test DSL has a few more features, like comments and setting and checking flags, but not too much more complex. So I would really appreciate some help with porting them. I was thinking good old regular expressions to do the conversions, but I'm open to suggestions. [Python decimal] <https://docs.python.org/3/library/decimal.html> OCaml 4.12.0, first alpha release ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-12-0-first-alpha-release/6777/1> octachron announced ─────────────────── The set of new features for the future version 4.12.0 of OCaml has been frozen, maybe a little earlier than expected. In this new version of OCaml, the gap between the mainline and multicore runtime has been considerably narrowed. Moreover, this new version comes with a port to the newly launched macOs/ARM architecture. We are thus planning to have a shorter release cycle this time around to get this new version out the door as soon as sensible — which probably translates to the beginning of January. I am thus happy to announce the first alpha release for OCaml 4.12.0 . This alpha version is here to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun. You can see the progress on this front at: <https://github.com/ocaml/opam-repository/issues/17530> Once the major tools are supported, we will switch to beta releases. And since changes are more fun when they come in pair, we are also testing a new layout for the opam compiler packages. The base compiler can now be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.12.0~alpha1 │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, the new layout offers much finer-grained options. The new command looks like this: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~alpha1+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where <option_list> is a comma separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 4.12.0~alpha1+flambda+nffa │ --packages=ocaml-variants.4.12.0~alpha1+options,ocaml-option-flambda,ocaml-option-no-flat-float-array │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with `opam search ocaml-option'. If you want to test this version, it is advised to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with ┌──── │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git └──── This alpha repository contains various fixes in the process of being upstreamed. The source code for the alpha is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.12.0-alpha1.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~alpha1.tar.gz> If you find any bugs, please report them here: • <https://github.com/ocaml/ocaml/issues> If you are interested by the ongoing list of new features and fixed bugs, the updated change log for OCaml 4.12.0 is available at: • <https://github.com/ocaml/ocaml/blob/4.12/Changes> Experimental new layout for the ocaml-variants packages in opam-repository ══════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/experimental-new-layout-for-the-ocaml-variants-packages-in-opam-repository/6779/1> David Allsopp announced ─────────────────────── The 4.12.0 alpha1 release is out and with it is an experiment for a new layout for the ocaml-variants packages to try to reduce the number of packages needed for each compiler release and also to allow packages to depend on particular OCaml configurations. Combinatorial explosions in `ocaml-variants' ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ This may seem like pre-history, but back in OPAM 1.x there was a distinction between the compiler and the packages installed in a switch. Every switch essentially had just one special package at its root and OPAM 1.x had the version of OCaml hard-wired into the `ocaml-version' variable. This set-up meant that non-vanilla installations of the compiler (for example, with flambda) had to be encoded on the version number giving us the slightly strange `4.07.0+flambda' version meaning “OCaml 4.07.0 with flambda enabled”. Fast forward to opam 2.0, and this gets generalised with the “compilers-as-packages” feature. The old compiler special package got split into `ocaml-system' (taking on the even more magical and hard-wired internal `system' switch from OPAM 1.x), `ocaml-base-compiler' (for the unaltered or “vanilla” compiler) and then `ocaml-variants' which contained, um, everything else! However, “compilers-as-packages” allows opam 2.x switches not to have the compiler as strictly the root package. The current scheme has a couple of benefits: • It’s immediately clear from the version of the `ocaml-variants' package what you have (for example, `ocaml-variants.4.08.1+fp+flambda') • It’s immediately clear which variants are supported by a given version of OCaml (for example, there is no `ocaml-variants.4.02.3+flambda' package) However, it some serious limitations: • The variants should be combinable, but doing this would lead to thousands of variants. If you need a missing one, the only solution is to have a custom repository • Every single release of the compiler needs to have corresponding variant packages • The very large number of compiler packages considerably increases the pressure on opam’s solvers • It’s not possible to depend on OCaml options (for example, to depend on, or conflict with, no-naked-pointers mode). @kit-ty-kate, @AltGr, and I have at various points done experiments to improve this. Thanks to @octachron, we’re trying one of them out in the safety of the 4.12 alpha/beta/rc packages and, in addition of course to testing your code with OCaml 4.12, we could really do with feedback on this new layout. How it works ╌╌╌╌╌╌╌╌╌╌╌╌ The `ocaml-variants.4.12.0+trunk' package and the new `ocaml-variants.4.12.0~alpha1+options' packages both allow compiler options to be customised by also installing `ocaml-option-' packages: ⁃ `ocaml-option-32bit' - 32bit build ⁃ `ocaml-option-afl' - enable AFL support ⁃ `ocaml-option-bytecode-only' - build bytecode compiler only ⁃ `ocaml-option-default-unsafe-string' - enable unsafe-string by default ⁃ `ocaml-option-flambda' - enable flambda ⁃ `ocaml-option-fp' - enable frame pointers ⁃ `ocaml-option-musl' - use musl instead of libc ⁃ `ocaml-option-nnp' - enable no-naked-pointers mode ⁃ `ocaml-option-no-flat-float-array' - disable flat float arrays in the runtime ⁃ `ocaml-option-spacetime' (for 4.12 this option is not available, since spacetime has been removed) ⁃ `ocaml-option-static' - no dynamic linking This allows options to be combined: for example installing `ocaml-option-32bit' and `ocaml-option-flambda' enables a 32-bit flambda compiler. It’s a bit of a mouthful (more on that below): ┌──── │ opam switch create 4.12-32-bit-flambda │ --packages=ocaml-variants.4.12.0~alpha1+options,ocaml-option-32bit,ocaml-option-flambda │ --repos=default,beta └──── (obviously if the new layout is adopted at release, then the `--repos' part won’t be necessary) In addition to these packages, there are also a small number of `ocaml-options-only-' packages (for example, `ocaml-options-only-flambda'). These packages conflict with other options packages, so for example with this: ┌──── │ opam switch create 4.12-release-builds │ --packages=ocaml-variants.4.12.0~alpha1+options,ocaml-options-only-flambda-fp --repos=default,beta └──── you get a switch with 4.12.0 alpha1 configured for flambda and frame-pointers _and which cannot be changed_. So if you attempt to install a package which depends on `ocaml-option-nnp', for example, then opam will complain of a conflict rather than suggesting that you recompile your switch with `ocaml-config-nnp'. The special package `ocaml-options-vanilla' can be used to make `ocaml-variants.4.12.0~alpha1+options' or `ocaml-variants.4.12.0+trunk' behave like `ocaml-base-compiler'. Currently ╌╌╌╌╌╌╌╌╌ • :white_check_mark: variants can be combined, and they don’t need to be specified with every compiler release • :grey_question: the CLI invocation is slightly more characters to type, though still about as clunky as the existing package names (opam 2.1 slightly improves this) • :grey_question: there’s still a combinatorial explosion with the `ocaml-options-only-*' packages, but we’re hoping that that’s less of a problem since these `only' packages are mainly useful for CI/CD systems • :x: `+trunk' packages still exist • :x: `ocaml-base-compiler.v' and `ocaml-variants.v+options' are an unnecessary and slightly confusing distinction Future work ╌╌╌╌╌╌╌╌╌╌╌ • There’s no reason to be maintaining `ocaml-variants' and `ocaml-base-compiler' separately and we could look to merging these into, say, `ocaml-compiler' • The `+trunk' variants have always been slightly odd - both because the maintenance branches for each release (e.g. [`4.11'], [`4.12']) are not called `trunk' and because the version number refers to an as-yet unreleased version of OCaml (e.g. `4.11.2+trunk'). We’re looking to switch to using `dev-repo' field and pinning, as other packages do, but also trying to keep a lid on the number of simultaneous changes! • opam 2.2 has plans in the pipeline to address “package parameters” properly, which should hopefully improve both the CLI and the number of “configuration-related” packages • The layout _could_ be back-ported to previous versions of the compiler. There are two questions with this: deleting the old variants packages will cause any existing switches to fail to upgrade, so we may wish to keep virtual packages for the old releases (e.g. have `ocaml-variants.4.11.1+flambda' depend on `ocaml-compiler.4.11.1' and `ocaml-options-only-flambda') and there’s also the fact that changing the opam files for these packages will cause _all_ switches to rebuild at next `opam upgrade'! Thanks for making it to the end, and all comments and feedback either to me directly, here on Discuss, or on the [opam-repository issue tracker] are very welcome! [`4.11'] <https://github.com/ocaml/ocaml/tree/4.11> [`4.12'] <https://github.com/ocaml/ocaml/tree/4.12> [opam-repository issue tracker] <https://github.com/ocaml/opam-repository/issues> Messages, a library for type safe encoding and decoding ═══════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-messages-a-library-for-type-safe-encoding-and-decoding/6780/1> Chimrod announced ───────────────── I have published today a library I ve done for my personnal usage : `messages', which allow to encode and decode json data between ocaml applications. The library as been thought in order to exchange data between javascript and server side with a minimum of code. The idea is to declare the type of the json content in a shared code, and then let the application generate the appropriate encoding and decoding functions automaticaly. I wanted something simple and easy to maintain (or extend), and opt for a classic libray instead of ppx rewrite. I found nothing with this design and built my own library :) The code is hosted on github : <https://github.com/Chimrod/messages> This is the first time I'm annoncing a library publically I hope you you will find it usefull for you ! 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.schm...@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/>
_______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly