New error in old Rule after updating OH

1

Hi there. One of my Rules has stopped working with the error

DSL model 'plane.rules' has errors, therefore ignoring it: There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.

I think I’ve been able to narrow down the erroring bit of code, but unfortunately the error seems to be occurring in a function that was kindly written for me by Rich Koshak, one of the smart people on here. The Rule has worked flawlessly since he wrote it in April 2024 and has stopped working in the last week or so. I don’t understand the error and I must ask for help. Here’s the few lines of text:

       // Lets use a little lambda to make the next section a little simpler
       // Test the value against the compareTo, if they are the same it's bad
       // so log it out with the passed in message. Return false if valid is false or 
       // isBad is true.
       // Usage: call with the previous result so as soon as one value is bad we mark
       // the whole Packet as bad.


        var isValid = [ value, compareTo, valid, msg | 
            var isBad = (value == compareTo)
             if (isBad) {
//                logWarn(LOGNAME, msg)
             }
             valid && !isBad
        ]

        TxValid = isValid.apply(PlaneICAO_TXT, Packet_TXT, TxValid, "ICAO fail")
        TxValid = isValid.apply(PlaneCallsign_TXT, Packet_TXT, TxValid, "callsign fail")
        TxValid = isValid.apply(PlaneContactAge_TXT, Packet_TXT, TxValid, "age fail")
        TxValid = isValid.apply(PlaneAltitude_TXT, Packet_TXT, TxValid, "alt fail")
        TxValid = isValid.apply(PlaneVertRate_TXT, Packet_TXT, TxValid, "vert fail")
        TxValid = isValid.apply(PlaneLatitude_TXT, Packet_TXT, TxValid, "lat fail")
        TxValid = isValid.apply(PlaneLongitude_TXT, Packet_TXT, TxValid, "long fail")

        logWarn (LOGNAME, "validity {}", TxValid)

        // filter to pass only Packets containing beluga icao prefixes
       if ((TxValid) && ((ICAO_PREFIXES_TXT.contains(PlaneICAO_TXT.substring(0,3))))) {

etc.

I haven’t changed or even edited this code since April 2024 as it Just Works. Until now.

Let me know what other information I can supply.

2

I have temporarily rolled back my OH install to 5.0.0-1 and the Rule is once again working, so I guess it’s a behaviour change in OH?

3

This is a change in the upstream Xtend library. It’s more strict about typing in some places.

Where ever you have a closure (i.e. [ <variables> | <code> ]) you need to provide a type for the variables.

I don’t know the types of these variables for certain but I would guess

[ String value, String compareTo, boolean valid, String msg |
1 Like
4

Thank you very much, Rich. Not only did you write that code snippet above, you debugged it 18 months later.

I simply did not know where to start.