|type_conv/ocaml4 release||Anil Madhavapeddy||7/8/12 2:12 PM|
Hi, is there an ETA for a release of type_conv that builds under ocaml4 (using Markus' patchqueue) ?
I'm doing bulk builds of OCaml4 packages on odd platforms (Linux/ARM and OpenBSD/PowerPC) using the new OPAM package manager to cover as many packages as possible. Unfortunately, the type-conv warning/errors cause many dependent packages to fail to build.
OPAM doesn't yet have patch support, but if it'll take more than a day or two for a type_conv release, then I'll roll my own to unblock the build. Just checking just in case...
Also, is it necessary to have warnings-are-errors enabled in the released tarballs? It makes it awkward to test out new compiler versions, which usually introduce new ones every release.
|Re: type_conv/ocaml4 release||Markus||7/8/12 7:02 PM|
On Sun, Jul 8, 2012 at 5:12 PM, Anil Madhavapeddy <an...@recoil.org> wrote:I agree with Anil that warnings-as-errors should not be enabled in
releases, only during development work.
Markus Mottl http://www.ocaml.info markus...@gmail.com
|Re: type_conv/ocaml4 release||Yury||7/9/12 9:03 AM|
I'll go ahead and generate a new point-release with Markus' fixes.
They'll also make it into the mercurial tree as part of the next
release. I'll get back to you as soon as they're up.
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||7/9/12 9:06 AM|
Thanks! Gerd also just released an ocamlfind-1.3.3 that works with both
OCaml4 and 3, so I'll retry everything tonight with OPAM and see how far it
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/6/12 2:36 PM|
On 8 Jul 2012, at 19:02, Markus Mottl <markus...@gmail.com> wrote:The latest pre-release Core tarballs also fail to compile under Homebrew/MacOS X (OCaml-4.00) due to warnings-as-errors still being activated on release tarballs. Have you considered disabling this on release tarballs?
|Re: type_conv/ocaml4 release||Yury||9/6/12 3:21 PM|
Thanks Anil, I'll fix the packages to disable the warnings-as-errors. In the meantime, you should be able to build with "warn_error=false" in your environment.
Aside from that, what warnings are you encountering?
|Re: type_conv/ocaml4 release||Yury||9/6/12 3:23 PM|
Ah, scratch that warn_error=false bit. Sorry, I just need to regenerate the packages.
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/6/12 3:25 PM|
The warnings are due to unused variables, mostly (such as linux_ext.ml and the Epoll module having variables in there like 'let none = 0' which are unused). It's hard to see how to fix these without conditional compilation, or just skipping the Linux_ext module entirely).
The warn_error=false flag in the environment sounds great, but isn't currently present in the tarballs. It would be very easy to set in most packaging systems, so that's a good alternative to turning it off by default too.
I'm trying a MacOS X 3.12.1 compile now to see how that goes...
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/6/12 3:26 PM|
Linux/Debian gives me a ~30000 line backtrace in the Async build, using separate tarballs. If you have OPAM-0.5, you can try:
$ opam remote -add core-dev git://github.com/avsm/opam-core-pre0
$ opam install async
File "lib/async.cmx", line 1, characters 0-1:
Error: The implementation (obtained by packing)
does not match the interface lib/async.mli:
Modules do not match:
module Backpatched :
<25,000 lines of signature snipped>
Values do not match:
val to_host_and_port :
int -> Async_extra.Import.Socket.Address.Inet.t where_to_connect
is not included in
val to_host_and_port :
int -> Async_extra.Import.Socket.Address.Inet.t where_to_connect
Anyone else see this? Async_core,_extra,_unix seem to install ok on Debian, it's just the final pack that's failing on ocaml-3.12.1.
|Re: type_conv/ocaml4 release||Yury||9/6/12 3:34 PM|
There's a horrible hack to get around this in the build-and-install script to disable the creation of async.mli during the link step. Does anyone understand why packing Async with a cmi causes this error?
|Re: type_conv/ocaml4 release||Yaron Minsky||9/6/12 3:35 PM|
Looping in Nick, Valentin and Sweeks. I think they've probably seen
some of these issues before.
|Re: type_conv/ocaml4 release||Yury||9/6/12 3:36 PM|
On Thu, Sep 6, 2012 at 6:25 PM, Anil Madhavapeddy <an...@recoil.org> wrote:
Thanks, I don't know how I missed that one. The fix there is to just remove line 669 in linux_ext.ml (that "none" value actually isn't used).
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/6/12 3:36 PM|
3.12.1/MacOS X Core compilation fails with yet another error. I've not had a chance to chase this one down either, but it's done via a fresh 3.12.1 install using `opam switch 3.12.1`.
+ mv open_stubs.o lib/open_stubs.o
+ ocamlfind ocamlc -ccopt -pipe -ccopt -g -ccopt -fPIC -ccopt -O2 -ccopt -fomit-frame-pointer -ccopt -fsigned-char -ccopt -Wall -ccopt -pedantic -ccopt -Wextra -ccopt -Wunused -ccopt -Wno-long-long -c lib/signal_stubs.c
+ mv signal_stubs.o lib/signal_stubs.o
+ ocamlfind ocamlc -ccopt -pipe -ccopt -g -ccopt -fPIC -ccopt -O2 -ccopt -fomit-frame-pointer -ccopt -fsigned-char -ccopt -Wall -ccopt -pedantic -ccopt -Wextra -ccopt -Wunused -ccopt -Wno-long-long -c lib/unix_stubs.c
+ + ocamlfind ocamlc -ccopt -pipe -ccopt -g -ccopt -fPIC -ccopt -O2 -ccopt -fomit-frame-pointer -ccopt -fsigned-char -ccopt -Wall -ccopt -pedantic -ccopt -Wextra -ccopt -Wunused -ccopt -Wno-long-long -c lib/unix_stubs.c
+ lib/unix_stubs.c: In function ‘core_unix_stat_64’:
+ lib/unix_stubs.c:393: warning: ‘stat64’ is deprecated (declared at /usr/include/sys/stat.h:466)
+ lib/unix_stubs.c: In function ‘core_unix_lstat_64’:
+ lib/unix_stubs.c:407: warning: ‘lstat64’ is deprecated (declared at /usr/include/sys/stat.h:465)
+ lib/unix_stubs.c: In function ‘core_unix_fstat_64’:
+ lib/unix_stubs.c:419: warning: ‘fstat64’ is deprecated (declared at /usr/include/sys/stat.h:464)
+ lib/unix_stubs.c:595:2: warning: #warning is a GCC extension
+ lib/unix_stubs.c:595:2: warning: #warning "_POSIX_SYNCHRONIZED_IO undefined or <= 0; aliasing unix_fdatasync to unix_fsync"
+ lib/unix_stubs.c:869:2: warning: #warning is a GCC extension
+ lib/unix_stubs.c:869:2: warning: #warning "posix timers not present; clock functions undefined"
+ lib/unix_stubs.c:1069:2: warning: #warning is a GCC extension
+ lib/unix_stubs.c:1069:2: warning: #warning "POSIX TMO not present; unix_mutex_timedlock undefined"
+ lib/unix_stubs.c:1419:2: warning: #warning is a GCC extension
+ lib/unix_stubs.c:1419:2: warning: #warning "_POSIX_PRIORITY_SCHEDULING not present; sched_setscheduler undefined"
+ mv unix_stubs.o lib/unix_stubs.o
+ /Users/avsm/.opam/3.12.1/bin/ocamlmklib -o lib/core_stubs lib/backtrace_stubs.o lib/bigstring_marshal_stubs.o lib/bigstring_stubs.o lib/crc_stubs.o lib/linux_ext_stubs.o lib/misc.o lib/ocaml_utils_stubs.o lib/open_stubs.o lib/signal_stubs.o lib/unix_stubs.o
+ + /Users/avsm/.opam/3.12.1/bin/ocamlmklib -o lib/core_stubs lib/backtrace_stubs.o lib/bigstring_marshal_stubs.o lib/bigstring_stubs.o lib/crc_stubs.o lib/linux_ext_stubs.o lib/misc.o lib/ocaml_utils_stubs.o lib/open_stubs.o lib/signal_stubs.o lib/unix_stubs.o
+ ld: warning: -read_only_relocs cannot be used with x86_64
+ /usr/bin/ranlib: file: lib/libcore_stubs.a(backtrace_stubs.o) has no symbols
+ /usr/bin/ranlib: file: lib/libcore_stubs.a(linux_ext_stubs.o) has no symbols
+ ranlib: file: lib/libcore_stubs.a(backtrace_stubs.o) has no symbols
+ ranlib: file: lib/libcore_stubs.a(linux_ext_stubs.o) has no symbols
+ ocamlfind ocamldep -package variantslib.syntax -package variantslib -package unix -package threads -package sexplib.syntax -package sexplib -package res -package pa_pipebang -package pa_ounit -package fieldslib.syntax -package fieldslib -package comparelib.syntax -package bin_prot.syntax -package bin_prot -package bigarray -syntax camlp4o -modules lib/array_permute.ml > lib/array_permute.ml.depends
+ + ocamlfind ocamldep -package variantslib.syntax -package variantslib -package unix -package threads -package sexplib.syntax -package sexplib -package res -package pa_pipebang -package pa_ounit -package fieldslib.syntax -package fieldslib -package comparelib.syntax -package bin_prot.syntax -package bin_prot -package bigarray -syntax camlp4o -modules lib/array_permute.ml > lib/array_permute.ml.depends
+ Camlp4: Uncaught exception: DynLoader.Error ("/Users/avsm/.opam/3.12.1/lib/ocaml/bigarray.cma", "error loading shared library: /usr/local/lib/ocaml/stublibs/dllbigarray.so: dlopen(/usr/local/lib/ocaml/stublibs/dllbigarray.so, 138): Symbol not found: _caml_hash_mix_double\n Referenced from: /usr/local/lib/ocaml/stublibs/dllbigarray.so\n Expected in: flat namespace\n in /usr/local/lib/ocaml/stublibs/dllbigarray.so")
+ Preprocessing error on file lib/array_permute.ml
+ Command exited with code 2.
caml_hash_mix_double should be exported in dllbigarray already, but I'll have to look into this one later.
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/6/12 3:37 PM|
Oh! A warning that actually is an error ;-)
|Re: type_conv/ocaml4 release||Markus||9/6/12 3:42 PM|
On Thursday, September 6, 2012, Anil Madhavapeddy wrote:
You might also want to apply my Bitbucket patch queue for ocaml-core. The resulting tree should build fine on Mac OS X, fixes a couple of bugs, and adds some useful features.
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/6/12 3:54 PM|
I'm a bit confused by all the patch queues up on Bitbucket (forgive me if this has been covered before on the list!)
Is this the correct one?
The pre-release tarballs aren't on Bitbucket yet, and the repository-splitting script has to be run by Yury, so it's got to be applied manually too I think. I only use the individual Core tarballs since other packages depend on them (mainly type_conv).
|Re: type_conv/ocaml4 release||Yury||9/6/12 3:55 PM|
A few of your sexplib changes didn't make it into this release, and I'll take a look at your patch queue to see what else we're missing. But I've been building and testing on Mac OS X. I'll see if I can recreate Anil's missing symbol problem (I haven't been testing with 3.12.1)
|Re: type_conv/ocaml4 release||Yury||9/6/12 4:09 PM|
Ah, okay. Anil, it looks like there might be some mixup in your install. The string "caml_hash_mix_double" only appears ocaml-4.00, but nowhere in ocaml-3.12.
Also, I was confused. It turned out I was testing with 3.12.1 on Mac OS after all, which is why I didn't catch that unused value warning. I'll install and test with 4.00 on a Mac tomorrow.
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/6/12 4:12 PM|
Spot on... looks like OPAM might be leaking an environment variable that is pointing to the wrong DLL stubs directory after a compiler switch. Should be easy to fix.
Sorry about that; I'll clean up the 25 different OCaml installations I have and do a more fresh build as soon as I get a chance!
|Re: type_conv/ocaml4 release||Markus||9/6/12 6:55 PM|
On Thu, Sep 6, 2012 at 6:54 PM, Anil Madhavapeddy <an...@recoil.org> wrote:The above is the queue of patches accepted by Jane Street. You can
get my fork, which has a lot of patches that have not yet been
You may want to read up on Bitbucket patch queues if you want to learn
how to merge and apply them:
|Re: type_conv/ocaml4 release||Valentin Gatien-Baron||9/7/12 3:01 AM|
It is hard to say why async doesn't build if we don't even know what commands were executed.
From the look of it, I would blame ocamlbuild for doing something fishy. When packing and when there is no mli for the pack, It touches the mli, calls the compiler and then deletes the mli. I don't see how that's solving anything, the code doesn't say it and there is actually a FIXME right at that place, although nothing says what needs to be fixed. It is also the only place in ocamlbuild where it is creates mlis this way.
|Re: type_conv/ocaml4 release||Yury||9/7/12 5:13 PM|
I've just uploaded new packages to https://ocaml.janestreet.com/ocaml-core/108.07.00-pre1/. I've moved the async hack down into base/async/setup.ml, so it should work when building async individually.
Could you take a look and see if they work for you?
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/7/12 5:43 PM|
Trying it now. I've pushed updates to the avsm/opam-core-pre0 and am compiling them now.
Is there a hard requirement on ocaml-4.00.0 now? bin_prot's myocamlbuild:
+ + /usr/bin/ocamlopt.opt -I /usr/lib/ocaml/ocamlbuild unix.cmxa /usr/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa myocamlbuild.ml /usr/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
+ File "myocamlbuild.ml", line 506, characters 24-50:
+ Error: Unbound value Filename.get_temp_dir_name
...which only appeared in ocaml-4.00.0, so 3.12.1 compilation fails (Debian/wheezy).
|Re: type_conv/ocaml4 release||Yaron Minsky||9/7/12 6:24 PM|
Doesn't seem like there should be. We're only using 4.0
experimentally internally, so we definitely support 3.12.1 in our
internal tree. Yury made some small modifications for the external
tarball, so maybe there's an issue there.
|Re: type_conv/ocaml4 release||Yury||9/7/12 8:48 PM|
Yes, sorry that's my fault. Ill fix the packages tomorrow, but in the
meantime I think you can just globally replace
[Filename.get_temp_dir_name ()] with [Filename.temp_dir_name] in
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/7/12 6:57 PM|
Stream of notes here:
- Compiles on the Mac, hurrah! Compiling my little HTTP library against it, and I notice:
(** [write_when_ready writer ~f] waits until there is space available in the pipe, and
then calls [f write], where [write] can be used by [f] to write a single value into
the pipe at a time. [with_write] guarantees that the pipe is open when it calls [f],
and hence that the writes will succeed, unless [f] itself closes the pipe. *)
- Pipe.with_writer is now gone, but there is still a reference to it in the ocamldoc above in the renamed function.
- Similarly, Deferred.whenever is now gone, but there is a reference that should be renamed to Deferred.dont_wait_for:
async_core/async_stream.mli:(** [iter t ~f] = [whenever (iter' t ~f:(fun a -> f a; Deferred.unit))] *)
- The new name Deferred.don't_wait_for seems really awkward with the apostrophe in it. Why not just call it 'do_not_wait_for' or 'dont_wait_for' ? Its quite rare to have function names with special characters, and the apostrophe is easy to mistake for a type variable when scanning through code. It may be too much hassle to change it now though...
- The unconditional use of GADTs in async_extra answers my earlier question about ocaml-4 being a requirement. I'll add a constraint to the OPAM packages.
- I like the new TCP.Where_to_listen use of GADTs. It's a much more self-documenting interface than before!
Cohttp only requires a small diff to compile with the new version. I'll test it over the weekend as I write tutorial notes.
On 7 Sep 2012, at 17:43, Anil Madhavapeddy <an...@recoil.org> wrote:
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/7/12 6:19 PM|
|Re: type_conv/ocaml4 release||Yaron Minsky||9/8/12 11:55 AM|
On Fri, Sep 7, 2012 at 9:19 PM, Anil Madhavapeddy <av...@cl.cam.ac.uk> wrote:Great.
Thanks. Will fix!
Yeah, we had a bunch of unsatisfactory names to choose between, and
I'm somewhat regret changing it, but it's far too much pain to change
it again now. I agree the apostrophe is not ideal, but I was for it
before I was against it...
Where specifically? As I said, our internal tree doesn't use GADTs,
since everything must compile against 3.12.1 to get through our
The version I'm looking at doesn't require GADTs, so again, I'm
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/8/12 12:04 PM|
On 8 Sep 2012, at 11:55, Yaron Minsky <ymi...@gmail.com> wrote:Sorry, ignore this chunk. My brain read the constraint clause as a
new GADT use, whereas it's been in OCaml for ages. Coding on Caltrain...
|Re: type_conv/ocaml4 release||Yury||9/9/12 9:00 AM|
Hi Anil, I just wanted to let you know that the updated packages are up now. Since the only change is that they compile with 3.12 now, I just replaced the existing 108.07.00-pre1 tarballs.
On Fri, Sep 7, 2012 at 11:48 PM, Yury Sulsky <yury....@gmail.com> wrote:
Yes, sorry that's my fault. Ill fix the packages tomorrow, but in the
|Re: type_conv/ocaml4 release||Anil Madhavapeddy||9/9/12 4:00 PM|
Thanks Yury; I've pushed an update to my avsm/opam-core-pre0 repo and am testing now.
For future releases, it would be useful not to ever modify distribution tarballs once released, as the file checksums are recorded separately in the various upstream packaging systems.