The Julia REPL comes with a default help mode which you can access by doing ? in the terminal. However, I saw someone mention the # Extended help and how package developers can use that header to write longer doc strings which are hidden from the usual ? help response. How do I access this extended help section?
Julia's extended help section can be accessed by doing something like ??Print rather than ?Print in the REPL. Again, as aforementioned, this will display the extended examples section.
It is worth noting that not every function nor every package take advantage of this. It is best to check the source file's to see if the # Extended help feature is enabled for a particular package.
Related
In argparse you provide help alongside the definition of the argument. This helps keep the doc up-to-date with the args.
Is there an option to do something similar in Hydra? Or some other preferred way for documenting the options, without having to list them manually within the hydra/help message?
Edit: this becomes an even greater problem when using call/instantiate and the config options depend on the code.
Right now we recommend using hydra/help. We do have a feature request, feel free to follow/contribute to the discussions here https://github.com/facebookresearch/hydra/issues/633.
Thanks!
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.
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 have a UBE that is failing after making a call to a jdeObjectCall. The API returns a 1, indicating a warning, which indicates to the report to stop processing.
The image below shows the jdeObjectCall in question that is returning a 1.
I'd like to determine why jdeObjectCall is returning a warning, so that I can investigate a fix.
Any help on this is greatly appreciated!
Cheers, Cam.
I was able to determine the answer to this question with some help from the forum jdelist.com. The topic in which I discovered my answer can be found here: https://www.jdelist.com/vb4/showthread.php/53758-E1920-Debugging-jdeObjectCall
The way I found my solution is as follows. Apologies for the high-level steps. There is some assumed knowledge here. If you are interested in a more in-depth explanation of one of these items please comment and I will provide it.
Enable logging in the jde.ini file.
Debug the locally.
Examine the output of the log file using a tool like JDETrace.
You can do a search for your business function within JDETrace. In my case, I searched for EditDate.
The line in the log will let you know the name of the busines function object.
Checkout the object in object management workbench.
Find the line where the EditDate function exists.
Place a breakpoint on this line and continue debugging.
Rstudio has a great code completion feature. It provides a quick view of functions that start with a given string, as well as function and parameter definitions.
ESS is powerful enough, familiar to me, and integrated into Emacs, where I conduct most of my work - so I am hesitant to move, but this feature is making me consider such a move.
Is it possible to integrate this feature into Emacs ESS?
Is there anything similar to this for Emacs ESS?
Any hope that there will be (and if so, how could I support such an effort?)
You do get the completion thanks to the rcompgen package by Deepayan (now "promoted" into base R as part of the utils package). So when I type
lm(
and hit TAB a new buffer opens which gets me the left-hand side of your window above: the available options to the function at hand. I don't think you can show the help directly though.
There is / was also a way to get context-sensitive help in the mini-buffer when typing but I have forgottten how/where that gets turned on.
[EDIT: This is an old answer and auto-complete package dropped out of fashion since then. Please use company-mode instead. It should work by default. Wiki configuration entry is here.]
Recent versions of ESS (> v.12.02) integrate with auto-complete package out of the box (you need not configure anything, just install auto-complete). It provides help on arguments as well as function help. I added detailed instructions to the wiki
Ess-eldoc was also rewritten and from v.12.02 it's active by default, so you don't need to configure anything.
Or maybe we should all use search:
Emacs autocomplete-mode extension for ESS and R
I don't want to be grumpy, I found this few hours ago and I'm still shocked. It works like a charm. Though I still prefer the old-style pop-ups. =)