Re: Which newsgroup for json parsing?

On 17/05/2024 05:24, Malcolm McLean wrote:

On 16/05/2024 20:21, bart wrote:

On 16/05/2024 19:53, Scott Lurndal wrote:

=?UTF-8?Q?Josef_M=C3=B6llers?= <josef@invalid.invalid> writes:

On 16.05.24 18:27, Mikko wrote:

On 2024-05-08 13:04:56 +0000, Josef Möllers said:
>

Hi all,
>
I am trying to parse a json string received through MQTT from a
"Shelly Plug S", e.g.
{"id":0, "source":"button", "output":true, "apower":0.0,
"voltage":237.9, "current":0.000,
"aenergy":{"total":0.000,"by_minute":[0.000,0.000,0.000],"minute_ts":1715172119},"temperature":{"tC":41.1, "tF":106.0}}
>
I am trying to use libjson-glib but I can't figure out what to use as
the first argument to json_gobject_from_data()!
I am also looking at libjson-c but cannot find any examples that could
guide me.
>
Thanks in advance,

>
Sometimes it is easier to make a parser than to use an existing one.
In this case I might try LEX.
>

>
Sorry to be nitpicking, but lex is a "lexical analyzer" aka a "scanner",
it can only recognize tokens, eg the brackets, quotes, identifiers etc,
but not structures.
"yacc" (or its "bison" equivalent" would be a parser but definitely too
heavy.
>
What one could do would be to use LEX to recognize the tokens and the
write a recursive descent parser in plain C.

>
I've done full expression parsing and subsequent evaluation with
lex (or flex).  No parser needed.
>

>
You've done 'full expression PARSING', then you say 'No PARSER needed'.
>
A bit contradictory?
>
Clearly parsing IS needed, so either you've used LEX from code that acts as a parser, or it does more than just recognise tokens.
>

Yes.
 I took Ben's advice and completely rewrote my XML parser wirh a formal lexer and recursive descent grammar. It was good idea, even though XML is simple enough to get away with a ad hoc approach.

'Deceptively simple' might be more apt. These schemes are always a bit more involved than they look. Although this is also to do with the subsequent representation than just parsing.
Isn't this the one with optional open/close tags, and optional attributes when those tags are provided?
Fortunately I've haven't had to work with XML for years. It is anyway an ugly format and pretty much unreadable even for humans, with the actual data barely discernable amidst all the tag clutter. Here's a real example:
     <Declarant>
         <Declarant_code>00013464-00002735</Declarant_code>
         <Declarant_name>
             ....
         <Declarant_representative>
             <null />
         </Declarant_representative>
         <Reference>
             <Year>2017</Year>
             <Number>001A</Number>
         </Reference>
     </Declarant>