Ruby's inconsistency or an IRB issue ?

Discussion in 'Ruby' started by David Unric, Nov 17, 2010.

  1. David Unric

    David Unric Guest

    Hi,

    I've discovered some strange behaviour in Interactive Ruby shell (IRB) I
    cann't explain myself. It manifests only with Wirble enhacement with
    colorization enabled.

    >> Class.methods.uniq.sort

    => [:!, :!, :!, :, :, :=>, :, :, :, :, :, :__id__, :__send__, :allocate,
    :ancestors, :autoload, :autoload?, :class, :class_eval, :class_exec,
    :class_variable_defined?, :class_variable_get, :class_variable_set,
    :class_variables, :clone, :const_defined?, :const_get, :const_missing,
    :const_set, :constants, :define_singleton_method, :display, :dup,
    :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include?,
    :included_modules, :initialize_clone, :initialize_dup, :inspect,
    :instance_eval, :instance_exec, :instance_method, :instance_methods,
    :instance_of?, :instance_variable_defined?, :instance_variable_get,
    :instance_variable_set, :instance_variables, :is_a?, :kind_of?, :method,
    :method_defined?, :methods, :module_eval, :module_exec, :name, :nesting,
    :new, :nil?, :eek:bject_id, :po, :poc, :pretty_inspect, :pretty_print,
    :pretty_print_cycle, :pretty_print_inspect,
    :pretty_print_instance_variables, :private_class_method,
    :private_instance_methods, :private_method_defined?, :private_methods,
    :protected_instance_methods, :protected_method_defined?,
    :protected_methods, :public_class_method, :public_instance_method,
    :public_instance_methods, :public_method, :public_method_defined?,
    :public_methods, :public_send, :remove_class_variable, :respond_to?,
    :respond_to_missing?, :ri, :send, :singleton_class, :singleton_methods,
    :superclass, :taint, :tainted?, :tap, :to_enum, :to_s, :trust, :untaint,
    :untrust, :untrusted?]
    >> Class.methods.class

    => Array
    >> defined? Class.methods

    => "method"
    >> Class.methods.uniq.sort[0].class

    => Symbol
    >> Class.methods.uniq.sort[1].class

    => Symbol
    >> defined? (Class.methods.uniq.sort[0])

    => "method"
    >> defined? (Class.methods.uniq.sort[1])

    => "method"
    >> Class.methods.uniq.sort[0] == Class.methods.uniq.sort[1]

    => false

    How can be the same symbols(names) different ? Can somebody explain ?

    If I define my own array of symbols, method 'uniq' works as expected,
    because the same symbols are discarded.
    >> [:eek:ne,:two,:three,:two,:four,:eek:ne].uniq

    => [:eek:ne, :two, :three, :four]

    Can this be explained as a correct Ruby's behaviour or did I missed
    something ?

    Thanks.

    David

    --
    Posted via http://www.ruby-forum.com/.
    David Unric, Nov 17, 2010
    #1
    1. Advertising

  2. David Unric

    Ammar Ali Guest

    On Wed, Nov 17, 2010 at 6:47 PM, David Unric <> wrote:
    > How can be the same symbols(names) different ? Can somebody explain ?


    They are both methods, but they are not the same method:

    >> Class.methods.uniq.sort[0]

    => :!
    >> Class.methods.uniq.sort[1]

    => :!=

    Regards,
    Ammar
    Ammar Ali, Nov 17, 2010
    #2
    1. Advertising

  3. David Unric

    David Unric Guest

    Ammar Ali wrote in post #962188:
    > On Wed, Nov 17, 2010 at 6:47 PM, David Unric <>
    > wrote:
    >> How can be the same symbols(names) different ? Can somebody explain ?

    >
    > They are both methods, but they are not the same method:
    >
    >>> Class.methods.uniq.sort[0]

    > => :!
    >>> Class.methods.uniq.sort[1]

    > => :!=
    >
    > Regards,
    > Ammar


    Nope, they are same in my case:

    >> Class.methods.uniq.sort[0]

    => :!
    >> Class.methods.uniq.sort[1]

    => :!

    But now I discovered it really would be an Wirble output issue:

    >> ">#{Class.methods.uniq.sort[0]}<"

    => ">!<"
    >> ">#{Class.methods.uniq.sort[1]}<"

    => ">!=<"

    Regards

    --
    Posted via http://www.ruby-forum.com/.
    David Unric, Nov 17, 2010
    #3
  4. David Unric

    Ammar Ali Guest

    On Wed, Nov 17, 2010 at 8:54 PM, David Unric <> wrote:
    > Nope, they are same in my case:
    >
    >>> Class.methods.uniq.sort[0]

    > => :!
    >>> Class.methods.uniq.sort[1]

    > => :!
    >
    > But now I discovered it really would be an Wirble output issue:
    >
    >>> ">#{Class.methods.uniq.sort[0]}<"

    > => ">!<"
    >>> ">#{Class.methods.uniq.sort[1]}<"

    > => ">!=<"


    I'm not familiar with Wirble, but #uniq should not leave identical
    items in the array.

    Regards,
    Ammar
    Ammar Ali, Nov 17, 2010
    #4
  5. David Unric

    David Unric Guest

    It really was a Wirble's issue the author was aware of. I find it an
    essential flaw that changes IRB behaviour that leads to unexpected
    results.

    After digging in sources I made the following quick fix so now it should
    display symbols properly. Besides equal-sign, there were
    discarded/ignored also <, >, and ~ characters that may appear in symbol
    names.

    --- wirble-0.1.3/lib/wirble.rb.orig 2010-11-18 16:26:34.000000000 +0100
    +++ wirble-0.1.3/lib/wirble.rb 2010-11-18 16:31:10.380273617 +0100
    @@ -180,14 +180,20 @@
    end
    when :symbol
    case c
    - # XXX: should have =, but that messes up foo=>bar
    - when /[a-z0-9_!?]/
    + when /[a-z0-9_!?~<>]/
    val << c
    else
    - yield :symbol_prefix, ':'
    - yield state[-1], val
    - state.pop; val = ''
    - repeat = true
    + # peek ahead if equal sign is part of reference operator
    '=>'
    + # and not of comparison method name at the same time
    '<=>'
    + if (c == '=' and chars[i, 2].join == '=>' and lc != '<')
    \
    + or (c != '=')
    + yield :symbol_prefix, ':'
    + yield state[-1], val
    + state.pop; val = ''
    + repeat = true
    + else
    + val << c
    + end
    end
    when :string
    case c


    Did sent also to author of Wirble.

    Take care.

    --
    Posted via http://www.ruby-forum.com/.
    David Unric, Nov 18, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Luís Miguel Lourenço

    irb issue

    Luís Miguel Lourenço, Dec 29, 2004, in forum: Ruby
    Replies:
    1
    Views:
    103
    Lorenzo Jorquera
    Dec 29, 2004
  2. Sam Stephenson
    Replies:
    1
    Views:
    225
    Andrew Walrond
    Jun 18, 2005
  3. Replies:
    1
    Views:
    156
    Florian Groß
    Oct 26, 2005
  4. anne001
    Replies:
    1
    Views:
    268
    anne001
    Jun 27, 2006
  5. William Knapp

    Inconsistency between irb and Win7 cmd

    William Knapp, May 23, 2011, in forum: Ruby
    Replies:
    1
    Views:
    166
    Ryan Davis
    May 23, 2011
Loading...

Share This Page