Windows 32bit

[RealyUniqueName]

Hi.
I get this message from opam under Win32:

#=== ERROR while compiling luv.0.5.6 ==========================================#
# context              2.0.7 | win32/x86_64 | ocaml-variants.4.07.0+mingw32c | git+https://github.com/fdopen/opam-repository-mingw.git#opam2
# path                 ~/.opam/4.07.0+mingw32c/.opam-switch/build/luv.0.5.6
# command              C:\cygwin\home\VssAdministrator\.opam\4.07.0+mingw32c\bin\dune.exe build -p luv -j 3
# exit-code            1
# env-file             ~/.opam/log/luv-5960-97bbf8.env
# output-file          ~/.opam/log/luv-5960-97bbf8.out
### output ###
#       ocamlc src/c/.luv_c_function_descriptions.objs/byte/luv_c_generated_types.{cmi,cmo,cmt} (exit 2)
# (cd _build/default && C:\cygwin\home\VssAdministrator\.opam\4.07.0+mingw32c\bin\ocamlc.opt.exe -w -40 -w -9-16-27 -g -bin-annot -I src/c/.luv_c_function_descriptions.objs/byte -I C:\cygwin\home\VssAdministrator\.opam\4.07.0+mingw32c\lib\bytes -I C:\cygwin\home\VssAdministrator\.opam\4.07.0+mingw32c\lib\ctypes -I C:\cygwin\home\VssAdministrator\.opam\4.07.0+mingw32c\lib\integers -I src/c/.luv_[...]
# File "src/c/luv_c_generated_types.ml", line 675, characters 4-14:
# Error: Integer literal exceeds the range of representable integers of type int

You can find the build log here: https://dev.azure.com/HaxeFoundation/GitHubPublic/_build/results?buildId=6743&view=logs&j=10276a7f-ec89-5d2f-4095-4252cc68097b&t=1b0e5269-bde3-524d-a9d4-99537d94684b&l=281

[RealyUniqueName]

The line pointed at by the error message:

| Ctypes_static.Primitive Cstubs_internals.Int, "SOMAXCONN" ->
    2147483647

I guess

luv/src/c/luv_c_type_descriptions.ml

Line 269 in 75c9761

let somaxconn = constant "SOMAXCONN" int

should be changed to

let somaxconn = constant "SOMAXCONN" int32

[aantron]

Thanks. Could you change it to nativeint locally and see if that fixes it for you? int32 is likely not the right choice for 64-bit systems.

For the usage of somaxconn in src/stream.ml where an int is expected, change that default value to 10000 for the purposes of testing. I'll probably change it to a clamped conversion from somaxconn to int for the final patch (or you're welcome to try that yourself and make a PR).

[aantron]

I've made the change in branch somaxconn, so you should be able to pin that in CI.

[RealyUniqueName]

It works. Thank you!

[aantron]

Ok great :) If you don't mind, I'll wait for a release of libuv before releasing Luv with this fix. libuv releases about monthly, and their last release was on 25 September, so it should be coming up soon.

[RealyUniqueName]

Sure! Thanks again.

[RealyUniqueName]

Hi.
You've removed the branch. Does that mean you're going to make a release anytime soon?

[aantron]

Sorry, I hadn't realized you likely were using the branch. master should also work, as the commit is included.

Yes about releasing. After working on other things, then taking a break, I decided to finally release Luv without waiting for libuv. Uncharacteristically for them, they still haven't had a release since September.

However, I then noticed this issue at libuv, "Release proposal: v1.41.0": libuv/libuv#3086, from last week. So, I subscribed to it and decided to wait a bit more... hopefully, this issue won't just be open for months producing another long wait. I won't wait that long, though. Anyway, it looks like the PR that they are waiting on is being worked on right now, is done or almost done, and they are finishing up nits. So I hope that means "release very soon."

[aantron]

I'll probably decouple Luv's release schedule from libuv's after this release. I think after a PR made to this repo, releasing the code in this repo is more important than generally obscure fixes done for other reasons in libuv. We've only had one instance so far where a change needed by a user had to be made upstream in libuv instead of here. So, the libuv releases can usually be picked up later.

[RealyUniqueName]

Thanks for detailed explanation. Good to know.

[aantron]

This is now out in Luv 0.5.7. There is also now support for linking with system libuv installation, which I understand from #94 and HaxeFoundation/haxe#9903 will be useful for packaging Haxe.

[RealyUniqueName]

Thank you!