On Thu, Aug 21, 2025 at 03:22:23PM +0200, Gabriele Monaco wrote:

On Thu, 2025-08-21 at 14:22 +0200, Nam Cao wrote:

quoted

On Thu, Aug 14, 2025 at 05:08:01PM +0200, Gabriele Monaco wrote:

quoted

Currently the automata parser assumes event strings don't have any
space, this stands true for event names, but can be a wrong
assumption
if we want to store other information in the event strings (e.g.
constraints for hybrid automata).

Adapt the parser logic to allow spaces in the event strings.

The current parser does have a few problems. Not all valid .dot files
are accepted.

I have a patch buried somewhere which removes the custom parser and
instead uses a library. But then it adds a new dependency, so I'm not
sure if it is worth..

Yeah it isn't really robust, I tried to improve it a bit but sure
something is still failing it.
We don't need full dot capabilities, but just extract some keywords,
I'd avoid pulling in a dependency for that.

I'm imagining users would either generate graphs from the
Waters/Supremica tool [1] or copy/edit existing ones, so I'm not sure
they can go that far.

When I tried out the DA monitor, I edited the .dot files directly.

Still that's hacky because some things are just lightly implied by the
code (e.g. initial/final states, edges labels, etc.), so one day we
should at the very least say what DOT is valid and what not.

We could also rewrite the parser using ply with a well-defined grammar and
tokenizer, like how the LTL parser is implemented. Doing it this way would
be easier to validate as well, because the grammar would be mostly
copy-pasted from the specification.

Do you have specific examples of what doesn't work?

Two things that I can remember:

  - breaking long lines

  - C-style and C++-style comments

Not really relevant if you do not edit the .dot files directly like I did.
But these things are valid according to https://graphviz.org/doc/info/lang.html

Nam