Posted by rue, Sat Feb 10 23:59:00 UTC 2007

• Contributions!

  Some discussion was had about getting more people to contribute—the best thing I can say: we are all Ruby coders and there is a LOT of Ruby code to be written, whether it is specs (which I am relegated to do right now due to the 64-bit issues), writing core stuff like missing Array features or anything of the like.

  Go to http://rubini.us/rubinius, read the docs that are available (pretty concise) and do a bit of hackering. If you have questions, this ML or the IRC channel should work fine!

• Fields vs. instance variables

  Evan took a moment to explain the difference between fields (from kernel/00auto_fields.rb and elsewhere) and regular instance variables and in hindsight it is obvious.

  Fields are, more or less, internal data that is not accessible from client code (see below) in any way. These are useful in implementing core classes. The discussion was sparked by defn52 looking to add a field to Hash to represent the default block (which due to Ruby’s semantics needs to be separated from a default value.) This type of data, while certainly requiring storage, should not be exposed to clients which is why a field is used. This type of data in MRI would probably be stored directly at the C level.

• What to call stuff

  The above discussion tangentially lead to a discussion about semantically separating the different roles that code may have in Rubinius. The way I see it, there are four entities:

  1) The VM (compiler, assembler, marshaling and what have you.) Parts C, parts Ruby.

  2) The Ruby language (which is somewhat intermingled with the VM code.)

  3) Ruby Environment libraries. Importantly, I use this term for both Ruby Core (Array, Hash etc.) as well as the real Ruby Stdlib (Socket, GetOptLong etc.) These are your favourite libs that MRI has ‘out of the box’ and are used to write regular programs.

  4) User code or client code. This is the stuff that the project is for—people running their programs in the environment that Rubinius provides (comprised of the first three items above.)

  This ended up being right about how everyone else did the mapping mentally (even Evan who tends to think of ANY .rb files as ‘interpreted code’) but it is good to agree on terminology so that it does not need to be redefined each time. Please propose a better name for 3), though.

1
2
3
4

  #define GUARD(predicate_expression) \
               if( ! (predicate_expression) ) { _ret = FALSE; break; }

  #define POP(var, type) var = stack_pop(); GUARD( type##_P(var) )

• Better reporting

  mae has been working on getting the reporting algorithms more representative. Check the report: namespace in Rake with rake -T report.

• for f in missing_features do

  Adam Ritter implemented the for .. in functionality and it has now been committed!

  hurdlea has also continued his work in getting Regexp to work with a steady stream of commits.

  end

• RSpec work

  brixen and mae are trying to get RSpec to run natively on Rubinius to avoid the hackery we are currently resorting to in order to run specs. Help there is appreciated.

The Rubinius IRC channel is #rubinius on Freenode. Join us!

Filed Under: rubinius | Tags: irc newsletter rubinius