Let’s keep the grammar the same where only one of these is allowed. We shouldn’t have any differences and the v1.1 code generator should do something reasonable for a type that would be a service for v1.0 but a related pair in v1.1. What “reasonable” is, I’m not exactly sure just yet.
I think we’re on the same page then. I think the first approximation of “reasonable” is the inference of two distinct but related types, where the actual meaning of distinct but related is yet to be defined.
An update on this project. It is now ready for pre-alpha testers.
Do you want to be the first? Brave!
Download a release for linux or mac (no windows yet. Sorry).
Docs are available here: llvm-dsdl User Manual
Note that dsdlc is the transpiler and has the cyphal 1.0 standard types baked into it so there’s no external dependencies. On mac you’ll need to xattr -d -r com.apple.quarantine after download.
dsdld is the language server and is less well tested then dsdlc but I was able to get it to work with an experimental vscode plugin.
My current focus is validating c on target ensuring we are able to support classic CAN and are generating the same, or better, serdes logic as we currently emit from nunavut The build system integration should also be fairly mature and I think users will be pleasantly surprised at the performance of this native solution.
Just a reminder, this is very experimental but nominally functional. Use with caution.
1 Like
Very interesting. It works! I tested only C so far though.
I couldn’t find facilities for union tag handling; I see there is a raw _tag_ but there is no way to specify a particular option by name. There is also some nontrivial tag validation logic that I am not sure I understand.
I am noticing that we still generate request/responses for ----containing types; are you going to keep it like this for now?
I ran into this warning; would be nice to either extend the limit or avoid full expansion:
zubax_dsdl/zubax/file/Read.0.1.dsdl:49:1:warning: the set of possible values of_offset_exceeds the analyzer’s expansion limit of 4096; assertions referencing ‘offset’ may be evaluated against an incomplete set and could be unsound
The generated code uses unconditional #pragma GCC; why does every file need #pragma GCC diagnostic ignored "-Wdeprecated-declarations"? This seems odd.
There is a bit of style inconsistency where the generated code places the opening brace on the same line while the runtime header places it a new line. A common style would be nice (I think leaving the brace on the same line is best, and in general more compact code is better).
There are generated identifiers with double underscores in them which are technically reserved but I guess it’s still fair use because this is likely the only sensible way to represent namespaces in C.
Nice. I’ll take all this into account and develop fixes! Also feel free to file (or have Claude file) issues in that repo. It’s easy to have Claude burn some of these down if they are in github.
1 Like