VS Code with stdin/out .exe server on Windows - visual-studio-code

I have an LSP server that works fine with VS 2019 IDE. I am now trying to get it to work with VSCode. I wrote a simple extension for VSCode that was working with the server at one point, but VSCode is now not working at all. So, I decided to write a simple C program that simply reads stdin and echos the characters to stderr, not expecting it to work, but to verify that VSCode is at least trying to communicate with the server. As with my original server, this program receives absolutely nothing: VSCode is not sending any packets to the server, and I don't know why.
Here is the simple "echo" server code. All it does is read stdin one character indefinitely then echo the char more or less to stderr, flush()ing each time.
#include <iostream>
#include <stdio.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <io.h>
int main()
{
for (;;)
{
char buf[10];
int readc = _read(0, buf, 1);
fprintf(stderr, "%d\n", buf[0]);
fflush(stderr);
}
return 0;
}
Here is a stripped-down VSCode client extension, derived from the doc, which so happens to provide zero information on spawning a server as a process. This calls spawn() of the server with a window.
export function activate(context: vscode.ExtensionContext) {
const server: vscodelc.Executable = {
command: `C:/Users/kenne/source/repos/ConsoleApplication1/Debug/ConsoleApplication1.exe`,
args: [],
options: {shell: true, detached: true }
};
const serverOptions: vscodelc.ServerOptions = server;
let clientOptions: vscodelc.LanguageClientOptions = {
// Register the server for plain text documents
documentSelector: [{ scheme: 'file', language: 'plaintext' }]
};
const client = new vscodelc.LanguageClient('Antlr Language Server', serverOptions, clientOptions);
console.log('Antlr Language Server is now active!');
client.start();
}
(Via debugging, I figured out that I needed options: {shell: true, detached: true } in the ServerOptions struct to make spawn() create a detached window for the process.) Running the client, the server is spawned with a window, but there is indeed no characters written to the server, even for the simple C "echo" program. In the debugger, I even see that write() is called in the client code, into the json write code, and then into the Node write code. For the VS2019 IDE, this all works perfectly fine.
Does anyone have any ideas on how to get an executable server that uses stdin/stdout to work with VSCode?

The answer is that the tables that the package.json file were messed up. It contains tables required for the server: "activationEvents" describes all the languages supported; "languages" associate a file extension with a language. In addition, the language table is duplicated in the LanguageClientOptions in the activate() function. Without these tables, VSCode may not send an open file request to the LSP server, or even not start the LSP server. In addition, there is a bug in libuv that prevents "windowHidden" to not be processed correctly for Windows. Therefore, the server process cannot be created with a window until fixed. Instead, send server debugging output to a file. The server now works great with VSCode for Antlr2, 3, 4, Bison, and W3C EBNF.

Related

VSCode extension testing: Use `vscode.executeDefinitionProvider` in test

Background
I'm trying to auto-test my VSCode extension. The extension works with python files and uses vscode.executeDefinitionProvider and vscode.executeDocumentSymbolProvider on them.
Problem
vscode.executeDefinitionProvider always returns [], vscode.executeDocumentSymbolProvider always returns undefined.
Notes
When running the same code in a debug session of the extension (no test session), the commands work flawless.
I ensured the extensions to be available during the test and even manually activated them with
let ext = vscode.extensions.getExtension("ms-python.python");
assert.notStrictEqual (ext, undefined);
await ext?.activate ();
ext = vscode.extensions.getExtension("ms-python.vscode-pylance");
assert.notStrictEqual (ext, undefined);
await ext?.activate ();
Question
How do I get the commands to succeed during automated test.
Edit: Workaround
Apparently VSCode takes its time to really activate the extensions. I could get it working placing a await sleep (10000); in index.ts::run () before return new Promise((c, e) => {.
While this is working, it's a really unstable workaround, Is there any way to make the code wait until the whole environment is fully loaded?
In the end nothing really stably worked for me, so I resorted to the following (perfectly fine working) solution.
My auto tests are run from the productive environment, like any other extension.
In package.json I created a new command _test.
the command would run ./test/suite/index.ts : run().
Extension<T>::activate(): Thenable<T>
Returns: Thenable<T> - A promise that will resolve when this extension has been activated.
await ext?.activate();

How to upload binary data (html + favicon) to ESP32 using ESP-IDF?

I am writing a file-serving http server for ESP32 using ESP-IDF and PlatformIO, but I just can't make data upload to SPIFFS work. I am trying to send html and favicon to flash, so it can be served on http.
Code of the server is taken from an example https://github.com/espressif/esp-idf/tree/master/examples/protocols/http_server/file_serving. Noticeable difference is that example project uses only ESP-IDF tools (without platformio) and that in an example data files are in the same directory as source files, where in my projects I have separated directories for /src and /data.
SPIFFS is configured using custom partition table.
I was following instructions from both PlatformIO documents (https://docs.platformio.org/en/latest/platforms/espressif32.html?utm_source=platformio&utm_medium=piohome) as well as from ESP (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html#embedding-binary-data).
I have custom partisions.csv file (identical to the example) + changed menuconfig to use it.
In platformio.ini I added:
board_build.partitions = partitions.csv
board_build.embed_txtfiles =
data/favicon.ico
data/upload_script.html
I also changed project CMakeLists file to embed data like this:
cmake_minimum_required(VERSION 3.16.0)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(HTTP-server)
target_add_binary_data(HTTP-server.elf "data/favicon.ico" TEXT)
target_add_binary_data(HTTP-server.elf "data/upload_script.html" TEXT)
/src/CMakeLists stayed unchanged:
FILE(GLOB_RECURSE app_sources ${CMAKE_SOURCE_DIR}/src/*.*)
idf_component_register(SRCS ${app_sources})
But even with all this configuration when I try to use this data in file_server.c like this:
extern const unsigned char favicon_ico_start[] asm("_binary_favicon_ico_start");
extern const unsigned char favicon_ico_end[] asm("_binary_favicon_ico_end");
extern const unsigned char upload_script_start[] asm("_binary_upload_script_html_start");
extern const unsigned char upload_script_end[] asm("_binary_upload_script_html_end");
I get compilation errors
Linking .pio/build/nodemcu-32s/firmware.elf
/home/artur/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/nodemcu-32s/src/file_server.o:(.literal.http_resp_dir_html+0x14): undefined reference to `_binary_upload_script_html_end'
/home/artur/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/nodemcu-32s/src/file_server.o:(.literal.http_resp_dir_html+0x18): undefined reference to `_binary_upload_script_html_start'
/home/artur/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/nodemcu-32s/src/file_server.o:(.literal.favicon_get_handler+0x0): undefined reference to `_binary_favicon_ico_end'
/home/artur/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/nodemcu-32s/src/file_server.o:(.literal.favicon_get_handler+0x4): undefined reference to `_binary_favicon_ico_start'
collect2: error: ld returned 1 exit status
*** [.pio/build/nodemcu-32s/firmware.elf] Error 1
================================================================================= [FAILED] Took 65.20 seconds =================================================================================
I tried changing extern definitions to:
extern const unsigned char favicon_ico_start[] asm("_binary_data_favicon_ico_start");
But it didn't change anything.
Additionally when running "Build Filesystem Image" task I get this error:
*** [.pio/build/nodemcu-32s/spiffs.bin] Implicit dependency `data/favicon' not found, needed by target `.pio/build/nodemcu-32s/spiffs.bin'.
================================================================================= [FAILED] Took 5.70 seconds =================================================================================
The terminal process "platformio 'run', '--target', 'buildfs', '--environment', 'nodemcu-32s'" terminated with exit code: 1.
Any help would be very much appreciated, as I feel that I did everything that the documentation stated.
I suspect you need to declare them as BINARY instead of TEXT. TEXT creates a null-terminated string which probably won't generate the _binary_..._end aliases.
target_add_binary_data(HTTP-server.elf "data/favicon.ico" BINARY)
target_add_binary_data(HTTP-server.elf "data/upload_script.html" BINARY)
Also something's off with your SPIFFS image generation. You know that the CMake macros target_add_binary_data() and idf_component_register(... EMBED_TXTFILES...) embed the stuff only into the application binary, right? You cannot use them add stuff to a pre-generated SPIFFS partition. For that you need to use spiffsgen-py script.
The problem was that I was a little bit confused with the difference between embedding files into an app and sending stuff to SPIFFS partition.
Solution was to move both .html and .ico files from /data to /src. I think the reason behind this is that this code: asm("_binary_favicon_ico_start") can't reference files in other directories, but I am not sure.
I also reversed project CMakeFile to default and added this line to /src/CMakeFile: idf_component_register(SRCS ${app_sources} EMBED_FILES "favicon.ico" "upload_script.html")
I also didn't need to create any filesystem images as SPIFFS partition was only needed for webserver itself.

WinDbg TTD: No trace files were identified from this record session

Trying to record execution of Hello World with WinDbg from store.
WinDbg settings:
Executable path: C:\Users\...\Documents\Visual Studio 2017\Projects\TestApplication\Debug\TestApplication.exe
Output directory: c:\Users\...\Documents\
Code:
#include "stdafx.h"
#include "iostream"
using namespace std;
int main()
{
std::cout << "Hello World!\n";
return 0;
}
Error:
TTD: No trace files were identified from this record session
The debugging session could not be started: Path cannot be null.
Parameter name: path
Why it's does not work? What I am missing?
Occasionally TTD recording has trouble creating TTD files to paths with spaces. Recommend entering or pointing Output Directory to save TTD files to a path with no spaces.

Where does dev_dbg writes log to?

In a device driver source in the Linux tree, I saw dev_dbg(...) and dev_err(...), where do I find the logged message?
One reference suggest to add #define DEBUG . The other reference involves dynamic debug and debugfs, and I got lost.
dev_dbg() expands to dynamic_dev_dbg(), dev_printk(), or no-op depending on the compilation flags.
#if defined(CONFIG_DYNAMIC_DEBUG)
#define dev_dbg(dev, format, ...) \
do { \
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
} while (0)
#elif defined(DEBUG)
#define dev_dbg(dev, format, arg...) \
dev_printk(KERN_DEBUG, dev, format, ##arg)
#else
#define dev_dbg(dev, format, arg...) \
({ \
if (0) \
dev_printk(KERN_DEBUG, dev, format, ##arg); \
})
#endif
dynamic_dev_dbg() and dev_printk() call dev_printk_emit() which calls vprintk_emit().
This very same function is called in a normal mode when you just do a printk(). Just note here, that the rest functions like dev_err() will end up in the same function.
Thus, obviously, the buffer is all the same, i.e. kernel intrenal buffer.
The logged message at the end is printed to
Current console if kernel loglevel value (can be changed via kernel command line or via procfs) is high enough for certain message, here KERN_DEBUG.
Internal buffer which can be read by running dmesg command.
Note, data in 2 is kept as long as there still room in the buffer. Since it's limited and circular, newer data preempts old one.
Additional information how to enable Dynamic Debug.
First of all, be sure you have CONFIG_DYNAMIC_DEBUG=y in the kernel configuration.
Assume we would like to enable all debug prints in the built-in module with name 8250. To achieve that we simple add to the kernel command line the following 8250.dyndbg=+p.
If the same driver is compiled as loadable module we may either add options 8250 dyndbg to the modprobe configuration or to the shell command line when do it manually, like modprobe 8250 dyndbg.
More details are described in the Dynamic Debug documentation.
The "How certain debug prints are automatically enabled in linux kernel?" raises the question why some debug prints are automatically enabled and how DEBUG affects that when CONFIG_DYNAMIC_DEBUG=y. The answer is lying in the dynamic_debug.h and since it's used during compilation the _DPRINTK_FLAGS_DEFAULT defines the certain message appearence.
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
#else
#define _DPRINTK_FLAGS_DEFAULT 0
#endif
you can find dev_err(...) in kernel messages. As the name implies, dev_err(...) messages are error messages, so they will definitely be printed if the execution comes to that point. dev_dbg(...) are debug messages which are more generously used in the kernel driver code and they are not printed by default. So everything you have read about dynamic_debugging comes into play with dev_dbg(...).
There are several pre-conditions to have dynamic debugging working, below 1. and 2. are general preconditions for dynamic debugging. 3. and later are for your particular driver/module/subsystem and can be .
Dynamic debugging support has to be in your kernel config CONFIG_DYNAMIC_DEBUG=y. You may check if it is the case zgrep DYNAMIC_DEBUG /proc/config.gz
debugfs has to be mounted. You can check with sudo mount | grep debugfs and if not existing, you can mount with sudo mount -t debugfs /sys/kernel/debug
refer to dynamic_debugging and enable the particular file/function/line you are interested

"Failed to open X display" when trying to run project from within Eclipse

I have a simple OpenGL/GLFW test program in Eclipse
#include <iostream>
#include <string>
#include <GL/glew.h>
#define GLFW_INCLUDE_GLU
#include <GLFW/glfw3.h>
void errorCallback(int error, const char *description)
{
std::cerr << description << " (GLFW error " << error << ")" << std::endl;
}
int main(int argc, char **argv)
{
int returnValue = 0;
try {
// Initialise GLFW.
glfwSetErrorCallback(errorCallback);
if(!glfwInit()) throw std::string("Could not initialise GLFW");
/* ...do everything else... */
} catch(std::string const &str) {
std::cerr << "Error: " << str << std::endl;
returnValue = 1;
}
return returnValue
}
However, running it causes the following to come up in the console:
X11: Failed to open X display (GLFW error 65542)
Error: Could not initialise GLFW
i.e. it fails during glfwInit() (I commented out all the code just to make sure it doesn't actually happen during window creation or something). However, navigating to the build directory (using my file manager, not Eclipse, that is) and manually launching from there works just fine.
Anyone know what the problem could be?
Sounds to me like Eclipse clears all or some of the environment variables when launching the program. The environment variable DISPLAY tell the program how to connect to the X11 server. Without that information it can't open the display, giving you that error.
Simple test to verify this: Add the following like right before glfwInit() (never mind that this is not C++ and doesn't use iostream, but that's okay for a quick test:
fprintf(stderr, "DISPLAY=%s\n", getenv("DISPLAY"));
You must include the headers stdio.h and stdlib.h.
Eclipse indeed wasn't passing any environment variables to my program (thanks datenwolf for getting me started). It's possible to select which environment variables to pass to the program by going to Run Configurations, selecting the appropriate launch configuration under "C/C++ Application" (I only had the default one), opening the Environment tab and then hitting the select button (it lists all available environment variables) and picking which ones you want.