Parrot Embed Grant - Report #3
Mon, 28-Feb-2011 by
Makoto Nozaki
edit post
<![CDATA[
_Jonathan Leto wrote:_
The quest to improve test coverage for src/extend_vtable.c has continued. Some dragons were slayed, a few trolls were paid tolls to cross creaky bridges of abstraction and many siren calls to hack on other code were dutifully ignored (mostly).
This "TPF":http://perlfoundation.org/ grant has forced me to become very familiar with Parrot vtables (virtual tables), which is basically an API for talking to Parrot "PMCs":https://github.com/parrot/parrot/blob/master/docs/pdds/pdd17_pmc.pod (really just objects with a funny name). PMC can stand for Parrot Magic Cookie or PolyMorphic Container. Take your pick.
Firstly, vtable is already slang for "vtable function", which expands to "virtual table function." What the junk is a "virtual table function" ? I find that the simplest way to think about it is that every PMC has slots or buckets with standardized names such as *get_bool* (get Boolean value) or elements (how many elements does this PMC have?).
All PMCs inherit sensible defaults for most vtables, but they are allowed to override them. Why would you want to override them? As a simple example, let us assume there is a vtable called *length* (there isn't actually, but it makes an easy example to explain these concepts). Our *length* vtable will act just like *elements* and tell us how many elements a PMC has. If we had a complex number PMC that was really just an "FixedFloatArray PMC":https://github.com/parrot/parrot/blob/master/src/pmc/fixedfloatarray.pmc of two numbers underneath, the *length* would always return 2 for every complex number. Not very useful.
A much more useful *length* vtable would use the coefficients *a* and *b* from *a + b∗i* and compute the Euclidean distance (length from the origin) *sqrt(aˆ2 + bˆ2)*. Hopefully you now have a taste for what what vtables are about. Parrot PMCs have over 100 vtables that can be overridden to provide custom functionality.
I recently ran across the hashvalue vtable and couldn't find any tests for it in Parrot core (outside of the test that I had written for it in extend_vtable.t) or any use of it in "Rakudo Perl 6":http://rakudo.org/. Oh noes! It seemed like an unused/untested feature, so I created a "Trac Ticket":http://trac.parrot.org/parrot/ticket/2027 to mark it as deprecated so it could be removed in a future release.
The discussion about the ticket was fierce. "NotFound++":https://github.com/NotFound explained why the vtable was important and the mighty coding robot known as "bacek++":https://github.com/bacek manifested tests quickly.
Yet another case of this grant work having a positive impact on the Parrot codebase, even outside the embed/extend interface. I also "improved an error message in the PMCProxy PMC":https://github.com/parrot/parrot/commit/612ec787dc975c4d570fb9b95d5f9fbd2993e92a, which arises when something goes bad during a partial re-compile. Yay for improved debuggability!
According to the current "code coverage statistics":http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend_vtable-c.html, extend_vtable.c is up to 54% coverage from 43%, which is not quite where I predicted from my last update. No doubt this has something to do with me packing and preparing to move to a new house this month. My velocity didn't decrease so much as the amount of time that I had to work on this grant.
I am greatly enjoying working on this grant and even if it is going a bit slower than I had planned, I am very confident that it will be completed in the next few months and hopefully sooner.
_Original article at "dukeleto.pl":http://leto.net/dukeleto.pl/2011/02/parrot-embed-grant-update-3-now-with-dragons.html ._
]]>
Comments (0)
