Hi Geoff, The W3C test suite contains many regex tests, particularly this large bucket [2] of tests contributed last year. That should give you a pretty good selection though beware that some of the tests are invalid. The known problems are documented in the W3C's Bugzilla here [3].
As for the code, one thing that may not be obvious is that it needs to be thread-safe. This is because the RegularExpression objects are cached in the schema grammar which could be shared with several parsers and validators. To avoid having many large synchronized blocks, the matching code keeps its state local to the call stack. Hoping that's the approach you've been taking. Thanks. [1] http://www.w3.org/XML/2004/xml-schema-test-suite/index.html#releases [2] http://dev.w3.org/cvsweb/XML/xml-schema-test-suite/2004-01-14/xmlschema2006-11-06/msMeta/Regex_w3c.xml [3] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=XML+Schema+Test+Suite&content= Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] "Geoff M. Granum" <[EMAIL PROTECTED]> wrote on 06/25/2007 04:15:27 AM: > (If you don't care about the particulars, but have some Regex's you can > contribute, jump to the code bit. Thanks) > > I have two implementations to test; one is a (somewhat) naive linked list > stack manager, the other is (as yet) still recursive. > > The former works, but I put it together as a proof of concept and don't > trust it much. Fifty-two return points in one method is a tad much. > Implemented as a raw java.util.Stack is ten times as slow as the original, > and creating a private static LocalStack class as a LinkedList is twice as > slow. > > Though, 10K runs of the first thousand chars of the two example regex > patterns take ~1.2 and 2.6 seconds, respectively. So .12ms and .26ms per > run. I'm rather set against ANY performance decrement, or I'd have just > verified that code and moved on. > > The latter implementation is a refactor of the method to a single point of > exit. THAT goal is working, now I have to make sure that I can add values > to an internal stack manager without blowing away any state -- some of the > CASE statements are a mite obtuse, and I don't like using breaks much. > Breaks also seem to affect the ability of the optimizer to do its job, as > the last CASE I modified (op.CLOSURE) gave a 10% performance boost without > it. Although I'm suspicious, as it's late and now the stack overflows > somewhat (ok, a lot) earlier than before. I did add a number of variables, > so it's possible I made no mistake in the logic (I'd better not have!). > > --- The request part --- > > Regardless of the final form, I need to populate a test library: > > I have a few regular expressions lying around, and I figure I'll parse in > a few of my XML files and modify the RegularExpression class to dump > anything it sees to a file... I still doubt I'd have more than 20, and > none of them shockingly complex. > > So if you could send me your favorite regular expressions, along with a > couple of stings to match them against (some pass, some fail, but indicate > which), it would be a big help. > > Even better, if you could format them like this sample: > > testCases.add(new TestCase( > "Overall description", > "Your Regex Pattern", > new SubCase("A description", shouldPass, "matchString" ), > new SubCase("A description2", shouldPass, "matchString2" ), > ... more SubCases ... > )); > > I would be able to paste them straight into the unit test and run them. > The SubCase argument uses varArgs, so add as many as you want/will. Feel > free to add your 'contributed by:' to the overall description area for > credit... Though I'd remind you not to include a parsable (or any, lest > random-someone ask you for help later) e-mail address on this list, as it > is public and archived. > > My own direct e-mail address is (my first name @ my last name).biz. And if > someone has written a parser for THAT, they can have it. > > The more complex your tests the better, for the beat down. Tailored > regex's would be grand for focused testing (e.g. the simplest lookahead, > lookbehind, singleline, multiline, etc). But I figure that's asking for > real work. > > Also, or instead, if you have a 'regular expression rich' schema and > conforming xml file that you can send (think 'might become public'), I > should be able to parse those out without much trouble. > > And yes (obviously), my test library uses 1.5 features... I'll convert it > if the changes are approved for commit. Keeps me sane. > > Of course the changes to RegularExpression are using JDK 1.3 as a target, > as that is the lowest I've available. My memory of the differences between > 1.2 and 1.3 are fuzzy, but I don't think anything I'm using has changed > since 1.0. My only real concern is that my JVM has a better optimizer and > could be hiding poor performance that I induce. > > > Thanks much, > -- > Geoff M. Granum > 760-534-1636 > Portland, Oregon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
