OCaml Weekly News

We are happy to announce the release of opam 2.2.0~alpha3.

Not something serious, something for the hobbies, here is a message to announce bindings for PovRay https://povray.org

This project started as an early daft in 2009: http://decapode314.free.fr/ocaml/povray/pov-bind.tgz and more recently I continued this project: http://decapode314.free.fr/ocaml/povray2/

The last version is: pov-bind-0.10

Here are examples of things you can do with it (with sources under the images):

• http://decapode314.free.fr/ocaml/povray2/examples/0.07/views.html
• http://decapode314.free.fr/ocaml/povray2/examples/0.08/
• http://decapode314.free.fr/ocaml/povray2/examples/0.09/

Here is the api-doc of version 0.10: http://decapode314.free.fr/ocaml/povray2/docs/0.10/Povray.html

This is not a bindings to a C lib, it’s a “printf wrapper”, it creates .pov files that you can provide to povray on the command line.

3 api are provided: a simple one that returns strings, functions start with “get_*”, another one that accumumate to a “scene” type that you create at the begining with “new_scene”, and the third one is more descriptive with the type “scene_desc” which can be usefull if you want to List.map something (some other input that you want to represent graphically).

Here is the beginning of a platformer game that I made for my 3 years old son: http://decapode314.free.fr/ant/platform7.3/platform.html

If the avatar falls into the water it changes its color, I made this because it was easy to do and it made laugh my son.

On my computers MariOCaml is slow, so I was happy to see that my version is not slow, even with a bigger canvas size. It’s not slow even on a modest laptop.

I didn’t found the algorythm by myself, I found it in an article but I didn’t kept the link. I should have kept it, so that I could have cite it in the source code.

This algorithm is very simple, it simplifies the process, with 2 loops, one for the Y axis, and another one for the X axis, so the move of the avatar is not a real diagonal, but it’s not visible when we play.

Also it uses int calculations, so that it matches the pixel of the screen, and the pixel of the platform that it collides.

I don’t know how MariOCaml’s physics works, I tried to read the source code to locate the physics, but I haven’t been able to find it.

There is curently only one screen in the level. I would take any advice about how to make a level that is larger than one screen, which algorithm to use to check collisions with only the nearest blocks.

I would like to announce the last versions of my shmup(s) (look like several shmups but it’s only skins with different graphics): http://decapode314.free.fr/games/shmups.html the scrolling in shmup_px11 should be improved, there are 2 screens one on top of eachother for the scrolling instead of generating only one new needed line at the time (not one entire second screen). I also just fixed a bug in the adjacency map of shmup_px11 today.

I’m happy to share Docfd 1.9.0, which allows you to find and search through text files and PDFs quickly.

• Repo
• Statically linked binary

It is my pleasure to announce the release of version 4.0.0 of Tezt, a test framework for OCaml which is well suited for unit, integration and regression tests in particular. It is used for most Tezos tests.

The main highlights of this major release are:

• --help is much easier to read;
• custom command-line arguments for tests can now be defined using Clap, and they will appear in --help;
• tests can now be selected using generic predicates such as 'tag1 && (tag2 || file = test.ml)';
• one can now use the JSON module without linking with all of Tezt, by linking with the tezt.json sublibrary.

See the changelog for the full list of changes, and the API Documentation for more details.

You can install Tezt with opam:

opam install tezt

Some time after the release of OCaml 5.1.0, we discovered that there in a packaging bug in the 5.1.0 compiler distribution: the new support for compressed compiler artefacts in the compiler made all OCaml executable program depends on the zstdlib library (if compression support was enabled).

There is already an opam configuration option -ocaml-option-no-compression to disable this support and this dependency.

Nevertheless, having a compiler dependency affects all OCaml end of users is far from ideal. Thus we have been trying to find alternatives to remove this dependency. Unfortunately, our current conclusion is that there are no robust and OS-independent solutions to remove this dependency in end-user programs while preserving the current Marshal api with its new Compression flag.

Therefore, we are currently planning to remove this flag in the upcoming 5.1.1 patch release. The compiler will still support compression using an internal library, but the standard library will be free from any dependency on zstdlib. Support for compressed marshalling might be proposed in a separate library at a later point.

This means that there will a breaking change in a patch release, but this breach of policy seemed a better option than leaving a disabled flag in a single version of the Marshall api.

If we have any comments on this unfortunate solution, I am all ears.

I am pleased to announce the adoption of the initial version of the OCaml Platform roadmap!

The roadmap is the result of extensive collaboration with key contributors and discussions within the community. We extend our thanks to organizations who participated in user interviews, including Jane Street, Bloomberg, Ahrefs, LexiFi, Routine, and Meta, as well as the many developers who shared valuable insights that helped shape the roadmap. We also thank our dedicated OCaml Platform maintainers and those who contributed their feedback on Discuss.

A few things that are important to keep in mind:

• The roadmap is a living document. It will continue to evolve. Now that the first version is live on OCaml.org, don’t hesitate to propose amendments in the form of Pull Requests to the OCaml.org repository.
• The roadmap is a directional guide, not a strict specification. It only sets priorities for tool development on the OCaml Platform, shaped in collaboration with maintainers. Changes in the workflows are very likely to happen as work starts on the different projects.
• With a focus on addressing major developer needs and requests, the roadmap is a three-year plan. It’s a relatively short timeline, so it aims for a balance between long-term goals and immediate improvements.

Entering the Execution Phase

With the planning phase complete, we’re moving towards executing the roadmap. This is a community effort, and everyone can participate:

• Community members: Contributions to Platform projects are welcome. All the Platform projects are actively looking for contributors and everyone will be more than happy to help you onboard on a project/task.
• OCaml developers: Your feedback is always helpful. We encourage you to share your experiences and suggestions through issues or here, on Discuss.
• Industrial users: If elements of the roadmap align with your organization’s interests, consider supporting through development contributions or funding maintainers.

Community Feedback

The roadmap went through a few iterations since its first draft was shared for community feedback. Among all the excellent feedback we received, the focus of the roadmap on building a cohesive experience through Dune is one point that spilt a lot of ink. I want to highlight a few changes we’ve made to the roadmap based on that feedback:

• Re-wrote (P5) Tools are independent, yet unified

  Following on P4, we underline the critical importance of permitting tools to flourish independently: the OCaml Platform exists and will continue to exist as a collection of tools that can be used independently. […] Amidst this integration, we firmly commit to ensuring that tools retain their independence and continue to be accessible through their own CLIs.

• Added (W15) Plugin Extensibility

  Following (P6) (The Platform is cohesive, yet extensible), Dune allows external tools to extend its language to add new build rules through a plugin system. […]

• Added (W16) Integrate With Other Build Systems

  […] In order to ensure that the OCaml ecosystem remains accessible and usable for all these users, regardless of their chosen build system, Dune offers support to eject the build plan to a machine-readable format. This enables third-party tools to consume the exported build plan and convert it into other build systems’ specifications. […]

And as mentioned above, the roadmap is a living document, so don’t hesitate to send a PR to update or add development workflows.

This roadmap is a significant step in our journey to improve the OCaml tooling, making OCaml even more pleasant to use, and easier to adopt. It was also the first time we organised a community discussion to adopt a Platform roadmap. This was absolutely worth it, and something we’ll aim to reproduce. In the meantime, if you have suggestions on how we can organise these conversations better in the future, don’t hesitate to share your thoughts.

Now, time to build. On we go!

Hello :)

Tomorrow, concretely [date=2023-11-21 time=18:00:00 timezone=“Europe/Madrid”], is our monthly ppxlib dev meeting. Here’s what we currently have on the agenda:

• Deprecation of Caml in ppxlib and how breaking that change is.
• Ast_builder and Ast_pattern have a restricted API wrt attributes. Ast_helper seemed more flexible wrt attributes. Why? (see https://github.com/ocaml-ppx/ppxlib/issues/458 and https://discuss.ocaml.org/t/best-practices-for-attributes-in-ppx/13400)
• We’re stopping the efforts to manually keep ppxlib compatible with trunk.
• Ppxlib driver performance
• Current state of ppx_deriving

We’re making it a zoom meeting this time, so the meeting link is different than usual. Here it is: https://us04web.zoom.us/j/74533427450?pwd=hx7YUL1LW9Ut9rycc4a1AAGyO36oIJ.1

We have exciting #OCaml news: https://blog.robur.coop/articles/miragevpn.html – the MirageVPN (an OpenVPN™ implementation) is resurrected, and we’re making progress.

We host https://blog.robur.coop (a #MirageOS unipi unikernel - https://github.com/robur-coop/unipi) using YOCaml (https://github.com/xhtmlboi/yocaml) and tlstunnel as reverse TLS proxy (https://github.com/robur-coop/tlstunnel). Deployment was done within < 15 minutes, using our #reproducible_builds infrastructure https://builds.robur.coop

Enjoy reading :D

Collaboration @dinosaure and @reynir

Here are links from many OCaml blogs aggregated at the ocaml.org blog.

• MirageVPN updated (AEAD, NCP)
• MirageVPN & tls-crypt-v2