Error handling in go, which file and line? - go

I did not find a better way to show error details in long form.
log.SetFlags(log.Llongfile)
I am particularly interested which file and line error happened. Is it any way to set long format application wide rather than add to every function?


You might want to consider gin to watch and tells you where errors happened after build.

Related

When cola.js fails, what's a fast way to find out what went wrong?

When cola.js fails, how do you find out what went wrong?
I don't have a minimal reproducible example, because that will likely take hours of debugging to make, and if I had it, then it wouldn't be an example of what I'm asking about. I'm hoping to hear of a way to quickly find out what's gone wrong. Presumably it's some bad data in my graph. But how can I tell what the bad data is?
The screenshot below illustrates a typical situation where something has gone wrong. Various NaNs are reported, there are a bunch of Uncaught TypeErrors, and an Assertion fails. There are a whole lot of local variables, all named with a single letter. Clicking and looking at them shows that a NaN got into a coordinate somewhere, as suggested by the previous error messages. It looks like sometime earlier, something got a null when it needed some sort of list-like data structure. How can I quickly find out what was the bad data that got into the graph?
I'm using cola.v3.min.js.
Details
I'm looking for a general approach to finding this kind of error, but here's the specific data that produced the errors in this example. Each line is the argument passed to cy.add() (as suggested by Stepan T.—and printing out everything passed to cy.add() might turn out to be the first step of the answer!).
{"group":"nodes","data":{"id":1,"label":"Workspace","parent":[]},"position":{"x":45,"y":0}}
{"group":"nodes","data":{"id":2,"label":"Target(121)","parent":[1]},"position":{"x":5,"y":0}}
{"group":"nodes","data":{"id":3,"label":"WantFullySourced","parent":[]},"position":{"x":50,"y":0}}
{"group":"nodes","data":{"id":4,"label":"Brick(120)","parent":[1]},"position":{"x":10,"y":0}}
{"group":"nodes","data":{"id":5,"label":"Avail","parent":[]},"position":{"x":55,"y":0}}
{"group":"nodes","data":{"id":6,"label":"Brick(1)","parent":[1]},"position":{"x":15,"y":0}}
{"group":"nodes","data":{"id":7,"label":"Avail","parent":[]},"position":{"x":60,"y":0}}
{"group":"nodes","data":{"id":8,"label":"Brick(2)","parent":[1]},"position":{"x":20,"y":0}}
{"group":"nodes","data":{"id":9,"label":"Avail","parent":[]},"position":{"x":65,"y":0}}
{"group":"nodes","data":{"id":10,"label":"Brick(3)","parent":[1]},"position":{"x":25,"y":0}}
{"group":"nodes","data":{"id":11,"label":"Avail","parent":[]},"position":{"x":70,"y":0}}
{"group":"nodes","data":{"id":12,"label":"Brick(4)","parent":[1]},"position":{"x":30,"y":0}}
{"group":"nodes","data":{"id":13,"label":"Avail","parent":[]},"position":{"x":75,"y":0}}
{"group":"nodes","data":{"id":14,"label":"Brick(5)","parent":[1]},"position":{"x":35,"y":0}}
{"group":"nodes","data":{"id":15,"label":"Avail","parent":[]},"position":{"x":80,"y":0}}
{"group":"nodes","data":{"id":16,"label":"NumericalRelationScout","parent":[1]},"position":{"x":40,"y":0}}
{"group":"nodes","data":{"id":17,"label":"OperandView","parent":[1]},"position":{"x":0,"y":0}}
{"group":"edges","data":{"id":"2.member_of.1.members","source":2,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"4.member_of.1.members","source":4,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"6.member_of.1.members","source":6,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"8.member_of.1.members","source":8,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"10.member_of.1.members","source":10,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"12.member_of.1.members","source":12,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"14.member_of.1.members","source":14,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"16.member_of.1.members","source":16,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"17.member_of.1.members","source":17,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"3.taggees.2.tags","source":3,"source_port_label":"taggees","target":2,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"2.support_from.3.support_to","source":2,"source_port_label":"support_from","target":3,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"3.support_from.2.support_to","source":3,"source_port_label":"support_from","target":2,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"5.taggees.4.tags","source":5,"source_port_label":"taggees","target":4,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"4.support_from.5.support_to","source":4,"source_port_label":"support_from","target":5,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"7.taggees.6.tags","source":7,"source_port_label":"taggees","target":6,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"6.support_from.7.support_to","source":6,"source_port_label":"support_from","target":7,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"9.taggees.8.tags","source":9,"source_port_label":"taggees","target":8,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"8.support_from.9.support_to","source":8,"source_port_label":"support_from","target":9,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"11.taggees.10.tags","source":11,"source_port_label":"taggees","target":10,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"10.support_from.11.support_to","source":10,"source_port_label":"support_from","target":11,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"13.taggees.12.tags","source":13,"source_port_label":"taggees","target":12,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"12.support_from.13.support_to","source":12,"source_port_label":"support_from","target":13,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"15.taggees.14.tags","source":15,"source_port_label":"taggees","target":14,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"14.support_from.15.support_to","source":14,"source_port_label":"support_from","target":15,"target_port_label":"support_to","weight":2}}
The object passed to cy.layout() had a circular structure, so JSON.stringify() wouldn't print it. Adding the getCircularReplacer() function recommended here seemed to crash the browser. But manually removing elements from the layout object exposed the error: in a relative alignment constraint (documented under API here), I had an offset of '0' where I needed a 0, i.e. a string where a number was needed.
OK, happily that problem is now fixed. That still leaves the original question: is there a faster way to find errors like that? (The static-typing advocates are surely cackling by now.)

How to make Compass/Sass compilation command generate parsable output

I’d like to automate the compilation of Compass projects and be able to get output that I can parse so I can take only what I need (the errors) and further format them how I want.
The issue is that Compass output is not in a format that can be easily parsed (it has error messages on multiple lines).
Is there any reliable way to parse this output? Or… any idea what would need to be changed and where in Compass’s code to allow a new param that would allow you to specify the output format (e.g. JSON, XML)?
I’m asking this because I don’t know Ruby, so I would need a starting point. Their current code is not easy to understand (due to the fact that I don’t know Ruby), but if I at least have a starting point I would try to see what I can do and hopefully create a pull request with this if I get it working.

I think, there is another way to solve this problem, what you think about to parse the output css and do not touch compass.
There is a good framework for creating postproccesor for css:
https://github.com/postcss/postcss
You can do what you want with output css and send message to console or send email or other things, and many other things.

make error latex

make -C doc html latexpdf
yields this:
Package hyperref Message: Driver (autodetected): hpdftex.
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/hypcap.sty))
(/usr/share/texlive/texmf-dist/tex/latex/multirow/multirow.sty)
Writing index file Arakoon.idx
(./Arakoon.aux)
Runaway argument?
{{1.10.3}{9}{Client side support\relax }{subsection.1.10.
! File ended while scanning use of \#newl#bel.
<inserted text>
\par
l.113 \begin{document}
?

If someone is still looking for this: For me usually, when a prior build had failed due to an error, subsequent builds would fail with this error. Solved it by deleting the main .aux file and building it again.

It is impossible to say with any confidence, but it looks like a fragile (non-robust) command in a subsubsection heading or a maths label (would be label 10.1.3), because:
It occurs at \begin{document}, when the .aux files are loaded,
The error indicates a malformed directive in the .aux file, and the presence of a \relax there - typically what command reduce to after having performed their side effect.
Two suggestions:
Generate an MWE by making a new document from this with all the body of your document except that heading/ equation (and perhaps the sentence following) deleted. Does this create the same error? If so, post it here. You might need some trial and error to find out which Lat3ex command is responsible, but it should contain the text Client side support.
Do read https://tex.stackexchange.com/questions/4736/what-is-the-difference-between-fragile-and-robust-commands - if I am right, you have a fragile command where it shouldn't be. Figure out what should be there instead.

How to debug Octopress markdown source files?

I use Octopress for blogging. Generally it works well except one occassion -- after typing rake generate, I got depressing output which says something like:
psych.rb:203:in `parse': (<unknown>): mapping values are not allowed in this context at line 3 column 6 (Psych::SyntaxError)
I can't remember how many times I've encounterd this situation. Every time I google the key words above, but got nothing help.
What I can do is to exclude all the source files (*.mkd) from _posts, and add them one by one to check which one goes wrong. I keep checking, and finally it turns out that a minor grammer mistake makes octopress angry.
Life should NOT be that hard. So is it possible to debug a octopress source file to show which line of file is incorrect in grammer? The outputs from rake generate don't make sense at all.

The reason could be wrong JAML in the top part of the post (e.g. ':' in the title), see https://github.com/jekyll/jekyll/issues/549 for more info.

I've seen a similar error ("mapping values are not allowed in this context") when I try to convert markdown files, using Pandoc. Perhaps your error message is coming from pandoc somehow?

Don't bother to debug Octopress. Please migrate to Pelican -- a Python-powered static site generator. It is full-featured, easy to use, and no doubt, generating useful debug information.

Getting the Compiler:Error-Row when the compile error occurs in an include file

Does anybody know whether it's possible to get the error-row of a file being compiled when the error occurs in an include file?
For example, I'm compiling a file, say abc.p, that uses def.i all over the place. At some point, I make a change to abc.p that causes a compile error in one of the includes, so the message says that the error occurred at line 123 of def.i, but I want to know at which line in abc.p that is. In other words, the line number where the offending include file is used.
Even though "Compiler:Get-File-Name(n)" returns def.i and "Compiler:File-Name" returns abc.p, both "Compiler:Get-Row(n)" as well as "Compiler:Error-Row" returns the line number in def.i.
Any ideas?

My guess would be to save the compiler listing or debug file and look at that.
Beyond that, I don't think there's a way to do it now - you need to submit an enhancement request to get this functionality.

My way of tracking this kind of error is with
compile source.p preprocess source.pp.
open source.pp in the procedure editor and check syntax.
This gives you the error location in the expanded source.
Once you have found that locate code that is not part of the include and search for that code in the original source.

Resources