Let's say there is some object I want to keep an eye on, meaning I want to know the current values of the member fields of this object while I use my app - can I do that somehow without having to set a breakpoint within some routine that has a reference to this object?
for Example, is it somehow possible breaking with the debugger in the moment the object is created, but then somehow keep an open view to this particular object within the debugger to see how variables change?
I know it's possible to set Watchpoints that will break whenever a variable changes, but that becomes very difficult to work with for variables that change very frequently - I'd rather have a live view of the objects content.
Hope the question is understandable.
Good thought. Its been a long time after the question asked.
Off course it it possible. You can use watchpoints in Xcode 5 onwards. Watchpoints will pause the program if the value is getting accessed.
You can set the watchpoints in two ways as given below.
(1) Use the following LLDB command
(lldb) w s v self->_your_variable
(2) Select the left debugging pane. select the variable you want to watch, then select on option Watch "_your_variable".
Hope this will help you.
Related
I'm very new to xcode.
I need to know what my variables all look like. I'm writing a program for homework that constantly takes in user input in a while loop.
During a normal breakpoint the variables are visible, however when I get into an fgets call the variable viewer window is empty while it waits for the input.
I need to know what my variables look like but I don't need a breakpoint because I need to keep passing in input. How do I do that?
Edit: guys my homework is getting due soon and I'm having trouble fixing this. I need to know the answer to this question because I'm having trouble debugging my program and Google searches haven't helped me at all
NetLogo being interactive makes debugging easy, but I yet to find any tools available for setting breakpoints and stepping through code.
Please guide me if such exist. Or I can achieve the same with the current setup available.
I am not aware of such a tool if one exists. For debugging I use meaningful print statements. First I make a switch as a global parameter to set the debug mode on and off, then I add a statement to each method that prints which method updates which variable and in which order they were called (if debug mode is on).
I also use profiler extension which shows how many times each method was called and which one is the most or least time consuming one.
Not existing currently. Still, you can use one of the alternatives from above or you might take a look at user-message (https://ccl.northwestern.edu/netlogo/docs/dictionary.html#user-message), which will pop up a dialog. This will also block the execution at that step, although not providing you with a jump-to-next-line mechanism, for me this solution proved to be the best.
Another possibility is to do the debugging in any modern browser if/when NetLogo Web produces source maps. This way one can set breakpoints in the NetLogo code and use Chrome or FireFox or IE11's developer tools on the NetLogo code.
I have used user-message and inspect together as the debugging tool for NetLogo. Here is a video demo on how to use them to identify the cause of an error.
the reason for using inspect is to examine all properties of an object when we are not sure where exactly went wrong
using user-message to print out some instruction, output some outcome and halt the program
I found Netlogo somewhat difficult to debug until I discovered print statements.
I basically zone in on the module that is causing problems and I add print statements within critical blocks to inspect the state of the variables. I have find this to be an effective way to debug.
I do wish the documentation was more comprehensive, with more code examples. Perhaps some good Samaritan will take it up as a project.
NB: Note that this approach is not just a convoluted way to achieve the exact same benefit that using random-seed gives. Using random-seed is an ex-ante way to reproduce a run. However, for rare errors, it is impractical to manually change random-seed (maybe a few hundred times) until you hit by chance a run in which the error appears. This approach, instead, makes you able to reproduce the error after it occurred, potentially saving tons of time by letting you reproduce that rare run ex-post.
Feel free to download this blueprint from the Modelling Commons if anyone finds it useful and wants to save the time to set it up.
Not a NetLogo feature, but an expedient I've devised recently.
Some errors might occur only rarely (for example, every few hundred runs). If that is the case, even just reproducing the error can become time consuming.
In order to avoid this problem, the following arrangement can be used (note that the code blocks only contain very few lines of code, the vast majority is only comments).
globals [
current-seed
]
to setup
clear-all
reset-ticks
manage-randomness
end
to manage-randomness
; This procedure checks if the user wants to use a new seed given by the 'new-seed' primitive, or if
; they want to use a custom-defined seed. In the latter case, the custom-defined seed is retrieved
; from the 'custom-seed' global variable, which is set in the Interface in the input box. Such variable
; can be defined either manually by the user, or through the 'save-current-seed-as-custom' button (see
; the 'save-current-seed-as-custom' procedure below).
; In either case, this selection is mediated by the 'current-seed' global variable. This is because
; having a global variable storing the value that will be passed to the 'random-seed' primitive is the
; only way to [1] have such value displayed in the Interface, and [2] re-use such value in case the
; user wants to perform 'save-current-seed-as-custom'.
ifelse (use-custom-seed?)
[set current-seed custom-seed]
[set current-seed new-seed]
random-seed current-seed
end
to save-current-seed-as-custom
; This procedure lets the user store the seed that was used in the current run (and stored in the
; 'random-seed' global variable; see comment in 'manage-randomness') as 'custom-seed', which will
; allow such value to be re-used after turning on the 'use-custom-seed?' switch in the Interface.
set custom-seed current-seed
end
This will make it possible to reproduce the same run where a rare error occurred, just by saving that run's seed as the custom seed and switching on the switch.
To make things even more useful, the same logic can be applied to ticks: to jump exactly to the same point where the rare error occurred (maybe thousands of ticks after the start of the run), it is possible to combine the previous arrangement about seeds and the following arrangement for ticks:
to go
; The first if-statement allows the user to bring the run to a custom-defined ticks value.
; The custom-defined ticks value is retrieved from the 'custom-ticks' global variable,
; which is set in the Interface in the input box. Such variable can be defined either
; manually by the user, or through the 'save-current-ticks-as-custom' button (see the
; 'save-current-ticks-as-custom' procedure above).
if (use-custom-ticks?) AND (ticks = custom-ticks) [stop]
; Insert here the normal 'go' procedure.
tick
end
to save-current-ticks-as-custom
; This procedure lets the user store the current 'ticks' value as 'custom-ticks'. This will allow
; the user, after switching on the 'use-custom-ticks?' switch, to bring the simulation to the
; exact same ticks as when the 'save-current-ticks-as-custom' button was used. If used in combination
; with the 'save-current-seed-as-custom' button and 'use-custom-seed?' switch, this allows the user
; to surely and quickly jump to the exact same situation as when a previous simulation was interrupted.
set custom-ticks ticks
end
This will make it possible not only to quickly jump to where an otherwise rare error would occur, but also, if needed, to manually change the custom-ticks value to a few ticks earlier, in order to be able to observe how things build up before the error occurring. Something that, with rare errors, can otherwise become quite time-consuming.
NetLogo is all about keeping the code in one spot. When I run a simulation in 2D or 3D, I usually have an idea what my whole system is going to produce at timepoint X. So when I'm testing, I usually color code my agents, the "turtles", around a variable I'm tracking (like number of protein signals etc.)
It can be as simple as making them RED when the variable your wondering about is over a threshold or BLUE when under. Or you can throw in another color, maybe GREEN, so that you track when the turtles of interest fall within the "optimal" range.
This is probably a simple question, but:
is it possible to see the value for the last variables calculated as we go through the debugging process step-by-step?
I know I can set the variables I want in the Watch windows when debugging, or see the values of each variable during debugging by placing the mouse over the variable in the code, but this is annoying and time consuming.
The "Locals" window seemed initially that it could do the trick, but I only manage to make it show the variables in an order that is totally random, and I have hundreds of variables (many are arrays), so it becomes useless.
Any thought on this would be more than welcomed! :)
Best
I'm not sure how to really put my question into words so let me try to explain it with an example:
Let's say my program runs into some weird behavior at a specific action. I already find some code which is the cause of this weird behavior. When disabling this sequence I don't run into this behavior. Unfortunately, I need this code because something else is not working then.
So, what I gonna do next is figuring out why something is going different when that code excerpt is active.
In order to better understand what's going on I sometimes want to run the whole action including the 'bad code' and sometimes without. Then I can compare the outcome, for example what happens in the UI or what my function returns.
The first approach which comes to my mind is to run my program with the code enabled, do whatever I want, then stop my program, comment out the code, recompile and run again. Um... that sounds dumb. Especially if I then again need to turn on that code to see another time the other behavior, and then again turn off, and on, and off and so on.
It's not an option for me to use breakpoints and influence the statement order or to modify values so that I run or not run into if-statements, for-loops etc. Two examples:
I debug a timing critical behavior and when I halt the program the timing changes significantly. Thus, the first breakpoint I can set must be at the end of the action. 1
I expect a tooltip or other window to appear which is 'suppressed' when focus is given to VS. Thus, I cannot use any breakpoints at all. Neither in the beginning nor at the end of the action.1
Is there any technique in Visual Studio 2012 which allows me to mark this code to be optional and I can decide whether or not I want to run this code sequence before I execute the action? I think of something like if(true|false) on a higher level.
I'm not looking for a solution where I need to re-run my program several times. In that case I could still doing the simple approach of simply commenting out the code with #if false.
1 Note that I, of course, may set a breakpoint when I need to look into a specific variable at a certain position (if I haven't written the value into output) but will turn off breakpoints again to run the whole action in one go.
In the Visual Studio debugger you can set a breakpoint right in front of your "code in question". When the code stops at that point, you can elect to let it continue or you can right-click on any other line and select Set Next Statement.
It's kind of a weird option, but I've come to appreciate it.
The only option I can think of is to add something to your UI that only appears when debugging, giving you the option to include/exclude the operations in question.
While you're at it, you might want to enable resetting the application to a "known state" from the UI as well.
I think of something like if(true|false) on a higher level.
Why "on a higher level"? Why not use exactly this?
You want a piece of code sometimes executed, sometimes not, and the switch should be changed at run time, not at compile time - this obviously leads to
if(condition)
{
// code in stake
}
The catch here is what kind of condition you will use - maybe a variable you set to true in the release version of your code, and to false sometimes in your debug version. Maybe the value is taken from a configuration file, maybe from an environment variable, maybe calculated by some kind of logic in your program, whatever and whenever you like.
EDIT: you could also introduce a boolean variable in your code for condition, initialize it to true by default and change its value using the debugger whenever you like.
Preprocessor Directives might be what you're after. They're bits of code for the compiler to execute, identifiable by starting with a # character (and stylistically, by default they don't follow the indent pattern of your code, instead always residing firmly at the left-hand edge of the editor):
#define INCLUDE_DODGY_CODE
public void MyMethodWithDodgyBits() {
#if INCLUDE_DODGY_CODE
myDodgyMethod();
#endif
myOkMethod();
}
In this case, if #define INCLUDE_DODGY_CODE was included, the myDodgyMethod() call will be compiled into your program. Otherwise, the call will be skipped by the compiler and will simply not exist in your binary.
There are a couple of options for debugging as you ask.
Visual Studio has a number of options to directly navigate through code. You can use the Set Next Statement feature to move directly to a particular statement. You can also directly edit values through the Immediate Window the QuickWatch and the tooltip that hovers over variables while debugging.
Visual Studio also has the ability to playback the execution history. Take a look at IntelliTrace to get started. It can be helpful when you have multiple areas of concern that are interacting and generating the error condition.
You can also wrap your sections of code within conditional blocks, and set the conditional variables as appropriate. That could be while you're debugging, or you could pass parameters in through a configuration file. Using conditional checks may be easier than manually stepping through code if there are a number of statements you wish to exclude.
It sometimes depends on the version of VS and the language, but you can happily edit the code (to comment it out, or wrap it in a big #ifdef 0) then press alt+F10 and the compiler will recompile, relink and continue execution as if you'd never fiddled with it.
But while that works beautifully in VC++ (since VS v6 IIRC), C# can have issues - I find (with VS2010) that I cannot edit and continue in this way with functions containing any lambda (mainly linq) statements, and 64-bit code never used to do this too. Still, its worth experimenting with as its really useful sometimes.
I have worked on applications that have optional code used for debugging alone that should not appear in the production environment. This segment of optional code was easiest for us to control using a config file since it didn't require a re-compile to change.
Such a fix might not be the end all be all for your end result, but it might help get through it until a fix is found. If you have multiple optional sections that need to be tested in combination this style of fix could require multiple keys in the config file, which could be a downside and a pain to keep track of.
Your question isn't exactly clear, which is possibly why there are so many answers which you think are invalid. You may want to consider rewording it if no one seems able to answer the question.
With the risk of giving another non-valid answer I'll add some input on how I've dealt with the issue in the past.
The easiest way is to place any optional code within
#if DEBUG
//Optional code here
#endif
That way, when you run in debug mode the code is implemented and when you run in release mode it's not. Switching between the two requires clicking one button.
I've also solved the same problem in a similar way with a simple flag:
bool runOptionalCode = false;
then
if (runOptionalCode)
{
//Place optional code here
}
Again, switching between modes requires changing one word, so is a simple task. You mention this in your question but discount it for reasons that are unclear. As I said, it requires very little effort to switch between the two.
If you need to make changes between the code while it's running the best way is to use a UI item or a keystroke which modifies the flag mentioned in the example above. Depending on your application though this could be more effort than it's worth. In the past I've found that when I have a key listener already implemented as part of the project, having a couple of key strokes decide whether to run my debug (optional) code works best. In an application without key listeners I'd rather stick with one of the previous methods.
now I'm developing a GUI with pop-up windows, so actually it is a workpackage with multiple GUIs.
I have read thorough the examples given in help files (changme, and toolpalette), but I failed to animate the method to transfer data from the new one back to the old one.
Here is my problem.
I have two GUIs, A, the Main one and B that I use it to collect input data and I want to transfer the data back to B.
Question 1:
I want to define new subclasses of handles in A.
lets say,
handles.newclass
how can I define its properties, e.g. 'Strings'?
Question 2:
In A, a button has the callback
B('A', handles.A);
so we activate B.fig.
After finished the work in B,
it has collected the following data (string and double) in B(!)
title_1 itle_2 ... title_n
and
num_1 num_2 ... num_n
I want to pass the data back to A.
Following the instruction, I wrote the codes shown below.
mainHandles = guidata(A);
title = mainHandles.title_1;
set(title,'String',title_1);
However, when I go back to A, handles in A was not changed at all.
Please someon help me out here.
Thank you!
=============update================
The solution I found is adding extra variables (say handles.GUIdata) to handles structure of one GUI, and whenever the data are required, just read them from the corresponding GUI.
And It works well for me, since I have a main control panel and several sub-GUIs.
There is a short discussion of this issue here.
I have had similar issues where I wanted external batch scripts to actually control my GUI applications, but there is no reason two GUI's would not be able to do the same.
I created a Singleton object, and when the GUI application starts up it gets the reference to the Singleton controller and sets the appropriate gui handles into the object for later use. Once the Singleton has the handles it can use set and get functions to provide or exchange data to any gui control that it has the handle for. Any function/callback in the system can get the handle to the singleton and then invoke routines on that Singleton that will allow data to be exchanged or even control operations to be run. Your GUI A can, for instance, ask the controller for the value in GUI B's field X, or even modify that value directly if desired. Its very flexible.
In your case be sure to invalidate any handles if GUI A or B go away, and test if that gui component actually exists before getting or modifying any values. The Singleton object will even survive across multiple invocations of your app, as long as Matlab itself is left running, so be sure to clean up on exit if you don't want stale information laying around.
http://www.mathworks.com/matlabcentral/fileexchange/24911-design-pattern-singleton-creational
Regarding Question 2, it looks like you forgot to first specify that Figure A should be active when setting the title. Fix that and everything else looks good (at least, the small snippets you've posted).