martinjevans's blog

Perl's PERL_UNICODE and failing tests

Increasingly I'm seeing reports of modules failing (e.g., t/test_autoencoding_conversion.t fails and Gofer test failures with PERL_UNICODE=AS and PERL_UNICODE and smokes) when PERL_UNICODE is set - I see others saying much the same thing and apparently eve

Unicode discussion on Perl dbi-dev mailing list

I use unicode data with DBD::Oracle and DBD::ODBC and don't have any issues with either of those DBDs although it appears others may have. I don't use Postgres or MySQL any more (well not really and certainly not with unicode) and it appears each DBD handles unicode data a little differently. If you have an interest in unicode support in DBI/DBDs and think you have some worthwhile input you might want to watch this thread in dbi-dev.

Faster HTTP usage

What module do you use when doing any kind of HTTP programming - LWP? By far the most popular module for the HTTP protocol in Perl and one which just works and works well with a minimal amount of application code. Now you might be put off by the 123 bug reports in the LWP rt queue but in all my time I've never hit one myself - other than an issue which was not LWP but Perl and to do with tainted data used with LWP (see Why is taint mode so slow?).

Problems building a compatible Perl DBD::ODBC with unixODBC driver manager on 64 bit UNIX platforms

I maintian DBD::ODBC but I am wrestling with problems coping with 64 bit platforms. The problem is rather complex but I'm hoping that by describing it here someone will help come up with a logical answer to at least stop DBD::ODBC building in circumstances which are suspect.

DBD::ODBC 1.31 release

I have just uploaded DBD::ODBC 1.31 to pause. This is the culmination of 7 development releases and I thought it was time to do an official release. Due to personal issues I am unlikely to be doing another update to DBD::ODBC in the near future but if you find issues please report them on RT and I'll try my best. The changes since 1.29 are below. There are significant changes since the last official release and a few changes in behaviour. If you didn't test a development release and it now goes wrong I'm sorry but after 7 development releases you had your chance.

Is my new Nikon D3100 broken? too dark warnings in bright light

I've recently stepped up from a bridge camera (a Panasonic Lumix) to a Nikon D3100 DSLR. I like the camera in general but one issue is bothering me a lot and it is the exposure metering and a too dark warning.

Switching to Data::Dump from Data::Dumper for some projects

Like many people I've used the Perl module Data::Dumper for years and been reasonably happy with the output. Generally I want the output rolled up into the smallest (line-wise) output and Data::Dumper allows this. However, I use Math::FixedPrecision quite a bit in this project and as it is a blessed object the fixed precision numbers of 2 come out ridiculously verbose and almost unreadable.

DBD::ODBC 1.30_6 is released - please test

I've just released DBD::ODBC 1.30_6 to CPAN. This is the culmination of 3 months of changes through 1.30_1 to 1.30_6 and also contains a few changes in behaviour (you are warned). It is unlikely that I will get much chance to do anything with DBD::ODBC for the next few months so I really need feedback before this becomes 1.31. Here is a list of changes since 1.29:
  1. Changes in DBD::ODBC 1.30_6 June 4, 2011
    • [BUG FIXES]

The Perl Community, thank you

I've been using Perl on and off for over 15 years. In the last 10 years of so I've been using Perl a lot in my work and play. I don't have a huge list of modules I look after but I maintain a couple of modules and contribute to many. What never ceases to amaze me is the Perl community. By that I mean the huge group of people working tirelessly to improve the Perl core, write Perl modules and applications, organise conferences and workshops, test Perl and CPAN, report issues, support Perl on IRC, the many mailing lists and web sites and give freely their knowledge and expertise to others. Thank you.

Building DBD::ODBC against unixODBC on 64 bit platforms

A word of warning. The build process for DBD::ODBC against unixODBC on 64 bit platforms may not produce a workable solution perhaps even segfaulting. The short reason is that few Linux distributions/packages of unixODBC are up to date and few distribute unixODBC's odbc_config which DBD::ODBC needs to ascertain the compiler defines required to build a DBI driver which matches unixODBC. The long answer which which includes a workaround follows.

Some background:

Syndicate content