OCaml Weekly News

Is there any library to easily draw shapes (circle, rectangles, etc.) and rotate or scale them, and that also supports some alpha layer.

I know Graphics, but it does not look like you can rotate/scale/alpha easily shapes. I know Cairo but it depends on lablgtk to draw things on the screen and I don't need any widgets and I'd rather avoid dependencies to gtk.

For context I'm trying to port elm-playgound which allows to super easily code pictures, animations, or games (see https://package.elm-lang.org/packages/evancz/elm-playground/latest/ for its API). I am almost done porting it in a Web context thanks to js_of_ocaml, ocaml-vdom, and the SVG support in a browser, but I'd like now to port it in a native context.

I'm using the ocaml-cairo in a project, and it works relatively well. The library is also very nicely documented (there's an ocaml translation of the cairo tutorial, and various examples). Note that it corresponds to the cairo2 package in opam, which does not depend on lablgtk! (the downside being, I think, that the API provided by the cairo ( C) library is very imperative and can be a bit tricky to use at times).

I also know of the vg library for vector graphics, which has the virtue of being pure ocaml code. It is also very well documented. I suspect that it has a smaller feature set and number of supported backends than Cairo, but has a nicer API. Actually, it seems that you can use Cairo as a backend for Vg (https://erratique.ch/software/vg/doc/Vgr_cairo/index.html), which might give you the best of both worlds, in the case where you want to use Vg with a backend only supported by Cairo.

You an use e.g. Cairo.Image.create_for_data32 to create a Cairo RGBA surface from a bigarray (that can be then shared with Sdl or whatever other lib for displaying).

Oh you're right. I just found this example to transfer pictures from cairo to graphics: https://github.com/Chris00/ocaml-cairo/blob/master/examples/graphics_demo.ml

Oh, and I should note that I know of a third option: https://github.com/let-def/wall

It also has a nice vector-graphics API, and can render to Tsdl (see the example). (downside: it's maybe a bit less mature and less documented than the other two, but seems to correspond to what you're looking for.)

You can scale and rotate with SDL2 and it's bindings. Use the function Render.copyEx to copy a sprite on screen. Use the angle parameter to rotate and use rectangles of different width and height to scale. SDL2 doesn't permit to draw much shapes though, only rectangles by default, because it's made for gamedev, but you can use the SDL2_gfx lib in addition with SDL2, with its template bindings OCamlSDL2_Gfx.

SFML and its bindings ocaml-sfml allow more shapes drawing than SDL2.

You will probably be able to do everything you want with it, any shapes, rotate, scale, translate and more! Have a look at its api-doc, and in particular the SFShape module.

(Also please notice that SDL and SDL2 are 2 different libs, that don’t share any code, and have 2 different licenses, and with different implementations, SDL 1.2 uses software render, and SDL2 uses OpenGL inside.)

GuaCaml is a simple extension to the Standard OCaml Library (Stdlib).

https://gitlab.com/boreal-ldd/guacaml

I have the pleasure to announce the to announce the first opam release of Snowflake : a Generic Symbolic Dynamic Programming framework interfacing WAP, RBTF and MLBDD.

Complex systems (either physical or logical) are usually structured and sparse, that is, they are build from individual components linked together, and any component is only linked to a rather small number of other components with respects to the size of the global system.

RBTF exploits this structure, by over-approximating the relations between components as a tree (called decomposition tree in the graph literature) each node of this tree being a set of components of the initial systems. Then, starting from leaves, each sub-system is solved and the solutions are projected as a new constraints on their parent node, this process is iterated until all sub-systems are solved. This step allows to condensate all constraints into a single sub-system and check their satisfiability. We call this step the Forward Reduction Process (FRP).

Finally, we can propagate all the constraints back into their initial sub-system by performing those same projection in the reverse direction. That is, each sub-system update its set of solution given the information from its parent then send the information to its children sub-systems (possibly none, if its a leaf). We call this step the Backward Propagation Process (BPP).

https://gitlab.com/boreal-ldd/snowflake

I was looking for common approaches and best practises regarding to CLI argument passing and configuration files. I couldn't find much after googling so here is my questions:

1. I am getting arguments with cmdliner library and passing those arguments through functions. And sometimes I have to pass these arguments through multiple functions. I am not sure if that's the correct way of doing it. Let's say I have verbose flag defined and I have logs in various modules. So how can I receive this flag whenever needed? Could you please share any resources regarding to saving arguments and accessing them from different modules?
2. Is there a configuration file concept in OCaml? Files such as .yaml and .json

For the specific case of logging, my advice is to use the Logs library or – failing that – to just copy the approach that it takes verbatim. Logs looks after some global mutable state that contains the current logging level of the program, so you don't have to bother with propagating this information throughout your program. When I'm reading OCaml code, I'm not concerned with whether any particular function might emit log lines, so I don't need this to be made painfully obvious at each call-site. If you do use Logs, it comes pre-packaged with Cmdliner specifications for setting the logging level in the logs.cli package (example here).

Generally, there are several options for propagating state throughout an OCaml program. In roughly decreasing order of explicitness:

• pass all params explicitly to the functions that need them, precisely as you're doing right now.
• pack params into a "context" record (or object) that is passed explicitly where it's needed. (c.f. Dune's Context and Super_context.)
• pack params into a "context" module that is then used to instantiate functors elsewhere in your program. (c.f. Ppxlib.Ast_builder as a way of propagating a ~loc flag everywhere.)
• use global mutable state, as in Logs.

I've seen all four of these used sensibly in OCaml programs; the best one will depend on your particular application requirements / how much you care about tracking which part of the program use which arguments.

Regarding your second point, AFAIK there's no generic library for managing config files in OCaml (i.e. what Cosmiconfig provides for NPM). Every OCaml library that I've seen that uses one tends to roll their own logic for it. You could of course use Yojson or OCaml-Yaml to read a file in one of those formats, but you'll end up managing the details yourself. The lightweight approach is to use environment variables, since Cmdliner will handle that boilerplate for you; managing config files is a pain, particularly w.r.t. things like respecting XDG_CONFIG and it's analogues on Windows.

Re: configuration files, there are a few libraries in OPAM:

• http://opam.ocaml.org/packages/config-file/
• http://opam.ocaml.org/packages/ocplib-config/
• http://opam.ocaml.org/packages/ez_config/

If you want to use globals with cmdliner, you might find it convenient to use some code such as:

(** Extension of Cmdliner supporting lighter-weight option definition *)
module Cmdliner : sig
  include module type of Cmdliner

  val mk : default:'a -> 'a Term.t -> 'a ref
  (** [mk ~default term] is a ref which, after [parse] is called, contains
      the value of the command line option specified by [term]. *)

  val parse : Term.info -> (unit -> unit Term.ret) -> unit
  (** [parse info validate] parses the command line according to the options
      declared by calls to [mk], using manual and version [info], and
      calling [validate] to check usage constraints not expressible in the
      [Term] language. *)
end = struct
  include Cmdliner

  (** existential package of a Term and a setter for a ref to receive the
      parsed value *)
  type arg = Arg : 'a Term.t * ('a -> unit) -> arg

  (** convert a list of arg packages to a term for the tuple of all the arg
      terms, and apply it to a function that sets all the receiver refs *)
  let tuple args =
    let pair (Arg (trm_x, set_x)) (Arg (trm_y, set_y)) =
      let trm_xy = Term.(const (fun a b -> (a, b)) $ trm_x $ trm_y) in
      let set_xy (a, b) = set_x a ; set_y b in
      Arg (trm_xy, set_xy)
    in
    let init = Arg (Term.const (), fun () -> ()) in
    let (Arg (trm, set)) = List.fold_right ~f:pair args ~init in
    Term.app (Term.const set) trm

  let args : arg list ref = ref []

  let mk ~default arg =
    let var = ref default in
    let set x = var := x in
    args := Arg (arg, set) :: !args ;
    var

  let parse info validate =
    match Term.eval (Term.(ret (const validate $ tuple !args)), info) with
    | `Ok () -> ()
    | `Error _ -> Caml.exit 1
    | `Help | `Version -> Caml.exit 0
end

Welcome to the October 2020 multicore OCaml report, compiled by @shakthimaan, @kayceesrk and of course myself. The previous monthly updates are also available for your perusal.

OCaml 4.12.0-dev: The upstream OCaml tree has been branched for the 4.12 release, and the OCaml readiness team is busy stabilising it with the ecosystem. The 4.12.0 development stream has significant progress towards multicore support, especially with the runtime handling of naked pointers. The release will ship with a dynamic checker for naked pointers that you can use to verify that your own codebase is clean of them, as this will be a prerequisite for OCaml 5.0 and multicore compatibility. This is activated via the --enable-naked-pointers-checker configure option.

Convergence with upstream and multicore trees: The multicore OCaml trees have seen significant robustness improvements as we've converged our trees with upstream OCaml (possible now that the upstream architectural changes are synched with the requirements of multicore). In particular, the handling of global C roots is much better in multicore now as it uses the upstream OCaml scheme, and the GC colour scheme also exactly matches upstream OCaml's. This means that community libraries from opam work increasingly well when built with multicore OCaml (using the no-effects-syntax branch).

Features: Multicore OCaml is also using domain local allocation buffers now to simplify its internals. We are also now working on benchmarking the IO subsystem, and support for CPU parallelism for the Lwt concurrency library has been added, as well as refreshing the new Asynchronous Effect-based IO (aeio) with Multicore OCaml, Lwt, and httpaf in an http-effects library.

Benchmarking: The Sandmark benchmarking test suite has additional configuration options, and there are new proposals in that project to leverage as much of the OCaml tools and ecosystem as much as possible.

As with previous updates, the Multicore OCaml ongoing, and completed tasks are listed first, which are followed by improvements to the Sandmark benchmarking test suite. Finally, the upstream OCaml related work is mentioned for your reference.

Here are links from many OCaml blogs aggregated at OCaml Planet.

• Announcing MirageOS 3.9.0
• SmartPy@OCaml2020: The Making Of
• Qrc
• Brr
• A Short Review of 4th Generation Cryptocurrencies
• Finding memory leaks with Memtrace
• Rehabilitating packs using functors and recursivity, part 2.
• What's new in ReScript 8.3 (Part 2)
• Rehabilitating Packs using Functors and Recursivity, part 1.
• Building portable user interfaces with Nottui and Lwd
• Tarides is now a sponsor of the OCaml Software Foundation
• Memory allocator showdown
• A general definition of dependent type theories
• Every proof assistant: Cubical Agda – A Dependently Typed Programming Language with Univalence and Higher Inductive Types
• Irmin: September 2020 update
• Introducing irmin-pack