Re: [CODE GEN] Extending the mspec to support arrays terminated by conditions instead of just "length" and "count", and others ...

[Christofer Dutz]

Hi all,

so I noticed that new field types require us to re-release the build-tools, so 
I would like to add a few more types:
- virtual: Generates the getXYZ() method in the POJO
- manual: Field for which the parse and serialization has to be provided
- manualArray: like an array version of the manual field
- fill: which can be used to insert fill bytes in cases like the S7 where the 
payloads have to be word-aligned (If an odd number of bytes is transferred, a 
fill byte is added to make it even again) 
- checksum: which works like an implicit, but also compares the value read 
during reading with the calculated value and throws a Checksum error if this 
doesn't match

In the mspec format I'll rename the "field" to "simple" as this sort of aligns 
more with the general structure of the rest. Same with the "arrayField" which 
I'd like to call "array".

Chris


Am 07.08.19, 18:23 schrieb "Christofer Dutz" :

Hi all,

In the train (Which I didn't miss) I had an idea.

I'd like to add a "virtual" field which generates a get-method without any 
property to back it in the pojo.
This can be helpful when working with the model objects.

It could look something like this:
[virtual uint 8 'hurz' 'field1.size + field2.size - 5']

Which generates this in the pojo:

public short getHurz() {
return (short) (getField1().getSize() + getField2().getSize() 
-5);
}

For the other case we have a normal field, but want to externally or 
manually map the content form and to the field.
So how about "externalField" or "manualField" and "externalArrayField" or 
"manualArrayField" for single or multi-value fields.

For these fields I would suggest to give them two expressions: One 
parsingExpression and one serializationExpression ... the pojo part would be 
identical to the normal field and arrayFields.

Chris


Am 07.08.19, 18:14 schrieb "Christofer Dutz" :

Hi Julian,

As all of the elements are "fields" I thought it as a virtual field... 
That's why I suggested that. If you go for "external" it would be an external 
field, which is sort of not quite what it is. And the "whatever name it has" - 
field doesn't have to call external code... It could just be an expression 
which is evaluated... Just in the pojo instead of the io component.

But I'm not insisting on "virtual" ;-)

Chris

Holen Sie sich Outlook für Android


From: Julian Feinauer 
Sent: Wednesday, August 7, 2019 11:49:45 AM
To: dev@plc4x.apache.org 
Subject: Re: [CODE GEN] Extending the mspec to support arrays 
terminated by conditions instead of just "length" and "count", and others ...

Hi Chris,

first, thanks for the update here.
I already checked your results this morning with Volker and have to say 
THANK both of you for your effort, we are pretty close on closing this off : )

For the rest... I agree with your suggestions. Perhaps instead of 
'virtual' we could use 'external', as we call external code.
It would be good for us to also generate Interfaces for those externals 
as this would make it easier to add everything in another language, if we 
generate the "skeleton" like that.

Julian

Am 07.08.19, 11:04 schrieb "Christofer Dutz" 
:

Hi all,

yesterday Volker and I meet in our codecentric office in FFM and 
worked on a DF1 driver based on mspec and generated code.
Here we learned that we need to extend the arrayField to support a 
“terminated” type in addition to the existing “count” (Explicit number is 
specified before the array in the data) or a “length” (the length of the 
payload in bytes is specified before the array in the data).
For the DF1 protocol we also need to be able to continue adding 
elements until a termination condition is true (In this case reading the 0x10 
0x03 byte sequence). So I’ll be extending the spec format with this feature. I 
would suggest not to use some sort of termination characters, but to call a 
function which tells the array to read another element or not.

Also did we encounter a situation where byte data is escaped … so 
in this case if the data contains the byte 0x10, this has to be escaped by 
duplicating it to 0x10, 0x10. This makes things a little tricky as we have to 
ignore the second 0x10 for the termination condition.

Last thing we noticed: for calculating the CRC checksum, it would 
be good to have a new type of field in the spec. One that isn’t used for 
parsing or serializing, but for referencing it (in expressions for example) … 
Not sure how to call it tough … was thinking of “virtual”

   

Re: Usage of Netty - JSerialcom-Bridge

[Niclas Hedhman]

The so called Category A licenses are allowed to be included as a
dependency AND/OR in source form of Apache projects, but we must respect
the language of those licenses. MIT is a relatively aligned license, which
in essence differs from ALv2 in the patent clause (IIRC, however IANAL).

There is also a social aspect to expropriating external codebases; If the
authors explicitly wish for the codebase to be placed into PLC4X, then
AFAIU an ICLA is nice, but not required. If the original authors don't want
the fork, ASF has historically followed that even if it legally could fork
it. IF all the authors are onboard for the codebase to come to ASF, then
try to do a "Software Grant" and take it through the Incubator's process of
codebase donations, and TRY to get the authors to change the license to
ALv2.

>From experience, if they have a few hours of time available, most are happy
to do it. If they are strapped on time, someone can have a quick talk with
them, and do the actual work on their behalf. That is also often
appreciated.

// Niclas

On Wed, Aug 7, 2019 at 11:16 PM Christofer Dutz 
wrote:

> Hi Julian,
>
> It seems the files am have apache headers, but the pom says mit license.
> Perhaps Justin can help us with what's allowed and what's not.
>
> It would be cool to have it in a location we can update and release it on
> our own. Cause even if the maintainer is accepting PRs, we don't know how
> often he releases.
>
> We could put it alongside the raw socket stuff.
>
> It's only one contributor, so he could donate everything without too much
> effort.
>
> Chris
>
> Holen Sie sich Outlook für Android
>
> 
> From: Julian Feinauer 
> Sent: Wednesday, August 7, 2019 3:13:33 PM
> To: dev@plc4x.apache.org 
> Subject: Usage of Netty - JSerialcom-Bridge
>
> Hi all,
>
> as we use in our DF1 Code (and also fort he Modbus Code, I think) the
> library: https://github.com/Ziver/Netty-Transport-jSerialComm which is
> under netty license.
> But it quite outdated and only “maintained” by one guy.
> I contacted him asking if he accepts PRs and also suggested, that we
> probably move / replicate the code in our code in a tools module (or
> integrate it in the Serial-Netty Stuff somewhere).
>
> What do you think?
> The best way, if he agrees, would be to have him sign an ICLA and we could
> simply take the code as is and refactor it perhaps a bit and adapt it to
> newer versions.
>
> Otherwise, I think it will be hard to use this lib and we would need to
> come up with an alternative.
>
> Julian
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [432]'

[Apache Jenkins Server]

BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [432]':

Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/432/;>PLC4X/PLC4X/develop
 [develop] [432]"

Re: [CODE GEN] Extending the mspec to support arrays terminated by conditions instead of just "length" and "count", and others ...

[Christofer Dutz]

Hi all,

In the train (Which I didn't miss) I had an idea.

I'd like to add a "virtual" field which generates a get-method without any 
property to back it in the pojo.
This can be helpful when working with the model objects.

It could look something like this:
[virtual uint 8 'hurz' 'field1.size + field2.size - 5']

Which generates this in the pojo:

public short getHurz() {
return (short) (getField1().getSize() + getField2().getSize() 
-5);
}

For the other case we have a normal field, but want to externally or manually 
map the content form and to the field.
So how about "externalField" or "manualField" and "externalArrayField" or 
"manualArrayField" for single or multi-value fields.

For these fields I would suggest to give them two expressions: One 
parsingExpression and one serializationExpression ... the pojo part would be 
identical to the normal field and arrayFields.

Chris


Am 07.08.19, 18:14 schrieb "Christofer Dutz" :

Hi Julian,

As all of the elements are "fields" I thought it as a virtual field... 
That's why I suggested that. If you go for "external" it would be an external 
field, which is sort of not quite what it is. And the "whatever name it has" - 
field doesn't have to call external code... It could just be an expression 
which is evaluated... Just in the pojo instead of the io component.

But I'm not insisting on "virtual" ;-)

Chris

Holen Sie sich Outlook für Android


From: Julian Feinauer 
Sent: Wednesday, August 7, 2019 11:49:45 AM
To: dev@plc4x.apache.org 
Subject: Re: [CODE GEN] Extending the mspec to support arrays terminated by 
conditions instead of just "length" and "count", and others ...

Hi Chris,

first, thanks for the update here.
I already checked your results this morning with Volker and have to say 
THANK both of you for your effort, we are pretty close on closing this off : )

For the rest... I agree with your suggestions. Perhaps instead of 'virtual' 
we could use 'external', as we call external code.
It would be good for us to also generate Interfaces for those externals as 
this would make it easier to add everything in another language, if we generate 
the "skeleton" like that.

Julian

Am 07.08.19, 11:04 schrieb "Christofer Dutz" :

Hi all,

yesterday Volker and I meet in our codecentric office in FFM and worked 
on a DF1 driver based on mspec and generated code.
Here we learned that we need to extend the arrayField to support a 
“terminated” type in addition to the existing “count” (Explicit number is 
specified before the array in the data) or a “length” (the length of the 
payload in bytes is specified before the array in the data).
For the DF1 protocol we also need to be able to continue adding 
elements until a termination condition is true (In this case reading the 0x10 
0x03 byte sequence). So I’ll be extending the spec format with this feature. I 
would suggest not to use some sort of termination characters, but to call a 
function which tells the array to read another element or not.

Also did we encounter a situation where byte data is escaped … so in 
this case if the data contains the byte 0x10, this has to be escaped by 
duplicating it to 0x10, 0x10. This makes things a little tricky as we have to 
ignore the second 0x10 for the termination condition.

Last thing we noticed: for calculating the CRC checksum, it would be 
good to have a new type of field in the spec. One that isn’t used for parsing 
or serializing, but for referencing it (in expressions for example) … Not sure 
how to call it tough … was thinking of “virtual”

Chris

Re: [CODE GEN] Extending the mspec to support arrays terminated by conditions instead of just "length" and "count", and others ...

[Christofer Dutz]

Hi Julian,

As all of the elements are "fields" I thought it as a virtual field... That's 
why I suggested that. If you go for "external" it would be an external field, 
which is sort of not quite what it is. And the "whatever name it has" - field 
doesn't have to call external code... It could just be an expression which is 
evaluated... Just in the pojo instead of the io component.

But I'm not insisting on "virtual" ;-)

Chris

Holen Sie sich Outlook für Android


From: Julian Feinauer 
Sent: Wednesday, August 7, 2019 11:49:45 AM
To: dev@plc4x.apache.org 
Subject: Re: [CODE GEN] Extending the mspec to support arrays terminated by 
conditions instead of just "length" and "count", and others ...

Hi Chris,

first, thanks for the update here.
I already checked your results this morning with Volker and have to say THANK 
both of you for your effort, we are pretty close on closing this off : )

For the rest... I agree with your suggestions. Perhaps instead of 'virtual' we 
could use 'external', as we call external code.
It would be good for us to also generate Interfaces for those externals as this 
would make it easier to add everything in another language, if we generate the 
"skeleton" like that.

Julian

Am 07.08.19, 11:04 schrieb "Christofer Dutz" :

Hi all,

yesterday Volker and I meet in our codecentric office in FFM and worked on 
a DF1 driver based on mspec and generated code.
Here we learned that we need to extend the arrayField to support a 
“terminated” type in addition to the existing “count” (Explicit number is 
specified before the array in the data) or a “length” (the length of the 
payload in bytes is specified before the array in the data).
For the DF1 protocol we also need to be able to continue adding elements 
until a termination condition is true (In this case reading the 0x10 0x03 byte 
sequence). So I’ll be extending the spec format with this feature. I would 
suggest not to use some sort of termination characters, but to call a function 
which tells the array to read another element or not.

Also did we encounter a situation where byte data is escaped … so in this 
case if the data contains the byte 0x10, this has to be escaped by duplicating 
it to 0x10, 0x10. This makes things a little tricky as we have to ignore the 
second 0x10 for the termination condition.

Last thing we noticed: for calculating the CRC checksum, it would be good 
to have a new type of field in the spec. One that isn’t used for parsing or 
serializing, but for referencing it (in expressions for example) … Not sure how 
to call it tough … was thinking of “virtual”

Chris

AW: Usage of Netty - JSerialcom-Bridge

[Julian Feinauer]

Hey,

Yeah it's confusing... Pom says mit, Readme says Apache 2 and some files have 
netty license header :)

Let's see what he answers.

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: Usage of Netty - JSerialcom-Bridge
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:

Hi Julian,

It seems the files am have apache headers, but the pom says mit license. 
Perhaps Justin can help us with what's allowed and what's not.

It would be cool to have it in a location we can update and release it on our 
own. Cause even if the maintainer is accepting PRs, we don't know how often he 
releases.

We could put it alongside the raw socket stuff.

It's only one contributor, so he could donate everything without too much 
effort.

Chris

Holen Sie sich Outlook für Android


From: Julian Feinauer 
Sent: Wednesday, August 7, 2019 3:13:33 PM
To: dev@plc4x.apache.org 
Subject: Usage of Netty - JSerialcom-Bridge

Hi all,

as we use in our DF1 Code (and also fort he Modbus Code, I think) the library: 
https://github.com/Ziver/Netty-Transport-jSerialComm which is under netty 
license.
But it quite outdated and only “maintained” by one guy.
I contacted him asking if he accepts PRs and also suggested, that we probably 
move / replicate the code in our code in a tools module (or integrate it in the 
Serial-Netty Stuff somewhere).

What do you think?
The best way, if he agrees, would be to have him sign an ICLA and we could 
simply take the code as is and refactor it perhaps a bit and adapt it to newer 
versions.

Otherwise, I think it will be hard to use this lib and we would need to come up 
with an alternative.

Julian

Re: Usage of Netty - JSerialcom-Bridge

[Christofer Dutz]

Hi Julian,

It seems the files am have apache headers, but the pom says mit license. 
Perhaps Justin can help us with what's allowed and what's not.

It would be cool to have it in a location we can update and release it on our 
own. Cause even if the maintainer is accepting PRs, we don't know how often he 
releases.

We could put it alongside the raw socket stuff.

It's only one contributor, so he could donate everything without too much 
effort.

Chris

Holen Sie sich Outlook für Android


From: Julian Feinauer 
Sent: Wednesday, August 7, 2019 3:13:33 PM
To: dev@plc4x.apache.org 
Subject: Usage of Netty - JSerialcom-Bridge

Hi all,

as we use in our DF1 Code (and also fort he Modbus Code, I think) the library: 
https://github.com/Ziver/Netty-Transport-jSerialComm which is under netty 
license.
But it quite outdated and only “maintained” by one guy.
I contacted him asking if he accepts PRs and also suggested, that we probably 
move / replicate the code in our code in a tools module (or integrate it in the 
Serial-Netty Stuff somewhere).

What do you think?
The best way, if he agrees, would be to have him sign an ICLA and we could 
simply take the code as is and refactor it perhaps a bit and adapt it to newer 
versions.

Otherwise, I think it will be hard to use this lib and we would need to come up 
with an alternative.

Julian

Re: How about adding PLC4X Swag to the Apache redbubble store?

[Justin Mclean]

+1

Usage of Netty - JSerialcom-Bridge

[Julian Feinauer]

Hi all,

as we use in our DF1 Code (and also fort he Modbus Code, I think) the library: 
https://github.com/Ziver/Netty-Transport-jSerialComm which is under netty 
license.
But it quite outdated and only “maintained” by one guy.
I contacted him asking if he accepts PRs and also suggested, that we probably 
move / replicate the code in our code in a tools module (or integrate it in the 
Serial-Netty Stuff somewhere).

What do you think?
The best way, if he agrees, would be to have him sign an ICLA and we could 
simply take the code as is and refactor it perhaps a bit and adapt it to newer 
versions.

Otherwise, I think it will be hard to use this lib and we would need to come up 
with an alternative.

Julian

Re: [CODE GEN] Extending the mspec to support arrays terminated by conditions instead of just "length" and "count", and others ...

[Julian Feinauer]

Hi Chris,

first, thanks for the update here.
I already checked your results this morning with Volker and have to say THANK 
both of you for your effort, we are pretty close on closing this off : )

For the rest... I agree with your suggestions. Perhaps instead of 'virtual' we 
could use 'external', as we call external code.
It would be good for us to also generate Interfaces for those externals as this 
would make it easier to add everything in another language, if we generate the 
"skeleton" like that.

Julian 

Am 07.08.19, 11:04 schrieb "Christofer Dutz" :

Hi all,

yesterday Volker and I meet in our codecentric office in FFM and worked on 
a DF1 driver based on mspec and generated code.
Here we learned that we need to extend the arrayField to support a 
“terminated” type in addition to the existing “count” (Explicit number is 
specified before the array in the data) or a “length” (the length of the 
payload in bytes is specified before the array in the data).
For the DF1 protocol we also need to be able to continue adding elements 
until a termination condition is true (In this case reading the 0x10 0x03 byte 
sequence). So I’ll be extending the spec format with this feature. I would 
suggest not to use some sort of termination characters, but to call a function 
which tells the array to read another element or not.

Also did we encounter a situation where byte data is escaped … so in this 
case if the data contains the byte 0x10, this has to be escaped by duplicating 
it to 0x10, 0x10. This makes things a little tricky as we have to ignore the 
second 0x10 for the termination condition.

Last thing we noticed: for calculating the CRC checksum, it would be good 
to have a new type of field in the spec. One that isn’t used for parsing or 
serializing, but for referencing it (in expressions for example) … Not sure how 
to call it tough … was thinking of “virtual”

Chris

[CODE GEN] Extending the mspec to support arrays terminated by conditions instead of just "length" and "count", and others ...

[Christofer Dutz]

Hi all,

yesterday Volker and I meet in our codecentric office in FFM and worked on a 
DF1 driver based on mspec and generated code.
Here we learned that we need to extend the arrayField to support a “terminated” 
type in addition to the existing “count” (Explicit number is specified before 
the array in the data) or a “length” (the length of the payload in bytes is 
specified before the array in the data).
For the DF1 protocol we also need to be able to continue adding elements until 
a termination condition is true (In this case reading the 0x10 0x03 byte 
sequence). So I’ll be extending the spec format with this feature. I would 
suggest not to use some sort of termination characters, but to call a function 
which tells the array to read another element or not.

Also did we encounter a situation where byte data is escaped … so in this case 
if the data contains the byte 0x10, this has to be escaped by duplicating it to 
0x10, 0x10. This makes things a little tricky as we have to ignore the second 
0x10 for the termination condition.

Last thing we noticed: for calculating the CRC checksum, it would be good to 
have a new type of field in the spec. One that isn’t used for parsing or 
serializing, but for referencing it (in expressions for example) … Not sure how 
to call it tough … was thinking of “virtual”

Chris

Re: How about adding PLC4X Swag to the Apache redbubble store?

[Julian Feinauer]

Haha, I just thought the same wenn reading ComDev __

+1

Am 07.08.19, 09:58 schrieb "Christofer Dutz" :

Hi all,

on the community dev list I noticed that Apache seems to have a swag store 
at redbubble.com:
https://www.redbubble.com/de/people/comdev

I think it would be great to have “Team Toddy” shirts and Coffee Mugs 
available there … what do you think?

Chris

How about adding PLC4X Swag to the Apache redbubble store?

[Christofer Dutz]

Hi all,

on the community dev list I noticed that Apache seems to have a swag store at 
redbubble.com:
https://www.redbubble.com/de/people/comdev

I think it would be great to have “Team Toddy” shirts and Coffee Mugs available 
there … what do you think?

Chris

RE: Next Meetup / Hackathon

[Strljic, Matthias Milan]

I think u are right 

Matthias Strljic, M.Sc.

Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und 
Fertigungseinrichtungen (ISW)

Seidenstraße 36
70174 Stuttgart
GERMANY

Tel: +49 711 685-84530
Fax: +49 711 685-74530

E-Mail: matthias.strl...@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de

-Original Message-
From: Julian Feinauer  
Sent: Tuesday, August 6, 2019 4:17 PM
To: dev@plc4x.apache.org
Subject: Re: Next Meetup / Hackathon

Hey,

I think we have a winner, or?
From what I see the clear favorite is Thursday, 22 of August.
Here we have 7 people (Tim is so so) all others get at most 6.

Should we fix that?
And as location... cc Frankfurt?

Julian

Am 01.08.19, 19:33 schrieb "Julian Feinauer" :

Hey,

Thanks for posting the doodle.
I would leave location open. Cc in Frankfurt had the better location when 
we are more people :)

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: RE: Next Meetup / Hackathon
Von: "Strljic, Matthias Milan"
An: dev@plc4x.apache.org
Cc:

Hi all,

so some anonymous PMC forced me to setup some doodle  . So I just throw in 
some dates where I had time over the next weeks to visit the pragmatic minds HQ 
and to invite some friends .
https://doodle.com/poll/rf3ibkv5cwa7izrd

Best regards
Matthias Strljic, M.Sc.

Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und 
Fertigungseinrichtungen (ISW)

Seidenstraße 36
70174 Stuttgart
GERMANY

Tel: +49 711 685-84530
Fax: +49 711 685-74530

E-Mail: matthias.strl...@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de

-Original Message-
From: Julian Feinauer 
Sent: Monday, July 29, 2019 5:50 PM
To: dev@plc4x.apache.org
Subject: AW: Next Meetup / Hackathon

Hey Matthias,

As you are out official doodle expert... Start it :)

J

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: RE: Next Meetup / Hackathon
Von: "Strljic, Matthias Milan"
An: dev@plc4x.apache.org
Cc:

+ 1

The location is not so important for me as long as we have Pizza + Internet.

Something in August?
I am very interested in the current code generation and it would be great 
to get in touch with it at a hackathon, to allocate some time for PLC4X and ofc 
to see you all again 

Best regards
Matthias Strljic, M.Sc.

Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und 
Fertigungseinrichtungen (ISW)

Seidenstraße 36
70174 Stuttgart
GERMANY

Tel: +49 711 685-84530
Fax: +49 711 685-74530

E-Mail: matthias.strl...@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de

-Original Message-
From: Julian Feinauer 
Sent: Monday, July 29, 2019 11:46 AM
To: dev@plc4x.apache.org
Subject: Next Meetup / Hackathon

Hi folks,

after our last TLP Party meetup I think it would be cool to have another 
meetup with a more technical focus.
First, we have new people on the list and contributors in jira (Kai, 
Volker, Mirko and Bjoern) and second we have big changes coming with the next 
release 0.5 like the code generation.
And as I also stated, it would be good to discuss some API Extensions that 
I want to do.

Whats your opinion on that?
We would of course provide our location here but are also free to come to 
somewhere else.

Julian

PS.: And on a final note I already start to be “unterhopft” (I checked, 
there is no nice counterpart in English) and we have a new PMC member coming up 
which is eager to spend us some beer, I hope : )