Hello Cyphal Community! I am an intern for this summer working on developing a local linter engine for PyDSDL. For this project’s scope, I have several formatting and alignment related rules I want to implement. However, I want to hear what you as a whole think and receive some guidance as well.
Formatting: To get started, I wanted to first complete an easy rule, which would require the user to have a copyright as the first line of their code.
Alignment: In the case of sealed directives, the linter would warn the user about sub-optimal alignment. Usage of void padding or reordering would be my approach as a standard. Suggestions on the alignment standard would be appreciated.
I will continue to update you all with their status and what their application to PyDSDL will mean for future Cyphal file standards. My primary focus is on .dsdl file support.
This is an interesting idea. So, we’d define a set of hooks appropriate for various linters to be developed? Would linters be injected (e.g. via Pluggy) or would you have to manually register linters with the library before invoking it?
Current plans are to host the linter within PyDSDL, but in the future it is very possible to have an independent API host the engine. I will be using a fork of PyDSDL for now. If it falls within the scope, I hopefully merge a hooked version of the linter. I’m absolutely open to creating a new repo for it once I know what I’m looking for.
Reading back, I realize I wasn’t being concise with what I was asking in regards to the formatting rule. I was asked to address the sub-optimal alignment caused by void padding. I’ll be referring to Figure 3.7.5.1 from the Cyphal Specification.
Based off this diagram, Cyphal is reading the bytes in little endian but the bits in big endian. Will forcing the user to change the order of the values in the DSDL files cause complications within PyDSDL or even into Nunuvat? What sorts of problems do unoptimized bytes cause for performance? Does it cut bus bandwidth for example? And what specific bit/byte orders I should be concerned with as well? I have some ideas in mind but I would like some feedback before I begin my approach.
Depending on the extent of the functionality implemented in the linter, it may be difficult to merge it into PyDSDL, because PyDSDL is designed to be a parsing front-end and any further processing would be outside of its scope. It may be a good choice for the initial experimentation but I would cautiously advise against building anything other than a prototype inside PyDSDL.
Both bits and bytes are little-endian. The reason it looks otherwise at first glance is that Arabic numerals are written in the big-endian order: 123 = 100 + 20 + 3, not 321, which would make a lot more sense in languages with the left-to-right writing system. My understanding is that this weirdness is because the modern Arabic system was borrowed from languages with the left-to-right writing direction but whoever did the borrowing neglected to flip the direction the numbers are written. I could be wrong, though.
