When VIM to used make builds using GNU make utility, there are two issues I see with the default configuration.
Background execution without freezing the editor.
Showing execution progress like emacs compile/grep command
Background execution is possible with simple !start or with plugins like dispatch or AsyncExecute etc
None of these options show the progress in a scratch window with warnings/errors emitted during build progress.
Is there anything I am missing ?
Searching the web took me to shellpipe/tee workaround which does not seem to work on Windows even after installing tee.exe
Vim only parses the :make output after the command has finished.
If you launch the build asynchronously, you'd also have to periodically read the resulting output and tell Vim to parse it via :cfile errorfile. There may be a plugin that provides such auto-reload logic, but I'm not aware of any.
In general, there's very little asynchronicity and parallelism built into Vim (possibly due to its age and implementation in C).
Related
I would like to debug a C++ program in VSCode. The problem is this program is run as part of a large and messy build system that spawns many processes and prepares input for the program. In other words if I run:
./do the_task
It will compile a load of C++, generate some input and eventually - through several layers of Bash, Python and Makefiles - run something like this:
/very/long/path/to/the_task --lots --of --arguments /very/long/path/to/generated_input.xml
I'd like to debug that process using VSCode/GDB, in such a way that I can
Set breakpoints in the_task.cpp
Just click "Start debugging" with the launch.json set to run do the_task
Unfortunately that doesn't work because by default GDB doesn't follow child processes. You can tell it to but then it will halt the parent process so that only a single process runs at a time. That causes everything to get stuck at some point in my case.
Some ideas I've had:
Is there a way to tell GDB to run a script when a new inferior (process) starts, check the executable name and then detach from the child if it doesn't match?
I could create a proxy GDB/MI wrapper that pretends to VSCode that the program has been started (so the connection doesn't time out), and then when we get to running /very/long/path/to/the_task prefix it with gdb --interpreter=mi and forward on all of the cached commands (to set breakpoints etc.) This seems like quite a lot of work and quite hacky so I'm not sure I like it.
Prefix /very/long/path/to/the_task with gdbserver. Then I can connect to it from VSCode. This is definitely the simplest and most obvious solution but the UX sucks - you have to manually start the command, then wait, then click "start debugging". Plus you're inevitably going to run into port reuse annoyances.
3, but write a custom VSCode extension that automatically starts debugging when it detects gdbserver has started. I've done this for Python debugging so it does work but there are some minor annoyances (e.g. if you restart VSCode and it restores a terminal session it doesn't work). Also it's a fair amount of work.
Is there an obvious solution I'm missing?
I used Msys1 for many years and was used to CTRL+C for killing processes that I start within my shell.
After updating from Msys1 to Msys2 CTRL+C does not work any more.
For example: I start "make" press CTRL+C. Shell prompts to finished and enables typing more commands, but make.exe is still running+working.
Result of my analysis:
In Msys1: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is (12345).
In Msys2: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is the (34567), which is not alive anymore. So I guess Msys2 uses an additional process for starting subprocesses.
I tried bash.exe, shell.exe, mintty.exe,... all seems to have the same problems.
Content I found searching
:
This ticket just focuses on missing signal types -> I don't care about that.
https://sourceforge.net/p/msys2/tickets/135/
The issue in this mailing list seems to be near my problem, but I do not understand what I should change, or if the change can only be made within the msys2 implementation. (What is CREATE_NEW_PROCESS_GROUP? and how to change it):
https://www.cygwin.com/ml/cygwin/2012-08/msg00062.html
Kindest regards
Luke
It looks like mintty provides the default terminal for MSYS2 (note that this is different from the shell that is run within). If so, then the "Ctrl+C kills native (e.g. MSYS2 compiled) programs abruptly rather than sending a catchable signal" problem is the same one as described over on https://superuser.com/questions/606201/how-to-politely-kill-windows-process-from-cygwin and the MSYS2 wiki porting FAQ.
If what you're attempting works when you are using Windows' default terminal (e.g. when using cmd.exe from the start menu) then this is the issue you're seeing.
It is in fact suggested in the other answer but you can just run each program by winpty.exe which will make CTRL-C working again.
After clearing a Mac terminal (via Command K, or the "Clear All" command under the edit menu), is there a way to easily restore the previously cleared text?
Periodically, when I run a long process on a Mac Terminal (such as a suite of unit tests) I prefer to clear the terminal. I do this so when I'm scrolling up to look over the results of the process, I can focus ONLY on the results of that process and not other commands I've recently run. (Such as, say, a different suite of tests)
But, sometimes I do eventually want to go back and look over the previous suit of tests.
Is there a way to restore previous terminal text?
The terminal is not going to help with restoring the text. It is gone.
If you anticipate wanting to review the text, you could (in a more or less transparent manner—not interfering with your work) run your session in script. That records everything sent to the terminal (including escape sequences for vi).
If your use of the terminal is largely just cat'ing files or watching logs, then the resulting typescript file is usable with less -R. It does not work well with cursor-movement, but for those, I use slowcat or similar filters to slowly cat a file, etc. For best results, the terminal emulator interprets escape sequences reliably.
When running the tests why not redirect the output to a file? This keeps your terminal clear and you can cat (or tail or more or less) that file to see only the results of that process. Another advantage is you can keep these log files around for future reference if needed.
I am trying to tidy up a process that uses multiple system calls from inside a ruby script executed using rubyw.exe (1.8.7).
As far as I can understand the main reason for rubyw.exe is that it doesn't pop up a command prompt to distract the user. However it appears that the system calls from within that process still do generate these popups which is very distracting for the users of this process script.
Does anyone know how to do this?
There are lots of questions similar to this on SO but none which quite answers this, if I was using python this questions/answer would help (http://code.activestate.com/lists/python-list/46042/) but so far my searching hasn't found a way to accomplish this with ruby.
UPDATE: There is this thread here Hiding curl Window on Windows which is close but the only working solution there doesn't also allow you to get the standard output.
I ended up going with the win32-open3 gem. Because fork isn't implemented on windows systems you can't use the built in open3 and you'll need to do a
gem install win32-open3
However this comes with flags that you can pass to the call method, in particular
There are a couple of differences in the Windows version for open3
(which
also apply to Open4.popen4) - the mode flag and the show flag. For the
mode, you can specify either 't' (text, the default) or 'b' (binary) as a
second argument. For the show flag, you can specify either true or false,
which will show the console window, or not, depending on the value you
pass. The default is false.
Users of this particular script are no longer bombarded with 15 cmd windows that constantly steal focus, so .... win?
I'm running a test script from batch file.
Because it is test, the programs are expected to fail once in a while. It is file as long as error code is returned so I can continue and mark specific test as failed.
However there is very annoying behavior of executable files under Microsoft Windows - if something fails it pop-ups window like:
This application has failed to start because foo.dll was not found, Re-installing the application may fix the problem
<OK>
Or even better:
The instruction at "..." referenced to memory at "..." ..
Click on OK to terminate the program
Click on CANCEL to debug the program
The result is known - the script execution blocks till somebody presses "Ok" button. And when we talk about automatic scripts that may run automatically at night in some headless virtual machine, it may be very problematic.
Is there a simple way to prevent such behavior and just make an application to exit with failure code - without changing the code of the program itself?
Is this possible at all?
The answer is following: You need to disable WER.
Simplest description for this I found at http://www.noktec.be/archives/259
Simply (ON XP): Right Click on My Computer > Advanced > Error Reporting > Disable
Voila - programs crash silently!
This does not solves problem when DLL is missing, but this is much rare case and this is good enough for me.
You can suppress AV's and such from showing a dialog box by running your application, or the script (the script engine, like cscript.exe), under a debugger.
Use Gflags.exe, or modify the registry directly, and set Image File Execution Options for the image in question. See this article for details on how to use the appropriate registry keys. You can set it up using a debugger commandline like "C:\Debuggers\ntsd.exe -g -G -c'command'", where you can pass commands to ignore certain types of exceptions in the -c"commmand" argument. This will effectively give you a tool to suppress interactive dialogs as a result of exceptions like AV, and will let the process continue (presumably to immediate end after the exception has occured).
This article explains the commands you can use to control exceptions and events from withing the debugger.
The -g and -G flags make sure that the process won't break into the debugger automatically during process start and end respectively. You'll have to play with the various exception suppression options to make sure that you 'eat' all possible first and second chance exceptiosn that might cause the process to break into the debugger.
Also, if you can tolerate a process being broken into the debugger (as against being stuck showing a dialog box), perhaps that would be a better option overall. You can evaluate each debug break in batch mode at a later time and decide which bugs you care to fix.
It is possible. We used to use IBM's Rational Robot product which could monitor the screen for specific items and, if found, send keystrokes to windows and other sorts of things.
We actually used it for fully automated unit and system testing, much like you're trying to do.
Now I thought that Robot has been through quite a few name changes so it may be hard to find but there it is, right on IBM's web page and with a free downloadable trial for you. It's not cheap, clocking in at a smidgeon under USD5,000 but it was worth it for us.
There's also TestComplete where you could get a licence for just unedr USD1,000 - it touts "Black-box testing - Functional testing of any Windows application" as one of its features and also has a downloadable demo to see if it's suitable before purchase.
However, you may be able to find another product to do the same sort of thing.
I initially thought of Expect but the ActiveState one seems to concentrate on console applications which leads me to believe it may not do graphics well.
The only other option I can suggest is to write your own program in VBScript. I've done this before to automate the starting of many processes (log on to work VPN, start mail, log in and so on) so I could be fully set up with one mouseclick instead of having to start everything manually.
You can use AppActivate to bring a window to the foreground and SendKeys to send arbitrary keypresses to it after that. It's possible you may be able to cobble together something from that if you want a cheaper solution.