(Very new to AHK, so sorry if this sounds very stupid/trivial)
I have a small AHK script (see below) with a variable called var. I would like to call and modify this variable from within multiple hotkeys. However, even when trying to "yield" its value (with the F8 hotkey) the value doesn't get printed. How can I go about with this?
#SingleInstance, force
+Escape::ExitApp
!r::Reload
!p::Suspend
var := 42
F8::
MsgBox % "Var value is " . var . "."
Return
;F12::
;blabla not relevant yet
Your variable declaration is unreachable code.
The code execution stops when the first hotkey label is encountered. This is called the Auto-execute Section.
Move your hotkey definition to be at the very bottom.
(All hotkeys defined by hotkey labels always get created regardless of being in the auto-execute section or not)
And as a bonus, the concatenation operator . is redundant, you don't need to use it, you can just leave it out.
(Unless you prefer to use it, of course)
Related
I'm trying out generics in swift an came across something unusual while debugging:
instead of printing out the value assigned to the variable, it just prints something different. Heres the example code:
class GenericExample<T: Comparable>{
var someVar: T
init(myVar: T){
someVar = myVar
}
}
let generics = GenericExample<Int>(myVar: 57)
print(generics.someVar)
the result is fine(57) but when running the program for debugging, as in with breakpoints, the value is presented as something like 4301684792
any tips would be appreciated
Don't examine, in the debugger, the value of a variable whose value is not assigned until the line you're breakpointed in or later. That line has not been executed yet, so you will see a random value! (Namely, whatever happens to be sitting in memory at that address.)
Only examine earlier variable values! And don't even look at the little tooltips that pop up. Look only at the variables pane and the lldb console.
When creating a tracepoint in Visual Studio (right-click the breakpoint and choose "When Hit..."), the dialog has this text, emphasis mine:
You can include the value of a variable or other expression in the message by placing it in curly braces...
What expressions are allowed?
Microsoft's documentation is rather sparse on the exact details of what is and is not allowed. Most of the below was found by trial and error in the Immediate window. Note that this list is for C++, as that's what I code in. I believe in C#, some of the prohibited items below are actually allowed.
Most basic expressions can be evaluated, including casting, setting variables, and calling functions.
General Restrictions
Only C-style casts supported; no static_cast, dynamic_cast, reinterpret_cast, const_cast
Can't declare new variables or create objects
Can't use overloaded operators
Ternary operator doesn't work
Can't use the comma operator because Visual Studio uses it to format the result of the expression; use multiple sets of braces for multiple expressions
Function Calls
Prohibited calls:
Lambdas (can't define or call them)
Functions in an anonymous namespace
Functions that take objects by value (because you can't create objects)
Permitted calls:
Member functions, both regular and virtual
Functions taking references or pointers, to either fundamental or class types
Passing in-scope variables
Using "&" to pass pointers to in-scope variables
Passing the literals "true", "false", numbers
Passing string literals, as long you don't run afoul of the "can't create objects" rule
Calling multiple functions with one tracepoint by using multiple sets of braces
Variable Assignment
Prohibited:
Objects
String literals
Permitted:
Variables with fundamental types, value either from literals or other variables
Memory addresses, after casting: { *(bool*)(0x1234) = true }
Registers: { #eip = 0x1234 }
Use Cases
Calling functions from tracepoints can be quite powerful. You can get around most of the restrictions listed above with a carefully set up function and the right call. Here are some more specific ideas.
Force an if
Pretty straightforward: set up a tracepoint to set a variable and force an if-condition to true or false, depending on what you need to test. All without adding code or leaving the debug session.
Breakpoint "toggling"
I've seen the question a few times, "I need to break in a spot that gets hit a lot. I'd like to simply enable that breakpoint from another breakpoint, so the one I care about only gets breaks from a certain code path. How can I do that?" With our knowledge above, it's easy, although you do need a helper variable.
Create a global boolean, set to false.
Create a breakpoint at your final destination, with a condition to break only when the global flag is true.
Set tracepoints in the critical spots that assign the global flag to true.
The nice thing is that you can move the tracepoints around without leaving the debugging session. Use the Immediate window or the Watch window to reset your global flag, if you need to make another run at it. When you're done, all you need to clean up is that global boolean. No other code to remove.
Automatically skip code
The EIP register (at least on x86) is the instruction pointer. If you assign to it, you can change your program flow.
Find the address of the line you want to skip to by breaking on it once and looking at the value of EIP, either in the Registers window or the Watch window with "#eip,x". (Note that the value in the Registers window is hex, but without the leading "0x".)
Add a tracepoint on the line you want to skip from, with an expression like {#eip = address}, using the address from step 1.
EIP assignment will happen before anything on the line is executed.
Although this can be handy, be careful because skipping code like this can cause weird behavior.
As Kurt Hutchinson says, string assignment is not allowed in a tracepoint. You can get around this by creating a method that assigns the string variable, and call that.
public static class Helper
{
public static void AssignTo(this string value, out string variable)
{
variable = value;
}
}
Then in your tracepoint message:
{"new string value".AssignTo(out stringVariable)}
Is it possible to detect when the value of a variable has changed using the lua debug library.
Something like A callback function which would give details like the function in which the value was changed, previous value, etc.
Is such a thing possible?
I read about hooks, but I'm not sure hooks can be set to variables.
If you don't mind using a debugger, then some debuggers allow you to set Watch expressions, which will be triggered when the condition in the expression is true. I'll show how this can be done in MobDebug (it is using lua debug library, but there is no direct way to detect a variable change as far as I know).
Let say we have a script start.lua like the one below and want to detect where foo gets value 2:
print("Start")
local foo = 0
for i = 1, 3 do
local function bar()
print("In bar")
end
foo = i
print("Loop")
bar()
end
print("End")
Download mobdebug.lua and make it available to your scripts (the simplest way is to put it into the folder with your scripts).
Start the server using lua -e "require('mobdebug').listen()" command.
Start the client using lua -e "require('mobdebug').loop()" command.
You will see the prompt in the server window: '>'. Type load start.lua to load the script.
Type step and then step again. You will see "Paused at file start.lua line 3".
Let's see what the value of foo is. Type eval foo and you should see 0.
Now we can set up our watch. Type setw foo == 2. You can specify any Lua expression after setw command; the execution of your script will be stopped when the condition is evaluated as true.
Continue execution of the script using "run" command.
The watch now fires, which will show you the message like: "Paused at file start.lua line 8 (watch expression 1: [foo == 2])". This means that the previous expression changed the value of foo to 2 and the execution is stopped at line 8. You can then inspect your script and the current values (you can use "eval" and "exec" commands to run any Lua code to be evaluated in your script environment) to find what triggered the change.
The benefit of this approach is that you are not limited to monitoring table values and can specify any expression. The main disadvantage is that your script runs under a debugger and the expression is evaluated after each step, which may get really slow.
You can do this to a certain extent in Lua by using metatables and keeping a "proxy" table, and using the __newindex function call to detect attempts to add a variable.
This is covered here in the Programming in Lua book under the section "Tracking Table Accesses":
http://www.lua.org/pil/13.4.4.html
See Also
http://www.gammon.com.au/forum/?id=10887
I am operating a huge code base and want to monitor a value of a particular variable (which is buried deep down inside one of the files)especially when it gets set to zero.
1) Variable does not belong to global scope .Is there a better option than to first set breakpoint into the function where it is defined and then set the watch point?
2) After trying the option in 1 I see that watch point gets deleted after a while saying its out of frame which used this .This way it adds to the tediousness of the procedure since I have to add it again and again?Any workarounds?
3) Is there a way to check ie watch if a particular variable is equal to 0( or any specific constant)?
want to monitor a value of a particular variable
Often this is not the best approach, especially in large codebases.
What you really likely want to do is understand the invariants, and assert that they are true on entry and exit to various parts of the code.
1) Variable does not belong to global scope .Is there a better option than to first set breakpoint into the function where it is defined and then set the watch point?
No. For automatic (stack) variables you have to be in the scope where the variable is "active".
What you can do is set a breakpoint on some line, and attach commands to that breakpoint that will set the watchpoint automatically, e.g.
(gdb) break foo.c:123
(gdb) commands 1
silent
watch some_local
continue
end
3) Is there a way to check ie watch if a particular variable is equal to 0
You can't do that with a watchpoint, but you can with a conditional breakpoint:
(gdb) break foo.c:234 if some_local == 0
I will assume that you are using Linux. You can try this:
The first step is to make the variable static, like:
static int myVar;
Then, after compiling your code using -ggdb, you must discover the address of the variable inside your binary, like so (I have used a real case as example):
readelf -s pdv | grep tmp | c++filt
In my situation, the output is:
47: 081c1474 4 OBJECT LOCAL DEFAULT 25 startProc(int)::tmp
The address in this case is 081c1474. Now you can set a watch point inside GDB:
watch *0x081c1474
Mind the "*0x" before the correct address.
I know this question is old, but I hope it helps anyway.
I have a method which returns a block. I want to add a breakpoint inside the block. In Xcode adding a breakpoint on a line that's inside the block causes execution to pause when the method is returned and not when the block is executed. How do I add a breakpoint inside a block?
I had the same difficulty, until I tried using Xcode 4's LLDB debugger (go to Product>Edit Scheme to turn it on). Perhaps you'll have better luck with it.
From the documentation
You can set breakpoints and single step into blocks. You can invoke a block from within a GDB session using invoke-block, as illustrated in this example:
$ invoke-block myBlock 10 20
If you want to pass in a C string, you must quote it. For example, to pass this string into the doSomethingWithString block, you would write the following:
$ invoke-block doSomethingWithString "\"this string\""