I'm trying to better understand the code in ROOT's RDataFrame and the type/class Proxied appears a lot. For example here. It seems likely to be a root specific thing, since it has methods like GetTree. I've downloaded the repo, but I haven't compiled it.
What I've tried;
Asking YouCompleteMe to automatically find it.
Grepping the dataframe folder for just Proxied. There are a lot of results for this, but none of them are a class definition or a typedef.
Grepping the whole repository with grep "class.*Proxied" . -R -I. I thought if it were defined somewhere, that would get it. No results.
Grepping the whole repository with grep "typedef.*Proxied" . -R -I, to try to find a typedef in the same manner. No results here either.
I also searched the ROOT documentation for Proxied; closest match is Proxy, which appears unrelated.
I could probably try building ROOT, and then see if then see if the the build logs held any secrets, but that seems a bit extreme for just finding out what this thing is. I don't actually need to work on ROOT right now, just understand how RDataFrame handles TChains, for which I need to know what a Proxied is.
What tips for finding declarations/definitions should I have tried here?
Related
I've been looking at the pytorch repo. In particular, I'm trying to find where this function is defined: https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/core/TensorBase.h#L505-L506
It's declared here in the header file but I can't seem to find where it's actually defined. Is there a quick way I can do this for a github repo?
You can search a lot of things without downloading the repo by using github search bar :
If you want full vscode search abilities, you can also use this marvelous project :
https://github1s.com/pytorch/pytorch
Edit #1: It have been brought to my attention, that you can have a similar effect by pressing the dot on you keyboard from -any- github repository directly ;) Enjoy !
Edit #2 : I also learnt that there is also this : https://gitpod.io/#{repository github url} that you can use to read and edit your own repo. Wow, the things we discover every days !
I don't think github has any such functionality and the search function often times doesn't work well for me.
However, depending on the specific case, there are some heuristic methods using the web interface that are quicker than scrolling through the search results.
For example in this case, have a look at the git blame for the line. The commit putting the declaration there should also have put the definition somewhere, usually.
In this case you will get this commit, which by a quick search on the page shows you that there is a macro for explicit specialization definitions of the function template in this file.
I also couldn't find a definition of the primary template with a quick look. Presumably the function is supposed to be explicitly specialized for all types it is used with.
The best way I know is to get a local copy with git clone and use git grep -n <fn_name> from the root of the directory (or wherever the source code is stored, either is fine). That will list all instances of the last argument and what file and line number it appears on, so it's typically pretty easy to tell which is the definition because it will have a { instead of a ; at the end.
In Visual Studio Code, F2 rename on purely local C++ symbols is fine, but trying it on a symbol with wider scope, results in a very aggressive scope of suggested renaming, going as far as suggesting to rename unrelated symbols with the same name in the system header files. These typically default to unchecked, but at one point, it did rename an unrelated symbol with the same name in a project header, so it would be nice if the default could be dialed down a bit. Is there a way to do that?
The problem isn't with vscode, it's the linter vscode is using.
The easiest way to try to resolve the problem is using a different more advanced c++ linter. It's what I did to resolve a similar issue using golang.
Maybe the below link will help you find your new favorite linter.
https://www.reddit.com/r/cpp/comments/5b397d/what_c_linter_do_you_use/
PS: There is probably a setting that can edit the linter like what I am posting below, but based off of what you're asking, it may be difficult to find the right regex or whatever you need. It'd probably be best just to switch linters and then maybe make an issue on their github repository if you can't find one that suis your need.
"python.formatting.blackArgs": [
"--line-length=80"
],
I try to run a cppcheck analysis over my code, which has the following file structure:
/code/module_1/src/a.cpp
/code/module_1/src/b.cpp
/code/module_1/test/c.cpp
/code/module_2/src/d.cpp
/code/module_2/src/e.cpp
/code/module_3/test/f.cpp
I'd like to run an analysis excluding all test code. Is this possible with a command like "cppcheck -itest"? It doesn't work for me, although I think it should, according to the docs:
...Directory name is matched to all parts of the path.
I'm using version 1.69. I know I could mention all test directories separately (which does work, I checked), but the number of modules is too high to do this for many analyses reasonably.
Is this possible?
I installed Cppcheck to do some tests and it seems the -i implementation is a bit bonkers. However, I managed to achieve what you want.
Solution: use -itest\ instead of -itest (this was in Windows; maybe Linux needs -itest/)
Rationale: in my tests, -itest worked only if there was a .\test\ directory, in which case even .\a\test\a.cpp was excluded. With -itest\, however, such exclusion took place regardless of the presence of .\test\ directory.
This seems like a bug which the developers ought to weed out, but, in the meantime, you can succeed using the above workaround.
This is a late response to an old question, but perhaps this will help other latecomers like myself.
Disclaimer: This answer is for Windows.
It seems as if v1.79 has remedied the OP's issue. The following command line syntax has worked for me:
cppcheck -itest code
In this example, "-itest" weeds out any occurrence of the "test" directory, as originally (and correctly) assumed by the OP. In addition, the code folder is found next to the cppcheck.exe. This will be the root of the recursive source-code scan.
I'd use something like:
cppcheck /code/module_1/src /code/module_2/src /code/module_3/src
A little retrospective now that I've settled into Mercurial. Forget forget files combined with hg remove. It's crazy and bass-ackwards. You can use hg remove once you've established that something is in a forget file that isn't forgetting because the item in question was tracked before the original repo was created. Note that hg remove effectively clears tracked status but it also schedules the file for deletion in anything that gets changes from your repo. If ignored, however the tracking deactivation still happens but that delete-me change set won't ever reach another repo and for some reason will never delete in yours which IMO is counter-intuitive. It is a very sure sign that somebody and I don't know these guys, is UNWILLING TO COMPROMISE ON DUH DESIGN PROBLEMS. The important thing to understand is that you don't determine what's important, Mercurial does. Except when you're merging on a pull of course. It's entirely reasonable then. But I digress...
Ignore-file/remove is a good combo for already-tracked but very specific files you want forgotten but if you're dealing with a larger quantity of built files determined with broader patterns it's not worth the risk. Just go with a double-repo and pull -u from the remote repo to your syncing repo and then pull -u commits from your working repo and merge in a repo whose sole purpose is to merge changes and pass them on in a place where your not-quite tracked or untracked files (behavior is different when pulling rather than pushing of course because hey, why be consistent?) won't cause frustration. Trust me. The idea that you should have to have two repos just to get 'er done offends for good reason AND THAT SO MANY OF US ARE DOING IT should suggest a serioush !##$ing design problem, but it's much less painful than all the other awful things that will make you regret seeking a sensible alternative.
And use hg help. It's actually Mercurial's best feature and often better than the internet (which I don't fault for confusion on the matter of all things hg) for getting answers to everything that is confusing and counter-intuitive in this VCS.
/retrospective
# switch to regexp syntax.
syntax: regexp
#Config Files
#.Net
^somecompany\.Net[\\/]MasterSolution[\\/]SomeSolution[\\/]SomeApp[\\/]app\.config
^somecompany\.Net[\\/]MasterSolution[\\/]SomeSolution[\\/]SomeApp_test[\\/]App\.config
#and more of the same following
And in my mercurial.ini at the root of my user directory
[ui]
username = ereppen
merge = bcomp
ignore = C:\<path to user ignore file>\.hgignore-config
Context:
I wrote an auto-config utility in node. I just want changes to the files it changes to get ignored. We have two teams and both aren't on the same page with making this a universal thing so it needs to be user-specific for now.
The config file is in place and pointed at by my ini file. I clone. I run the config utility and change the files and stat reveals a list of every single file with an M next to it. I thought it was the utf-8 thing and explicitly set the file to utf-16 little endian. I don't think I'm doing with the regEx that any modern flavor of regEx worth actually calling regEx wouldn't support.
The .hgignore file has no effect for files that are tracked. Its function is to stop you from seeing files you want ignored listed as "untracked". If you're seeing "M" then they're already added (you got them with the clone) so .hgignore does nothing.
The usual way config files that differ from machine to machine are handled is to put a app.config.sample in source control, have app.config in .hgignore and have people do a copy when they're making their config edits.
Alternately if your config files allow for includes and overrides you end them with include app-local.config and override any settings in a app-local.config which you don't add and do include in .hgignore.
I have a source code of about 500 files in about 10 directories. I need to refactor the directory structure - this includes changing the directory hierarchy or renaming some directories.
I am using svn version control. There are two ways to refactor: one preserving svn history (using svn move command) and the other without preserving. I think refactoring preserving svn history is a lot easier using eclipse CDT and SVN plugin (visual studio does not fit at all for directory restructuring).
But right now since the code is not released, we have the option to not preserve history.
Still there remains the task of changing the include directives of header files wherever they are included. I am thinking of writing a small script using python - receives a map from current filename to new filename, and makes the rename wherever needed (using something like sed). Has anyone done this kind of directory refactoring? Do you know of good related tools?
If you're having to rewrite the #includes to do this, you did it wrong. Change all your #includes to use a very simple directory structure, at mot two levels deep and only using a second level to organize around architecture or OS dependencies (like sys/types.h).
Then change your make files to use -I include paths.
Voila. You'll never have to hack the code again for this, and compiles will blow up instantly if something goes wrong.
As far as the history part, I personally find it easier to make a clean start when doing this sort of thing; archive the old one, make a new repository v2, go from there. The counterargument is when there is a whole lot of history of changes, or lots of open issues against the existing code.
Oh, and you do have good tests, and you're not doing this with a release coming right up, right?
I would preserve the history, even if it takes a small amount of extra time. There's a lot of value in being able to read through commit logs and understand why function X is written in a weird way, or that this really is an off-by-one error because it was written by Oliver, who always gets that wrong.
The argument against preserving the history can be made for the following users:
your code might have embarrassing things, like profanity and fighting among developers
you don't care about the commit history of your code, because it's not going to change or be maintained in the future
I did some directory refactoring like this last year on our code base. If your code is reasonable structured at the beginning, you can do about 75-90% of the work using scripts written in your language of choice (I used Perl). In my case, we were moving from set of files all in one big directory, to a series of nested directories depending on namespaces. So, a file that declared the class protocols::serialization::SerializerBase was located in src/protocols/serialization/SerializerBase. The mapping from the old name to the new name was trivial, so that doing a find and replace on #includes in every source file in the tree was trivial, although it was a big change. There were a couple of weird edge cases that we had to fix by hand, but that seemed a lot better than either having to do everything by hand or having to write our own C++ parser.
Hacking up a shell script to do the svn moves is trivial. In tcsh it's foreach F ( $FILES ) ... end to adjust a set of files. Perl & Python offer better utility.
It really is worth saving the history. Especially when trying to track down some exotic bug. Those who do not learn from history are doomed to repeat it, or some such junk...
As for altering all the files... There was a similar question just the other day over at:
https://stackoverflow.com/questions/573430/
c-include-header-path-change-windows-to-linux/573531#573531