Closed peci1 closed 1 year ago
The same happens in Pycharm Pro 2023.1.
And another exception:
I replicated the error.
The error is unsurprisingly caused because the library is being disposed, then the disposed library is used again, which causes errors like a NPE would, hence why nothing is working. The surprising thing is that the very creation of the library caused its disposal as it triggered a module root update event.
The code no longer stores libraries as they are constantly disposed, and the fix was tested on CLion 2023.1 I want to test it on PyCharm and IntelliJ before committing it though.
Hi @peci1,
I believe the major bug was dealt with by the above commit. Does it fix the issues you encountered?
Thanks it helped somewhat. Now it sometimes work. But sometimes it does not, usually without any error message.
I've noticed 3 "modes" of (non)-working:
These three modes seem to randomly happen even in the same project. I haven't noticed any pattern in it. I tried launching CLion with just a single project loaded (I usually have more), I tried invalidating caches, nothing works in the sense of getting the plugin predictably to any of the three modes.
In mode 2, when I hover or Ctrl+Click a message definition in a message file, I get an NPE:
Right now, I have a running CLion with 3 projects opened, each in a different mode:
Mode 1:
Mode 2:
Mode 3:
Playing with Additional package path seems to semi-randomly switch between the modes. Sometimes even Reload CMake project does. However, there is no pattern in it - even two projects from the same metapackage (and workspace): one has mode 1 when I clear the additional packages path, while the other has mode 1 when I fill the source path to the underlying workspace.
When opening a project that was never opened with this plugin, I also get assertion error:
And I got this once (but only once):
I think I can help you with the pattern behind this flavor of issues.
Since packages are completely independent from the workspace scope (the workspace doesn't have to be the project in its entirety, and obviously the core ROS files are outside the workspace), the plugin needs to create different libraries which are in turn used to run searches and indexing.
When the "workspace" library (.idea/libraries/workspace.xml
) fails (for example the previous error), the plugin is not applied on the project at all, hence "mode 3"
When the "ROS" library (.idea/libraries/ROS.xml
) fails, all the ROS defined packages cannot be looked for and are treated as if they don't exist, hence "mode 2" (assuming the workspace is loaded properly)
Adding additional package paths extends the workspace library, so that would explain why it works. From my experience the rest of the code works fine, but the library indexing has many issues. The bugs you raise (and raised in the past) help me find those issues which is something I appreciate.
Message files are one of the few features that do not rely on packages at all, so that explains why they are the only things that work when the libraries don't work
In mode 2, when I hover or Ctrl+Click a message definition in a message file, I get an NPE:
Was the message you clicked on a "ROS" message or from your workspace? If it was a ROS default message, that would explain why it would crash.
Was the message you clicked on a "ROS" message or from your workspace? If it was a ROS default message, that would explain why it would crash.
The message I tried had both standard library types (Header) and custom types. Header was not red and caused the NPE. The custom messages were red (missing), and did not cause the NPE. I hope this helps...
The first header in message files, just like in ROS, receives special treatment. The same applies in the plugin, and the plugin will not annotate the first header and will redirect to std_msgs/Header automatically, even if it does not exist (It should always succeed though as it is a standard ROS message)
When the "ROS" library (
.idea/libraries/ROS.xml
) fails
Hmm, but I don't see any errors logged...
There are multiple ways the library can decide to not load, even without errors. For example, in the video you sent in this thread it fails without error: it loads (you can see it in the bottom of the external libraries tab) then immediately disappear, probably because it is being incorrectly disposed. I do not know why this happens, but I hope that once I manage to consistently replicate a scenario where this happens I will resolve it
Since the principle bug reported here was fixed and CLion doesn't crash all the time, I think I will close this particular issue My guess is that the other crashes and the "broken" states of the plugin are caused by the plugin attempting to load the libraries before it is aware of the files. For example, the "write access" exception when the plugin is opned on a new project is caused by the icon provider trying to determine whether a folder is a package or not because it is aware of the contents of the folder.
It seems there may be more sources of this sort of issue, and I want to tackle them all together. If you want to, you can write that stack-trace in issue #84 where I will tackle this issue as a whole
Describe the bug I decided to give the plugin another go seeing the current development efforts. But it does nothing.
To Reproduce Steps to reproduce the behavior:
Environment Information:
Stack Trace
This is a huge one:
I can also trigger an NPE by Ctrl+Clicking a message type definition in a .msg file:
And another one when ctrl+clicking a message field name in a .msg file:
Screenshots I can see the "ROS" item appear shortly in External libraries on startup, but then it disappears and never appears again.
https://user-images.githubusercontent.com/182533/231294264-3c9af764-53a5-477a-804f-50e502f7f8e0.mp4
Another issue - when I right-click a .msg file and choose "Override file type", I get 3 options named "ROSPkt (from 'ROS Support' plugin)". This is not very helpful.