A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
Related
I'm using the DIA SDK to get symbol information from .pdb files. For example, I want to use this to get a list of classes, functions, member variables, and so on from a project.
After some messing around I've been able to get this information, however I'm also getting a lot of extra stuff that isn't my own code but is added in after (by the standard library and such).
I've tried filtering this based on the source file of the given symbol, however get_sourceFileName() seems to be unreliable, usually not returning any value.
Any help would be appreciated, whether it's getting get_sourceFileName() to work properly or some other way of filtering out objects from code that isn't part of the project.
Note that I know there are alternatives to the DIA SDK that would make this easier, such as libclang, however those are not an option for this project for various reasons.
Following these instructions, I have already managed to fix the IntelliSense suggestions for my C++ hello world program using Qt headers. So for instance, when I type QString::, the class methods append, arg, etc. are suggested correctly. However, when I choose any of them, I would expect to read a short documentation comment describing what the selected method does do. Unfortunately, this information is not available.
I have also followed this tip and installed qt5-doc on my Ubuntu system, but I have no idea how I can use the .qch documentation files in VS Code. Do you have any pointer for me?
(I've looked far and wide but I can't even find anyone having the same problem, not to mention a fix or anything. Closest is this thread which just announces the feature...)
The way it currently works for me, the VS2019 code lens integration of P4VS (for C++ at least) is almost completely pointless. Each function has an indicator added, but the information in each is identical - namely the change history of the entire file:
According to this Microsoft article, I would expect to either get function-level change information that pertains only to that function or a single change summary of the file at the bottom of the editor. But instead I get the worst combination of both.
I'm mainly surprised that I can't find anyone else talking about this, so I assume something is misconfigured on my part. Can't find anything in the configuration options though...
Is this just a bad implementation by Perforce or is something wrong on my end?
I have just found out that it can be turned off by Visual Studio options.
How to turn off CodeLens-References
Text Editor > All Languagues > CodeLens
coldfusion.compiler.FactoredNodeAggregation cannot be cast to coldfusion.compiler.ASTfunctionDefinition
I get the above error when attempting to replace a really, really old legacy custom tag with a new custom tag that has some substantial workflow improvements. I only have one idea on how to debug this: comment out different parts of the code (binary search style) until it will compile, narrowing my search until I find the problem code.
Has anyone else ever seen this error before? Any idea what it could possibly be? Contextually, it sounds like I'm trying to use ... something... as a function that isn't defined as a function. That doesn't ring a bell so I'm going to try the binary search idea.
Update: It's running on CF 8.0.1, and doesn't use any <cfscript> blocks at all. Using the binary search of commenting out, I've narrowed it down to a CFThread that starts a background thread that never re-joins the page (by design).
If I comment out the entire contents of the thread, the error goes away (so the cfthread tag itself doesn't appear to have problems on its own...). If I copy the contents of the thread to its own template, that template will compile fine (so the thread contents doesn't appear to have problems on its own...)... so... in theory it should work? I don't know. This is me with my arms up in the air. (WTF?)
I think I've already disproven this idea by un-commenting a small section without the error coming back, but a CFThread should have access to local custom tags that the template creating the thread would have, right? so if there's foo.cfm, it could be accessed from the page as <cf_foo>, and the thread could do the same?
In the last week I've been in contact with the ColdFusion Engineering team at Adobe about this issue and they confirmed for me that this is a bug in ColdFusion.
Specifically, if the number of lines of code inside the thread tag body was too large, it would cause a compile error. The work-around, which I discovered a day or two before I got my answer, is to use a <cfinclude /> to import your thread contents from another file; or to put the code into a method somewhere and call that method from inside the thread body. (Presumably, a custom tag or other clever methods of encapsulation would also work.)
That explains the part of the whole thing that was driving me absolutely insane: that commenting out various parts of the thread body would sometimes make it compile... and now I know it was because enough of the thread body was commented out.
They report that they have fixed the bug, so I assume it will be fixed in the next cumulative hot-fix (if there is one), and in ColdFusion 9.
Since I can't comment yet, Adam, is it really a bug with CF or with the JVM? There's a similar limit on how many lines of code can be compiled within a CFFUNCTION, but the limit is really in the JVM, not the CF tag.
Oooh, that's one I've not seen before.
Depending on what the custom tag does, rather than commenting out different parts, you could try using cfabort - same technique, but only one line to change rather than uncommenting and re-commenting (which can be fiddly and time-consuming).
Also, are you able to test the custom tag in isolation, with completely simplified arguments/etc?
If you're able to post the code, there might be something odd that jumps out at a fresh pair of eyes?
that error usually comes up when you have a function that is set to remote. kinda funny that your getting it with a custom tag though. are you sure that the custom tag doesn't have any functions in it? can you post the code?
Strange that it is a compilation error. If the code base is not too huge I would make sure all variables in the thread and called udfs are explicitly scoped.
Next I would move as much externally referenced data into the thread arguments scope to isolate the interactions with the page.
Finally if that does not clear it up I would try mangling the names of every variable, function and udf the thread accesses a bit with some test prefix just to make sure that you have not hit a bug where one of your vars or funcs is causing a namespace collision in the jvm in the context of the original page.
Tricky problem.
Have you deleted the compiled class files and saved the original source to a new file just in case something weird occurred during a save?
Have you tried reinstalling CF8.01? Maybe some files got corrupted?
I was going to create the C++ IDE Vim extendable plugin. It is not a problem to make one which will satisfy my own needs.
This plugin was going to work with workspaces, projects and its dependencies.
This is for unix like system with gcc as c++ compiler.
So my question is what is the most important things you'd need from an IDE? Please take in account that this is Vim, where almost all, almost, is possible.
Several questions:
How often do you manage different workspaces with projects inside them and their relationships between them? What is the most annoying things in this process.
Is is necessary to recreate "project" from the Makefile?
Thanks.
Reason to create this plugin:
With a bunch of plugins and self written ones we can simulate most of things. It is ok when we work on a one big "infinitive" project.
Good when we already have a makefile or jam file. Bad when we have to create our owns, mostly by copy and paste existing.
All ctags and cscope related things have to know about list of a real project files. And we create such ones. This <project#get_list_of_files()> and many similar could be a good project api function to cooperate with an existing and the future plugins.
Cooperation with an existing makefiles can help to find out the list of the real project files and the executable name.
With plugin system inside the plugin there can be different project templates.
Above are some reasons why I will start the job. I'd like to hear your one.
There are multiple problems. Most of them are already solved by independent and generic plugins.
Regarding the definition of what is a project.
Given a set of files in a same directory, each file can be the unique file of a project -- I always have a tests/ directory where I host pet projects, or where I test the behaviour of the compiler. On the opposite, the files from a set of directories can be part of a same and very big project.
In the end, what really defines a project is a (leaf) "makefile" -- And why restrict ourselves to makefiles, what about scons, autotools, ant, (b)jam, aap? And BTW, Sun-Makefiles or GNU-Makefiles ?
Moreover, I don't see any point in having vim know the exact files in the current project. And even so, the well known project.vim plugin already does the job. Personally I use a local_vimrc plugin (I'm maintaining one, and I've seen two others on SF). With this plugin, I just have to drop a _vimrc_local.vim file in a directory, and what is defined in it (:mappings, :functions, variables, :commands, :settings, ...) will apply to each file under the directory -- I work on a big project having a dozen of subcomponents, each component live in its own directory, has its own makefile (not even named Makefile, nor with a name of the directory)
Regarding C++ code understanding
Every time we want to do something complex (refactorings like rename-function, rename-variable, generate-switch-from-current-variable-which-is-an-enum, ...), we need vim to have an understanding of C++. Most of the existing plugins rely on ctags. Unfortunately, ctags comprehension of C++ is quite limited -- I have already written a few advanced things, but I'm often stopped by the poor information provided by ctags. cscope is no better. Eventually, I think we will have to integrate an advanced tool like elsa/pork/ionk/deshydrata/....
NB: That's where, now, I concentrate most of my efforts.
Regarding Doxygen
I don't known how difficult it is to jump to the doxygen definition associated to a current token. The first difficulty is to understand what the cursor is on (I guess omnicppcomplete has already done a lot of work in this direction). The second difficulty will be to understand how doxygen generate the page name for each symbol from the code.
Opening vim at the right line of code from a doxygen page should be simple with a greasemonkey plugin.
Regarding the debugger
There is the pyclewn project for those that run vim under linux, and with gdb as debugger. Unfortunately, it does not support other debuggers like dbx.
Responses to other requirements:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
My BuildToolsWrapper plugin has a g:BTW_run_parameters option (easily overridden with project/local_vimrc solutions). Adding a mapping to ask the arguments to use is really simple. (see :h inputdialog())
work with source control system
There already exist several plugins addressing this issue. This has nothing to do with C++, and it must not be addressed by a C++ suite.
debugger
source code navigation tools (now I am using http://www.vim.org/scripts/script.php?script_id=1638 plugin and ctags)
compile lib/project/one source file from ide
navigation by files in project
work with source control system
easy acces to file changes history
rename file/variable/method functions
easy access to c++ help
easy change project settings (Makefiles, jam, etc)
fast autocomplette for paths/variables/methods/parameters
smart identation for new scopes (also it will be good thing if developer will have posibility to setup identation rules)
highlighting incorrect by code convenstion identation (tabs instead spaces, spaces after ";", spaces near "(" or ")", etc)
reformating selected block by convenstion
Things I'd like in an IDE that the ones I use don't provide:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
A "Tools" menu that is configurable on a per-project basis
Ability to rejig the keyboard mappings for every possible command.
Ability to produce lists of project configurations in text form
Intelligent floating (not docked) windows for debugger etc. that pop up only when I need them, stay on top and then disappear when no longer needed.
Built-in code metrics analysis so I get a list of the most complex functions in the project and can click on them to jump to the code
Built-in support for Doxygen or similar so I can click in a Doxygen document and go directly to code. Sjould also reverse navigate from code to Doxygen.
No doubt someone will now say Eclipse can do this or that, but it's too slow and bloated for me.
Adding to Neil's answer:
integration with gdb as in emacs. I know of clewn, but I don't like that I have to restart vim to restart the debugger. With clewn, vim is integrated into the debugger, but not the other way around.
Not sure if you are developing on Windows, but if you are I suggest you check out Viemu. It is a pretty good VIM extension for Visual Studio. I really like Visual Studio as an IDE (although I still think VC6 is hard to beat), so a Vim extension for VS was perfect for me. Features that I would prefer worked better in a Vim IDE are:
The Macro Recording is a bit error prone, especially with indentation. I find I can easily and often record macros in Vim while I am editing code (eg. taking an enum defn from a header and cranking out a corresponding switch statement), but found that Viemu is a bit flakey in that deptartment.
The VIM code completion picks up words in the current buffer where Viemu hooks into the VS code completion stuff. This means if I have just created a method name and I want to ctrl ] to auto complete, Vim will pick it up, but Viemu won't.
For me, it's just down to the necessities
nice integration with ctags, so you can do jump to definition
intelligent completion, that also give you the function prototype
easy way to switch between code and headers
interactive debugging with breaakpoints, but maybe
maybe folding
extra bonus points for refactoring tools like rename or extract method
I'd say stay away from defining projects - just treat the entire file branch as part of the "project" and let users have a settings file to override that default
99% of the difference in speed I see between IDE and vim users is code lookup and navigation. You need to be able to grep your source tree for a phrase (or intelligently look for the right symbol using ctags), show all the hits, and switch to that file in like two or three keystrokes.
All the other crap like repository navigation or interactive debugging is nice, but there are other ways to solve those problems. I'd say drop the interactive debugging even. Just focus on what makes IDEs good editors - have a "big picture" view of your project, instead of single file.
In fact, are there any plugins for vim that already achieve this?