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.
Related
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.
In a quite simple test-case, the output of printf() is not shown, if the test fails. I use µunit as a framework and the test routine itself is trivial:
static MunitResult test(...)
{
// Some variable initialisation
printf("Test running...\n");
//Do the test
bool bResult = tested_method();
munit_assert(bResult == true);
}
If I comment out the assertion, i.e. the test succeeds, the printf-output is shown. It isn't if the test fails. Running other test routines works as expected and shows their output from printf() correctly.
I invoke ctest like this to run the test:
ctest -V --output-on-failure -R '.*nameoftest.*'
The whole is running inside a docker container on Windows 10.
How can I make ctest display all output the test-routine sends on stdout?
Thanks for your help and have a nice day!
The solution, in my case, was, to call the generated elf-executable directly, and not via ctest. It seems that ctest adds another layer of output-redirection which I wasn't able to circumvent. By calling the binary directly, I could get all the output and logs I desired.
This is not a direct solution to the problem, but a workaround I found acceptable.
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
THIS WORKED (see comment in the code)
I am new to MPI and still learning it. I am actually trying to write a code in Fortran to read data from same set of files (already generated) on each processor at same time and perform different computations in different processors. For which I decided to use,
program...
use mpi
implicit none
.
.
.
call mpi_file_open(mpi_comm_world,filename_i,mpi_mode_rdonly,mpi_info_null,i,ierr)
to start with the program. Now, each processor calls a subroutine in which I am trying to use normal fortran command to open files, open(i,*)...(since I don't use mpi in subroutine).
First, I am not confident about this idea itself. Next, it gives this error,
_open(mpi_comm_world,filename_i,mpi_mode_rdonly,mpi_status_ignore,i,ierr) (1)
Error: There is no specific subroutine for the generic 'mpi_file_open'
at (1)
Please give your suggestions and comments.
The thing I am trying to do is very long because of subroutine, I would just include a prototype code, if this is solved, my problem will be solved. The code below gives the same error as said before. Please give your suggestions. Thanks.
program hello
use mpi
integer::ierr,num_procs,my_id,i,j,no
call MPI_INIT(ierr)
call MPI_COMM_RANK (MPI_COMM_WORLD,my_id,ierr)
call MPI_COMM_SIZE (MPI_COMM_WORLD,num_size,ierr)
open(4,file='hella') !CHANGING THIS LINE
do i=1,num_size
if(i-1 .eq. my_id)print*,"In",my_id
if(i-1 .eq. my_id)then
read(4,*)no
print*,no
endif
enddo
call mpi_finalize(ierr)
end program hello
Is is there a programmatic way to test for errors in Avisynth scripts before seeing the black and red Error message in the output.
We are currently assembling Avisynth script files as a part of an automated encoding routine. When something goes wrong with Avisynth or the source file, Avisynth renders a big black and red error message. Our encoder sees this as a normal video file and keeps on encoding without raising an error.
What is the best way to check for these errors without actually being seeing the output from the video file.
AviSynth has support for try-catch: http://avisynth.org/mediawiki/Control_structures#The_try..catch_statement
I'm not sure how you would signal an error to your encoder from there. As far as I know you must return a clip from the script, and a return statement inside a try/catch block does not return from the entire script anways: http://avisynth.org/mediawiki/The_full_AviSynth_grammar#Closing_Remarks
You can however log error messages to text files, so I've seen people doing this to test an AVS script for error before running it:
script = "file_to_test.avs"
try {
Import(script)
} catch (err) {
WriteFileStart(BlankClip(), "C:\logfile.txt", script, """ ": " """, err, append=true)
}