Skip to content
Browse files

Add some html versions of blog posts

  • Loading branch information...
1 parent 1cd39d3 commit adc7dffad2efc5bce977cc61ccd81e0a7e4dae43 @leto committed
Showing with 269 additions and 0 deletions.
  1. +120 −0 blog_posts/tpf/TPF_grant_update_6.md.html
  2. +149 −0 blog_posts/tpf/TPF_grant_update_7.md.html
View
120 blog_posts/tpf/TPF_grant_update_6.md.html
@@ -0,0 +1,120 @@
+<h1>Yet Another TPF Parrot Embed/Extend Grant Update</h1>
+
+<p>I am excited to announce that I have completed my next grant milestone! I
+recently increased test coverage of extend_vtable.c to over 95% (
+<a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend_vtable-c.html">95.5%</a> to be
+exact), achieving the milestone with a half percent buffer. It definitely
+wasn't easy, but I changed the way I was approaching writing tests and it
+resulted in a <a href="https://github.com/parrot/parrot/compare/5dd8c543ab...8c04cc3e66">huge burst of
+productivity</a>.</p>
+
+<p>I went through a test coverage report and wrote down, on an actual piece of
+<em>paper</em>, every function that had no test coverage. This allowed me to circle
+the functions that I thought would be easiest to write tests for, and quickly
+got those out of the way. I then went for uncovered functions that were similar
+to already covered functions, and then finally I got to the hard functions.</p>
+
+<p>This was a fruitful exercise, because it was decided by Parrot developers that
+some VTABLE functions escaped accidentally and that they should be removed from the public API.
+Whiteknight++ <a href="https://github.com/parrot/parrot/commit/cbfc76e64acf9f0a526b5f7da0e4c6c4ec0d1189">removed Parrot_PMC_destroy (extra points for humor)</a>, which I was using incorrectly in the
+extend_vtable tests and which was actually coredumping Parrot, but only on certain
+platforms. I then removed <a href="https://github.com/parrot/parrot/commit/cd1edef38c9f7d4af8ec3229fa166e4fe92d21f6">Parrot_PMC_mark</a> and <a href="https://github.com/parrot/parrot/commit/44a9634f2764ccccfd7a5cbad1552159fc73bff8">Parrot_PMC_invoke</a>, the first being
+an implementation detail of the garbage collector, and Parrot_PMC_invoke because
+it was the only function that returned a '''Parrot_Opcode_t*''' and basically
+not fit for public consumption.</p>
+
+<p>I also <a href="http://trac.parrot.org/parrot/ticket/2126">created a ticket (TT#2126)</a>
+for a bug in the Parrot_PMC_morph function, which
+has some possibly buggy but definitely unspecified behavior.</p>
+
+<p>The remaining, untested functions in extend_vtable are clone_pmc, cmp_pmc,
+get_pointer_keyed_int, get_pointer_keyed_str, remove_vtable_override,
+set_pointer_keyed and set_pointer_keyed_str. I leave the testing of these
+functions as an exercise to the interested reader :)</p>
+
+<h2>Grant Refactoring</h2>
+
+<p>This reminds me of a saying, I can't remember it exactly, but it is something
+about the best laid plans of camels and butterflies often taste like onions.
+Anyway, since I wrote my grant, the Parrot Embed API was deprecated and replaced
+with a shinier and better documented system. After talking with cotto++ and
+whiteknight++ on IRC, it was decided that working on test coverage for the new
+embed API was a better use of resources than writing tests for the old embed
+API that my original grant referred to, which will most likely be removed from
+Parrot soon.</p>
+
+<p>The new embed API is called <a href="https://github.com/parrot/parrot/blob/master/src/embed/api.c">src/embed/api.c</a>
+and the plan is to replace my grant milestone of 95% coverage of embed.c with 95% coverage
+of embed/api.c, which is currently at <a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-embed-api-c.html">72%</a> coverage.</p>
+
+<p>To summarize, I have two grant milestones left, increasing extend.c (currently
+at <a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend-c.html">61%</a> )
+and embed/api.c to 95% coverage.</p>
+
+<p>Given the lessons learned from testing extend_vtable and based on the fact that
+I have already <a href="https://github.com/parrot/parrot/commit/b59b869c9dd6f51109aa41e495082e09844ba348">made some
+headway</a>,
+my new estimate for these milestones is three weeks each. To make this more
+definite, I plan to be done with this grant work by July 15th.</p>
+
+<p>This is the home stretch! I can feel it in my bones.</p>
+<h1>Yet Another TPF Parrot Embed/Extend Grant Update</h1>
+
+<p>I am excited to announce that I have completed my next grant milestone! I
+recently increased test coverage of extend_vtable.c to over 95% (
+<a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend_vtable-c.html">95.5%</a> to be
+exact), achieving the milestone with a half percent buffer. It definitely
+wasn't easy, but I changed the way I was approaching writing tests and it
+resulted in a <a href="https://github.com/parrot/parrot/compare/5dd8c543ab...8c04cc3e66">huge burst of
+productivity</a>.</p>
+
+<p>I went through a test coverage report and wrote down, on an actual piece of
+<em>paper</em>, every function that had no test coverage. This allowed me to circle
+the functions that I thought would be easiest to write tests for, and quickly
+got those out of the way. I then went for uncovered functions that were similar
+to already covered functions, and then finally I got to the hard functions.</p>
+
+<p>This was a fruitful exercise, because it was decided by Parrot developers that
+some VTABLE functions escaped accidentally and that they should be removed from the public API.
+Whiteknight++ <a href="https://github.com/parrot/parrot/commit/cbfc76e64acf9f0a526b5f7da0e4c6c4ec0d1189">removed Parrot_PMC_destroy (extra points for humor)</a>, which I was using incorrectly in the
+extend_vtable tests and which was actually coredumping Parrot, but only on certain
+platforms. I then removed <a href="https://github.com/parrot/parrot/commit/cd1edef38c9f7d4af8ec3229fa166e4fe92d21f6">Parrot_PMC_mark</a> and <a href="https://github.com/parrot/parrot/commit/44a9634f2764ccccfd7a5cbad1552159fc73bff8">Parrot_PMC_invoke</a>, the first being
+an implementation detail of the garbage collector, and Parrot_PMC_invoke because
+it was the only function that returned a '''Parrot_Opcode_t*''' and basically
+not fit for public consumption.</p>
+
+<p>I also <a href="http://trac.parrot.org/parrot/ticket/2126">created a ticket (TT#2126)</a>
+for a bug in the Parrot_PMC_morph function, which
+has some possibly buggy but definitely unspecified behavior.</p>
+
+<p>The remaining, untested functions in extend_vtable are clone_pmc, cmp_pmc,
+get_pointer_keyed_int, get_pointer_keyed_str, remove_vtable_override,
+set_pointer_keyed and set_pointer_keyed_str. I leave the testing of these
+functions as an exercise to the interested reader :)</p>
+
+<h2>Grant Refactoring</h2>
+
+<p>This reminds me of a saying, I can't remember it exactly, but it is something
+about the best laid plans of camels and butterflies often taste like onions.
+Anyway, since I wrote my grant, the Parrot Embed API was deprecated and replaced
+with a shinier and better documented system. After talking with cotto++ and
+whiteknight++ on IRC, it was decided that working on test coverage for the new
+embed API was a better use of resources than writing tests for the old embed
+API that my original grant referred to, which will most likely be removed from
+Parrot soon.</p>
+
+<p>The new embed API is called <a href="https://github.com/parrot/parrot/blob/master/src/embed/api.c">src/embed/api.c</a>
+and the plan is to replace my grant milestone of 95% coverage of embed.c with 95% coverage
+of embed/api.c, which is currently at <a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-embed-api-c.html">72%</a> coverage.</p>
+
+<p>To summarize, I have two grant milestones left, increasing extend.c (currently
+at <a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend-c.html">61%</a> )
+and embed/api.c to 95% coverage.</p>
+
+<p>Given the lessons learned from testing extend_vtable and based on the fact that
+I have already <a href="https://github.com/parrot/parrot/commit/b59b869c9dd6f51109aa41e495082e09844ba348">made some
+headway</a>,
+my new estimate for these milestones is three weeks each. To make this more
+definite, I plan to be done with this grant work by July 15th.</p>
+
+<p>This is the home stretch! I can feel it in my bones.</p>
View
149 blog_posts/tpf/TPF_grant_update_7.md.html
@@ -0,0 +1,149 @@
+<h1>A Final TPF Parrot Embed/Extend Grant Update</h1>
+
+<h2>Really TLDR: The Parrot has landed.</h2>
+
+<p>It brings me great joy to announce that I have completed all milestones for my
+grant regarding the Parrot Embed/Extend subsystems.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<h2>The Deets</h2>
+
+<p>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.</p>
+
+<p>Whiteknight++ greatly helped me write a test for Parrot<em>sub</em>from_c XXX which
+does YYY.</p>
+
+<p>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.</p>
+
+<h3>Lesson 1</h3>
+
+<p>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.</p>
+
+<p>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 XXX, 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.</p>
+
+<p>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.</p>
+
+<h3>Lesson 2</h3>
+
+<p>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.</p>
+
+<h3>Lesson 3</h3>
+
+<p>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.</p>
+
+<p>I theorize that pi is the factor of time it takes to debug and write tests for
+behavior of hard-to-recreate edge cases.</p>
+
+<p>I originally thought my grant would take about 3 months, but it ended up taking about
+9 or ten. QED.</p>
+
+<p>Finally, I would like to thank my grant manager Makamoto XXXX for providing
+lots of feedback, support and encouragement, as well as everyone else at the
+The Perl Foundation for funding this grant.</p>
+<h1>A Final TPF Parrot Embed/Extend Grant Update</h1>
+
+<h2>Really TLDR: The Parrot has landed.</h2>
+
+<p>It brings me great joy to announce that I have completed all milestones for my
+<a href="http://perlfoundation.org">TPF</a> [grant regarding the Parrot Embed/Extend subsystems]
+(http://news.perlfoundation.org/2010/11/2010q4-grant-proposal-improve.html)!
+Not only that, but all of my grant work was included in the most recent release of
+Parrot, <a href="http://parrot.org/news/2011/Parrot-3.5.0">3.5.0 "Menelaus"</a>.</p>
+
+<p>The actual TLDR of this update is "many tests were written, code coverage is
+above <a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-embed-api-c.html">95%</a>
+<a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend-c.html">for all</a>
+<a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend_vtable-c.html">systems described</a>
+in the grant, docs were improved, many
+Parrot Trac tickets were created and <a href="http://leto.net/dukeleto.pl/2010/12/parrot-embed-grant-update-1.html">many</a> <a href="http://leto.net/dukeleto.pl/2011/01/parrot-embed-grant-update-2.html">a</a> <a href="http://leto.net/dukeleto.pl/2011/02/parrot-embed-grant-update-3-now-with-dragons.html">blarg</a> <a href="http://leto.net/perl/2011/04/parrot-embed-grant-update-4-the-journey-continues.html">toast</a> <a href="http://leto.net/dukeleto.pl/2011/04/parrot-embed-grant-update-5-zen-pebbles.html">was</a> <a href="http://leto.net/dukeleto.pl/2011/05/parrot-embed-grant-update-6-still-hackin-less-slackin.html">cooked</a>.</p>
+
+<p>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.</p>
+
+<h2>The Deets</h2>
+
+<p>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.</p>
+
+<p><a href="http://whiteknight.blogspot.com">Whiteknight++</a> greatly helped me write a test for <a href="https://github.com/parrot/parrot/blob/master/src/extend.c#L700">Parrot<em>sub</em>new<em>from</em>c_func</a> which
+takes a C function and a string that describes the function signature of the C
+function and returns a <a href="https://github.com/parrot/parrot/blob/master/src/pmc/nci.pmc">NCI PMC</a>, which can be invoked.</p>
+
+<p>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.</p>
+
+<h3>Lesson 1</h3>
+
+<p>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 <a href="https://secure.wikimedia.org/wikipedia/en/wiki/Ender's_Game">Ender's
+Game</a>: continually inventing new tactics to keep a winning edge over the
+competition.</p>
+
+<p>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 <a href="https://github.com/parrot/parrot/blob/master/src/extend.c#L331">POP_CONTEXT</a>, 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.</p>
+
+<p>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.</p>
+
+<h3>Lesson 2</h3>
+
+<p>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.</p>
+
+<h3>Lesson 3</h3>
+
+<p>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.</p>
+
+<p>I theorize that pi is the factor of time it takes to debug and write tests for
+behavior of hard-to-recreate edge cases.</p>
+
+<p>I originally thought my grant would take about 3 months, but it ended up taking about
+9 or ten. QED.</p>
+
+<p>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.</p>

0 comments on commit adc7dff

Please sign in to comment.
Something went wrong with that request. Please try again.