[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Aug 9 01:02:39 PDT 2022
Hello
Here is the latest OCaml Weekly News, for the week of August 02 to 09,
2022.
Table of Contents
─────────────────
pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications
Interesting OCaml Articles
Logs to a file (a primitive way)
Timedesc 0.8.0 - modern date time handling
OCaml website: Owl book not listed
Application-specific Improvements to the Ecosystem
Other OCaml News
Old CWN
pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications
════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-pyml-bindgen-a-cli-app-to-generate-python-bindings-directly-from-ocaml-value-specifications/8786/8>
Ryan Moore announced
────────────────────
New release
╌╌╌╌╌╌╌╌╌╌╌
Version 0.4.1 is now available from [GitHub] and [Opam]. The [change
log] has more details.
[GitHub]
<https://github.com/mooreryan/ocaml_python_bindgen/releases/tag/0.4.1>
[Opam] <https://opam.ocaml.org/packages/pyml_bindgen/>
[change log]
<https://github.com/mooreryan/ocaml_python_bindgen/blob/main/CHANGELOG.md>
New stuff
╌╌╌╌╌╌╌╌╌
New attributes
┄┄┄┄┄┄┄┄┄┄┄┄┄┄
There is a new attribute you can use: `py_arg_name'. It allows you to
use different argument names on the OCaml side from those that are
used on the Python side.
One use case is for Python functions that have an argument name that
is the same as some reserved OCaml keyword. In this case, you can use
`py_arg_name' to map it to something else on the OCaml side.
┌────
│ val f : t -> method_:string -> unit -> string
│ [@@py_arg_name method_ method]
└────
The attribute is followed by two items, the first is the argument name
on the OCaml side, and the second is the argument name on the Python
side.
See the [attributes example] on GitHub for more info.
[attributes example]
<https://github.com/mooreryan/ocaml_python_bindgen/tree/main/examples/attributes>
Helper scripts
┄┄┄┄┄┄┄┄┄┄┄┄┄┄
I added a couple of scripts to help in cases where you need to run
`pyml_bindgen' on a lot of different input files in one go. I have
been using them when writing bindings for bigger Python libraries, and
in cases where there are a lot of cyclic python classes to bind.
[This] example has more info about using the helper scripts.
[This]
<https://github.com/mooreryan/ocaml_python_bindgen/tree/main/examples/recursive_modules>
Other stuff
┄┄┄┄┄┄┄┄┄┄┄
• Added an option to split generated modules into `ml' and `mli'
files.
• Added a dev package for (hopefully) easier installation of
development dependencies.
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/99>
Calascibetta Romain announced
─────────────────────────────
Hi, I would like to share my recent article about GADTs and state
machines: [GADTs and state machine]
It's another introduction about GADTs and it explains a bit what I did
for [robur.io]. Eenjoy it and happy hacking!
[GADTs and state machine]
<https://blog.osau.re/articles/gadt_and_state_machine.html>
[robur.io] <https://robur.io>
Logs to a file (a primitive way)
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/logs-to-a-file-a-primitive-way/10262/1>
🌍 Marcus Rohrmoser asked
─────────────────────────
I found
<https://github.com/oxidizing/sihl/blob/c6786f25424c1b9f40ce656e908bd31515f1cd09/sihl/src/core_log.ml#L18>
and wonder what a primitive way to log to a file would be.
I need to keep `stdout' clean and not show any log message under all
circumstances.
🌍 Marcus Rohrmoser later added
───────────────────────────────
I do a cgi and `stdout' is the response – logging has to go to a
separate file. Not even `stderr' as I want debug logs not to taint the
webserver error log in case. And I would like to funnel logging
through `Logs'.
Yawar Amin suggested and 🌍 Marcus Rohrmoser replied
────────────────────────────────────────────────────
I don't know about `logs' but it should be relatively easy
to keep an open file handle and print log messages there.
<https://opam.ocaml.org/packages/logs/> - I like the loglevel
approach. But maybe I will do without and pass around the channel,
yes.
Jean Michel suggested
─────────────────────
I believe logs support logging to a file via Format. See
<https://erratique.ch/software/logs/doc/Logs/index.html#val-format_reporter>
Shon also suggested
───────────────────
I’ve found logs very ergonomic and easy to work with. I tend to pull
it in via [Bos], which has a very nice interface to OS
interactions. Opening the `Bos_setup' module also does default logs
configuration, and I find all quite painless and pleasant.
[Bos] <https://erratique.ch/software/bos>
🌍 Marcus Rohrmoser said
────────────────────────
thanks @yawaramin @beajeanm @shonfeder, I took a [middle ground] and
went along the lines of <https://opam.ocaml.org/packages/logs/> (using
the loglevels and logging call style) but base writing almost directly
on [out_channel]. (I need a log rotation on top)
I was struggling with lost messages however – the logfile remained
empty until I flushed after each log message.
Is that known behaviour that writing to a channel (with
[Printf.fprintf]) doesn't necessarily end up in the file? Even when
closed quickly.
[middle ground]
<https://codeberg.org/mro/seppo/src/branch/develop/lib/logr.ml>
[out_channel] <https://ocaml.org/api/Stdlib.html#TYPEout_channel>
[Printf.fprintf] <https://ocaml.org/api/Printf.html>
UnixJunkie replied
──────────────────
You must Printf.printf with "%!" at the end of your format string, to
be sure that the log is flushed to file.
That's what I do in dolog: <https://github.com/UnixJunkie/dolog>
Timedesc 0.8.0 - modern date time handling
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-timedesc-0-8-0-modern-date-time-handling/10138/2>
Darren announced
────────────────
Tiny update: Timedesc 0.9.0 has been released, moving `sexplib'
dependency into `timedesc-sexp' and moved from `mparser' to `angstrom'
for some date time text parsers since angstrom is a strict necessity
for some binary (de)serialization already.
This overall means Timedesc is about as slim as it can get as a date
time handling lib, depending only on: `seq', `angstrom', `result', and
`ptime' (`ptime' is not a strict dependency, but it's nice to have
timedesc <-> ptime convertors).
Florent Monnier asked
─────────────────────
Is this a lib that targets to process dates and time in a
programmatically way? (this is what the provided example make me
think) Or is it also supposed to be used to print something readable
for a user else than a programmer?
If there is no end-user goal in this lib, please just ignore my
message, and sorry to make you lose some time.
In the other case if you consider printing for end users, it's maybe
worth to mention that there is the [DateLocale-ocaml] module that is
available and which provides the name for the months, and days for
more than 200 languages. It also provides abbreviated versions for
both months and days, which are often used.
The [ocaml-community/calendar] was not designed with localisation in
mind, it just does `String.sub d 0 3' to provide short names, which
will not work with languages that need UTF8.
There is this PR that is still waiting for some review since 2 years
to make it compatible with localisation:
[ocaml-community/calendar/pull/33].
(At least the patch is available there for someone who could be
interested.)
I don't know if it could interest some one but I see that the example
outputs a list of dates, that look like some kind of logs. In case
some one would like to visualise it in a way similar than the unix
command `cal' you can just create empty files where the file name
follows the pattern YYYY-MM-DD like for example "dir/2022-08-06.txt",
you will then be able to visualise it in the console with [detri].
[DateLocale-ocaml] <https://github.com/fccm/DateLocale-ocaml>
[ocaml-community/calendar] <https://github.com/ocaml-community/calendar>
[ocaml-community/calendar/pull/33]
<https://github.com/ocaml-community/calendar/pull/33/commits/9fcd7386e287f8841e503fb1d1e0547295aeb0c9>
[detri] <https://github.com/fccm/detri>
Darren replied
──────────────
Is this a lib that targets to process dates and time in a
programmatically way? (this is what the provided example
make me think) Or is it also supposed to be used to print
something readable for a user else than a programmer?
Development has been primarily focused on former, mostly because
solving it properly was already (very) involved.
Now that Timedesc has stabilised, the latter reads like a very nice
next TODO to match feature parity of other date time libs.
In the other case if you consider printing for end users,
it’s maybe worth to mention that there is the
[DateLocale-ocaml] module that is available and which
provides the name for the months, and days for more than
200 languages. It also provides abbreviated versions for
both months and days, which are often used.
Looks neat! I believe there have been requests of locale sensitive
pretty printing/conversion functions, so I definitely would be
interested in incorporating your work (if that was the intention).
I don’t know if it could interest some one but I see that
the example outputs a list of dates, that look like some
kind of logs. In case some one would like to visualise it
in a way similar than the unix command `cal` you can just
create empty files where the file name follows the pattern
YYYY-MM-DD like for example “dir/2022-08-06.txt”, you will
then be able to visualise it in the console with [detri].
I was interested in something like this for another small utility cmd
I've written, neat!
[DateLocale-ocaml] <https://github.com/fccm/DateLocale-ocaml>
[detri] <https://github.com/fccm/detri>
OCaml website: Owl book not listed
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-website-owl-book-not-listed/10274/1>
Andreas Poisel said
───────────────────
It would be nice to add [OCaml Scientific Computing] to the list on
<https://ocaml.org/books>.
This is a great book and it would be a shame not to promote it. Maybe
anyone responsible for the website reads this or can point me in the
right direction.
I'm not in any way affiliated with the authors of this book.
[OCaml Scientific Computing]
<https://link.springer.com/book/10.1007/978-3-030-97645-3>
Application-specific Improvements to the Ecosystem
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/application-specific-improvements-to-the-ecosystem/10223/49>
Deep in this thread, Kay-Uwe Kirstein said
──────────────────────────────────────────
Personally, I often use the monadic Result type together with a
polymorphic variant for the actual errors. This makes dealing with
errors from different "levels" of my software (library, command-line
tool, and GUI) quite comfortable (and type-safe!). @keleshev has
written a nice blog post on this:
<https://keleshev.com/composable-error-handling-in-ocaml> with a
recent follow up:
<https://keleshev.com/advanced-error-handling-in-ocaml>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Irmin in the Browser]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Irmin in the Browser]
<https://tarides.com/blog/2022-08-02-irmin-in-the-browser>
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] <https://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <https://alan.petitepomme.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20220809/36252630/attachment-0001.html>
More information about the caml-news-weekly
mailing list