Perfect, then we do it that way.
I feel a bit sorry for you that you did most of the heavy lifting and I'm like
standing next to you giving bad comments like "nah, it would be better doing it
that way".
But when we meet in Nürtingen I owe you a beer for that __
Julian
Am 06.09.18, 11:29
Hi Julian,
I think that would be ideal ... as this way I don't feel like moving things
underneath your feet all the time ;-)
After my change marathon yesterday I am hopeful that I will be able to finish
this this week.
Chris
Am 06.09.18, 10:53 schrieb "Julian Feinauer" :
Hi Chris,
Hi all,
just wanted to give you an update on my progress.
I started with updating the examples and integrations and quickly came to a
point, where I had to continue finishing the API refactoring and the
base-driver refactoring.
So I just committed my last changes that should make it possible
Hi chris,
I agree with your S7 field except for one little change.
How do we proceed with the (optional) bit offset?
I made it "Short" with the contract that null indicates no offset given.
Another alternative would be to make it 0 as default or even Optional.
I would prefer to have it nullable,
Hi Sebastian,
Yeah ... I thought that we last removed JUnit5 again as it was completely
buggy, but having now read some "Yeah till the latest releases it really
sucked, but now it works fine" I thought, why not allow it and we'll see how it
works. I wouldn't propose to migrate everything
Hi Chris,
[1] no need to supply a text to „ PlcInvalidFieldException“ as it only requires
you to supply the field name.
[2] using junit5 for parameterd tests seems to be a big relief :)
You should add a Pull-Request with WIP: (work in progress fix) so we can add
remarks like above inline as
Hi all,
especially @Julian ... could you please have a look at that I did with the
S7Field [1]?
Also there is a unit-test that should allow adding more statements and testing
everything is working ok [2].
Does this match your idea on [3]? Looking at your addresses, I think that I
might have
Hi all,
I just pushed changes to my API refactoring branch ... so far I only adjusted
the API module and added an example using the changed API.
To have a look, please go to [1] ...
General changes I implemented while working on the refactoring itself. I did
notice, that my current proposal
Ups ... after reloading .. I just saw Julians Proposal pop up ... haven't
looked into that ...
Will do that right away.
Chris
Am 25.08.18, 15:52 schrieb "Christofer Dutz" :
Hi Julian,
version 2 should now be quite different ... I started reworking my original
proposal and
Hi all,
I would strongly like to encourage you to have a look as the API Changes we
have listed in Confluence.
With the option to have diagrams, I think discussing such changes is a lot
easier than in pure text form here.
Currently I am in strong favor of my second proposal [1]
Major changes
Hi Julian,
version 2 should now be quite different ... I started reworking my original
proposal and decided to revert that an start a second proposal.
My first did address some parts needing cleaning up, but I still wasn't quite
satisfied with it. So I did another more radical refactoring.
If
Hi Chris,
I’m about to go through your suggestions fort he API changes (by the way,
thanks for your effort and the very nice documentation) and I’m a bit confused
about the differences between
* Chris Proposal
* Chris Proposal 2
They seem very equal to me.
Are these two versions of
12 matches
Mail list logo
