I am wanting to run a CPU profiler on my C++ code via CLion. The profiler in CLion only used to be available for Linux (using perf) and macOS (using DTrace), but as of CLion 2021.2, the profiler is supposed to be available for WSL (also using perf) and I am using CLion 2022.2.4. CLion's docs have also been updated to reflect this change, listing WSL under the supported OSs, but there is no additional information for it, so I would assume the steps would be identical to those of Linux.
perf is only available for WSL on WSL 2, but I am using WSL 2 and have successfully installed perf. I have configured a CLion toolchain for this same WSL instance, and have successfully managed to use another WSL-only feature (Valgrind MemCheck) through it.
However, with Valgrind, all Valgrind-related IDE features (settings, run configurations, notifications...) were available to me before I even installed WSL, whereas the equivelant features for profiling don't seem to be available even after completely configuring WSL 2. How can I access the profiler for WSL?
By default, CLion has a plugin called Copyright enabled, but it appears I must have disabled it. There is a bug which causes profiler-related features to only show with this plugin enabled, and enabling it fixed the issue.
Related
How do I avoid installing same programming languages both in WSL and Windows10?
I am thinking about using WSL as a dev workspace. However, I realized I will need to install Node.js, Python, create-react-app, and so on in WSL even though my windows 10 already have them installed.
It would be helpful if you could spare me some advice.
Thanks.
To some degree, it depends on what type of development you are doing. Given your example languages/tools, I'm going to assume that most of your development is platform agnostic, web-development, etc.
My recommendation is to go all-in on WSL and install the Linux versions of the tools you use (with some notable exceptions covered below).
Uninstalling the Windows versions is recommended, but not strictly necessary. I recommend uninstalling because I continue to see a number of questions across the Stack sites where it becomes apparent that the Windows version of Node or Python is getting called from inside WSL. It's likely that some tool, such as nvm or equivalent, attempted to prepend the Windows Node or Python location to the Linux path.
This causes problems, as the Windows versions Node and Python understand Windows paths and processes. When you call them from the Linux shell in WSL, the shell/OS uses, of course, the Linux versions. And Windows Python just won't understand something like /mnt/c/Projects. It needs C:\Projects. You can work around this with utilities such as wslpath (automatically installed in some WSL distributions, installable in all others), or you could just manually adjust the path. But ... why go through the hassle if you don't need to.
Just use the Linux versions, with the corresponding Linux paths and instructions. Most development tools, tutorials, instructions, etc. are going to "default" to the Linux doc. It will typically be more complete, more up-to-date, etc.
And, of course, the Linux command-line experience is (subjectively, sure) far-and-above better than PowerShell. Don't get me wrong, I like PowerShell, but I like PowerShell even better when I call it through WSL (powershell.exe or pwsh.exe), since I can take advantage of Linux niceties like less (or bat), jq, and many others.
Not to say there aren't WSL caveats that you have to get used to. Be prepared to run into a few snags here and there (lack of Systemd support, permissions, filesystems, inotify), but most everything has a workaround that you'll typically find here on Stack (Stack Overflow, Ask Ubuntu, Unix & Linux, and/or Super User) if you search.
And for those "notable exceptions" I mentioned, I recommend installing:
Windows Terminal (available in the Microsoft Store), which will provide an upgraded terminal experience for WSL.
The Windows version of Visual Studio Code -- I've seen a question from someone here who tried to install the Linux version. It's just not necessary. Microsoft has done a great job of integrating the Windows version of VSCode with WSL. Just install the "Remote Development" extension pack, which includes the "Remote - WSL" extension.
Currently, I have two machines, one with Ubuntu in the company and one with Mac OS at home. Sometimes I would like to work at home while accessing the Ubuntu machine in the company. I can ssh into the Ubuntu machine and navigate and compile there. However, when I actually want to edit some cpp source codes, I realize that the editor (VS code) is actually opened in the Ubuntu machine, so I cannot view it from Mac. What should I do if want to edit files remotely on my Mac through VS code?
Though many of the answers mention using version control tools like git, it can be hard to use in my specific case. The problem is that the building environment of my company is Linux, so most of the building tools I have can only run on Linux. This means that I can only compile my source codes in Linux. If I use git, then every time I want to compile and debug my codes, I have to commit and push with my Mac, and then pull and test on Linux. This can be time consuming if want to incrementally modify, test and debug my codes.
Use some version control system like git. Then you might edit and compile at home (provided your code is portable between Linux & MacOSX, e.g. because it is POSIX compliant).
You could install some X11 server on your Mac and use ssh -X to access the remote Ubuntu machine (then run a GUI or editor remotely, e.g. ssh -X remotelinuxhost.company.com emacs). However, that requires good bandwidth and latency between your home computer and the remote one.
BTW, you might use some other source code editor, like emacs (it is capable of remote editing) or vim.
Since Linux and MacOSX are both POSIX systems, it is usually (but not always) easy to port source code from Linux to MacOSX and write source code compilable on both systems. BTW, many Linux frameworks (e.g. Qt, GTK, POCO, Boost, etc...) and build systems are usable and ported to MacOSX. Some Linux system calls (listed in syscalls(2)) are not available on MacOSX (e.g. signalfd(2)...)
Of course you could install Linux (perhaps inside some VM) on your Apple laptop.
I am getting following error while running /tmp/jprofiler8/bin/jpenable
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 1.7.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file
I have also set INSTALL4J_JAVA_HOME to point to suitable JVM.
Java version on my machine is 1.4.2.
Can anyone please suggest what might be wrong or missing?
Unfortunately you did not mention details about your environment, so I don't know which Linux distribution you use.
There are some options though:
install a current JRE alongside the installer for JProfiler
As you can't install or update Java, you could provide a JRE in a kind of "portable application" setup. Simply unzip the server jre Oracle provides or (if you are not on an x64 architecture) unzip the jdk you also can download from Oracle.
But if the code you want to profile is limited to your pre-installed Java 1.4 you will run into another problem, because as far as I know Java 1.5 is the minimum JProfiler expects
use a different machine for profiling
Unless your code depends heavily on the environment you run it in you can even take a Windows 8.1 machine and profile the code there. Code that is slow is slow on any operating system. Or make use of a different Linux computer.
I am trying to two-way sync my NAS (running Lubuntu) from my local network to a remote server (running Debian) with Unison CLI. I was using Unison before syncing my laptops files directly with the remote server. I always get an issue when trying to sync files from my NAS to my server:
Invalid argument: index out of bounds
Does anybody know why this happens? Is there a problem because Debian and Ubuntu are using not the exactly same version of Unison?
Edit: So in addition to making sure the Unison version numbers match and that the same version of OCaml was used to compile (as I said in my original answer below), there is one more thing necessary to get Unison working on your Banana Pi: compile it into bytecode, not native code. It turns out that (for whatever reason) Unison doesn't compile properly into native code for ARM processors like what the Banana (and my Raspberry) Pi have.
If you download a pre-compiled version of Unison it should work fine, but if you compile yourself, be sure to add the line Native=false to the Unison Makefile.
According to the unison manual:
It is important that the version of Unison installed on the server machine is the same as the version of Unison on the client machine.
This is because they change the format of the archive file in practically every update. You can check your version with unison -version. Update unison (or build/install it from source) to ensure your versions match, and then edit your post if you still have the same problem.
In some cases it also turns out to be important that unison is built using the same version of OCaml. I'm using Unison version 2.40.63 and I've had to build using OCaml 3.12.1 to avoid issues.
I'm developing C# using Mono and MonoDevelop in Windows and Ubuntu. I might code the same project in Windows today and tomorrow in Ubuntu (which is why I chose Mono and MonoDevelop).
In project properties I need to add some After Build commands to copy some projects compiled files into some alternate folders. And I've done this like so:
cp ${TargetFile} ${SolutionDir}/SomePorject/bin/${ProjectConfigName}/Plugins
While this command works perfectly in my Ubuntu machine, each time I'm using Windows my Build requests get canceled since this command can not be executed in Windows (there's no cp in Windows). It makes this a pain to switch between Ubuntu and Windows since each time I need to change these commands.
Now my question is, is there a copy command which works in Windows and Ubuntu alike? Or maybe MonoDevelop has come up with a copy command of its own which works according to the OS it is running under!
I think "configurations" is your way to go.
Create separate configurations for each platform (Right click on solution -> options -> configurations). After that, in "Custom commands" create two "After Build" commands, one for Windows, and other for Ubuntu.
When you build solution just choose your platform from your configurations.
You could install cygwin on your Windows box.