![]() The integration works really well - allowing you to access the WSL directory structure from Windows File Explorer by navigating to Network->wsl$ - if you cannot see the wsl$ share then just type in wsl$ into the address bar and then selecting the required WSL installation (you will note below that I got carried away and installed four WSL versions): īefore discovering the WSL File Explorer integration. Initially, I was typing long winded command lines like:Ĭp /mnt/c/Refinitiv/RTSDK-2.0.2.L1.win.rrg/Cpp-C/Ema/Examples/Training/Consumer/100_Series/100_MP_Streaming/Consumer.cpp. Any coding/editing was still done on Windows and copying the files/changes back and forth between Windows to Linux as required. My first experiments around WSL simply involved copying across the Linux versions of our SDKs and trying to build and run them. You can imagine my hopefulness when I first started hearing the great promises Microsoft were making around their new Windows Subsystem for Linux. However, I personally did not find that Docker offered me the same flexibility and integration suited to my workflow. Some of you may ask 'What about Docker?'- we have published some Docker Container Images for our Real-Time SDKs (see links below) which I find useful for basic testing. However, there was always the issue of reduced performance and the headache of maintaining the VM, configuring the network settings etc and VMs that mysteriously stopped working. Things got a bit easier with virtualisation products such as VMWare and VirtualBox - allowing me to use a GUI interface with Linux and only resort to a Linux shell when I absolutely had to. It's not like I did not want to learn Linux - just the infrequent usage and lack of time meant I never made any reasonable progress. I had to rely on tools like WinSCP and PuTTY to transfer files and access our Linux test machines. If all worked OK on Windows, then I would migrate it to Linux or try and recreate the issue on Linux as required. When possible I always did my coding or tried recreating a customer issue on Windows. I seriously struggled - the joys of Vi, the considerable difference between cmd.exe and the various Linux shells etc. But for someone who had spent most of their working life with Windows and MS-DOS, this did not come easy. So, I had to adapt and start familiarising myself with Linux. When I joined Reuters back in 2004 I discovered that our real-time streaming APIs came in both Windows and Linux versions and most of our clients' real-time data applications were deployed on Linux - which makes sense - improved performance and stability compared to Windows (certainly back then). I may have interacted with a SQL Server or Oracle systems over the years, but these would have always been via a Windows-based interface/utility. I have been a Windows developer for most of my career - I started with MS-DOS-based development before quickly moving onto Windows development. followed by the detailed steps I carried out in order to be able to edit, compile and run C++ & Java examples inside the WSL environment.an overview of some key relevant WSL + VS Code features I discovered.Whilst I will be using some of the examples from our Real-time SDKs - the notes below should be applicable to general C++ and Java development. In this article, I will share my experience of using Windows Subsystem for Linux along with Visual Studio Code for some basic coding and testing in C++ & Java. This capability will be added in a future release.Knowledge Prerequisite – working knowledge of Windows, developer tools such as make, JVMs and a basic understanding of Linux console usage Introduction Otherwise, nvcc compilation and running compiled CUDA code works fine under WSL2 and under a CUDA Docker container running in WSL2.ĬUDA Toolkit Documentation mentions this: “CUDA debugging or profiling tools are not supported in WSL 2. VSCode connected to a CUDA Docker container running in WSL2.A cuda-gdb session inside a CUDA Docker container running in WSL2. ![]() The same CUDBG_ERROR_INVALID_DEVICEhappens to: ![]() (error code = CUDBG_ERROR_INVALID_DEVICE(0xb) Please consult the list of supported CUDA devices for more details. ![]() Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".įatal: One or more CUDA devices cannot be used for debugging. However, when I launch cuda-gdb in WSL2, it fails: cuda-gdb. WSL2 with Ubuntu 20.04 and Ubuntu 18.04.ĬUDA debugging works fine within Visual Studio Community 2019 and Visual Studio 2022 (local development under Windows).I am trying to set up debugging on a station with the following configuration: ![]()
0 Comments
Leave a Reply. |