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.
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?
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.
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.
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.
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.
The flag -mconsole on windows system add an console windows, this facilitate the pipe redirect between vscode internal terminal and the executable application.
Don’t need any extra configurations in launch or task .json, just point to run your Rack compiled exe, and set the cwd diectory relative.
The advantages to have an multi-root workspace is to have the Plugin and Rack repository opened in one editor, so you can set and share vscode settings, and other multi-root feature, this also help to use the internal terminal, if it is configured to use the mingw64 terminal, as internal one,
and more to complete the vscode environment git get/git update/edit/compile/debug experience.