WG: REMINDER: Project Stickers for Apachecon NA or EU

[Julian Feinauer]

Do we have enough @ Chris?

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: REMINDER: Project Stickers for Apachecon NA or EU
Von: Sharan Foga
An: d...@community.apache.org
Cc:

Hi Everyone

This is a reminder that I am putting the main sticker order together now with 
the plan to get the order in progress by the weekend. So if you are coming to 
Apachecon NA or EU and would like to see some of your project stickers there 
then please let me know. And remember this covers podlings too.

Please check to see if your project is already on the Sticker list at
https://cwiki.apache.org/confluence/display/COMDEV/ApacheCon+NA+2019

and if not, then please either add it to the list on the wiki or respond to 
this thread with the name of your project and I will add it.

Thanks
Sharan

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

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