I use vscode with clangd extension. Clangd works really nice, but when I am editing the file, clangd starts parsing it almost right away, with minimum timeout. As a result it consumes lots of cpu and shows lots of errors for nothing, before I finish typing. Is it possible to specify some kind of timeout, so that clangd waits a couple of seconds before parsing the file that changed?
I looked into clangd --help and clangd --help-hidden, but I couldn't find any arguments that could specify that. I also didn't find anything in vscode settings (I mean there are some timeouts and delays that I can specify, but none of them seems to be the one I'm looking for).
My OS is Ubuntu, but I think it shouldn't matter.
Related
I need to be able to know all of the files a web browser has open (most specifically Google Chrome).
Right now I've only been able to find the results I need with lsof since this is a fairly low-level operating system request. Basically I use lsof and then look through the list it returns and determine whether any files are downloading and then take some actions based on this result.
The problem I'm having is that lsof is a CPU pig even on a good day. Sometimes I'm hitting a wall where lsof just goes nuts and lsof has to be killed manually. I have to believe that Chrome does something funny as it seems as though it's the only misbehaved app that causing this trouble for lsof.
I'd love to have a better way of detecting download activity, but haven't been able to come up with anything that's reliable.
It seems as though Chrome has some sort of file handle open that lsof can't deal with or that causes it to suck down a serious amount of cpu time. (I'm wondering if the problem could be a giant memory-mapped file that Chrome uses as its own private virtual memory system or something?) Since this problem doesn't happen consistently I'm trying to hunt for lsof options for macOS that might behave a little better...
Is it possible to have certain code executed whenever a file of a certain type is opened? In my case, I want to "listen" for when video files (".avi, mp4, etc.") are opened (either via the windows file explorer shell, or maybe directly from a video player?), so that I can store a history of played videos.
An hour's worth of googling turned up nothing, so I turn to you stackoverflow. Please point me in the right direction.
Thanks.
The best (and only reasonable way) to capture file system events (open/read/write) from arbitrary processes is by writing a File System MiniFilter
If you're developing a commercial product, please refrain from "hooking" Usermode APIs like CreateFile. Doing so requires numerous, platform-specific hacks, and is a compatibility nightmare.
I wouldn't hook CreateFile for this job. Windows has mechanisms built-in to handle jobs like this much more cleanly.
The easy way to handle this would be with ReadDirectoryChangesW with the FILE_NOTIFY_CHANGE_LAST_ACCESS flag. Any time a file is opened, its last-access time will be updated, so this tells you any time the file was opened.
Although it's pretty rare, that can "miss" changes under rare circumstances1. If you must have 100% accuracy (instead of, say, 99.9%), you can read change journals instead, but it's a fair amount of extra work for an advantage you may not care about.
1. There is one circumstance that isn't (necessarily) rare that you might care about though: ReadDirectoryChangesW will only work when/if your program is running. Change journals will let you know about things that happened even when your code isn't running at all.
Whenever possible, I usually tend to learn keyboard shortcuts. It's really amazing to see an experienced coder works with VI effectively.
I've been trying for sometime switching to debugging with gdb, instead of eclipse debugger (based on gdb)
And I still find it hard to actually navigate through the code, inspecting variables, etc.
Actually, I have never seen an experienced gdb user, so I'm wondering... does it worth it? Is it possible to work effectively with gdb ?
Note: I also tried cgdb, which is a curses extension of gdb. It's better, but I still feel that its still not effective enough...
GDB has a curses interface, which can be activated via the command line option -tui.
This interface has a single key mode, which makes the most common operation available with a single keystroke. If additionally you make use of automatic command execution e.g. to display variable values, when a breakpoint is reached, then this is as comfortable and quick as it gets. But if you use Eclipse anyway, I see no point in avoiding the Eclipse UI for gdb.
I used GDB inside emacs for some time, but found the time to transfer information between GDB and emacs unacceptable, so I switched to this TUI mode mentioned above. I don't know, if the transfer of information between GDB and Eclipse is faster, but at least startup time of complex programs might be much better in GDB directly than in Eclipse.
You could also try the ddd debuger:
http://www.gnu.org/software/ddd/
This question didn't get much attention, although a bounty was offered.
So I decided to investigate further the issue for myself.
Finally I stumbled upon a solution which I think can be quite effective.
It's called tmux, and it's basically similar to gnu screen.
This tool allows splitting the console to several panes, each containing different process.
Therefore it's possible to have a single window with gdb and emacs.
switching between the windows is very easy using a dedicated hot key.
On Linux, when tailing a log, I can hit enter a couple times to give me a bit of separation in the output. Makes it easy to debug or just watch for things happening.
I've tried a couple of tail programs for Windows ("Tail for Win32" and "mTail") and they cannot do that. It's a bit painful to check the timestamps to find what the last set of lines that was dumped out. Rather than conduct an exhaustive survey myself, and because I didn't find this feature addressed here, I thought I'd ask the SO collective mind. Does this behaviour exist in any program for windows?
You can try Hoo WinTail or SnakeTail, that supports the ability to make bookmarks. Maybe there are other alternatives
Try this:
Win Log Inspector
It allows also to connect to a remote file by using http or ssh protocol
I am experiencing kernel panics when I kill node js under certain circumstances such as when it is stuck in an infinite loop (always) or when it is a stopped job under Bash (sometimes).
EDIT: My code isn't doing anything network related. I'm running a modified CoffeeScript repl.
I don't expect to be able to get a direct answer since it is a rather complicated problem and may be a bug in node, v8, or OS X for all I know at the moment.
However, I am at least somewhat familiar with all the technical aspects required to find it so I think with the right clues I could narrow it down, prevent it, and send a bug report to the appropriate people.
Feel free to have me investigate anything, up to and include using programs such as SIMBL and Application Enhancer if need be.
Here is the error report from the last kernel panic:
http://pastie.org/3043592
Thanks!
I can't tell for sure, but my suspicions would lie first with the following kernel extensions:
at.obdev.nke.LittleSnitch. Little Snitch messes with the network stack in some pretty major ways, so it seems likely that it might have something to do with your crashes (assuming that your node.js app is using sockets).
com.cisco.nke.ipsec. It also has to do with networking, so I'm also suspicious. Less so, though, because it (theoretically...) should just be adding a Cisco VPN interface.
org.pqrs.driver.NoEjectDelay, org.pqrs.driver.PCKeyboardHack, org.pqrs.driver.KeyRemap4MacBook. They're hacks. Need I say more?
com.shapeservices.msm.driver.MSMFramebuffer, com.shapeservices.msm.driver.MSMVideoDevice. iDisplay is unlikely to be related, but it might be!
If all else fails, submit a bug report at https://bugreport.apple.com.