Given a positive number N, my print_even() function prints out all the even numbers between 1 and N:
-module(my).
-compile(export_all).
print_even(N) when N>0 -> even_helper(1, N).
even_helper(Current, N) when Current =< N ->
io:format("(Current = ~w)~n", [Current]),
case Current rem 2 of
0 -> io:format("Number: ~p~n", [Current]);
_ -> do_nothing
end,
even_helper(Current+1, N);
even_helper(Current, N) when Current > N ->
ok.
Here's some sample output:
28> my:print_even(10).
(Current = 1)
(Current = 2)
Number: 2
(Current = 3)
(Current = 4)
Number: 4
(Current = 5)
(Current = 6)
Number: 6
(Current = 7)
(Current = 8)
Number: 8
(Current = 9)
(Current = 10)
Number: 10
ok
Below is the code I'm using for a conditional break:
-module(c_test).
-compile(export_all).
c_break(Bindings) ->
case int:get_bindings('Current', Bindings) of
{value, 3} -> true;
_ -> false
end.
I set a conditional break on the following line in print_even():
case Current rem 2 of
...which according to the Erlang debugger docs should be legal. But no matter what I do, I can't get my c_break() function to execute. I expected execution to halt at the breakpoint when Current is equal to 3, but the code runs to completion, and the breakpoint is skipped. I even tried:
c_break(Bindings) ->
case int:get_bindings('Current', Bindings) of
_ -> true;
end.
But execution still won't halt at the breakpoint.
Update: I can get execution to halt if I use the following function for my conditional break:
c_break(_) ->
true.
If I change that to:
c_break(X) ->
io:format("~w~n", [X]),
true.
...then once again execution won't halt.
!##$!##$#!! It should be:
int:get_binding()
^
|
not:
int:get_bindings()
^
|
Even then, recompiling the module did not succeed in getting execution to halt. To get things to work, I had to quit the debugger: I closed all the debugger windows, then I issued the command:
82> debugger:stop().
ok
(I can't find any information for the function debugger:stop(), so I don't know if that is necessary or even does anything.)
Then I recompiled both modules:
83> c(my, [debug_info]).
{ok,my}
84> c(c_test).
{ok,c_test}
Then:
85> debugger:start().
{ok,<0.305.0>}
debugger:start() launches the Monitor window, and with the Monitor window active I chose the menu item:
Module > Interpret
...and I selected my.erl from the popup--where my.erl is the module containing the function where I want to halt execution.
Then with the Monitor window still active, I chose the menu item:
Break>Conditional Break
...and I filled in the information. You can also double click your module name displayed in the Monitor window, and then use the View Module window that opens to set breakpoints. The View Module window displays your source code, and the window also has a Break menu item, which allows you to set the various types of breakpoints. In the View Module window, you can use a shortcut for creating a Line breakpoint, i.e. a regular breakpoint: you can set a breakpoint by double clicking a line in your code.
Finally:
86> my:print_even(10).
(Current = 1)
(Current = 2)
Number: 2
(Current = 3)
Hurray!
Then I double clicked on the process listed in the Monitor window, and an Attach Process window opened. The Attach Process window shows where execution halted in your code, and it provides the means for you to step through the code.
Back in the Monitor window, if you check the checkbox On Break, then an Attach Process window will open automatically when execution halts at a breakpoint. As far as I can tell, you need to open a new Attach Process window every time you run your code.
By the way, the module name c_test and the function name c_break() can be any name. Their names are not important, for instance I changed the module name to conditional_breaks and the function name to break1().
Related
This program is not complete but is a work in progress.
import speech_recognition as sr
import subprocess as sp
import time, os
r = sr.Recognizer()
print("Voice Recognition Software\n\n******************************************************************************\n")
while True:
r.energy_threshold = 8000
t = None
with sr.Microphone() as source:
success = False
print (">")
audio = r.listen(source)
try:
print("Processing...")
t = r.recognize_google(audio)
print (": " + t)
except sr.UnknownValueError:
print("Unknown input")
continue
except sr.RequestError as e:
print("An error occured at GAPI\nA common cause is lack of internet connection")
continue
if "open" in t:
t = t.replace("open","")
t = t.replace(" ","")
t = t + ".exe"
print (t)
for a,d,f in os.walk("C:\\"):
for files in f:
if files == t.lower() or files == t.capitalize() or files == t.upper():
pat = os.path.join(a,files)
print (pat)
sp.call([pat])
success = True
if success == True:
continue
The problem I'm facing is that after > or Processing the program sometimes stops responding. No error messages or anything, in the shell it just prints > or Processing and stays there.
This happens randomly, the program can function continuously for a long time but at any given moment for whatever reason it freezes. Usually after a minute or 2 it moves onto the next part and starts responding again but that isn't always the case.
I've attempted to create a sort of fail-safe so if it takes too long to respond the program closes and opens again but I was unsuccessful with that so now I'm trying to figure out the root cause of the problem.
Can someone with experience with this sort of thing help me understand why this is happening?
Edit:
I was able to solve the problem. Turns out there is a timeout parameter here r.listen(source).
I was able to solve the problem. Turns out there is a timeout parameter here r.listen(source).
To debug the values of high frequency timers or sensors it would be useful to configure a breakpoint that only fires every x times. What's the best way to accomplish this?
I tried the "Ignore x times before stopping" option in Xcode but that only works for the first time. Can I reset this counter using an LLDB command?
You can reset the ignore counter at any time with:
(lldb) break modify -i <NEW_VALUE> <BKPT_SPECIFICATION>
Note, a breakpoint which doesn't satisfy its "ignore count" is not considered to be hit, so its breakpoint command does NOT get run. So if you wanted to stop every tenth the time you hit the breakpoint automatically, just do:
(lldb) break set -l 10 -i 10 -N my_bkpt
Breakpoint 1: where = foo`main + 46 at foo.c:10, address = 0x0000000100000f5e
(lldb) break com add
Enter your debugger command(s). Type 'DONE' to end.
> break modify -i 10 my_bkpt
> DONE
(lldb)
Then just hit "continue" at each stop and you will hit the breakpoint once every 10 times.
Note, I used the ability to name the breakpoint (the -N option) so I didn't have to know the breakpoint number in the breakpoint command that I added. That's convenient if you're going to store these breakpoints in a command file, etc.
Ref: Apple docs on Managing breakpoints. You can also do help breakpoint set command for a complete list of available options
I'm not sure you can define a persistent variable(counter) in lldb. You can always have one global var that you use as a counter helper and simply not include it in the release builds.
class BrCounter{
static var freq = 10
}
Edit the breakpoint and add the following condition:
BrCounter.freq--;
if(BrCounter.freq == 0){
BrCounter.freq = 10;
return true;
}else{
return false;
}
Oneliner:
BrCounter.freq--; if(BrCounter.freq == 0){ BrCounter.freq = 10; return true; }else{ return false; }
I dont have much experience with IDL but i need to fix a bug where in the compilation failure status needs to be returned to the calling script.
cat << ENDCAT > something.pro
PRINT, "Start"
PRINT, "Compiling functions needing early compile"
#do_early_func
PRINT, "Compiling remaining functions"
#do_other_func
PRINT, "Running: resolve_all"
resolve_all
EXIT
ENDCAT
setenv IDL_STARTUP something.pro
$IDL_DIR/bin/idl
The above content exists in a script called make_program which is called by another script called the build_script
The problem i am facing is that even if 'resolve_all' results in a compilation failure, the make_program always returns a true to the build_script making it think the compilation succeeded when it actually didnt. How can i return the failure status back to the calling script?
The EXIT routine has a STATUS keyword that can return the exit status of the script. So something like:
exit, status=status_code
To determine if RESOLVE_ALL completed correctly, you may need to do a CATCH block. The easiest way is probably to wrap RESOLVE_ALL in your own routine that has an ERROR keyword that returns whether the RESOLVE_ALL succeeded.
I'm not sure where I picked this up but you'll need two routines:
function validate_syntax_helper, routineName
compile_opt strictarr, hidden
catch, error
if (error ne 0) then return, 0
resolve_routine, routineName, /either, /compile_full_file
return, 1
end
and
function validate_syntax, routineName
compile_opt strictarr, hidden
oldquiet = !quiet
!quiet = 1
catch, error
if (error ne 0) then return, 0
; Get current directory
cd, current=pwd
o = obj_new('IDL_IDLBridge')
o->execute, '#' + pref_get('IDL_STARTUP')
; Change to current directory
o->execute, 'cd, ''' + pwd + ''''
; Validate syntax
cmd = 'result = validate_syntax_helper(''' + routineName + ''')'
o->execute, cmd
result = o->getVar('result')
obj_destroy, o
!quiet = oldquiet
return, result
end
You then call validate_syntax, which returns 1 when it can compile and 0 when it can't. I don't think this can be used from the IDL virtual machine since it uses execute, but maybe that doesn't matter to you. You'll have to manually run this on all your routines to be compiled instead of running resolve_all.
I am using Qt Ruby
How do I keep the value of a user entered QlineEdit to keep its state even after the program is closed, in that way, the user can access the contents the next time he opens the program.
Solution 1 - using File.write/read:
edit_widget = Qt::LineEdit.new(parent)
File.write(filename, edit_widget.text)
exit
After the program re-start:
text = File.read(filename)
edit_widget.setText text
Solution 2 - using QSettings:
settings = Qt::Settings.new(filename, Qt::Settings::NativeFormat)
edit_widget = Qt::LineEdit.new(parent)
edit_widget.text = "abcde"
settings.setValue("field1", Qt::Variant.fromValue(edit_widget.text))
settings.sync
exit
After the program re-start:
settings = Qt::Settings.new(filename, Qt::Settings::NativeFormat)
edit_widget = Qt::LineEdit.new(parent)
edit_widget.text = settings.value("field1").toString
The problem:
I've got a situation where we have a media playback during launch, and objc_exception_throw() hits about 5 times during that period, but is always caught, and it's way south of the media player object.
I'm tired of either (a) having to manually continue n times, or (b) having to leave breakpoints disabled until after the playback is complete.
What I've tried:
making the breakpoint ignore the first five hits (problem: it's not always exactly five times)
creating my own symbolic breakpoint using my target as the module (problem: nothing changed)
What I'd like to do:
One solution that comes to mind is to evaluate the stack when the breakpoint hits, and continue if a particular method or function is listed therein. But I have no idea how to do this.
Other ideas welcome as well.
You do it using Python.
The following defines an ignore list and a function you can attach as a command to a breakpoint.
The function grabs the names of functions in the backtrace and set-intersects those names with the ignore list. If any names match, it continues running the process. This effectively skips dropping into the debugger for unwanted stacks.
(lldb) b objc_exception_throw
Breakpoint 1: where = libobjc.A.dylib`objc_exception_throw, address = 0x00000000000113c5
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> ignored_functions = ['recurse_then_throw_and_catch']
def continue_ignored(frame, bp_loc, dict):
global ignored_functions
names = set([frame.GetFunctionName() for frame in frame.GetThread()])
all_ignored = set(ignored_functions)
ignored_here = all_ignored.intersection(names)
if len(ignored_here) > 0:
frame.GetThread().GetProcess().Continue()
quit()
(lldb) br comm add -F continue_ignored 1
(lldb) r
I tried it against the following file, and it successfully skips the first throw inside recurse_then_throw_and_catch and drops into the debugger during the throw inside throw_for_real.
#import <Foundation/Foundation.h>
void
f(int n)
{
if (n <= 0) #throw [NSException exceptionWithName:#"plugh" reason:#"foo" userInfo:nil];
f(n - 1);
}
void
recurse_then_throw_and_catch(void)
{
#try {
f(5);
} #catch (NSException *e) {
NSLog(#"Don't care: %#", e);
}
}
void
throw_for_real(void)
{
f(2);
}
int
main(void)
{
recurse_then_throw_and_catch();
throw_for_real();
}
I imagine you could add this function to your .lldbinit and then connect it to breakpoints as needed from the console. (I don't think you can set a script command from within Xcode.)
break command add -s python -o "return any('xyz' in f.name for f in frame.thread)"
If a python breakpoint command returns False, lldb will keep going. So this is saying: if any frame in the stack has the string 'xyz' in its name, then return True (to stop). Otherwise if no frame has that name, this any expression will return False (to keep going).