Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate Bigarray documentation #1779

Merged
merged 1 commit into from May 14, 2018

Conversation

Projects
None yet
5 participants
@pmetzger
Copy link
Member

pmetzger commented May 9, 2018

As requested by @Octachron. Should help #1708, should close #1744

  1. Add Bigarray lines to library/stdlib.etex
  2. Move intro from libbigarray.etex to stdlib/bigarray.mli
  3. Note that 0-dimensional arrays are supported.
  4. Move C interface description to cmds/intf-c.etex
  5. Change wording in libbigarray.etex to reflect legacy status.
  6. Add a label to libunix.etex (needed for link from libbigarray.etex)
  7. Put the changes in Changes (for 4.07).

Still to do in the future: move the Bigarray syntax information from Extensions into the main manual, and add a Bigarray tutorial.

@pmetzger

This comment has been minimized.

Copy link
Member Author

pmetzger commented May 9, 2018

I note Travis failed for want of a Changes entry. Can this just be folded into the previous Changes entry for the Bigarray integration?

@Octachron

This comment has been minimized.

Copy link
Contributor

Octachron commented May 10, 2018

I think it would be cleaner in this case to have your own change entry, in the documentation and manual section for 4.07 .

arrays are as follows:
- Big arrays are not limited in size, unlike OCaml arrays.
(Normal float arrays are limited to 2,097,151 elements on a 32-bit
platform, and normal arrays of other types to 4,1943,03 elements.)

This comment has been minimized.

@xclerc

xclerc May 10, 2018

Contributor

The comma separators are non-SI (4,1943,03).

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

That was a mistake. Good catch. I'll fix it.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Wait, did you mean the mistaken position of the separators, or the existence of the separators.

This comment has been minimized.

@xclerc

xclerc May 10, 2018

Contributor

Sorry, SI was probably misleading; I meant the position of the separators.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

I've fixed that.

(Normal float arrays are limited to 2,097,151 elements on a 32-bit
platform, and normal arrays of other types to 4,1943,03 elements.)
- Big arrays are multi-dimensional. Any number of dimensions
between 1 and 16 is supported. In contrast, OCaml arrays

This comment has been minimized.

@xclerc

xclerc May 10, 2018

Contributor

It is probably "between 0 and 16".

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Is it actually 0? Note I took this from previous documentation.

This comment has been minimized.

@xclerc

xclerc May 10, 2018

Contributor

I guess the documentation was not updated when Array0
was introduced -- see here.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

I will make this fix and push it.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Pushed.

@pmetzger pmetzger force-pushed the pmetzger:bigardocfix branch 2 times, most recently from 69007a0 to cb5646a May 10, 2018

@pmetzger

This comment has been minimized.

Copy link
Member Author

pmetzger commented May 10, 2018

@Octachron:

I think it would be cleaner in this case to have your own change entry, in the documentation and manual section for 4.07 .

Fixed. Please let me know if it's okay.

Changes Outdated
@@ -365,6 +365,9 @@ OCaml 4.07

### Manual and documentation:

- PR#1779: integrate the Bigarray documentation into the main manual.
(Perry E. Metzger, review by Florian Angeletti and Xavier Clerc)

This comment has been minimized.

@Octachron

Octachron May 10, 2018

Contributor

Could you move the entry at the end of the section to keep the entries relatively sorted (the order is descirbed in CONTRIBUTING.md) and use GPR#1779 rather than PR#1779 (the convention being G for github and M for mantis) ?

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Will do. Please note the section I'm changing has LOTS of things that are labeled just "PR#" so you might look at fixing them.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

(It also has some things that are clearly out of this order. Will push a fix for my own entry in a couple of moments.)

This comment has been minimized.

@gasche

gasche May 10, 2018

Member

I do global reordering passes on a regular basis, but it's always nicer when things are ordered from boot -- it reduces the number of Changes-related conflicts, for example.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Done!

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

@gasche you might want to do a PR -> GPR pass earlier rather than later. I got the notion that PR from context. :(

@pmetzger pmetzger force-pushed the pmetzger:bigardocfix branch from cb5646a to 1b739c4 May 10, 2018


The "bigarray" functionality may now be found in the standard library
"Bigarray" module, except for the "map_file" function which is now
part of the "Unix" module. The documentation has been integrated into

This comment has been minimized.

@Octachron

Octachron May 10, 2018

Contributor

"Unix" library might be more precise and avoid some confusion. (and ideally it might be nice to add a label to the library description and link to it).

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Will change it to library.

I don't know how to add such a label and link (hevea is not my area of expertise), but if you tell me how, I will do it.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

It now says "Unix" library. If you can tell me the rest of the magic for linking etc. I'll add it.

This comment has been minimized.

@Octachron

Octachron May 10, 2018

Contributor

First, it would require to add a label to libunix.etex: label{c:unix} just after the hevea cutname, then it should be possible to add a link by replacing "Unix" with \ahrefloc{c:unix}{Unix}.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Is there a good way to hyperlink the Bigarray library document itself? It clearly has to be different since that file is generated by ocamldoc.

This comment has been minimized.

@Octachron

Octachron May 10, 2018

Contributor

For linking to a generated API documentation, you can use \ahref{url}{name} in a html only section and a reference on the latex side ((see \ref{Bigarray} should link to the stdlib Bigarray module).

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member
! Undefined control sequence.
l.12 part of the \ahrefloc
                          {c:unix}{Unix library}. The documentation has

This comment has been minimized.

@Octachron

Octachron May 10, 2018

Contributor

Like I said above, \hyperref[ref]{text} works.

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

The manual clearly explains this is a real thing, see http://hevea.inria.fr/doc/manual018.html#hevea_default59

And yet, it doesn't work?

This comment has been minimized.

@pmetzger

pmetzger May 10, 2018

Author Member

Okay, I figured it out. Latest version should link the legacy description properly both to the Unix library chapter and to the libref docs for Bigarray.

@pmetzger pmetzger force-pushed the pmetzger:bigardocfix branch from 1b739c4 to 35afdc2 May 10, 2018

Integrate Bigarray documentation
1. Add Bigarray lines to library/stdlib.etex
2. Move intro from libbigarray.etex to stdlib/bigarray.mli
3. Note that 0-dimensional arrays are supported.
4. Move C interface description to cmds/intf-c.etex
5. Change wording in libbigarray.etex to reflect legacy status.
6. Add a label to libunix.etex (needed for link from libbigarray.etex)
7. Put the changes in Changes (for 4.07).

@pmetzger pmetzger force-pushed the pmetzger:bigardocfix branch from 35afdc2 to 1a412be May 10, 2018

@Octachron

This comment has been minimized.

Copy link
Contributor

Octachron commented May 11, 2018

As far as I am concerned, this is good to merge in 4.07 since it makes the integration of Bigarray into the standard library very explicit.

@gasche , @diml , do you wish to review this PR or should I go ahead with the merge?

@gasche

This comment has been minimized.

Copy link
Member

gasche commented May 11, 2018

I don't have time to review, sorry, but I trust your judgment here, feel free to go ahead.

@diml

This comment has been minimized.

Copy link
Member

diml commented May 12, 2018

Same here. Thanks @pmetzger for the PR and @xclerc and @Octachron for the review.

@gasche gasche merged commit 83b0ee1 into ocaml:trunk May 14, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

gasche added a commit that referenced this pull request May 14, 2018

Merge pull request #1779 from pmetzger/bigardocfix
Integrate Bigarray documentation

(cherry picked from commit 83b0ee1)

@pmetzger pmetzger deleted the pmetzger:bigardocfix branch May 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.