tag:blog.nicksieger.com,2005:Typo Typo 2007-08-31T17:47:20+00:00 dasd urn:uuid:680b2a69-c52c-444f-8d5b-734a4fdf8e5a 2006-12-20T01:44:27+00:00 2007-08-31T17:47:20+00:00 <p><a href='http://www.goolde.com' rel="nofollow"></p> SonOfLilit urn:uuid:0d73991c-c70d-458f-a248-ceace5eacdeb 2006-10-25T07:51:46+00:00 2007-08-31T17:47:13+00:00 <p>_why&#8217;s redhanded.hobix.com has a link.</p> Pat Eyler urn:uuid:4da133d1-a189-42fa-b593-9b44d7cd71f0 2006-10-21T12:08:24+00:00 2007-08-31T17:47:13+00:00 <p>Evan said that, yes he&#8217;s used valgrind with rubinius already.</p> Nick urn:uuid:ba6e75cd-25a3-4d9e-9131-4cc9586c5fd5 2006-10-21T02:48:42+00:00 2007-08-31T17:47:12+00:00 <p>Evan said the code is in a public SVN repo, but he hasn&#8217;t published the URL yet. He&#8217;ll probably be transitioning it to Rubyforge soon. When I find out I&#8217;ll update here with info.</p> Anonymous Coward urn:uuid:c64b8c4b-c186-472f-90b7-64331f661527 2006-10-20T22:57:52+00:00 2007-08-31T17:47:12+00:00 <p>Any URL for this project yet?</p> Nick Sieger urn:uuid:9785ffcc-1680-492c-8b42-6e9111cc85aa 2006-10-20T19:07:00+00:00 2007-08-31T16:50:37+00:00 <p><em>Update: Evan has posted code and has <a href="http://blog.fallingsnow.net/rubinius/">a page set up for the project</a>.</em> </p> <p>Evan Phoenix (nee Webb), of Seattle.rb, is presenting on Sydney and Rubinius, an experiment in improving the ruby interpreter. Sydney has died, and Rubinius has risen from its ashes, appropriately.</p> <h2>Why</h2> <ul> <li>Why would you write a new Ruby interpreter? It&#8217;s fun, it&#8217;s a good challenge.</li> <li>What&#8217;s wrong with the existing interpreter &#8211; are you hating on Matz? Of course not.</li> </ul> <p>Today&#8217;s Ruby interpreter is like a big dump truck &#8211; sometimes a little slow, but it works for us. YARV is like the red, shiny fire truck. Both big and complex. Rubinius, by comparison, is like a dune buggy. Fast, light, but you&#8217;re going to get sand in your eyes if you drive it a lot.</p> <p>The project, admittedly, is naive.</p> <ul> <li>Simple architecture and implementation.</li> <li>As little background magic as possible</li> <li>No opaque C backend</li> <li>Leverage axiom of simple == powerful</li> <li>Less magic means more introspection <ul> <li>More control for the developer</li> <li>Richer introspection: Backtrace, MethodTable objects</li> </ul></li> </ul> <h2>What was Sydney?</h2> <ul> <li>Giant patch to 1.8.2 that included reentrancy and thread-safety</li> <li>Turned out to be a major PITA</li> <li>CRuby uses a large number of C globals, references to which had to be tracked and fixed</li> </ul> <h2>Transition to Rubinius</h2> <ul> <li>Ruby borrowed a lot from Smalltalk, so why not try an implementation based on the same concepts?</li> <li>Prototype A ported the blue-book implementation to Ruby</li> <li>It worked and validated the basic concept and approach</li> <li>Prototype B took ideas from A but implemented a bytecode interpreter and compiler. Used RubyInline to access raw memory operations.</li> <li>At this time the goal emerged to have a translator which could take a prototype and bootstrap itself into C code.</li> <li>Prototype S was a manual translation of Prototype B into C code to make the implementation quicker.</li> <li>Prototype W was created to translate parts of Prototype B so that there is a maintainable core in Ruby code itself.</li> </ul> <h2>Questions</h2> <p><em>Q. Since you were starting over, could you use a platform-independent library to ease the process, such as APR?</em> Yes &#8211; currently using String and PointerArray from glib.</p> <p><em>Q. How is performance?</em> Too early to tell &#8211; I hope to know by the end of the conference. Prototype S became runnable and usable on the plane here.</p> <p><em>Q. Can you clarify the goal?</em> To create a Ruby interpreter in Ruby that can translate itself out into a C interpreter.</p> <p><em>Q. Have you figured out how to link in external libraries in a platform independent way?</em> No. My hope is that the decision will be made to write a common framework for translating to system calls, e.g., SWT.</p> <p><em>Q. Have you looked at PyPy? (similar project for Python)</em> Yes, and it&#8217;s f-in complicated. It worries me actually.</p> <p><em>Q. Could you have it generate backend code in another language/platform (Java bytecode, CLR)?</em> Yes, I certainly hope so, otherwise I&#8217;m wasting my time.</p> <p><em>Q. How will you add native thread support in a cross-platform way?</em> I hope I won&#8217;t have to, by leveraging external tools.</p> <p><em>Q. If you&#8217;re building a Ruby-to-C translator, why write a Ruby interpreter at all?</em> If I didn&#8217;t, what would I translate? You still need some core engine to translate. <em>Would it be a subset of Ruby?</em> Yes.</p> <p><em>Q. Looks very similar to Squeak, have you looked at Squeak code and talked to Squeak people?</em> Looked at code a lot, I&#8217;ve really stolen all of their ideas. I haven&#8217;t talked to the folks yet because I&#8217;m afraid they might laugh at me.</p> <h2>Resulting Works</h2> <ul> <li>SydneyParser: Used parser from Sydney and stole ParseTree&#8217;s algorithm for generating a sexp that represents the Ruby code.</li> <li>SegfaultProtection: detects a segfault in an extension, saves the Ruby interpreter, and raises a memory fault exception instead.</li> </ul> <h2>The Nitty Gritty (Red Pill)</h2> <ul> <li>All components separated by APIs for swappability</li> <li>Garbage collector: baker two-space copy collector, and a train GC</li> <li>Bytecode interpreter: small set of instructions driven by tests and need, so there are no extraneous operations</li> <li>Compiler: written completely in Ruby, using ParseTree and SexpProcessor. Intended to compile itself to be used as a base compiler for Prototype S.</li> </ul> <h2>Future</h2> <ul> <li>Other backends &#8211; Java, Smalltalk</li> </ul> <h2>More questions</h2> <p><em>Q. Worried about fragmentation?</em> Yes, but I really want to make it as compatible as possible with the current interpreter.</p> <p><em>Q. Rubinius bytecode compatibile with YARV?</em> No, but I hope to be able to write a bridge to YARV in Rubinius.</p> <p><em>Q. Have you looked at Valgrind for the C code?</em> Yes, I have. Good possibility for future direction.</p> <p><em>Q. Can you demo some code?</em> They&#8217;re incredibly boring. &#8220;Look I got a MethodTable object, I asked for one.&#8221;</p>