| Anonymous | Login | Signup for a new account | 2017-09-21 21:35 CEST |  |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |||
| 0006285 | OCaml | standard library | public | 2014-01-02 01:57 | 2016-12-07 11:47 | |||
| Reporter | gfxmonk | |||||||
| Assigned To | dim | |||||||
| Priority | normal | Severity | feature | Reproducibility | always | |||
| Status | closed | Resolution | fixed | |||||
| Platform | x86_64 | OS | Linux | OS Version | ||||
| Product Version | 4.01.0 | |||||||
| Target Version | Fixed in Version | 4.03.0+dev / +beta1 | ||||||
| Summary | 0006285: Unix st_mtime has only second-level resolution | |||||||
| Description | stat.c (in the `unix` module) uses the old second-level precision data attributes of linux `stat` results: https://github.com/ocaml/ocaml/blob/trunk/otherlibs/unix/stat.c#L46 [^] It should use the newer, subsecond-precision attributes where available. Jane Street Core does this: https://github.com/janestreet/core/blob/master/lib/unix_stubs.c#L426 [^] | |||||||
| Steps To Reproduce | The following script always prints a whole number for `mtime`, despite other programs on the same machine/OS accessing sub-second resolution for `mtime` (e.g python): #!/usr/bin/env ocamlscript Ocaml.packs := ["unix"] -- open Unix open Printf let () = let this_file = Array.get Sys.argv 0 in let stats = Unix.stat this_file in printf "mtime: %f" stats.st_mtime | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0011683) xleroy (administrator) 2014-06-05 17:33 |
I'm putting this as a feature wish, because it is. Yes, it would be a nice touch to support subsecond resolution here. I am concerned about the three different ways to access the nanosecond parts: a solid configure-time test is needed here, because Jane Street's code seems to assume either Linux, MacOS X, or BSD, but nothing else. I am also surprised at the "1000000000.0f" constant in their code. By forcing computation to single precision, rounding errors become much larger (up to 1.1 ns instead of 6e-8 ns for double precision). Not that it matters much, but as a floating-point nit-picker I *had* to point it out. |
|
(0013377) dim (developer) 2015-03-04 11:39 |
We added a configure-time test for this in core a few month ago. I wrote a patch for OCaml: https://github.com/ocaml/ocaml/pull/148 [^] Without the single precision constant... |
|
(0013384) dim (developer) 2015-03-05 12:11 |
Committed in trunk: 15877. |
|
(0013441) dim (developer) 2015-03-11 13:54 |
Committed in 4.02: 15894 |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2014-01-02 01:57 | gfxmonk | New Issue | |
| 2014-05-30 15:25 | shinwell | Status | new => confirmed |
| 2014-06-05 17:33 | xleroy | Note Added: 0011683 | |
| 2014-06-05 17:33 | xleroy | Severity | minor => feature |
| 2015-03-04 11:36 | dim | Assigned To | => dim |
| 2015-03-04 11:36 | dim | Status | confirmed => assigned |
| 2015-03-04 11:39 | dim | Note Added: 0013377 | |
| 2015-03-05 12:11 | dim | Note Added: 0013384 | |
| 2015-03-05 12:39 | dim | Status | assigned => resolved |
| 2015-03-05 12:39 | dim | Fixed in Version | => 4.03.0+dev / +beta1 |
| 2015-03-05 12:39 | dim | Resolution | open => fixed |
| 2015-03-11 13:54 | dim | Note Added: 0013441 | |
| 2016-12-07 11:47 | xleroy | Status | resolved => closed |
| 2017-02-23 16:43 | doligez | Category | OCaml standard library => standard library |
|
Issue History |
| Copyright © 2000 - 2011 MantisBT Group |
 |