Lua features hook call BEFORE every processed line. What I need is a call AFTER line is processed, so that I can check for encountered errors and so on. Is there a way to make such kind of call?
Otherwise things get a little bit confusing if error is encountered at the last line of the script. I don't get any feedback.
UPDATE #1
We want to catch both Lua errors and 'our' errors asserted via lua_error(*L) C interface, and Lua should throw correct debug info including the line number where the error occurred.
Using return hook we always get error line number -1, which is not what we want. Using any combination of pcall and any hook setup after lua_error(*L) we get either line number -1, or number of the next executed line, never a correct one.
SOLUTION#
We managed to make everything work. The thing was that Lua throws a real C exception after it detects an error, so some of our 'cleaning & finalizing' C code called from Lua operation did not execute, which messed up some flags and so on. The solution was to execute 'cleaning code' right before calling lua_error(...). This is correct and desired Lua behavior as we really want to stop executing the function once lua_error(...) is called, it was our mistake to expect any code would be executed after lua_error(...) call.
Tnx Paul Kulchenko, some of this behavior was found while trying to design a simple example script which reproduces the problem.
Try setting a return hook: it'll be called after the last line is executed.
I'm not sure debug hook is the best solution for what you are trying to do (or you need to provide more details). If you just need to check for run-time errors, why use debug hooks at all if you can run your code with pcall and get an error message that points to the line number where the error happened (or use xpcall, which also allows you to get a stack trace)? You can combine this with debug.getinfo(func, "L") to get a table whose indexes are valid line numbers for the function.
Related
I'm sure most Windows developers are familiar with this error message, usually when trying to mix 32- and 64-bit executables. In particular Python and Java can both get it.
%1 is not a valid Win32 application.
It's clear that %1 represents the first argument to the failing command - i.e. the executable that is trying to be loaded - but why does it not get filled in with the actual path?
Is it something that the caller is doing wrong, or is it a basic failing of some Windows subsystem that cannot be fixed for compatibility reasons?
The error message comes from Windows itself, you can see the complete list at System Error Codes (0-499). You translate an error code returned by the API into a message using FormatMessage, which has an optional Arguments array; any %1 in the message will be replaced by the first element in this array. If nothing is passed for the arguments, the %1 will be left unchanged if the FORMAT_MESSAGE_IGNORE_INSERTS flag was used or the FormatMessage will fail if it wasn't (thanks to IInspectable for that information).
As an example of how this might get missed, consider code where an error code gets converted immediately to an exception. If the exception contains the error code but nothing else, then there is no context for knowing what to pass to FormatMessage.
The caller is doing everything right. They are calling FormatMessage, passing along the FORMAT_MESSAGE_IGNORE_INSERTS flag1), like everyone should. The caller is not in control of the message that gets created, and has no way of knowing, that it should pass additional arguments, what types they should be or how many.
This was an early design bug in the Windows error reporting system, and you'll see those placeholders in every well-behaved application.
1) See The importance of the FORMAT_MESSAGE_IGNORE_INSERTS flag.
I am triggering scenarios by calling startcmd.sh OdiStartscen it executes the scenario, but I would like to know if this execution failed or successed without checking the ODI.
Is there a way to elevate return code from OdiStartScen to startcmd.sh
Thanks,
Isn't it as simple as in case of any other OS command?
Once successful any OS should internally return success code (0 in linux) back to the parent process. Otherwise it would be error code (non-zero).
That means you simply need to handle 'success' and 'failure' paths in your ODI package (green and red lines). Simply put some nonsense in the startcmd.sh OdiStartScen call for some quick test so see if it behaves as expected in case of failures. Alternatively you may use same step for both paths (red and green) and test using getPrevStep() function for errors (cf. STATUS property).
Two things worth mentioning:
This makes only sense for synchronous calls (so it waits for your Scenario to finish).
Why don't you use ODIStartScen() as an ODI Tool type of package/procedure step instead? Seems lot more elegant. Same answer applies.
I am trying to isolate the cause of an error. The interpreter give "bad argument type" and a call history of 16 identical lines: <eval> [procedure name] (sexpr). However, this procedure is call from many different places in the program. Is there a way to find out which one of these locations is the source of the problem without going thru the time consuming process of putting print calls in front of each and every possible candidate?
you can use the debug egg and change your procedure to first call trace.
Otherwise you could try and compile it with
csc --debug 2 <foo.scm>
I am trying to understand the code in this page: https://github.com/corroded/git-achievements/blob/gh-pages/git-achievements
and I'm kinda at a loss on how it actually works. I do know some bash and shell scripting, but how does this script actually "store" how many times you've used a command(im guessing saving into a text file?) and how does it "sense" that you actually typed in a git command? I have a feeling it's line 464 onwards that does it but I don't seem to quite follow the logic.
Can anyone explain this in a bit more understandable context?
I plan to do some achievements for other commands and I hope to have an idea on HOW to go about it without randomly copying and pasting stuff and voodoo.
Yes on 464 start the script, everything before are helping functions. I dont know how it gets installed, but I would assume you have to call this script instead of the normal git-command. It just checks if the first parameter is achievement, and if not then just (regular) git with the rest parameters is executed. Afterwards he checks if an error happend (if he exits). And then he just makes log_action and check_for_achievments. log_action just writes the issued command with a date into a text file, while achievments scans for that log file for certains events. If you want to add another achievment you have to do it in this check_for_achievments.
Just look how the big case handles it (most of the achievments call the count_function which counts the # usages of the function and matches when a power of 2 is reached).
I'm debugging a matlab script that takes ~10 minutes to run. Towards the end of the script I do some i/o and simple calculations with my results, and I keep running into errors. Is there a way to start matlab from a certain sport in a script after it exits with an error--the data is still in the workspace so I could just comment out all of the code up until the error point, but I'm wondering if anyone knows a better way to go about doing this without rerunning the entire script (the ultra-lazy/inefficient way)?
Thanks,
Colorado
Yes, use dbstop. Type dbstop if error and then run your script. The minute it hits an error, it will create a breakpoint there and you're in the workspace of the script --- which means you can debug the error, save data ; anything you want! Here's a snippet from the documentation for dbstop if error --- there are other ways to do dbstop, so do check it out:
dbstop if error
Stops execution when any MATLAB program file you subsequently run produces a run-time error, putting MATLAB in debug mode, paused at the line that generated the error. The errors that stop execution do not include run-time errors that are detected within a try...catch block. You cannot resume execution after an uncaught run-time error. Use dbquit to exit from debug mode.
Double percent signs will enable 'cell mode' which lets you run little blocks of code in steps. Sounds like just what youre looking for.