What happened on the mruby front in December 2012?
As described in the last blog entry, my
mrbgems patch was merged this month into the HEAD of
mruby. Since then an insane amount of activities around this implementation started. I hardly kept track of all the improvements which were done by the following people: mattn, MATSUMOTO Ryosuke, Yuichiro MASUI, Masaki Muranaka, Davide D’Agostino, Xuejie Xiao, Akira Yumiyama and Tomoyuki Sahara. Next to bug-fixes, Windows support was added and also external library integration is now possible. And as far as I can count there are already a dozen of mruby libraries transformed to the GEM standard (i.e. mruby-sqlite3, mruby-redis). At the same time I have to notice that this is all still quite alpha. Yuichiro MASUI is working hard on rewriting many parts of mrbgems to empower Rake, so the GEM standard is moving still. More about that in the next paragraph.
After some back and forth matz finally agreed to use Ruby as a building pre-condition. That means we can drop the good-old Make and move to Rake. Yuichiro MASUI ported Rake to mruby (now called
minirake), which is included in the mruby source by now. So the only thing you need is a Ruby interpreter (at the moment CRuby 1.8 or 1.9 – JRuby 1.9 Mode is not working – I’m investigating) and you are good to go.
Cross compiling will now also become easier. Half a year ago I explained how to use
cmake to cross-compile mruby for different platforms. After finishing all rough edges of the minirake build process, we will drop cmake completely. I think it is a bit sad remembering all the hard work which went into it. But after seeing the beauty of the new Rakefiles I will stop crying soon, perhaps.
skandhas did an incredible job in improving
Module. Many missing methods were added, mainly used for introspection.
Removes the method identified by symbol from the current class.
Removes the definition of the
sym, returning that constant’s value.
Returns true if the given class variable is defined in
Sets the class variable names by symbol to object.
Returns the value of the given class variable (or throws a NameError exception).
Evaluates block in the context of the
Module. This can be used to add methods to a class.
module_eval returns the result of evaluating its argument.
Returns an array containing the names of the public and protected instance methods in the receiver. For a module, these are the public and protected methods; for a class, they are the instance (not singleton) methods. With no argument, or with an argument that is false, the instance methods in mod are returned, otherwise the methods in mod and mod’s superclasses are returned.
Returns true if module is included in mod or one of mod’s ancestors.