Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006139OCamlOCaml otherlibspublic2013-08-26 17:552014-09-23 17:32
Reporteravsm 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target Version4.03.0+devFixed in Version 
Summary0006139: reversing the Unix and Bigarray dependency
DescriptionWith the splitting out otherlibs/ from the compiler distribution, I wanted to also see if we could remove the hard dependency on the Unix library from Bigarray. Currently, there is just one function (map_file) which causes Bigarray to depend on Unix.

Bigarray is increasingly used in the more exotic backends (js_of_ocaml, Mirage, ocamljava) as a convenient way to access externally allocated memory safely and fast. It would therefore make compilation much easier if the map_file were moved into the Unix module, thus introducing a Unix->Bigarray dependency rather than Bigarray->Unix. It's hard to override Bigarray via package management as it's installed in the standard library area and therefore picked up by default unless overridden for every case where it's used.

I'm happy to come up with a patch if there's general agreement that is a good idea. I can't see how not to break the existing interface, although telling people who to switch their existing use should be quite easy.

(two concrete reason I want this is to purge the last of POSIX from Mirage/Xen, which uses Bigarray, and also to more easily compile Core to Javascript for an interactive Real World OCaml toplevel).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0010239)
frisch (developer)
2013-08-26 18:03

I'd actually argue for making Bigarray part of the stdlib. AFAIK, it is supported on all platforms (at least for the core features, I'm unsure about map_file, precisely) and it has a special status w.r.t. the compiler (syntax and optimizations).
(0010240)
avsm (reporter)
2013-08-26 18:07

Putting it in base, sans map_file, would be great. It's been very easy to port to all kinds of embedded platforms (as long as they have a malloc), and it has win32 support.
(0010243)
dbuenzli (reporter)
2013-08-27 10:39

FWIW I'd also like to have them in the stdlib. I did sometimes avoid them at legitimate places because of their special status (namely sources/destinations for codecs, though in the current state it would still be hard to support an *efficient* interface that allows to e.g. source from either an in_channel, a string or a bigarray).
(0010245)
doligez (administrator)
2013-08-28 11:05

If you want to maintain compatibility at all costs, you can rename your new version of the Bigarray module to something like Bigarray_core, then make a new Bigarray that just reexports all the functions plus map_file.
(0010583)
johnwhitington (reporter)
2013-11-04 16:58

Can I add my voice to the calls for reversing the dependency and putting Bigarray into the stdlib? It would be very useful.

Not really a strong argument, but recall that Bigarray has special syntax even without loading bigarray.cma:

$ ocaml
        OCaml version 4.01.0
# Bigarray.Array1.create;;
Error: Reference to undefined global `Bigarray'
# let x = 0;;
val x : int = 0
# x.{2};;
Error: This expression has type int but an expression was expected of type
         ('a, 'b, 'c) Bigarray.Array1.t

So in some sense, it's already in the stdlib.
(0010594)
frisch (developer)
2013-11-06 14:27

> If you want to maintain compatibility at all costs, you can rename your new
> version of the Bigarray module to something like Bigarray_core, then make a new
> Bigarray that just reexports all the functions plus map_file.

What's the opinion of other proponents of the integration of Bigarray into stdlib? My preference would be to simply move the map_file functions into Unix (and not provide a compatibility module). It requires to fix client code, but the required change is trivial.
(0010595)
avsm (reporter)
2013-11-06 15:11

Yes, I'd prefer the simpler approach of moving Bigarray into the stdlib, and the map_file function into Unix. I'm happy to help fix up the resulting problems with an OPAM bulk build over the 4.2 release cycle.
(0010596)
dbuenzli (reporter)
2013-11-06 15:40

Also in favour of the last two comments. Let's put OCaml's type system and ocamlot to good use.
(0011401)
dbuenzli (reporter)
2014-05-08 11:17

Has this a chance of occurring for 4.02 ?

- Issue History
Date Modified Username Field Change
2013-08-26 17:55 avsm New Issue
2013-08-26 18:03 frisch Note Added: 0010239
2013-08-26 18:07 avsm Note Added: 0010240
2013-08-27 10:39 dbuenzli Note Added: 0010243
2013-08-28 11:05 doligez Note Added: 0010245
2013-08-28 11:05 doligez Status new => acknowledged
2013-08-28 11:05 doligez Target Version => 4.02.0+dev
2013-11-04 16:58 johnwhitington Note Added: 0010583
2013-11-06 14:27 frisch Note Added: 0010594
2013-11-06 15:11 avsm Note Added: 0010595
2013-11-06 15:40 dbuenzli Note Added: 0010596
2014-05-08 11:17 dbuenzli Note Added: 0011401
2014-08-18 15:09 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-23 17:32 doligez Target Version undecided => 4.03.0+dev


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker