So it does :) I'll have a closer look soon.

On Sunday, 8 June 2014 22:29:13 UTC+2, Tim Holy wrote:
>
> 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