Coming from an R background, and just started learning Julia, I wonder how's documentation in Julia, and if there are analogues to R's help pages and vignettes.
Furthermore, in R, one can document functions using roxygen comment blocks, is there also something similar in Julia?
I think it is best to understand how things work by example. I will comment on how DataFrames.jl is documented as this is a pretty standard approach:
Functions are documented using docstrings, here is an example of a docstring of function names; These docstrings are then discoverable interactively via help system (by pressing ?)
A standard way to generate a documentation for a package is to use Documenter.jl; by the way: the package has a great team of maintainers who are very helpful and responsive; here you have a link to the make.jl file that is executed to generate the documentation; note in particular the option doctest=true which makes sure that all code examples that are properly anoteted following Documenter.jl rules are producing an expected output
In order to set-up auto-generation of package documentation you need to set up CI integration on GitHub; again - there are many ways to do it; a standard one is to use GitHub Actions; here you have a link to the part of the ci.yml specification file that ensures that documentation is built as a part of CI; then in any PR, e.g. this one (I am giving a link to a currently open PR that is documentation related) you can see in the section reporting CI results that after running tests also documentation was generated. Here you can see how a documentation generated using this toolchain looks like (e.g. note that at the bottom you can switch the version of the package you want to read manual of dynamically which shows you that all here is really well integrated - not just a bunch of PDF or HTML files).
I hope this will help you to get started. I have pointed you to all essential pieces that are normally used by packages hosted on GitHub (i.e. this is not the only way to do it, but it is a standard way most commonly used).
To master all the details of the above you need to read the documentation in the Julia Manual and Documenter.jl carefully. Unfortunately writing a proper documentation is not easy (in any programming language). The good thing is that Julia has a really excellent toolchain that supports this process very well.
Related
I want to create a product/project documentation in R that is going to be reviewed and discussed by a group of reviews. There are plenty of examples of how to create book-like documents using Rmarkdown (e.g. https://bookdown.org/) or interactive data visualizations using R-shiny. However, I could not find any solution for user comments similar to LibreOffice Writer, MS Word, or Google Docs. I could also imagine having a split-pane where one side is dedicated to the content presentation (e.g. text, graphs, code), while the other side is left for comments.
I am aware that such a solution requires a server-side solution for storing comments.
Any hints on existing solutions, workarounds, and implementations are welcome.
If I correctly understood, your question isn't very R specific. R is just code, R files are just text and they don't allow comments (beside the raw hashtag comments) and reviews. Your question is more about version control environments, that allow reviews on code stuff. The most used version control system is git, and git has an integrated panel in RStudio.
Git allows you to split your developpements in branches, which are the different ideas you and your coworkers can work on independentely. Once an idea is finalised, after some consecutive modifications known as commits, it is to be asked for merge in the "main branch". It is a "pull request".
That is where the different platform using git, like GitHub or GitLab, allow some review systems. Basically, when a branch is done, you ask "is that ok ?". Your reviewer can see the changes, can try you things, and tell if that is actually ok.
The other advantage of these is the continuous integration, that is : elaborating tests (in R with testthat) that will be tested on some events merge, like "on each merge to master". It is meant to ensure that the software is going forward : if a merge breaks some earlier test, you'll know it.
For beginners, in order to avoid being lost in bash commands, GitHub Desktop is a fine GUI above Git.
Note : You can also rely on the package usethis which has a few helper functions like use_git, use_gitlab_ci, use_github_action... It's not specific to reviews and comments but to the gitlab and github integration
When I look at documentation for R packages, it often comes in a PDF document like this:
https://cran.r-project.org/web/packages/glmnet/glmnet.pdf
Does that document have a name?
Normally I find these documents by searching on the web, but I wonder if I can also produce them using some R command like library(help=...) or vignette(...). However, this answer makes it sound somewhat complicated, like I have to compile the package myself and run R CMD Rd2pdf, is that correct?
Also, as a prospective package author, I could imagine having this PDF document serve as the primary documentation for my package. The only obstacle is that when I read these documents, the documented functions always seem to appear in alphabetical order. Is there a way to put the most important functions first, so that the document can be read straight through (rather than just as a reference)? Or is there another documentation format which will let me document things in a certain order?
The reference manual is just a collection of the help pages. They should be written as reference material, which is probably not the first place a user should look for documentation, if that's what you mean by "primary documentation".
The first place users should look is for a vignette which provides an overview of the package. It can be displayed in HTML or PDF (it's up to the package author to choose). Since it is free-form, you can document things in a logical order, you aren't restricted to the alphabetical order of the reference manual.
It's also optional, and I use it as a measure of quality of a package that I'm investigating: if they don't have such a vignette, the authors don't really care about providing good documentation.
I'm using openapi-generator for jersey-jaxrs (OpenAPI 3.0). I'd like to control the package where my code is being generated.
I'm setting the api-package, model-package, package-name, and invoker-package options, all to a xxx.yyy.zzz value.
My problem is that most of the code is generated under gen.xxx.yyy.zzz, and it's not discoverable by the part of the code generated under xxx.yyy.zzz. Implicitly, gen is prepended to the package name. I understand this is convenient in many cases, but not mine. Is there any generator option to avoid this?
I've learned a bit about the Mustache templates and they seem like a possible solution, but maybe a bit too much for my requirements.
Ultimately, I can move the code in gen to the other (non-gen) package manually, and it works, but this is quite inconvenient.
Finally, I found out that you can mark folders in IntelliJ IDEA as "generated sources root", which makes it discoverable to the rest of the project's code.
This doesn't solve my question, but it does solve the problem that originated the question.
I'd like to use the xref information from a GPS Ada project to generate lists of the variables defined for each package spec and body. I need to exclude any variables defined inside of subprograms.
I can see this information in GPS's "Project View" which shows the literals, package, pragmas, types, and variables defined in each file. However, the information is not selectable for cut/paste. How do I generate this in text form?
GPS is customised using Python. The provided scripts are in {installation}/share/gps/library; it looks as though unused_entities.py might be a good start. Or, there's a chapter on "Customizing and Extending GPS" in the GPS documentation.
[Edit]
Or, even better, look at the example globals.py in {installation}/share/examples/gps/python. A quick poke through the documentation (accessed in GPS via Help/Python extensions) suggests you're looking for GPS.Entities e where e.category() is "object".
Since you mention GPS, have you tried Tools->Documentation->Generate project?
This will generate html, with hyperlinks etc, similar to Javadoc.
SciTools' Understand product can extract this information, although it's rather pricey. Though if you're working with a mound of legacy code, it's well worth the money--it has saved my bacon on more than one occasion.
I have several custom functions that I use frequently in R. Rather than souce this file (or parts thereof) in each script, is there some way to add this to a base R file such that they are always available when I use R?
Yes, create a package. There are numerous tutorials as well as the Writing R Extensions manual that came with your copy of R.
It may seem like too much work at first, but you will probably be glad that you did this in the longer run.
PS And you can then load that package from ~/.Rprofile. For really short code, you can also define it there.
A package may be overkill for a for a few useful functions. I'd argue there's nothing wrong with explicitly source()ing them as you need them - at least it is explicit so that if you email someone your code, you won't forget to include those other scripts.
Another option is to use the .Rprofile file. You can read about the details in ?Startup. Basically, the idea is that:
...a file called ‘.Rprofile’ is searched for in the current directory or
in the user's home directory (in that order). The user profile file is
sourced into the workspace.
You can read here about how many people use this functionality.
The accepted answer is best long-term: Make a package.
Luckily, the learning curve for doing this has been dramatically reduced by the devtools package: It automates package creation (a nice assist in getting off on the right foot), encourages good practices (like documenting with roxygen2, and helps with using online version control (bitbucket, github or other), sharing your package with others. It's also very helpful for smoothing your way to CRAN submission.
Good docs at http://adv-r.had.co.nz and http://r-pkgs.had.co.nz .
to create your package, for instance you can:
install.packages("devtools")
devtools::create("path/to/package/pkgname")
You could also look at the 'mvbutils' package: it lets you set up a hierarchical set of "tasks" (folders with workspace ".RData" files in them) such that you can always see what's in the ancestral tasks (ie the ancestors are in the search() path). So you can put your custom functions in the "starting task" where you always start R; and then you change to vwhatever project-specific task you require, so you can avoid cluttered workspaces, but you'll still be able to use (and edit) your custom functions because the starting task is always ancestral. Objects (including functions) get stored in ".RData" files and are thus loaded/saved automatically, but there are separate text-backup facilities for functions.
There are lots of different ways of working in R, and no "one-size-fits-all" best solution. It's also not easy to find an overview! Speaking just for myself:
I'm not a fan of having to 'source' everything in every time; for one thing, it simply doesn't work with big data sets and/or results of model runs.
I think packages are hard to create and maintain; there is a really significant overhead. After the first 5 packages you write, it does get a bit easier provided you do it on at least a weekly basis so you don't forget how, but really...
In fact, 'mvbutils' also has a bunch of tools for facilitating the creation and (especially) maintenance of packages, designed to interface smoothly with the task-hierarchy system. I use & edit my own packages all the time (including editing mvbutils itself); but if it wasn't for the tools in 'mvbutils', I'd be grinding my teeth in frustration most days of the week.