Posted by rue, Sun Feb 11 00:43:00 UTC 2007

Apologies about the delay, for some reason I thought I did not have enough content to ‘publish’ yesterday. Hopefully none of you had to go on a crime spree due to missing your fix.

Additional apologies are offered for including information from the commit stream and any non-biased commentary instead of delivering just cold, hard IRC news. Think of those parts as op-eds. Or the cartoons.

• Class variables vs. class instance variables again

  mae and I talked about having @@x be syntactic sugar for (self.class.) instance_eval {@x} since it would break compatibility with 1.8 (1.9 follows pretty much the same track as proposed change). Decision was to be deferred to evan.

• Get to Know a Macro pt. 2

  REFERENCE_P tells you whether an object reference cleverly holds an immediate value instead of a reference, just like in MRI. The objects that appear as immediate values are as follows: nil, true, false, undef, Symbols and Fixnums. The reference is encoded to make this detection simple.

  In addition, you can use things like STRING_P to figure out whether a reference points to a core class instance.

• Block parameter semantics

  cabo and I put our heads together trying to figure out how exactly block parameters work in some kind of strict terms. The issue is mostly with multiple parameters. Here are a few test cases I wrote: http://pastie.caboo.se/37715.

  And this is what we came up with:

  1. Multiple arguments are always treated as separate.
  2. If the only argument is a single Array, multiple assignment semantics are used.
  3. If the only argument responds to #to_ary, 2) applies.
  4. * behaves normally.
  5. If the block takes only one parameter, a warning is emitted if multiple are passed.
  6. If the block takes multiple parameters, extra ones are silently ignored.
  7. If the block takes multiple parameters and too few are passed in, missing ones are silently assigned nil.
  8. Damnit, I forgot what this one was when I had to rewrite this after my battery died. Damnit all!

  Please add any cases these do not address.

• How does addressing work?

  In my travails through the compilation path I took a look at assembler.rb as well and my grand hypothesis was confirmed by cabo. The bytecode addresses for labels and gotos are simply byte offsets in the encoded instructions. The assembler keeps tabs on how many bytes different instructions consume with @current_op which can be used when labeling is needed.

• ruedbg

  The incredible ruedbg will walk you through the transformation of sexp to assembly by compiler.rb with merely food, sleep and some money! For self-education I was tracing this piece of code through the compiler to see how the processing went. You can follow along on your local copy of compiler.rb!

  [[1, 2]].each {|a, b| p a, b}  # http://pastie.caboo.se/37718

• Know your datatypes: Tuple

  Tuple is somewhat like a very primitive Array. It has two properties: 1) it has a fixed number of fields, 2) any objects can be inserted and removed to/from those fields.

  Rubinius uses Tuples for many internal representations including in argument passing. They are also exposed to the outside world as, essentially, an additional Core class.

• Primitives

  mae and evan have engaged in a back-and-forth all through the weekend regarding changes to primitives. mae is keen on trying to isolate them as much as possible along with some more drastic changes but those are, for now, on hold. One product of this has been the addition of the argument count to send_primitive, enabling mae to better test the primitives.

• Committing changes

  evan stated a preference of receiving slightly larger aggregate changesets instead of minimal one- or two-line changes (barring high-importance stuff of course) very frequently.

• The Big Reveal nighs

  evan is polishing off his addition of among other things a fastmethodcontext to replace the current presumably slower MethodContext which should make things on the VM side snappier.

  He also indicated that in the future he would try to set up branches for these types of large all-encompassive changesets so that we may view the code while he is working at it without compromising stability in the trunk. Hooray!

• Subversion (and svk)

  We rehashed all the old centralised- vs. distributed Version Control System arguments without really getting anywhere but perhaps that was not the point. Fun was had by all.

  In the process, I set up svk on this side to help with the workflow. svk help intro gave me all the information I needed once I actually FOUND it :/

• Issues of importance

  To help get rid of obsolete.rcompile, shotgun needs to get some problems fixed. Run bin/reports/self_hosting_errors.rb and see where help is needed!

1
2

  "a#{@x}b"  => [:dstr, "a", [:evstr, [:ivar, :@x]], [:str, "b", 0]]
  :"a#{@x}b" => [:dsym, [:array, [:evstr, [:ivar, :@x]], [:str, "b", 0]]]

• Compatibility

  brixen and I had a spirited conversation about incompatibility with headius putting in some insightful commentary. Since the IRC Correspondents write the history, here is my take.

  There are two kinds of incompatibility. The first, clearer one is that there is an interface incompatibility with the reference implementation. For example, having String#split return a Tuple instead of an Array or different semantics for the ternary op. Another would be a missing feature, shipping without Hash for example or substituting it with a Dict. These types of problems are less likely to be an issue.

  The second and slightly harder form are additions to the standard (if a portable library is not available.) Again I pick on poor Tuple but if Tuple is available in Rubinius as, essentially, an additional Core class, then what is there to stop Bob Programmer from using it to write his MightyIRCBot? And what if Bob wants to distribute the program, will people need to have multiple Ruby implementations available? For the sake of the argument, assume that no portable Tuple

  My point was not necessarily to assign responsibility to anyone over Bob’s decision but to state that /regardless of whose ‘fault’ it is/, it will be a problem. I am sure all of the long-time programmers remember a time when a meticulously crafted program either completely exploded or had its performance halved due to a platform not offering all of the features of another one.

  My personal ideal would be that /so long as there must be different implementations of Ruby/, Matz defines what the language is and all implementations conform to it so that any Ruby application can run on any of the platforms. These points are of course all moot should Matz decide that Rubinius is where ‘it’ is ‘at’ and decree that all other Ruby implementations must die a horrible death and enforce singularity.

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

Filed Under: rubinius | Tags: irc newsletter rubinius