Bug #1520: "options not a hash" error in Base class

Comments

1. Greg Hurrell 2010-03-27T04:19:37Z

   As I commented in my reply to you via email, you're probably not missing something obvious. It's likely some subtle difference between your version of Ruby and the one I'm using here (1.8.7), or perhaps something fishy with your LOAD_PATH.

   I'm going to see if I can figure out what the cause might be.

2. Greg Hurrell 2010-03-27T04:38:29Z

   Having trouble seeing how this error could be appearing. The code flow is basically:

   • in command-t.vim, we create a new controller object:

   $command_t = CommandT::Controller.new

   • in controller.rb, we set up a new CommandT::Base instance:

   @scanner = CommandT::Base.new nil,
     :max_files => ...,
     :max_depth => ... # etc

   • the initializer for CommandT::Base looks like this:

   def initialize path = Dir.pwd, options = {}
     @scanner = Scanner.scanner path, options
     @matcher = Matcher.new @scanner, options
   end

   So it is a very short and simple call chain and I don't see how options could be anything but a hash here. At least in my manual testing in irb running under Ruby 1.9.1-p378 I definitely get a hash when using that pattern.

   There is one other Base class in the hierarchy (CommandT::Scanner::Base) and at first I wondered that might somehow be getting involved when it shouldn't be, but I can't really see how that could be happening.

   I am about to do a refactoring which gets rid of that other Base class in any case, so I might get you to try the next release of the plug-in and see if there is any change.

3. KTamas 2010-03-27T07:09:08Z

   Thing is, I don't get it either... it works for me in IRB too...

   [ktamas@ainsley:~/.vim/ruby]$ irb
   irb(main):001:0> require 'command-t/ext'
   => true
   irb(main):002:0> require 'command-t/scanner'
   => true
   irb(main):003:0> include CommandT
   => Object
   irb(main):004:0> @scanner = Scanner.scanner(Dir.pwd, {})
   => #<CommandT::Scanner::Ruby:0x8b94b40 @path="/home/ktamas/.vim/ruby", @max_depth=15, @max_files=10000, @scan_dot_directories=false, @excludes=["*.o", "*.obj", ".git"]>
   irb(main):005:0> @matcher = Matcher.new(@scanner, {})
   => #<CommandT::Matcher:0x8b453c4 @scanner=#<CommandT::Scanner::Ruby:0x8b94b40 @path="/home/ktamas/.vim/ruby", @max_depth=15, @max_files=10000, @scan_dot_directories=false, @excludes=["*.o", "*.obj", ".git"]>, @always_show_dot_files=false, @never_show_dot_files=false>

4. Greg Hurrell 2010-03-27T08:40:16Z

   I'm going to release a new version shortly (0.4) in which I've refactored away some stuff to make the internals more simple.

   I'll get you to try that and if you're still seeing a problem we can investigate further.

5. Greg Hurrell 2010-03-27T11:00:45Z

   Ok, 0.4 is out now so if you can let me know if you're still having problems with that we'll get it sorted out.

6. KTamas 2010-03-27T11:19:18Z

   Same error with 0.4, same place (well, finder.rb:34, which is the same command). Very weird...

7. Greg Hurrell 2010-03-27T11:26:41Z

   Ok, well at least we've ruled out one possible cause (multiple Base classes at different points in the hierarchy). Right now I don't have any other suggestions but I'll think about it and add another comment when I come up with something.

8. KTamas 2010-03-27T11:38:58Z

   Okay, I've tried with the stock ruby of Fedora 12 (1.8.6) and it's working... so it's definitely ruby 1.9.1... somehow.

9. Greg Hurrell 2010-03-27T11:39:09Z

   Just realized that the "options not a hash" message actually comes from CommandT_option_from_hash function in ext.c.

   You could try commenting out the check there:

       if (TYPE(hash) != T_HASH)
           rb_raise(rb_eArgError, "options not a hash");

   And then run make again and see if you get a different message.

10. KTamas 2010-03-27T11:45:27Z

    Okay, so if I compile it with Ruby 1.8, it works with 1.9 too, so I think we can narrow it down to the C part somewhere...

11. KTamas 2010-03-27T11:47:24Z

    haha, just saw your message, I guess I guessed right :)

    I guess something changed in Ruby's C extension, indeed, then.

    By the way, the plugin is awesome, I love it.

12. Greg Hurrell 2010-03-27T14:42:44Z

    Had a look at the ruby.h header for 1.8.7 and T_HASH is defined as:

    [/tags/define #define] T_HASH   0x0b

    Compare that with Ruby 1.9.1 where it's defined like this:

    RUBY_T_HASH   = 0x08,
    ...
    [/tags/define #define] T_HASH   RUBY_T_HASH

    I wonder if when you're compiling the extension it is somehow picking up the wrong header file?

    In any case, I might be able to remove the check as the only "user" of the classes which perform the check is the Command-T controller itself (ie. it's not public API), so I can probably "trust" the input and let an exception be raised naturally if any third ever tries to pass in a non-hash options parameter.

13. Greg Hurrell 2010-03-28T05:18:33Z

    Ok, closing this one now. Will continue the discussion on the new ticket #1524.

14. Greg Hurrell 2010-03-28T05:18:38Z

    Status changed:

    • From: new
    • To: closed

Add a comment

Comments are now closed for this issue.