* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-09-03 7:35 Alan Schmitt
0 siblings, 0 replies; 7+ messages in thread
From: Alan Schmitt @ 2019-09-03 7:35 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 1966 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 27 to
September 03, 2019.
Table of Contents
─────────────────
Ocaml-multicore: report on a June 2018 development meeting in
Paris
Interesting OCaml Articles
Old CWN
Ocaml-multicore: report on a June 2018 development meeting in
Paris
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june-2018-development-meeting-in-paris/2202/10>
Deep in this thread, sid announced
──────────────────────────────────
As a small step towards multicore, its interesting to note that
<https://github.com/ocaml/ocaml/pull/8713> just got merged to
master!
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/46>
Yotam Barnoy announced
──────────────────────
<https://www.ocamlpro.com/2019/08/30/ocamlpros-compiler-team-work-update/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <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/>
[-- Attachment #1.1.2: Type: text/html, Size: 12394 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-10-15 7:28 Alan Schmitt
0 siblings, 0 replies; 7+ messages in thread
From: Alan Schmitt @ 2019-10-15 7:28 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 5627 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 08
to 15,
2019.
Table of Contents
─────────────────
capnp-rpc 0.4.0
Ocaml-protoc.plugin.1.0.0
Old CWN
capnp-rpc 0.4.0
═══════════════
Archive:
<https://discuss.ocaml.org/t/ann-capnp-rpc-0-4-0/4524/1>
Thomas Leonard announced
────────────────────────
I'm pleased to announce the release of [capnp-rpc 0.4.0], an
OCaml
implementation of the Cap'n Proto RPC specification.
If you haven't used the library before, please see the
[documentation
and tutorial]. Cap'n Proto RPC aims to provide secure,
efficient,
typed communications between multiple parties.
This library is now being used to build [ocaml-ci], where it is
used
for all communication between the web frontend and backend
services,
and to provide a command-line client.
[capnp-rpc 0.4.0]
<https://github.com/mirage/capnp-rpc/releases/tag/v0.4.0>
[documentation and tutorial]
<https://github.com/mirage/capnp-rpc/blob/master/README.md>
[ocaml-ci] <https://github.com/ocaml-ci/ocaml-ci>
Main changes since v0.3
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Breaking changes:
• Wrap errors with the ``Capnp' tag to make it easier to compose
with
other types of error.
• Prefix all command-line options with `capnp-'.
e.g. `--listen-address' is now `--capnp-listen-address'. The
old
names were confusing for applications that supported other
protocols
too (e.g. a web server).
New features:
• Add `Capability.with_ref' convenience function. This
automatically
calls `dec_ref' when done.
• Add Unix `Cap_file' module to load and save `Sturdy_refs'. In
particular, this ensures that saved cap files get a mode of
`0o600',
since they contain secrets.
• Export cmdliner network address parsing. This is useful if
you
don't want to use the default option parsing. For example, if
you
want to make Cap'n Proto an optional feature of your program.
• Upgrade from `uint' (which is deprecated) to the newer
`stdint'.
The latest version of `uint' is just a wrapper around
`stdint', so
this shouldn't break anything if you are using the latest
version.
• Put cmdliner options in their own man-page section. Use
`Capnp_rpc_unix.manpage_capnp_options' to control where in
your
man-page they appear.
• Enable `SO_KEEPALIVE' for TCP connections. For use with
Docker's
libnetwork, try something like this in your `stack.yml':
┌────
│ sysctls:
│ - 'net.ipv4.tcp_keepalive_time=60'
└────
Ocaml-protoc.plugin.1.0.0
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-1-0-0/4535/1>
Anders Fugmann announced
────────────────────────
I'm happy to announce the second release of
[ocaml-protoc-plugin].
Ocaml-protoc-plugin is a plugin to googles `protoc' compiler
which
generates type idiomatic to ocaml from `.proto' files including
full
compliant serialization and deserialization functions.
[ocaml-protoc-plugin]
<https://github.com/issuu/ocaml-protoc-plugin>
Most noteworthy changes in this release:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Full proto2 support.
• The list of dependencies has been slimmed way down, and now
only
depends on `conf-protoc' (the `protoc' compiler and googles
*well
known types*).
• Buckescript support.
• Added options to change the ocaml (type for scalar types (int,
int64
or int32).
Many thanks to Wojtek Czekalski for helping trimming
dependencies and
for Buclescript support.
Full changelog:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Support enum aliasing
• Avoid name clash with on 'name'
• Fix code generation when argument contains a path
• Refactor internal types to make serialization and
deserialization
type spec symmetrical.
• Optimize deserialization for messages with max_id < 1024
• Don't depend on Base in runtime
• Slim runtime dependencies: Remove need for base, ocplib-endian
and
ppx_let
• Honor [packed=…] flag.
• Make fixed scalar types default to int32 and int64
• Support proto2 specification
• Add options to switch between int64|int32 and int
• Fix name clash problem with special enum names
• Refactor serialization and deserialization to simplify emitted
code
• Eagerly evaluate serialization (for speed).
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <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/>
[-- Attachment #1.1.2: Type: text/html, Size: 16446 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-05 6:55 Alan Schmitt
0 siblings, 0 replies; 7+ messages in thread
From: Alan Schmitt @ 2019-11-05 6:55 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 1700 bytes --]
Here is the latest OCaml Weekly News, for the week of October 29
to
November 05, 2019.
Table of Contents
─────────────────
vim-ocaml - new home
Old CWN
vim-ocaml - new home
════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-vim-ocaml-new-home/4615/1>
Rudi Grinberg announced
───────────────────────
Dear Vim & Neovim users,
I would like to announce that I've officially moved the
[vim-ocaml]
repository under the control of the OCaml organization on
github. Please direct your bug reports and pull requests to this
repository. This move is done not because vim-ocaml is being
neglected, on the contrary, there's an active team of
maintainers that
recently expanded. I simply want to take this opportunity to
draw more
Vim & Noevim users to this project, as I suspect many users
aren't
aware of recent efforts.
[vim-ocaml] <https://github.com/ocaml/vim-ocaml>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <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/>
[-- Attachment #1.1.2: Type: text/html, Size: 11877 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-12 13:21 Alan Schmitt
0 siblings, 0 replies; 7+ messages in thread
From: Alan Schmitt @ 2019-11-12 13:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 2875 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 05
to 12,
2019.
Table of Contents
─────────────────
Mirage 3.7.1 released
Old CWN
Mirage 3.7.1 released
═════════════════════
Archive:
<https://discuss.ocaml.org/t/mirage-3-7-1-released/4634/1>
Hannes Mehnert announced
────────────────────────
MirageOS 3.7.1 is released to opam repository now.
Breaking change:
• The hooks previously defined in
OS.Main.at_enter/at_enter_iter/at_exit/at_exit_iter are now
part of
Mirage_runtime (only used by mirage-entropy)
<https://github.com/mirage/mirage/pull/1010>
Behaviour changes of MirageOS unikernels:
• A unikernel now always calls the Mirage_runtime.at_exit
registered
hooks – once a unikernel succesfully executed its `start' in
`Lwt_main.run', `exit 0' is called to ensure this behaviour
<https://github.com/mirage/mirage/pull/1011>
• Top-level exceptions are no longer caught (there used to be in
mirage-unix/mirage-xen/mirage-solo5 custom handlers). The
OCaml
runtime prints the exception and backtrace on stdout and calls
exit
2 (from 4.10.0, abort() will be called).
Deprecations (being removed from Mirage 4.0)
• All Mirage_YYY_lwt are deprecated, Mirage_YYY interfaces are
no
longer astracted over 'a io and buffer. This reduces the
amount of
opam packages - mirage-yyy-lwt are no longer part of the
release
(each mirage-yyy package provides a Mirage_yyy_lwt module for
backwards compatibility). Motivation was discussed in
<https://github.com/mirage/mirage/issues/1004>
• mirage-types and mirage-types-lwt are deprecated, please use
the
Mirage_YYY signatures directly instead.
Other observable changes
• `mirage configure' now deletes all exising opam files
Most reverse dependencies are already released to opam, have a
look at
<https://github.com/mirage/mirage/issues/1012> for progress (and
the
temporary <https://github.com/mirage/mirage-dev.git#easy> opam
overlay).
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <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/>
[-- Attachment #1.1.2: Type: text/html, Size: 13405 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-26 8:33 Alan Schmitt
0 siblings, 0 replies; 7+ messages in thread
From: Alan Schmitt @ 2019-11-26 8:33 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 28861 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 19
to 26,
2019.
Table of Contents
─────────────────
tiny_httpd 0.1
printbox.0.3
v0.13 release of Jane Street packages
opam2nix (v1)
GitHub Actions for OCaml / opam now available
OCurrent 0.1 (CI/CD pipeline eDSL)
New pages for OCaml API
Irmin 2.0.0 release
Tail cascade: a new indentation style for some OCaml constructs
Old CWN
tiny_httpd 0.1
══════════════
Archive: <https://discuss.ocaml.org/t/ann-tiny-httpd-0-1/4727/1>
Simon Cruanes announced
───────────────────────
Hello and good morning, I'm pleased to announce that
[tiny_httpd] 0.1
has been released and is on opam.
The goal is to emulate python's standard `http.server' by
providing a
0-dependencies, minimalist, simple HTTP server for embedding in
applications that are not primarily a website, with very basic
routing
(thanks to `Scanf'). A binary `http_of_dir' is also distributed
and
can be used to serve a directory, with optional upload of files.
[tiny_httpd] <https://github.com/c-cube/tiny_httpd>
printbox.0.3
════════════
Archive: <https://discuss.ocaml.org/t/ann-printbox-0-3/4731/1>
Simon Cruanes announced
───────────────────────
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/8/8e7c55c5ab69c12f53a7862d2f84dd6e0cfc0dc0.png>
┌────
│ let b =
│ let open PrintBox in
│ PrintBox_unicode.setup();
│ frame @@ grid_l [
│ [text "subject"; text_with_style Style.bold "announce:
printbox 0.3"];
│ [text "explanation";
│ frame @@ text {|PrintBox is a library for rendering nested
tables,
│ trees, and similar structures in monospace text or
HTML.|}];
│ [text "github";
│ text_with_style Style.(bg_color Blue)
"https://github.com/c-cube/printbox/releases/tag/0.3"];
│ [text "contributors";
│ vlist_map (text_with_style Style.(fg_color Green))
["Simon"; "Guillaume"; "Matt"]];
│ [text "dependencies";
│ tree empty
│ [tree (text "mandatory")
│ [text "dune"; text "bytes"];
│ tree (text "optional")
│ [text "uutf"; text "uucp"; text "tyxml"]]];
│ [text "expected reaction"; text "🎉"];
│ ]
│
│ let () = print_endline @@ PrintBox_text.to_string b
└────
([actual link to the release])
[actual link to the release]
<https://github.com/c-cube/printbox/releases/tag/0.3>
v0.13 release of Jane Street packages
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735/1>
Xavier Clerc announced
──────────────────────
We are pleased to announce the v0.13 release of Jane Street
packages!
This release comes with 14 new packages, and a number of fixes
and
enhancements. The documentation for this release is available on
our
website:
<https://ocaml.janestreet.com/ocaml-core/v0.13/doc/>
The remainder of this mail highlights the main changes since the
v0.12
release; we hope it will be useful to developers in the process
of
migrating to the new version. A comprehensive changelog is
available
at the end.
Notable changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Changed `Base', `Core_kernel', and `Core' functions to raise
`Not_found_s' instead of `Not_found'. `Hashtbl.find_exn' and
`Map.find_exn' now include the key in their error message.
• Changed `Core' and `Core_kernel' to export `int' comparison
rather
than polymorphic comparison.
• Removed the "robust" float comparison operators (`>.', `=.',
…)
from the default namespace.
• Replaced `sexp_*' types (`sexp_list', `sexp_option',
`sexp_opaque',
…) with preprocessor attributes (`[@sexp.list]',
`[@sexp.option]',
`[@sexp.opaque]', …).
• Changed `let%map' syntax from `let%map.Foo.Let_syntax' to
`let%map.Foo'.
• Added to `match%optional' support for specifying a path, so
you can
write `match%optional.Foo foo_option' rather than `let open
Foo.Optional_syntax in match%optional foo_option'.
• Improved `Base.Backtrace' so that it enables recording of
backtraces
in more situations, specifically when `OCAMLRUNPARAM' is
defined but
doesn't mention the backtrace flag, `b'.
• Added javascript support for `Zarith', `Bigint', `Bignum', and
`Bigdecimal'.
• Changed `Hashtbl.create''s default `size' from 128 to 0.
• Changed `Core_kernel.Command' so that all commands accept
double
dash flags: `--help', `--version', and `--build-info'.
New packages
╌╌╌╌╌╌╌╌╌╌╌╌
• async_udp (<https://github.com/janestreet/async_udp>): UDP
support
for Async.
• async_websocket
(<https://github.com/janestreet/async_websocket>): A
library that implements the websocket protocol on top of
Async.
• bonsai (<https://github.com/janestreet/bonsai>): A library for
building dynamic webapps, using Js_of_ocaml.
• postgres_async
(<https://github.com/janestreet/postgres_async>):
OCaml/async implementation of the postgres protocol (i.e.,
does not
use C-bindings to libpq).
• ppx_cold (<https://github.com/janestreet/ppx_cold>): Expands
`[@cold]' into `[@inline never][@specialise never][@local
never]'.
• ppx_pattern_bind
(<https://github.com/janestreet/ppx_pattern_bind>):
A ppx for writing fast incremental bind nodes in a pattern
match.
• ppx_python (<https://github.com/janestreet/ppx_python>):
`[@@deriving]' plugin to generate Python conversion functions.
• ppx_yojson_conv
(<https://github.com/janestreet/ppx_yojson_conv>):
`[@@deriving]' plugin to generate Yojson conversion functions.
• ppx_yojson_conv_lib
(<https://github.com/janestreet/ppx_yojson_conv_lib>): Runtime
lib
for `ppx_yojson_conv'.
• pythonlib (<https://github.com/janestreet/pythonlib>): A
library to
help writing wrappers around OCaml code for python.
• sexp_select (<https://github.com/janestreet/sexp_select>): A
library
to use CSS-style selectors to traverse sexp trees.
• timezone (<https://github.com/janestreet/timezone>): Time-zone
handling.
• toplevel_backend
(<https://github.com/janestreet/toplevel_backend>):
Shared backend for setting up toplevels.
• zarith_stubs_js
(<https://github.com/janestreet/zarith_stubs_js>):
Javascript stubs for the Zarith library.
Deprecations / Removals
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`Async_kernel':
• Deprecated monadic `ignore' functions in favor of `ignore_m'.
`Base':
• Deleted `Array.replace' and `replace_all' functions, which
have been
deprecated since before the last public release.
• Deprecated `Result.ok_unit'; use `Ok ()'.
• Removed the `Monad' and `Applicative' interfaces' `all_ignore'
function; it was previously deprecated and replaced by
`all_unit'.
• Removed `List.dedup', which has been deprecated since 2017-04.
• Removed `String' mutation functions, which have been
deprecated in
favor of `Bytes' since 2017-10.
• Deprecated `Array.truncate', `Obj_array.unsafe_truncate', and
`Uniform_array.unsafe_truncate'.
• Deprecated `Sys.argv', which has been superseded by
`get_argv',
which is a function, reflecting the fact that `argv' can
change (as
of OCaml 4.09).
`Core_kernel':
• Removed `Core_kernel.Std', which had been deprecated for a
year.
• Deprecated type `Command.Spec.param' in favor of
`Command.Param.t'.
• Removed `Hashtbl' functions that had been deprecated for
years.
• Removed `Float.to_string_round_trippable', which has been
deprecated
in favor of `to_string' since 2017-04.
• Deprecated `Fqueue' functions where one should use `Fdeque'
instead:
`bot', `bot_exn', and `enqueue_top'.
• Deleted `Bus.unsubscribes', which will be obviated by a
performance
improvement to `Bus.unsubscribe'.
`Timing_wheel':
• Removed the `alarm_upper_bound' function, which has been
deprecated
for 6 months, and superseded by `max_allowed_alarm_time'.
Moves
╌╌╌╌╌
`Core_kernel':
• Moved `Bounded_int_table' to a standalone library.
• Moved the `Pool' and `Tuple_type' modules to a standalone
library,
`Tuple_pool'.
`Async_unix':
• Moved `Unix.Fd.replace' into a `Private' submodule.
Changelog
╌╌╌╌╌╌╌╌╌
Please visit
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735>
opam2nix (v1)
═════════════
Archive: <https://discuss.ocaml.org/t/ann-opam2nix-v1/4741/1>
Tim Cuthbertson announced
─────────────────────────
Anouncing opam2nix (v1)
[opam2nix] generates [nix] expressions from the [opam] OCaml
package
repository. It works similarly to [bundix], [node2nix], etc:
You run an (impure) command to resolve all transitive dependency
versions using the current opam repository, generating a .nix
file
that locks down the exact package sources and versions. Then
this file
can be imported to provide `buildInputs' for building your ocaml
project in nix.
*What is nix and why would I care?* Well, that's a long story
but the
headline benefits of nix are:
• reproducible builds (if it builds for me, it builds for you)
• stateless (you don't set up switches and then install
packages, each
expression specifies everything it needs, and anything you
don't
have is fetched/built on demand)
• language agnostic (takes care of non-ocaml dependencies)
It's sadly not a shallow learning curve, but those benefits are
hard
to find elsewhere, so I obviously think it's worthwhile. So if
you use
nix (or would like to), please give it a try and provide
feedback. I'll (slowly) start working on upstreaming it into
nixpkgs.
[opam2nix] <https://github.com/timbertson/opam2nix>
[nix] <https://nixos.org/>
[opam] <https://opam.ocaml.org/>
[bundix] <https://github.com/nix-community/bundix>
[node2nix] <https://github.com/svanderburg/node2nix>
GitHub Actions for OCaml / opam now available
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/github-actions-for-ocaml-opam-now-available/4745/1>
Anil Madhavapeddy announced
───────────────────────────
I was in the [GitHub Actions] beta program and forward ported my
code
to the latest version that just went public. It's a pretty
simple way
to get your OCaml code tested on Linux, macOS and Windows,
without
requiring an external CI service. The action attempts to
provide a
homogenous interface across all three operating systems, so
invoking
'opam' from subsequent actions should "just work".
You can find it here:
• In the GitHub Marketplace at
<https://github.com/marketplace/actions/setup-ocaml>
• Source code on <https://github.com/avsm/setup-ocaml/>
• Hello World usage on
<https://github.com/avsm/hello-world-action-ocaml>
• Usage in ocaml-yaml:
•
<https://github.com/avsm/ocaml-yaml/blob/master/.github/workflows/test.yml>
• An [example ocaml-yaml run]
This should be considered fairly experimental as GH Actions is
so new.
If you do use it, then consider [updating this issue with your
usage].
It does not current supporting caching yet, but is pretty fast
to
bootstrap (~4minutes).
It also doesn't have any higher level purpose other than to set
up an
opam environment, since most of the additional functionality
such as
revdeps testing is planned for addition to the [ocurrent DSL].
Nevertheless, this GH feature will hopefully be useful for
smaller
projects without a lot of computational requirements. Let me
know how
it goes!
Windows is currently supported through @fdopen's excellent fork
that
uses Cygwin. As Windows support is being mainlined into opam
itself
at the moment, I'm hoping that we will gradually move over to
that.
That should eventually remove the need for two separate
opam-repositories, so I won't be adding any features that are
Linux or
macOS-specific and do not work on the Cygwin version.
[GitHub Actions] <https://github.com/actions>
[example ocaml-yaml run]
<https://github.com/avsm/ocaml-yaml/runs/314055554>
[updating this issue with your usage]
<https://github.com/avsm/setup-ocaml/issues/4>
[ocurrent DSL]
<https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/2>
OCurrent 0.1 (CI/CD pipeline eDSL)
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/1>
Thomas Leonard announced
────────────────────────
[OCurrent] 0.1 has just been released to opam-repository.
OCurrent is an OCaml eDSL intended for writing build/test/deploy
pipelines. It is being used as the engine for [ocaml-ci] and the
[docker-base-images] builder (used to build the OCaml Docker
images,
such as `ocurrent/opam:alpine-3.10-ocaml-4.08'). Other good uses
might
be building and redeploying a Docker service or a unikernel
whenever
its source repository changes. It can be run locally as a single
Unix
process.
An OCurrent pipeline is written as an OCaml program, but the
OCurrent
engine ensures that it is kept up-to-date by re-running stages
when
their inputs change. A web UI is available so you can view your
pipeline and see its current state.
OCurrent can statically analyse the pipelines before they have
run,
allowing it to run steps in parallel automatically and to
display the
whole pipeline. It does this using a light-weight alternative to
arrows, which doesn't require programming in an awkward
point-free
style. See [CI/CD Pipelines: Monad, Arrow or Dart?] for more
about
that.
The basic functionality can be extended using "plugins" (just
normal
OCaml libraries). Plugins are available for interacting with
Docker,
Git, GitHub and Slack. These are in separate packages
(e.g. `current_github') to avoid having the base package pull in
too
many dependencies).
There is also an optional Cap'n Proto RPC interface, in the
`current_rpc' opam package. This is used, for example, by
[citty] to
provide a TTY interface to ocaml-ci.
[The OCurrent wiki] contains examples, and documentation on the
various plugins.
Here's an example pipeline (from the base image builder):
<https://roscidus.com/blog/images/cicd/docker-base-images-thumb.png>
[OCurrent] <https://github.com/ocurrent/ocurrent>
[ocaml-ci] <https://github.com/ocurrent/ocaml-ci/>
[docker-base-images]
<https://github.com/ocurrent/docker-base-images>
[CI/CD Pipelines: Monad, Arrow or Dart?]
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
[citty] <https://github.com/ocurrent/citty>
[The OCurrent wiki] <https://github.com/ocurrent/ocurrent/wiki>
Anil Madhavapeddy then added
────────────────────────────
For those curious about the relation to the existing CI used in
opam-repository, then it is no coincidence that @talex5 is the
author
of both :-)
This DSL is the next iteration of the [datakit-ci], but
specialised to
be faster and simpler for extending with OCaml and more complex
workflows that our OCaml Platform tools need these days (like
ocamlformat linting, or dune expect promotion, or odoc
cross-referenced doc generation). We are planning a smooth
migration
next year over to the new system, but wanted to release this
early to
show you some of the pieces going into this new iteration. I am
particularly excited about the new tty-based interface that
saves an
awful lot of clicking around on web UIs for CI results…
[datakit-ci] <https://github.com/moby/datakit>
New pages for OCaml API
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/new-pages-for-ocaml-api/4720/13>
Continuing this thread, sanette announced
─────────────────────────────────────────
I have uploaded a new version (same link
<https://sanette.github.io/ocaml-api/>)
• background color for links in the TOC @Maelan
• more indentation for value descriptions @Maelan, @grayswandyr
• word wrapping long `<pre>' codes @grayswandyr
• type table: remove `(*' and `*)', give more space to code wrt
comments, diminish comment's color @grayswandyr
searching is not ready yet… please wait suggestions for dark
theme
welcome
sanette later added
───────────────────
I have just uploaded a new version with a basic search engine.
• for each page, you can search values/modules
• in the general index page, the search includes also the
descriptions
• search results are ranked by relevance
the downside is that each page now comes with an index of about
570Kb
in the form of an index.js file. I'm kind of hoping that the
browser
will cache this, but I'm not sure. It would be maybe better to
only
load the index file on demand.
Irmin 2.0.0 release
═══════════════════
Archive:
<https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/1>
Thomas Gazagnaire announced
───────────────────────────
On behalf of the Irmin development team, I am very happy to
announce
the release of Irmin 2.0.0, a major release of the Git-like
distributed branching and storage substrate that underpins
[MirageOS]. We began the release process for all the components
that
make up Irmin [back in May 2019], and there have been close to
1000
commits since Irmin 1.4.0 released back in June 2018. To
celebrate
this milestone, we have a new logo and opened a dedicated
website:
[irmin.org].
More details here:
<https://tarides.com/blog/2019-11-21-irmin-v2>
[MirageOS] <https://mirage.io/>
[back in May 2019]
<https://tarides.com/blog/2019-05-13-on-the-road-to-irmin-v2>
[irmin.org] <https://irmin.org/>
Tail cascade: a new indentation style for some OCaml constructs
═══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/tail-cascade-a-new-indentation-style-for-some-ocaml-constructs/4736/1>
gasche announced
────────────────
I recently decided to change my indentation style for certain
OCaml
constructs in a way that I'm going to describe below. I just
coined a
name for this approach, "tail cascade". I'm creating this topic
to
convince everyone that this is a cool idea you should adopt as
well. Or at least tolerate it when you review other people's
code.
Problem
╌╌╌╌╌╌╌
Programs that heavily use `match' often see a shift to the right
due
to nested indentation.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ match f y with
│ | Some z ->
│ ...
└────
Another problem with this style is that it suffers from the
"dangling
bar" issue: if you try to add a new case for one of the exterior
`match', it is parsed as belonging to the innermost `match'.
People
have been recommending (rightly) to use `begin match .. end' for
all
nested match constructs to avoid this issue.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ begin match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ begin match f y with
│ | None -> ...
│ | Some z ->
│ ...
│ end
│ (* now this is safe *)
│ | FooBlah -> ...
│ end
└────
But still the unpleasant shift to the right remains.
Proposal: cascading tail case
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We should in general use `begin match .. end' for nested
matches. But
the "cascading tail case" proposal is to *not* do it for the
*last*
case of the pattern-matching, and instead *de-indent* (dedent)
this
last case – tail case.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ match f y with
│ | None -> ...
│ | Some z ->
│ ...
└────
Note that with this indentation style, the "dangling match"
problem is
also avoided: unlike with the original, non `end'-protected
program,
the indentation makes it immediately obvious that any further
case
will be attached to the innermost match, and not any of the
exterior
ones.
A program using this "cascading tail" approach should always use
`begin match .. end' for nested matches, except for a nested
match
returned within the last branch of an outer match, which can
(optionally) be dedented instead.
The choice to dedent the last case corresponds to encouraging a
sequential reading of the program, where the other cases are
"auxiliary cases" checked first and dispatched quickly, and the
last
case is the "main part" where the "rest" of the logic of the
program
lies. This pattern is typical of nested pattern-matching on the
`option' or `result' type for example:
┌────
│ match foo x with
│ | Error err ->
│ fail_foo_error err
│ | Ok y ->
│ match bar y with
│ | Error err ->
│ fail_bar_error err
│ | Ok () ->
│ ...
└────
Remark: it is *not* always the case that the `Error' constructor
is
the auxiliary case, and the `Ok' constructor is the main case;
sometimes we implement fallback logic like "if `foo' work then
we are
good, but otherwise we have to do this and that", and the error
case
is the most salient (and longer) part of the program logic. I
would
recommend being mindful, when you write code, of whether there
is a
most convincing way to "sequentialize" it (distinguish auxiliary
and
main/tail case), and avoid using cascading tails when there is
no
clear sequentialization choice.
Remark: some cases of tail cascades can be linearized by using a
good
definition of "bind" and a monadic style. This tends to be very
limited however: it fixes one of the constructors to always be
the
"tail" constructor (always `Some', always `Ok'), and it only
works
when the handling of the other constructors is very homogeneous
(typically: return directly). In real code, many situations
occur
where the monadic style doesn't fit the problem, but tail
cascade does
help writing a readable program.
Generalization: tail cascade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
While I have never seen cascading tail cases in real-world OCaml
code
before (I'm happy to be given pointers; I think that the idea is
not
new, but I'm not aware of previous attempts to give it a catchy
name
and spread the cascade love), this is in fact a new (to me)
instance
of a common technique that is used for other OCaml constructs:
┌────
│ if foo x then ...
│ else if bar x then ...
│ else ... (* this `tail else` was dedented *)
│
│ let x = foo in
│ let y = bar in (* this `tail let` was dedented *)
│ ... (* and the rest as well *)
│
│ bind foo @@ fun x ->
│ bind bar @@ fun y -> (* this "tail function body" was dedented
*)
│ ... (* and the rest as well *)
└────
I would call "tail cascade" (or maybe: "cascading tail") the
idea of
dedenting the "rest" of an OCaml expression (compared to a
strict
tree-nesting-based approach) when it morally describes the
"rest" of
the expression. I use the name "tail" because those expressions
are
almost always in tail-position in the sense of tail-calls.
This general approach legitimizes some styles that I have seen,
and
sometimes used, in the wild, while at the same time considering
that I
may have been doing something improper, for example:
┌────
│ if foo then blah else
│ ... (* dedented *)
│
│
│ Fun.protect
│ ~finally:(...)
│ @@ fun () ->
│ ... (* dedented *)
│
│
│ try simple_approach with exn ->
│ ... (* dedented *)
│
│
│ 1 +
│ 2 + (* dedented *)
│ ... (* dedented *)
└────
Remark: after a `then' or `else', many people share the
reasonable
view that any expression containing imperative constructs (`foo;
bar')
should be enclosed in a `begin .. end' block to avoid
surprising-precedence issue. Just as for nested `match', this
recommendation should be lifted for "tail else" constructs.
Remark: The last example is a case where the dedented
expressions are
*not* in tail-position from a runtime-evaluation point of view.
I am
not sure as whether the two notions should be made to coincide
more
strongly, but in any case I'm not fond of the style in this
particular
example, I prefer to move the infix operator to the beginning of
the
next line instead, following a different style and
justification.
The possibility this "cascading tail" style today crucially
relies on
the nesting properties of open-ended syntactic constructs,
notably
`let' (commonly cascaded), and now `match' and `if
... else'. Proposals to transition to a syntax where `match' and
`else' are forced to take a closing marker are incompatible with
the
cascading style. I have not made my mind on whether this should
be
considered a blocker for those proposals, but at least it shows
that
having the open-ended form available has value for certain
programs.
Louis Gesbert then said
───────────────────────
@gasche I prototyped a dedicated option in `ocp-indent', if
you're
interested in trying it out :)
┌────
│ opam pin
git+https://github.com/OCamlPro/ocp-indent#match-tail-cascade
│ echo "match_tail_cascade=true" >> ~/.ocp-indent
└────
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <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/>
[-- Attachment #1.1.2: Type: text/html, Size: 50844 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-03 15:43 Alan Schmitt
0 siblings, 0 replies; 7+ messages in thread
From: Alan Schmitt @ 2019-12-03 15:43 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 22620 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 26
to
December 03, 2019.
Table of Contents
─────────────────
Irmin 2.0.0 release
How viable is delivering binaries linked to Cygwin to Windows
customers?
Dune 2.0.0
Advanced C binding using ocaml-ctypes and dune
Upcoming breaking change in Base/Core v0.14
CI/CD Pipelines: Monad, Arrow or Dart?
Use of functors to approximate F# statically resolved type
parameters
Old CWN
Irmin 2.0.0 release
═══════════════════
Archive:
<https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/5>
Continuing this thread, samoht announced
────────────────────────────────────────
And there is now a follow-up blog post, explaining how to use
the new
GraphQL API available in Irmin2:
<https://tarides.com/blog/2019-11-27-introducing-irmin-graphql>.
How viable is delivering binaries linked to Cygwin to Windows
customers?
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/how-viable-is-delivering-binaries-linked-to-cygwin-to-windows-customers/4775>
mbacarella asked
────────────────
I’m in the early stages of planning a deliverable binary product
that
will run on Linux, Mac and Windows.
My brief sniff of the air around the OCaml ecosystem says I
should
expect to target Cygwin to get Windows going (although there’s
impressive work to get native Windows stuff done that can become
the
preferred approach in a few years).
My experience using Cygwin as an operating environment is that
it’s
pretty darn sluggish compared to Linux on the same computer.
Why is this? There’s an anecdote that says Cygwin can only fork
at
about 30-50x a second on Windows, due to how it has to adapt it
to
work within Windows’ task spawning model. (For contrast, Linux
can
achieve thousands of forks per second if you play around with
it).
I understand from another product developer that when they build
binaries to deliver to Windows/Cygwin, they actually
cross-compile on
Linux because of how slowly the toolchain runs on Cygwin.
That sounds like bad news if you want to do UNIXy things, but
for a
single standalone application this might not be so bad? I assume
if I
ship a deliverable to Windows/Cygwin, the end user may enjoy
good
performance, so long as I’m not spawning tons of processes or
relying
on fork for multi-programming. Is this a safe assumptions?
Any other gotchas when it comes to OCaml on Cygwin w.r.t.
performance?
The app pretty much has real-time gaming requirements (though
it’s not
a game so can side-step worrying about access to GPUs and
what-not). Stated another way, although my application will
depend on
the POSIX layer offered by Cygwin, I expect it not to crunch
POSIX
related stuff in the main loop.
How has your experience gone?
John Whitington replied
───────────────────────
I have been shipping commercial binaries for Linux (32 and 64
bit),
Windows (32 and 64bit) and OS X for years. For example:
<https://github.com/coherentgraphics/cpdf-binaries>
And even static or shared libraries in binary form:
<https://github.com/coherentgraphics/cpdflib-binary>
On OS X, you need to use MACOSX_DEPLOYMENT_TARGET or similar to
make
sure your builds will run on older systems. And, in fact, you
need to
use MACOSX_DEPLOYMENT_TARGET when asking OPAM to compile the
OCaml
compiler itself. And, you will need to deal with codesigning and
notarization. But it’s all doable.
For linux, you may need to build under older linux versions, to
make
sure that the glibc in use is old enough. This is not an
ocaml-specific problem. I have a 64 bit and 32 bit VM with
old-ish
glibc versions for this purpose.
Under Windows, there are no such backward-compatibility
problems. I
use the new OCaml for windows system, which comes with OPAM, and
is
mingw-based. No cygwin remains in the final binary.
For more obscure systems (AIX, HPUX, Sparc etc) customers
compile from
source (with help from me). Not once in more than ten years has
anyone
cared that it was written in OCaml.
dbuenzli also replied
─────────────────────
remember that on the Windows native port, the Unix module
distributed
with OCaml is your POSIX compatibility layer. There are a few
entry
points to avoid though, the list is at the bottom of [this
page].
[this page]
<https://caml.inria.fr/pub/docs/manual-ocaml/libunix.html>
nojb also replied
─────────────────
At LexiFi our main application is developed and shipped on
Windows. We
use the msvc port of OCaml. This means that you need Cygwin to
develop, but the resulting application is fully native and does
not
depend on the Cygwin DLL. As @dbuenzli mentioned, the Unix
module *is*
the POSIX compatibility layer.
Compilation speed is slower on Windows because process creation
is
slower on Windows as a general rule, but it is manageable (our
application has around 2000 modules + Js_of_ocaml + C bindings +
C#
component).
We don’t have any issues with runtime performance. The `Unix'
library
mentioned above implements Windows support directly without
going
through any compatibility layer and is quite efficient.
BikalGurung also replied
────────────────────────
There is an editor being built in ocaml/reasonml which currently
targets windows, linux and macos -
<https://github.com/onivim/oni2>. However, the binary is native
windows rather than cygwin derivative. So if you don’t have to
use
cygwin dependencies then native windows binary could be the way
to go.
Also esy - <https://github.com/esy/esy> makes developing
ocaml/reasonml on windows viable.
keleshev also replied
─────────────────────
*TLDR*: Install the [Mingw port of OCaml 4], freely use most
opam
libraries, and compile to native Windows binaries, without
licensing
issues.
I recommend you read the “Release notes for Windows”:
<https://github.com/ocaml/ocaml/blob/trunk/README.win32.adoc>
To summarise, there are three Windows ports:
• Native Microsoft port,
• Native Mingw port,
• Cygwin port.
All three require Cygwin for development purposes. I recommend
using
the Native Mingw, as:
• it *doesn’t* require Visual Studio (it uses a mingw fork of
GCC that
“cross-compiles” native Windows executables),
• it *doesn’t* rely on the dreaded cygwin.dll
• it has good opam support with opam-repository-mingw:
<https://github.com/fdopen/opam-repository-mingw>
• it has a convenient installer:
<https://fdopen.github.io/opam-repository-mingw/> 5.
To contrast, Native Microsoft requires Visual Studio, and
doesn’t have
opam. You can still vendor pure OCaml packages, but as soon as
you
want to use some C bindings you’re in trouble, because of the
“minor”
differences between Visual C and GCC. And everything assumes GCC
nowadays.
Cygwin port is the one I don’t have experience with, but
re-reading
the “Release notes for Windows” above it strikes me that it
mentions
that Cygwin was re-licensed from GPL to LGPL with static linking
exception. So it looks like the Cygwin port could be viable for
commercial use, but I never tried to statically linked
`cygwin.dll',
and I’m not sure what are the benefits of Cygwin port over the
Mingw
port.
[Mingw port of OCaml 4]
<https://fdopen.github.io/opam-repository-mingw/>
dmbaturin also replied
──────────────────────
With [soupault 4], I decided to ship prebuilt binaries for all
platforms including Windows. Mostly to see if I can, all its
users I
know of are on UNIX-like systems and know how to build from
source,
but that’s beside the point. :wink:
I can confirm everything @keleshev says: fdopen’s package just
works,
opam works exactly like it does on UNIX, pure OCaml libraries
are
trivial to install, and the binaries don’t depend on cygwin.
Note
that “opam switch create” also just works, you can install
either
MinGW or MSVC compiler versions as opam switches. I only ever
start
the Windows VM to make release builds, and the workflow is
exactly the
same as on Linux where I’m actually writing code.
My only obstacle on that path was that FileUtils lost its
Windows
compatibility, but I wanted to use it, so I worked with
@gildor478 to
make it cross-platform again. Uncovered a bug in the
implementation of
Unix.utimes in the process, but it’s hardly a commonly used
function.
You can also setup AppVeyor builds. It’s not as simple as I wish
it
would be, but there are projects doing it that you can steal the
setup
from.
There’s also opam-cross-windows, but it’s very incomplete and
needs
work to be practical. There are no big obstacles, it just needs
work. While files in opam-repository-mingw are normally
identical to
the default opam repository, the cross one needs small
adjustments in
every package to specify the toolchain to use, so the required
work is
mostly a lot of trivial but manual actions. I hope eventually it
reaches parity with fdopen’s one and we’ll be able to easily
build for
Windows without ever touching Windows.
As of static Linux builds, @JohnWhitington’s approach can work,
but
there’s a better option if you don’t need anything from glibc
specifically and don’t link against any C libs: build statically
with
musl. There’s a `+musl+static+flambda' compiler flavour. You
need musl
and gcc-musl to install it, but after that, just build with
`-ccopt
-static' flag and you get a binary that doesn’t depend on
anything.
[soupault 4] <https://soupault.neocities.org/>
Dune 2.0.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>
rgrinberg announced
───────────────────
On behalf of the dune team, I’m delighted to announce the
release of
dune 2.0. This release is the culmination of 4 months of hard
work by
the dune team and contains new features, bug fixes, and
performance
improvements . Here’s a selection of new features that I
personally
find interesting:
• New boostrap procedure that works in low memory environments
• (`deprecated_library_name' ..) stanza to properly deprecate
old
library names
• (`foreign_library' ..) stanza to define C/C++ libraries.
• C stubs directly in OCaml executables
Refer to the change log for an exhaustive list.
We strive for a good out of the box experience that requires no
configuration, so we’ve also tweaked a few defaults. In
particular, `$
dune build' will now build `@all' instead of `@install', and
ocamlformat rules are setup by default.
Lastly, dune 2.0 sheds all the legacy related to jbuilder and
will no
longer build jbuilder projects. This change is necessary to ease
maintenance and make it easier to add new features down the
line. There are a few other minor breaking changes. Refer to the
change log for the full list. We apologize in advance for any
convenience this might cause.
[Changelog]
[Changelog] <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>
Advanced C binding using ocaml-ctypes and dune
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/advanced-c-binding-using-ocaml-ctypes-and-dune/4805>
toots announced
───────────────
I worked on a socket.h binding last summer and had a great
experience
integrating ocaml-ctypes with dune, I thought that might be of
interest to other developers so I wrote about it:
<https://medium.com/@romain.beauxis/advanced-c-binding-using-ocaml-ctypes-and-dune-cc3f4cbab302>
rgrinberg replied
─────────────────
This is a good article. I encourage anyone who writes C bindings
with
ctypes to study it carefully.
A little bit of advice to shorten your dune files:
┌────
│ (deps (:gen ./gen_constants_c.exe))
└────
This line isn’t necessary. Dune is smart enough to know that
running a
binary in a rule incurs a dependency on it.
dune has a truly amazing [support for cross-compiling],
which we do not cover here, but, unfortunately, its
primitives for building and executing binaries do not yet
cover this use case.
Indeed, we don’t have any primitives for running binaries on the
target platform. Perhaps we should add some. However, we do in
fact
have some features in dune to solve this concrete cross
compilation
problem. As far as I understand, the goal is to obtain some
compile
time values such as #define constants and field offsets for the
target
platform. This does not in fact require to run anything on the
cross
compilation target. In configurator, we have a primitive
`C_define.import' to extract this information. The end result is
that
these configurator scripts are completely compatible with cross
compilation.
Perhaps this could be generalized to work with ctypes generators
as
well?
Funny bit of trivia: The hack in configurator required to do
this is
in fact something I extracted from ctypes itself. The original
author
is [whitequark], who in turn wrote it to make ctypes itself
amendable
to cross compilation.
[support for cross-compiling]
<https://dune.readthedocs.io/en/latest/cross-compilation.html>
[whitequark] <https://github.com/whitequark>
emillon then added
──────────────────
This does not in fact require to run anything on the cross
compilation target. In configurator, we have a primitive
`C_define.import' to extract this information. The end
result is that these configurator scripts are completely
compatible with cross compilation.
If anybody wants to know more about this bit, I wrote an article
about
this last year:
<https://dune.build/blog/configurator-constants/>
Upcoming breaking change in Base/Core v0.14
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/upcoming-breaking-change-in-base-core-v0-14/4806>
bcc32 announced
───────────────
We’re changing functions in Base that used to use the
polymorphic
variant type `[ `Fst of 'a | `Snd of 'b ]' to use `('a, 'b)
Either.t'
instead. As well as enabling the use of all of the functions in
the
Either module, this makes the functions consistent with other
functions that already use `Either.t', (currently just
`Set.symmetric_diff')
The following functions’ types will change:
• `Result.ok_fst'
• `List.partition_map'
• `Map.partition_map', `Map.partition_mapi'
• `Hashtbl.partition_map', `Hashtbl.partition_mapi'
The type of List.partition3_map will not change:
┌────
│ val partition3_map
│ : 'a t
│ -> f:('a -> [ `Fst of 'b | `Snd of 'c | `Trd of 'd ])
│ -> 'b t * 'c t * 'd t
└────
We don’t have a generic ternary variant, and it doesn’t seem
worth it
to mint one just for this purpose.
Since this change is pretty straightforward, we expect that a
simple
find/replace will be sufficient to update any affected call
sites.
CI/CD Pipelines: Monad, Arrow or Dart?
══════════════════════════════════════
Archive:
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
Thomas Leonard announced
────────────────────────
In this post I describe three approaches to building a language
for
writing CI/CD pipelines. My first attempt used a monad, but this
prevented static analysis of the pipelines. I then tried using
an
arrow, but found the syntax very difficult to use. Finally, I
ended up
using a light-weight alternative to arrows that I will refer to
here
as a dart (I don’t know if this has a name already). This allows
for
static analysis like an arrow, but has a syntax even simpler
than a
monad.
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
Use of functors to approximate F# statically resolved type
parameters
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/use-of-functors-to-approximate-f-statically-resolved-type-parameters/4782>
cmxa asked
──────────
I am learning OCaml coming from F#. In F#, to calculate the
average of
an array whose element type supports addition and division, one
can
write
┌────
│ let inline average (arr: 'a[]) : 'a
│ when ^a : (static member DivideByInt : ^a * int -> ^a)
│ and ^a : (static member (+) : ^a * ^a -> ^a)
│ and ^a : (static member Zero : ^a)
│ =
│ if Array.length arr = 0 then
(LanguagePrimitives.GenericZero) else
│ LanguagePrimitives.DivideByInt (Array.fold (+)
(LanguagePrimitives.GenericZero) arr) (Array.length arr)
└────
My understanding is that in OCaml, one would have a module type
like
so:
┌────
│ module type Averagable = sig
│ type 'a t
│
│ val divide_by_int : 'a -> int -> 'a
│ val plus : 'a -> 'a -> 'a
│ val zero : 'a
│ end
└────
My question is how the corresponding function would be written:
┌────
│ let average arr =
│ ???
└────
smolkaj replied
───────────────
First, `Averagable' should look like this:
┌────
│ module type Averagable = sig
│ type t
│ val divide_by_int : t -> int -> t
│ val plus : t -> t -> t
│ val zero : t
│ end
└────
Then average will look something like this:
┌────
│ let average (type t) (module A : Averagable with type t = t)
(arr : t array) : t =
│ Array.fold ~init:A.zero ~f:A.plus arr
└────
(The code above uses Jane Street’s Base/Core library.)
ivg then added
──────────────
While @smolkaj’s answer is a correct and direct implementation
of your
F# code, it might be nicer if your code can interplay with
existing
abstractions in the OCaml infrastructure. For example,
┌────
│ open Base
│
│ let average (type a) (module T : Floatable.S with type t = a)
xs =
│ Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
│ Float.of_int (Array.length xs)
└────
and now it could be used with any existing numeric data in
Base/Core
┌────
│ average (module Int) [|1;2;3;4|];;
│ - : Base.Float.t = 2.5
└────
and even adapted to non-numbers,
┌────
│ let average_length = average (module struct
│ include String
│ let to_float x = Float.of_int (String.length x)
│ let of_float _ = assert false
│ end)
└────
The latter example shows that we requested more interface than
need, a
cost that we have to pay for using an existing definition. In
cases
when it matters, you can specify the specific interface, e.g.,
┌────
│ module type Floatable = sig
│ type t
│ val to_float : t -> float
│ end
│
│ let average (type a) (module T : Floatable with type t = a) xs
=
│ Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
│ Float.of_int (Array.length xs)
└────
But we reached the point where using first class modules is
totally
unnecessary. Our interface has only one function, so the
following
definition of average, is much more natural
┌────
│ let average xs ~f =
│ Array.fold ~init:0. ~f:(fun s x -> s +. f x) xs /.
│ Float.of_int (Array.length xs)
└────
it has type `'a array -> f:('a -> float) -> float' and computes
an
average of `f x_i' for all elements in the array.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <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/>
[-- Attachment #1.1.2: Type: text/html, Size: 41191 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-10 8:21 Alan Schmitt
0 siblings, 0 replies; 7+ messages in thread
From: Alan Schmitt @ 2019-12-10 8:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 4145 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 03
to 10,
2019.
Table of Contents
─────────────────
Internships at Nomadic-labs
Interesting OCaml Articles
Next OUPS meetup December 18th 2019
Old CWN
Internships at Nomadic-labs
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/internship-at-nomadic-labs/4819>
Julien Tesson announced
───────────────────────
Nomadic Labs is currently looking for students with an interest
in
functional programming for internships that would take place in
our
offices in Paris or Grenoble.
We have a catalog of internships topics available at [1] The
internships topics are mainly addressed to master student but
other
well motivated application will be considered.
A first selection phase on received résumé will occur on
december
15th. Please contact us at contact@nomadic-labs.com by
specifying
which topics in the catalog you're interested in.
[1]: <https://nomadic-labs.com/download/internship_catalog.pdf>
Please, feel free to redistribute widely.
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/57>
james woodyatt announced
────────────────────────
Found on *Lobste.rs*: Mark Karpov writes yet another [Haskell
vs. OCaml] for old time's sake. I found it worth a read and a
mention
here.
p.s. He spends a bit of time in the intro lamenting the lack of
a
conventional Unicode string library for OCaml, and I feel that
pain
acutely, especially since I'm the author of an *unconventional*
one,
i.e. the [Ucs_text] module in my [Orsetto] project.
[Haskell vs. OCaml]
<https://markkarpov.com/post/haskell-vs-ocaml.html>
[Ucs_text]
<https://bitbucket.org/jhw/orsetto/src/default/src/ucs/ucs_text.mli>
[Orsetto] <https://bitbucket.org/jhw/orsetto>
Next OUPS meetup December 18th 2019
═══════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2019-12/msg00009.html>
Bruno Bernardo announced
────────────────────────
The OUPS meetup is back. The next one will take place on
Wednesday,
December 18, 7pm at IRILL on the Jussieu campus. As usual, we
will
have a few talks, followed by pizzas and drinks.
The talks will be the following:
• Nathan Rebours, The future of OCaml-PPX
• Guillaume Claret, coq-of-ocaml
(<https://clarus.github.io/coq-of-ocaml/>)
And possibly a third talk. Contact us if you want to present
something, especially if you have a small project you want to
show in
10-15min.
To register, or for more information, go here:
<https://www.meetup.com/ocaml-paris/events/267019458>
*Registration is required! Access is not guaranteed after 7pm if
you're not registered.* (It also helps us to order the right
amount of
food.)
Access map:
IRILL - Université Pierre et Marie Curie (Paris VI)
Barre 15-16 1er étage
4 Place Jussieu
75005 Paris
<https://www.irill.org/pages/access.html>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <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/>
[-- Attachment #1.1.2: Type: text/html, Size: 15372 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, back to index
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-03 7:35 [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Alan Schmitt
2019-10-15 7:28 Alan Schmitt
2019-11-05 6:55 Alan Schmitt
2019-11-12 13:21 Alan Schmitt
2019-11-26 8:33 Alan Schmitt
2019-12-03 15:43 Alan Schmitt
2019-12-10 8:21 Alan Schmitt
caml-list - the Caml user's mailing list
Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list
AGPL code for this site: git clone https://public-inbox.org/ public-inbox