Zugg Software :: View topic

Posted: Thu Mar 20, 2008 3:02 pm

Previously this subreg expression used to change non-letters to a pipe would do this:

%subregex( %1, "[^\a]+", "|")

Tom, Dick, Larry. => Tom|Dick|Larry

Instead, now it is doing this:

Tom, Dick, Larry. => |||||||||||||||||

Wizard Joined: 17 Jun 2006 Posts: 1201

Works fine if you do it this way...

Posted: Thu Mar 20, 2008 10:19 pm

I'm sure I could come up with another pattern, but why is the old one no longer valid?

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

I wonder if this is related to the bug Vijilante noted in this thread. If so, the regex engine has already been corrected for the next version.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I just checked this and a few related patterns in my test app and it doesn't seem right. I will have to hunt down what is going on and send Zugg some other corrections. It is related, but my fix for the other problem doesn't cover this, and I can't really see why right now.

Wizard Joined: 17 Jun 2006 Posts: 1201

Posted: Fri Mar 21, 2008 4:43 am

And actually, using the supplied pattern on that string will result in a bar at the end of the string, causing it to have an extra blank item. If it were me, in that case, I'd've used %subchar(%1,", ","|").

Wizard Joined: 17 Jun 2006 Posts: 1201

I don't see any difference at all.

Posted: Fri Mar 21, 2008 6:17 am

The intent was to get rid of the period at the end as well, which it does, or rather did, before version 2.20. Having an extra pipe at the end didn't seem to mess with anything.

Posted: Fri Mar 21, 2008 6:28 am

Yeah, I typoed. I meant it to be %subchar(%1,", .","|"). And whether or not it caused any problems would depend on what you were doing with the items and how much you cared - if I were #saying something for every item, the blank ones would annoy me, for example.

Wizard Joined: 17 Jun 2006 Posts: 1201

Ah ha...you are exactly right! Didn't think about the period. However, I thought he just wanted to get rid of the commas.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I checked through some more with the corrections I already sent Zugg and found everything to be working right. When I quickly tested it the other morning I tried \a and \A. The definition of the pattern code \a is the bell character. Zugg might have had some override for it in the old version so that it related to letters. The definition of \A is the start of the text. I had to look it up to figure out that problem.

The \w pattern item is defined for both letters and numbers and would do what you want. If you only want letters then the pattern item \pL would be ideal. Also \w and \p support automatic negation as \W and \P. Some seggested patterns for you to test in the new version.
%subregex( %1, "\W+", "|")
%subregex( %1, "\PL+", "|")

Posted: Sun Mar 23, 2008 3:55 pm

Aha, I learned perl before I ever used Zmud and I remember the day when I saw \a in the documentation and I thought, gee, that's useful, I wonder why I had never learned that about regexs before. So I started using it and I just assumed it was part of perl which I had just missed in the past. I'll have to go through and eradicate the other uses of \a since Cmud seems more in-line with standard perl regexs at this time.

Zugg might want to delete the \a from the documentation to avoid confusion.

Here's the current documentation for #regex:

\s a space character (ascii 32)
\p the | pipe character
\w a word delimiter (matches a-zA-Z0-9)
\a a letter (matches a-zA-Z)
\d a digit (matches 0-9)
\h a hex character (0-9A-F)
\n matched a newline for multiline triggers

Posted: Sun Mar 23, 2008 3:57 pm

Oh, and thanks for the alternate suggestions, although, finding an alternative wasn't really the issue. I could come up with multiple alternatives pretty easily. My main issue was finding out and fixing why it suddenly stopped working. Things that suddenly break are always areas I investigate to make sure there's nothing serious going on.