CLion 1.5 EAP: new build brings Python, attach to local process and more!

Hi,

It’s been a while since we published the previous CLion 1.5 EAP build. And we are happy to announce that a fresh build (144.3143) is now available for download. A patch update from the previous EAP build is also available.

This build includes a lot of goodies, so let’s start looking at them.

Attach to local process

This long-awaited feature allows you to attach to the process running on your local machine and debug it with CLion. It works with GDB on Linux/Windows and LLDB on OS X. To search a process to attach you can use either its name or pid:
attach_search_pid
More details are available in the dedicated blog post.

Python support

You’ve asked us about Python for so many times and finally here it is – Python support in CLion! We’ve bundled slightly changed PyCharm Community Edition plugin prepared by the PyCharm team and included the most essential features you may need for developing in Python in your CMake-based project. Read the blog post to find more details and watch a small teaser:

Clear CMake Cache

In Tools | CMake menu and CMake Cache tool window one can find a new option called Reset Cache and Reload Project:
cmake_reset
This could be helpful if you’d like to change some settings stored in CMake Cache and don’t want to drop the whole IDE indexes and caches. Calling it doesn’t require an IDE to restart.

YAML support improvements

Since version 1.1 CLion includes a bundled plugin for YAML, famous data serialization standard. In this EAP the plugin learned to handle spaces as tabs, started supporting multiline scalars as value of property key, as well as addressed several bugs and problems.

Fixed Java crash on OS X

In case you’ve experienced a crash in Java2D Queue Flusher thread on OS X, please, check this build carefully since it includes a fix for the problem. The fix is included into our customized version of the JRE bundled by default, thus please check you haven’t changed it (you can do so via Find Action dialog (Shift+Ctrl+A on Windows/Linux, ⇧⌘A on OS X): type Switch IDE boot JDK there, then select any prefered JDK installed in our system). Feedback is more than welcome in this ticket.

And more

Besides, there are more fixes prepared in the IntelliJ platform like:

  • support for RTL languages (Arabic, Hebrew) in the editor;
  • by-word difference highlighting that makes merging with Git and other VCS way more easier:
    by_word_diff
  • possibility to compare revisions of a file between branches for Mercurial (it was previously possible only within a single branch).

That’s about it, and the full release notes are available by the link if you’re after more details. Download the build and give it a try.

The CLion Team
JetBrains
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , , , . Bookmark the permalink.

24 Responses to CLion 1.5 EAP: new build brings Python, attach to local process and more!

  1. Yury V. Zaytsev says:

    Looking forward to trying this new EAP, just a short question regarding the “Mark directory as” functionality. The markings are stored somewhere deep in the ./.idea directory, is that right? If yes, is there also a way to add something to the CMakeLists.txt to make CLion interpret it as “Mark directory as” hints, like custom comment annotations (as in PyCharm) or so?

    The obvious use case is to share the marks with colleagues without committing ./.idea into the version control. On top of that, unless you chose to commit ./idea, the markings are going to be wiped out e.g. by git clean -dfx, which is, unfortunately, often needed for not so cleanly run projects :-)

    So… am I missing something? Is there already a ticket for that?

    • Anastasia Kazakova says:

      It’s stored in .idea/misc.xml since it’s CLion’s specific information. Find: sourceRoots, libraryRoots and excludeRoots tags there. You can actually store this file in the VCS to share with the team.
      We’ve decided not to implement CMake files markup for this, though had some concerns about it. The main argument against it – it may not be always possible with any build system (since in the future we are going to have more than CMake for sure), and requires IDE-specific info in the generic build system description.
      Feel free to share your ideas/suggestions here: https://youtrack.jetbrains.com/issue/CPP-4443 in comments.

  2. Roman says:

    gdb, gdb, gdb, when do you plan to start working on debugging performance? It’s very frustrating when you have to switch to VisualStudio or Eclipse to do some debugging :( Clion is still very slow and timeout errors are frequent.

    • Anastasia Kazakova says:

      With continuous work on debugger, we introduce many fixes. Currently we’ve found a big bunch of problems most likely causing timeout errors, fixes are in process, planned for one of the upcoming EAP builds.

      • Roman says:

        Some example code:
        int data[1000000];
        int main(int argc, char* argv[])
        {
        for (int i = 0; i < 100; i += 2) {
        data[i] = i; // set breakpoint here
        }
        return 0;
        }

        Stop on breakpoint, than try to step inside loop and check how values of data got updated in watch window. In Clion it is not possible for me to watch data values: I got timeout immediately.

        With smaller array you can see values in Clion, but stepping is slow.
        Check how it works in other IDEs: MSVS, Eclipse CDT, Netbeans.

  3. Yury V. Zaytsev says:

    So, I’m trying CLion on a new internal project, and everything is red again. Of course, in part it is due to unsupported variadic templates and extensive usage of Boost in general which means very complicated templated code, but then there are also numerous type inference errors, failed macro expansions, etc.

    Unfortunately, extracting reproducers for this problems would require an inhuman effort. It would be really awesome if there was a tool which would try to automatically extract a reproducer from a selected code, by duplicating the structure up to this level, but removing anything unused from the abstract syntax tree. Do you have anything like this, at least for internal usage? Otherwise, I really wonder how do you manage to narrow down parser errors, is it pure brain power plus debugging? External users can’t debug for obvious reasons, and guesswork is complicated by the lack of understanding of how the parser really works.

    • Anastasia Kazakova says:

      Variadic templates are still unsupported but in development currently. So should come really soon to the EAP build.

      We have our own automatic tests, regression tests, as well as manual testing. Unfortunately, we don’t have the tool you are describing and I’m not sure it could be implemented easily. Of course the smallest possible sample is the most useful, but we sometimes just dig in the long-long projects submitted by our users, since it’s really not obvious what caused the error, especially for C++.

      • Yury V. Zaytsev says:

        I see, thanks for clarification! Conceptually such tool shouldn’t be too difficult to implement, since you must certainly already have some internal AST representation, so it’s basically a lot of graph traversal work with some clever heuristics. Of course, it’s the details that will be hard to get right, and then comes the question of whether this investment would be still worthwhile. On the other hand, it would enable users to submit smaller reproducers for most elusive bugs, especially if they are not allowed to disclose the code.

        I’ve investigated some compiler bugs in the past using a similar approach (piping gcc -E preprocessed output through a reducer that does a fixpoint computation to end up with the smallest possible sample) and it has proven to be very useful to come up with minimal reproducers exhibiting the bug…

        Anyways, just though I’d mention it.

    • Anastasia Kazakova says:

      I would suggest you to try the build with variadic templates and compare the red code coverage. It would be useful for us to learn the results.

  4. Yury V. Zaytsev says:

    Another problem that the project that I’m looking at uses the following set of conventions:

    *.cc – non-inline non-template implementation (includes *.hh, *.ih, *.mpp)
    *.hh – public header
    *.ih – internal header
    *.mpp – external iteration include
    *.cci – inline non-template implementation (included at the end of *.hh)
    *.cti – inline template implementation (included at the end of *.hh, includes *.ih)
    *.ct – non-inline template implementation (included at the end of *.hh)

    Of course, this great structure confuses CLion completely, because it doesn’t understand that it should resolve *.cci / *.cti / *.ct / *.mpp in the context of *.hh . Is there any way to help it out with some CMake magic?

  5. Roman says:

    Do you know if Clion scales well on multicore CPUs? If I upgrade from 4 core cpu to 8 core, can I expect substantial performance improvement?

  6. Jeremy says:

    Thanks for your work on the product. For me, Clion performance and correctness should be a priority next if possible. The debugger is so slow, stepping through code is extremely painful (I get second to several second delays on a top of the line macbook pro). Reindexing code is very slow as well for a single line change to a single CMakeLists.txt file.

    Last, I’m glad things like variadic templates and such are being worked on. People who have the luxury of using a new tool like Clion are likely compiling with C++11/14. I noticed also that things like user-defined literals aren’t respected either. Finally, handling force include letters makes my files almost entirely red 😛

  7. Stanley says:

    brilliant blog post cheers for posting this.

Leave a Reply to Roman Cancel reply

Your email address will not be published. Required fields are marked *