I am working on a vscode extension.
I want to know the events emitted after I do something in vscode, e.g., printting out all the events if a debug session starts.
Of course, onDebug event is one, but what are the remainings.
This function is pretty similar to strace command where you can trace the system calls during execution of a program.
The vscode log file is in ~/.config/Code/logs but currently I do not find any useful information.
Related
In an extension, I'm trying to implement a TextEditorCommand in response to which the document in the active editor is processed by an external program. I managed to do so by registering a function with the command, within which a Task object is created and executed:
in function activate:
vscode.commands.registerTextEditorCommand('extension.command', process);
in function process(textEditor):
const document = textEditor.document;
const task = new vscode.Task(
{type: ''},
vscode.TaskScope.Workspace,
extensionDisplayName,
extensionName,
new vscode.ProcessExecution(executable, [fileName].concat(args)));
vscode.tasks.executeTask(task);
This works, except that executing a task leads all open documents to be saved, which is unnecessary and may be unwanted; I only need the active editor document to be saved, which I can do myself.
Therefore my question: Is it possible to run an external process in the integrated terminal without a Task?
I checked whether I can execute the ProcessExecution on its own, without passing it to a Task, but that doesn't seem possible.
I also tried to directly create a terminal, but vscode.window.createTerminal does not provide the option to specify an executable, just a shell – though I might simply pretend that my executable is a shell?
Moreover, I already failed at creating any kind of terminal; putting
````typescript
vscode.window.createTerminal(extensionDisplayName);
````
into the `activate` function seems to have no effect whatsoever.
Turns out the transpiler process wasn't running, so my code never made it into the running extension.
I could simply use node's child_process.spawn, but then the process would not be attached to VS Code's integrated terminal.
Update: Specifying an arbitrary executable as the "shell" running in the Terminal works.
However, it seems currently impossible to keep the terminal tab open after the process ended, so a shell or another wrapper is necessary.
But then it's impossible to get the exit status of the actual (wrapped) process, except maybe by having the wrapper write it to the terminal and parsing it's text content... nah, impossible too. Ugh
I'm using VS Code to write and debug a C++ program binding to libfuse.
Unfortunately, if you kill a libfuse process with SIGKILL, you then have to use sudo umount -f <mountpoint> before you can start the program again. It's a minor nuisance if I have to do this every time I want to stop or restart debugging, especially as I shouldn't have to authenticate to do such a regular task (the sudo is somehow necessary despite the mount occurring as my user).
While I think this is mainly FUSE's fault (it should gracefully recover from a process being ungracefully killed and unmount automatically instead of leaving the directory saying Transport endpoint is not connected), I also think there should be a way to customise VS Code (or any IDE) to run some clean-up when you want to stop debugging.
I've found that entering -exec signal SIGTERM in the Debug Console will gracefully unmount the directory correctly, stop the process and tell VS Code it's no longer debugging (status bar changes back from orange to blue). But I can't seem to find a way to automate this. I've tried using a .gdbinit file, with some inspiration from this question:
handle SIGTERM nostop
# This doesn't work as hook-quit isn't run when quitting via MI mode, which VS Code uses...
define hook-quit
signal SIGTERM
end
But as noted in the linked question, GDB ignores quit hooks when in MI mode, and VS Code uses MI mode.
The ideal solution for me would be if I could put something in a .vscode configuration file telling it to send -exec signal SIGTERM when I click the stop or restart buttons (and then wait for whatever notification it's getting that debugging has stopped, before restarting if applicable) but I imagine there probably isn't an option for that.
Even if the buttons can't be customised, I'd be happy with the ability to have a keybinding that would just send -exec signal SIGTERM to the Debug Console without me having to open said console and enter the command, though the Command Palette doesn't show anything useful here (nothing that looks like it will send a specified Debug Console command), so I don't expect there's a bindable command for that either.
Does anyone have any suggestions? Or would these belong as feature requests over on the VS Code github? Any way to get GDB to respect its quit hook in MI mode, or to get FUSE to gracefully handle its process being killed would be appreciated too.
On Centos 6.2, trying to get the kernel log redirected to the serial console, I came across an issue where agetty seems to be respawning every few keypresses.
That is, I get a login prompt in the middle of typing (after logging in).
In order to investigate the issue further, I'm looking for the location of agetty logs, but to no avail. Where and how can I see log messages for respawned agetty process?
The "diagnostics" section of the "agetty" command manpage states:
Depending on how the program was configured, all diagnostics are written to
the console device or reported via the syslog(3) facility. Error messages are
produced if the port argument does not specify a terminal device; if there is
no utmp entry for the current process (System V only); and so on.
The syslog facility by default writes the "/var/log/messages" file, but it can be configured to write another file by editing its configuration file "/etc/syslog.conf".
Finally, if the error you get is "respawning too fast", you should check your "/etc/inittab" file, as described here.
I'm working with Windows 7 64X and DebugView 4.76.0.0.
Logs isn't shown on DebugView.
I trying to write logs with Debug.WriteLine("Text"); and see nothing.
I can see that It's connected to my computer.
When I use DebugView V4.64.0.0 I get error message that it is already connected to other instance of DebugView, but I've checked and there isn't any other.
What can I do or check ?
BTW,
I can see the log in the output window.
Regards,
Eitan Gabay
To check if you really have another instance of debugview running, open up your task manager, and select "show processes from all users". Make sure that only one debugview is running.
When debugging through Visual Studio, Visual Studio actually competes against DebugView. If you were to compile your executable, and run it externally, you will see your log messages printed in DebugView.
One other thing that people sometimes overlook is that Debug.Write statements are excluded if a program is compiled for Release. However, you can still write to the trace if you use Trace.Write instead of Debug.Write.
All messages that you print go to a shared section of memory called DB_WINBUFFER link. It is important to realize that each windows session has its own "DB_WINBUFFER". Whenever DebugView detects that you are not in session 0, it will provide a "Capture Global" option. If your program is running as a windows service, then you will need to enable capture global (unless you are already in Session 0, which is only possible in Windows XP).
Howdy, I am trying to run matlab remotely on windows via OpenSSH installed with Cygwin, but launching matlab in windows without the GUI seems to be impossible.
If i am logged in locally, I can launch matlab -nodesktop -nodisplay -r script, and matlab will launch up a stripped down GUI and do the command.
However, this is impossible to do remotely via ssh, as, matlab needs to display the GUI.
Does anyone have any suggestions or work arounds?
Thanks,
Bob
Short story: is your script calling exit()? Are you using "-wait"?
Long story: I think you're fundamentally out of luck if you want to interact with it, but this should work if you just want to batch jobs up. Matlab on Windows is a GUI application, not a console application, and won't interact with character-only remote connectivity. But you can still launch the process. Matlab will actually display the GUI - it will just be in a desktop session on the remote computer that you have no access to. But if you can get it to do your job without further input, this can be made to work, for some value of "work".
Your "-r script" switch is the right direction. But realize that on Windows, Matlab's "-r" behavior is to finish the script and then go back to the GUI, waiting for further input. You need to explicitly include an "exit()" call to get your job to finish, and add try/catches to make sure that exit() gets reached. Also, you should use a "-logfile" switch to capture a copy of all the command window output to a log file so you can see what it's doing (since you can't see the GUI) and have a record of prior runs.
Also, matlab.exe is asynchronous by default. Your ssh call will launch Matlab and return right away unless you add the "-wait" switch. Check the processes on the machine you're sshing to; Matlab may actually be running. Add -wait if you want it to block until finished.
One way to do this stuff just use -r to call to a standard job wrapper script that initializes your libraries and paths, runs a job, and does cleanup and exit. You'll also want to make a .bat wrapper that sets up the -logfile switch to point to a file with the job name, timestamp, and other info in it. Something like this at the M-code level.
function run_batch_job(jobname)
try
init_my_matlab_library(); % By calling classpath(), javaclasspath(), etc
feval(jobname); % assumes jobname is an M-file on the path
catch err
warning('Error occurred while running job %s: %s', jobname, err.message)
end
try
exit();
catch err
% Yes, exit() can throw errors
java.lang.System.exit(1); % Scuttle the process hard to make sure job finishes
end
% If your code makes it to here, your job will hang
I've set up batch job systems using this style in Windows Scheduler, Tidal, and TWS before. I think it should work the same way under ssh or other remote access.
A Matlab batch system on Windows like this is brittle and hard to manage. Matlab on Windows is fundamentally not built to be a headless batch execution system; assumptions about an interactive GUI are pervasive in it and hard to work around. Low-level errors or license errors will pop up modal dialog boxes and hang your job. The Matlab startup sequence seems to have race conditions. You can't set the exit status of MATLAB.exe. There's no way of getting at the Matlab GUI to debug errors the job throws. The log file may be buffered and you lose output near hangs and crashes. And so on.
Seriously consider porting to Linux. Matlab is much more suitable as a batch system there.
If you have the money or spare licenses, you could also use the Matlab Distributed Computing toolbox and server to run code on remote worker nodes. This can work for parallelization or for remote batch jobs.
There are two undocumented hacks that reportedly fix a similar problem - they are not guarantied to solve your particular problem but they are worth a try. Both of them depend on modifying the java.opts file:
-Dsun.java2d.pmoffscreen=false
Setting this option fixes a problem of extreme GUI slowness when launching Matlab on a remote Linux/Solaris computer.
-Djava.compiler=NONE
This option disables the Java just-in-time compiler (JITC). Note that it has no effect on the Matlab interpreter JITC. It has a similar effect to running Matlab with the '–nojvm' command-line option. Note that this prevents many of Matlab's GUI capabilities. Unfortunately, in some cases there is no alternative. For example, when running on a remote console or when running pre-2007 Matlab releases on Intel-based Macs. In such cases, using the undocumented '-noawt' command-line option, which enables the JVM yet prevents JAVA GUI, is a suggested compromise.
Using putty use ssh -X remote "matlab" it should work