Errors

[eddier]

Lutz,



I think the best addition to newLisp would be for the interpreter to give the line number where an error occurs.  I know this adds a little overhead counting "n"s, but for me, this would be a huge timesaver.



It's kind of hard finding the culprit when given

Code Select Expand

String expected in function format

and I've got about twenty or so in a program. I've got a data type error somewhere????



Oh BTW, Thanks kazemori for helping Lutz with the documentation. I've been meaning to go through the documentation but never have the time.



Eddie[/code]

[Lutz]

newLISP compiles source code to an internal lisp-cell-expression based binary format. There is no easy way to supply line numbers without inflating memory usage considerably (similar to 'debug' builds in 'C').



But! there are two forms of error routines: errorProc() which only reports the type of error, the other errorProcExt(), which can supply extra information.



I can go through all the errorProc() and see if there are more places where that extra infor can be supplied i.e.: longer source pieces for parse errors, the arguments a function has been called with, etc.. The richer form of error reporting was introduced later in the develpopment, so there are more places where the second form is applicable.



Lutz

[eddier]

Thanks!



I generally build a program one function at a time, testing as I go. But sometimes functions interact in a way I haven't predicted (generally with function parameters and data types) and then the bug hunt is on. I like your debug function except that it is awkard with cgi, where I generally have to wire in some hypothetical url. I've found that many of my errors are due to the (format function with the wrong data types. Sometimes I get segment faults due to the internal C function vsprintf or vsnprintf (I assume). Maybe I should start using the (string ) function more often?



Eddie

[Lutz]

yes, 'format' is one of the few functions, which are not safe and are able  to crash the system when passing non-string parameters to '%s' format specifiers because the 'C' function sprintf() is used..  String is always safe, but  also not as comfortable to use as 'format' in some situations.



Lutz

[CaveGuy]

AutoLISP barfs up its stack to the console when it blows up, while it is not a grecefull exit, it leaves little doubt as to where it the code things went wrong. An error dump would not require any line numbers :)

[Lutz]

since 7.1.6 error messages also report  the expression argument of a function, which made the function fail. This somewhat improves the possibility to find the source of an error.



Error reporting in a VM language like newLISP is a tradeoff against performance. newLISP doesn't have a call stack, which I could report on; adding a call stack for error reporting would decrease speed and increase memory usage.



I think that we have a good balance on that tradeoff at the moment.



Lutz

[CaveGuy]

I will have to check it out,

I am still running on 7004 :(

Guess it is time I get caught back up again...

[Lutz]

Look into the development directory and grep 7.1.12.



Also: I will try to add the calling userdefined function the error reporting. At this moment only the built in function is reported. That could be done without adding much overhead and may help.



Lutz

[eddier]

The debug function generally works well. It seems the only place I have problems finding erros is    iin the format function which I use many in every program I write. I don't catch all of the data type conversions, and hence, I get a segment fault before I can see what is going wrong.



BTW, I like the new "if" format :)



How is kazemori coming along with the newlisp manual?



Eddie

[Lutz]

the 'format' crash on wrong parameter string types could only be solved developing newLISP's own printf() 'C' function, which would check types. Perhaps somebody knows such a small printf()  implementation which could be used/modified???



reporting the userdefined function in an error came out nice and without a performance hit. A new version 7.2.0 containing all the improvments since 7.1.4 will be released today or tomorrow.



the 'format' crash on wrong parameter types could only be solved rolling newLISP's own printf() 'C' function, which would check types. Perhaps somebody knows such an implementation???



Overall 7.2.0 grew less than 1% in size but overall 5% in speed



Lutz

[eddier]

I doubt the typesafe "C" printf function exists. If I remember correctly, all variable argument functions depend on va_start, va_arg, and va_end. I believe that printf and variants, determine the number and type of arguments from the format string. However, all we can get from the stack on a "C" call is the stack size. I don't see any way of determining the boundaries of each argument since a double takes 8 bytes, an int takes 4 bytes, etc... to determine the actual types of the arguments themselves to ensure the arguments match the string format.



Eddie

[Lutz]

propbably the best thing would be to just parse the format string for well-formed-ness and looking for the positions of string formats to verify the correct type of lisp parameters for those. Then pass on everything to the 'C' function.



I'll have to look into the documentation of printf formats, perhaps we just go with those mentioned in the newLISP reference, forgetting about other fancy stuff. Then it would be relatively short to code. What do you think?



Lutz

[eddier]

I a agree, check the types of the lisp parameters against the format string. My suggestion for types are "s,c,d,x,f,g, and %."  "g" wasn't in the manual, however, I don't see any need for "u" or a preceeding "l."



Eddie

[CaveGuy]

I got It and I love it !!!!!



list or string expected : (set 'temp (assoc "FileID" cgi-in))

just saved me much much time !!!



debugging cgi's just became soo..much easier !

Count one more happy camper here :)



Thanks :)

[Lutz]

Another way to debug CGI files is to execute them in a console window. If the CGI file is getting parameters from a GET request, it will simply hang on a 'read-line', which is trying to get the HTTP query-string via STDIN.



At this moment you just hit enter or enter the query string from the GET request (everything after the ? mark).



All the output now goes to the console. You can try this with the file 'form.cgi' in the newLISP distribution. Run it in a console window. It will stop after outputting a header and some HTML, now enter: mode=some&any=thing (or any query string) and hit enter.



If you have a longer more complex query string or a multi-line POST request, just put the request in a file and do 'form.cgi < input', where input is the file containing your GET or POST request.



Lutz