Forum Replies Created
-
Posts
-
Although it is used in many production environments, it is still not as popular as the mainstream languages. Either way, feel free to give it a try with the Quick Debug feature and if you find some annoyances along that path, we should be able to fix them for you.
Hi,
Our latest Beaglebone toolchain is Debian-compatible, so you should have no problems using it for your device.
Regarding the complexity, answer depends on what are you trying to accomplish. The development tool experience (building, debugging, configuring) with VisualGDB is very similar to classical Visual Studio. The APIs, however, are completely different: if you are used to certain Windows APIs, they won’t work on the Beaglebone even with VisualGDB, i.e. you will still need to learn and use the Linux API. However, there are numerous tutorials on those and you can also ask here if you have further questions.Wait a bit more on that. Once the beta is out, I will release a self-contained source package that won’t require any further adjustments.
Hey guys, if I promise something, I don’t forget it 🙂
The new WinCDEmu beta is out. Check out the highlights here: http://wincdemu.sysprogs.org/news/4.0/
I’ve added what everything that was asked except 2 things:
* Registry cleanup for portable driver uninstallation. Simply could not reproduce it. If you can share exact repro steps, I’ll look into it more.
* Localization for the portable version. The current localization engine stores translations in separate files, but the portable version has to be 1 stand-alone file. If someone is willing to modify the sources to support localization via resources, I can show how to do this.If you have other requests or feedback on the beta, feel free to post them here.
OK guys, the Beta 1 is out so I need your feedback on it. Once we ensure it’s stable, I will release a complete source package that will include BazisLib so you won’t need to mess with installing and configuring it.
Hi,
Most likely your LD_LIBRARY_PATH is modified from .bashrc that is not processed when running commands like GDB over SSH directly (opposed to typing the command name manually in the shell). VisualGDB 4.3 Beta 2 actually detects this condition and configures a workaround automatically. Please try updating to it.
That depends on the bug. If your bug caused an exception during program initialization (before main() got a chance to run), the breakpoints would not be triggered.
OK, your prayers have been heard. I’ll try to get as much feedback from the community as I can and make a new release.
Regarding vmnt, have you installed BazisLib 3.0? It is needed by the latest WinCDEmu.Hi,
From the GDB perspective, the breakpoints are set correctly, but the tool simply exits. Are you missing custom LD_LIBRARY_PATH? Does the tool run normally when you launch it manually? Do you experience the same issues with a basic “Hello, World” tool?
Hi,
Thanks for the log. The problem might actually be caused by VisualGDB. We have recently modified our workaround that handles VSPackage registration and it may be causing your problem. Please try this build:
http://visualgdb.com/tmp/VisualGDB-4.3.1.184.msi
Then create a registry value: HKLMSOFTWAREWow6432NodeSysprogsVisualGDBSettingsPackageSiteWorkaroundMode and set it to 2. If that does not help, set it to 0. Let us know if that solves the problem.Hi,
Do you get any IntelliSense errors in the Errors pane? IntelliSense currently uses a completely different mechanism than the compiler uses, so it is known miss some GCC-specific declarations occasionally. We are currently working on a separate IntelliSense engine that will understand GCC-specific code much better.
Hi,
You appear to be using a very old version of tar that has a known bug. Please update to a newer version or configure VisualGDB to ignore file transfer errors on the Project Settings page in VisualGDB Project Properties.
It also looks like you are doing either a clean or a rebuild on a project that does not define the clean rules. Please either use the ‘Build All’ command or add a clean rule to your Makefile.Hi,
The easiest way would be first import the actual app (it should have the jni folder defining which libraries to import), then import the library project:
1. Copy the AndroidManifest.xml file to the root directory of your library (the one that contains the jni subdirectory). It will be deleted later.
2. Import the library as if it was an app.
3. Delete the AndroidManifest.xml file.
4. In the VisualGDB Project Properties set the “This is a library-only project” checkbox on the Build Settings page.Note that we have added support for Gradle projects to VisualGDB 4.3.
