[27276] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 9032 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 8 21:05:47 2006

Date: Wed, 8 Mar 2006 18:05:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Wed, 8 Mar 2006     Volume: 10 Number: 9032

Today's topics:
    Re: Different results parsing a XML file with XML::Simp robic0
    Re: merge event loops and threads (was Re: simple point robic0
    Re: Regex - need help! <rvtol+news@isolution.nl>
    Re: Regex: Backreferences do not work inside quantifier <nospam-abuse@ilyaz.org>
        regexp: segmentation fault <sm244@kent.ac.uk>
    Re: regexp: segmentation fault <1usa@llenroc.ude.invalid>
    Re: regexp: segmentation fault <sm244@kent.ac.uk>
    Re: Weighing the evidence, Perl is a GUESSING game !! robic0
    Re: Weighing the evidence, Perl is a GUESSING game !! <jurgenex@hotmail.com>
    Re: Weighing the evidence, Perl is a GUESSING game !! robic0
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Wed, 08 Mar 2006 16:54:10 -0800
From: robic0
Subject: Re: Different results parsing a XML file with XML::Simple (XML::Sax vs. XML::Parser)
Message-Id: <bkuu0252b7m7pa2a40jvctojkc3svaem4l@4ax.com>

On Sun, 05 Mar 2006 23:09:03 +0100, "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:

>Erik Wasser wrote:
>
>[XML::Simple gives correct results with XML::Parser, but wrong results
>with XML::SAX]
>
>> My question was: why two XML parsers are getting different results?
>> The different results are confusing me not unicode itself.
>
>Looks like a bug in XML::SAX or one of the libraries it uses.
>However, like Sinan, I cannot reproduce it here on a Debian Sarge
>system:
>
>perl, v5.8.4 built for i386-linux-thread-multi
>XML::Simple version 2.14
>XML::SAX version 0.12
>XML::Parser version 2.34
>libexpat1      1.95.8-3
>
>So it may be caused by something weird in your einvironment.
>
>        hp
I'm going to have to agree. Using many parsers at the same time will
cause either slowdows or indeterminate results.
xml:sax is not a good parser. Just because it has "sax" in the title
(simple api xml) is bellweather on its functionality/performance.
After using xml:sax in place of expat once, the performance fell off
by %800. If you are going to parse and capture and expand a string
to be later converted into a hash, be carefull of what you use and
how its used. Expat and Simple (with expat directive) are a good 
combination. Good cleanup is required. Keep your instantiation,
single operation, closure, sub-scoped. If you are doing schema checking
with Xerces, keep that at a different scope, and a preliminary to
data extraction parsing.

Any ?'s (oh fuck my spelling), let me know



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

Date: Wed, 08 Mar 2006 17:47:22 -0800
From: robic0
Subject: Re: merge event loops and threads (was Re: simple pointer operations (newbe))
Message-Id: <rd1v02lp5q99otfivdfvudlmt7mlpr7hft@4ax.com>

On Mon, 6 Mar 2006 08:59:07 +0100, "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> wrote:

>Also sprach Uri Guttman:
>
>>>>>>> "TvP" == Tassilo v Parseval <tassilo.von.parseval@rwth-aachen.de> writes:
>
>>  TvP> Well, I know that you know that. But for Event::Lib, I received
>>  TvP> quite a few mails from people who were apparently under the
>>  TvP> misapprehension that each event handler is triggered in its own
>>  TvP> process or thread. An event-based application is still running
>>  TvP> sequentially so it will not always spare one the pain to use
>>  TvP> fork() or threads.
>>
>> i have an idea and most of the design for a module that will allow event
>> loops to work well with kernel (not perl!) threads that will run
>> blocking operations. of course it involves xs which i have done very
>> little with. would you (or anyone else) be interested in working on it
>> with (or for :) me? one variation on it (which could use this new module
>> or be its own module) would do true async file i/o and be synchronized
>> with the event loop. i have done such a beast before in pure c and it
>> worked very well. i think these modules are wanted and would be useful
>> to many event loop apps. imagine a simple api for async file i/o in perl
>> that was actually portable and bypasses all those wacko kernel aio apis
>> that each OS provides.
>
>The specifications sound tempting although you didn't state how you'd
>actually want to achieve the asynchronity when you avoid the existing
>async IO mechanisms (of which each is unportable by nature). Does your
>plan include rolling your own async IO scheme?
>
>Also, I don't yet see how kernel threads come into this. Perl programs
>don't have access to them other than through perl's ithreads.
>
Now wait a minute. Are you saying Perl programs "don't" have direct access
to the underlying OS api core?

Well, how come? Apparently, Perl programs can do "pointer arithmatic".
Heh, where the fuck does those docs exist?

So, the whole Perl thing is just a blow-me bullshit cover for really doing
C pointers. Well, holy GOD, why didn't they just say so. I could have used
any number of regex c-libs out there. Didn't know Perl was just a neo training
camp for the stupedist of C programmers. I didn't realize there was such a lack
of C/C++ (which is not the point), and of course the most important, a/the
OS Api. 

Control and synchronization programming (blocking, etc) is a talent that you
can't just read-up on. Windows kernel, which provides "all" control programming
to user apps, uses "multiple blocking nomenclature and schem's", pseudo (name)
categories, hard/soft/level.

You guys don't know your ass from your elbow!




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

Date: Thu, 9 Mar 2006 01:40:48 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Regex - need help!
Message-Id: <duo1b9.ho.1@news.isolution.nl>

dutch disCo schreef:

>   find . -name "index.html"
> ./0223/html/index.html
> ./0357/html/index.html
> 
> Now, I want these lines to become:
> 
> <a href="./0223/html/index.html">./0223/html/index.html</a>
> <a href="./0357/html/index.html">./0357/html/index.html</a>

  find2perl . \
    -name "index.html" \
    -eval "print qq{<a href=\"\$name\">\$name</a>\\n}" \
    | perl \
    > file

bash:
  for f in `find . -name "i*"`; \
  do echo '<a href="'$f'">'$f'</a>'; \
  done > file 

-- 
Affijn, Ruud

"Gewoon is een tijger."


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

Date: Wed, 8 Mar 2006 23:10:46 +0000 (UTC)
From:  Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Regex: Backreferences do not work inside quantifiers?
Message-Id: <duno9m$1lc8$1@agate.berkeley.edu>

[A complimentary Cc of this posting was sent to
Tad McClellan 
<tadmc@augustmail.com>], who wrote in article <slrne0sdg5.1oi.tadmc@magna.augustmail.com>:
> > "{" is special in REx only in very few of contexts.

> So it is only incompletely documented (from perlre.pod):
> 
>    The following standard quantifiers are recognized:
> 
>        *      Match 0 or more times
>        +      Match 1 or more times
>        ?      Match 1 or 0 times
>        {n}    Match exactly n times
>        {n,}   Match at least n times
>        {n,m}  Match at least n but not more than m times
> 
>    (If a curly bracket occurs in any other context, it is treated
>    as a regular character.) 

As usual, when documenting a historical misfeature, it is better to
insert an f-word (well, a c-word in this case ;-):

    (CURRENTLY, If a curly bracket occurs in any other context, it is treated
    as a regular character.)

Yours,
Ilya


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

Date: Thu, 09 Mar 2006 00:22:27 +0000
From: "S.Marion" <sm244@kent.ac.uk>
Subject: regexp: segmentation fault
Message-Id: <dunsg9$h90$1@oheron.kent.ac.uk>

Hello,

I have a problem with my regexp.
I'm trying to match the following pattern:

$cmd =~ /static \{\};(.*\n)(.*)Signature: 
\(\)V(.*\n){1,3}.*Code:\n(.+\n){1,$limit}\s*$offset:(.*)/g;

The problem is that there can be many lines between the "Code" and the 
$offset.
By many line I mean thousands.
When the offset is further than about 8000 lines, I have a segfault !
I guess the problem is that it's feeding too much info into $3 whereas 
I'm only interested in the remaining of the line after $offset (that is $4).
Basically, if I could avoid using $3 I wouldn't mind !


Do you know any way I could fix this?

Thank you for your help,

Sebastien


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

Date: Thu, 09 Mar 2006 00:30:41 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: regexp: segmentation fault
Message-Id: <Xns9780C696CDF69asu1cornelledu@127.0.0.1>

"S.Marion" <sm244@kent.ac.uk> wrote in
news:dunsg9$h90$1@oheron.kent.ac.uk: 

> I have a problem with my regexp.
> I'm trying to match the following pattern:
> 
> $cmd =~ /static \{\};(.*\n)(.*)Signature: 
> \(\)V(.*\n){1,3}.*Code:\n(.+\n){1,$limit}\s*$offset:(.*)/g;
> 
> The problem is that there can be many lines between the "Code" and the
> $offset.
> By many line I mean thousands.
> When the offset is further than about 8000 lines, I have a segfault !
> I guess the problem is that it's feeding too much info into $3 whereas
> I'm only interested in the remaining of the line after $offset (that
> is $4). Basically, if I could avoid using $3 I wouldn't mind !

Without any idea what the input looks like, the regex above does not 
mean much to me.

By the way, the (.*) after $offset is the fifth capture group.

If you are not interested in capturing anything before that, why are you 
using capturing groups?

I have a feeling (since I have no data, I cannot test this), anchoring 
the pattern, using .+ rather than .* might help.

On the other hand, depending on what the input looks like, I might be 
tempted to use the .. operator.

See

perldoc perlre for non-capturing groups
perldoc perlop for range operators

Sinan

-- 
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html



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

Date: Thu, 09 Mar 2006 01:23:59 +0000
From: "S.Marion" <sm244@kent.ac.uk>
Subject: Re: regexp: segmentation fault
Message-Id: <duo03f$oc2$2@oheron.kent.ac.uk>

Hello,

Thank you for your reply.
Let me apologise if I wasn't clear enough.
Basically the inputs are from javap, and I want to match a particular 
offset of a given output in the given method with the given signature.

> 
> By the way, the (.*) after $offset is the fifth capture group.
> 
That's right, my mistake, got confused after moving it around.

> If you are not interested in capturing anything before that, why are you 
> using capturing groups?
> 
well... simply because I have no idea how else I could say "ok jump as 
many lines as you want until you find my offset".

> I have a feeling (since I have no data, I cannot test this), anchoring 
> the pattern, using .+ rather than .* might help.
> 
No unfortunately that doesn't do the trick.

> On the other hand, depending on what the input looks like, I might be 
> tempted to use the .. operator.
> 
I'm not sure I understand what this does, but in any case it does not 
work unfortunately :(




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

Date: Wed, 08 Mar 2006 16:40:34 -0800
From: robic0
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <aauu02ha2rl6388vm8o1d9rc7caq3hsl0b@4ax.com>

On Sun, 05 Mar 2006 02:25:42 GMT, "Jürgen Exner" <jurgenex@hotmail.com> wrote:

>robic0 wrote:
>> On Thu, 02 Mar 2006 00:47:56 GMT, "A. Sinan Unur"
>>> He sucks at spelling any word.
>>
>> Whatever u say Nissan
>          ^^^
>          |||
>
>I rest my case :-)))
>
>jue 
>
You don't had a case. "u" is not a word!


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

Date: Thu, 09 Mar 2006 00:51:19 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <b_KPf.5785$sp4.2034@trnddc01>

robic0 wrote:
> On Sun, 05 Mar 2006 02:25:42 GMT, "Jürgen Exner"
> <jurgenex@hotmail.com> wrote:
>> robic0 wrote:
>>> On Thu, 02 Mar 2006 00:47:56 GMT, "A. Sinan Unur"
>>>> He sucks at spelling any word.
>>>
>>> Whatever u say Nissan
>>          ^^^
>>          |||
>>
>> I rest my case :-)))
>>
> You don't had a case.
      ^^^^^^^^^
      |||||||||

Ok, fair enough, it's not spelling, it's grammar.

> "u" is not a word!

Interesting question. Does a letter become a word when it is used as a word?

Anyway, if a sentence is composed of words and u is not a word, then
- the u had no business being there
- some word is still missing in that sentence

On the other hand, if some word is missing in a sentence, is it still a 
sentence or just a sequence of random words?

I think the answer is 42.


jue 




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

Date: Wed, 08 Mar 2006 17:04:30 -0800
From: robic0
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <eovu0257m31p8jribf789ih2dpuus7b6tq@4ax.com>

On Thu, 09 Mar 2006 00:51:19 GMT, "Jürgen Exner" <jurgenex@hotmail.com> wrote:

>robic0 wrote:
>> On Sun, 05 Mar 2006 02:25:42 GMT, "Jürgen Exner"
>> <jurgenex@hotmail.com> wrote:
>>> robic0 wrote:
>>>> On Thu, 02 Mar 2006 00:47:56 GMT, "A. Sinan Unur"
>>>>> He sucks at spelling any word.
>>>>
>>>> Whatever u say Nissan
>>>          ^^^
>>>          |||
>>>
>>> I rest my case :-)))
>>>
>> You don't had a case.
>      ^^^^^^^^^
>      |||||||||
>
>Ok, fair enough, it's not spelling, it's grammar.
>
>> "u" is not a word!
>
>Interesting question. Does a letter become a word when it is used as a word?
>
>Anyway, if a sentence is composed of words and u is not a word, then
>- the u had no business being there
>- some word is still missing in that sentence
>
>On the other hand, if some word is missing in a sentence, is it still a 
>sentence or just a sequence of random words?
>
>I think the answer is 42.
>
>
>jue 
>
Your too funny for words!


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

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 9032
***************************************


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