how to automatically break the lua program at the error line - zerobrane

I use my own interpreter to run the lua program and debug with zerobrane. If the interpreter encounters an error, how to let the debugger break at the error line?

There is no mechanism in Lua that allows to catch run-time errors. There was a call to debug.traceback function in Lua 5.1, but it's no longer called in Lua 5.2+. If you have your own error handling, you can call require("mobdebug").pause(), which will request ZeroBrane Studio debugger to stop on the next executable Lua line, which will allow you at least to see the stack trace and the location of the error, but this is probably all you can do. You can also try to assign debug.traceback to the function that calls pause, but, again, this will only work in Lua 5.1.
For example, try running the following script from the IDE:
require("mobdebug").start()
debug.traceback = function(...)
print("traceback", ...)
require("mobdebug").pause()
end
a()
print("done") -- it will never get here
If you save it into on-error.lua file and run, you should see the execution stopped on line 5 (after the pause()) call with the following message:
traceback on-error.lua:6: attempt to call global 'a' (a nil value) 2

Related

PyCharm Selenium not openening Chrome, "Process finished with exit code 0" [duplicate]

I am new to PyCharm and I have 'Process finished with exit code 0' instead of getting (683, 11) as a result (please see attachment), could you guys help me out please? Much appreciate it!
That is good news! It means that there is no error with your code. You have run it right through and there is nothing wrong with it. Pycharm returns 0 when it has found no errors (plus any output you give it) and returns 1 as well as an error message when it encounters errors.
Editors and scripts do not behave like the interactive terminal, when you run a function it does not automatically show the the result. You need to actually tell it to do it yourself.
Generally you just print the results.
If you use print(data.shape) it should return what you expect with the success message Process finished with exit code 0.
exit code 0 means you code run with no error.
Let's give a error code for example(clearly in the below image): in below code, the variable lst is an empty list,
but we get the 5 member in it(which not exists), so the program throws IndexError, and exit 1 which means there is error with the code.
You can also define exit code for analysis, for example:
ERROR_USERNAME, ERROR_PASSWORD, RIGHT_CODE = 683, 11, 0
right_name, right_password = 'xy', 'xy'
name, password = 'xy', 'wrong_password'
if name != right_name:
exit(ERROR_USERNAME)
if password != right_password:
exit(ERROR_PASSWORD)
exit(RIGHT_CODE)
I would recommend you to read up onexit codes.
exit 0 means no error.
exit 1 means there is some error in your code.
This is not pyCharm or python specific. This is a very common practice in most of the programming languages. Where exit 0 means the successful execution of the program and a non zero exit code indicates an error.
Almost all the program(C++/python/java..) return 0 if it runs successful.That isn't specific to pycharm or python.
In program there is no need to invoke exit function explicitly when it runs success it invoke exit(0) by default, invoke exit(not_zero_num) when runs failed.
You can also invoke exit function with different code(num) for analysis.
You can also see https://en.wikipedia.org/wiki/Exit_(system_call) for more details.
What worked for me when this happened was to go to
Run --> Edit Configurations --> Execution --> check the box Run with
Python Console (which was unchecked).
This means that the compilation was successful (no errors). PyCharm and command prompt (Windows OS), terminal (Ubuntu) don't work the same way. PyCharm is an editor and if you want to print something, you explicitly have to write the print statement:
print(whatever_you_want_to_print)
In your case,
print(data.shape)
I think there's no problem in your code and you could find your print results (and other outputs) in the tab 5: Debug rather than 4: Run.
I just ran into this, but couldn't even run a simple print('hello world') function.
Turns out Comodo's Firewall was stopping the script from printing. This is a pretty easy fix by deleting Python out of the Settings > Advanced > Script Analysis portion of Comodo.
Good Luck
I had same problem with yours. And I finally solve it
I see you are trying to run code "Kaggle - BreastCancer.py"
but your pycharm try to run "Breast.py" instead of your code.
(I think Breast.py only contains functions so pycharm can run without showing any result)
Check on tab [Run] which code you are trying to run.
Your starting the program's run from a different file than you have open there. In Run (alt+shift+F10), set the python file you would like to run or debug.

Debugging suspended at 'mobdebug.start():1' (couldn't activate the file)

I am trying to use Remote Debugging of ZeroBrane to debug my application.
I don't want users add any extra codes to their scripts. So when a user click the debug button, at the C side, first, I set the path and call the mobdebug lib, then I try to execute the user code:
luaL_dostring(L, "package.path = package.path .. ';./scripts/lualibs/mobdebug/?.lua;./scripts/lualibs/?.lua'");
luaL_dostring(L, "package.cpath = package.cpath .. ';./scripts/bin/clibs/?.dll'");
luaL_dostring(L, "mobdebug = require('mobdebug').start()");
luaL_dofile(L, FileName);
It works fine for the official lua 5.1 intepreter. The debugger stops at line 1 of the source file. But if I switch to luajit, the zerobrane prompts "Debugging suspended at 'mobdebug.start():1' (couldn't activate the file).". Then I click "step over", the script file can be activated and the debugger stops at line 1.
Is there any way to skip the error message and directly activate the source file when using luajit?
You may want to set debugger.runonstart = true to continue execution without stopping at the first line (documentation), but you will need to use breakpoints or Project | Break to suspend the execution when the debugging is started.

Why don't I get output from Debug.log in an infinite loop in the Elm REPL?

I'm debugging some code with an infinite loop, but it's difficult, because I can't get any log messages out. Here's a simplified case:
import Debug exposing (log)
f x =
let _ = log "Hello, world!" ()
in f x
If I run this at my Elm REPL like f (), it infinitely loops and never prints out "Hello, world!" as I expect it to.
I looked at the implementation of Debug.log (following it to Native.Debug.log), but it just seems to be calling process.stdout.write or console.log synchronously, so I'm surprised that I'm not seeing any output.
This is just a bug in the Elm REPL.
The Problem
I dove into the implementation of the Elm REPL. The relevant function is here: Eval.Code.run
This run function seems to be the function that executes a piece of code. It looks like each line of code is executed in a subprocess, via Elm.Utils. unwrappedRun. There are two problems with the way it runs it:
The stdout of the subprocess is not streamed; it's only returned once the whole subprocess is done. So as long as you're waiting for your code to finish evaluation, you won't see anything.
If you hit ctrl-c to end evaluation prematurely (which works fine, and returns you back to the Elm prompt), the Elm Repl ignores the stdout that is returned to it. Notice the pattern match for CommandFailed:
Left (Utils.CommandFailed _out err) ->
throwError err
The Utils.CommandFailed result helpfully includes the stdout (which is being bound to _out), but this code ignores it and just throws the error.
So basically this isn't anything that weird going on with the Elm compiler or runtime, just that the REPL isn't as good as it could be with respect to logged results.
The Workaround
As a workaround, in order to debug things like infinite loops, you can
put some test code in a new file, Scratch.elm, like x = f ()
compile the code with elm-make Scratch.elm --output scratch.js
run the code with node scratch.js
Then output will be streamed to your terminal.

Return code/Exit status of the WebPICmd.exe

Is there a way to detect the exist status of WebPICmd.exe (Command line version of WebPlatformInstaller), so that I can use it in my script.
I need to know if installation of particular product succeeded or not. (Trying to install PHP53, which seems to fail randomly due to download failures)
This can be detected using $LASTEXITCODE variable in PowerShell.
In dos mode it should be LASTERRORLEVEL.
Remember to check this variable immediately after running the WebPICmd.exe so that it's return code is not overwritten by something else down the line.

ActiveTCL - Unable to run a batch file from an Expect Script

I was originally trying to run an executable (tftpd32.exe) from Expect with the following command, but for some unknown reason it would hanged the entire script:
exec c:/tftpd32.351/tftpd32.exe
So, decided to call a batch file that will start the executable.
I tried to call the batch file with the following command, but get an error message stating windows cannot find the file.
exec c:/tftpd32.351/start_tftp.bat
I also tried the following, but it does not start the executable:
spwan cmd.exe /c c:/tftpd32.351/start_tftp.bat
The batch file contains this and it run ok when I double click on it:
start tftpd32.exe
Any help would be very much appreciated.
Thanks
The right way to run that program from Tcl is to do:
set tftpd "c:/tftpd32.351/tftpd32.exe"
exec {*}[auto_execok start] "" [file nativename $tftpd]
Note that you should always have that extra empty argument when using start (due to the weird way that start works; it has an optional string in quotes that specifies the window title to create, but it tends to misinterpret the first quoted string as that even if that leaves it with no mandatory arguments) and you need to use the native system name of the executable to run, hence the file nativename.
If you've got an older version of Tcl inside your expect program (8.4 or before) you'd do this instead:
set tftpd "c:/tftpd32.351/tftpd32.exe"
eval exec [auto_execok start] [list "" [file nativename $tftpd]]
The list command in that weird eval exec construction adds some necessary quoting that you'd have trouble generating otherwise. Use it exactly as above or you'll get very strange errors. (Or upgrade to something where you don't need nearly as much code gymnastics; the {*} syntax was added for a good reason!)