On Thu, 2022-01-06 at 10:59 -0500, Fred Decker wrote: > > I don't know if there are other forks or other completely > separate decoders for DCC, but the only one as far as we are > concerned is the LittleYoda GitHub repository. I will ask > Roland to make a PR there so we are all working from the same > master.
Roland appears to have the most comprehensive implementation. Its relation to littleyoda's was unknown to me but was made clear in recent messages here. Had vague memories of benedikt in a github PR. Which (from my POV) suffered from not being immediately acceptable and then was left behind because more work was needed and other implementations became available and the submitter was not available for discussion and those who are expected to take it are not familiar with the subject. There is no strict need to move repositories or "merge" different implementations' code base, assuming that you can collect a list of implementations and check their feature parity and determine which of them is preferred, and whether one or two additional features could get added to cover everything that was covered in existing implementations. It's more about reasoning and confidence and less about tooling. If the common repo helps you then by all means go ahead and do it. Your choice. A reasoned statement that Roland's version is _the_ implementation to take, then that's as good. Ideally those "applicants" whose submission "gets rejected" would be aware and could agree, or that it's obvious that one implementation is a subset or obsolete or incorrect or ... whatever the reason is to not pick it. > I will look into how to add a Wiki page to your site. You are > the founder or one of founders of Sigrok, yes? I was trying to > find the context for your email. No I'm not, and no I'm not. And my message was a reply to another ML message. What happened to email clients that they cannot keep threads any longer? It's such a pity. :( Not the mail client's users' fault though when even the client's authors no longer are aware of the email protocol's proper operation ... > I asked my parents, but they did not fully understand your last > paragraph either regarding the sigrok structure of dumps, > tests, etc. ;) But I'll look into it to learn more. The sigrok project consists of several components which are kept in separate git repositories. It's easily(?) seen in the web browser: sigrok.org -> search for "source -> second match after "OpenSource" -> https://sigrok.org/gitweb/ -- this is where the project's source code lives and where the components are seen. For this specific DCC discussion three things are essential: The Python implementation of a protocol decoder, typically kept in libsigrokdecode. Example captures for users to see and for developers to use, kept in sigrok-dumps. And the test infrastructure which uses the PD and dumps, kept in sigrok-test. The decoder HOWTO refers to these parts, and discusses their importance: Dumps should go first, they don't "depend" on the presence of a decoder, they are useful to have during development of decoders, nice to have for other users to explore. Decoder implementations go afterwards, while dumps are essential for reviews. Not everybody has the hardware to capture sessions themselves, or the even more special setup to observe a protocol's specific traffic. Tests would ideally be provided by people who are familiar with the protocol (read: submitters), but might as well get created by developers in the simple cases. PD authors may find this separation inconvenient, and "just" start a single repo where they put everything together. That's fine for personal use, but results in extra work on maintainers' sides. Which can get reduced by creating subdirs in the submitter's repo which at least better correspond to the sigrok project's layout, set of files and doc style etc etc. > The DCC protocol (Digital Command Control) is [ ... ] That's a good candidate for the collection of information at a "more persistent" place. Chat is volatile, ML often is considered volatile, too. That's why the wiki page for protocol decoders is the best place to put this. Thank you for providing that context here as well, so that readers of this ML thread know this decoder is about model railways. The "DCC" term is also used in the ARM hardware context, where it refers to a debug channel. That's why I feel that even the "short name" of the decoder should reflect model railroad to reduce ambiguity. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
