Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v0.17 of Core and dependencies #25818

Merged
merged 46 commits into from May 23, 2024
Merged

Conversation

dkalinichenko-js
Copy link
Contributor

This PR contains the latest release of Jane Street's Core and necessary dependencies.

@dkalinichenko-js
Copy link
Contributor Author

Seems like many packages have errors due to the deprecated Caml module. I will add version bounds to them.

@dkalinichenko-js
Copy link
Contributor Author

I see there are still a bunch of errors related to Caml, will fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @dkalinichenko-js,

I wanted to mention to you in case this is useful information, as I was trying different combinations of core and ocaml versions I noticed that core.v0.17.0 doesn't build with ocaml.5.2.0.

File "core/src/gc.ml", line 581, characters 6-8:
581 |     | () ->
            ^^
Error: This pattern matches values of type unit/2
       but a pattern was expected which matches values of type
         Stdlib.Gc.Memprof.t
       File "_none_", line 1:
         Definition of type unit/2

Looks like it is due to an Experimental API change in ocaml/ocaml#12381 the function Stdlib.Gc.Memprof.start now returns a t rather than unit.

As it stands, it seems you would need to constraint core.v0.17.0 to 5.1 only.

It's possible there's a quick fix that makes the pattern permit the type t (perhaps a version dependent preprocess or something), but looking into the function measure_and_log_allocation_local as a whole, it seems there might be a more subtle story with respect to multicore runtime. I'll defer to you on that.

I'm interested to know if you plan for having a core.v0.17.* that's compatible with 5.2 or, if you think it'll likely to await v0.18.*.

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi! We definitely want v0.17 of our libraries to be available with OCaml 5.2. I'll look into the problem after finishing releasing all packages and will submit Core v0.17.1 if there's a fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! Thanks for letting me know, and good luck with the release.

Copy link
Member

@mseri mseri May 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add an upper bound on ocaml5.2 to core v0.17?

This PR is huge. @dkalinichenko-js would it be possible to move the upper bounds on third party packages to a separate PR? I can merge that straight away, then we can add the bounds to core here and have an easier time with the review

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, see #25888. I also added an upper bound to Core.

Based on the previous CI run, I think all remaining failures are unrelated to this release.

Copy link
Member

@mseri mseri May 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. d87bb8f slipped in, I made a new PR without it (#25898) and merged it.

If update this one with just d87bb8f and 264b360 I think it is ready for review

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, though one commit adding version bounds still got left out of the previous PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for spotting it!

@mseri
Copy link
Member

mseri commented May 21, 2024

Besides the CI issues, there are a few failures I would like to look at before merging. I’m traveling and have bad internet these days, but I should be able to do it on Thursday

@mseri
Copy link
Member

mseri commented May 22, 2024

Is this failure in qucheck-core 0.20--0.21.3 related to the new release?


#=== ERROR while compiling qcheck-core.0.21.3 =================================#
# context              2.2.0~beta3~dev | linux/x86_64 | ocaml-base-compiler.5.2.0 | file:///home/opam/opam-repository
# path                 ~/.opam/5.2/.opam-switch/build/qcheck-core.0.21.3
# command              ~/.opam/opam-init/hooks/sandbox.sh build dune runtest -p qcheck-core -j 39
# exit-code            1
# env-file             ~/.opam/log/qcheck-core-7-527038.env
# output-file          ~/.opam/log/qcheck-core-7-527038.out
### output ###
# (cd _build/default && /home/opam/.opam/5.2/bin/ocamlc.opt -w -40 -g -bin-annot -I test/core/.QCheck_unit_tests.eobjs/byte -I /home/opam/.opam/5.2/lib/alcotest -I /home/opam/.opam/5.2/lib/astring -I /home/opam/.opam/5.2/lib/bytes -I /home/opam/.opam/5.2/lib/cmdliner -I /home/opam/.opam/5.2/lib/fmt -I /home/opam/.opam/5.2/lib/ocaml/unix -I /home/opam/.opam/5.2/lib/re -I /home/opam/.opam/5.2/lib/seq -I /home/opam/.opam/5.2/lib/stdlib-shims -I /home/opam/.opam/5.2/lib/uuidm -I src/core/.qcheck_core.objs/byte -no-alias-deps -open Dune__exe -o test/core/.QCheck_unit_tests.eobjs/byte/dune__exe__QCheck2_unit_tests.cmo -c -impl test/core/QCheck2_unit_tests.ml)
# File "test/core/QCheck2_unit_tests.ml", line 23, characters 14-20:
# 23 |     Alcotest.(check' (list int))
#                    ^^^^^^
# Error: Unbound value "check'"
# Hint: Did you mean "check"?
# File "test/core/dune", line 60, characters 9-26:
# 60 |   (names QCheck_unit_tests QCheck2_unit_tests)
#               ^^^^^^^^^^^^^^^^^
# (cd _build/default/test/core && ./QCheck_unit_tests.exe)
# Error: "Test.make ~long_factor" is not a valid test label (must match ^[a-zA-Z0-9_- ]+$).
# Error: "Test.make ~count" is not a valid test label (must match ^[a-zA-Z0-9_- ]+$).

Is this also related to this release?

#=== ERROR while compiling ocplib-simplex.0.3 =================================#
# context              2.2.0~beta3~dev | linux/x86_64 | ocaml-base-compiler.5.2.0 | file:///home/opam/opam-repository
# path                 ~/.opam/5.2/.opam-switch/build/ocplib-simplex.0.3
# command              ~/.opam/opam-init/hooks/sandbox.sh build make
# exit-code            2
# env-file             ~/.opam/log/ocplib-simplex-7-fbb5e2.env
# output-file          ~/.opam/log/ocplib-simplex-7-fbb5e2.out
### output ###
# cp src/extSigs.mli src/extSigs.ml
# cp src/coreSig.mli src/coreSig.ml
# ocamldep -I src src/*.ml* > .depend
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/version.mli
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/version.ml
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/extSigs.mli
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/rat2.mli
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/rat2.ml
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/extSigs.ml
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/polys.mli
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/polys.ml
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/coreSig.mli
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/coreSig.ml
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/core.mli
# ocamlc.opt -c -annot -absname -bin-annot -short-paths -strict-sequence -w +A -g -I src -for-pack OcplibSimplex src/core.ml
# File "/home/opam/.opam/5.2/.opam-switch/build/ocplib-simplex.0.3/src/core.ml", line 231, characters 14-75:
# 231 |               "%a   [ %a == (%4a , %4a) ]   %a   (computed %s) (flag %s)@."
#                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# Error: invalid format "%a   [ %a == (%4a , %4a) ]   %a   (computed %s) (flag %s)@.": at character number 20, `padding' is incompatible with 'a' in sub-format "%4a"
# make: *** [Makefile:130: src/core.cmo] Error 2

@mseri
Copy link
Member

mseri commented May 22, 2024

The rest seems fine (or unrelated and fixed in a separate PR that I am submitting now)

@dkalinichenko-js
Copy link
Contributor Author

dkalinichenko-js commented May 22, 2024

As far as I can tell, the first failure you linked is caused by alcotest, not our packages.

@dkalinichenko-js
Copy link
Contributor Author

ocplib-simplex also does not depend on our packages.

@mseri
Copy link
Member

mseri commented May 22, 2024

The first part yes, it was this my doubt:

File "test/core/dune", line 60, characters 9-26:
# 60 |   (names QCheck_unit_tests QCheck2_unit_tests)
#               ^^^^^^^^^^^^^^^^^
# (cd _build/default/test/core && ./QCheck_unit_tests.exe)
# Error: "Test.make ~long_factor" is not a valid test label (must match ^[a-zA-Z0-9_- ]+$).
# Error: "Test.make ~count" is not a valid test label (must match ^[a-zA-Z0-9_- ]+$).

@dkalinichenko-js
Copy link
Contributor Author

Just checked, qcheck-core also does not depend on our packages.

@mseri
Copy link
Member

mseri commented May 23, 2024

Thanks for checking!

@mseri mseri merged commit bfebf95 into ocaml:master May 23, 2024
1 check failed
@mseri
Copy link
Member

mseri commented May 23, 2024

And for the release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants