%C
token in ControlPath
. It produces a shorter string, so will help get around some path length restrictions. Also, that really ought not to be a path in a world-readable place like /tmp
!
]]>
It worked.
]]>If you want to generate reports from this, please be gentle!
]]>First, why the hell haven't you upgraded to something - anything! - else?
Second, I just released updated versions of Palm::SMS, Palm::Treo680MessagesDB, and Palm::TreoPhoneCallDB. Now they should build with a vaguely modern perl toolchain (in the case of Palm::SMS) and will work with a modern version of Palm::PDB, which appears to have mysteriously travelled back in time and gone from version 1.29 in 2002 to version 1.016 today.
]]>I am, of course, far too lazy to edit XML by hand, and I want something that will work in a terminal. I was surprised that I couldn't find anything like this. Well, I could. It was 1300 lines of PHP. I've not got anything against PHP, but 1300 lines of code for such a simple task? Really?
Here's my version. Tell it a source directory, a target directory, and the address of that directory in HTTP-land, and Bob's yer uncle.
]]>As I mentioned then, we ran all our tests under Jenkins. Because we're testing quite a complex application, which needs configuration data, databases and so on, we've got a wrapper script that sets up all that jibber-jabber, runs the tests, and then tears down the temporary databases and stuff that it created. But that script had a bug. Under some circumstances, if one of the test scripts failed, the wrapper script would eventually exit with status 0, which is the Unix-ism for "everything went as expected", and so Jenkins would say "all the tests passed, hurrah". We need it to exit with a non-zero status if anything went wrong so that Jenkins will know that it needs to kick up a fuss.
Oops. It's something that's come up a couple of times - we've found it was broken, fixed it after some time of getting erroneous results from Jenkins, then later broken it again when we updated the wrapper script to make it do more stuff, got loads of erroneous reports, fixed it again ...
So now I've written a script that tests that the script that runs the tests has the correct return value. Hopefully this will make any errors more obvious as we'll see a "not ok" on our dev machines before ever sending a broken testing wrapper to Jenkins.
The only question remaining is whether I should write tests for the script that tests that the script that runs the tests is ok.
And ... diagram that previous sentence, I dare you :-)
]]>The change was well-publicised in advance, with a fairly long deprecation cycle. But I just never had the tuits to make the changes I needed, and so eventually that part of CPANdeps just stopped updating. It was still reporting dependencies OK, but didn't have any pass/fail data after a particular date.
Well, I'm pleased to say that it's back. Most of the work was actually done by Andreas König, whose script I am using as a shim to import data into the database that the rest of my code expects. I've also made a few other tiny changes which most of you won't notice, and also made the scripts that build the site rather more efficient so that they won't hammer search.cpan.org so hard when populating the site's metadata cache.
Next on my to-do list is to make the same fix to cpXXXan.
]]>It turns out that unreachable code doesn't necessarily produce warnings from Apple-ish compilers like I expected it to. It turns out that in gcc the -Wunreachable-code option doesn't do anything. It's only there because it used to do something but that functionality was removed because it didn't work very well. In Clang, -Wunreachable-code is functional, but isn't enabled under -Wall. All apparently doesn't mean all in Clang-land.
I consider both of these to be compiler bugs.
All the other points I made still hold though, especially the most important one about unit testing and code coverage in tests.]]>