I think an mspec-aware editor would eliminate most oft he hard to find difficulties. Also I will probably submit a PR to the antlr4 languages repo, as the folks there promissed to give it a spin to iron out the quirks of our lanuage. After all none of us are Antlr4 experts.
But I am sure that we'll sort out these difficulties. However with the Editor ... well we just need people to work on that. And any form of help on the documentation is greatly appreciated. Chris -----Ursprüngliche Nachricht----- Von: Łukasz Dywicki <[email protected]> Gesendet: Freitag, 8. Januar 2021 20:16 An: [email protected] Betreff: Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff Hi Chris, I don't mind mspec as a tool. I do see it to be a game changer and it is a real enabler to write more protocols. I do believe it is a major invention which makes things much better and viable. I am also well aware of troubles any first time contributor faces when his excitement leads him to write first protocol. He or she gets a slap, after a slap. My concerns are not that the tool is wrong. As I said, its great, but rather hard to use when you do it first and second time (third probably too). After all - copy-paste of bigger or smaller chunk from somebody else mspec eventually leaves you with non-working build and no idea what went wrong. Writing first frame which does not use discriminator is straight, but no protocol is so simple. You probably remember mspec documentation PR I made against build-tools repo which put more context into how protocols are constructed and how mspec fits into that. (you can blame me for not bringing it to main repo) To outline troubles I found which are worth to document for people who start. I had number of situations when my mspec seemed fine, was parsed with no error but some of types got swallowed. I had then to use IntelliJ and check type after type to find where I made a mistake. It took me quite a bit before I learned that I should be starting from last generated type before swallowed one. Everyone who wrote mspec also found some reserved names which cause mspec parser to silently fail. However it is not obvious and can depend on actual template used to generate code. We also have no documentation on serializer test framework which is great in verifying binary payloads. It definitely makes sense to promote (document) these parts to gain other developers traction. I am also one to blame cause once I promised that I will write down my "first timer" experiences and so far haven't done. I do not even want to start on conversation context/netty stuff cause its second barrier we have and which have own quirks people learn over time. In order to shift load from you and distribute it over others we need to get more people working with mspec and other protocols. They will help project move forward only if them or their companies will achieve own goals at the same time (ie. have custom protocol they want). Surely getting more users taking PLC4X API and interacting with their hardware is important but there is quite long way from using project to maintaining its parts. With regard to tooling - if we have cmake in plc4cpp/plc4c/plc4not its final time to call Bjorn to the table. ;-) I do not consider code generation as an blocker. It is not prettiest but I got into troubles there much less often than with other parts. Best, Łukasz On 08.01.2021 12:22, Christofer Dutz wrote: > Hi Lukasz, > > do you really think mspec is a "show stopper"? ... cause I thought of it more > as a "game changer" and an "enabler". > Cause let's face it: writing drivers for protocols is not a simple task. With > mspec I think we have reached a simplicity that I haven't seen anywhere > before in this sector. And I think seeing that some of our new contributors > could just checkout and learn from the exising examples and produce their own > mspecs in a short amount of time, proves that it's actually a pretty powerful > tool. > > I think the protocols you were working on we simply just a nightmare to start > with ... no tool will help you with such a task and make the bad dreams go > away. Perhaps if you wrote the dirvers manually you would have been quicker > in case of CAN. > > I agree that we could need a beginners guide, but currently just don't have > the time to write one. I did submit talks and workshops to multiple CFPs now > and I hope that from this I'll be able to prepare some content that we can > use or even that some recordings might come out of it, which we can link. > > And regarding your complaint about using Maven excessively: I agree in the > beginning I tried to mavenize the non-java parts, but if you actually had a > look recently, that had changed more than a year ago. > > Right now every non java part uses the build system native to that language: > - PLC4C uses CMake > - PLC4CPP usses CMake > - PLC4Py (the initial version) uses the Python build system > - PLC4Go uses go > - In my feature/PLC4Net branch you can use the default .Net build > system to build > > Even the default directory stuctures were mostly used. > > You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE of > choice in that particular Language. So I don't quite get the point of your > complaint. > > Yes: in order to generate a new driver in any of these languages, you > also need to setup maven in order to generate the code. I even reduced > the problems here by checking in the generated code for C and Go. So > you really only need to run the maven build to generate, if the mspecs > change or you want to add a new driver. The other reason for the Maven > integration is simply to have the builds run in Jenkins. Of course we > could not do that and setup a Zoo of jobs, each building part of the > project, but as I'm currently the only one actually taking care of > these plumbing tasks, I'didn't want to do that (And I could see for > other projects how bad this actually works) > > You could probably change the requirement to run the maven code-generation, > but for that you would need to implement the code-generation for those > languages/build-systems. Feel free to do so, if this is an itch you feel > needs scratching. > > What do you others think about this? > > Chris > > > > > > > -----Ursprüngliche Nachricht----- > Von: Łukasz Dywicki <[email protected]> > Gesendet: Freitag, 8. Januar 2021 00:23 > An: [email protected] > Betreff: Re: Reflecting on how we volunteer to do stuff > > Its low part of the season. People got locked down in their homes (Poland > just entered new year with another lockdown, Germany is same AFAIK), so I am > not yet worried by "slowdown" you observe. > > I am prime example of someone who has more will that abilities to contribute. > You know I stayed around since long time and eventually made few > contributions. I think there might be few more like me. I agree with you that > making an open community (I think we are) and opportunity to contribute is > necessary to give dopamine shots we all need. > > Now - in terms of low hanging fruits. I saw very few successful initiatives > such this. Main reason why they fail is .. well, people are not often not > even aware of them. Making them listed somewhere in JIRA does not help (how > often do you look in github 'need helps' issues?). > Its mainly about making entry point easier for people who use project. > I know how much effort it was for you to help with Ethernet/IP. You > personally helped me with almost every mspec related contribution I made so > far. I believe that our main "show stopper" is the mspec. Even existing > project staff don't know how to start with it or have troubles with it. If we > could publish beginner guide to mspec that could turn into more people trying > to write their protocols. > > Also we use heavily Maven. While it simplifies life for us (java folks) it > makes problems for everyone else. I recall Bjorn complaining about it for > C(#/++?) stuff. Not all people know how to use it, especially if they are not > from old Java landscape. > Our docs are dug under maven folders making it hard to contribute docs. > Maybe pulling it up could help. > > This are just my free thoughts on how to make it easier. > > Cheers, > Łukasz > > On 07.01.2021 10:28, Christofer Dutz wrote: >> Hi folks, >> >> I'd like to discuss something ... something I have been noticining in the >> last year or so. >> >> We're a cool bunch of people, doing awesome stuff. However momentum in the >> project has sort of slowed down quite a bit. I know we have some great new >> initiatives going on, but let's say it's become a bit quiet around the folks >> which have been involved for a longer time period. >> >> I would like to get more people involved and active in the project. >> Therefore I would like to strart posting low-hanging fruit here on the list. >> >> In the past when I did so, the community was quite fast in raising hands and >> volunteering to do things. However volunteering is one thing, actually doing >> seems to be something else. In my impression we could improve on the >> delivering side. I know we are a volunteer driven community and you are >> therefore contributing voluntarily in your free time or in the time your >> company is paying you. But ... keep in mind: >> >> >> * If you volunteer to do something, probably others will not raise a >> hand to also contribute. If you now don't deliver what you signed up for, >> the others won't either. >> * If you volunteer to do something, I will think that this base is >> covered and not jump in (I don't want to interfere in every initiative, but >> I am happy and willing to help if help is needed) >> >> So could you please do me a favour? >> >> If I start posting some low-hanging fruit in the near future, please >> consider if you will also have the time to actually do so, before signing up? >> >> Chris >>
