Hi all,

i see there some chris  waving šŸ˜ƒ I always need some provocation to act sry for 
that.

@Chris I agree with you that such a sub-project like the attempt of  a template 
based code generation(TbCG) should be also done in the Apache way and it will 
be. But Julian and me just wanted first to work out a rapid prototype on which 
we can then discuss some pro and cons of the attempt over a DSL. Julian is 
there a bit better in communicating the actual state then me and we discussed 
there some possibilities where we can push forward and include the the research 
areas of the ISW in a efficient way. The ideas with the students was more to 
have roadmap of the code generation idea and plan there some tooling around the 
TbCG which could be build in parallel around the core pipeline, when it is 
available(The full DFDL or the DSL).

In my opinion there have both approaches pros and cons. The DFDL approach 
supports a well implemented tool chain in a declarative manor and the DSL idea 
targets more on a programming like evolution of a DSL, there was the idea of a 
more practical attempt of restricting a sub-set of a programming language like 
python so that it fulfills all of our requirements, regarding supported 
communication patterns, messages structures and behavior model. 

@Niclas I would try to avoid language bindings or the integration of 
interpreter engines. There you will always have a strict coupling to the 
implementation of the source language and each change will propagate through 
every platform. So it would promise fast language coverage but tight coupling 
to the core implementation.

Greetings the most silent
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: Christofer Dutz <christofer.d...@c-ware.de> 
Sent: Monday, April 29, 2019 10:06 AM
To: dev@plc4x.apache.org
Subject: Re: [generation] Another approach to generated drivers

Hi All,

to answer Niclas' question first ... yes a lot of tools allow writing code in 
for example Java and have that compiled to c-like programs.
I had a look at a lot of these options before starting to work on PLC4X and 
continued since then. 

I was never quite happy with the results. While the performance of the original 
is ... well ... 100% you usually have great losses on the cross compiled 
outputs. Also there is the problem that the cross-compiled version usually 
needs quite a lot more resources as the original and especially as the native 
implementation.

For example when writing Raw-Socket code in java, we use some extra hoops to do 
so, in C, C++, C# (maybe even python) we could directly use the network 
hardware. So depending on the language you use and the platform you build for 
the drivers could be quite different. 

And regarding the API: We would be translating an API of one language to others 
... what would we use for C support? Mapping Java to C isn't trivial and the 
result would be quite evil looking, I bet. The way we were currently planning 
on doing things, would be to manually implement an API module that perfectly 
fits for the language we are targeting and to generate the drivers for that 
language.

Regarding Julian's proposal:
Well if you wouldn't be spawning new initiatives that bind me with preparing 
the build all the time, I would have a chance to actually work on my proposal 
;-) (Haven't worked on that for weeks) 

Also didn't I ever have the chance to explain it to anyone yet, so calling it a 
"mind detonator" is a little unfair, cause I think it's a lot simpler than our 
current hand-written drivers. I do agree that a specially hand-crafted and well 
implemented DSL for exactly this use-case will probably be easier, but you 
would have to implement the DSL first and then the tooling (Keep in mind with 
Daffodil/DFDL we get a full blown toolkit to write unit-tests and document the 
protocol). I was trying to use, what's already out there, cause I knew that 
inventing something that achieves 90% of what you are doing is super-easy, 
however to get to 100% you need to put in great efforts.

I would be the last to object in general, but I wouldn't want to rely on a 
student project where we have to wait till someone else finishes something and 
hope that he does. Especially if the key-person in charge of this initiative 
seems to have great problems communicating on this list (Me "waiving with a 
fence pole" here :-P). I would only call it a PLC4X Paper, if it's actually 
done by involving the community ... and doing that in a private repo isn't 
quite the way we do things at Apache. So for this to be a real Apache 
initiative ... do it in public and do discussions on the list.

So if I finally manage to clean up and prepare the build for the multi-language 
part ... please at least give me the chance to work on my proposal a little 
more and at least explain what I had planned. 

I would suggest you work on the other option and then we let the community 
decide which path to take. I am really fond of the DFDL part, but not so 
overwhelmed by the SCXML part of my proposal... perhaps the ideal solution 
would be something in-between.

Chris


ļ»æAm 29.04.19, 08:53 schrieb "Niclas Hedhman" <nic...@hedhman.org>:

    Outsider looking in; Many language runtimes allows embedding of other
    languages' runtimes within. So why not pick a languages that is reasonably
    easy to integrate into other languages, and then write the drivers in a
    fully fledged programming language, rather than the DFDL abstraction or
    creating a new DSL with a whole slew of consequences later on.
    
    Languages that might be suitable; JavaScript, Lua, Forth, microPython or
    even C...
    
    Niclas
    
    On Mon, Apr 29, 2019 at 2:20 PM Julian Feinauer <
    j.feina...@pragmaticminds.de> wrote:
    
    > Hi all,
    >
    > just wanted to sum up some talks and discussions we had off-list about the
    > whole topic of driver generation / providing drivers in other languages.
    > Currently, there are the following two approaches going on:
    >
    > Driver Generation based on DFDL by Chris:
    > Chris already shared his branch and is working on the generation of
    > drivers based on the specification of the messages and a state machine.
    > This should then generate Code based on Freemarker Templates.
    >
    > Proxy Drivers by me, Chris and also others:
    > We have a thrift based server / client spec.
    > A simple Java Server is implemented as Interop Server and we work on
    > providing client in other languages.
    > This is a separate feature (as Proxy) but in a mode, where the Client
    > itself starts the server in the background, this is an intermediate
    > solution to already provide other language bindings (although at a cost).
    > All work is done in the PLC4X-111 branch and I hope that we will be able
    > to Merge that soon (Chris spend a lot of effort to include all the new
    > stuff in our build).
    >
    > And there is a new thing coming currently which is mostly Driven by
    > Matthias and myself regarding the driver code generation.
    > We went over Chris example code (and the xmls) and our heads nearly
    > exploded as it is so abstract.
    > And as Matthias does a lot with model based code generation we had a long
    > discussion about using a model based approach (probably with a DSL).
    > So we currently try to investigate that a bit but also with a focus on
    > research. In fact, we have the potential that we can engage some students
    > from his institute to participate at the work.
    > In fact, we even started a private Repo where we prepare a Paper to
    > discuss the matter.
    > As this would be our first ā€œPLC4X Paperā€ everybody is invited to join us
    > and should simply ping me (with github credentials), to get repo access.
    > If we make it through we will will of course list everybody who
    > contributed as author.
    >
    > To make it clear, this work, the DSL based driver generation tries to
    > achieve the same as Chris approach based on DFDL just through another way.
    > And right now Iā€™m unable to say which one is better, could be better and
    > where are the drawbacks and advantages. So we want to investigate that to
    > have a basis for a discussion and decision. In fact, both approaches 
should
    > be equally powerful, so one could be able to translate one to the other 
and
    > vice versa, in theory.
    > I consider it highly important to have a good and easy way to develop and
    > maintain drivers as this is the crucial thing for the future of PLC4X.
    >
    > So please feel free to comment or discuss, if you feel like : )
    >
    > Julian
    >
    
    
    -- 
    Niclas Hedhman, Software Developer
    http://polygene.apache.org - New Energy for Java
    

Reply via email to