(Classic) Tips for Developers

There are a few things that will make writing KRL code easier. 

Hosting Code

Because the rules engine reads your KRL program from the Web, it has to be available online. You can host it anywhere, but Github works especially well. See these instructions for more information about how to use Github to host KRL

Flushing the Ruleset

Where ever you host your code, the rules engine caches it after parsing it for better performance. That means that you need to flush your code from the rules engine cache whenever you update it. You can do that using the following URL:

http://cs.kobj.net/ruleset/flush/RULESETIDHERE.prod

So, if your ruleset ID (after registering your code) were b16x17, you'd call this URL:

http://cs.kobj.net/ruleset/flush/b16x17.prod

You can provide a semicolon delimted list of RIDs after /flush/:

http://cs.kobj.net/ruleset/flush/rid0.prod;rid1.prod;rid2.prod

This is slightly simplistic. You can register rulesets with different suffixes. The default is prod. You'd change prod in the preceding URL to whatever suffix you used if you took advantage of that feature.

As noted in the Github instructions, flushing rulesets can be automated using post-commit hooks. 

Parsing KRL

You need to be able to check your ruleset for parse errors before checking it in. Debugging syntax errors on the rules engine is a messy business. 

There are two ways to do it.

  1. You can use the online validation form and cut and paste your KRL into it. 
  2. You can download and install the KRL parse tool on your own machine and run it from the command line. 

The second method is recommended for any serious development.

 Development Environments

(Classic) KRL Programming Tools lists several development tools that people have built. They are maintained by their developer and may or may not be in a usable state. 

Debugging

There's a page of debugging tips you should be familiar with.  You should also make use of the tools for test-driven development in KRL. 

Common KRL Mistakes

There's a collection of common KRL mistakes that might help you. 

Getting Info for a Ruleset

KRE provides an API for getting information about rulesets from their RID. You can access this API at

/ruleset/describe/<rid0>;<rid1>;...;<ridn>

KRE returns a JSON hash with information about the rulesets in the semicolon delimited list of RIDs. 

This can be used to compare ruleset versions, determine when a ruleset was last flushed, see the ruleset author, see rules and provided functions, and so on. 

For example:

// /ruleset/describe/a16x66.dev
{
  "a16x66.dev": {
    "number_of_rules": "2", 
    "ruleset_id": "a16x66", 
    "number_of_inactive_rules": 0, 
    "ruleset_version": "dev", 
    "inactive_rules": [], 
    "provides": [
      {
        "type": "function", 
        "function_name": "hello", 
        "parameters": [
          "msg"
        ]
      }
    ], 
    "logging": "on", 
    "description": "\n      Playing with an echo endpoint\n    ", 
    "ruleset_cached": "2015-02-11T22:46:08", 
    "number_of_active_rules": 2, 
    "author": "Phil Windley", 
    "name": "echo", 
    "active_rules": [
      {
        "selector": "select when echo hello", 
        "rule_name": "hello_world"
      }, 
      {
        "selector": "select when echo message input re/.*/ setting (m)", 
        "rule_name": "echo"
      }
    ], 
    "sharing": "on"
  }
}

 

 

 

 

Copyright Picolabs | Licensed under Creative Commons.