warnings and errors in the realm of XS

ethan on 2003-04-10T07:57:05

I continued with implementing the driver-infrastructure of AA-Lib after the nice folks on the perl-xs list told me how to best deal with pointers to C-functions and Perl code-references.

During that I again realized how the errors one gets when doing XS never cease to amaze me. One of the problems with them is that the line numbers of course refer to the Perl code that called the XS-functions and not to the actual part of the XS file. So this:

... my $driver = AALib::Driver::Mouse->new( -name => "custom", -shortname => "ctm", -init => sub { 1 }, -uninit => sub { print "@_" }, );

print $driver->_function("asdkj"); # line 18


might become that:

Bizarre copy of HASH in print at 3.pl line 18.

Nedless to say: line 18 calls about 200 lines of XS (most of them incidentally involving hash manipulation) so finding the cause for that is non-trivial.

Another dreadful warning is

Unitialized value in subroutine entry at...

It can happen even when every subroutine entry is in fact initialized. In my case it was quite the opposite: It turned out to be an uninitialized value that I returned from a subroutine unknowingly.

I wish there was a compilation flag that enabled perl to report errors XS-wise. Currenty not even the C debugger is a big help because it'd require you to step through large Perl types and try to spot an inconsistency.

But other than these slight annoyances, AA-Lib turns out to be real fun which is partly due to the innards of XS: They might not be beautiful or extremely self-explanatory, but they are extremely flexible.

And while I write all that, I am trying to track down a particular MP3 that must be somewhere on my harddrive. I usually know each and every MP3 I have (and have them even properly tagged). But some weeks ago a fried of mine gave me a CD full of balkanian music (he is Croatian) that I dropped in a subdirectory below /mp3. After hitting a couple of hundred times '>' in my mp3-player to skip through the tracks I finally found it: Try to track down a particular song if it has the filename /mp3/_various_/ExYU/Punk - Rap - Alternative/Zabranjeno Pusenje/Devojcice kojima mirise koza.mp3. I really need to get things into order again so I started setting the id3-comment to 'Keep!' of those MP3s I intend to, well, keep. In a couple of weeks these 400-ish songs should all be tagged and I can write a little Perl script that involves File::Find and one of the id3-tagging modules to delete all songs in the ExYU/ directory that do not have the 'Keep!' comment.


MP3 Tagging

barbie on 2003-04-10T08:54:01

In a couple of weeks these 400-ish songs should all be tagged and I can write a little Perl script that involves File::Find and one of the id3-tagging modules to delete all songs in the ExYU/ directory that do not have the 'Keep!' comment.

Have a look at File::Find::Rule and File::Find::Rule::MP3Info . I use these alot to search for and update my mp3s. I have a set of scripts that prepare mp3s for burning, including creating m3u files too. These two little modules help the whole process as I don't have to keep checking every single file for awkward filenames (eg really long names) and bad tags (eg blank entries).

Re:MP3 Tagging

ethan on 2003-04-10T09:44:19

I didn't know of File::Find::Rule::MP3Info. That looks very sweet for such a kind of task! :-) I first thought of using my own MP3::Mplib just to see it in the wild. But then I am rewriting this module from scratch anyway so there is no need to test a dead horse.