3 ms·
Obviously the first thing to say is that logs should be structured, by design, at least for individual modules and cohesive subsystems. So maybe that's not pos
by mikhailfranco 3y ago
Obviously the first thing to say is that logs should be structured, by design, at least for individual modules and cohesive subsystems.
So maybe that's not possible, because other modules are under 3rd party control (even within your org).
At my last job, I developed a test library implementing Regular Expressions for Events (regev). It allowed a test case to specify a regular expression grammar for the events it expected to be emitted by a test execution.
For example, it could wildcard over the unknown junk events from other nested libraries (the whitespace of the event world), and quantify over repeated emissions from loops (0,1,n,?,+,*).
My previous employer is bankrupt, so maybe it could be open sourced now, depending on who ends up with the IP.
- bafe 3y agoIt sounds like the Match_recognize clause in SQL:2020, where you can define regex patterns for sequences of rows. It's a pity it's not available in most databases yet
- mikhailfranco 3y agoP.S. regev had its own unit tests that used ycombinator to generate event streams dynamically specified in the test - just thought I should mention that on this forum :) I have only used ycombinator one other time: for parsing text using grammars defined at runtime. I think that is the main use case for yc. It's in a personal side project, but will be open sourced real soon now.
- PhilipRoman 3y agoThat is a really cool use of regexes. I feel like regexes (or more generally, grammars) still have lots of unexplored potential. I was toying around with making a strongly typed queue system based on grammars. Every time an element is written or read from a queue, the type gets updated (linear types help here).