How to see log when debugging from vscode?

Development
1

After some faffing, I am now able to build and debug Rack and plugins in VSCode (on Windows), but I’m missing the console log that I saw when running rack in a MINGW console outside of VSCode using make run.

Anyone have an idea where I can find that log, or what configuration I need to see it in VSCode somewhere? There’s some useful stuff in it.

Here’s my working-so-far launch,.json:

{
    "name": "(gdb) Launch",
    "type": "cppdbg",
    "request": "launch",
    "program": "${workspaceFolder}/Rack.exe",
    "args": ["-d"],
    "stopAtEntry": true,
    "cwd": "${workspaceFolder}",
    "environment": [ {"name": "RACK_DIR", "value":"${workspaceFolder}"} ],
    "externalConsole": true,
 
    "MIMode": "gdb",
    "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe",
    "setupCommands": [
        {
            "description": "Enable pretty-printing for gdb",
            "text": "-enable-pretty-printing",
            "ignoreFailures": true
        },
        {
            "description": "Set Disassembly Flavor to Intel",
            "text": "-gdb-set disassembly-flavor intel",
            "ignoreFailures": true
        },
        {
            "description": "Set UTF-8 charset",
            "text": "set charset UTF-8",
        }
    ]
},
1 Like
2

I think the log you are looking for is located in the Rack user folder, log.txt

3

Turns out that in Development mode (-d option), which is typical case during development, it doesn’t write log.txt and instead to stderr. (With -d the system and user directories are the same folder Rack.exe is running from.)

So the question is, how to capture stderr while debugging in VSCode?

I do see this in the terminal:

pcdem@PDesk  /g/repos/Rack
$  /usr/bin/env c:\\Users\\pcdem\\.vscode\\extensions\\ms-vscode.cpptools-1.15.4-win32-x64\\debugAdapters\\bin\\WindowsDebugLauncher.exe --stdin=Microsoft-MIEngine-In-dpy52sip.scg --stdout=Microsoft-MIEngine-Out-nnadnfc3.qyi --stderr=Microsoft-MIEngine-Error-xqwemjgx.qfc --pid=Microsoft-MIEngine-Pid-303biirx.ib4 --dbgExe=C:/msys64/mingw64/bin/gdb.exe --interpreter=mi

So VScode is piping stderr somewhere, but I’m not seeing it in the integrated terminal, despite configuring the launch command to use the integrated terminal (per a number of resolutions to VSCode issues).

Seems this isn’t currently possible with VSCode+MINGW64+GDB, and I must resort to modifying Rack so that it creates the log file even with -d.

4

or you could just debug from the command line like most of us do. But google tells me that it’s pretty easy to do what you want (without re-writing VCV).

Does this work? Debug output doesn't appear in debug console without "outputCapture": "std" · Issue #41600 · microsoft/vscode · GitHub

1 Like
5

Thanks for trying – (truly - I don’t mean it sarcastically. I appreciate all the time you spend helping people here). That’s for when you’re running Node.

What’s needed is a working configuration for type=cppdbg the MINGW64 console, and the GDB debugger. I’m not familiar with running GDB in the console. I suppose it would be like going back to days when I had to spend a lot of time doing Windows kernel debugging). I’ve been spoiled by the good GUI debuggers. But I suppose I should try it out.

6

My workflow is totally janky. I do most of my debugging in a unit test suite that runs in old Visual studio. So I don’t need to debug much as a plugin running in vcv.

7

Much better debugging experience there.

Back in the day I was a developer on Visual Studio, I had my hands in the Editor, Unicode support (even on Win95, which was a non-Unicode OS), and the Debugger. Before that I did Beta support for Microsoft C 6, which may have been Microsoft’s first home-grown C compiler. IIRC they had licensed one before that.

8

haha, I’m older. I used Borland c++ until MS finally came out with one. Developed an app for windows 2.0 (before that, of course).

1 Like
9

Not sure if you’re older :wink:

In college, my Fortran class was taught on a mainframe (CDC something something). Input was on punch cards where you submitted your card decks at a service windows and you picked up your program output (syntax error on card# 123) at the window hours later. You could tell who the nerds were because they knew how to use format cards in the keypunch machine. The real nerds like me haunted the computer center at night so you could get better turnaround on your jobs.

At another college later on, the course for Assembly was taught on an HP-1000 – a primitive process-control computer that was programmed using punch cards. this time you had direct access to the card reader, so no waiting for your job. For extra credit at the end of the class, you programmed it in machine language using toggle switches and a push button on the front panel to set the binary code of each opcode. Assignment was to get the panel lights to flash marching across the panel. Extra extra credit was to animate two lights going opposite directions. I got extra-extra credit ;-).

Mine was the last class that used this machine. The next year they moved to Apple IIs. I felt a little cheated.

In high school we used BASIC running on a PDP-11 at the University via a teletype in the Calculus room. After the assembly class everything was taught in Pascal on a PDP-11 (probably the same one that we used in High school). I got a special permission from the teachers to use Turbo Pascal that I ran on my personal Kaypro II, so I had an unfair advantage.

10

Ditto… not sure you are older than me (71) :wink:

11

@k-chaffin - you have me beat. I arrived in June '59.

I’m inspired by your passion and vitality – keep going!.

1 Like
12

Ok, we are the same age. My school also used mainframe and Fortran. Toggle switches on a pdp 11 for asm, etc…