GSoC Status Update

Skip to first unread message

Marc Green

Aug 15, 2011, 10:00:20 PM8/15/11

I got a *bunch* of stuff done this past week, but not everything I wanted to.

Things I got done:

- implement different warning levels in Pod::Checker (P::C, for shorthand)
- test P::C's interface (e.g., $pc->node())
- update P::C's documentation to reflect reworded, added, and deleted checks
- test the podchecker cli
- ask pod-people their opinion on particular error checks*
- submit small bug in Pod::Escapes (used to resolve E<> fcodes) to rt
- document 'fake-closer' attribute passed to end_event_handlers if Pod::Simple (P::S) did not find a real closing directive (e.g., "=end")**
- implement, document, and test 'whiteline_handler' P::S attribute, which takes a subroutine to handle POD lines that have only whitespace on them***
- add a TODO to P::S::Blackbox to correct E<> resolution based on the current =encoding
- fix a bug in P::S inhibiting =begin blocks in =over blocks
- send pull requests for all my edits to Pod::Simple and friends

* - I ended up not implementing the error check "argumentless =item", as I do not think anyone thought it was necessary, and I ended up switching the error check "=itemless =over/=back block" for "empty =over/=back block", as the former is not an error.

** - The 'fake-closer' attribute allowed me to implement the error check "no closing directive for =begin/=over", as Pod::Simple automatically closes unclosed blocks before triggering the appropriate event so I needed more information to know if there was in fact a closing directive.

*** - 'whiteline_handler' allowed me to implement the error check "whitespace on seemingly blank line"

Things I did not get done:

- make P::C its own dist (away from Pod::Parser)
- go over all 'XXX's in Pod::Checker to see if I can remedy the TODOs
- double check that the new Pod::Checker is as good or better than the old, error checking wise (this will be time consuming)
- document what needs to be done for another module I wanted to convert this summer, Pod::Usage

The four items above are what I want to get done this next and final week. rjbs offered to help me with the minor stuff, like removing the 5.14isms I have been erroneously using, and I am very thankful for that.

Regarding Pod::Html: once all my pull requests for Pod::Simple are accepted (I need to fixup a few things in two of them) and the module is released and merged into blead, we can merge Pod::Html into blead and await tests and complaints.


Marc Green

Aug 24, 2011, 1:03:02 AM8/24/11
Hello everyone,

This is my last status update, as GSoC ended today (Monday, at the time of writing). [I am not able to send this out now because I do not have access to my email (well, to the Internet). I am going to send it out tomorrow or the day after.]

I believe my project has been successful, and I am positive my mentors would agree. That being said, I am *still* not done with neither Pod::Html nor Pod::Checker. Well, I am done with all the coding -- they're both in their final stages in that regard, but they are yet to be merged into core and tested (and complained about). I plan to see them through though, and I plan on being the maintainer for both of them if possible.

I was able to wrap up everything with Pod::Checker this week, so all I need to do is to clean up its commit history (which will get done within the next few days). Actually, that is a lie, I was not able to get everything wrapped up. There is one thing in particular that I did not get done: splitting Pod::Checker into Pod::Checker and Pod::Checker::Internals, the latter being-a Pod::Simple and the former having-a Pod::Checker::Internals. This split was conjured up in order to remove Pod::Simple from Pod::Checker's interface. However, as I just said, I was not able to do this. Instead, I added a warning in Pod::Checker's documentation explaining that no user should EVER use any aspect of Pod::Checker's interface that has to do with Pod::Simple unless it is documented. Perhaps this is a task that can be tackled by me or someone else in the future.

Oh, actually, my lie in the previous paragraph was a lie for another reason too. My mentor, rjbs, offered to do some grunt work on Pod::Checker for me so I could focus on the bigger stuff. These tasks include removing the 5.14isms I used throughout and making Pod::Checker its own dist (apart from Pod::Parser). These are not done yet, but him and I are going to remain in contact so that the new Pod::Checker can see the light of day.

Pod::Html shall also see the light of day. My second mentor, theory, released a new version of Pod::Simple which contains some new code I added to allow me to finish Pod::Html a while back. [At the time of writing this it might not be released, but he assured me it would be in the next few days, so I will take his word.] Now that it is released, I can rebase its commit history to remove some hacks that let me use the aforementioned new code. Pod::Html will then be merged into core and hopefully be a success.

I feel this has been a wonderful experience for me; my foot is in the Perl community door now, and I have gotten a taste of what it is like to contribute to an open source project. It has also been a great experience for the Perl community (I can imagine), as who doesn't like seemingly free, beneficial code. (Seemingly beneficial, perhaps.)

Thank you everyone who helped me this summer, in particular rjbs, theory, and rafl. I appreciate it!


Karl Williamson

Aug 24, 2011, 10:30:59 AM8/24/11
to Marc Green,,


Reply all
Reply to author
0 new messages