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.
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 🙂
PS. Related references:
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
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
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:
And to switch to 5.8.9 all you need is this ENV variable set:
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)
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.
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