I would expect (doc Math/exp) to give me something but it doesn't.
Sure it's not a Clojure function, but still there should be some way to reach the documentation.
Closest thing that I can get is (javadoc Math).
I would prefer the actual doc from that page as a string:
static double exp(double a)
Returns Euler's number e raised to the power of a double value.
UPD: signature by reflection
Here's how I can get a signature:
(.toString (first (filter #(= (.getName %) "exp") (.getMethods Math))))
I'm hoping for a similar way to get the doc.
UPD: no doc by reflection
According question How to read Javadoc comments by reflection?,
it's not possible to get the doc by reflection.
I wonder if it's possible to re-use some of Eclipse code that does give access to docs.
Simply start typing the method name that you intend to use:
(java.lang.Math/exp)
and with the cursor on the "exp" , press M-.
See the CIDER docs for more related hotkeys https://cider.readthedocs.io/en/latest/interactive_programming/
If you also install "company-mode", then searching for the class you intend to use also gets easier via autocomplete.
Related
I'm using Eclipse with the OcaIDE-Plugin to write my ocaml-project.
I have written several ocaml-functions that I want to document (comment, return values and params).
I've created my documentation in the .ml-files like described in this link: http://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html
Here is an example of one function:
(** sorting tuples where first element is key *)
let my_comp x y = (*Some code*)
Unfortunately, my comments don't show up, when I press F2 at one of the functions, it only shows the name and the file it is contained.
When writing comments in an mli-file, it works as expected, but i also want to document "private" functions that are not accessible from the outside. Can I define functions in the mli, that are NOT accessible from the outside, just for the documentation?
How can I make Eclipse to show my documention?
Well, as you said, you would like to show the documentation but not export the function out of the module. That, sadly, won't work.
I guess OcaIDE can be considered as incomplete but it doesn't look like it's something people care about (I don't know a single person working on OcaIDE). If you like having autocompletion etc, maybe try to program with emacs and install merlin (look, I found the perfect post for you : here)
As for the suggestion of defining a function in the mli not accessible from the outside, it's completely opposed to why mli files are created, so don't expect that to be possible. ;-)
I hoped I've been able to help you.
With intellij idea, how do I find out what makes a variable be visible?
An example of when it is hard:
Suppose you look at class A, and you see a variable something. If you jump to source you see that it's defined in trait X. But you don't extend trait X directly. What do you extend, then, that makes this variable visible? If you have a deeply nested hierarchy, tracking can be hard.
Any recommendations or solutions?
EDIT: Please vote for the feature if you're interested: http://youtrack.jetbrains.com/issue/IDEA-124369
I don't think that IntelliJ IDEA has any shortcut for "finding what makes a variable visible".
However you can determine it using the "Find Usages" option (Alt + F7). For example:
import java.nio._
object TempObj extends App {
def func = 2
val p = file.Paths.get("some-path")
func
}
So Find Usages on "file", tells you that its from the Package "file" (in heading of the new Tab it also shows the complete package name, ex: Find Usages of java.nio.file in Project Files).
Whereas Find Usages on func will tell you that its a Method (And the Tab heading now says: Find Usages of func() in Project and Libraries)
So now in way you can determine, what exactly makes the variable visible. This also works for imports since it shows the package from which it is imported and you can then look for import of that packages.
I know of two almost-solutions to this problem.
Go-to-declaration, as you mentioned, solves this problem in the case of local variables.
More generally, the "find usages" feature gives you a neat little breakdown by type and file of different uses of the variable. From this you can see if it's involved in a static import.
It's not perfect, but with a moment's thought these two are generally sufficient to figure out what you want.
Use ctrl+b or F4 to jump to source code. Alternatively you can use ctrl+shift+a to get option/action. You can find shortcuts at http://gaerfield.github.io/ide-shortcuts/ as well. Hope it will help.
From what I understood you want to see the code that creates an Object you use, for instance Mystery someMystery;.
That gives you two options to populate someMystery:
someMystery = ... where ... is your code to populate
someMystery and if that is the case you should follow
that code (with ctrl+B as far as you need to) to the point where it
actually creates the Mystery object.
Use CDI to populate that object instance for you, in which case you should look into the CDI mechanism in order to see in what way the object instance is populated.
In either way IMO there is no way to know for sure if the someMystery instance is of some more concrete class than Mystery, because it is decided in runtime, not in compile time, so your next bet would be to run the program in debug and see what object goes into someMystery, although you are not guaranteed to get the same type of object every time.
PS. My answer is based entirely on my java understanding of the topic, can't say if it is valid for scala also.
This might not be exactly the answer you were hoping to get.
However, quoting yourself,
If you have a deeply nested hierarchy, tracking can be hard.
Have you considered using composition over inheritance? Perhaps this would remove the need for the feature you are looking for.
Deeply nested hierarchy doesn't sound good. I understand your pain about that.
When you override vals or defs there is a little circle next to the line number that shows where it is from even when it is from nested hierarchy. Hovering over vals with the command key down also shows you a little tooltip where it is from.
Does this help?
https://youtu.be/r3D9axSlBo8
if you want class, field or method to be visible, you need to implement them as public. If it was your question.
Let us say that I have a Matlab function and I change its signature (i.e. add parameter). As Matlab does not 'compile' is there an easy way to determine which other functions do not use the right signature (i.e. submits the additional parameter). I do not want to determine this at runtime (i.e. get an error message) or have to do text searches. Hope this makes sense. Any feedback would be very much appreciated. Many thanks.
If I understand you correctly, you want to change a function's signature and find all functions/scripts/classes that call it in the "old" way, and change it to the "new" way.
You also indicated you don't want to do it at runtime, or do text searches, but there is no way to detect "incorrect" calls at "parse-time", so I'm afraid these demands leave no option at all to detect old function calls...
What I would do in that case is temporarily add a few lines to the new function:
function myFunc(param1, param2, newParam) % <-- the NEW signature
if nargin == 2
clc, error('old call detected.'); end
and then run the main script/function/whatever in which this function resides. You'll get one error for each time something calls the function incorrectly, along with the error stack in the Matlab command window.
It is then a matter of clicking on the link in the bottom of the error stack, correct the function call, and repeat from the top until no more errors occur.
Don't forget to remove these lines when you're done, or better, replace the word error with warning just to capture anything that was missed.
Better yet: if you're on linux, a text search would be a matter of
$ grep -l 'myFunc(.*,.*); *.m'
which will list all the files having the "incorrect" call. That's not too difficult I'd say...You can probably do a similar thing with the standard windows search, but I can't test that right now.
This is more or less what the dependency report was invented for. Using that tool, you can find what functions/scripts call your altered function. Then it is just a question of manually inspecting every occurrence.
However, I'd advise to make your changes to the function signature such that backwards compatibility is maintained. You can do so by specifying default values for new parameters and/or issuing a warning in those scenarios. That way, your code will run, and you will get run-time hints of deprecated code (which is more or less a necessary evil in interpreted/dynamic languages).
For many dynamic languages (and MATLAB specifically) it is generally impossible to fully inspect the code without the interpreter executing the code. Just imagine the following piece of code:
x = magic(10);
In general, you'd say that the magic function is called. However, magic could map to a totally different function. This could be done in ways that are invisible to a static analysis tool (such as the dependency report): e.g. eval('magic = 1:100;');.
The only way is to go through your whole code base, either inspecting every occurrence manually (which can be found easily with a text search) or by running a test that fully covers your code base.
edit:
There is however a way to access intermediate outputs of the MATLAB parser. This can be accessed using the undocumented and unsupported mtree function (which can be called like this: t = mtree(file, '-file'); for every file in your code base). Using the resulting structure you might be able to find calls with a certain amount of parameters.
I'm new to CoffeeScript and seems that I can't find any document generator for CoffeeScript using Javadoc syntax. The only one I could find is available as a patch to the CoffeeScript compiler.
So, what do you use to generate documentation from Javadoc comment on CoffeeScript or how do you document your function arguments and return values?
So, JavaDoc syntax has never really caught on with JavaScript developers. There are those who use something like it—notably Google—but it's kind of at odds with JS, which doesn't have static typing and allows any number of arguments to any function.
If you want to create beautiful documentation with CoffeeScript, the standard is Docco (its home page is an excellent example). If you want to create JavaDoc-style comments for every function... well, you'll have to create them by hand, and escape them with backticks.
Alternatively, you could work in CoffeeScript until your code is release-ready, then document the resulting JavaScript.
Docco is great for prozedural coding style. If you want to document an API, coffeedoc is for you.
People looking forward to using javadoc style documentation in coffeescript can checkout codo ( http://netzpirat.github.com/codo/ ) which provides support for a subset of javadoc and automatically infers class names, function names and parameters from source code.
I'm using YUIDoc. I can add comments using a syntax similar to Javadoc to my classes, methods and events. The documentation gets output as html/css files and you can even customize the page layout.
Check this documentation example: http://yui.github.com/yuidoc/api/
PS: It relies on Node.JS and you need to install the package yuidocjs
npm install yuidocjs -g
I'm very impressed for PyCharm capabilities to detect errors in my code by inspecting type hints in docstrings:
def f(a):
"""Some docs here
:type a: int
:rtype: str
"""
...
and I'm trying to replicate it in PyDev.
As described in docs, PyDev can use docstring to infer parameters and return types:
So, I can ask PyDev for allowed methods (Ctrl + Space) based on variable type, but I can't use it for code checking, to make sure I don't misuse variables.
Is it possible to include this check during code analysis in PyDev?
PyDev doesn't really do type checking for instances/parameters (even when it knows the type for code completion like in that case)... right now it only complains about tokens not found when following imports.
So, at this point, this would be a feature request for PyDev... I haven't implemented this so far because knowing the type can be tricky, but I think that when it's 100% sure of the type (from a type hint), it could really do that analysis -- it should be reasonably straightforward to implement too, so, the major issue is me having time to do it -- or having someone contribute it ;)