type_conv/ocaml4 release

Showing 1-31 of 31 messages
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.

cheers,
Anil

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:
> 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.

I agree with Anil that warnings-as-errors should not be enabled in
releases, only during development work.

Regards,
Markus

--
Markus Mottl        http://www.ocaml.info        markus...@gmail.com
Re: type_conv/ocaml4 release Yury 7/9/12 9:03 AM
Hi guys,

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
gets.

-anil
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:

> On Sun, Jul 8, 2012 at 5:12 PM, Anil Madhavapeddy <an...@recoil.org> wrote:
>> 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.
>
> I agree with Anil that warnings-as-errors should not be enabled in
> releases, only during development work.


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?

-anil

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...

-anil
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:
        sig
          module Backpatched :

 <25,000 lines of signature snipped>

      Values do not match:
        val to_host_and_port :
          string ->
          int -> Async_extra.Import.Socket.Address.Inet.t where_to_connect
      is not included in
        val to_host_and_port :
          string ->
          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.

-anil
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.

y
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:
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).

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).
 

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...

-anil

On 6 Sep 2012, at 15:21, Yury Sulsky <yury....@gmail.com> wrote:

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?

On Thu, Sep 6, 2012 at 5:35 PM, Anil Madhavapeddy <an...@recoil.org> wrote:
On 8 Jul 2012, at 19:02, Markus Mottl <markus...@gmail.com> wrote:

> On Sun, Jul 8, 2012 at 5:12 PM, Anil Madhavapeddy <an...@recoil.org> wrote:
>> 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.
>
> I agree with Anil that warnings-as-errors should not be enabled in
> releases, only during development work.


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?

-anil




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.

-anil
Re: type_conv/ocaml4 release Anil Madhavapeddy 9/6/12 3:37 PM
On 6 Sep 2012, at 15:36, Yury Sulsky <yury....@gmail.com> wrote:

On Thu, Sep 6, 2012 at 6:25 PM, Anil Madhavapeddy <an...@recoil.org> wrote:
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).

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).

Oh! A warning that actually is an error ;-)

-anil
Re: type_conv/ocaml4 release Markus 9/6/12 3:42 PM
On Thursday, September 6, 2012, Anil Madhavapeddy wrote:
The warnings are due to unused variables,

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
On 6 Sep 2012, at 15:42, Markus Mottl <markus...@gmail.com> wrote:

On Thursday, September 6, 2012, Anil Madhavapeddy wrote:
The warnings are due to unused variables,

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.

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).

-anil
Re: type_conv/ocaml4 release Yury 9/6/12 3:55 PM
Hi Markus,

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!

-anil
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:
> 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?
> https://bitbucket.org/yminsky/ocaml-core-submissions

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
accepted, from:

  https://bitbucket.org/mmottl/ocaml-core-submissions

You may want to read up on Bitbucket patch queues if you want to learn
how to merge and apply them:

  http://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org
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
Hi Anil,

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?

Thanks,
Yury
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).

-anil
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.

y
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
*/{myocamlbuild,setup}.ml

Yury
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:

Async_core:
(** [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.

-anil
Re: type_conv/ocaml4 release Anil Madhavapeddy 9/7/12 6:19 PM
Stream of notes here:

- Compiles on the Mac, hurrah!  Compiling my little HTTP library against it, and I notice:

Async_core:
(** [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.

-anil



On 7 Sep 2012, at 17:43, Anil Madhavapeddy <an...@recoil.org> wrote:


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:
> Stream of notes here:
>
> - Compiles on the Mac, hurrah!  Compiling my little HTTP library against it,
>   and I notice:

Great.

> Async_core:
> (** [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.

Thanks.  Will fix!

> - 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))] *)

Will fix!

> - 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...

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...

> - 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.

Where specifically?  As I said, our internal tree doesn't use GADTs,
since everything must compile against 3.12.1 to get through our
compile daemon.

> - I like the new TCP.Where_to_listen use of GADTs. It's a much more
>   self-documenting interface than before!

The version I'm looking at doesn't require GADTs, so again, I'm
confused.
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:

>>
>> - 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.
>
> Where specifically?  As I said, our internal tree doesn't use GADTs,
> since everything must compile against 3.12.1 to get through our
> compile daemon.
>
>> - I like the new TCP.Where_to_listen use of GADTs. It's a much more
>>  self-documenting interface than before!
>
> The version I'm looking at doesn't require GADTs, so again, I'm
> confused.

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...

-anil
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.

Yury
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.

-anil
More topics »