Been reddited
Been very busy with work lately so it nearly slipped completely past me that I had a large spike in traffic to this blog last week with over 1200+ unique hits on one day.
The culprit: Reddit (Programming). My post Anyone for Perl 6 metaprogramming? had been posted there .
My first blog entry to make reddit *blush*
Glad it created enough stir, comments & even points (29 in total… 59 up & 30 down!). Unfortunately some of the commenters didn’t follow link on my page to previous post and so didn’t understand the full context (only 17 of the 1200+ reddit surge actually did click the said link).
Apart from quick scans to see if anything interesting is on Perl Reddit, I don’t go to Reddit anymore. I much prefer Hacker News. In fact its been so long that I couldn’t remember what my password was so I gave up even trying to leave a comment on the Reddit post 🙂
/I3az/
Update: Gosh I also nearly missed that it had been posted to Hacker News only few days later as well!
Update 2: Things go from weird to bizarre. You can now buy a T-shirt with my post title 🙂
First reported bug for one of my CPAN modules
It should invoke some trepidation when seeing the first ever reported bug hitting your inbox. However it was the complete opposite because I got a nice warm feeling about the fact that something I’ve written is being used in the wild.
Still the bug(s) needs fixing and its understandable that prolific CPAN / opensource authors may get bogged down having to find time to fix bugs in heavily used projects.
Fortunate for me I only have a few CPAN modules at this time and I doubt they’re heavily used! Even more lucky that in this case the bug was only related to testing on Windows.
So if you’ve written software then you have bugs! Thus you need a good issue tracking system to keep a handle on things. Luckily CPAN comes with its own Request Tracker (RT) from Best Practical. My first reported bug came via this last week.
You can change your CPAN module page to point to any other issue tracker should you wish this (see part about amending your meta tag and also my old post on repo link). But I’m more than happy to go with RT and there maybe good reasons for doing this because it maybe better integrated into the CPAN toolchain (my PAUSE login worked with RT).
BTW, my testing with Windows issue is the usual pathname and EOL delimiter differences. Just because it leaves your box with 100% passes it would be silly to expect it arrives at someone else’s box the same 🙂
/I3az/
PS. Related references:
Nearly famous on Github!
After reading about Tatsuhiko Miyagawa well deserved accolade for being famous on github, I thought I better check my own vanity score 🙂
I was a little shocked to see i am listed in San Francisco list? Though no surprises to see I’m in the bottom bunch with score of 0.0 on that list!
But i am relieved to see i do appear in the London list and indeed pretty chuffed to see i reached a respectable position of 155 with a github “social score” of 688.949686387002
Well done to Miyagawa and all those other Perl mongers who continue keep the Perl flag flying high on Github.
/I3az/
refs:
Perl and Mac OS X versions
Apple website has an opensource page: http://www.opensource.apple.com/, which lists all its products and components which have and use opensource technology.
If you go here: http://www.apple.com/opensource/, it provides a complete list of opensource projects that Apple uses.
In this list is of course Perl. From this we can see which version of Perl was compiled on Mac OS X. We can also see what options, patches, fixes & extra modules were included.
So I’ve been able to glean these Perl versions that Apple have used with Mac OS X:
- 5.10.0 & 5.8.9 (perl-63)
- 5.8.8 (perl-51 patches: perl-51.1.1, perl-51.1.4)
- 5.8.6 (perl-38 patch: perl-38.1)
- 5.8.6 (perl-35 patch: perl-35.1.1)
- 5.8.4 (perl-28.2)
- 5.8.1-RC3 (perl-25.2)
- 5.8.1 (perl-24.1) “Maintenance release working toward v5.8.1”
- 5.6.0 (perl-21)
- 5.6.0 (perl-17)
Now which one(s) are tied to which Mac OS X is still in the air a bit! This is my best stab at it:
10.6 5.10.0 & 5.8.9 perl-63 10.5 5.8.8 perl-51 10.4 5.8.6 perl-38 or perl-35 10.3 5.8.4 or 5.8.1 ? 10.2 5.8.1 ? 10.1 5.6.0 ? perl-21 and/or perl-17 10.0 5.6.0 ?
Hopefully this information is useful to someone
/I3az/
refs:
Mac OS X “Snow Leopard” (10.6) and Perl
Snow Leopard ships with multiple versions of Perl:
- 5.10.0 (64 bit)
- 5.10.0 (32 bit)
- 5.8.9 (32 bit)
The default Perl is 5.10.0 (64 bit). However you can change this to 32-bit Perl by setting the following ENV shell variable:
export VERSIONER_PERL_PREFER_32_BIT=yes
And to switch to 5.8.9 all you need is this ENV variable set:
export VERSIONER_PERL_VERSION=5.8.9
Instead of setting these ENV variables in your Terminal sessions you can also make the change to the systems defaults:
- defaults write com.apple.versioner.perl Prefer-32-Bit -bool yes
- defaults write com.apple.versioner.perl Version 5.8.9
This is a interesting move by Apple and something which may come in very handy in the future.
As it stands at this moment though you probably want 5.10.1 (and beyond) because of issues with 5.10.0. So you will probably be looking down the compiling route anyway. Still it does give the future option of a local::lib possibility with the pre-installed Perl provided by Apple.
NB. I always recommend that you avoid installing modules with CPAN (shell) on OS provided Perl. Always stick to the OS provided package installer to update Perl & modules (which unfortunately for Mac’s means “zilch” 😦 Apple “Software Updater” may update Perl itself but no extra modules are provided above what Apple provides on top of core Perl)
/I3az/
References:
Receiving contributions to your Github project
Received my first ever contribution to one of my Github projects today. A pull request from a cpanservice? And I wasn’t the only one or was wondering who this cpanservice is or was?
I suspect that this as something to do with the recent gitPAN upload to Github and therefore is probably some automated service that is going through related projects making sure that Github CPAN projects do have the meta repository tag populated in the build process.
NB. I blogged about this repository link back in May but forgot to put my changes live. *blush*
This contribution was the necessary nudge I needed to find out how to use git to merge in external changes. Github itself did seem to provide a web option to apply this change directly under “Fork Queue”. However I wanted to do it all via git so first place I looked is the Github documention on pull requests.
My local directory was up-to-date so I just needed to do the following to pull & merge into my code:
git pull git://github.com/cpanservice/builder.git master
All merged and committed (see PS). Quick check of diffs & logs and then just needed to populate it back to Github:
git push origin master
You will see cpanservice changes immediately in the commits. However the Github graphs and fork queue take a little while to be updated to show the merge.
/I3az/
PS. The merged cpanservice changes showed up under me in the network graph (see red line below) despite showing up correctly under commits.
I think this is because I merge changes locally and then pushed back to Github? Its not an issue for these cpanservice changes but I would like to get it right for “proper” contributors.
So I think the alternate merge example documented by Github might be the better approach?
git remote add defunkt git://github.com/defunkt/grit.git
git fetch defunkt
git merge defunkt/master
Couple of CPAN pressies
Just uploaded a couple of new modules to CPAN:
The first one you is just a small xmas cracker that you will already know about from my “bare URL” post from last week. Just pull, enjoy for a little while and then chuck away like most xmas cracker toys 🙂
The second one is a tad similar (ie. Devel::Declare) but with a much more sympathetic syntax by allowing you to create new Quote-Like Operators in Perl with Perl.
For a good end product exemplar have a look at PerlX::QuoteOperator::URL included with the distribution:
use PerlX::QuoteOperator::URL 'qh'; my $content = qh{ https://transfixedbutnotdead.com/ };
There is no scary parsing going on with this example. PerlX::QuoteOperator / Devel::Declare simply hits the ‘qh’ keyword and converts it to:
qh qq{ https://transfixedbutnotdead.com/ }
And ‘qh’ is a subroutine with a ($) prototype. So nothing too sinister (unless you really do abhor subroutine prototypes!), just a simple macro which gives the appearance that we have new quote-like operators.
Certainly an interesting concept to be able to produce new quote-like operators in Perl. So hopefully PerlX::QuoteOperator might find its way under a few xmas trees 🙂
Merry Xmas & happy St. Stephen’s day to everyone.
/I3az/
PS. I chose the PerlX::* because gugod as already provided some wonderful Devel::Declare Perl extending modules under this namespace. I feel its in the same vein so hopefully a good place for it to live.
Contributing to a project on Github
After getting my head into Devel::Declare::Context::Simple to create the bare URL for my last blog post
I realised that I’ve percolated enough knowledge about the module that it would be a good idea to redirect it back to the project by at least doing the POD.
This will be the first time I’ve “properly” contributed in some form to an opensource project (“properly” being via source control management & a patch).
Devel::Declare is hosted on Github here. And the process to contribute back changes to a Github project is “forking” simple!
With Git & Github its all about forking. Here is a concise Github howto (which I’ll regurgitate below with my own slant & spiel!).
I only use Git for my Github projects, so forking etc is all new to me. To break it down into a few simple steps the process to contribute would be:
- Fork project
- Clone your fork
- Make your changes
- Push changes back to you fork
- Send pull request back to original project
Here are the minutiae steps I went through for Devel::Declare:
- Went to Devel::Declare project on Github and forked it.
- Forked project now appears in my project list.
- Cloned my forked Devel::Declare (use “Your Clone URL” copy/paste)
git clone git@github.com:draegtun/devel-declare.git
cd devel-declare/
- Linked my forked project to original
git remote add upstream git://github.com/rafl/devel-declare.git
git fetch upstream
- Make my changes to project
- Run tests (in case I did something stupid!)
perl Makefile.PL
make
make test
- Clear down build once happy
make realclean
- Push my changes back to my fork
git commit -a -m "Documentation added to D::D::Context::Simple + examples directory"
git push origin master
Now on Github the changes can be seen in my fork
All I do now is click the “pull request” button and off went a request of my changes to rafl. Fingers cross my documentation changes were good enough to be accepted.
So I’m no longer a virgin to contributing to this opensource malarky 🙂
/I3az/