[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Ruby status



Hello, world!

Some notes about the current state of Ruby on GNU/Hurd:

- It runs with Moritz' patch. The patch and Debian packages are
  available at <http://duesseldorf.ccc.de/~moritz/ruby-hurd/>.

- Neither the upstream version nor the package in Debian-unstable
  compile on GNU/Hurd. I am trying to find out why the patch was
  not included. More about that later.

- Interactive Ruby (irb) does not work. It tries to read the users
  home directory as configuration file, but that does not contain
  valid Ruby code, of course. This is probably a bug in irb and
  at least finding a workaround shouldn't be to hard. The error
  message is the following:

/usr/lib/ruby/1.6/irb/init.rb:160:in `load': /home/toor:1: Invalid char
`\231' in expression (SyntaxError)
/home/toor:1: Invalid char `\001' in expression
/home/toor:1: parse error
-
    ^
        from /usr/lib/ruby/1.6/irb/init.rb:160:in `run_config'
        from /usr/lib/ruby/1.6/irb/init.rb:158:in `each'
        from /usr/lib/ruby/1.6/irb/init.rb:158:in `run_config'
        from /usr/lib/ruby/1.6/irb/init.rb:157:in `catch'
        from /usr/lib/ruby/1.6/irb/init.rb:157:in `run_config'
        from /usr/lib/ruby/1.6/irb/init.rb:17:in `initialize'
        from /usr/lib/ruby/1.6/irb.rb:39:in `start'
        from /usr/bin/irb:13


- I had to insert a "void _start (void) {}" in a Ruby module I
  wrote (Alfred M. Szmidt found this solution for me). Otherwise
  I'd get the error message:

./hello.rb:3:in `require': /lib/libshouldbeinlibc.so.0.2: undefined
symbol: _start - ./test.so (LoadError)
        from ./hello.rb:3

  Various people in IRC (#hurd) proposed different locations for
  fixing this, including libc and libgcc.

- The errno constants are wrong. For example, Errno::EBUSY::Errno
  does not give us EBUSY (0x40000010), but 0xC0000010. This has
  probably to do with the fact that Ruby converts the error codes
  to Fixnums and the Ruby Fixnum type is a 31-Bit integer. The
  Fixnum type is optimized for performance through some dirty hack:
  A Ruby object is of type VALUE in C, which is normaly a pointer.
  A Fixnum is stored directly in this VALUE, however. (Ruby requires
  sizeof(void*) to be sizeof(long). Yes, Ruby _is_ supposed to be
  portable). It uses the least significant bit (bit 0) of a VALUE to
  indicate that it is a Fixnum and stores the number in the bits
  1-31, that's the reason why Fixnum is a 31-Bit integer. Ruby
  converts Fixnum VALUEs to integers and vice versa by shifting (and
  setting the lsb in case of int->Fixnum). However, this means that
  a Fixnum can't hold a value like 0xC0000010, which doesn't prevent
  Ruby from letting Errno::EBUSY::Errno.class be Fixnum and at the
  same time Errno::EBUSY::Errno be 0xC0000010. Oh, just in case you
  haven't noticed yet: 0x40000010 with the most significant bit set
  is this 0xC0000010 thing. Could this be some signed/unsigned
  problem? At least ruby -e 'puts Errno::EBUSY::Errno' prints the
  number -1073741808. Perhaps replacing INT2FIX() with INT2NUM()
  where   Ruby converts the errno constants to VALUEs would solve
  this problem, I did not test this yet.

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling <wolfgang@pro-linux.de> `-:._ "Omnis enim res, quae dando
Debian GNU/Linux user && Debian GNU/Hurd user  `-:. non deficit, dum habetur
Hurd Hacking Guide - http://stdio.cjb.net/hhg.html )  et non datur, nondum
www.debian.org || www.gnu.org || hurd.gnu.org _,-:' habetur, quomodo habenda
["Accelerate your PC - with 9.81 m/s^2."] ,-:'   est." --> fsfeurope.org <--



Reply to: