February 2011 Archives

Parrot Embed Grant - Report #3

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 grant has forced me to become very familiar with Parrot vtables (virtual tables), which is basically an API for talking to Parrot PMCs (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 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. Oh noes! It seemed like an unused/untested feature, so I created a Trac Ticket to mark it as deprecated so it could be removed in a future release.

The discussion about the ticket was fierce. NotFound++ explained why the vtable was important and the mighty coding robot known as 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, which arises when something goes bad during a partial re-compile. Yay for improved debuggability!

According to the current code coverage statistics, 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 .

We have received the following Hague Grant application from Moritz Lenz.

Before the Board votes on this proposal we would like to have a period of community consultation. Please leave feedback in the comments or if you prefer send email with your comments to karen at perlfoundation.org.


Moritz Lenz

Project Title

Structured Error Messages: Design and Implementation


A system for error messages will be designed, and implemented in Rakudo, that makes it easy to programmaticially identify and classify errors. This will apply to errors from the compiler, run-time errors and custom errors thrown by the user.

Benefits to Perl 6 Development

The Perl 6 makers strongly emphasize good error messages, but the absence of a specification or standard currently leads to divergence of error messages between the different compiler projects. This project aims to unify them again, by providing a standard, and data files to obtain error message formats from.

Also non-standard error messages make it nearly impossible to write robust tests for getting the right error message for a particular failure mode, leading to either regressions due to lack of tests, or implementation-specific tests. Significantly improved testability is both a goal and the main motivation for this project.

Finally Perl 6 needs a specification for error messages at some point for the benefit of the users, advancing it is a natural step on the path to Perl 6.0.


D1: Specification

I will design a system that makes it easy to construct error objects, makes it easy to query error objects for useful# information (for example if it's a compile time or a runtime error, related to IO, related to numeric operation etc). The design will make it easy to add custom error modes, and enable hooks for localization and internationalization. It includes description of an (or possibly multiple) error class, ways to identify and query errors, and an API for customizations.

It will be developed in collaboration with the Perl 6 design team, and the contributors of all major Perl 6 compiler projects.

D2: Error catalog, tests

Based on the current error messages from STD.pm, Rakudo and Niecza, an initial catalog of standardized error messages will be compiled, and provided in a form that makes it easy to use by compiler writers.

Tests for the official spectest suite will be written, both for the error API, and for individual cases where failures are provoked on purpose, and tested for leading to the correct

D3: Implementation, tests, documentation

I will implement the error construction and classification/introspection mechanism in Rakudo, and switch all error messages triggered from within Perl 6 code to the new system.

I will also extend the tests, and replace most tests for error messages with tests for error objects or error characteristics. I'll also make it very easy to write such tests, and provided documentation for compiler writers and test writers on how to properly deal with error situations.


Work on this grant could start as early as March 2011, and is planned to take 1 to 2 months per deliverable.

Report Schedule

I plan to blog at least every two weeks, on a blog that is assembled by planetsix.perl.org. A final grant report will be submitted to TPF.


All result of my work will be added to public repositories: contributions to the specification and the spectest suite to the roast repository, contributions to Rakudo to the Rakudo repository.

Code Ownership and License

By German laws I have imprescriptible ownership of my code. It will be licensed under the Artistic License 2.0 (to be compatible with the licenses of all projects involved). I have signed a TPF CLA.


I hold a German Diploma in Physics and a Master of Honours in Physical Science, and I have a strong background in computer science. I have been contributing to Perl 6 since 2007, and have made more than 2000 commits to the test suite and more than 1000 to Rakudo, contributed to the Perl 6 specification, blogged, and I'm one of the main authors of the "Using Perl 6" book (to be published by Onyx Neon Press).

Amount Requested

Since my employer allows me only to earn 400 Euro per month additionally, I request 400 EUR or 540 USD per deliverable, ie. 1200 EUR or 1620 USD in total.

Dave Mitchell writes:

As per my grant conditions, here is a report for the January period.

Tinkered a bit more with overloading and tieing, and worked on the security issues associated with user-defined \p{} properties.

Over the last month I have averaged 10 hours per week. Over the 47 weeks of the grant (to 31/Jan/11), I have done 585 hours, averaging 12.4 hours per week. There are 315 hours left on the grant.

Report for period 2011/01/01 to 2011/01/31 inclusive


Effort (HH::MM):

0:00 diagnosing bugs
42:25 fixing bugs
0:00 reviewing other people's bug fixes
0:00 reviewing ticket histories
0:00 review the ticket queue (triage)
42:25 Total

Numbers of tickets closed:

4 tickets closed that have been worked on
0 tickets closed related to bugs that have been fixed
0 tickets closed that were reviewed but not worked on (triage)
4 Total

Short Detail

4:30 [perl #2460] electric-fence finds a bad memory reference in perl
3:30 [perl #58530] Bus error with constant + overload + stash manipulation + bless ]
9:30 [perl #71286] overload (2 bugs): fallback/nomethod failures with heterogeneous operands
5:50 [perl #75466] [PATCH] glob is inconsistent about <> overloading
0:20 [perl #75870] perldata.pod tied hash in scalar context
18:45 [perl #82616] security Issues with user-defined \p{} properties

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

About this Archive

This page is an archive of entries from February 2011 listed from newest to oldest.

January 2011 is the previous archive.

March 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2