I have a golang project, but am using a bit of c++. I downloaded a header file dependency, nlohmann/json, and is 22875 lines long, so naturally my github languages is not showing the proper language (Go) and is instead showing c++. How can I remove the json.hpp from the github linguist? I know that the .gitattributes file exists and I can change the language of some files, but how can I remove a file entirely from the linguist?
You can't tell Linguist to skip a file entirely. But I don't think that's actually what you want, as you don't care if it remains highlighted, right? You can tell Linguist to ignore some files when computing language statistics. In your case, the best way to do that would be to declare these C++ files vendored, with e.g.:
*.hpp linguist-vendored
See Linguist's README for more information.
Related
I am trying to refactor some code. My approach (using vi) is to copy my old libraries from /lib to /lib2. That way I can hack out big sections, but still have a framework to refactor.
So I go ahead and change mymain.p6 header from use lib '../lib'; to use lib '../lib2';. Then I delete a chunk of the lines in ../lib2/mylibrary.pm6 and make darn sure :w is doing what I expect.
Imagine my surprise when my program still works perfectly despite having been largely deleted. It even works when I rm -R /lib, so nothing back there is persisting.
Is there a chance that I have a precomp of the old lib module lying around? If so, how can I flush it?
This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
implementing Perl 6.d.
Precompiled modules are stored in the precomp directory. You can try to rename or delete the ~/.precomp directory.
See also this SO question here.
Update. Well I thought I'd replicated the scenario. It was reliably showing the bug during a one hour period. But now it isn't. Which is pretty disturbing. Investigation continues...
I've replicated #p6steve's scenario in case someone wishes to report this as a bug. At the moment I'm with #p6steve (per comment below) in that I'm going to treat this as a DIHWIDT rather than a reportable bug. That said, now we have a golf'd summary.
Original main program using path1 followed by the module it uses directly and then the one that uses:
use lib 'path1';
use lib1;
say $lib1::value;
unit module lib1;
use lib2;
our $value = $lib2::value;
unit module lib2;
our $value = 1;
This displays 1.
If the libs are copied to a fresh directory, including the .precomp directory, and then the lib2 is edited but the lib1 is not, the change to lib2 is ignored.
Here it is on glot.io before and after copying the libs and their .precomp directory and then editing the libs.
Original answer
Thank you for editing your question. That gives us all more to go on. :)
I'd like to try to get to the bottom of it and hope you're willing to have a go too. This (n)answer and comments below it will record our progress.
From your comment on #ValleLukas' answer:
Then I noticed ../lib2/.precomp directory - so realised library precomps are stored in the library folder. That did the job!
Here's my first guess at what happened:
You copied lib en masse to lib2. This copied the precomp directory with it.
You modified the use lib ... statement in mymain.p6 to refer to lib2.
Your mymain.p6 code includes a use module-that-directly-or-indirectly-uses-mylibrary.
You modify mylibrary.pm6.
But nothing changes! Why not?
You haven't touched module-that-directly-or-indirectly-uses-mylibrary, so Rakudo uses the precompiled version of that module from the lib2/.precomp directory.
Speculating...
Perhaps the fact that that precompiled version exists leads the precompilation logic to presume that if it also finds a precompiled version of a module that's used by module-that-directly-or-indirectly-uses-mylibrary then it can go ahead and use that and not even bother to check how its timestamp compares to the source version.
Does this match your scenario? If not, which bits does it get wrong?
The CMake doc says about the command file GLOB:
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.
Several discussion threads in the web second that globbing source files is evil.
However, to make the build system know that a source has been added or removed, it's sufficient to say
touch CMakeLists.txt
Right?
Then that's less effort than editing CMakeLists.txt to insert or delete a source file name. Nor is it more difficult to remember. So I don't see any good reason to advise against file GLOB.
What's wrong with this argument?
The problem is when you're not alone working on a project.
Let's say project has developer A and B.
A adds a new source file x.c. He doesn't changes CMakeLists.txt and commits after he's finished implementing x.c.
Now B does a git pull, and since there have been no modifications to the CMakeLists.txt, CMake isn't run again and B causes linker errors when compiling, because x.c has not been added to its source files list.
2020 Edit: CMake 3.12 introduces the CONFIGURE_DEPENDS argument to file(GLOB which makes globbing scan for new files: https://cmake.org/cmake/help/v3.12/command/file.html#filesystem
This is however not portable (as Visual Studio or Xcode solutions don't support the feature) so please only use that as a first approximation, else other people can have trouble building your CMake files under their IDE of choice!
It's not inherently evil - it has advantanges and disadvantages, covered relatively well in this answer here on StackOverflow. But if you use it carelessly, you could end up ignoring dependency changes and requiring clean rebuilds of large parts of your codebase.
I'm personally in favor of using it - in smaller projects, or on certain subdirectories in larger ones - to avoid having to enter every file manually into the build files. Edit: My preference has changed and I currently tend to avoid it.
On top of the reasons other people here posted, imho the worst issue with glob is that it can yield DIFFERENT file lists on different platforms. As I see it, that's a bug. In OSX glob ignores case sensitivity and in a ubuntu box it doesn't.
Globbing breaks all code inspection in things like CLion that otherwise understand limited subsets of CMakeLists.txt and do not and never will support globbing as it is unsafe.
Write script to dump the globbed list and paste it in, its very simple, and then CLion can actually find the referenced files and infer them as useful. Maybe even put such script into the tree so that the other devs can either run it without being a moron OR set git hooks to make it happen.
In no case should some random file dropped into some directory ever get automatically linked that's how trojans happen.
Also CLion without context jumping to known definitions and what not, is like hiking barefoot /// why bother.
I'm trying to get a Cocoa development environment working in Emacs, and I'm 80% of the way there. The one feature I miss is Xcode's "Open Quickly", which basically performs a fuzzy match of the string you type against the filenames referenced in the Xcode workspace and the symbols defined in those files.
My problem is that our project is huge: if I generate a TAGS file using etags for the .h and .m files in our project's sub-directories, the result is over a gig in size and Emacs complains "TAGS file is large. Really open?", and if I say yes, then Emacs hangs and becomes essentially unusable. Of course, this is before I've even considered indexing tags for system libraries. I've also tried projectile, but unfortunately it's similarly unusable on a project of my size (on the order of a full minute to find a match).
It occurs to me that all the indexing information I really want is in the Xcode projects themselves, so if I had an Emacs package that could parse them and traverse their dependencies, that might be a start, but I'm not aware of any such package.
Any suggestions/solutions in this respect?
I've never found a single function quite as convenient as Xcode's "Open Quickly", but these days I use
helm-projectile-git-grep when I want to match on strings I know to be in the filenames, and
helm-git-grep for quick searches through the contents of the files themselves.
I've found that this gets me really close to what I wanted in my original question.
I have two files:
black.less
/* imports */
#import "elements.less";
#import "crush.less";
#import "tree.less";
I'm using the less watch functionality by adding:
less.watch();
Sure enough I can see the traffic getting black.less. Black.less hasn't changed though so any change in any of the files being imported is not counted as a change and the style is not updated.
If I however touch black.less the style updates as it should.
Is there a way to automatically update regardless of if it's an imported file or the actual less file being added to the page i.e. so that I only have to change let's say tree.less.
/K
I use Grunt and the grunt-contrib-less plugin to watch all of my less files and compile them into CSS as they change.
Then I use live.js in the browser to watch the CSS files.
The advantage to doing it this way is that I can do the same thing with my HTML and JS files, as well as run tests, lint my JS files, etc.
Remy Sharp recently wrote a post about how newer versions of Chrome support the ability to save files that you edit in the dev tools back to the file system.
He advocates Never having to leave devtools. Just do your edits right in the browser. The advantage to this solution for you is that you could continue to use the client-side Less compiler.
(I still like my robust text editors and command-line too much to ditch them entirely, but thought this answer would likely appeal to at least a few people who arrived at this question.)
Here's another quick way.
watch -n 1 touch black.less
This may be too late for op, but I had the same question and maybe others have it too.
less-watch-compiler will watch a directory (and sub-directories) for changes and compile any less code to a destination folder. The cool bit is that you can specify the main file and only the main file will be compiled when any file in the source directory is changed.
Usage:
less-watch-compiler [options] <source_dir> <destination_dir> [main-file]
I have a need to handle various rar/zip files, in Objective-C. Ideally I'd like to be as flexible as possible in terms of rar/zip versions. I'd also like to be able to only extract certain files from the rar/zip files, after pulling out a list of the file contents.
If that wasn't enough, I'd like to be able to access and modify the zip comment.
Is this easily possible in objective-c? I've searched around a lot and found a lot of half-finished libraries that don't do everything I want, or only support rar up to version 2, or don't support extracting single files.
I know I could just use the command line unzip tool that ships with MacOS Panther and up, but this seems inelegant and doesn't help me with rar files, as no unrar application ships with MacOS by default.
Can anyone point me at a decent library that does one or the other of these two types of files, or a recommended best approach for dealing with this problem? I know that one option is to wrap the unrar source, and also wrap the zlib source, but this to me is a daunting task. If there's no other option I'll do it - any advice or guidance on this would be gratefully received.
Thanks!
Yes, doing that it's easy in objective C. For zip files just use ZLIB (it's already included in Mac OS X.
RAR is not that simple though. Look for a C library (not an Objective-C library). There will be way more C libraries for RAR handling than Objective-C ones. And you can use all C libraries you want within an Objective-C program.