The Dailyish IRC Newsletter, 2007.02.12-14
Posted by rue, Thu Feb 15 22:20:00 UTC 2007
New stuff.
- Matters of precedence
An important part still to be designed and implemented is the Ruby Native Interface or RNI (to be renamed following a contest that closes on Monday over on pate’s blog.) This layer will support writing C extensions—and running old extensions from MRI.
However, another important step before this is the stabilisation of the shotgun platform. Both the compiler and VM side need some work. I have been working on getting everything to be able to be compiled with shotgun instead of relying on rcompile. The next step would be to actually make the compiled code /work/.
- sirb and evaling
evan pushed in a change that allows local variables to persist between cycles in sirb (essentially by allowing using the same vm state) so sirb should work closer to normal now.
- New developments
zimbatm is working on some String stuff (one patch is already in) and hornbeck is starting his tour of duty with Time!
- Pointers…?
mae suggested that we allow (via some primitive-like syntax) access to direct memory pointers. The question is, can you come up with a good use case for this?
- FMC backtrack
evan decided on another approach for the faster MethodContext merge; he is currently breaking it into pieces that can be individually merged to trunk. The fmc branch does still exist if you want to look at it.
- There is Marshalling and there is Marshalling
Sidenote-type thing: the marshal format used by rubinius is not the same that MRI uses. There will be a compatibility or conversion library.
- Website changes
http://rubini.us is moving to use devalot instead of collaboa. You can head over there and create accounts yourself.
- Notoriety
Someone posted this, ah, ‘insightful’ commentary.
http://jesusphreak.infogami.com/blog/rubinius_fights_on
It was discussed in some detail—too much, in fact. They are clearly trying to distract us by their suckiness.
- Virtues of atomic commits
Discussion was had about atomic commits—any commit made should be self-contained and usually minimal set of changes strictly related to one thing (i.e. not putting vm fixes and a new method implementation in the same commit, for example.) This helps focus and clear the intention of a changeset as well as make it easier to roll it back if a part does not function as expected.
Evan has expressed a preference for not getting eight commits in a half-hour so we certainly try to abide by that—but it does not mean commits cannot be atomic!
- The Injured and Vacationing list
evan is going to be out vacationing for a week-ish but cabo has returned from his excursion so we all have someone to bother!
- Architecture, self-hosting and bootstrapping
gcorriga stopped by and asked to verify his impression that rubinius produces C code from Ruby to create the VM and, if so, would it allow interpreting the same code.
He was informed that, currently, the C is a manual translation from the Ruby VM and the two are not kept in sync.
The idea is to move to the cuby model of writing the VM in Ruby and translating that code to C that can be compiled for the twofold goal of making the VM easier to develop and having the C speed. The cuby stuff can be bootstrapped using the existing tools and then fully migrate to it instead.
- Heisenbug rears its.. erm, is that a tail?
With the recent commits, everything that is needed to build the compiler using shotgun actually compiles (does not run yet though.)
In testing this, the problem nicknamed Heisenbug by cabo manifested itself by causing a segfault in the compilation process—but only on 32-bit. On 64-bit everything works fine.
You can use the RUBINIUS_OMSIZE env to try to work around this (OM standing for Object Memory.) A value around two million (2000000) or up should be alright.
Hopefully we will be able to get rid of the problem soon.
These summaries are available on the Web:
The rubinius IRC channel is #rubinius on Freenode. Join us!