if we can see line number in error message

[csfreebird]

I am not sure if newLisp can output line number or not in error message currently. But according to my experience, I always take many minutes to find the error location when my code becomes large.
If newlisp does support this, it will save many time. e.g

Code: Select all

(define (check-checksum2 msg-length msg-body)                                                                                   
  (letn ((msg-checksum (append "0x" (pick-string msg-body (- msg-length 10) (- msg-length 8))))
         (checksum-value (cal-checksum (total msg-body 0 (- msg-length 10)))))
        (log (string checksum-value))
        (log (string (int msg-checksum)))
        (if (= checksum-value (int msg-checksum))
            (log (append "checksum is equal, received: " (string (int msg-checksum)) " calculated: " (string checksum-value)))
           (throw-error (append "checksum is wrong: " checksum-value)))))

I got error message:

Code: Select all

ERR: string expected in function append : checksum-value
called from user defined function Sign:check-checksum2
called from user defined function Sign:login
called from user defined function Sign:create-session
called from user defined function Sign:launch
called from user defined function create-sign

Because I forget to convert checksum-value to string at the last line. But I was not aware of the real reason at first, so I have to add a few log statements to search.
Is it possible to show error line number in newlisp?

[rickyboy]

In this case, there is no need for line numbers. The stack trace shows that some append call is complaining about one of its arguments in the body of the function Sign:check-checksum2. There is only one place where that could be happening, thanks due to the shortness of your function definition (which in my view is the right way to code in newLISP; good job).

By the way, in newLISP, if you ever find yourself using append where all the arguments are strings, it's better to replace the append call with a string call. In that case, you can also drop the (string ...) wrappers around the arguments. For instance, this:

Code: Select all

(append "checksum is equal, received: " (string (int msg-checksum)) " calculated: " (string checksum-value))

can be expressed in a better way like this:

Code: Select all

(string "checksum is equal, received: " (int msg-checksum) " calculated: " checksum-value)

Also, the offending append call:

Code: Select all

(append "checksum is wrong: " checksum-value)

would have yielded no error if expressed like this:

Code: Select all

(string "checksum is wrong: " checksum-value)

[csfreebird]

Hi,
Thanks for your suggestion about replacing append with string function, I will use it later.
Maybe my code snippet is not a good example here, in my code, only the last two lines are using

Code: Select all

(append ... checksum-value)

But I still think newLisp should offer line number when getting error because it will make developer's life easier. Everyone knows I am using newLisp will say like these:"wow, lisp, are you crazy?" "it's too hard to learn and use".
newlisp has made lisp coding much easier than before. If it can give line number, that will be very helpful like other programming languages. Currently, I cannot find any other programming language (or compiler) which doesn't report error line number.

[Astrobe]

I second the suggestion of adding line numbers to error messages. The debugger could also use some improvements.

I am an embedded systems programmer, and I'm quite used to debug using only printf, but the lack of support from Newlisp in this area makes things more difficult than it should be.

Since I'm in the process of butchering....errr, I mean hacking the guts of Newlisp, I took a look at the problem. It doesn't seem easy to do, but it has to be done imho.

[conan]

Some time ago Lutz replied here (i searched for it, but couldn't find it) that it wasn't possible without making newLisp go slower. Also that given the nature of the two step parsing newLisp does, source line numbers get lost.

I'm quoting from memory so maybe this is not exactly what he said. But the general concept I got from there was: can't be done without making a poor quality newLisp.

So maybe the solution would be to provide a fat-newLisp version for development that does not loose this information.

Another possible solution would be to learn how the people who don't complain about this do their development. Maybe there's something we're missing there.

[Lutz]

Line numbers for errors definitely add to much resource usage for storing them and parsing and loading code would get slower. In my opinion its also just not necessary, I think the stack trace we have is much more usable.

One could build a better debugger using the current debugging facilities and reflective API offered by newLISP and without changing anything inside newLISP. The current debugger was built with the idea in mind, that it can be driven by and outside program. See the old Tcl/Tk based debugger and IDE shipped years back. I think it is still maintained by HPW on this forum.

Ps: in any case, welcome hacking newLISP internals, there are things which can be made faster, smaller or otherwise improved.

[conan]

One could build a better debugger using the current debugging facilities and reflective API offered by newLISP and without changing anything inside newLISP.

When you said that, do you mean it is possible to build a debugger which can point to the proper line of code ?

I think one of the big problems we newbies face with debugging newLisp is that if you have repeated code, debugger will point to the first place the code is used instead of the one producing the error. With that out of the way I believe we can ditch the line numbers request.

[Astrobe]

When you said that, do you mean it is possible to build a debugger which can point to the proper line of code ?

One can write an interpreter of newlisp in newlisp itself. It could load the file and keep track of the line numbers.

[Lutz]

I think one of the big problems we newbies face with debugging newLisp is that if you have repeated code, debugger will point to the first place the code is used instead of the one producing the error. With that out of the way I believe we can ditch the line numbers request.

This is fixed for the next version: The debugger will now always highlight the correct expression, not highlight the first one if multiple instances exist:

http://www.newlisp.org/downloads/development/inprogress

[conan]

Beautiful. Please don't die.

[csfreebird]

OK. I don't need error line number now because correct highlight is enough.
Thanks.

[Astrobe]

Debugging and error messages are still a weak point of Newlisp for me.

I could make it slightly easier by inserting a call to getDebuggerInput() at the end of printErrorMessage(). At least one can check the value of local variables, arguments, and even those of the callers if names don't overlap.

Can it be improved?