[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [699]'
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [699]': Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/699/;>PLC4X/PLC4X/develop [develop] [699]"
RE: [NOTICE] Some additional changes to mspec
But in general, it's just omitting the "ticks" around the field names. Chris -Original Message- From: Cesar Garcia Sent: Freitag, 26. November 2021 17:42 To: Apache PLC4X Subject: Re: [NOTICE] Some additional changes to mspec Hi Chris, What impact would it have on the existing mspec? best regards, El vie, 26 nov 2021 a las 8:41, Christofer Dutz () escribió: > Hi all, > > as I'm currently working hard on making the Java code generation > strongly typed, I ran into a problem: > For typeSwitches we can't infer the types of the switch case constants > as the inputs were expressions. > > A quick search resulted in the fact, that not a single time were we > actually using expressions, in all cases the input were variable literals. > > So Sebastian and I refactored the code-gen and the mspec parsers to > now only allow variable literals as inputs. The only obvious change > this brings, is that now no longer the expression-ticks are allowed. > > Second change is that constant fields had "expressions" as values. > However this is actually not correct as constant fields can only have > constants (If in java we had a const field with an expression, it wouldn't > compile). > So we also changed constant fields to only allow valueLiterals, which > are eigher bool, numeric (int or float), string or hexadecimal values. > Now here also the expression ticks need to be omitted. > > With these changes, I can now infer the type of a discriminator value > and then correctly output the constant value (Like adding the "L" > suffix to > uint32 hex constants) ... this is what I'm going to work on next. > > Hopefully after that's done, I'll be able to finish the PROFINET driver. > (Famous last words) > > Chris > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
RE: [NOTICE] Some additional changes to mspec
None, as I / we generally always update all existing mspec documents while doing it. Only if I run into trouble, I ask you guys for help. Chris -Original Message- From: Cesar Garcia Sent: Freitag, 26. November 2021 17:42 To: Apache PLC4X Subject: Re: [NOTICE] Some additional changes to mspec Hi Chris, What impact would it have on the existing mspec? best regards, El vie, 26 nov 2021 a las 8:41, Christofer Dutz () escribió: > Hi all, > > as I'm currently working hard on making the Java code generation > strongly typed, I ran into a problem: > For typeSwitches we can't infer the types of the switch case constants > as the inputs were expressions. > > A quick search resulted in the fact, that not a single time were we > actually using expressions, in all cases the input were variable literals. > > So Sebastian and I refactored the code-gen and the mspec parsers to > now only allow variable literals as inputs. The only obvious change > this brings, is that now no longer the expression-ticks are allowed. > > Second change is that constant fields had "expressions" as values. > However this is actually not correct as constant fields can only have > constants (If in java we had a const field with an expression, it wouldn't > compile). > So we also changed constant fields to only allow valueLiterals, which > are eigher bool, numeric (int or float), string or hexadecimal values. > Now here also the expression ticks need to be omitted. > > With these changes, I can now infer the type of a discriminator value > and then correctly output the constant value (Like adding the "L" > suffix to > uint32 hex constants) ... this is what I'm going to work on next. > > Hopefully after that's done, I'll be able to finish the PROFINET driver. > (Famous last words) > > Chris > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
Re: [NOTICE] Some additional changes to mspec
Hi Chris, What impact would it have on the existing mspec? best regards, El vie, 26 nov 2021 a las 8:41, Christofer Dutz () escribió: > Hi all, > > as I'm currently working hard on making the Java code generation strongly > typed, I ran into a problem: > For typeSwitches we can't infer the types of the switch case constants as > the inputs were expressions. > > A quick search resulted in the fact, that not a single time were we > actually using expressions, in all cases the input were variable literals. > > So Sebastian and I refactored the code-gen and the mspec parsers to now > only allow variable literals as inputs. The only obvious change this > brings, is that now no longer the expression-ticks are allowed. > > Second change is that constant fields had "expressions" as values. However > this is actually not correct as constant fields can only have constants (If > in java we had a const field with an expression, it wouldn't compile). > So we also changed constant fields to only allow valueLiterals, which are > eigher bool, numeric (int or float), string or hexadecimal values. Now here > also the expression ticks need to be omitted. > > With these changes, I can now infer the type of a discriminator value and > then correctly output the constant value (Like adding the "L" suffix to > uint32 hex constants) ... this is what I'm going to work on next. > > Hopefully after that's done, I'll be able to finish the PROFINET driver. > (Famous last words) > > Chris > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [698]'
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [698]': Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/698/;>PLC4X/PLC4X/develop [develop] [698]"
[NOTICE] Some additional changes to mspec
Hi all, as I'm currently working hard on making the Java code generation strongly typed, I ran into a problem: For typeSwitches we can't infer the types of the switch case constants as the inputs were expressions. A quick search resulted in the fact, that not a single time were we actually using expressions, in all cases the input were variable literals. So Sebastian and I refactored the code-gen and the mspec parsers to now only allow variable literals as inputs. The only obvious change this brings, is that now no longer the expression-ticks are allowed. Second change is that constant fields had "expressions" as values. However this is actually not correct as constant fields can only have constants (If in java we had a const field with an expression, it wouldn't compile). So we also changed constant fields to only allow valueLiterals, which are eigher bool, numeric (int or float), string or hexadecimal values. Now here also the expression ticks need to be omitted. With these changes, I can now infer the type of a discriminator value and then correctly output the constant value (Like adding the "L" suffix to uint32 hex constants) ... this is what I'm going to work on next. Hopefully after that's done, I'll be able to finish the PROFINET driver. (Famous last words) Chris
