Tracking errors to line and column

[Rush]

Hi! First of all, nice addon. I firstly tried EJS for code generation but indentation really sucked. When I get reference errors in the template function is there a way to track it down to line and column? EJS does it so it should be possible. Thanks!

[celer]

Hi,

I'm on vacation, so I can't look right now (I have no computer ;) ) I'll
have to take a look when I get back late next week.

Thanks,

celer
On Feb 21, 2014 5:42 PM, "Damian Kaczmarek" [email protected]
wrote:

Hi! First of all, nice addon. I firstly tried EJS for code generation but
indentation really sucked. When I get reference errors in the template
function is there a way to track it down to line and column? EJS does it so
it should be possible. Thanks!

Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

[celer]

I've dramatically improved the error handling, given that I'm not parsing the JavaScript. When possible I provide a line number in the exception and a .line property as well. But there are still cases that I can't handle without fully parsing the JavaScript.

[Rush]

Trying out the new version and I intentionally referenced a missing variable

        <% if(declaration['function']) {%>
            <% var func = declaration['function']; intentionallyMissing  %>
            {

ReferenceError: intentionallyMissing is not defined
    at eval (eval at <anonymous> (/home/rush/Programowanie/node-tov8/node_modules/fire-ts/lib/fire-ts.js:307:20), <anonymous>:33:39)

I got no hint where this error occured. I worry that when I move on with my project it may take lots of time to find out where errors occured.

[Rush]

It turns out all of my cases are always undebuggable ... like missing ) or missing }. It's a choire to find an error ... What what be the course of action? Where do you need to add javascript parser? I bet there are PEG rules for JS just there for the taking.

[celer]

Hmm, so given your feature requests/issues the right answer is to include a JavaScript parser (there is an example one as part of peg.js), but I'm thinking that the entire package would need a serious re-write to make that work (I'll think on this some more)

In the mean time, I've immediately improved the detection of unbalanced braces and parens, which works and passes my tests but, isn't as good as actually including a JS parser.

Check out the newly pushed package

Over the next few days I'll take a look at how some of the other template engines do their error handling to see if they get by without parsing the JavaScript. I was trying to let the Node interpreter do this for me, but it really doesn't do a good job of providing enough details to pin-point the line the error occurred on.

[Rush]

Have you given any more thought to the problem? The mature parser of JS is of course http://esprima.org/ I think that big win would be to at least leave the line numbers the same from the template to the generated JS. May look ugly while generating that code but debugging would be whole lot easier. Then any errors when caught could tell in which template file the error occurred.

I wanna share with you the project I am doing which is using fire-ts at its core.
https://github.com/CodeCharmLtd/node-cbind
I am automatically generating binding code for a given C/C++ API definition.

fire-ts is really awesome and better than everything else but still hard to code at time. You wouldn't happen to have syntax highlighting for Sublime Text, would you?

[celer]

Hi Damian,

I haven't put much more thought on it, I have about 8 projects I'm involved
in so I haven't circled back around to this one. Hmm esprima looks pretty
interesting! I don't think I'll get back to it for a while; I'm currently
working on a major release of hopjs.

Your node cbinding is pretty neat. I wrote fire-ts to generate java and
objective-c code for hopjs after becoming really frustrated with all the
other template engines.

I don't have any syntax highlighting that really works well.

Thanks,

Dave

On Tue, May 13, 2014 at 2:14 PM, Damian Kaczmarek
[email protected]:

Have you given any more thought to the problem? The mature parser of JS is
of course http://esprima.org/ I think that big win would be to at least
leave the line numbers the same from the template to the generated JS. May
look ugly while generating that code but debugging would be whole lot
easier. Then any errors when caught could tell in which template file the
error occurred.

I wanna share with you the project I am doing which is using fire-ts at
its core.
https://github.com/CodeCharmLtd/node-cbind
I am automatically generating binding code for a given C/C++ API
definition.

fire-ts is really awesome and better than everything else but still hard
to code at time. You wouldn't happen to have syntax highlighting for
Sublime Text, would you?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-43006532
.