by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    David Rodríguez
    @deivid-rodriguez
    Yes, it is.
    Takashi Kokubun
    @k0kubun
    :tada:
    David Rodríguez
    @deivid-rodriguez
    I'd like a test for this Control-D behavior, but I don't think it is necessary here, since the behavior has always been there.
    Takashi Kokubun
    @k0kubun
    I want a test for it too. Writing it is hard but I can add a unit test to ensure "continue" is returned when Readline.readline returns nil.
    Since continue's behavior is already tested, I think it'll be enough.
    David Rodríguez
    @deivid-rodriguez
    Don't worry about it, at least not in this PR.
    Takashi Kokubun
    @k0kubun
    Thanks!
    David Rodríguez
    @deivid-rodriguez
    Thanks to you!
    Takashi Kokubun
    @k0kubun
    I investigated why tests randomly crash and noticed that tracepoint's hooks are unexpectedly xfreed.
    I could manage to create the fix for it in ruby/ruby#1059, and I've never seen the SEGV with Ruby complied with the patch.
    David Rodríguez
    @deivid-rodriguez
    @os97673 I've tried to create a regression test for https://bugs.ruby-lang.org/issues/11492, but couldn't find a simple ruby code that reproduces the issue. Not really a big deal, but any ideas?
    Oleg Sukhodolsky
    @os97673
    @deivid-rodriguez the problem for debugger is that it incorrectly count stack size and stops in the wrong place, so the test should do something like
    stop at some point, do step over (I believe this is next in byebug's terms)
    and stops in wrong place
    the code should be something like
    class A
      define_method "method1" do
        return 1
      end
    
      def foo
        method1 # suspect we may stop here instead
      end
    end
    A.new.foo # breakpoint (stops here)
    puts '1' # after step over should should stop here
    Oleg Sukhodolsky
    @os97673
    I have not tried but hope it illustrates the idea
    David Rodríguez
    @deivid-rodriguez
    yes, that's what I've been trying but I haven't found a failing test case. I know it involves define_method but it's definitely not that simple. Your example passes against all supported versions in byebug.
    Oleg Sukhodolsky
    @os97673
    Perhaps you need add more code in foo after method1 call, to have line event to stop at.
    If this doesn't work could you please create a branch with the test and I will play with it.
    David Rodríguez
    @deivid-rodriguez
    @os97673 Your suggestion worked! Thanks!
    But now there's one concern. I thought it was a regression in 2.2.3 that didn't affect 2.1, but it fails in 2.1 too. In that case, we would need to ask for a backport. Can you confirm?
    David Rodríguez
    @deivid-rodriguez
    Oleg Sukhodolsky
    @os97673
    I have never tested it with 2.1 because user has not complained about it :)
    And, unfortunately, I don't have test for this :(
    David Rodríguez
    @deivid-rodriguez
    I just requested backporting the fix to 2.1
    Oleg Sukhodolsky
    @os97673
    Great
    Ryan Buckley
    @ridiculous
    Hi everyone. Quick question: how do you escape byebug methods that clash with local vars? For instance condition. I was able to work around it with var local but that could get out of hand with a lot of locals
    David Rodríguez
    @deivid-rodriguez
    Oops, I think I need to get some kind of notifications enabled for this channel... Sorry.
    Yes, var local would be a way. Another way would be puts condition, eval condition, or something like that
    Ryan Buckley
    @ridiculous
    ok, thanks @deivid-rodriguez :) Using puts is a good workaround :+1:
    Lucas Kanashiro
    @lucaskanashiro
    Hi o/ are the maintainers planning to release a new version with ruby2.7 fixes any time soon?
    David Rodríguez
    @deivid-rodriguez
    Yes
    Lucas Kanashiro
    @lucaskanashiro
    great, thanks for the info @deivid-rodriguez , do you have an estimation for that to happen?
    David Rodríguez
    @deivid-rodriguez
    Next week
    Lucas Kanashiro
    @lucaskanashiro
    @deivid-rodriguez Great, glad for the work you've been doing
    David Rodríguez
    @deivid-rodriguez
    Thanks for the kind words, @lucaskanashiro. I released byebug 11.1.0 with official MRI 2.7 support.
    Jorge Barreto
    @jorge-barreto

    Hello @deivid-rodriguez: I believe I found a bug in the latest release. However it is so basic that it leads me to believe it is actually a configuration error on my end. However, I can reproduce the error on fresh installs of latest version 11.1.0, and it is not present for 11.0.1.

    So: there is a broken path in inside of core.rb (line 4: require_relative 'byebug') which errors out when trying to load the file. That makes sense since the byebug folder inside of lib does not contain a byebug.rb file. The file it is looking for is apparently in the parent directory, however changing the line to require_relative '../byebug' does not help. Just a little later while loading Byebug's post-mortem settings, I get a seemingly unrelated error: undefined methodpost_mortem=' for Byebug:Module`

    also thank you for making amazing software :)
    David Rodríguez
    @deivid-rodriguez

    Hi @jorge-barreto! Thanks so much for reporting this early. Could you post steps for me to reproduce the problem? How are you installing byebug? Which OS? Which ruby version? That require_relative should actually load a .so file (or whichever extension shared libraries have in your OS) located in the same directory. I suspect your installation is not putting the compiled extension in the same folder but in some place only accesible throught the $LOAD_PATH.

    So, I will revert that specific change and use require again there and release 11.1.1, but if you can help me figure out how this happened and how to prevent it in the future, that'd be awesome.

    David Rodríguez
    @deivid-rodriguez
    Ok, I figured it out. I think your installation of rubygems might be tweak to not install extensions in the gem's lib directory. Fedora does this, for example: https://src.fedoraproject.org/rpms/rubygems/blob/master/f/operating_system.rb#_136-144. I'll release a bugfix release as soon as possible, hopefully tomorrow! Thanks, and sorry :/
    Jorge Barreto
    @jorge-barreto
    No need to apologize! I'm glad to help in any way I can. I can post a formal issue on github's tracker if you prefer. Your hunch was correct, I am running Fedora 30.
    Jorge Barreto
    @jorge-barreto
    So, just poking around a little: if I modify those lines you linked in my operating_system.rb to return true, and then install a fresh byebug 11.1.0 (through gem install byebug), then everything works as intended
    Jorge Barreto
    @jorge-barreto
    BTW: changing all of the calls from require_relative to require byebug/... and compiling the gem from that works on my system. the byebug.so file is created in my ~/.gem/ruby/extensions/... directory, and that's where require fetches it from.
    The fact that in my RubyGems install_extension_in_lib returns false (as per your link) prevents the .so file from being copied to byebug's lib folder, which is what causes the bug in the first place.
    David Rodríguez
    @deivid-rodriguez
    Yup, that's it
    Working on a bug fix release now
    David Rodríguez
    @deivid-rodriguez
    Jorge Barreto
    @jorge-barreto
    Thanks! Just compiled w/ the new code and it all works as it should
    David Rodríguez
    @deivid-rodriguez
    Thanks for trying it! :heart: