2023-12-22

[Caml-list] [TFP (and TFPiE) 2024] Call For Participation (January 9-12, Seton Hall University, NJ, USA)

# TFP 2024 -- Call For Participation
(trendsfp.github.io)

## Venue
TFPiE and TFP will take place in-person at Seton Hall University, New Jersey in the United States. 

## Dates

TFPiE Workshop: Tuesday 9th January, 2024
TFP Symposium:  Wednesday 10th - Friday 12th January, 2024

The Symposium on Trends in Functional Programming (TFP) is an
international forum for researchers with interests in all aspects of
functional programming, taking a broad view of current and future
trends in the area. It aspires to be a lively environment for
presenting the latest research results, and other contributions.

## Keynote speakers
We are happy to have the following keynotes in the programme:

* Jeremy Gibbons, Oxford University
* Benjamin Pierce, University of Pennsylvania
* John Reppy, University of Chicago

## Programme
The programme schedule can be found here:
trendsfp.github.io/schedule.html

## Excursion and banquet
After lunch on Thursday there is a private guided tour of the 
Thomas Edison National Historical Park and Museum.
Thursday evening we have the TFP banquet at Forno's of Spain.
During dinner the winners of the best paper awards of last year's TFP
will be announced. 

Posted by at No comments:

2023-12-12

[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of December 05 to 12, 2023.

Ecosystem Wishlist Survey

Archive: https://discuss.ocaml.org/t/ecosystem-wishlist-survey/13578/1

Sabine Schmaltz announced

Hey OCaml folks,

I am running a little OCaml Ecosystem Wishlist survey where you can put in really specific wishes for

  • new packages,
  • package improvements,
  • compiler / tooling / language changes

I’m really curious what you all need and I think this will be helpful to better understand the current state of the ecosystem.

The survey will stay open at least into January, probably much longer.

Put those wishes in! đŸŽ„đŸ«đŸ”„đŸ”„

https://docs.google.com/forms/d/e/1FAIpQLSdVGjO3g9qS31rXy3SE-PxcG6Aki652jiqxzfM2lb7kVh5UHg/viewform?usp=sf_link

OUPS meetup december 2023

Archive: https://discuss.ocaml.org/t/oups-meetup-december-2023/13580/1

zapashcanon announced

The next OUPS meetup will take place on Thursday, 14th of December 2023. It will start at 7pm at the 4 place Jussieu in Paris.

:warning: :trumpet: It will be in the in the Esclangon building (amphi TBA). :trumpet: :warning:

Please, register on meetup as soon as possible to let us know how many pizza we should order.

For more details, you may check the OUPS' website .

This month will feature the following talks :

Miou, un simple scheduler pour OCaml 5 – Romain Calascibetta (@dinosaure)

Miou est un scheduler pour OCaml 5 utilisant les effets nouvellement introduit. Il se concentre sur la disponibilitĂ© d’une application au travers d’une politique de gestion des tĂąches bien dĂ©crite. Cette prĂ©sentation introduira les effets avec OCaml 5 ainsi qu’une rĂ©trospective de son API. Il s’agira ensuite de prĂ©senter les spĂ©cifitĂ©s de Miou par rapport aux autres schedulers. Enfin, il y aura la prĂ©sentation d’un client/serveur HTTP dĂ©veloppĂ© selon le design de Miou. La prĂ©sentation permettra de faire un Ă©tat des lieux du scheduling en OCaml, des raisons de la multiplicitĂ© des solutions ainsi que des objectifs concrets de Miou (implĂ©mentation de services, disponibilitĂ©s des applications, unikernels).

Towards a solution to the expression problem for compilers: strongly typed nano-passes – Boris Yakobowski

We present a new solution to the problem of (strongly) typing compiler passes when the source and destination language share multiple constructors. We are interested in approaches that limit the amount of boilerplate that needs to be (re)written for each language, while still maintaining a very strict typing discipline. Our solution uses well-known tools, but combine them in a novel way:

  • the idea of nanopasses, in which each pass encodes a very limited transformation
  • the use of ppx syntax extensions to express only the differences between a language and the next
  • the traversal of the AST using top-down and bottom-up recursion schemes
  • OCaml polymorphic variants, which are instrumental to precisely type our (non-recursive) transformation functions.

We present our implementation of this approach in the context of the Ada frontend for the Infer analyzer, which as of today contains 28 passes. We will also discuss the various pitfalls we have encountered along the way, as well as possible improvements (in particular deforesting the combination of multiple passes).

Js_of_ocaml 5.2

Archive: https://discuss.ocaml.org/t/ann-js-of-ocaml-5-2/13581/1

Hhugo announced

I'm pleased to announce the release of js_of_ocaml 5.2. It should soon be able available in opam.

Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it possible to run pure OCaml programs in JavaScript environment like browsers and Node.js.

Most significant changes:

  • Improve support for modern javascript
  • New global dead code elimination pass. Jsoo can now drop unused code inside functors. See the pull request for more details
  • Change strategy used for control flow compilation. It was adapted from wasm_of_ocaml and based on the following paper https://dl.acm.org/doi/abs/10.1145/3547621.

See the Changelog for other changes.

containers 3.13

Archive: https://discuss.ocaml.org/t/ann-containers-3-13/13582/1

Simon Cruanes announced

Hello, I just released containers 3.13 on opam.

This release is somewhat more breaking than usual:

  • OCaml 4.08 is now the minimum OCaml version.
  • CCShims_ (which was used to provide a shim for Stdlib pre-4.08) is removed
  • containers-thread, which was deprecated, is no more. The recommended alternative is Moonpool.

On OCaml 5.1 and above, tail-rec-mod-cons is used to simplify and accelerate some functions in CCList.

Happy hacking!

Melange 2.0

Archive: https://discuss.ocaml.org/t/ann-melange-2-0/13073/3

Antonio Nuno Monteiro announced

Melange 2.2 is now out with support for OCaml 5.1.1.

OCaml 5.1.1 released

Archive: https://discuss.ocaml.org/t/ocaml-5-1-1-released/13592/1

octachron announced

In the last three months after the release of OCaml 5.1.0, three significant regressions have been discovered in OCaml 5.1.0. Those regressions concern the packaging of executables, the typechecking of OCaml programs, and the performance of numerical codes.

Since those regressions affect many users and could have lasting effects, we have published a patch release, OCaml 5.1.1, fixing those issues.

As a major exception to our policy for patch releases, OCaml 5.1.1 will contain one breaking change in the standard library: the Compression flag has been removed from the Marshal module. This drastic measure has been taken because supporting zstd compression in the standard library made zstd a dependency of all OCaml executables. Since the compiler should not propagate its dependencies on end-users, the support for compressed marshalling has been moved to a compiler internal library in 5.1.1.

Accounting for the still experimental nature of the multicore runtime, this patch release 5.1.1 also contains safe fixes for subtle concurrency bugs in the OCaml runtime.

In brief, if you were using OCaml 5.1.0, I strongly recommend that you switch to 5.1.1 .

The full list of changes is available below for more details.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands: 

  opam update  opam switch create 5.1.1

The source code for the release is also directly available on:

Changes in OCaml 5.1.1 (8 December 2023)

  • Standard Library
    • (breaking change) #12562, #12734, #12783: Remove the Marshal.Compression flag to the Marshal.to_* functions introduced in 5.1 by #12006, as it cannot be implemented without risking to link -lzstd with all ocamlopt-generated executables. The compilers are still able to use ZSTD compression for compilation artefacts. (Xavier Leroy and David Allsopp, report by Kate Deplaix, review by NicolĂĄs Ojeda BĂ€r, Kate Deplaix, and Damien Doligez).
  • Bug Fixes
    • #12623, fix the computation of variance composition (Florian Angeletti, report by Vesa Karvonen, review by Gabriel Scherer)
    • #12581, #12609: Fix error on uses of packed modules outside their pack to correctly handle nested packs (Vincent Laviron, report by Javier ChĂĄvarri, review by Pierre Chambart)
    • #12645, #12649 fix error messages for cyclic type definitions in presence of the -short-paths flag. (Florian Angeletti, report by Vesa Karvonen, review by Gabriel Scherer)
    • #12757: Fix ocamlnat (native toplevel) by registering frametables correctly (Stephen Dolan, Nick Barnes and Mark Shinwell, review by Vincent Laviron and SĂ©bastien Hinderer)
    • #12791: extern is applied to definitions of caml_builtin_cprim and caml_names_of_builtin_cprim when linking bytecode ’-custom’ executables with a C++ linker. (Shayne Fletcher, review by Antonin DĂ©cimo and Xavier Leroy)
  • GC Performance Regression Fixes
    • #12318: GC: simplify the meaning of custom_minor_max_size: blocks with out-of-heap memory above this limit are now allocated directly in the major heap. (Damien Doligez, report by Stephen Dolan, review by Gabriel Scherer)
    • #12439: Finalize and collect dead custom blocks during minor collection (Damien Doligez, review by Xavier Leroy, Gabriel Scherer and KC Sivaramakrishnan)
    • #12590, #12595: Move caml_collect_gc_stats_sample in caml_empty_minor_heap_promote before barrier arrival. (B. Szilvasy, review by Gabriel Scherer)
    • #12491, #12493, #12500, #12754: Do not change GC pace when creating sub-arrays of bigarrays (Xavier Leroy, report by Ido Yariv, analysis by Gabriel Scherer, review by Gabriel Scherer and Fabrice Buoro)
  • Runtime Bug Fixes
    • #11800, #12707: fix an assertion race condition in install_backup_thread (Jan Midtgaard, review by Gabriel Scherer)
    • #12486, #12535: Fix delivery of unhandled effect exceptions on amd64 with –enable-frame-pointers (Miod Vallat, report by Jan Midtgaard, review by Gabriel Scherer)
    • #12712, #12742: fix an assertion boundary case in caml_reset_young_limit (Jan Midtgaard, review by Guillaume Munch-Maccagnoni)
    • #12713, #12715: disable common subexpression elimination for atomic loads (Gabriel Scherer and Vincent Laviron, review by Vincent Laviron, KC Sivaramakrishnan and Xavier Leroy, report by Vesa Karvonen and Carine Morel)

DkML 2.1.0 - Major changes

Archive: https://discuss.ocaml.org/t/ann-dkml-2-1-0-major-changes/13593/1

jbeckford announced

I’m pleased to announce a major overhaul of DkML in version 2.1.0.

Some of the major changes include:

  • winget install dkml is the recommended way to install.
  • Installation is now in stages. The first stage (winget install dkml) takes 5 minutes and lets the end-user do utop, ocamlc and ocamlrun (sufficient for learning). However, any command that need Visual Studio (ex. opam, dkml) will first:
    • guide you if you need Git and/or Visual Studio (winget does not support auto-installing dependencies like other sane package managers), and then
    • install the OCaml system compiler, the opam root and a playground global switch automatically on first run
  • Alpha support for macOS/Silicon and most modern distros of GNU/Linux
  • Has an accompanying video describing how to install and use DkML on Windows targeted to both learners and professionals. Includes Visual Studio Code and LSP:

Call for Participation: BOB 2024 (Berlin, March 15)

Archive: https://discuss.ocaml.org/t/call-for-participation-bob-2024-berlin-march-15/13609/1

Michael Sperber announced

More info at https://bobkonf.de/2024/! 

  =========================================================================  			       BOB 2024  			      Conference  	     "What happens if we simply use what's best?"  		       March 15, 2024, Berlin  		       https://bobkonf.de/2024/    	    Program: https://bobkonf.de/2024/program.html  	  Registration: https://bobkonf.de/2024/registration.html  =========================================================================    BOB conference is a place for developers, architects, and decision-makers  to explore technologies beyond the mainstream in software development  and to find the best tools available to software developers today. Our  goal is for all participants of BOB to return home with new insights  that enable them to improve their own software development  experience.    The program features 14 talks and 8 tutorials on current topics:    https://bobkonf.de/2024/program.html    Talk subjects includes functional programming, property-based testing,  service API design, programming for spacecraft, accessibility,  hypermedia, business processes, software analytics, event-based  communication and zero-knowledge proofs.    BOB will feature tutorials on F#, Haskell, Lean, SwiftUI, Copilot, the  K Framework, functional domain modelling, and Liberating Structures.    Andreas Rossberg will give the keynote talk.    Registration is open - online tickets are all under 200€, and many  discount options are available, as are grants for members of groups  underrepresented in tech:    https://bobkonf.de/2024/registration.html

ocaml-protoc 3.0

Archive: https://discuss.ocaml.org/t/ann-ocaml-protoc-3-0/13611/1

Simon Cruanes announced

Dear camlidae,

I’m happy to announce the release of ocaml-protoc 3.0 (alongside the multiple runtime libraries: pbrt, pbrt_yojson, and the new pbrt_services). This is a majorly breaking release, I’m sorry for that (I do, however, believe it necessary) and recommend every user of ocaml-protoc add an upper bound < 3.0 to their current project and migrate when they have time.

First, a summary. ocaml-protoc is a self-contained compiler that turns protobuf IDL files (.proto files) into OCaml types, pretty-printers, and (de)serialization functions. The runtime library pbrt (“protobuf runtime”) contains support code for printers and binary (de)serialization; pbrt_yojson contains support code for JSON (de)serialization by way of yojson.

So what changed with ocaml-protoc 3.0? Many things.

For a start, from one .proto file we now generate one pair of .ml and .mli files instead of several pairs. This reduces the boilerplate in build systems and simplifies user code overall (one module per .proto file). A large internal refactor of ocaml-protoc was done prior to the integration of… services.

The major new feature of ocaml-protoc 3.0 is the support for service declarations. These are essentially a way to describe RPC endpoints, next to the types used to interact with the endpoint (example; full generated code). This is typically what it used in systems such as gRPC. Now ocaml-protoc generates server and client stubs for each endpoint, that pack together the type definitions and the relevant (de)serializers; that code doesn’t presume anything about a concrete RPC system. I have in the works a simple Twirp OCaml library that relies on this generated code to provide services over HTTP 1.1; It is also possible to write RPC systems over ZMQ, websockets, etc. without changes to the generated code[^1].

[^1]: note that twirp doesn’t support stream RPC over HTTP 1.1. Other RPC systems can support these, e.g. gRPC does.

Another big-ish change is how the generated code looks like, at least when it comes to binary (de)serialization. ocaml-protoc 3.0 comes with significant speedups for encoding (up to twice the throughput; order of magnitude reduction in allocations in some cases [^2]) and some less impressive speedups for decoding. This is a combination of multiple changes:

  • use of a few C stubs to accelerate varint decoding/encoding;
  • encoding is done back-to-front, which allows the encoder to use a single slice internally[^3]. This is what required changes in the generated code in the first place;
  • encoding code now requires a lot fewer closures (passing arguments explicitly instead) which reduces allocations to almost nothing.

I haven’t recently benchmarked against other protobuf implementations in OCaml, but I’m reasonably confident that this is now the fastest one by a healthy margin.

There are also other improvements and bugfixes. I want to thank in particular @Konstantin_Olkhovski for some of these contributions and for very helpful discussions, and also @VPhantom for more discussions on the topic of performance.

[^2]: if the encoder type is reused, there’s almost no minor allocations, and no major allocations, to encode an existing value into the encoder’s buffer.

[^3]: because sub-messages use varint as their sizes, encoding front-to-back cannot be efficiently done in a single buffer, because it’s not clear how many bytes to reserve in front of a sub-message. With back-to-front that’s not an issue.

The changelog contains many more details.

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 to the caml-list.

Posted by at No comments:

2023-11-30

[Caml-list] [TFP 2024 Final Call for Papers] 25th International Symposium on Trends in Functional Programming

# TFP 2024 -- Call for Papers
(trendsfp.github.io)

## Important Dates

Submission deadline: pre-symposium, full papers,  Saturday 4 November, 2023 (AOE)
Submission deadline: pre-symposium, draft papers, Friday 8 December, 2023 (AOE)
Notification:        pre-symposium full papers,   Friday 8 December, 2023
Notification:        pre-symposium draft papers,  Thursday 14 December, 2023
Registration:                                     Friday 5 January, 2024
TFPIE Workshop:                                   Tuesday 9 January, 2024
TFP Symposium:                                    Wednesday 10 - Friday 12 January, 2024
Submission deadline: post-symposium review,       Friday 23 February, 2024 (AOE)
Notification:        post-symposium submissions,  Friday 5 April, 2024
Camera-ready:        post-symposium submissions,  Friday 3 May, 2024 (AOE)


The Symposium on Trends in Functional Programming (TFP) is an international 
forum for researchers with interests in all aspects of functional programming, 
taking a broad view of current and future trends in the area. It aspires to 
be a lively environment for presenting the latest research results, and other 
contributions.

This year, TFP will take place in-person at Seton Hall University, in South 
Orange, NJ in the United States. It is co-located with the Trends in Functional 
Programming in Education (TFPIE) workshop, which will take on the day before 
the main symposium.

Please be aware that TFP has several submission deadlines. The first, November 4, 
is for authors that wish to have their full paper reviewed prior to the symposium. 
Papers that are accepted in this way must also be presented at the symposium. The 
second, November 30, is for authors that wish to present their work or work-in 
progress at the symposium first without submitting to the full review process for 
publication. These authors can then take into account feedback received at the 
symposium and submit a full article for review by the third deadline, February 23.

## Scope

The symposium recognizes that new trends may arise through various routes. As part 
of the Symposium's focus on trends we therefore identify the following five article 
categories. High-quality articles are solicited in any of these categories:

* Research Articles:
  Leading-edge, previously unpublished research work
* Position Articles:
  On what new trends should or should not be
* Project Articles:
  Descriptions of recently started new projects
* Evaluation Articles:
  What lessons can be drawn from a finished project
* Overview Articles:
  Summarizing work with respect to a trendy subject

Articles must be original and not simultaneously submitted for publication to any 
other forum. They may consider any aspect of functional programming: theoretical, 
implementation-oriented, or experience-oriented. Applications of functional 
programming techniques to other languages are also within the scope of the symposium.

Topics suitable for the symposium include, but are not limited to:

* Functional programming and multicore/manycore computing
* Functional programming in the cloud
* High performance functional computing
* Extra-functional (behavioural) properties of functional programs
* Dependently typed functional programming
* Validation and verification of functional programs
* Debugging and profiling for functional languages
* Functional programming in different application areas:
  security, mobility, telecommunications applications, embedded
  systems, global computing, grids, etc.
* Interoperability with imperative programming languages
* Novel memory management techniques
* Program analysis and transformation techniques
* Empirical performance studies
* Abstract/virtual machines and compilers for functional languages
* (Embedded) domain specific languages
* New implementation strategies
* Any new emerging trend in the functional programming area

If you are in doubt on whether your article is within the scope of TFP, please contact 
the TFP 2024 program chair, Jason Hemann.

## Best Paper Awards

TFP awards two prizes for the best papers each year.

First, to reward excellent contributions, TFP awards a prize for the best overall paper 
accepted for the post-conference formal proceedings.

Second, each year TFP also awards a prize for the best student paper. TFP traditionally 
pays special attention to research students, acknowledging that students are almost by 
definition part of new subject trends. A student paper is one for which the authors 
state that the paper is mainly the work of students, the students are the paper’s first 
authors, and a student would present the paper.

In both cases, it is the PC of TFP that awards the prize. In case the best paper happens 
to be a student paper, then that paper will receive both prizes.


## Instructions to Authors

Authors must submit papers to:

  https://easychair.org/conferences/?conf=tfp24

Authors of papers have the choice of having their contributions formally reviewed either 
before or after the Symposium. Further, pre-symposium submissions may either be full 
(earlier deadline) or draft papers (later deadline).


## Pre-symposium formal review

Papers to be formally reviewed before the symposium should be submitted before the early 
deadline and will receive their reviews and notification of acceptance for both presentation 
and publication before the symposium. A paper that has been rejected for publication but 
accepted for presentation may be resubmitted for the post-symposium formal review.


## Post-symposium formal review

Draft papers will receive minimal reviews and notification of acceptance for presentation at 
the symposium. Authors of draft papers will be invited to submit revised papers based on the 
feedback receive at the symposium. A post-symposium refereeing process will then select a 
subset of these articles for formal publication.


## Paper categories

Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 
10 pages in length) or full papers (20 pages). The submission must clearly indicate which 
category it belongs to: research, position, project, evaluation, or overview paper. It should 
also indicate which authors are research students, and whether the main author(s) are students. 
A draft paper for which all authors are students will receive additional feedback by one of the 
PC members shortly after the symposium has taken place.


## Format

Papers must be written in English, and written using the LNCS style. For more information about 
formatting please consult the Springer LNCS Guidelines web site:

  https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines


## Organizing Committee
Jason Hemann      PC Chair            Seton Hall University, USA
Stephen Chang     Symposium Chair     University of Massachusetts Boston, USA
Shajina Anand     Local Arrangements  Seton Hall University, South Orange, USA
Peter Achten      Publicity Chair     Radboud University Nijmegen, Netherlands

Posted by at No comments:

2023-10-24

[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of October 17 to 24, 2023.

Ppxlib dev meetings

Archive: https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/9

Sonja Heinze announced

@octachron has come to the ppxlib dev meeting today, which has been a very nice surprise. It’s nice to discuss intersections between ppxlib and the compiler together with compiler maintainers. Thanks, @octachron!

So it has been @panglesd, @octachron and me in the meeting. Here are the meeting notes: https://github.com/ocaml-ppx/ppxlib/wiki/Dev-meeting-19-09-2023.

A hack to implement efficient TLS (thread-local-storage)

Archive: https://discuss.ocaml.org/t/a-hack-to-implement-efficient-tls-thread-local-storage/13264/1

Vesa Karvonen announced

Currently OCaml 5 provides a Domain.DLS module for domain-local-state.

Unfortunately,

  1. there is no corresponding Thread.TLS for (sys)thread-local-state, and
  2. the current implementation of Domain.DLS is not thread-safe.

I don’t want to spend time to motivate this topic, but for many of the use cases of Domain.DLS, what you actually want, is to use a Thread.TLS. IOW, many of the uses of Domain.DLS are probably “wrong” and should actually use a Thread.TLS, because, when using Domain.DLS, the assumption must be that you don’t have multiple threads on the domain, but that is typically decided at a higher level in the application and so making such an assumption is typically not safe.

Domain.DLS is not thread-safe

I mentioned that the current implementation Domain.DLS is not thread-safe. What I mean by that is that the current implementation is literally not thread-safe at all in the sense that unrelated concurrent Domain.DLS accesses can actually break the DLS.

Consider the implementation of Domain.DLS.get: 

  let get (idx, init) =      let st = maybe_grow idx in      let v = st.(idx) in      if v == unique_value then        let v' = Obj.repr (init ()) in        st.(idx) <- (Sys.opaque_identity v');        Obj.magic v'      else Obj.magic v

If there are two (or more) threads on a single domain that concurrently call get before init has been called initially, then what might happen is that init gets called twice (or more) and the threads get different values which could e.g. be pointers to two different mutable objects.

Consider the implementation of maybe_grow: 

  let maybe_grow idx =      let st = get_dls_state () in      let sz = Array.length st in      if idx < sz then st      else begin        let rec compute_new_size s =          if idx < s then s else compute_new_size (2 * s)        in        let new_sz = compute_new_size sz in        let new_st = Array.make new_sz unique_value in        Array.blit st 0 new_st 0 sz;        set_dls_state new_st;        new_st      end

Imagine calling get (which calls maybe_grow) with two different keys from two different threads concurrently. The end result might be that two different arrays are allocated and only one of them “wins”. What this means, for example, is that effects of set calls may effectively be undone by concurrent calls of get.

In other words, the Domain.DLS, as it is currently implemented, is not thread-safe.

How to implement an efficient Thread.TLS?

If you dig into the implementation of threads, you will notice that the opaque Thread.t type is actually a heap block (record) of three fields. You can see the Thread.t accessors: 

#define Ident(v) Field(v, 0)  #define Start_closure(v) Field(v, 1)  #define Terminated(v) Field(v, 2)

and the Thread.t allocation: 

static value caml_thread_new_descriptor(value clos)  {    CAMLparam1(clos);    CAMLlocal1(mu);    value descr;    /* Create and initialize the termination semaphore */    mu = caml_threadstatus_new();    /* Create a descriptor for the new thread */    descr = caml_alloc_3(0, Val_long(atomic_fetch_add(&thread_next_id, +1)),                         clos, mu);    CAMLreturn(descr);  }

The second field, Start_closure, is used to pass the closure to the thread start: 

static void * caml_thread_start(void * v)  {    caml_thread_t th = (caml_thread_t) v;    int dom_id = th->domain_id;    value clos;    void * signal_stack;      caml_init_domain_self(dom_id);      st_tls_set(caml_thread_key, th);      thread_lock_acquire(dom_id);    restore_runtime_state(th);    signal_stack = caml_init_signal_stack();      clos = Start_closure(Active_thread->descr);    caml_modify(&(Start_closure(Active_thread->descr)), Val_unit);    caml_callback_exn(clos, Val_unit);    caml_thread_stop();    caml_free_signal_stack(signal_stack);    return 0;  }

and, as seen above, it is overwritten with the unit value before the closure is called.

What this means is that when you call Thread.self () and get a reference to the current Thread.t, the Start_closure field of that heap block will be the unit value: 

assert (Obj.field (Obj.repr (Thread.self ())) 1 = Obj.repr ())

Let’s hijack that field for the purpose of implementing an efficient TLS!

Here is the full hack: 

module TLS : sig    type 'a key    val new_key : (unit -> 'a) -> 'a key    val get : 'a key -> 'a    val set : 'a key -> 'a -> unit  end = struct    type 'a key = { index : int; compute : unit -> 'a }      let counter = Atomic.make 0    let unique () = Obj.repr counter      let new_key compute =      let index = Atomic.fetch_and_add counter 1 in      { index; compute }      type t = { _id : int; mutable tls : Obj.t }      let ceil_pow_2_minus_1 n =      let n = n lor (n lsr 1) in      let n = n lor (n lsr 2) in      let n = n lor (n lsr 4) in      let n = n lor (n lsr 8) in      let n = n lor (n lsr 16) in      if Sys.int_size > 32 then n lor (n lsr 32) else n      let[@inline never] grow_tls t before index =      let new_length = ceil_pow_2_minus_1 (index + 1) in      let after = Array.make new_length (unique ()) in      Array.blit before 0 after 0 (Array.length before);      t.tls <- Obj.repr after;      after      let[@inline] get_tls index =      let t = Obj.magic (Thread.self ()) in      let tls = t.tls in      if Obj.is_int tls then grow_tls t [||] index      else        let tls = (Obj.magic tls : Obj.t array) in        if index < Array.length tls then tls else grow_tls t tls index      let get key =      let tls = get_tls key.index in      let value = Array.unsafe_get tls key.index in      if value != unique () then Obj.magic value      else        let value = key.compute () in        Array.unsafe_set tls key.index (Obj.repr (Sys.opaque_identity value));        value      let set key value =      let tls = get_tls key.index in      Array.unsafe_set tls key.index (Obj.repr (Sys.opaque_identity value))  end

The above achieves about 80% of the performance of Domain.DLS allowing roughly 241M ~TLS.get~s/s (vs 296M ~Domain.DLS.get~s/s) on my laptop.

New Get Started Documentation on OCaml.org

Archive: https://discuss.ocaml.org/t/ann-new-get-started-documentation-on-ocaml-org/13269/1

Thibaut Mattio announced

Dear OCaml Community,

On behalf of the OCaml.org team, I’m thrilled to announce the publication of the new Get Started documentation.

It is organised in three stages:

  • Installing OCaml, which guides you through the installation of opam, the initialisation of a switch and the installation of Platform tools.
  • A Tour of OCaml, which walks you through the basics of the OCaml language and invites you to use the top-level to start playing with the language.
  • Your First OCaml Program, which is a bit more practical and assumes you’re using an editor to help you create your first executable using Dune.

In addition to these, you’ll also find introductory guides on the tooling to complement the introduction to the language:

Our goal is to make OCaml.org the best resource to get started with and learn OCaml.

There are still a lot of gaps to fill in the documentation – and we’ll continue to work on these in the coming months – but the Get Started experience is probably the most important part of the documentation to alleviate friction points that discourage new users from adopting OCaml. As such, don’t hesitate to publicise these, but most importantly, let us know your feedback!

Happy reading!

Web Analytics on OCaml.org

Archive: https://discuss.ocaml.org/t/web-analytics-on-ocaml-org/13188/8

Continuing this thread, Thibaut Mattio said

Thanks for the feedback and the participation in the survey!

Seeing that there aren’t major concerns, we’ll be moving forward with a trial of Plausible.

As @avsm said, we plan on self-hosting it on the OCaml.org infrastructure to respect our commitment to not use any third-party service. This means that not only we won’t be collecting any personal data, but even the aggregate data will never leave the OCaml.org infrastructure.

There’s roughly a third of people who are against adding analytics to OCaml.org in the survey above. We strongly believe that Plausible is aligned with our commitment to protect OCaml.org visitors’ privacy, but I’ll echo @avsm in saying that if people believe that this is not the case, I’d love to hear about the specific concerns and ideas for alternatives.

To answer some questions above:

Are you going to give a public access to the Plausible statistics ? Or will it be only for the maintainers i.e. Tarides ?

The analytics dashboard will be public.

Have you considered running a server-side analytics service?

Yes, @JiaeK actually worked on a server-side analytics service as part of her Outreachy internship in 2021 and had made fantastic progress. The WIP dashboard is available at https://ocaml.org/dashboard.

It currently doesn’t collect any data and only logs unique page accesses.

We had planned on building on top of this, but as you can imagine this is a large project, and the OCaml.org team has been prioritising improvements to the site itself.

I found the following to be a good read on the pros and cons of server-side vs client-side analytics: https://plausible.io/blog/server-log-analysis#how-big-of-a-data-gap-is-there-between-server-log-analysis-and-web-analytics

TL;DR for all its benefits, server-side analytics comes with a load of drawbacks and isn’t fundamentally more privacy-friendly than privacy-oriented client-side analytics solution.

That being said, if someone would like to contribute to the Dream analytics dashboard to make it usable as an alternative to other analytics solutions, I’d be more than happy to move towards this! Don’t hesitate to reach out to me or other OCaml.org maintainers about that.

OCaml.org Newsletter: August and September 2023

Archive: https://discuss.ocaml.org/t/ocaml-org-newsletter-august-and-september-2023/13272/1

Thibaut Mattio announced

Welcome to the August and September 2023 edition of the OCaml.org newsletter! This update has been compiled by the OCaml.org team. You can find the previous updates on Discuss.

Our goal is to make OCaml.org the best resource for anyone who wants to get started and be productive in OCaml. The OCaml.org newsletter provides an update on our progress towards that goal and an overview of changes we are working on.

We couldn’t do it without all the amazing OCaml community members who help us review, revise, and create better OCaml documentation. Your feedback enables us to better prioritise our work and make progress towards our goal. Thank you!

These past two months, our priorities were:

  • Learn Area: We’re working towards making OCaml.org a great resource to learn OCaml and discover its ecosystem. We’ve focussed on getting the new Get Started documentation ready for publication, and we started work on a second iteration of the designs for the Learn area.
  • General Improvements: As usual, we also worked on general maintenance and improvements based on user feedback, so we’re highlighting some of our work below.

Learn Area

  • 1. Redesign of the Learn Area

    After completing the first version of the design in July, we started working on a new iteration that is more in line with the current branding of the site. Feedback from the team and users has been extremely positive on the UX (the structure of the new documentation and the layout of the pages), but we felt that the design direction needed to be reconciled with and improve on the existing designs of all pages. Thus, we are revisiting the designs’ UI aspects in both light and dark modes.

    Relevant PRs and Activities:

    • Continued work on Figma UX/UI designs for the new Learn area:
      • Continued overall Learn area UI design
      • Improved dark mode for the home page on mobile and made necessary text amendments
      • Designed mobile views for the search field with an open navigation feature and breadcrumb navigation
      • Worked on updating the design systems to ensure consistency between light and dark variants
    • Continued the implementation of new components for the Learn Area:
  • 2. OCaml Documentation

    Since August, we’ve focused mainly on the “Getting Started” documents, including a guide to installing OCaml, a “tour” of the OCaml language, and a tutorial to create your first project in OCaml.

    Anticipating on our October update, we’ve just published the new Get Started documentation pages! :tada:

    We still encourage community feedback, as we fully expect to iteratively improve these docs in the coming weeks, especially as they will now serve as the primary resource to everyone who wants to get up and running with OCaml.

    Our focus will now shift to filling the gaps in the Language section of the documentation, starting with the Basic Data Types and Functions and Values pages, which are currently in the Community review stage.

    Relevant PRs and Activities:

General Improvements

This month, we’re welcoming 2 new contributors:

and welcome contributions from returning contributors:

Thanks a lot to all the contributors this month! It’s lovely to see more and more people making contributions to the site!

Relevant PRs and Activities:

Release of odoc 2.3.0

Archive: https://discuss.ocaml.org/t/ann-release-of-odoc-2-3-0/13273/1

Paul-Elliot announced

The odoc team is thrilled to announce the release of odoc 2.3.0! 🎉 This release is the result of almost a year of diligent work since the last major release of odoc 2.2.0, it comes packed with significant new features and improvements!

🌟 Spotlight Features of Odoc 2.3.0

Here are a couple of the new features introduced in Odoc 2.3.0 that we’d like to highlight.

  • 1. Table Support

    Table support is the last addition to the odoc language, and comes with two syntax flavours: a light one, and a heavy one. The light markup is similar to markdown’s markup for table, producing tables that are readable in the source file as well.

    However, this markup has some limitation, since it only allows inline content in cells. It can also be difficult to read and mantain for big tables, without a proper editor support. For this reason, Odoc also provides a “heavy” markup, closer to the html one, with fewer limitations!

    Here is a table in heavy, light, and rendered form: 

      {t  Table | support  ------|--------  is    | cool!  }  
      {table  {tr {th Table} {th support}}  {tr {td is} {td cool!}}  }
    Table support
    is cool!
  • 2. Source Code Rendering

    Source code rendering is an extremely exciting new feature. Not only odoc is now able to generate a rendering of the source files (and source hierarchy) of a project, but it is also able to create direct links from the documentation to the implementation!

    This puts the documentation browsing to a new level, by helping to quickly answer any implementation-related question!

    The source code rendering is also tailored to OCaml, for instance with links from variables to their definition, something missing from traditional html-based source viewing such as github!

    Using this features in odoc’s driver will require some work, but you can already have a preview of the feature by going to the odoc API website, which was built with the feature enabled. For instance, the Odoc_html module is now populated with many Source links, jumping right into the implementation file! Directory pages to browser the implementation are also included :D

đŸ—ș️ Background & Roadmap

Before displaying the full changelog, some background on our roadmap and what comes next.

The lack of access to comprehensive documentation for OCaml libraries is one of the biggest pain points reported by the OCaml community, as highlighted in the 2022 OCaml survey (c.f. Q50).

This motivated the odoc and OCaml.org teams to jointly work on a centralised package documentation, that went live in April 2022, as part of the new version of OCaml.org.

With documentation for OCaml libraries readily available on OCaml.org, we now turn our focus on making sure that library authors have the tooling they need to create high-quality documentation.

Our roadmap highlights some features we believe will make the generated documentation significantly better for readers, and documentation-writing much more pleasant and rewarding.

This release is a significant milestone in implementing the features on our roadmap and is the precursor to a series of upcoming releases. Odoc 2.4.0 will follow shortly and will bring support for search. Stay tuned and follow our progress through the OCaml Platform newsletter!

đŸ€ Join The Mission

While we are dedicated to developing the best tooling to generate and serve documentation on OCaml.org, creating a well-documented library ecosystem can only be a collective effort. Package authors: we’re working hard to give you great tools, but we’ll need all your help to create an ecosystem of well-documented libraries for OCaml!

If you find that writing documentation for your library isn’t as straightforward as you would like, please do share your feedback with us.

2.3.0 Changelog

  • Added
    • Source code rendering (@Julow, @panglesd, @jonludlam #909, #996, #993, #982)
    • Handle tables markup (@panglesd, @gpetiot, #893)
    • Initial support for assets (@trefis, #975)
    • odoc-parser remerged (@jonludlam, #973) This includes table support (@gpetiot, @panglesd, ocaml-doc/odoc-parser#11 ocaml-doc/odoc-parser#14) and delimited code blocks with optional output (@jonludlam, ocaml-doc/odoc-parser#17)
    • Add a tooltip to references with text (@Julow, #945)
    • Add emoji to alerts in CSS (@yawaramin, #928)
    • Add common language in shipped highlightjs (@Julow, #953)
    • Display ’private’ keyword for private type extensions (@gpetiot, #1019)
  • Fixed
    • Fix --hidden not always taken into account (@panglesd, #940)
    • Syntax highlight labels in function arguments (@panglesd, #990)
    • Ensure generated html ends with a newline (@3Rafal, #954)
    • Warn against tags in pages (@Julow, #948)
    • Remove unhelpful ’Unresolved_apply’ errors (@gpetiot, #946)
    • Allow links and references in headings (@EmileTrotignon, @panglesd, #942)
    • Fix rendering of method types (@zoggy, #935)
    • Fix section labelling with submodules (@EmileTrotignon, @panglesd, #931)
    • LaTeX backend fixes (@Octachron, #921 #920)
    • html: Remove extra space in class declarations (@Julow, #936)
    • Fix rendering of unresolved references (@Julow, #957)

Announce Seppo.Social v0.3 and invite thoughts

Archive: https://discuss.ocaml.org/t/ann-announce-seppo-social-v0-3-and-invite-thoughts/13277/1

Marcus Rohrmoser 🌍 announced

Hi all,

I am happy to announce yesterday’s release of v0.3 of #Seppo!, the friendly, sustainable, permacomputing inspired alternative to all those heavy microblog servers. Generously funded by #NLnet https://nlnet.nl/project/Seppo

It’s built to be operated by yourself on commodity shared webspace without requiring much further attention.

Read more at https://seppo.social/en/support/#installation

Changes

  • post notes
  • being subscribed to (aka ’followed’)
  • distribute post to subscribers
  • job queue to do so
  • housekeeping UX (password, profile page, timezone)

Your thoughts are very much appreciated.

Marcus Rohrmoser https://digitalcourage.social/@mro/111261271071034377

P.S.: There will be đŸ« stickers again, soon.

bwd 2.3.0 for backward lists

Archive: https://discuss.ocaml.org/t/ann-bwd-2-3-0-for-backward-lists/13278/1

Favonia announced

I am happy to announce a new version of bwd for backward lists! The new release added init and a few other List functions introduced in OCaml 5.1 (is_empty, find_index, and find_mapi). It also added many inlining annotations.

Backward lists are isomorphic to regular lists but place elements backward. Using a different type for semantically backward lists can avoid bugs such as missing or misusing List.rev or List.rev_append. Our strategy is to keep the elements’ textual order and avoid functions such as List.rev. Initially, this package was created to eliminate bugs in our type checkers, but we have been using it almost everywhere since then. I recommend using bwd if you use list to store anything semantically backward. 😉

More information at https://github.com/RedPRL/ocaml-bwd

Storing credentials to a private OPAM repository

Archive: https://discuss.ocaml.org/t/storing-credentials-to-a-private-opam-repository/3520/10

Richard Degenne announced

Welp, 4 years later, I decided to give that whole private OPAM repository thing another shot, and I ended up with something I’m quite proud of, with a private Opam repository, and private packages uploaded to GitLab’s package registries!

https://blog.richarddegenne.fr/2023/10/20/setting-up-a-private-opam-repository-on-gitlab-step-by-step/

OCaml on Windows: the long paths issue

Archive: https://discuss.ocaml.org/t/ocaml-on-windows-the-long-paths-issue/13283/1

Manas announced

Not very long ago, I managed to solve the long paths issue for OCaml and I want to share how.

While building a large project, I ran into the path issues - Dune would fail with errors saying a certain file present in a long file was not found. Shortening libraries names helped. But what was really needed was manifesting OCaml tools so that they can perform I/O on long paths as described here on MSDN docs.

Guidelines there expect binary artifacts (dll or exe) have to be manifested with something like this 

<?xml version="1.0" encoding="utf-8"?>  <application xmlns="urn:schemas-microsoft-com:asm.v3">      <windowsSettings  xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">          <ws2:longPathAware>true</ws2:longPathAware>      </windowsSettings>  </application>

Ideally, the application being built is also manifested so.

I use esy as my daily driver for Windows development. I have always found the workflow on Windows with esy reasonable and never stopped using it since I discovered. Over time, I have taken up maintenance of the project too.

OCaml on Windows is practical only with Cygwin. Not because the tools needs a Unix like environment - they have evolved significants over the years since I have been using OCaml on Windows. Cygwin is convenient because of the libraries in the ecosystem - for instance all the native libraries from GNU project. GNU projects are easily built inside Cygwin/MSYS/mingw but not so outside.

I was worried that I’d have to write some gory hack in the compiler to manifest every binary artifact - dune had to be manifested too. There are many ways to embed the manifest with tools windres etc. But fortunately, I found that Mingw already embeds all executables with a default one. It can be found here among the Cygwin projects

I decided to fork the repository and use the manifest MSDN docs recommended. You can find it here This helped me fix my project, but I wanted this for the rest of the community too.

Esy uses a utility called esy-bash which packages the Cygwin environment for the user. We find that users have mostly uniform setups this way. Helps with reproducibility. I decided to tweak esy-bash to package my fork of the windows-default-manifest along with other Cygwin packages. This way OCaml users dont have to worry about the long paths issue anymore.

This has been available since esy 0.7.0. If you’d like to try the latest esy, it is available on NPM and can be installed with npm i -g esy

I’d love to hear your thoughts on this approach. More than happy to contribute a solution like this for opam too.

A Roadmap for the OCaml Platform - Seeking Your Feedback

Archive: https://discuss.ocaml.org/t/a-roadmap-for-the-ocaml-platform-seeking-your-feedback/12238/68

Thibaut Mattio announced

I updated the roadmap to incorporate the latest feedback. This update:

  • Adds a workflow to support Dune plugins (W15)
  • Adds a workflow to integrate with other build systems (W16)
  • Adds a workflow to compile to WebAssembly from Dune (W14)
  • Adds a workflow to compile MirageOS unikernels from Dune (W12)
  • Updates Literate Programming workflow to use odoc and mention interactive code blocks (W24)
  • Updates Generate Documentation workflow to list features planned as part of the odoc roadmap (W25)
  • Updates Package Publication to remove mention that users need not to commit an opam file (W26)

A big thank you to everyone who participated in the discussion! Building a community-driven roadmap is no trivial exercise, but witnessing so many people being driven to share constructive feedback, there’s no doubt that it’s absolutely worth it.

Much of the feedback, both here and in other Discuss threads (e.g. https://discuss.ocaml.org/t/the-ocaml-platform-a-vehement-dissent/13008), points out the roadmap’s pronounced Dune-focus. I want to be very clear that while the focus of the coming years highlighted in the roadmap is indeed to consolidate the integration of the Platform tools to create a cohesive experience – a top request in the OCaml surveys – there’s no intention to make Dune the singular solution for OCaml tooling. The OCaml Platform is a collection of independent tools that can be used without Dune, and this will remain the case.

We’ve worked on formalising the Guiding Principles before sharing the roadmap. One key principle we’ve asserted is that while Platform tools operate under a single frontend (the editor or Dune at the moment), they remain independent. @xavierleroy rightly suggested that we commit to this in stronger terms, so we’ve updated the relevant Principle to make this more explicit.

In addition to clarifying the Guiding Principles, seeing that the majority of the feedback we received is asking for better support for non-Dune users, two of the added workflows in this last update (W15 and W16) aim at bringing better support for third-party (i.e. non-Platform) tools.

Special thanks to @jbeckford for initiating discussions on Dune plugins!

Let us know what you think of these new workflows and the other updates! As usual, let’s give an additional 2 weeks for feedback on the roadmap. Barring significant concerns, we’ll undergo a final revision based on all the discussions before adopting the first version.

PS: thank you @shonfeder for pointing out that the issues were deactivated on the repository. I’ve activated them, so don’t hesitate to open issues there now.

Adding Dynamic Arrays / Vectors to StdLib

Archive: https://discuss.ocaml.org/t/adding-dynamic-arrays-vectors-to-stdlib/4697/48

Continuing this thread, gasche announced

Hi everyone,

A short note: we eventually manage to build consensus on https://github.com/ocaml/ocaml/pull/11882 and I merged it yesterday, so there will be a Dynarray module in the standard library in OCaml 5.2. Thanks @BastouP411 and @c-cube for their efforts bringing us to this point, and to the many reviewers of the latest iteration of the PR (in particular @314eter, @c-cube, @clef-men, @damiendoligez, @dbuenzli, @gadmm, @Octachron and @wiktor).

The implementation uses an indirection to get a type-safe “empty” value to use in unused elements of the support array. Hopefully we can improve on that with a safe magical implementation in the short future – but I think that the performance is good enough already.

vdom 0.3: functional UI applications now with custom event handlers

Archive: https://discuss.ocaml.org/t/ann-vdom-0-3-functional-ui-applications-now-with-custom-event-handlers/13298/1

Aurélien Saue announced

We are thrilled to announce the release of the new v0.3 release of vdom, previously named ocaml-vdom!

The library implements the functional Elm architecture. Combined with the power of OCaml, it makes the development of UI applications easy and reliable, and that is why we have been using it internally since 2016.

A highlight of this new version is the introduction of fully customizable event handlers, using Elm-style decoders. This enhancement simplifies the management of intricate browser events, such as retrieving drag-and-dropped files.

Read our blog post for more details about this new feature!

GitHub homepage: https://github.com/LexiFi/ocaml-vdom

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 to the caml-list.

Posted by at No comments:
Subscribe to: Posts (Atom)