RE: Warnings during decode() of raw MARC
From: Bryan Baldus [mailto:[EMAIL PROTECTED] Sent: 18 August, 2004 09:24 Subject: Warnings during decode() of raw MARC I'm probably missing something obvious, but I have been unsuccessful in trying to capture the warnings reported by MARC::Record that are set by MARC::File::USMARC-decode(). Is there a simple way to store the warnings reported during the decode() process (using a MARC::Record or MARC::Batch object)? How about this technique: #!perl package main; sub out { print STDERR ERR: Error 1\n; print STDERR ERR: Error 2\n; print STDERR ERR: Error 3\n; return; } sub main { my @errs = (); open SAVERR, STDERR; open STDERR, errors.txt; open GETERR, errors.txt; main::out; while (GETERR) { push(@errs,$_); } close(GETERR); open STDERR, SAVERR; print STDOUT scalar(@errs),\n; return 0; } exit main::main;
Re: Warnings during decode() of raw MARC
On Wed, Aug 18, 2004 at 08:23:59AM -0500, Bryan Baldus wrote: Both seem to fail to capture the warnings reported by MARC::File::USMARC. There appears to be a bug in MARC::Batch::next() code at line 123 which extracts the warnings from the newly instantiated MARC::Record object and stuffs them into the MARC::Batch object so that they are available at that level. my @warnings = $rec-warnings(); The bug is that calling warnings() clears the warnings storage in the MARC::Record object as a side effect. MARC::Batch should probably side step calling warnings() and dig into the object directly...or there should be another method that doesn't zap the storage. Let me see if I can duplicate this problem in a test, and then see if the fix actually works. If you can provide a .t file for the MARC::Record distribution that would be handy too :-) //Ed
RE: Warnings during decode() of raw MARC
How do you typically do the install? MARC::Record is included at the ActiveState PPM Repository, so it should do these things on a Windows platform...assuming nmake or some sort of make variant is being used. At home (on the Mac), I just drop the MARC folder in my site_lib folder in the MacPerl folder (MacPerl adds site_perl to @INC automatically, I believe). This is after I expand the tar.gz files with Stuffit Expander. There used to be an installer.pl for Mac, but it no longer works with the current version of MacPerl (5.8.0a). Since the documentation in MacPerl seems to indicate that it is not compatible with MakeMaker?, drag-drop installation seems to be the easiest alternative. To convert line endings, I use either BBEdit Lite, a 3rd party program, or a script I just wrote that should convert line endings and change the Type and Creator (to TEXT and BBEdit). In Windows, I take the folder from home, convert the line endings from Mac to DOS, and then drop the MARC folder in C:\Perl\site\lib\. This (dragging and dropping) seems to work fine for most stand-alone modules (where a C compiler is not needed). In some cases, I do look at the Makefile.PL, for example with MARC::Charset where it was necessary to create a database file of EastAsian character sets. Of course, once I got that installed (through drag-dropping), it gave a number of errors (when I ran the tests), probably because of my operating system (MacOS 9.2.2) not working well with Unicode? I do generally try running each of the test files when I first install a new module, just to make sure they work ok, but I've not usually bothered to look at how the tests or the Makefile.PL work. This is one reason I haven't tried to distribute my modules through CPAN. Bryan Baldus http://home.inwave.com/eija/ (http://home.inwave.com/eija/readme.htm)
Re: Warnings during decode() of raw MARC
... I've not usually bothered to look at how the tests or the Makefile.PL work. This is one reason I haven't tried to distribute my modules through CPAN. What no OS X yet!? The drag and drop trick is what you are stuck with in MacPerl, and it's kind of a testament to Perl's flexibility that you can even do this. However you should consider getting your stuff into the CPAN cookie cutter mold if you have the time and energy. Understanding ExtUtils::MakeMaker is not necessary (in fact that way lies madness), but understanding the little that you have to do to get a distribution together is worth the effort. This way you don't have to distribute the code yourself and it is made available at hundreds of mirrors around the world; plus you benefit from the CPAN tools at large: documentation [1], ticketing [2] and testing [3] (among others). Even if you don't send your code to CPAN for the rest of the world to enjoy, you can benefit from having installers for your code. Installers come in handy when you need to migrate your code to a new machine, or when recovering from a failure of some kind [knock on wood]. In general, bundling your code up into installable packages encourages you to think of your software in terms of units of functionality (modules), instead of one big mass of interrelated scripts. Sam Tregar has a book on writing CPAN modules which is a great place to start learning about CPAN if you are interested [4]. //Ed [1] http://search.cpan.org [2] http//rt.cpan.org [3] http://testers.cpan.org/ [4] http://sam.tregar.com/book.html