While debugging a program in Xcode I have several CFStringRef variables that point to strings with lengths around the 200 character mark.
In the debugger, it only shows the value of these strings up to a certain length and then just ellipses them away. I'd really like to see the full value of the strings.
Is there some option I can configure so it doesn't terminate them at arbitrary length?
In the debugging console you can get the string value by doing something like:
(gdb) print (void)CFShow(myCFString)
or:
(gdb) po (NSString*)myCFString
Either of those will display the entire string's contents to the debugging console. It's probably the easiest way to deal with large, variable-length strings or data structures of any kind.
For more information, the print command in the debugger basically dumps some data structure to the console. You can also call any functions or whatever, but since print doesn't have access to the function declarations, you have to make sure you provide them implicitly (as shown in the example above), or the print command will complain.
po is a shortcut for print-object and is the same as print except for Objective-C objects. It basically functions like this:
(gdb) print (const char *)[[theObject debugDescription] UTF8String]
This is really useful for examining things like NSData object and NSArray/NSDictionary objects.
For a lot more information on debugging topics, see Technical Note TN2124 - Mac OS X Debugging Magic and (from the debugger console) you can issue the help command as well.
To display really long string use method from print long string in xcode 6 debugging console
In lldb console increase max-string-summary-length
setting set target.max-string-summary-length 10000
Print your string with print or po commands
print my_string
If you are compiling c++ project in xcode just use this command
po string_name
Related
I am utilizing Pick Basic on the uniVerse operating system. Many times, I will need to watch a variable change during a debugging session. I will locate the variable throughout the program and note every time it can possibly be modified. I will then go into the program and during its execution, I have the program display the value of the variable on the screen along with the line number of the source code. For argument's sake, let us say that the variable name is begdate and in this case, on line 146, I set it to today's date. I will add the proceeding line:
146: begdate = DATE()
147: DISPLAY "Line 147: ":OCONV(begdate,"D4-")
This works just fine. But, if the program can possibly change this variable on many different lines, once I start adding or subtracting lines to the source code, the display is usually not displaying the correct line number anymore because the line number is hardcoded.
Does Pick Basic have any system variable that captures the line number of the source code so that:
I do not have to keep going back and changing the hardcoded line number and better yet,
I do not have to hardcode the line number at all.
Welcome to StackOverflow! The answer to this is in the UniVerse BASIC User Guide V11.3.4:
https://docs.rocketsoftware.com/bundle/UniVerse_BASICUserGuide_V1134/resource/UniVerse_BASICUserGuide_V1134.pdf
Ref page 63 on Debugging Tools (RAID) and the M command to set watchpoints on variables.
A watchpoint condition occurs when RAID monitors a variable until the variable’s value changes. The
program then suspends operation and displays the variable’s old value, its new value, and the source
instruction that caused the change to occur
The command is entered at the :: prompt, within the debugger. You can enter the debugger with a DEBUG statement in your code or by breaking into it at runtime. You can also use the command RAID BP ProgName.
Another way to go about this is to compile with -X option so that you can get see where variables are referenced. See page 35 from above.
When I debug like this in BASIC, I tend to use names, not line numbers, to indicate what the code is doing, not where it is. So the code would look more like this:
147: DISPLAY "Initializing Beginning Date: ":OCONV(begdate,"D4-")
Now the line can move and you'll still be able to find it easily with the unique text. You can also use simpler unique text like this:
147: DISPLAY "BEGDATE_INIT: ":OCONV(begdate,"D4-")
Use whatever pattern seems comfortable.
Be sure begdate isn't EQUated to a dynamic element or some other variable. If, for example, EVENT<3> is equated to begdate the debugger tracing the specific variable name might not pick up on EVENT<3> or EVENT<Beginning_Date> being modified.
I am not aware of a specific #VAR or other runtime mechanism in UniVerse that will return the currently executing line number back to the BASIC code so that you can DISPLAY "Current line is ":#LINE.
In D3 I peeked into the local workspace and the current stack trace.
Someone with more current UniVerse expertise might be able to cite a specific function, #VAR, user exit, or other mechanism for this. It's possible that the feature you're looking for is only available in a later platform.
Rocket Support will help with this question : Support Agreement should not be necessary to ask a simple question like this. If that's not an option, check the forum on the Rocket site, or one of the community forums. I can provide links if required.
I am using the AppleWin emulator, setup as an Apple IIe, Apple DOS 3.3 with Applesoft. My goal is to make a simple game.
This simple GET program works fine at the ] prompt (I am not sure, but I think it's called the monitor).
10 GET V$
20 PRINT V$
It prints the pressed key as expected
Then I start Applesoft using LOAD APPLESOFT. I tried writing the same simple program than at the ] prompt. But this time when I type the first line 10 GET V$ I get as output *** SYNTAX ERR.
I think it's not a supported feature, but in the ApplesoftII Basic Programming Reference Manual they list get a reserved keyword.
I could update to a higher version of Applesoft, then which version of Applebasic would support it?
I can also use another method of getting a key press without the user needing to press enter afterwards.
Applesoft on the Apple ][e (the first apple version to support lower-case at all) is case sensitive, and all the keywords are UPPERCASE only -- so get will not match the keyword (or anything) and will give you a syntax error.
Of course, if you're emulating an original Apple ][, there's no lower case at all, and lower case letters show up as flashing uppercase -- and still won't match a keyword.
After continuing to research my issue, I have found the location of memory for the keyboard buffer.
The keyboard buffer is -16384 and the way to reset that value of that address is to access -16368.
If the value in -16384 is larger than 128 then a key has been pressed.
So, I can use PEEK -16384 to read the value. To get an ASCII code you need to subtract 128 to that value.
Example code:
KEY= PEEK(-16384)
IF KEY>=128 THEN PRINT KEY-128
To tell the system you dealt with the key press and reset the value, you need to access the value in -16368. By using PEEK or POKE.
Example code:
POKE -16368,0
Or can also be PEEKed
PRINT PEEK -16368
if the error you are getting is *** SYNTAX ERR and not "?SYNTAX ERROR" then you are using integer basic and not applesoft basic. Try to switch to applesoft basic first by using FP
I'm just getting into Go for the first time and finally got things running on my Win10 machine. Finally got breakpoints working inside of IntelliJ IDEA, and I'm seeing stuff like this in my debugger window. Those messes of unicode chars should actually be a 24-char HEX id that's coming from MongoDB.
My best guess is that this is a problem with mgo not properly unmarshalling ObjectId objects, but this doesn't seem to be a problem for any of the devs running linux or macOS, so maybe it's just a Windows thing?
Any input would be appreciated!
No error here. bson.ObjectId has an underlying type of string:
type ObjectId string
But it is used to store 12 "arbitrary" bytes ("arbitrary" means it is not meant to be interpreted by runes, and it's not a valid UTF-8 encoded sequence). It is usually displayed using the hex representation of its bytes, for humans.
Debuggers don't take that convenience. They see it's a string, so they attempt to display it as a string (even though it's not meant to). This is not a Windows-only thing, the Atom editor with the delve debugger does the same on Linux too. Nothing to worry about.
If you print an ObjectId, it's usually the fmt package's "thing" to use its String() method to acquire the string value to be displayed. Debuggers do not necessarily do that.
I have written a program that uses ncurses for the UI and the function mvwgetnstr to read in a string from a window. I want to allow users to make edits to the text they enter, so if they enter foo they can later go back and append bar. I cannot figure out how to do this with the curses API, the getnstr function only takes in a char buffer and length variable. Any ideas? I started making my own string input function, but it's difficult to keep everything constrained within the window.
It depends on what you want. There are many possible ways to organize a program:
getnstr reads the buffer from the standard screen (a window)
The wgetnstr function accepts a buffer from a given window. Using a separate window (or subwindow) reduces the problem of updates for the edited buffer interfering with other things on the screen.
getnstr editing is crude. If you use the form library (which in turn uses ncurses), that allows you to do more than just append/remove characters from the end of the input buffer.
write your own input-function, which can get complicated. The dialog program does this.
The ncurses-examples might be helpful for reading and seeing how to build up a suitable input function.
Could someone please tell me what exactly does printw do? I tried looking for information but just could not find anything.
5 seconds on Google revealed some nice documentation.
printw() class: Print formatted output similar to printf()
and
6.3.1. printw() and mvprintw
These two functions work much like printf(). mvprintw() can be used to move
the cursor to a position and then print. If you want to move the cursor first
and then print using printw() function, use move() first and then use printw()
though I see no point why one should avoid using mvprintw(), you have the
flexibility to manipulate.
Source - NCURSES-Programming-HOWTO
Type man printw (I suppose you are not programming with Windows).