|Anonymous | Login | Signup for a new account||2018-12-13 02:13 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006139||OCaml||otherlibs||public||2013-08-26 17:55||2018-04-09 16:37|
|Target Version||later||Fixed in Version||4.07.0+dev/beta2/rc1/rc2|
|Summary||0006139: reversing the Unix and Bigarray dependency|
|Description||With 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.
|Tags||No tags attached.|
|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).|
|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.|
|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).|
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.
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 version 4.01.0
Error: Reference to undefined global `Bigarray'
# let x = 0;;
val x : int = 0
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.
> 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.
|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.|
|Also in favour of the last two comments. Let's put OCaml's type system and ocamlot to good use.|
|Has this a chance of occurring for 4.02 ?|
|Was consensus reached on this? It would be a useful improvement.|
|I don't think there has been any more discussion on this. Probably not for 4.03.|
|There is now a GPR https://github.com/ocaml/ocaml/pull/997 [^]|
|And another one here https://github.com/ocaml/ocaml/pull/1077 [^]|
|Solved by merging https://github.com/ocaml/ocaml/pull/1685 [^]|
|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 / +beta1|
|2015-06-15 17:29||doligez||Relationship added||related to 0006885|
|2015-12-03 13:35||frisch||Target Version||4.03.0+dev / +beta1 => later|
|2015-12-18 22:16||johnwhitington||Note Added: 0015177|
|2015-12-24 15:01||frisch||Note Added: 0015191|
|2017-01-05 20:54||dbuenzli||Note Added: 0017079|
|2017-02-23 16:42||doligez||Category||OCaml otherlibs => otherlibs|
|2017-03-03 17:06||dbuenzli||Note Added: 0017559|
|2017-03-07 14:23||frisch||Severity||minor => feature|
|2018-04-09 16:37||gasche||Note Added: 0018995|
|2018-04-09 16:37||gasche||Status||acknowledged => resolved|
|2018-04-09 16:37||gasche||Fixed in Version||=> 4.07.0+dev/beta2/rc1/rc2|
|2018-04-09 16:37||gasche||Resolution||open => fixed|
|2018-04-09 16:37||gasche||Assigned To||=> gasche|
|Copyright © 2000 - 2011 MantisBT Group|