How can we trace expressions / print statements with line numbers in Scala? - scala

If you want print statements with line numbers, how do you do it?

Check out Haoyi Li's sourcecode library, I think it gives you what you are looking for.
sourcecode is a small Scala library for that provides common "source
code" context to your program at runtime, similar to Python's
__name__, C++'s __LINE__ or Ruby's __FILE__. For example, you can
ask for the file-name and line number of the current file, either
through the () syntax or via an implicit.
See for example https://github.com/lihaoyi/sourcecode#logging
You can use sourcecode.File and sourcecode.Line to define log
functions that automatically capture their line number and file-name
def log(foo: String)(implicit line: sourcecode.Line, file: sourcecode.File) = {
println(s"${file.value}:${line.value} $foo")
}
log("Foooooo") // sourcecode/shared/src/test/scala/sourcecode/Tests.scala:86 Fooooo

It depends on what you want to do.
With the scala-trace-debug library, you can type something like this:
Debug.trace(1 + 2)
And get this:
"3" in thread main:
path.to.file(file.Scala: 22) // click-able stack trace
You can customize the number of lines of stack trace, like so:
Debug.trace(1 + 2, 3) // 3 lines of stack trace
And if you do info.collaboration_station.debug._, you can even do this:
val three = 3.trace
...
"3" in thread main:
path.to.file(file.Scala: 22)
Finally, there is support for expressions:
Debug.traceExpression{
val myVal = 4
1 + 2 + myVal
}
...
"{
val myVal = 4;
(3).+(myVal)
} -> 7" in thread main:
at main.Main$.main(Main.scala:12)
Unlike the other library, this is more geared toward debugging. If I wanted to provide a history of what was going on and I did not want the user to see a stack trace, I would not use this tool.

Related

How can I get the name of procedure in Nim?

I am trying to write a macro for debug print in the Nim language.
Currently this macro adds filename andline to the output by instantiationInfo().
import macros
macro debugPrint(msg: untyped): typed =
result = quote do:
let pos = instantiationInfo()
echo pos.filename, ":", pos.line, ": ", `msg`
proc hello() =
debugPrint "foo bar"
hello()
currently output:
debug_print.nim:9: foo bar
I would like to add the name of the procedure (or iterator) of the place where the macro was called.
desired output:
debug_print.nim:9(proc hello): foo bar
How can I get the name of procedure (or iterator) in Nim, like __func__ in C?
At runtime you can do getFrame().procname, but it only works with stacktrace enabled (not in release builds).
At compile-time surprisingly I can't find a way to do it. There is callsite() in macros module, but it doesn't go far enough. It sounds like something that might fit into the macros.LineInfo object.
A hacky solution would be to also use __func__ and parse that back into the Nim proc name:
template procName: string =
var name: cstring
{.emit: "`name` = __func__;".}
($name).rsplit('_', 1)[0]
building on answer from #def- but making it more robust to handle edge cases of functions containing underscores, and hashes containing trailing _N or not
also using more unique names as otherwise macro would fail if proc defines a variable name
import strutils
proc procNameAux*(name:cstring): string =
let temp=($name).rsplit('_', 2)
#CHECKME: IMPROVE; the magic '4' chosen to be enough for most cases
# EG: bar_baz_9c8JPzPvtM9azO6OB23bjc3Q_3
if temp.len>=3 and temp[2].len < 4:
($name).rsplit('_', 2)[0]
else:
# EG: foo_9c8JPzPvtM9azO6OB23bjc3Q
($name).rsplit('_', 1)[0]
template procName*: string =
var name2: cstring
{.emit: "`name2` = __func__;".}
procNameAux(name2)
proc foo_bar()=
echo procName # prints foo_bar
foo_bar()
NOTE: this still has some issues that trigger in complex edge cases, see https://github.com/nim-lang/Nim/issues/8212

How to get intellij to offer a text diff comparison on failed tests

I'm writing a Scala test with some ScalaTest matchers.
When my test fails, intellij says something like
{"count":3,"pagination":{"offset":0,"limit":100},"content":{"uri":"http://locahost.com/catalogue/content?order=Query&id=18,20,19"},"list":[{"id":"18","position":27},{"id":"20","position":341},{"id":"19","position":33}]} was not equal to {"count":3,"pagination":{"offset":0,"limit":100},"content":{"uri":"http://locahost.com/catalogue/content?order=Query&id=18,20,19"},"list":[{"id":"18","timestamp":"2015-01-28T11:55:44.494Z","content":"Episode","position":27},{"id":"20","timestamp":"2015-01-19T11:55:44.494Z","content":"Program","position":341},{"id":"19","timestamp":"2015-01-17T11:55:44.494Z","content":"Episode","position":33}]}
org.scalatest.exceptions.TestFailedException: {"count":3,"pagination":{"offset":0,"limit":100},"content":{"uri":"http://locahost.com/catalogue/content?order=Query&id=18,20,19"},"list":[{"id":"18","position":27},{"id":"20","position":341},{"id":"19","position":33}]} was not equal to {"count":3,"pagination":{"offset":0,"limit":100},"content":{"uri":"http://locahost.com/catalogue/content?order=Query&id=18,20,19"},"list":[{"id":"18","timestamp":"2015-01-28T11:55:44.494Z","content":"Episode","position":27},{"id":"20","timestamp":"2015-01-19T11:55:44.494Z","content":"Program","position":341},{"id":"19","timestamp":"2015-01-17T11:55:44.494Z","content":"Episode","position":33}]}
at org.scalatest.MatchersHelper$.newTestFailedException(MatchersHelper.scala:160)
at org.scalatest.Matchers$ShouldMethodHelper$.shouldMatcher(Matchers.scala:6231)
at org.scalatest.Matchers$AnyShouldWrapper.should(Matchers.scala:6265)
...
However, intellij does not give me the handy see difference in the text feature.
I thought it might be because I'm comparing 2 objects
val responseBody = responseAs[JsValue]
responseBody should be(viewingByAccountIdResponseJson)
but changing it to
assert(responseBody.toString() === viewingByAccountIdResponseJson.toString())
Does not allow me to do a text comparison either.
Is there any way to configure intellij to do this?
(I'm currently using a FlatSpec with Matchers)
Note: This is related to this question
Formatting output so that Intellij Idea shows diffs for two texts
However, even using the syntax recommended that intellij might pick up, it does not work.
I see this is not possible at the moment and as of the current moment in time, is a feature request:
https://youtrack.jetbrains.com/issue/SCL-4867
As intellij feature request mentioned by Bruce celebrates it's 7th birthday, some of us have lost their hope (still don't forget to +1 it). Here's an ugly script which allows you to mitigate the issue a bit. Just copy This was not equal to That line and feed it to the stdin of this script:
| scalatest-diff
cat > ~/bin/scalatest-diff
#!/usr/bin/perl
my $in = join("", <STDIN>);
if( $in =~ m/[^:]+\: (.+?) was not equal to (.+)/so ) {
my $this = $1;
my $that = $2;
$this =~ s/,/,\n/g;
$that =~ s/,/,\n/g;
open(thisFile, ">", "/tmp/this");
open(thatFile, ">", "/tmp/that");
print thisFile $this; close thisFile;
print thatFile $that; close thatFile;
exec("vimdiff /tmp/this /tmp/that");
}
<Ctrl-D>
chmod a+x ~/bin/scalatest-diff
P.S. feel free to change vimdiff to your favorite differ.
The problem is that ScalaTest is trying to nicely format the left and the right object before displaying the difference.
You can get around this by defining your own matcher that throws a less fancy TestFailedException. Here is a sketch of how to achieve this in a matcher-based test:
it must "show diff" in {
"""Hello
|World!
|""".stripMargin shouldEqualPlainly
("""Hello
|ScalaTest.
|""".stripMargin)
}
implicit class PlainEquality[T](leftSideValue: T) {
// Like should equal, but does not try to mark diffs in strings with square brackets,
// so that IntelliJ can show a proper diff.
def shouldEqualPlainly(right: Any)(implicit equality: Equality[T]): Assertion =
if (!equality.areEqual(leftSideValue, right)) {
throw new TestFailedException(
(e: StackDepthException) => Some(s"""${leftSideValue} did not equal ${right}"""),
None,
Position.here
)
} else Succeeded
}
This will let you click and give you something like this:

Go: C like macros for writing test code

When writing test code, I do a lot of this
if (!cond) {
t.Fatal("error message")
}
It's a bit tedious. So I'd like to achieve the following
CHECK(cond, "error message")
So I attempted this
func CHECK(t *testing.T, cond bool, fmt string, a ...interface{}) {
if !cond {
t.Fatal(fmt, a)
}
}
If it were a C macro it would've worked perfectly. But in Go, the line number where the failure is is wrong.
Is there a fix for this?
Sadly you can't do that.
A workaround would be to get the line / function yourself, something like the trace function from https://stackoverflow.com/a/25954534/145587.
You could possibly make use of runtime.Callers()&plus;runtime.Caller(): the first one gives you the call stack while the second allows to extract the debug info about any arbitrary stack frame (obtained from that list).
Your CHECK() function is always one function call down the place the check should have happened at if it was a macro, so you can inspect the stack frame just above.
Update: the only functon which is really needed is runtime.Caller(). Here's your case, simplified:
package main
import (
"runtime"
"testing"
)
func CHECK(t *testing.T, cond bool) {
if !cond {
_, fname, lineno, ok := runtime.Caller(1)
if !ok {
fname, lineno = "<UNKNOWN>", -1
}
t.Fatalf("FAIL: %s:%d", fname, lineno)
}
}
func TestFoo(t *testing.T) {
CHECK(t, 12 == 13)
}
When saved as check_test.go and run via go test, it produces:
$ go test
--- FAIL: TestFoo (0.00 seconds)
check_test.go:14: FAIL: /home/kostix/devel/go/src/check/check_test.go:19
FAIL
exit status 1
FAIL check 0.001s
where line 19 is the line a call to CHECK() is located inside TestFoo().
While the above answer to use CHECK() function will work, I think that the actual answer is code readibility. Much of Go has been designed as a compromise to increase readibility among the community as a whole. See gofmt for example. Most people will agree that it's format is not best for every case. But having a convention agreed to by all is a huge plus for Go. The same answer is to your question. Go is for writing code for your peers, not for yourself. So don't think "I prefer this." Think "what will people reading my code understand."
Your original code should be like this, without parenthesis.
if !cond {
t.Fatal("error message")
}
This is idiomatic and every Go coder will recognize it instantly. That is the point.

Procedural macro parsing weirdness in Rust

I'm trying to parse a macro similar to this one:
annoying!({
hello({
// some stuff
});
})
Trying to do this with a procedural macro definition similar to the following, but I'm getting a behaviour I didn't expect and I'm not sure I'm doing something I'm not supposed to or I found a bug. In the following example, I'm trying to find the line where each block is,
for the first block (the one just inside annoying!) it reports the correct line, but for the inner block, when I try to print them it's always 1, no matter where the code is etc.
#![crate_type="dylib"]
#![feature(macro_rules, plugin_registrar)]
extern crate syntax;
extern crate rustc;
use macro_result::MacroResult;
use rustc::plugin::Registry;
use syntax::ext::base::{ExtCtxt, MacResult};
use syntax::ext::quote::rt::ToTokens;
use syntax::codemap::Span;
use syntax::ast;
use syntax::parse::tts_to_parser;
mod macro_result;
#[plugin_registrar]
pub fn plugin_registrar(registry: &mut Registry) {
registry.register_macro("annoying", macro_annoying);
}
pub fn macro_annoying(cx: &mut ExtCtxt, _: Span, tts: &[ast::TokenTree]) -> Box<MacResult> {
let mut parser = cx.new_parser_from_tts(tts);
let lo = cx.codemap().lookup_char_pos(parser.span.lo);
let hi = cx.codemap().lookup_char_pos(parser.span.hi);
println!("FIRST LO {}", lo.line); // real line for annoying! all cool
println!("FIRST HI {}", hi.line); // real line for annoying! all cool
let block_tokens = parser.parse_block().to_tokens(cx);
let mut block_parser = tts_to_parser(cx.parse_sess(), block_tokens, cx.cfg());
block_parser.bump(); // skip {
block_parser.parse_ident(); // hello
block_parser.bump(); // skip (
// block lines
let lo = cx.codemap().lookup_char_pos(block_parser.span.lo);
let hi = cx.codemap().lookup_char_pos(block_parser.span.hi);
println!("INNER LO {}", lo.line); // line 1? wtf?
println!("INNER HI {}", hi.line); // line 1? wtf?
MacroResult::new(vec![])
}
I think the problem might be the fact that I'm creating a second parser to parse the inner block, and that might be making the Span types inside it go crazy, but I'm not sure that's the problem or how to keep going from here. The reason I'm creating this second parser is so I can recursively parse what's inside each of the blocks, I might be doing something I'm not supposed to, in which case a better suggestion would be very welcome.
I believe this is #15962 (and #16472), to_tokens has a generally horrible implementation. Specifically, anything non-trivial uses ToSource, which just turns the code to a string, and then retokenises that (yes, it's not great at all!).
Until those issues are fixed, you should just handle the original tts directly as much as possible. You could approximate the right span using the .span of the parsed block (i.e. return value of parse_block), which will at least focus the user's attention on the right area.

How to further improve error messages in Scala parser-combinator based parsers?

I've coded a parser based on Scala parser combinators:
class SxmlParser extends RegexParsers with ImplicitConversions with PackratParsers {
[...]
lazy val document: PackratParser[AstNodeDocument] =
((procinst | element | comment | cdata | whitespace | text)*) ^^ {
AstNodeDocument(_)
}
[...]
}
object SxmlParser {
def parse(text: String): AstNodeDocument = {
var ast = AstNodeDocument()
val parser = new SxmlParser()
val result = parser.parseAll(parser.document, new CharArrayReader(text.toArray))
result match {
case parser.Success(x, _) => ast = x
case parser.NoSuccess(err, next) => {
tool.die("failed to parse SXML input " +
"(line " + next.pos.line + ", column " + next.pos.column + "):\n" +
err + "\n" +
next.pos.longString)
}
}
ast
}
}
Usually the resulting parsing error messages are rather nice. But sometimes it becomes just
sxml: ERROR: failed to parse SXML input (line 32, column 1):
`"' expected but `' found
^
This happens if a quote characters is not closed and the parser reaches the EOT. What I would like to see here is (1) what production the parser was in when it expected the '"' (I've multiple ones) and (2) where in the input this production started parsing (which is an indicator where the opening quote is in the input). Does anybody know how I can improve the error messages and include more information about the actual internal parsing state when the error happens (perhaps something like a production rule stacktrace or whatever can be given reasonably here to better identify the error location). BTW, the above "line 32, column 1" is actually the EOT position and hence of no use here, of course.
I don't know yet how to deal with (1), but I was also looking for (2) when I found this webpage:
https://wiki.scala-lang.org/plugins/viewsource/viewpagesrc.action?pageId=917624
I'm just copying the information:
A useful enhancement is to record the input position (line number and column number) of the significant tokens. To do this, you must do three things:
Make each output type extend scala.util.parsing.input.Positional
invoke the Parsers.positioned() combinator
Use a text source that records line and column positions
and
Finally, ensure that the source tracks positions. For streams, you can simply use scala.util.parsing.input.StreamReader; for Strings, use scala.util.parsing.input.CharArrayReader.
I'm currently playing with it so I'll try to add a simple example later
In such cases you may use err, failure and ~! with production rules designed specifically to match the error.