just downloaded the library for use on the command
(windows).

the logic queries (AND, OR) are not working ?

# agrep ‘FATAL’ report.20110408.txt
776 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
20 FATAL ERROR IN TWO-TASK SERVER: error = 12571
#
# agrep ‘FATAL;ERROR’ report.20110408.txt
# agrep ‘FATAL,ERROR’ report.20110408.txt

also, when i ran the command in a cygwin terminal,
there is a complain that delimiters should not be
empty strings ?

# agrep -d ‘$$’ ‘FATAL,ERROR’ report.20110408.txt
C:\GnuWin32\bin\agrep.exe: Record delimiter pattern must not match an empty string
#

are these features no longer supported ?

Thanks,
sam

I have stumbled upon an unexpected behavior:

pattern: ‘1111$’
str: ‘1111′ cost 0
str: ‘1111 ‘ cost 1 (as expected)

pattern: ‘2004$’
str: ‘2004′ cost 0
str: ‘2004 ‘ cost 2 (strange?)

I used a fresh download and default normal compilation
http://laurikari.net/tre/tre-0.8.0.tar.bz2
./configure
and then python setup.py install
My platform is Ubuntu 10.04

Here is the python code:

import tre
fz = tre.Fuzzyness(maxerr=3)

for test_str in ['1111','1111 ', '2004','2004 ']:
m = pt.search(test_str, fz)
if m:
print "str:", repr(test_str), "cost", m.cost


Is this a known issue and something that would be fixed?
Thanks again.
Julien

While here I see a vastly opposite result:
http://hackerboss.com/is-your-regex-matcher-up-to-snuff/

Now, is this slowdown fixable in your library, at least for non-approximate matching? Do you think there’s a special case for such patterns (using a tree for them) or is the slowdown just a product of using NFA’s versus recursive backtracking*?

*I just read the article you quote on your blog:
Regular Expression Matching Can Be Simple And Fast by Russ Cox.

In the normal case, tre_ctype() is just the same as the wctype() function from the C library. It returns a “character class” object. The counterpart of tre_ctype() is tre_isctype(), which takes a character and a character class object, and returns non-zero if the character is part of the character class. Normally tre_isctype() is the same as iswctype().

If the system does not have wctype() and iswctype(), TRE uses it’s own implementation. In this case, the character class object returned by tre_ctype() is actually a function which gets called by tre_isctype().

You can find the macros that control this in tre-internal.sh. Search for SYSTEM_WCTYPE.

tre_ctype_t tre_ctype(const char *name)
{
int i;
for (i = 0; tre_ctype_map[i].name != NULL; i++)
{
if (strcmp(name, tre_ctype_map[i].name) == 0)
return tre_ctype_map[i].func;
}
return (tre_ctype_t)0;
}

It is prototyped as returning a character type, but if name is found, it returns a pointer to a function. The parsing code behaves as if it returned a character (I think). Could you possibly explain?

Thanks Steve

I have no problems downloading files from the web interface.

Downloading the files from the darcs web interface by clicking on the ‘plain’ link doesn’t work either. What I actually got were HTML-decorated text (< garbled with &lt\;) rather than plain text.

Downloading from the browser's view-source page doesn't work either. This time the server refuses to send data to the browser.