> ... 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
>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 MacPer
On Wed, Aug 18, 2004 at 03:34:11PM -0500, [EMAIL PROTECTED] wrote:
> MARC::Field->as_string() takes a string of subfields rather than an array.
> It would be better for as_string() and delete_subfields() to have the same
> interface. Since as_string() is used a lot in production,
> delete_subfield
On Wed, Aug 18, 2004 at 03:34:11PM -0500, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> MARC::Field->as_string() takes a string of subfields rather than an array.
> It would be better for as_string() and delete_subfields() to have the same
> interface. Since as_string() is used a lot in productio
MARC::Field->as_string() takes a string of subfields rather than an array.
It would be better for as_string() and delete_subfields() to have the same
interface. Since as_string() is used a lot in production,
delete_subfields() should be the one to change.
Mike O'Regan
On Wed, Aug 18, 2004 at 12:56:17PM -0500, Bryan Baldus wrote:
> Ok, I'll try to provide a test file. However, since I've been using MacPerl
> (and Windows), I don't usually deal with test files (the usual
> perl Makefile.PL
>make
>make test
>make install
> doesn't usually work for me,
I have been informed that this is a Voyager ILMS Z39.50 server bug. (Thanks
Sandy!)
Sorry for the false alarm... didn't mean to cast any aspersions on
Net::Z3950!
-- Michael
> -Original Message-
> From: Michael D Doran
> Sent: Wednesday, August 18, 2004 11:23 AM
> To: '[EMAIL PROTECTED
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 in
Please excuse the cross-posting (perl4lib & Net-z3950).
I am working with a Perl script designed to query our catalog via Net::Z3950
and retrieve a journal record. The OPAC record syntax is specified because
the ultimate point of the script [1] is to parse the journal holdings to
determine if a p
> 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::USMAR
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
11 matches
Mail list logo
