This Week on perl5-porters (7-13 June 2004)

This Week on perl5-porters (7-13 June 2004)
  This week, a small summary is better than no summary at all.

h2ph
  Rafael Garcia-Suarez finds that h2ph can't process the newest C headers
  from the glibc, because they include inline functions (instead of good
  old macros). He forced a bit of heuristics in it to decode the less
  convoluted C inline functions that might be there. Your mileage may
  vary.

IO::File on windows
  Roderich Schupp finds that IO::File fails on open a file that is found
  on another volume on Windows (bug #30132). The problem comes from the
  Cwd and File::Spec modules (and their handling of volumes in pathnames),
  on which Ken Williams is working. He released thereafter a new beta of
  Cwd.pm, on which Mark Mielke provided some performance considerations.

      http://groups.google.com/groups?selm=1CDC3096-BCF9-11D8-9A4F-000A95BD9874%40mathforum.org

DB_File fooled by substr
  Ton Hospel finds (bug #30237) that the DB_File methods don't behave
  correctly when they're passed results of substr() in argument. Paul
  Marquess investigates.

      http://groups.google.com/groups?selm=rt-3.0.9-30237-90394.14.8512570678496%40perl.org

Obscure bug of the week
  Ton Hospel (again) finds that a small snippet of code involving the
  "locale" pragma, regexp manipulation and loading the POSIX module at
  run-time dies with an insecure dependency error when run under -T. (bug
  #30068). Nobody commented on the possible causes of this regression.

      http://groups.google.com/groups?selm=rt-3.0.9-30068-89825.7.20442262108094%40perl.org

Data::Dumper deparsing indentation
  Mathieu Arnold proposed a patch to improve the indentation of the output
  of Data::Dumper when it is configured to deparse code references (bug
  #30197).

Safe Panic
  Perl panics when one tries to use split() on an utf8-string from your
  average Safe compartment, as Rusty Conover reported (bug #30258). This
  is probably due to perl trying to load some data behind the scenes,
  which is forbidden by Safe, so the operation is aborted, and this
  abortion doesn't end well for some unclear reason.

      http://groups.google.com/groups?selm=rt-3.0.9-30258-90458.7.13228983473336%40perl.org

".." optimized
  The range ".." operator is usually optimized in a foreach loop, so that
  the list is not constructed in place. However, for alphabetic ranges,
  and when the range is not the only thing in the foreach() argument, this
  optimization does not occur (bug #30123, reported by Michael G Schwern).

About this summary
  This summary was written by Rafael Garcia-Suarez. Weekly summaries are
  published on http://use.perl.org/ and posted on a mailing list, which
  subscription address is perl5-summary-subscribe@perl.org. Comments and
  corrections welcome.
0
rgarciasuarez
6/15/2004 4:56:40 PM
perl.perl5.porters 47902 articles. 1 followers. Follow

5 Replies
235 Views

Similar Articles

[PageSpeed] 19

Rafael Garcia-Suarez <rgarciasuarez@mandrakesoft.com> writes:

> ".." optimized
>   The range ".." operator is usually optimized in a foreach loop, so that
>   the list is not constructed in place. However, for alphabetic ranges,
>   and when the range is not the only thing in the foreach() argument, this
>   optimization does not occur (bug #30123, reported by Michael G Schwern).

Alphabetic ranges are certainly optimized.  The optimization
kicks in for all blocks of the form:

   for ((expr) .. (expr)) {
       #...
   }

Regards,
Gisle
0
gisle
6/15/2004 5:05:17 PM
Gisle Aas wrote:
> Rafael Garcia-Suarez <rgarciasuarez@mandrakesoft.com> writes:
> 
> > ".." optimized
> >   The range ".." operator is usually optimized in a foreach loop, so that
> >   the list is not constructed in place. However, for alphabetic ranges,
> >   and when the range is not the only thing in the foreach() argument, this
> >   optimization does not occur (bug #30123, reported by Michael G Schwern).
> 
> Alphabetic ranges are certainly optimized.  The optimization
> kicks in for all blocks of the form:
> 
>    for ((expr) .. (expr)) {
>        #...
>    }

Isn't this what I wrote ?

$ perl -MO=Deparse -e 'for(a..aa){}'
foreach $_ ('a' .. 'aa') {
    ();
}

$ perl -MO=Deparse -e 'for(a,a..aa){}'
foreach $_ ('a', ('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 'aa')) {
    ();
}
0
rgarciasuarez
6/15/2004 5:06:12 PM
On Tue, Jun 15, 2004 at 07:06:12PM +0200, Rafael Garcia-Suarez wrote:
> Gisle Aas wrote:
> > Rafael Garcia-Suarez <rgarciasuarez@mandrakesoft.com> writes:
> > 
> > > ".." optimized
> > >   The range ".." operator is usually optimized in a foreach loop, so that
> > >   the list is not constructed in place. However, for alphabetic ranges,
> > >   and when the range is not the only thing in the foreach() argument, this
> > >   optimization does not occur (bug #30123, reported by Michael G Schwern).
> > 
> > Alphabetic ranges are certainly optimized.  The optimization
> > kicks in for all blocks of the form:
> > 
> >    for ((expr) .. (expr)) {
> >        #...
> >    }
> 
> Isn't this what I wrote ?

It was somewhat ambiguous; it sounded like you were describing two separate
cases rather than one.  Perhaps:

However, for alphabetic ranges when the range is not the only thing in the
foreach() argument, this optimization does not occur.


Ronald
0
rjk
6/15/2004 5:19:51 PM
Rafael Garcia-Suarez <rgarciasuarez@mandrakesoft.com> writes:

> Gisle Aas wrote:
> > Rafael Garcia-Suarez <rgarciasuarez@mandrakesoft.com> writes:
> > 
> > > ".." optimized
> > >   The range ".." operator is usually optimized in a foreach loop, so that
> > >   the list is not constructed in place. However, for alphabetic ranges,
> > >   and when the range is not the only thing in the foreach() argument, this
> > >   optimization does not occur (bug #30123, reported by Michael G Schwern).
> > 
> > Alphabetic ranges are certainly optimized.  The optimization
> > kicks in for all blocks of the form:
> > 
> >    for ((expr) .. (expr)) {
> >        #...
> >    }
> 
> Isn't this what I wrote ?

At least I did not read it that way.  Besides, alphabetic should not
have anything to do with it.  for(1,1..11){} would create a list of 12
elements on the stack and then iterate over it, thus behaves as
for(a,a..aa){}.

> $ perl -MO=Deparse -e 'for(a..aa){}'
> foreach $_ ('a' .. 'aa') {
>     ();
> }
> 
> $ perl -MO=Deparse -e 'for(a,a..aa){}'
> foreach $_ ('a', ('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 'aa')) {
>     ();
> }

I think the following is a better way to test if this kind of
construct is actually optimized at *run time*:

    perl -Ds -e 'for(1..11){}'
    perl -Ds -e 'for(1,1..11){}'

It actually confuses me why perl evaluate a..aa at compile time but
not 1..11.  I think that is the wrong thing to do.  It will certainly
blow up the op tree.  Not a very good idea if you have a large
alphabetic range that might not even be visited during runtime.
What I'm saying is that this program ought to exit quickly:

    perl -e 'if ($rarely) { @a = (a..aaaaaa) }'

It does not currently.

Regard,
Gisle
0
gisle
6/15/2004 6:03:29 PM
On Tue, 2004-06-15 at 13:03, Gisle Aas wrote:
> What I'm saying is that this program ought to exit quickly:
> 
>     perl -e 'if ($rarely) { @a = (a..aaaaaa) }'
> 
> It does not currently.
> 
> Regard,
> Gisle

a hard maximum would be easy to implement. But how much?




-- 
david nicol
    "People used to be able to read my thoughts, but
it doesn't appear to work any more. Should I eat less cheese?"
                                               -- Elizabeth Woods

0
whatever
7/9/2004 4:15:10 AM
Reply: