[26064] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 8269 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 22 18:05:19 2005

Date: Fri, 22 Jul 2005 15:05:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Fri, 22 Jul 2005     Volume: 10 Number: 8269

Today's topics:
        buffering between tied file handle "layers" <bugbear@trim_papermule.co.uk_trim>
    Re: Error.pm and try/catch/throw <tadmc@augustmail.com>
    Re: Error.pm and try/catch/throw <richard@zync.co.uk>
    Re: Error.pm and try/catch/throw <BLOCKSPAMfishfry@your-mailbox.com>
    Re: Regex (?(?{CODE})) has too many branches <spam-block-@-SEE-MY-SIG.com>
    Re: Regex (?(?{CODE})) has too many branches <spam-block-@-SEE-MY-SIG.com>
    Re: Regex (?(?{CODE})) has too many branches <abigail@abigail.nl>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 22 Jul 2005 15:49:27 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: buffering between tied file handle "layers"
Message-Id: <42e10777$0$3495$ed2619ec@ptn-nntp-reader01.plus.net>

I have successfully implement a number of tied
filehandle classes, using the knowledge given me
in a recent thread (thanks to all).

Each tied filehandle is also given an input filehandle,
allowing the building up of useful processing chains.

I only have 1 small problem.

The various layers mainly perform byte at a time
processing, and the call overhead is very high.

The simple answer (it occurs to me) is to havew
yet another layer, providing non data transforming
buffering between the layers.

This would seem less intrusive than making
each layer do its own buffering.

(in particular, it would allow layers that
already work in large batches to avoid
further redundant buffering).

Has anyone done this, or (a fine source of
inspiration) implemented conventional buffered
IO in perl?

    BugBear


------------------------------

Date: Fri, 22 Jul 2005 06:14:08 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Error.pm and try/catch/throw
Message-Id: <slrnde1l80.gk2.tadmc@magna.augustmail.com>

fishfry <BLOCKSPAMfishfry@your-mailbox.com> wrote:


> No responses?


Maybe potential responders have decided to keep their attitude to
themselves, as you have requested in the past?


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: Fri, 22 Jul 2005 13:00:21 GMT
From: Richard Gration <richard@zync.co.uk>
Subject: Re: Error.pm and try/catch/throw
Message-Id: <pan.2005.07.22.13.00.21.438492@zync.co.uk>

On Thu, 21 Jul 2005 19:08:50 -0700, fishfry wrote:

> In article
> <BLOCKSPAMfishfry-D36AD2.22540220072005@comcast.dca.giganews.com>,
>  fishfry <BLOCKSPAMfishfry@your-mailbox.com> wrote:
> 
>> Is Error.pm the standard way to do error handling these days? Or at
>> least *a* standard way?
>> 
>> Are there any standard or popular libraries of exceptions, or should I
>> just write my own Error.pm subclasses?
> 
> No responses? I was just curious to know what kind of error handling
> people do. It seems to me that the try/catch/throw method is an
> improvement to the old days of checking error returns and trying to pass
> the right amount of error detail info upstairs to callers. I know how to
> use eval and die handlers.
> 
> Do most serious Perl programmers use one method or another of handling
> errors, and if so, what?

I use eval and a custom error object. The main problem I have with this is
that the eval is at the top level and so any module error messages which
don't provide a line number in the caller (as is the case with
DBD::Sybase) can be difficult to trace. Otherwise it works well. I define
some error codes in my Error object and trapping specific errors can be as
simple as

die MyApp::Error->new(<errorcode>) unless (...);

Also unforseen errors get trapped by the eval. $@ is a string not an
object when that happens, but is easily remedied.

Rich

-- 
"...Then anyone who leaves behind him a written manual, and likewise
anyone who receives it, in the belief that such writing will be clear and
certain, must be exceedingly simple-minded..."
	-- Plato, _Phaedrus_



------------------------------

Date: Fri, 22 Jul 2005 09:18:26 -0700
From: fishfry <BLOCKSPAMfishfry@your-mailbox.com>
Subject: Re: Error.pm and try/catch/throw
Message-Id: <BLOCKSPAMfishfry-37E2A8.09182622072005@comcast.dca.giganews.com>

In article <slrnde1l80.gk2.tadmc@magna.augustmail.com>,
 Tad McClellan <tadmc@augustmail.com> wrote:

> fishfry <BLOCKSPAMfishfry@your-mailbox.com> wrote:
> 
> 
> > No responses?
> 
> 
> Maybe potential responders have decided to keep their attitude to
> themselves, as you have requested in the past?

Thanks Tad.


------------------------------

Date: Thu, 21 Jul 2005 22:08:31 +0100
From: James Taylor <spam-block-@-SEE-MY-SIG.com>
Subject: Re: Regex (?(?{CODE})) has too many branches
Message-Id: <ant212131b07fNdQ@riscpc.jtnet>

In article <ua-dnSRXDdGGfUPfRVnytg@pipex.net>,
Big and Blue <No_4@dsl.pipex.com> wrote:
> 
> James Taylor wrote:
> > 
> > However, the Camel book (3rd ed) demonstrates (on page 213)
> > that code blocks *can* access backreferences from earlier in
> > the current match. So, what am I doing wrong?
> 
>    (Wild guessing here...)
> 
>     Don't you need \1 rather than $1 for that?

I believe the only place where it is correct to use \1 is in the
non-code parts of the match pattern. The insides of (?{ }) are
normal Perl code and so use the $1 syntax.

-- 
James Taylor, London, UK                              PGP key: 3FBE1BF9
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use james at oakseed demon co uk.



------------------------------

Date: Fri, 22 Jul 2005 12:37:55 +0100
From: James Taylor <spam-block-@-SEE-MY-SIG.com>
Subject: Re: Regex (?(?{CODE})) has too many branches
Message-Id: <ant221155568fNdQ@riscpc.jtnet>

In article <slrnddtnl3.7fo.abigail@alexandra.abigail.nl>,
Abigail <abigail@abigail.nl> wrote:
> 
> I'd write that as (untested):
> 
>   m{ <table\b [^"'>]* (?: (?: "[^"]*" | '[^']*' ) [^"']*) * >
>      [^<c]* (?: (?: <(?!table) | c(?!lass="whiteHeading") ) [^<c]* )*
>      </table>
>    }xi;


Wow, that looks pretty clever, and it gets away without using
any code blocks too which must be an efficiency improvement.
So that I can be sure I've understood what this is doing,
I'm going to number each line and comment it. Perhaps you'd
be kind enough to point out any misunderstandings. Thanks.


 1 m{
 2     <table\b                # Start of begin table tag
 3     [^"'>]*                 # inside of tag but avoiding quotes
 4     (?:                     # zero or more of...
 5         (?:                 #     either...
 6             "[^"]*"         #         a double quoted attribute value
                               #         which may include a > char
 7         |                   #     or...
 8             '[^']*'         #         a single quoted attribute value
                               #         which may include a > char
 9         )                   #
10         [^"']*              #     more tag between quoted bits (but we must
                               #     add a > char to stop it running away)
11     )*                      #
12     >                       # End of begin table tag
                               # Table content follows (should be captured):
13     [^<c]*                  # content between tags or possible class=
14     (?:                     # zero or more of...
15         (?:                 #     either...
16             <               #         a tag
17             (?!table)       #         which isn't a begin table tag
18         |                   #     or...
19             c               #         a 'c'
20             (?!lass="whiteHeading") # which isn't a class="whiteHeading"
21         )                   #
22         [^<c]*              #     more non-tag non-c content
23     )*                      #

24     </table>                # End table tag
25 }xi;


I've never seen a > inside an attribute value that hasn't been
converted to a &gt; entity. Wouldn't it would be an error anyway?
To guard against missing close quotes on attribute values I would
prefer to regard the first > as a tag terminator regardless of
whether all quotes have been closed correctly. I could therefore
simplify the regex by removing lines 4-11. Would this be sensible,
or would it actually contravene the formal syntax rules?

> It'll fail to match if there's a `class="whiteHeading"'
> outside a tag

Yes, but this is never likely to happen on the specific page
I'm scraping, so I'm happy to fudge over that.

> something like `<!-- <table> -->' in the text,

If commented out portions of HTML become a problem, I can
simply strip out the comments before applying the table
finding regex under discussion.

The main problem I see with this regex is that it seems to
capture only tables that do NOT contain class="whiteHeading",
but my two criteria for selecting the right table are that:

  1. It does not contain any nested tables
  2. It DOES contain cells with class="whiteHeading"

Is there a simple way to ensure class="whiteHeading" *is* present
within the table whilst still using your clever trick for
avoiding nested tables? I cannot simply change line 20 into a
positive look-ahead because there are other class="" attributes
which have nothing to do with my selection criteria. I suppose I
could flag the occurrence of a class="whiteHeading" using yet
more code blocks like this:

                               # Table content follows (should be captured):
13     [^<c]*                  # content between tags or possible class=
13a    (?{ local $found = 0 }) # whiteHeading not yet found
14     (?:                     # zero or more of...
15         (?:                 #     either...
16             <               #         a tag
17             (?!table)       #         which isn't a begin table tag
17a        |                   #     or...
17b            class="whiteHeading"    # a class="whiteHeading"
17c            (?{ $found = 1 })       # which we flag as found
18         |                   #     or...
19             c               #         a 'c'
20             (?!lass="whiteHeading") # which isn't a class="whiteHeading"
21         )                   #
22         [^<c]*              #     more non-tag non-c content
23     )*                      #
23a    (?(?{ $found }) | --FAIL-- ) # Backtrack unless whiteHeading found


However, I'm reluctant to go back to code blocks now that
you've shown me how to avoid them. Is there a better way?

-- 
James Taylor, London, UK                              PGP key: 3FBE1BF9
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use james at oakseed demon co uk.



------------------------------

Date: 22 Jul 2005 20:05:37 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Regex (?(?{CODE})) has too many branches
Message-Id: <slrnde2kch.7fo.abigail@alexandra.abigail.nl>

James Taylor (spam-block-@-SEE-MY-SIG.com) wrote on MMMMCCCXLIII
September MCMXCIII in <URL:news:ant221155568fNdQ@riscpc.jtnet>:
''  
''  
''  I've never seen a > inside an attribute value that hasn't been
''  converted to a &gt; entity. Wouldn't it would be an error anyway?

No. You seldomly need to escape an > in HTML. About the only time
you need to escape an > is in the ]]> token - and there's no mainstream
browser that can handle <!INCLUDE [ ... [ ... ]]> in a meaningful way
anyway.

''  To guard against missing close quotes on attribute values I would
''  prefer to regard the first > as a tag terminator regardless of
''  whether all quotes have been closed correctly. I could therefore
''  simplify the regex by removing lines 4-11. Would this be sensible,
''  or would it actually contravene the formal syntax rules?

So, you're willing to mismatch correctly written HTML in order 
to deal with incorrectly written HTML?

I'd worry more about using whitespace around the equal sign in

    class="whiteHeading"

or that single quotes (or no quotes at all) are used. Or 'class' in
capitals.

'' > It'll fail to match if there's a `class="whiteHeading"'
'' > outside a tag
''  
''  Yes, but this is never likely to happen on the specific page
''  I'm scraping, so I'm happy to fudge over that.
''  
'' > something like `<!-- <table> -->' in the text,
''  
''  If commented out portions of HTML become a problem, I can
''  simply strip out the comments before applying the table
''  finding regex under discussion.

But an attribute might contain '<!--', and another attribute might
contain '-->'. What's in between is not an HTML comment.

''  The main problem I see with this regex is that it seems to
''  capture only tables that do NOT contain class="whiteHeading",
''  but my two criteria for selecting the right table are that:
''  
''    1. It does not contain any nested tables
''    2. It DOES contain cells with class="whiteHeading"

Oh. I thought it shouldn't contain such a cell.

Anyway, I'd use something like (untested):


  m{ <table\b [^"'>]* (?: (?: "[^"]*" | '[^']*' ) [^"']*) * >
     [^<]* (?: <(?!table) [^<]* )*
     class="whiteHeading"
     [^<]* (?: <(?!table) [^<]* )*
     </table>
   }xi;


Although it doesn't check whether it's a class attribute of a table cell.


I do think that you're better off using an HTML parser instead of a regex.



Abigail
-- 
   my $qr =  qr/^.+?(;).+?\1|;Just another Perl Hacker;|;.+$/;
      $qr =~  s/$qr//g;
print $qr, "\n";


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc.  For subscription or unsubscription requests, send
#the single line:
#
#	subscribe perl-users
#or:
#	unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V10 Issue 8269
***************************************


home help back first fref pref prev next nref lref last post