Sweth Chandramouli wrote: >Marcus was doing his >version in C, which for performance reasons makes a lot of sense :) I was doing it in C because it's the only programming language I know. :) It wasn't for performance reasons!!! But I think that the approach I was taking would be fast if coded in any language. Remember - you can write slow code in C, too!! >Perhaps a good way to start would be to ignore the implementation >issues for now, and just start building a stockpile of grammars as you >suggest I think that's probably the wrong approach. Unfortunately, grammars tend to drag implementations kicking and screaming along behind them. Unfortunately, it's hard to write abstract parse trees down in a compute-able format without exploring implementation issues. Unless you use BNF - but if you use BNF you've got recursive aspects that probably won't show up in a log message - and SHOULDN'T show up in a log message. >; it should be relatively easy to convert a well-formed grammar to >a lex/yacc syntax, yes? (I don't know, as my C skills are less than >stellar and I've never actually used lex/yacc.) Lex/Yacc produce static parsers. They're compiler/parser generators and I think you'd be taking the wrong approach to use them. What I'd suggest is developing a subset of a BNF grammar (see my other post which includes some examples) that lets you specify log parse trees. Then use lex/yacc to write something that parses the parse trees and then build a tree evaluator (also described in my other post) to execute against them. > (I also started a conversation this morning with Damian >Conway and Mark-Jason Dominus about a faster way to implement a parser >in Perl, using iteration rather than recursion; In parsing, iteration/recursion are implementation details. What will make your parser fast or slow is how effectively your evaluator trims off parse tree branches that can't be reached. If you consider the totality of all log messages as a big parse tree you'll realize there's a heck of a lot of optimization you can perform in parsing it! Then the next trick is writing the knowledge-base. :) mjr. --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Wed Jun 05 2002 - 08:07:53 PDT