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: > > On Thu, Aug 14, 2025 at 05:08:01PM +0200, Gabriele Monaco wrote: > > > 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
