v2.0.0

v2.0.0

This release features a breaking API change, which has forced us to bump the major-version.

This release features a major rework or our internals:

• Previously we parsed the source given to us into an AST.
• We then walked the AST, evaluating as we went.

Now we do something different:

• We parse the source given to us into an AST.
• We then walk the AST, to generate a series of bytecode operations.
• Finally when the script is run we execute the bytecode operations in a simple virtual machine.

This new approach has some additional overhead when we're performing our setup, but if the script is reused even one time then that overhead pays off; because running the virtual machine is super-fast compared to walking the AST tree.

All the tests and examples have been updated, but to update you just need to call the Prepare() method, after New() and before Run().

v1.5.2

v1.5.2

This release is aimed at making our benchmark results a little faster, as noted in #32, by short-circuiting if we can the || and && operators.

In short we can skip evaluating b in the following case if a is false:

a && b

Similarly if a is true we can skip b:

a || b

v1.5.1

v1.5.1

This release improves the parser to change the precedence of && and ||. This was identified in #31, and resolved in #33

v1.5.0

v1.5.0

This release was issued in error, before merging a pull-request rather than after. Rather than reuse the release ID, or delete it, I'll leave it in-place.

v1.4.0

v1.4.0

This release updates our utility command, cmd/evalfilter such that it can now dump the AST generated by parsing a program. This is useful when looking for syntax-errors, or investigating problems identified by fuzz-testing.

Otherwise I've added three new mathematical operators:

• % - Modulus
• √ - Square root
• ** - Power

These work as you'd expect if ( √9 == 3 ) { print("Mathematics is fun\n"); }

The final update in this release is the addition of a GetVariable method which mirrors the SetVariable already present. Using this new function you can run a script and retrieve any variables which the script has created/updated. This can be useful for passing state in both directions between a host-application and a user-written script.

v1.3.0

v1.3.0

This release is a minor update to v1.2.0, making minor changes to the documentation and adding three new built-in functions which scripts may call:

• lower(field|string)
  • Return a lower-case version of the given string, or object/structure value.
• type(field|object)
  • Return the type of a given field from the given object-structure, or the given object.
• upper(field|string)
  • Return a lower-case version of the given string, or object/structure value.

These are useful for user-scripts.

v1.2.0

v1.2.0

This release adds the new built-in function match which allows a regular expression to be tested against a string, or field.

You can make a regular expression case-insensitive via the (?i) prefix:

if ( match( Name, "(?i)^steve$" ) ) {
    print( "Steve is present\n");
} else {
   print( "Steve is not present.\n");
}

Note that the string/field passed to this function will be split by any present newline-characters, and each piece matched separately. This allows "^" and "$" to work in a natural fashion.

v1.1.0

v1.1.0

This is a minor update which improves the use of functions in conditional-tests. This means that the following works as you would expect:

if ( Function() ) { print("OK\n"); }

Where Function() is a user-implemented function, added by a host application. Specifically the test passes if the function returns a non-empty string, a non-zero number, or a boolean true-result.

There have been several fixes to the parser to avoid infinite loops when parsing malformed input:

• Unterminated string-literals are handled correctly.
• return statements without a trailing semi-colon are reported correctly.

These issues were identified via the use of fuzz-testing, and using a fuzz-tester against the code is now documented in FUZZING.md.

release-1.0.0

release-1.0.0

This is the first stable release, having recently had most of the internals replaced and overhauled I'm happy to commit to keepign the user-facing API stable:

• This mostly means the evalfilter package.
• But also includes the object-package which is used in the implementation of user-added golang functions.

The code is stable under load, and has been running in production reacting to thousands of incoming Slack messages, so while there might be issues the system as a whole does what I need it to do:

• Dynamically choose which events are worthy of special-action.
• Via the use of simple human-readable & editable scripts, rather than golang code.