**
I am pretty sure a set of sequential commands with same input cant
change it's output every time you run it
It might sound stupid . For example while installing an application or bulding using Cmake , atleast for me , i would encounter different bugs each time i run the installer using the same system.
I guess i might have changed the cmake setting or the system settings but it feels so strange and i am totally paranoid about it.
**.
you never initialize arr but you use it to do M=M-arr[i]; the behavior is undefined
out of that to use an array with a dynamic size is not recommended (ISO C++ forbids variable length array), allocate it in the heap
I am new in tensorflow and I am trying to run a basic program but I am getting the error while feeding the data into the model. I would like to debug it to pin point what is causing the error. I want to track the data in a node of the graph. When I am starting the tfdbg it throws the error "OutOfRangeError RandomShuffleQueue".
Is there any way to debug it from the start ? or can we put the breakpoint in the program ? I understand that the tensorflow program has a graph structure and it might not excecute like a normal python script.
Any help is appreciated.
To make it short,
can we put a breakpoint in a tensorflow program at the desired location to see the tensor values?
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 running my code on SWI Prolog and Windows 7. In my code, I call another application using 'win_exec()' (I tried using the method 'shell()', but it won't work.), and at the end produces its output in a text file. However sometimes it runs for times like 30 minutes. Now my prolog code uses this output text file, to further parse it and process it.
This is the code I use to call the other application and then use its output file:
main(Value,X) :- win_exec('C:\\myfolder\\external_app.bat C:\\myfolder\\outputfile.txt', normal),
open('C:\\myfolder\\outputfile.txt', read, Mf),
read_file(Mf, X), % PROCEDURE TO READ FILE CONTENTS
close(Mf),
statistics(cputime, Value). % CALCULATE HOW LONG IT TOOK
However, since the file has not been outputted by that another application, it gives the error:
ERROR: open/4: source_sink `C:\myfolder\outputfile.txt' does not exist (No such file or directory)
So, as a workaround, I try to catch the error, handle it by comparing with 'existence_error' and then recursively call the open procedure, until it finally succeeds i.e. the other application has completed its processing and the output file is produced. This is my workaround code for this:
main(Value,X) :- win_exec('C:\\myfolder\\external_app.bat C:\\myfolder\\outputfile.txt', normal),
open_output(X), % PROCEDURE FOR FILE EXCEPTION HANDLING
statistics(cputime,Value).
open_output(X) :- catch((open('C:\\myfolder\\outputfile.txt', read, Mf), read_file(Mf,X), close(Mf)),
error(Err,Context),
open_output_aux(Err,X)). % AUX PROCEDURE TO RECOVER
% Write some code here
% open_output_aux code matches the error code with 'existence_error';
% if true, calls open_aux_wait procedure; else throw the error.
open_aux_wait(Z):- catch((open('C:\\myfolder\\outputfile.txt', read, Mf), read_file(Mf,Z), close(Mf)),
error(Err,Context),
open_aux_wait(Z)).
However this seems to be very inefficient of way doing this. I wanted to know if there's any better way to do this, like in java, you could simply call wait() while handling file exception. In the documentation, there's a method 'wait_for_input\3' but it says 'wait_for_input()' cannot be used for File Streams in Windows. I tried using it, but it gives error.
Any help or guidelines is greatly appreciated.
You have several options to solve this:
You can totally reconsider the way that these processes communicate. For example, SWI-Prolog ships with very powerful HTTP libraries, and you can set up the communication between the two processes to work over HTTP, using a client/server architecture. In this case, you avoid the busy waiting that currently uses many CPU cycles unnecessarily.
A much more trivial solution is to simply insert a call of the built-in sleep/1 predicate to put the process to sleep before trying to open the file again. Use for example sleep(1) to put the process to sleep for 1 second.
Use for example process_wait/2 to wait until the called process has finished and generated the file.
From what you are describing, it looks like (2) will do, (3) is slightly more elegant, and (1) may be good to know in general, for more difficult cases.
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.