JRuby

jirb tab completion not working in Windows

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.7.0
  • Fix Version/s: JRuby 1.7.5
  • Component/s: None
  • Labels:
    None
  • Environment:
    Win7 x64, 32-bit and 64-bit Java 7
  • Number of attachments :
    0

Description

Been trying to figure this one out all day...

Tab completion works fine in 1.6.8 on Windows, but when I install 1.7.0 it doesn't. When I hit the tab key it appears to actually be inserting a tab, which is not the case under jirb for 1.6.8.

The problem is in evidence on two different machines now, both Win7 x64. It happens in cmd, powershell, and ConEmu, and doesn't seem to make a difference what gems I load. I've tried both under x86 and x64 Java with same results in both.

jirb tab completion is working under linux, as expected.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Hiro Asari added a comment -

Just for the sake of completeness, could you confirm that you have irb/completion loaded on all machines?

Show
Hiro Asari added a comment - Just for the sake of completeness, could you confirm that you have irb/completion loaded on all machines?
Hide
Permalink
Nathan Walker added a comment -

Yes. It looks like it's loaded by default in JRuby 1.7.0 (based on behavior in linux), but there's no difference even when I do an explicit require on it. The irb/completion.rb file is present and when I do the require it returns true, FYI.

Show
Nathan Walker added a comment - Yes. It looks like it's loaded by default in JRuby 1.7.0 (based on behavior in linux), but there's no difference even when I do an explicit require on it. The irb/completion.rb file is present and when I do the require it returns true, FYI.
Hide
Permalink
Nathan Walker added a comment -

Tab completion also does not work in 1.7.0 in Ruby 1.8 mode, FYI

Show
Nathan Walker added a comment - Tab completion also does not work in 1.7.0 in Ruby 1.8 mode, FYI
Hide
Permalink
Thomas E Enebo added a comment -

I have this tracked down a bit. in Ruby.java we actually specify 'none' for JLineTerminal type. This basically turns this off. There is a comment above it about a problem loading Jansi with our Classloader setup. Trying to understand why we disabled this a bit better.

Show
Thomas E Enebo added a comment - I have this tracked down a bit. in Ruby.java we actually specify 'none' for JLineTerminal type. This basically turns this off. There is a comment above it about a problem loading Jansi with our Classloader setup. Trying to understand why we disabled this a bit better.
Hide
Permalink
Thomas E Enebo added a comment -

We should have fixed this for 1.7.1, but there is some weirdness here with classloaders which might make fixing this require changes to jline2 itself. So targeting the next point release.

Show
Thomas E Enebo added a comment - We should have fixed this for 1.7.1, but there is some weirdness here with classloaders which might make fixing this require changes to jline2 itself. So targeting the next point release.
Hide
Permalink
Christian MICHON added a comment -

Unfortunately not fixed for jruby-1.7.2 on Windows.

Possible workaround:
jruby -S jirb_swing

Show
Christian MICHON added a comment - Unfortunately not fixed for jruby-1.7.2 on Windows. Possible workaround: jruby -S jirb_swing
Hide
Permalink
Charles Oliver Nutter added a comment -

I vaguely remember the issue that caused us to set jline.terminal to "none". I believe it was due to some classloader sequence in jansi blowing up because JRuby normally boots from the boot classpath. Will try to reproduce today and come up with a better solution.

Show
Charles Oliver Nutter added a comment - I vaguely remember the issue that caused us to set jline.terminal to "none". I believe it was due to some classloader sequence in jansi blowing up because JRuby normally boots from the boot classpath. Will try to reproduce today and come up with a better solution.
Hide
Permalink
Charles Oliver Nutter added a comment -

So here's the exception it blurps out in Windows:

C:\jruby>bin\jirb
[ERROR] Terminal initialization failed; falling back to unsupported
java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32
        at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50)
        at jline.WindowsTerminal.getConsoleMode(WindowsTerminal.java:177)
        at jline.WindowsTerminal.init(WindowsTerminal.java:80)
        at jline.TerminalFactory.create(TerminalFactory.java:101)
        at jline.TerminalFactory.get(TerminalFactory.java:159)
        at jline.console.ConsoleReader.<init>(ConsoleReader.java:227)
        at jline.console.ConsoleReader.<init>(ConsoleReader.java:219)
        at jline.console.ConsoleReader.<init>(ConsoleReader.java:207)
        at org.jruby.ext.readline.Readline.initReadline(Readline.java:105)
        at org.jruby.ext.readline.Readline.getHolderWithReadline(Readline.java:143)
        at org.jruby.ext.readline.Readline.s_readline(Readline.java:169)

Again, classloader issues in jansi. If I run it in such a way as to not load JRuby into boot classpath, it works:

C:\jruby>set VERIFY_JRUBY=1

C:\jruby>bin\jirb
irb(main):001:0> a = "foo"
=> "foo"
irb(main):002:0> require 'irb/completion'
=> true
irb(main):003:0> a.su
a.sub     a.sub!    a.succ    a.succ!   a.sum

So we have a conundrum. jansi needs to be fixed to work when loaded from boot classpath, which then needs to propagate into jline, which then needs to be propagated into jruby. The alternative would be removing them from jruby.jar and only loading them as .jars in their own classloaders, similar to how we load jruby-openssl bits right now. I'm going to explore the latter, since it would also move us toward being able to ship our readline subsystem as an updatable gem.

Show
Charles Oliver Nutter added a comment - So here's the exception it blurps out in Windows: C:\jruby>bin\jirb [ERROR] Terminal initialization failed; falling back to unsupported java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32 at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50) at jline.WindowsTerminal.getConsoleMode(WindowsTerminal.java:177) at jline.WindowsTerminal.init(WindowsTerminal.java:80) at jline.TerminalFactory.create(TerminalFactory.java:101) at jline.TerminalFactory.get(TerminalFactory.java:159) at jline.console.ConsoleReader.<init>(ConsoleReader.java:227) at jline.console.ConsoleReader.<init>(ConsoleReader.java:219) at jline.console.ConsoleReader.<init>(ConsoleReader.java:207) at org.jruby.ext.readline.Readline.initReadline(Readline.java:105) at org.jruby.ext.readline.Readline.getHolderWithReadline(Readline.java:143) at org.jruby.ext.readline.Readline.s_readline(Readline.java:169) Again, classloader issues in jansi. If I run it in such a way as to not load JRuby into boot classpath, it works: C:\jruby>set VERIFY_JRUBY=1 C:\jruby>bin\jirb irb(main):001:0> a = "foo" => "foo" irb(main):002:0> require 'irb/completion' => true irb(main):003:0> a.su a.sub a.sub! a.succ a.succ! a.sum So we have a conundrum. jansi needs to be fixed to work when loaded from boot classpath, which then needs to propagate into jline, which then needs to be propagated into jruby. The alternative would be removing them from jruby.jar and only loading them as .jars in their own classloaders, similar to how we load jruby-openssl bits right now. I'm going to explore the latter, since it would also move us toward being able to ship our readline subsystem as an updatable gem.
Hide
Permalink
Charles Oliver Nutter added a comment - 
commit fb264a04ccecb13d5f9e25de210d954ad7711d99
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Tue May 21 10:08:46 2013 -0500

    Move readline out of jruby.jar.
    
    There are a number of reasons for this:
    
    * Allows us to version it separately (potentially even moving it
      out of JRuby repo altogether.
    * Resolves issues where our bundling or our boot classloading
      interferes with parts of jline or jansi. I have removed the
      hack we had in place that prevented jansi from erroring while
      breaking several readline features (like tab completion,
      JRUBY-6996) on Windows.
    * Reduces jruby.jar size for cases where you don't need readline.
    
    This also follows our (and MRI's) pattern of moving ext libraries
    out of core into gems.

:100644 100644 2d37778... aa1496e... M	.gitignore
:100644 100644 061a7aa... bbe2e5e... M	build.xml
:000000 100644 0000000... dd3fa3a... A	lib/ruby/shared/readline.rb
:000000 100644 0000000... e69de29... A	lib/ruby/shared/readline/.keep
:100644 100644 73beefd... 92b57cb... M	src/org/jruby/Ruby.java
Show
Charles Oliver Nutter added a comment - commit fb264a04ccecb13d5f9e25de210d954ad7711d99 Author: Charles Oliver Nutter <headius@headius.com> Date: Tue May 21 10:08:46 2013 -0500 Move readline out of jruby.jar. There are a number of reasons for this: * Allows us to version it separately (potentially even moving it out of JRuby repo altogether. * Resolves issues where our bundling or our boot classloading interferes with parts of jline or jansi. I have removed the hack we had in place that prevented jansi from erroring while breaking several readline features (like tab completion, JRUBY-6996) on Windows. * Reduces jruby.jar size for cases where you don't need readline. This also follows our (and MRI's) pattern of moving ext libraries out of core into gems. :100644 100644 2d37778... aa1496e... M .gitignore :100644 100644 061a7aa... bbe2e5e... M build.xml :000000 100644 0000000... dd3fa3a... A lib/ruby/shared/readline.rb :000000 100644 0000000... e69de29... A lib/ruby/shared/readline/.keep :100644 100644 73beefd... 92b57cb... M src/org/jruby/Ruby.java

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Nathan Walker
Vote (1)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved: