I think I do follow your point. I don't mind getting it implemented in a
way which just works.
Maybe below example is not perfect, but shows two optional blocks nested
under each other.
[type DataBlock [uint 16 'size']
[optional 'size > 0'
[implicit uint 32 'length' 'COUNT(data)' ]
Hi Lukasz,
don't understand me wrong ... I would adjust the parsers to do that ... it
would just be the way our generator-internal-model would keep track of it.
Problem is that for optional fields I need to generate the code differently
(pointers to simple types instead of direct variables)
So
I see a valid point to get optional block since way pointed by Ben
causes creation of multiple wrappers.
Assuming that we have nested optional fields:
[type OptionalBlock
[implicit uint 32 'length' 'COUNT(data)' ]
[array int 8 'data' count 'length' ]
]
[type DataBlock [uint 16
And for the record ... I'm totally +1 on this ;-)
-Ursprüngliche Nachricht-
Von: Christofer Dutz
Gesendet: Mittwoch, 25. August 2021 13:06
An: dev@plc4x.apache.org
Betreff: [DISCUSS] Change the way we use "optional"
Hi,
as the discussion just came up on Slack ... taking it where it
Hi,
as the discussion just came up on Slack ... taking it where it belongs ... on
the list ;.)
So the problem was, that it's difficult to have anything optional that is not a
"simple" field.
My Idea would be to change the way "optional" is used and to convert it into a
wrapper element. It
Hi,
thanks Otto
--gustavo
- Mensaje original -
> De: "Otto Fowler"
> Para: "dev"
> Enviados: Martes, 24 de Agosto 2021 19:22:49
> Asunto: Re: AW: AW: Nifi integration record oriented processor for reading
> ok, new review up
>
> From: Otto Fowler
> Reply: Otto Fowler
> Date:
Łukasz Dywicki created PLC4X-311:
Summary: ADS driver lost with short replies for read requests
Key: PLC4X-311
URL: https://issues.apache.org/jira/browse/PLC4X-311
Project: Apache PLC4X
