Comments are not properly ignored when reading flex decoder configuration blocks

[rct]

In config files, comments beginning with # get filtered out, BUT not if they are part of a decoder { .... } block's key value pairs. Should this an enhancement request or is there some bit of flex decoder syntax that prevents that?

So for example if you try to comment out a line in the decoder or add some doc, you get:

• # my comment on a line by itself -- Bad flex spec, unknown keyword (#mycomment)! (white space was removed in the error message)
• get=name:@24:{1}, # skip the next bit -- Bad flex spec, unknown keyword (#skipthenexbitget)! (note the get added at the end)

[zuckschwerdt]

It is a deficit of the "parser". The whole "block" is parsed as a single string, as if it was given on the command line. I guess a to-end-of-line comment would not work there. We'd need to strip something like /#.*?\n/ beforehand. I.e. at the beginning of flex_create_device(), before getkwargs().

[gdt]

I hear that these days alll the cool kids are using Parsing Expression Grammars.

[zuckschwerdt]

Sounds fun. I've been enjoying Nom and there seems to be a PEG wrapper for it. I might give that a try just to get a feel of PEG.

[rct]

Interesting, seems the simple quick parse a line has been getting the job done.

Somewhat separate question, does the limitation of 8 get= statements come from current parsing limitations or other practical constraints?

[zuckschwerdt]

It should be 16 possible getters. https://github.com/merbanan/rtl_433/blob/master/src/devices/flex.c#L77 A case of simply "good enough" to have fixed number there, no other reason.

[rct]

Hmm, adding the 9th gives me this error:

rtl_433 version 23.11-126-g7f60fff4 branch master at 202405311102 inputs file rtl_tcp RTL-SDR with TLS
Maximum getter slots exceeded (8)!
Use -X <spec> to add a general purpose decoder. For usage use -X help

When I follow the line you pointed to (line 77) it says, #define GETTER_SLOTS 8

[zuckschwerdt]

I confused it with GETTER_MAP_SLOTS… yes it's 8. Is that too limiting?

[rct]

I have bumped up against it. Though it is good motivation to implement a regular decoder instead.