Prev: trim the last blank-line and compare files
Next: Can you compile a perl executable?
From: Adam Kellas on 3 Mar 2010 22:47
On Mar 3, 11:42 am, s...(a)netherlands.com wrote:
> Just a comment that no where is it written that you can reconstruct
> variables from the output of  variable substitution.

Yes, this is analogous to decompilation; it's not possible to reliably
put it back the way it was, but it may be possible to generate
something which is both correct and fairly readable. There will always
be macroization opportunities missed and bad choices. For a simple
instance:

RM = rm
RM_FLAGS = -f
MV = mv
MV_FLAGS = -f

Given this, varify("rm -f foo") might turn into "$(RM) $(MV_FLAGS)
foo" and I don't think there's any way to prevent it without getting
into some serious AI stuff. But in this application that's ok as long
as the result works. The user can be expected to do a little manual
cleanup in an editor if need be.

Thanks for the sample code.

AK
From: David Harmon on 4 Mar 2010 10:11
On Wed, 3 Mar 2010 06:29:38 -0800 (PST) in comp.lang.perl.misc, Adam
Kellas <adam.kellas(a)gmail.com> wrote,
>but wouldn't we all? Though how you can argue that % is ugly while /
>is not while explicitly rejecting the notion that it's an aesthetic
>disagreement

% is a poor choice because it is dense, busy, and wide. It puts more
black on the display, so that is about the same density of many other
characters. It has more squiggles than / making it indeed harder to
read. / is lighter that average, and narrow so it leaves minute white
space between it and adjacent characters, for better visual separation.

/ loses these advantages when adjacent characters resemble it, as in the
infamous leaning toothpicks syndrome s/\/\//\\\\/; etc. but there are
other solutions for that.

And, of course, % is contrary to convention.
From: Peter J. Holzer on 4 Mar 2010 13:31
On 2010-03-03 16:04, Adam Kellas <adam.kellas(a)gmail.com> wrote:
> On Mar 3, 10:21�am, "Uri Guttman" <u...(a)StemSystems.com> wrote:
>> >>>>> "AK" == Adam Kellas <adam.kel...(a)gmail.com> writes:
>> � AK> Really, we have no disagreement here. It's just that when one is
>> � AK> trying desperately to speed something up it's reasonable to try
>> � AK> everything you know of. What I posted was not a published, supported
>> � AK> piece of code, it was the result of a tuning exercise.
>>
>> desperation is not a reason to try everything under the sun for
>> speedups. just applying the benchmark module is a saner way to find out
>> what is actually faster and by how much.
>
> OK, if you insist, we do have a disagreement. I will simply note that
> the benchmark module is of little use when the code you're fixing is
> so slow as to never finish.

If the code you're fixing is so slow as to never finish, blindly
replacing named variables with $_ is even less use. At best that brings
you a small constant speedup. 95% of infinity is still infinity.

If your code is so slow that you can't even measure it you first should
make sure that it isn't stuck in an infinite loop. Then prepare a test
case where it does finish in a practicable time (maybe run with a
reduced data set, or simply exit after a fixed number of iterations),
and look where it spends the time (Devel::NYTProf is a good profiler but
be warned that it can add a lot of overhead (I've had code which ran 5
to 10 times slower with profiling than without[1])). Then try to make
that code faster - and that will almost always mean a change to the
algorithm, not a micro-optimization.

hp

[1] All the profilers for perl I know hook into the debugger, so they
execute extra code for each line/block/sub that is executed. Using
a SIGPROF handler (like the traditional Unix profiler does) should
have much less overhead - does anyone know a perl profiler which
does this?

From: Ben Morrow on 4 Mar 2010 14:05

Quoth "Peter J. Holzer" <hjp-usenet2(a)hjp.at>:
>
> [1] All the profilers for perl I know hook into the debugger, so they
> execute extra code for each line/block/sub that is executed. Using
> a SIGPROF handler (like the traditional Unix profiler does) should
> have much less overhead - does anyone know a perl profiler which
> does this?

I don't, but as of 5.10 there is some support for dtrace, if you're on a
system that supports that. (I've never used it, so don't ask me how it
works.)

Ben

From: RedGrittyBrick on 5 Mar 2010 04:14
On 04/03/2010 15:11, David Harmon wrote:
> On Wed, 3 Mar 2010 06:29:38 -0800 (PST) in comp.lang.perl.misc, Adam
> Kellas<adam.kellas(a)gmail.com> wrote,
>> but wouldn't we all? Though how you can argue that % is ugly while /
>> is not while explicitly rejecting the notion that it's an aesthetic
>> disagreement
>
> % is a poor choice because it is dense, busy, and wide. It puts more
> black on the display, so that is about the same density of many other
> characters. It has more squiggles than / making it indeed harder to
> read. / is lighter that average, and narrow so it leaves minute white
> space between it and adjacent characters, for better visual separation.
>
> / loses these advantages when adjacent characters resemble it, as in the
> infamous leaning toothpicks syndrome s/\/\//\\\\/; etc. but there are
> other solutions for that.
>
> And, of course, % is contrary to convention.

perldoc perlop gives as an example $path =~ s|/usr/bin|/usr/local/bin|;
and Conway's recommendation of {} seems a useful one to follow.

I'm sure I've read a recommendation for "tall thin characters" as
delimiters but can't find the source now.

--
RGB
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: trim the last blank-line and compare files
Next: Can you compile a perl executable?