Results tagged “tpf” from dukeleto.pl

A Final TPF Parrot Embed/Extend Grant Update

|

Really TLDR: The Parrot has landed.

It brings me great joy to announce that I have completed all milestones for my TPF grant regarding the Parrot Embed/Extend subsystems! Not only that, but all of my grant work was included in the most recent release of Parrot, 3.5.0 "Menelaus".

The actual TLDR of this update is "many tests were written, code coverage is above 95% for all systems described in the grant, docs were improved, many Parrot Trac tickets were created and many a blarg toast was cooked.

For those of you that have a thirst for knowledge unquenched (I know who you are), you are welcome to pondiferously peruse the Impending Technical Details.

The Deets

The last portion of this grant definitiely challenged me to think in new ways about testing and I am now only beginning to reap the benefits. I was charged with adding code coverage a few rarely-if-ever-used C functions in Parrot's embed/exted subsystem, which allows you embed Parrot into other applications and other funky stuff.

Whiteknight++ greatly helped me write a test for Parrot_sub_new_from_c_func which takes a C function and a string that describes the function signature of the C function and returns a NCI PMC, which can be invoked.

I also learned many lessons about code coverage during the final stage of this grant, even though I thought I was at such a level of expertness that it would be hard to learn drastically new and important perspectives on testing. This pattern of thinking is always wrong.

Lesson 1

Sometimes you are the underdog and you have to interpret the rules in a new way in order to have a chance at winning. You need to be Ender Wiggins from Ender's Game: continually inventing new tactics to keep a winning edge over the competition.

I noticed that a large portion (about 80%) of the uncovered code in one file was a macro that was copy-and-pasted into two places. I refactored this into a single macro called POP_CONTEXT, which reduced the total number of lines in the file by roughly 10, while simultaneously decreased the number of uncoverd lines in the file by ~20 lines, which had a combined effect of pushing the code coverage over the necessary 95% mark.

This change definitely increases the maintainability and modularity of the code, but it feels a bit like gaming the system. Nonetheless, it saved the day.

Lesson 2

The simplest useful test that you are avoiding is the most valuable next test to write, because it has the best ROI (Return on Investment, where investment is the time it takes to write the test, and the return is having an automated way of verifying that the feature works.

Lesson 3

Software developers are very optimistic about time estimates. We forget about all the possible things that could go wrong and often quote estimates on something approaching "base case scenario". As a rule of thumb, I think all software developers should think long and hard about a time estimate for a given project, write down the estimate, then multiply that time estimate by pi for a REAL estimate.

I theorize that pi is the factor of time it takes to debug and write tests for behavior of hard-to-recreate edge cases.

I originally thought my grant would take about 3 months, but it ended up taking about 9 or ten. QED.

Finally, I would like to thank my grant manager Makoto Nozaki for providing lots of feedback, support and encouragement, as well as everyone else at the The Perl Foundation for funding this grant.

Parrot Embed Grant Update #5 : Zen Pebbles

|

I am still on the path of increasing test coverage in src/extend_vtable.c. It is much like a zen study, where you methodically concentrate on many tiny little pebbles, one at a time, moving them in the sand, to just the right place. According to the latest code coverage statistics, we are now at 72% code coverage, which is an increase of about 8% since my last report.

Many, many more tests involving Key PMCs were added. For an intro to what they are, take a look at my previous grant update. Many of the tests are clusters of related tests, because most VTABLEs have many similar forms which take integer, string or PMC-flavored keys. I ran into some platform-specific bugs which only manifest on Darwin machines, which were reported by Jim Keenan in TT# 2098 and which I then fixed by querying with a non-empty Key, which is more prudent.

I also ran into some actual bugs which I reported as Trac Tickets. First is that the cmp_pmc VTABLE does not seem to be working correctly from extend_vtable, which was reported in TT #2103. Then I fell into a "hole" in the VTABLE API, where ResizablePMCArray does not respond to defined_keyed(), which it should. This is described in TT #2094.

In retrospect, this was one of the most productive periods of my grant work. I estimate that I will be very close to the 95% milestone by my next grant update at this pace, which is very exciting.

Parrot Embed Grant Update #3 : Now with Dragons

|

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.

I'm excited to announce that Parrot Foundation and The Perl Foundation have been accepted as organizations in Google Code-In 2010!

Google Code-In is a contest, similar to Google Summer of Code, where Google pays students aged 13-18 to do tasks designed by open source communities, while learning about open source. Google pays for the work to be done, and we get new members to our communities, while students learn useful skills. It is a big win for everyone.

In 2010, Google Summer of Code was a great success for Perl and Parrot. We got amazing new features in Parrot, Perl 5 and Perl 6 . In 2009, we had similarly spectacular results.

For the students, the benefits are huge. They get mentored by some of the best minds in open source and get "street cred" in the community. This contest also acts as a stepping stone for Google Summer of Code, so students that excel at Code-In will most likely be sought after for future Google Summer of Code involvement. It's also fantastic experience to put on a résumé. I see many Google Summer of Code students get snapped up by respected companies, or accepted to prestigious academic institutions.

The more well-documented tasks we have before that, the more students we will have the potential to attract. I can attest that these kind of contests attract some of the smartest students in the world, so the Perl and Parrot communities have much to gain by being involved.

I expect great results for Code-In as well, but we need your help. The Google Code-In contest opens up for students on:

  • November 22, 2010 at 12:00 AM Pacific Time / 08:00 UTC.

How Can You Get Involved?

  • Add a task to our task list There is a template that you can copy and paste, as well as many examples. Any task related to Perl 5, Perl 6 or Parrot is fair game.
  • Improve the description of an existing task. The more specific a task and the more documentation and links you provide, the easier it is for a student to choose and complete a task.
  • Volunteer to mentor a student on a task. You apply to be a mentor here. Please join the tpf-gsoc-students mailing list and introduce yourself. Provide a brief description of why you are interested when you sign up, so we know you aren't a bot :) Please also join the #gci channel on irc.perl.org.
  • Tell potential students about Google Code-In and how we are involved. Here is a link to the timeline and FAQ that you can send them, as well as flyers to post.
Clicky Web Analytics 42