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

Update to OCaml 5.1.1, jsoo 5.8.2 #602

Open
wants to merge 32 commits into
base: master
Choose a base branch
from
Open

Update to OCaml 5.1.1, jsoo 5.8.2 #602

wants to merge 32 commits into from

Conversation

AltGr
Copy link
Collaborator

@AltGr AltGr commented Jul 25, 2024

(reopen of #601, closed by mistake)

This mainly required time debugging and finding which parts of the code where silently failing with the newer version. Once I found the way to make our version of ppx_metaquot work with the newer ppxlib (very small code change in the end, but it took quite a bit of digging the ppxlib api), most of the effort was actually in updating jsoo rather than OCaml.

We stick at 5.1 for now because ppx_tools (of which we vendor a patched bit) could easily work with it, but isn't ported to 5.2 yet. There has been lots of improvements in jsoo in the 5.x branch, and I expect things to be faster although I haven't run benches.

I expect this to be part of a 1.1 release and bumped the version number in prevision

@AltGr AltGr force-pushed the ocamlup branch 3 times, most recently from 6296e2b to 9da4406 Compare July 25, 2024 16:06
@AltGr
Copy link
Collaborator Author

AltGr commented Jul 26, 2024

Build on OSX fails, but actually at the OCaml compilation stage ; I have no idea about the state of the OCaml 5.1 support, maybe it's been discontinued for x86_64 ?
The CI should probably be updated but we need someone with familiarity with these systems to do so.
Note also that with the new support of opam for Windows, it probably wouldn't be too difficult to propose native Windows builds, as well.

These issues are mostly unrelated to the current PR though.

@AltGr AltGr requested a review from erikmd July 26, 2024 11:50
@AltGr
Copy link
Collaborator Author

AltGr commented Jul 26, 2024

All other checks pass ; some more manual testing is still warranted (I checked the printing, running and grading only on a few ones)

@erikmd
Copy link
Member

erikmd commented Jul 26, 2024

Hi @AltGr, thanks a lot for this meticulous work!

Build on OSX fails, but actually at the OCaml compilation stage ;
I have no idea about the state of the OCaml 5.1 support, maybe it's been discontinued for x86_64 ?

Yes I just saw this failure.
I think it is not an OCaml error, but the fact the macos-latest GHA image now only provide arm support:
actions/runner-images#9741

Given the static-bin-macos CI job manually installs opam*x86_64-macos, I see two approaches:

  • either we use the macos-13 image,
  • or we replace the script with installing an arm version of opam/ocaml (this shouldn't induce much change I guess… but maybe reduce the compatibility for old macOS users, won't it?)

The CI should probably be updated but we need someone with familiarity with these systems to do so.

FWIW I am a macOS user, not a macOS expert but I could test the macOS artifacts anyway!

Note also that with the new support of opam for Windows, it probably wouldn't be too difficult to propose native Windows builds, as well.

Ah OK, great!
anyway in the meantime, users can rely on WSL.

These issues are mostly unrelated to the current PR though.

Yes. Except the macOS static binaries I'd say, as it will block continuous deployment and release.

What do you think of just putting macos-13 here?

runs-on: macos-latest

@erikmd
Copy link
Member

erikmd commented Jul 26, 2024

What do you think of just putting macos-13 here?

on second thought: given master already failed this way because of the arm image, I'll push a separate PR with this change.

Then you'll be able to rebase on this small PR (and maybe add feat:/fix: prefixes to more commits messages in your PR - those that look important to you)

(compilation_mode whole_program)
(flags --no-source-map --opt=2 --enable=use-js-string --target-env=browser)))

(dev (flags (:standard -safe-string -w -32 -warn-error -a+8))
Copy link
Member

@erikmd erikmd Jul 26, 2024

Choose a reason for hiding this comment

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

Two questions:

  1. adding this dev profile, should I change my usual learn-ocaml programming inner loop?

    Namely, coding then building learn-ocaml with a bash alias that runs:
    cd $learn_ocaml && eval $(opam env) && opam install . --deps-only --locked && make && make opaminstall && learn-ocaml build --repo=demo-repository serve

  2. I had the impression that the dev profile had less warnings enabled than in the release profile ? but probably I'm mistaken

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Historically it was impossible to build in dev mode because (i) dune didn't allow to customise the jsoo flags manually, it was tied to the built-in profiles, and (ii) source-map was blowing on us and the compilation wouldn't terminate. Thankfully both of these are now fixed :)

In the new setting, the jsoo --opt=2 flag makes release compilation quite a bit slower so I'd advise to use the dev mode when, well, developping 🤯 . The Makefile still defaults to release though, I'll add a PROFILE ?= release variable.
Then you could just run make testrun PROFILE=dev

  1. hm it's quite possible, I haven't taken much attention to the specific warning flags ; I've copied them from another of my projects mainly to disable warn-error in dev mode which I find very hard to work with ("yes I know that this argument is unused, I just commented out the code, will you go on anyways ?" ;) )

Copy link
Member

@erikmd erikmd left a comment

Choose a reason for hiding this comment

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

To start with, I just reviewed the opam files. I go on

learn-ocaml-client.opam Outdated Show resolved Hide resolved
learn-ocaml-client.opam Show resolved Hide resolved
Copy link
Member

@erikmd erikmd left a comment

Choose a reason for hiding this comment

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

LGTM, thanks a lot @AltGr for the PR!

FYI next week I'm on vacation - I'm not sure at all I'll be able to perform manual tests by then. But surely in August.

src/app/dune Outdated Show resolved Hide resolved
src/app/dune Outdated Show resolved Hide resolved
src/main/learnocaml_client.ml Show resolved Hide resolved
src/ppx-metaquot/genlifter.ml Show resolved Hide resolved
@erikmd erikmd added the kind: feature New user-facing feature. label Jul 26, 2024
@erikmd
Copy link
Member

erikmd commented Jul 26, 2024

Last question: in the end, would you like that we squash-merge your PR ? or keep all the commits in the master's history.

In the latter case, I'd suggest you rebase -i with rewording some commits messages just to add some prefix (you know, this is important because they will automatically populate the release changelog only if there's some prefix).

To make this easier, below are some suggestions for the 31 commits of the PR.

  • 21f51fd déjà OK feat(build): Migrate ocplib-i18n to ppxlib
  • c29d4ae Suggestion=> deps(opam): Use pin-depends until release of newer ocp-indent-nlfork
  • 7e744ff Suggestion=> build(dune): Update stdlib file names for 4.13
  • f69fb6b déjà OK fix(build): Fix/disable some warnings
  • 82c1ca7 Suggestion+Typo=> fix: Update genlifter.ml from upstream ppx_tools
  • 6a4e595 Suggestion=> deps(opam): Remove dependency on ocaml-migrate-parsetree
  • e765106 Suggestion=> feat: Upgrade to OCaml 4.13
  • c40c880 Suggestion+Typo=> feat: Update to OCaml 4.14.2
  • 3b5835a Suggestion=> refactor: Disable Asak for now (it's not compatible with OCaml 5.0 at the moment)
  • 2813944 Suggestion=> build(dune): Update dune-project
  • 97d9783 Suggestion=> deps(opam): ocplib-json-typed is now json-data-encoding
  • f5fd701 Suggestion=> deps(opam): Update opam files for OCaml 5.0
  • 6b4289e Suggestion=> build(dune): ppx_ocplib_i18n doesn't cope well with dune sandboxing
  • 2546d47 Suggestion=> refactor: Disable partitioning functionality for now (asak isn't compatible with 5.0)
  • 3f1d191 Suggestion=> build(duine): Update stdlib cmi list
  • 64b4968 OK Now compiles (but is broken) with 5.0.0
  • b9dc09c Suggestion=> fix: a bunch of deprecation warnings & errors
  • 6032da4 Suggestion=> fix(dune): Adjust jsoo compilation flags
  • 5d555bd Suggestion=> deps(opam): Working with OCaml 5.0.0 / jsoo 5.0.1
  • 0217355 Suggestion=> deps(opam): Update jsoo to 5.1.1
  • 378c951 Suggestion=> fix: Many fixes and update for jsoo 5
  • 3641979 Suggestion=> fix: Actually bind the --dry-run flag
  • 993e286 Suggestion=> refactor: Improve web-worker debug messages
  • b6c9cc0 Suggestion=> feat: Adjust to OCaml 5.1.1
  • ebd0091 déjà OK feat: complete porting to OCaml 5.1 and jsoo 5.8
  • e87ad94 déjà OK feat: bump version to 1.1.0
  • 787440d déjà OK feat: Reenable asak (using pin-depends for compat patch with OCaml 5)
  • fc6fafe déjà OK fix(CI): fix Dockerfile and client dependencies
  • c10038b déjà OK fix(CI): use older dependency releases in lockfile
  • 5c5a133 déjà OK fix(CI): fix static builds and some specific deps
  • 73423d1 déjà OK fix(CI): fix base Alpine version for final Docker images

@AltGr
Copy link
Collaborator Author

AltGr commented Jul 26, 2024

I'd prefer it not to be squashed as this loses a lot of information. In particular, if one wanted a build working with 4.14, it can easily be extracted now by selecting the correct intermediate commit, and that would be completely lost if squashed.

I don't believe, however, that most of these commit belong to the changelog: saying that we updated jsoo and OCaml versions is the gist of it (plus a few aside improvements, like the --dry-run flag fix). For example, it doesn't hold much meaning to have a changelog stating that Asak was disabled and then re-enabled.

@AltGr
Copy link
Collaborator Author

AltGr commented Jul 26, 2024

Thanks a lot for reviewing, this last patch should address your concerns :)

@@ -68,7 +68,7 @@ case $(uname -s) in
esac
;;
Darwin)
COMMON_LIBS="camlstr ssl_stubs /usr/local/opt/openssl/lib/libssl.a /usr/local/opt/openssl/lib/libcrypto.a cstruct_stubs bigstringaf_stubs lwt_unix_stubs unix"
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Darwin compilation failed again later on... probably something to adjust here ? I'd be glad @erikmd if you could have a look 🙏🏿

Copy link
Member

@erikmd erikmd Jul 29, 2024

Choose a reason for hiding this comment

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

Hi @AltGr, sure! I'll be able to take a look (notably, relying on the make detect-libs target I had (co)written)
but I'm going into vacation so I won't be able to do it before the week of 12 August… stay tuned, and see you!

@AltGr AltGr mentioned this pull request Jul 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: feature New user-facing feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants