[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Nov 17 01:23:10 PST 2020
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.schmitt at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20201117/b4dd051d/attachment-0001.html>
More information about the caml-news-weekly
mailing list