) if v then local text = ( "%i" ): format ( v ) assert ( tonumber ( text ) = v, "Formatting didn't work!" ) print ( text ) So we can split line 3 in two parts and add a test in the middle which tells us if the formatting code works as intended.įunction draw ( v. There is either a formatting error or print() is not printing everything.Īssert() can help here: When the first argument is true, it does nothing, else it throws an error with its second argument as a message. In the previously removed debug output we could see that the value of v is 4.5 but on the screen it is 4. Looks good, doesn't it? Let's remove the debug output again: We should better check the line where 'draw' is initially called: Here we can see that the table is already part of the four original arguments. )) if v then print (( "%i" ): format ( v ))ĭraw (.) end print ( "end draw" ) end print ( "before draw" )ĭraw ( 1, 2, 3, ) print ( "after draw" ) ) print ( "begin draw" ) print ( "v=", v ) - debug output With so many numbers being thrown around its best if you add the name of each value and describe what is happening:įunction draw ( v. V indeed is a table on the fourth call before it is used in function 'format'.įor complete information you should print the other function arguments, too. If v then print (( "%i" ): format ( v )) - normal output For more complicated projects it might be a good idea to write to a file or even create a whole library around it.įunction draw ( v. We still don't know where this value really came from. Staring at the code and error message didn't solve the problem. It is possible to get a traceback without an error by running aceback() within Lua. The process library of OpenOS called a function without name created in file /lib/a, line 80. It called the named function 'xpcall' defined in the builtin file 'machine'. (Therefore we don't get much info.) Of course this function also calls other functions. But this one is written in C and not in Lua. It called a function also called 'xpcall'. This is the point where our file has been executed. 'draw' which displays its first argument and calls itself with the remaining arguments. This process of solving part of the problem and calling itself to solve the remaining problem is called 'recursion'. It is a very powerful concept in programming. This is the line where the (originally) fourth value is supposed to be printed. *You can continue to read left->right/top->bottom.* This function throws the error because it detected the wrong type of its parameters. The value is prepared within the C function 'format'. *You need to read it from the bottom to the top.* (It also stores local functions.)Ī traceback is a human readable printout of this data. The stack is a part of the memory Lua uses to remember where to jump back to after returning from a function. To understand that it might be good to read the stack traceback. It contains the location where the error message comes from:īad argument #1 to 'format' (number expected, got table) - You called the function 'format' but the type of its first argument - 'v' - was 'table' and not 'number' as the function expected. a:3: bad argument #1 to 'format' (number expected, got table): ) if v then print (( "%i" ): format ( v )) This is a program that should print 4 numbers:įunction draw ( v. It helps.īeware of the Heisenbug which only appears when you are not watching it! -) This makes it very easy to see the bug in action. If the program had no trouble on a T3 screen but crashes on a T1 screen there might be something involving the resolution or color depth. Maybe the work you did before opening *this* file did not have anything to do with your bug.Īlso try some variations to find out if this bug needs a specific setup or if it happens in a more general use case. Test this instruction yourself and try to find ways to make it as short as possible. Write down every step of what you did to reach the bug. It is very good manners to add a step by step instruction to your bug report: This is something that does not necessarily require programming. So step one in debugging is finding a way to reproduce the bug. If you spot an error or miss some content: Please tell me!Įven with maxed out debugging skills you are going to have a hard time fixing a bug if you can't see it. I could use your help to improve this guide. This guide is meant to introduce you to several useful debugging techniques with the primary focus being OpenComputers and Lua. This can be fun and inspiring but most often it is just frustrating. More often than not something is not working as intended and sometimes your program just crashes the instant you run it. Writing code is one thing, making it work is a completely different story.
0 Comments
Leave a Reply. |