I'm debugging some code with Eclipse CDT and GDB, and some strings are in UTF-8, so I use x/sh <buffer name> in the debugger console to display them.
Is there a way to put GDB command as expressions in the Expression view? I have a buffer called Work1, so I tried to add x/sh Work1 as an expression, but that didn't work.
When adding an expression, Eclipse uses the -var-create command to create a variable object. After reading the documentation I don't think it's possible to provide a custom format with var-set-format that fits what I need.
So my questions are:
Is there a way to directly use a GDB expression with Eclipse in a more automated way than the Debugging Console?
Is there a way to specify a more flexible display format with var-set-format?
Is any other way I can achieve this, like using the Memory View?
Thank you!
Related
Has anyone maybe used Intelij as the default merge/diff tool in Eclipse?
I don't know what parameters should be used in the highlighted fields below.
EDIT:
See https://www.jetbrains.com/help/idea/2016.2/running-intellij-idea-as-a-diff-or-merge-command-line-tool.html about what kind of command-line parameters IntelliJ expects for the diff/merge: it seems like you have to add a diff argument first and then use the ${file1Path} and other placeholders separated with spaces, without using any comma nor and.
I'd like to get the output of apropos/1 and help/1 etc. inside my Emacs buffer, instead of an XPCE window. I'm using SWI-Prolog under Linux.
What I have tried:
Setting flags in the init file (~/.plrc):
:- set_prolog_flag(gui, false).
:- set_prolog_flag(xpce, false).
Calling swipl with the --nopce flag (a wild guess looking at /usr/lib/swi-prolog/xpce.rc)
ssh localhost, effectively emulating a terminal-only machine, which worked, but there must be a better solution...
And yes, I could just uninstall the swi-prolog-x package, but I may want to write GUI programs in the future. Ideally I would like to turn off the GUI only for the documentation / debugging.
EDIT:
I've found out part of the solution: the goals online_help:give_help/1 and online_help:give_apropos seem to be what I need. I just need to re-hook these onto help and apropos, maybe via prolog:help_hook/1. Any ideas?
[~]# unset DISPLAY
swipl --nopce
This a an undocumented flag... Normally it is only used when building the system/
I am new to Coverity,I am using it from the command prompt with it's .exe files.So I want to pass specific macros in coverity cov-build.exe so that those macros will be implemented when cov-emit.exe(when it is called by cov-build.exe) is parsing the .c files.Till now I have tried the below stated configurations.
code-build.exe Intermediate_folder --delete-stale-tus --preprocessor-first --return-emit-failure "My_bat_file" -- -D My_macro_name=my_macro_body
So any help will be much be appreciated.I am stuck on this.
Thanks and regards,
Newbie_in
cov-build wraps your existing build command, monitors it and spawns parallel compiler invocations in order to understand your code. These parallel compiler invocations will see the same command line being passed to your own compiler.
So if you want this define to take effect for your compiler as well as Coverity's then you should simply just add it to your build the way you would normally and Coverity will see it.
If you want to add a define that only Coverity's compiler can see, this is best done with within the config for your compiler.
You can either edit the config directly (add
<append_arg>-Dmy_macro_name=my_macro_body</append_arg>
after the <begin_command_line_config> line), or re-configure using --xml-option.
For example, if you're using the shortcut gcc config this would look like this:
$ cov-configure --gcc --xml-option=append_arg>-Dmy_macro_name=my_macro_body.
I noticed you're using --preprocess-first on the cov-build command line - I recommend against this, as it destroys XREFs making it much more difficult to browse defect information, as well as makes the analysis unable to find some defects (i.e. ones that are due to macros). --preprocess-next behaves like --preprocess-first and will only fire if the initial compilation attempt fails, so if you're using --preprocess-first to work around compilation issues, I strongly recommend using --preprocess-next instead.
If you do have compilation issues, it's always good to report them (along with a reproducer) to Coverity support so that they can be fixed in future releases.
why doesn't eclipse match the argument while doing code completion. In the following example it should have automatically matched the throwable. In stead it shows arg1 as the first option.
The autocomplete options in Eclipse for auto-completed method arguments, start with the parameter names found in the source distribution (that contains the class with the method). If no source distribution is available, then it will use the parameter names as indicated in the binary distributions i.e. in the compiled byte code. This is the default behavior
If you want to change this behavior of inserting parameter names from source code or binaries to inserting the best guessed arguments (including local variables), then you can configure the auto-complete options of Eclipse to do so, as shown in the following screenshot:
This will produce the desired result of automatically displaying the options containing the list of best-guessed arguments. This also seems to avoid suggesting parameter names:
I guess arg1 is thing you already typed. So the proposal eclipse can provide is trying to find something which start from arg1.
So it puts it as the first choice.
You can type t , and try Alt+/ , to see if this is the reason.
I am using Eclipse 3.6.1 Build id: M20100909-0800 and Aptana Studio 2.0.5 which is based on Eclipse 3.5.2 (both on OS X) and in both programs the external tools feature seems to swallow double quotes and whitespace for the ${selected_text} variable.
Isn't the ${selected_text} variable essentially useless with the mentioned behaviour?
Is there a way around that or maybe a hidden setting somewhere?
Thanks for reading.
This could easily be considered a safety/security feature.
I suggest "${selected_text}".
...but if it's eating ALL whitespace, that won't really help. Huh. Maybe it's clever enough to detect the quotes and preserve the whitespace... but probably not.
Okay, I did a little poking around. Quotes within the argument list itself are preserved, as per my initial suggestion above. I found the following auto-generated argument list that was working Just Fine:
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog
-debug "${workspace_loc:/com.cardiff.bpm.ide.webforms.ui/debug.options}"
But if your text selection contains quotes, I'd expect it to be handled as per the underlying OS. Windows "cmd" does some... creative things with them for example. My *nix-fu is Not Mighty, so I couldn't tell you what OS X will do under the covers, but I suspect that's where you'll find your solution.
You may have to do something goofy like URL-encode your selection, and use some command line tool to un-encode it before passing it to your desired external tool once the text is out of Eclipse's clutches.
A (very) quick look around my 3.6.1 UI didn't turn up that would do this automagically for you, but there's probably a plugin out there somewhere that'll add that feature to an editor's context (right click) menu.
I'd expect the HTML editor to have this ability already... but I don't see anything other than "smart insert mode" that sounds promising, and I don't see that working either.
That doth bloweth goats, most heartily, yay for weeks on end. E'en till yon goat hath a rash, most unpleasant in both severity and locality. Verily.
I don't think you're getting my proposed solution:
Set up your tool so it'll de-url-encode-ificate the incoming string with some proposed command line tool.
In your editor (in eclipse), URL-encode the text you wish to select and pass to the tool. Manually.
Run the tool on the selected (url-encoded) text.
Revert the selected text. Also manually. Probably just "undo".
"1" is why I was looking for some eclipse UI way of url-encoding a selection. The HTML Editor won't even do it when you paste into an attribute string. Sheesh.
Two Other Options:
Fix the bug yourself. Open Source and all that.
Write a plugin that exposes it's own version of ${selected_text} that doesn't strip out all the strings.
Hey! SED! Replace the quotes with some random (unused in any selection you might make) high-ascii character and sed it back to a double quote instead of the proposed de-url-encode-ificationizer. You'd still have to manually edit/undo the text, but at least you won't have to """ Actually search/replace over a given selection makes that less painful than one might think.
I'm not sure what the scope of #2 is, but I'd image if you don't have any eclipse plugin experience the thought might be rather daunting. There might even be a sample plugin that exposes such a variable, though I haven't checked.
I don't think we're communicating.
You don't select text with quotes in it. You select mangled text, and sed demangles it back into quotes for you.
For example, you have the string print("hello world"); in your editor and want to send that to your tool.
change it to print(~hello world~); in your editor. Manually or via a script or whatever.
select it
run your tool, maybe wrapped in a script that'll sed the ~s back to "s.
change it back to print("hello world");.
This is a manual process. It's not pretty. Bug workarounds are like that. You can probably come up with a monkey script to convert quotes to Something Else, and "undo" is easy. You might even be able to get your script attached to a keyboard short cut... dunno. And ~ is a lousy choice for a replacement character, it's just the first thing I could think of that was rare enough to be a decent example.
Are we communicating yet?
For the record, I put together a patch using some guidance from a gentleman in the bug comments.
I don't know if it will be accepted, but it fixes things for me so maybe someone else may find it useful.
Again, this is only for Mac OS X Eclipse.
Start Eclipse.
Go to Import > Plug-ins and Fragments.
Import From: Active Platform
Fragments to import: Select from all plug-ins
Import As: Projects from a repository
Next >
Pick org.eclipse.debug.ui and org.eclipse.debug.core
Once the projects are in your workspace, apply the two patches that compose proposed patch v1, found at the bug tracker page for bug 255619
Go to Export > Deployable plug-ins and fragments and make a jar out of your changed packages.
Hope it helps.