Page Comparison

...

As an example of what can go wrong, consider the wrangler:ruleset_addedinstalled event (discussed also in the Initializing entity variables and Wrangler Full API pages). Whenever a ruleset is installed in a pico, Wrangler will raise this event. The engine will then consider all of the rulesets installed in the pico (including the one just installed). Unless you have a ruleset keeping track of all rulesets installed in a pico, you probably only want the rule in the ruleset just installed to select. The idiom commonly used to ensure this is shown here:

    select when wrangler ruleset_addedinstalled where event:attr("rids") >< meta:rid

...

      raise wrangler event "new_child_request" attributes {
        "name": random:uuid(), "rids": [meta:rid],
        "expr": expr, "txn_id": meta:txnId
      }

In this case the child pico will have a random name, and will have the currently evaluating ruleset installed in itthe same backgroundColor as the parent pico. In addition to these the required event attributesattribute, this rule is asking for two other attributes to be included, named expr and txn_id (this example is taken from the Generate KRL code using KRL page). Once Wrangler has created the new child pico (per these specifications) it will raise the wrangler:new_child_created event (and all rules in all rulesets installed in the pico will have a chance to be selected).

...

The key to making this work is meta:txnId (part of the meta library) which is a unique identifier for this schedule of rules to evaluate. This ensures that this rule will select only one time, when the child pico it asked for is created. So if, later, the developer manually creates a new child pico in the Pico Engine developer UI About tab, this rule will not be selected.

...

    ...
      raise twilio event "send_twilio_sms_message" attributes { ... } // should be twilio event "new_sms_message"
    ...

This way of thinking is also evidence of a misconception: rules are not like procedures which we can call by raising an event.

...

select when phone incoming number re#\d{10}# setting(caller_id)

Here, the programmer expected to bind the name caller_id to a portion of the event attribute named number. But caller_id remains unbound (and thus evaluates to null when used) because no capture group was specified in the regular expression! A simple typo which can lead to a hard-to-find bug. It should have been written:

...