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

decide where documentation should live #720

Closed
JeffBezanson opened this issue Apr 15, 2012 · 15 comments
Closed

decide where documentation should live #720

JeffBezanson opened this issue Apr 15, 2012 · 15 comments
Labels
domain:docs This change adds or pertains to documentation needs decision A decision on this change is needed

Comments

@JeffBezanson
Copy link
Sponsor Member

Consensus seems to be that the current approach is not optimal. I'm leaning towards the idea of maintaining docs in the master repo under doc/ much like how test/ is there now. This will provide better development workflow and easier offline browsing.

An example approach from @nolta: http:https://readthedocs.org/docs/julia-test/en/latest/

@nolta
Copy link
Member

nolta commented Apr 15, 2012

@pao
Copy link
Member

pao commented Apr 15, 2012

Will we also establish policy for required documentation? It seems like a good idea.

@StefanKarpinski
Copy link
Sponsor Member

Will we also establish policy for required documentation? It seems like a good idea.

Can you elaborate on what you mean?

@pao
Copy link
Member

pao commented Apr 16, 2012

What needs to be documented where before commit/pull. It's related to the base vs. extras vs. examples discussion.

@StefanKarpinski
Copy link
Sponsor Member

Gotcha. Yeah, we should do that and then try to actually stick to it ;-)

@nolta
Copy link
Member

nolta commented Apr 20, 2012

I've updated the sphinx branch, importing the whole stdlib and modifying help() to pull from doc/ instead of the website.

Before:

julia> help("open")
Downloading help data...
open(file_name[, read, write, create, truncate, append])
  Open a file in a mode specified by five boolean arguments. The default is to open files for reading only. Returns a stream for accessing the file.

open(file_name[, mode])` - Alternate syntax for open, where a string-based mode specifier is used instead of the five booleans. The values of `mode` correspond to those from `fopen(3)` or Perl `open`, and are equivalent to setting the following boolean groups

After:

julia> help("open")
Loading help data...
open(file_name[, read, write, create, truncate, append])

   Open a file in a mode specified by five boolean arguments. The
   default is to open files for reading only. Returns a stream for
   accessing the file.

open(file_name[, mode])

   Alternate syntax for open, where a string-based mode specifier is
   used instead of the five booleans. The values of 'mode' correspond
   to those from 'fopen(3)' or Perl 'open', and are equivalent to
   setting the following boolean groups:

   +------+-----------------------------------+
   | r    | read                              |
   +------+-----------------------------------+
   | r+   | read, write                       |
   +------+-----------------------------------+
   | w    | write, create, truncate           |
   +------+-----------------------------------+
   | w+   | read, write, create, truncate     |
   +------+-----------------------------------+
   | a    | write, create, append             |
   +------+-----------------------------------+
   | a+   | read, write, create, append       |
   +------+-----------------------------------+

@StefanKarpinski
Copy link
Sponsor Member

This looks really nice.

@timholy
Copy link
Sponsor Member

timholy commented Apr 21, 2012

A huge step forward.

@timholy
Copy link
Sponsor Member

timholy commented Apr 21, 2012

One question: there are obviously a lot of undocumented functions even within the standard library, some of which are powerful but probably not for "newbie" usage (e.g., gen_cartesian_map). Is the thought that we'd get these into documented form, too? If so, would this pose any challenges in organizing the documentation?

@JeffBezanson
Copy link
Sponsor Member Author

Yeah, we should just merge this as soon as we're ready. Nice work, Mike.

I guess we could have a section for power user functions. "Documented undocumented functions" :)

@pao
Copy link
Member

pao commented Apr 21, 2012

I agree it would be best if no one has to start an "Undocumented Julia" blog, unlike a certain other technical computing language.

@nolta
Copy link
Member

nolta commented Apr 22, 2012

Thanks Stefan, Tim, & Jeff. I've tidied up the doc/ directory a bit, and i'm ready to merge when you are.

@timholy
Copy link
Sponsor Member

timholy commented Apr 26, 2012

Mike, certainly there are no objections to merging from me.

@pao pao mentioned this issue May 11, 2012
@JeffBezanson
Copy link
Sponsor Member Author

Let's merge it!

@nolta nolta closed this as completed in 403b0d1 May 18, 2012
@pao
Copy link
Member

pao commented May 19, 2012

Whoo!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:docs This change adds or pertains to documentation needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

5 participants