in reply to Shot myself in the foot with a pos

A simpler solution is to lose the /g on your match: 
if ($packets[$i] =~ /$str/g) {
  ++$all{$str};
}

[download]
Also note that the rewrite means people don't have to remember relative precedence - always a good thing IMO.

BTW I am curious whether you ever tried out what I offered at One possible answer. It is a rather different idea than the other solutions you were given, and I wouldn't mind knowing how it works in practice. (It could be very slow and use a lot of memory, it might be fast, I really don't know have a good sense of how it will scale.)

Replies are listed 'Best First'.
RE: RE: Shot myself in the foot with a pos
by chip (Curate) on Aug 11, 2000 at 04:29 UTC
    I think it's a bad idea to let readers off the hook when it comes to any language rules, including precedence rules. The whole language is there for me to use when appropriate, and I'm not going to take very well to instructions to back off some construct just because it takes a little research to understand the first time.

        -- Chip Salzenberg, Free-Floating Agent of Chaos

[reply]
      I think if I took that attitude when I started at my current job I wouldn't have wound up being asked to train most of the other programmers how to use Perl.

      I wholeheartedly agree that any good Perl programmer should know the precedence rules. That does not mean that their code should be written using them all if you have any expectation that it will someday have to be altered by someone not as conversant as you.

      But this is a disagreement we won't settle any time soon. One of my sillier mistakes was to have this argument with Tom C. You know that I deliberately limit myself to a set of constructs that I think I can teach to others. The one I was responding to is simply not common enough for me to want it on a short-list of things I have to teach. OTOH another time I showed a construct I had to deal with (that was written by someone else) to p5p and got general shock and horror about how convoluted it was. Plus one of my favorite quotes ever on programming from Tom C:

      A programmer who hasn't been exposed to all four of the imperative, functional, objective, and logical programming styles has one or more conceptual blindspots. It's like knowing how to boil but not fry. Programming is not a skill one develops in five easy lessons.

      I think that when there are valid and valuable constructs that can cause that much reaction on a list with as many tuits as p5p, it is beyond the bounds of reason to expect most companies to have people who could maintain a code-base that uses all of them.

      For bystanders, the construct handed to me is this: 

      print join ",", map { &{$field_info{$_}{format}}($deal) } @fields;

      [download]
      I pointed out that I had cleaned it up. Thanks to merlyn it got cleaned up a bit more, and this construct shows up from time to time in my code like this: 
      my @field_subs = map {$field_info{$_}{format}} @fields;
# TIME PASSES
print join ",", map {$_->($deal)} @field_subs;

      [download]
      In fact a variation of it appeared in my first post here, at A few style suggestions.
[reply]
[d/l]
[select]
        I'm wholly in favor of making things maintainable, and I have no interest in gratuitous confusion. So I think we are in broad agreement.

        However, when I'm under a deadline, I simply don't have the time to optimize for readability; I have to optimize for speed of programming and ease of debugging (that's debugging my own code, BTW :-)). And the shorter my code is, the less likely it is to be broken.

        I'm reminded of something Kipling is reported to have written: ``I apologize for the length of this letter, but I had no time to make it shorter.'' In constrast, writing short Perl code is easy; when I'm programming for money, I have no time to make it longer.

            -- Chip Salzenberg, Free-Floating Agent of Chaos

[reply]
(Guildenstern) RE: RE: Shot myself in the foot with a pos
by Guildenstern (Deacon) on Aug 11, 2000 at 00:30 UTC
    did you mean
    if ($packets[$i] =~ /$str/) {?
    The only thing that I see with this is if there's multiple instances of $str in $packets$i, the hash counter won't be incremented correctly. If I leave the /g in, my matches won't happen because pos is past the start of a match.
    For example, I have ABC and I check (and match the substring AB). This means that pos points at C now. If I go through again and try to match the substring BC, it won't find it.
    Maybe I've misunderstood what you were suggesting here. Correct me if necessary.

    As far as the solution you provided, I haven't tried it yet. To be completely honest, I'm just trying to get myself into the groove of learning the minor nuances of Perl, and I have very little idea of what parts of your code are doing. Fear not, though - I am going through it bit by bit with my Camel book at hand, and hopefully in the next day or two I'll feel confident enough to run it. I'd like to at least be able to tweak things if I need to and know what I'm doing! :)
[reply]
[d/l]
      Perl only cares about pos() for matches with the /g modifier. Drop the /g, and all attempts at matching start from the beginning of the string.

      As for the code I provided, well good luck deciphering it. The algorithm I used is pretty complex. The key idea though is for each packet to maintain a hash whose keys are the substrings we are still interested in, and whose values are the set of positions in that packet where the pattern starts. :-)

      I don't tend to write production code like that....

[reply]

In Section Meditations