[support]

Hi,

Please use the following option to disable it: Tools->Options->Text Editor->C/C++ (VisualGDB) -> Advanced -> Typing Assist -> Auto-match brackets (you may need to reopen the source file for the changes to take effect).

[support]

Hi,

OK, the official VisualKernel 3.0 Beta 1 is ready: https://sysprogs.com/files/VisualKernel/VisualKernel-3.0-beta1.msi

It has passed all our internal tests and includes many new features. We will do an official announcement with the detailed list of new features on Monday.

[support]

Hi,

The LXSS root directory is currently cached until you restart Visual Studio, so if you changed the default key after starting VS, it could get an invalid value.

With VisualGDB menus, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2037.msi

We will try to provide better support for multiple LXSS installations in v5.4, but we can still help you resolve the issues you encounter currently. If you can still confirm inconsistent behavior with WSL paths, we can send you another diagnostic build with further logging that will help pinpoint this.

[support]

Hi,

Thanks for the dump file. This actually looks like a known Clang bug that we have not been able to pinpoint yet. Clang crashes while trying to parse a comment after an #ifdef directive. If you could locate the place in the code responsible for this and send us a repro, we should be able to fix it.

Another option (if you could get this to crash consistently) would be to try a debug build of the engine (https://sysprogs.com/files/tmp/CppEngineCore64.7z) and send us a full dump (if you get an ‘assertion failed’ message, please attach VS, click ‘retry’ and create a dump file). This should help us pinpoint and fix this.

[support]

Hi,

Strange. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.18.2024.msi

It will show the command line it is trying to run as a part of the exception message. Please try running the same command line manually and see if it shows any meaningful errors.

[support]

Hi,

If you are using a Custom edition of VisualGDB, you can change the SDK location via the first page of VisualGDB Project Properties. You can also conveniently share this setting with your colleagues using the Team Settings feature.

If you are using a lower edition, the only way to change the paths would be by manually editing the .vcxproj file.

You can always upgrade your edition here: https://sysprogs.com/splm/mykey

[support]

Hi,

Thanks for pointing this out – we have switched the bootloader file definition and fixed the ESPImageTool binary. Please download the r13 toolchain here: http://gnutoolchains.com/esp8266/

Regarding the OTA scripts, our toolchain is based on the original ESP8266 SDK. If you believe it is missing files for some of the OTA modes, please double-check this with Espressif, they might be able to provide you with the correct linker script.

[support]

Hi,

The easiest way to resolve this would be to manually add a statement filtering out the excluded files to Makefile (using the $(filter–out …) syntax).

Another option would be to patch the VisualGDB MSBuild platform files to run your compiler instead of the gcc. If the Intel compiler command line is compatible with the gcc command line, we can add an option to override the gcc executable via Project Properties. If not, you would need to create a file similar to gcc.xml (in VisualGDB directory) describing the command-line options for the Intel compiler. Let us know if you would like to try this out and we will provide you with a build that allows overriding the compiler name.

[support]

Hi,

Sorry, getting a toolchain right is often tricky, that’s why we provide it as a paid service. The good news is that 64-bit ARM boards are becoming more mainstream (Raspberry Pi 3 is actually 64-bit, although the Raspbian distro is 32-bit), so we may eventually add a free 64-bit cross-toolchain if one of the boards becomes really popular.

[support]

Hi,

This likely happens because those extensions are specifically looking for the regular Visual C++ project backend. If you are using Clang IntelliSense, it completely replaces the regular C++ IntelliSense, so extensions that are not aware of the Clang IntelliSense won’t find it.

You could disable Clang IntelliSense via VisualGDB Project Properties (or via a switch on the Clang IntelliSense Diagnostics Console window), however this would reduce the quality of the code completion results, as the Clang IntelliSense is specifically designed to work the best with GCC-specific code.

[support]

Hi,

Thanks for the dump file. It looks like it might be related to a recently solved problem. Could you please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.18.2019.msi

If the problem persists, please attach an updated dump file so that we could investigate it.

[support]

Hi,

This looks like a missing (or incorrectly configured) test framework directory. Normally, VisualGDB would reference the test framework files as shown below:

LOCAL_SRC_FILES := $(TESTFW_BASE)/com.sysprogs.unittest.googletest/src/gtest-death-test.cc <...>

Then it would pass the TESTFW_BASE variable via environment. Could you please check whether the LOCAL_SRC_FILES statement uses this syntax? If yes, does setting TESTFW_BASE to $(LOCALAPPDATA)\VisualGDB\TestFrameworks solve the problem?

[support]

Hi,

The normal ARM cross-toolchain only works for barebone devices (i.e. without Linux). If you would like to target Linux, you would need a special toolchain that is built to match your Linux distro and configuration. Please check your device vendor’s site whether they provide such a toolchain. If not, we could build one for you as a part of our custom toolchain building service. Please contact our sales if you would like to get a quote.

[support]

Hi,

VisualGDB would normally use the HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss\DefaultDistribution registry key to locate the LXSS distro to use. Could you please check that the value points to a valid LXSS installation on your machine? If you are not sure, please feel free to attach a screenshot of that registry key contents (or a .reg file).

As another quick workaround please try creating another regular SSH connection and simply specify localhost:<port number> in the “Host name” field, so that VisualGDB will use SSH.

[support]

Hi,

Normally this should not be a problem, however if your code depends on some specific constraints of the ARM GNU Toolchain, simply using it instead of the toolchain installed by VisualGDB should be the easiest solution.

[Author]

Posts