RubyMine 2019.2 Released: Faster Debugger, Ruby 2.7, Rails 6, and Much More

Artem Sarkisov

RubyMine 2019.2

RubyMine 2019.2 is now released!  Visit the What’s new page for a detailed overview of the new v2019.2, or check out the highlights below:

Debugger

  • The debugger is significantly faster
  • Investigate every method or block on a line with Smart Step Into
  • Set breakpoints at blocks
Comments below can no longer be edited.

16 Responses to RubyMine 2019.2 Released: Faster Debugger, Ruby 2.7, Rails 6, and Much More

  1. Ole Christian Rynning says:

    August 20, 2009

    This looks pretty awesome! Will you also consider including the Cucumber-support in IDEA please? Perhaps also take a look at Aslak’s cuke4duke-integration?

  2. yole says:

    August 20, 2009

    We’ve looked at cuke4duke, and considered implementing completion and navigation between .feature files and steps defined in Java. So far it’s not a high-priority feature for us, but if we do implement it, it will be part of the Ruby plugin for IntelliJ IDEA.

  3. jacob says:

    August 27, 2009

    Awesome! Is that formatter publicly available?

  4. yole says:

    August 27, 2009

    The formatter is available as part of the Rake Runner plugin in TeamCity 5.0 EAP builds.

  5. Matt Wynne says:

    August 25, 2010

    Thanks for sharing this guys, there’s nothing like the taste of dogfood eh?

    I’d love to hear more about how you wire your step definition code up to the IDE itself. Are you using a library like WindowLicker?

  6. Oleg Shpynov says:

    August 25, 2010

    Hello Matt,

    We don’t use any GUI testing tools for RubyMine testing, however we have lots of the functional tests which cover most of the business logic. They perform actions like refactorings, typing in editor and so on without GUI.

    Regards,
    Oleg

  7. Haroon says:

    November 24, 2010

    It will be really usefull if we can have cuke4duke integration with IntelliJ, is there any ETA to implement that feature?

  8. Dennis.Ushakov says:

    November 24, 2010

    @Haroon,
    I’ve filed a feature request http://youtrack.jetbrains.net/issue/RUBY-7247. Feel free to watch the progress and vote for it

  9. Eric says:

    July 30, 2019

    This is great! I really hope to see a less usage of RAM in the next version, 2019.1.3 is currently taking 1.5G, it’d be nice lowering that to 1G <3

    • Olga Kuvardina says:

      August 20, 2019

      Hello Eric! Have you tried it already? How does it go in terms of performance?

  10. Mikhail Varabyou says:

    August 16, 2019

    Nice update! Breaking the debugger, skipping all breakpoints and crashing it with segfault really made it faster.
    Tested on 2019.2.1 RC either – still not working. Horrible!

    • Olga Kuvardina says:

      August 20, 2019

      Could you please provide more details? Which Ruby version are you working with and where are breakpoints skipped? We had related issues but all of them have been fixed in 2019.2.1 RC so it’d be great if you could provide a reproduce scenario.

      • Mikhail Varabyou says:

        October 5, 2019

        Here is simplified example.

        RubyMine 2019.2.3
        Build #RM-192.6817.16, built on September 24, 2019

        # ruby 2.4.2, rails 5.0.7
        # ubuntu 18-04-3

        # app/controllers/some_controller.rb
        class SomeController < ApplicationController
        def index
        some_block do
        some_instance.some_method_call
        end
        end
        end

        # lib/some_instance.rb
        class SomeInstance
        include SomeModule
        end

        # lib/some_module.rb
        module SomeModule
        def some_method_call
        a = 1 # !!! i cant breakpoint there !!!!!!!!!!!!!
        end
        end

        Debugger ignores the breakpoint inside the #some_method_call.
        In the given example I can breakpoint at controller level and then step into to get to the #some_method_call. But more often when I step into I get segfault error:
        [BUG] Segmentation fault at 0x000000003c734da0
        ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux]

        All my colleagues suffer from the same issues and rollback to 2019.1.
        I can't remember update worse. Was the "improvement" so much valuable that overweight numerous bugs it introduced? Please rollback the debugger.

      • Mikhail Varabyou says:

        October 5, 2019

        Yes! Debugger is still not working. Neither 2019.2.1 stable nor past updates fixed it.

        • Olga Kuvardina says:

          October 7, 2019

          I’ve changed your code a bit (adding to the controller `test = SomeInstance.new.some_method_call`) instead and launched debug in the last 2019.3 EAP (Ruby 2.3.0 though), it stopped on the breakpoint in question. Could you please check the last EAP as well?

          • Mikhail Varabyou says:

            October 7, 2019

            That was a simplified example of how the code generally looks like. I was not going to provide any reproducible sample.
            I’m 99% sure its the problem of the legacy product we work with now. But it does not change the fact that debugger was working more or less correctly before 2019.2 and now it doesn’t.
            Tested that case in 2019.3 – it it working. I’ll keep you posted =)
            Thx

Subscribe

Subscribe for updates