Hi,

okay, then I got you wrong, then its only good to notice everybody that some 
incomplete work is in the sandbox, if I understand correctly.

Julian

Am 08.08.19, 16:50 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

    Hi Julian,
    
    actually all the changes shouldn't have affected anything outside the 
sandbox drivers. So I doubt it would have a negative impact on the existing 
drivers and integration modules.
    I did double-check that the build itself works.
    
    Chris
    
    
    Am 08.08.19, 16:43 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
    
        Hi Chris,
        
        thanks fort he effort.
        
        I agree to merge this into develop if we ensure that we go back to 
"full stable" ASAP.
        
        Julian
        
        Am 08.08.19, 16:38 schrieb "Christofer Dutz" 
<christofer.d...@c-ware.de>:
        
            Hi all,
            
            so I just finished refactoring the code generation in the 
"feature/implement-df1-driver" branch. However I think I need to merge the 
things happening there into develop quite soon as now the maven-plugin is no 
longer in sync with the state of develop.
            
            First of all I cleaned up a little:
            - field --> simple
            - arrayField --> array
            - optionalField --> optional
            
            Then I added some new fields:
            - checksum (Like an implicit field, but during parsing it reads a 
value, and also calculates the checksum and compares the values and throws an 
exception if they don’t match)
            - padding (If a condition is met, a given input is added ... this 
is generally used in the S7 protocol for word-aligning data)
            - manual (a "simple" field, however do we have full control over 
serialization, deserialization and calculating the length)
            - manualArray (an "array" field, however the developer controls 
serialization, deserialization and calculating the length)
            
            The "manual" field types can be considered "advanced" features as 
they do require quite a bit of getting used to. But they seem to be doing a 
nice job.
            
            I also updated all specs to these changes and added one or two 
tests to test my additions.
            
            Chris
            
            
            Am 08.08.19, 07:47 schrieb "Christofer Dutz" 
<christofer.d...@c-ware.de>:
            
                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" 
<christofer.d...@c-ware.de>:
                
                    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" 
<christofer.d...@c-ware.de>:
                    
                        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<https://aka.ms/ghei36>
                        
                        ________________________________
                        From: Julian Feinauer <j.feina...@pragmaticminds.de>
                        Sent: Wednesday, August 7, 2019 11:49:45 AM
                        To: dev@plc4x.apache.org <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" 
<christofer.d...@c-ware.de>:
                        
                            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
                        
                        
                        
                        
                        
                    
                    
                
                
            
            
        
        
    
    

Reply via email to