David House wrote:

Hi all. I need a decent regex library and JRegex seems the perfect choice: simple API, yet well-featured, as well as PCRE support.

I "maintain" Text.Regex.Lazy ( http://sourceforge.net/projects/lazy-regex ) so I would mention it does not have full PCRE support. The module's documentation ( summarize here http://sourceforge.net/forum/forum.php?forum_id=554104 ) explains what it does have. In summary of summary: For simple Regex usage (with capture) the Text.Regex.Lazy.Compat module replaces Text.Regex with a better implementation. For simple expressions where a DFA works, the CompatDFA is fastest. For fancier Regexes (such as using lazy pattern with ?? *? and +?) the Text.Regex.Lazy.Full extends Text.Regex.Lazy.Compat. For much fancier regular expressions (e.g. PCRE) you would need to add two hopefully simple pieces: (1) Extend the parsec code used to comprehend the meaning of the regex string. (2) Extend the code that produces the Parsec parser that implements the desired matching semantics. (3) Test cases for the expanded syntax and semantics. Note that Text.Regex.Lazy is an all Haskell solution. There are other haskell projects that wrap the standard regex/pcre libraries. The problem is that marshaling [Char] to c-strings is quite slow and cannot be lazy, so you may want to use the new Fast Packed String (now ByteString) library with foreign functions to call the pcre c-library.

I want to use it on a simple project which involves input files a little larger than typical -- between 100KB and 500KB -- but still small enough so as to not present a problem.

However, and I'm fairly sure JRegex is at fault here, my program segfaults on an input of ~230KB. Has anyone used JRegex successfully in this way before? If so, what tactics did you use?

Thanks in advance.

On Jul 1, 2006, at 6:27 AM, David House wrote:

Hi all. I need a decent regex library and JRegex seems the perfect choice: simple API, yet well-featured, as well as PCRE support. I want to use it on a simple project which involves input files a little larger than typical -- between 100KB and 500KB -- but still small enough so as to not present a problem.

However, and I'm fairly sure JRegex is at fault here, my program segfaults on an input of ~230KB. Has anyone used JRegex successfully in this way before? If so, what tactics did you use?

Thanks in advance.

I have no idea how JRegex works, but regular expressions are normally implemented using finite automata, so the input size should be immaterial. Gregory Woodhouse gregory.woodhouse@sbcglobal.net "Judge a man by his questions not his answers." --Voltaire

On Sat, Jul 01, 2006 at 02:27:17PM +0100, David House wrote:

Hi all. I need a decent regex library and JRegex seems the perfect choice: simple API, yet well-featured, as well as PCRE support. I want to use it on a simple project which involves input files a little larger than typical -- between 100KB and 500KB -- but still small enough so as to not present a problem.

However, and I'm fairly sure JRegex is at fault here, my program segfaults on an input of ~230KB. Has anyone used JRegex successfully in this way before? If so, what tactics did you use?

This is due to the fact it tries to build the whole string in memory before running the regex on it. Originally, this limitation was due to the fact the API provided by the regex binding in fptools was insufficient to allow chunking of data properly. now that JRegex uses its own FFI binding, there is no reason this limitation should still exist. I will happily accept any patches fixing this. There was some talk of integrating JRegex into the main tree. It should be noted that there are 2 somewhat independent things included in JRegex, a better FFI binding to posix expressions as well as the PCRE library. and the general framework for providing the =~ and =~~ operators. All that is needed is a smarter FFI binding, or even just using another one that exists like Text.Regex.Lazy. it is straightforward to add the instances needed to use the JRegex fancy syntax. John -- John Meacham - ⑆repetae.net⑆john⑈