For the times when you are reading source code without an IDE at hand.
Compile with the Xprint:typer scalac option.
This tells scalac to explain what it's doing.
This article explains the option and gives an example of the output (towards the bottom).
Related
I'm solving a problem about scala tracing.
What I want to do is get the environment after executing each line of a scala file, which means, for a program in scala, I could know which line it is executing now and the variables existing now, for every line.
Now I'm using the method of stepping. I let the program step into or step return automatically(by editting the scala IDE in Eclipse) for every line, and then I could get what we want.
But for a long program, it's very slow and will cost a large amount of memory, more than 20GB!
So do you have any better idea about how to achieve it?Give me the whole trace in source code format for every line of a program, with source file path, line number and current variables.
Thanks!
AFAIK there is no free/opensource tools for the task you described, only commercial ones:
Chronon, but looks like that only Java is supported.
Jidebug, I also not sure about Scala.
They both can record runtime traces of your JVM code and later you can drill into these to understand what has happened there.
I wanted to ask if there are any features (or add-ons) for Doxygen to measure the documentation coverage via command line. I already know that I can set up Doxygen to write undocumented elements as warnings into a log file, but to fully evaluate the documentation coverage from that, I'd need to write my own warning log parser. Was something like this done already or is there an even easier way I couldn't find? Is there any add-on I could check out for this?
Thank you.
I don't know anything that can give documentation coverage for doxygen, but a quick search gives 2 interesting results : https://github.com/alobbs/doxy-coverage (require xml output for doxygen) and http://jessevdk.github.io/cldoc/ (alternative for c++ projects?)
There is coverxygen which is using the same idea as alobbs/doxy-coverage (uses xml output of Doxygen) but provides more options (for example, filter by access specifier).
Disclaimer: I am contributing to that project.
I frequently use the Scala console to evaluate and test code before I actually write it down in my project. If I want to know the contents of a variable, I can just enter it and scala evaluates it. But is there also a way to show the code of methods I entered?
I know there's the UP-key to show single lines, but what I was searching for is to show the whole code at once.
There's a file in your home directory named .scala_history that contains all of your recent REPL history. I regularly copy and paste code from this file into project source files. It's not exactly the same as showing the code for individual methods in the REPL, but it might help you accomplish the same goals.
See the comments by Paul Phillips in this issue for a discussion of some related functionality in the REPL (grouping statements in the history):
At some point I implemented the logic for this, but the real obstacle
is jline. It has enough trouble figuring out where the cursor is under
the simplest conditions. Start throwing big multiline blocks into the
history and it breaks down in tears. Would love to see this and
SI-2547 addressed by the community.
...
I expect to fix this soon too, but it depends on how well the recent
jline work goes. I implemented it long ago, and display issues are the
impediment.
Both of these comments are over two years old, so I wouldn't hold your breath.
I dont know a command to load all the code from command line.
What you can do is to :load path/to/my/file.scala to load some complex code and re- :load it when you changed the code in the file.
Whether or not I compile a Racket program seems to make no difference to the runtime performance.
Is it just the loading of the file initially that is improved by compilation? In other words, does running racket src.rkt do a jit compilation on the fly, which is why I see no difference in compiling vs interactive?
Even for tight loops of integer arithmetic, where I thought some difference would occur, the profile times are equivalent whether or not I previously did a raco make.
Am I missing something simple?
PS, I notice that I can run racket against the source file (.rkt) or .zo file. Does racket automatically use the .zo if one is found that corresponds to the .rkt file, or does the .zo file need to be used explicitly? Either way, it makes no difference to the performance numbers I'm seeing.
Yes, you're right.
Racket compiles code in two stages: first, the code is compiled into bytecode form, and then when it runs it gets jitted into machine code. When you compile a file, you're basically creating the bytecode which saves on re-compiling it later. Since that's usually not something that takes a lot of time for small pieces of code, you won't see any noticeable difference in runtimes. For an extreme example, you can delete all *.zo files in the collection tree and start DrRacket -- it will take a lot of time to start since there's a ton of code, but once it does start, it would run almost as usual. (It would also be slow to click "run" since that will reload and recompile some files.) Another concern for bigger pieces of code is that the compilation process can make memory consumption higher, but that's also not an issue with smaller pieces of code.
See also the Performace chapter in the guide for hints on how to improve performance.
Racket will always compile your code, regardless of whether it is run interactively at the REPL or run from the command-line. Here is the section in the guide that explains it. In interactive mode, the compiler turns every expression/definition into bytecode in memory and executes that. Otherwise, the compilers outputs the bytecode to zo files.
Note: Eli replied at the same time I did. See his response for more details.
I've been experimenting with Scala lately and I noticed that when I need to look up a function or a class, I have to go to the website or navigate to the local documentation.
Is there a way to read the Scaladoc from inside the interpreter?
Maybe something like help() in Python.
Scalaex is a cool Scala-web documentation like Hoogle with an usefull CLI-client.
(But it's not inside the interpreter. Unfortunately I cannot write a comment to your question, so I write this as an answer.)
I'm running the command line scala interpreter for 2.9, and tab-key completion works for me:
val x = List(1,2,3)
x.
Then press TAB
Shows the list of methods.
Not quite full docs, but helpful nonetheless.