I started a poc plugin for IntelliJ that I will try to work on when I can, but writing a language plugin that does anything substantial is not easy even when you know the language inside and out, and I do not have full time job time to throw at it.
I can’t guarantee I’ll have anything soon, so I’ll un-assign the jira in case I’m blocking > On Jan 8, 2021, at 15:45, Christofer Dutz <[email protected]> wrote: > > 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 >>>
