On Sunday, June 08, 2014 01:16:51 PM Michael Hatherly wrote:
> Since everything in help is in Base as
> well, it doesn't seem to be a problem currently.

Actually, the help system does take the module into account (I believe Carlo 
Baldassi implemented this):

 help> Base.print
Base.print(x)

   Write (to the default output stream) a canonical (un-decorated)
   text representation of a value if there is one, otherwise call
   "show". The representation used by "print" includes minimal
   formatting and tries to avoid Julia-specific details.

 help> Profile.print
Base.Profile.print([io::IO = STDOUT], [data::Vector]; format = :tree, C = 
false, combine = true, cols = tty_cols())

   Prints profiling results to "io" (by default, "STDOUT"). If you
   do not supply a "data" vector, the internal buffer of accumulated
   backtraces will be used.  "format" can be ":tree" or ":flat".
   If "C==true", backtraces from C and Fortran code are shown.
   "combine==true" merges instruction pointers that correspond to
   the same line of code.  "cols" controls the width of the display.

Base.Profile.print([io::IO = STDOUT], data::Vector, lidict::Dict; format = 
:tree, combine = true, cols = tty_cols())

   Prints profiling results to "io". This variant is used to examine
   results exported by a previous call to "Profile.retrieve()".
   Supply the vector "data" of backtraces and a dictionary
   "lidict" of line information.


> I'll take another look
> when I get a chance.
> 
> [1] https://github.com/JuliaLang/julia/blob/master/base/help.jl#L102
> 
> On Sunday, 8 June 2014 21:32:36 UTC+2, Tim Holy wrote:
> > I agree with Daniel. We just need _something_, and on this issue the
> > diversity
> > of tastes seems to make consensus impossible. So kudos to you. I really
> > hope
> > this keeps moving forward.
> > 
> > What prevents it from working with functions rather than strings?
> > 
> > --Tim
> > 
> > On Saturday, June 07, 2014 02:16:11 PM Daniel Jones wrote:
> > > A good way of documenting packages is one of the biggest gaps in the
> > > julia ecosystem right now. Part of the reason why is evinced in the
> > > issues you cite: no matter what the system is, someone is going to hate
> > > it. At this point, I'm sort of hoping someone will just ignore all
> > > feedback and build whatever they want.
> > > 
> > > 
> > > 
> > > That said, I think this is a pretty elegant solution. Just relying on
> > > markdown h1 and h2 headers leaves open the possibility of generating
> > > html documentation from the same source. That's something I appreciate,
> > > since I'd also want to generate html docs with example plots rendered
> > > for gadfly.
> > > 
> > > 
> > > 
> > > With Jake Bolewski's julia parser, I hope it will become easier to
> > > extract documentation from source code, either from comments or
> > > something like docstrings. Have you given any though to that?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Thu, Jun 5, 2014, at 03:13 PM, Michael Hatherly wrote:
> > > 
> > > Hi all,
> > > 
> > > 
> > > 
> > > I've just put up a rough prototype for package documentation at
> > > [1]https://github.com/MichaelHatherly/Docile.jl. This is not meant to
> > > be a solution to the documentation problem, but rather to start some
> > > fresh discussion on the matter.
> > > 
> > > 
> > > 
> > > Any feedback would be great. There's more details in the readme.
> > > 
> > > 
> > > 
> > > Regards,
> > > 
> > > Mike
> > > 
> > > References
> > > 
> > > 1. https://github.com/MichaelHatherly/Docile.jl

Reply via email to