Code review and other activities
416 views
Skip to first unread message
ma...@makr.zone
Dec 24, 2024, 9:51:03 AM12/24/24
to OpenPnP
Hi everybody,
as some of you surely have noticed, I wasn't very present lately, and code review of PRs is stalling. This is due to high and all-responsibility work load in my job, and I'm afraid it is not getting any better anytime soon, on the contrary. It's also starting to take its toll on my health, so its high time I make some changes where I can.
Therefore, I'm unhappy to announce that I will be mostly unable to continue reviewing code etc. Again, I'm very unhappy with the situation. I do see that I might have
encouraged contributions with the past routine of
reviewing and adopting PRs quickly, and now contributors are waiting and waiting. Hurts me to see that. Plus contributions have increased dramatically, lately, which is a very good thing for OpenPnP, but at the same time not helping my situation. I really, really hope you guys can find a new arrangement to allow progress.
@vonnieda has suggested restructuring the git branches a while back. Maybe that would help open up development, so (new) maintainers could risk earlier adoption of PRs in a bleeding edge testing branch, but then also only curate proven PRs into a stable branch, that doesn't lag behind that much.
Please, dear contributors, organize yourselves and take things into your hands! I'm sure @vonnieda will assist by providing the necessary repo access.
I will still be reading the group, and help where limited time and energy permits.
_Mark
Wayne Black
Dec 24, 2024, 10:35:55 AM12/24/24
to ope...@googlegroups.com
Thank you so very much for your tremendous efforts Mark! Wishing you good health and a better life work balance!
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/1936da63-c6ba-4682-a1f9-3e50bf29bf2cn%40googlegroups.com.
Mike Menci
Dec 24, 2024, 12:27:53 PM12/24/24
to OpenPnP
Hello Mark !
Mike
Thank you for your work and all the support you have done for us !
Wishing you all the best and happy Christmas and gorgeous new coming years!!
Wishing you all the best and happy Christmas and gorgeous new coming years!!
Mike
vespaman
Dec 25, 2024, 4:24:34 AM12/25/24
to OpenPnP
I also want to say Thank you for your contributions both in code as well as being present here in the forum, always trying to help out! Hope your situation will get better soon, even if it looks distant at the moment.
- Micael
Ian Arkver
Dec 27, 2024, 6:24:06 AM12/27/24
to OpenPnP
Thanks and take care Mark. I hope you get to a better place soon.
Zdenko Stanec
Dec 27, 2024, 9:31:05 AM12/27/24
to OpenPnP
Cheers Mark and thank you for all your work and dedication, workload has a big impact on stress/health so keeping that in order is the number one thing to focus on.
I wish you all the best and hope to see you back.
Zdenko,
mark maker
Dec 27, 2024, 10:08:21 AM12/27/24
to ope...@googlegroups.com
Thank you all for the kind wishes!
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/1171d2b1-b8af-4e13-98c1-bc09f7e7b4c3n%40googlegroups.com.
Toby Dickenson
Dec 28, 2024, 8:30:16 AM12/28/24
to ope...@googlegroups.com
Thank you for your contributions, assistance, and insights which have been very much appreciated during my short time using openpnp. I hope your situation improves.
Toby.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/e7c3dbb7-0803-4773-914c-9e3d983c65dd%40makr.zone.
Jan
Dec 28, 2024, 9:42:13 AM12/28/24
to ope...@googlegroups.com
Dear Mark!
I'm very sorry to read this! You are such a wealth of knowledge and so
willing to share it with everyone that you will for sure leave a great
hole behind. Many thanks for letting us participate! All the best to you
and your family! Hope to see you back some time.
Dear fellow developers! Dear users!
Lets look into the future and see what we have to do to keep OpenPnP alive!
As you all know, the current recommendation is to run the test branch.
This is solely due to the circumstance that Mark reviewed PRs with such
a great vision and in depth understanding, that I hardly can remember a
single PR that had to be reverted. If You can fill this gap please speak
up and let us continue the development as we did. Otherwise I'd like to
propose to restructure the process as follows:
If we can't make sure, that only PRs are merged, that are known to work
even on exotic machines, we shall convert the test branch into a true
test version of OpenPnP that is really for testing new features only and
hence may not work for everyone immediately. I'd still encourage users
to test the this version so detect problems early. Unfortunately
downgrading to a stable version is not that easy due the simplexml
framework that does not handle excessive tags/attributes gracefully and
some features may not be easily downgraded. IIRC some month back someone
started working on replacing it. Unfortunately I have not heard about
the progress or if there are show stopper. Without such a downgrade
path, manual machine.xml editing would be required making this a rocky
path...
With such a "test version", the distance to the stable version shall
not get to large so that downgrades are not to bitter. I'd suggest to
implement something like a timed release schedule. For lets say two
month new features are merged into the test version and for an other
month only fixes are accepted before a new stable version is created.
This would result in a stable release every three month. To be
successful, this schema requires enough tests of the test version. In
addition it would be good to encourage more people to review PRs before
they get merged. Two eyes see more then one and reviewing is IMHO still
very successful even without detailed knowledge of the Java language or
in depth understanding of the entire project.
As a starting point, I'd suggest to merge the current test version into
the stable branch.
What do you think? Do you have any other suggestions?
Jan
> <https://groups.google.com/d/msgid/openpnp/1936da63-c6ba-4682-
> a1f9-3e50bf29bf2cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
I'm very sorry to read this! You are such a wealth of knowledge and so
willing to share it with everyone that you will for sure leave a great
hole behind. Many thanks for letting us participate! All the best to you
and your family! Hope to see you back some time.
Dear fellow developers! Dear users!
Lets look into the future and see what we have to do to keep OpenPnP alive!
As you all know, the current recommendation is to run the test branch.
This is solely due to the circumstance that Mark reviewed PRs with such
a great vision and in depth understanding, that I hardly can remember a
single PR that had to be reverted. If You can fill this gap please speak
up and let us continue the development as we did. Otherwise I'd like to
propose to restructure the process as follows:
If we can't make sure, that only PRs are merged, that are known to work
even on exotic machines, we shall convert the test branch into a true
test version of OpenPnP that is really for testing new features only and
hence may not work for everyone immediately. I'd still encourage users
to test the this version so detect problems early. Unfortunately
downgrading to a stable version is not that easy due the simplexml
framework that does not handle excessive tags/attributes gracefully and
some features may not be easily downgraded. IIRC some month back someone
started working on replacing it. Unfortunately I have not heard about
the progress or if there are show stopper. Without such a downgrade
path, manual machine.xml editing would be required making this a rocky
path...
With such a "test version", the distance to the stable version shall
not get to large so that downgrades are not to bitter. I'd suggest to
implement something like a timed release schedule. For lets say two
month new features are merged into the test version and for an other
month only fixes are accepted before a new stable version is created.
This would result in a stable release every three month. To be
successful, this schema requires enough tests of the test version. In
addition it would be good to encourage more people to review PRs before
they get merged. Two eyes see more then one and reviewing is IMHO still
very successful even without detailed knowledge of the Java language or
in depth understanding of the entire project.
As a starting point, I'd suggest to merge the current test version into
the stable branch.
What do you think? Do you have any other suggestions?
Jan
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/1936da63-c6ba-4682-a1f9-3e50bf29bf2cn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/1936da63-c6ba-4682-
> a1f9-3e50bf29bf2cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Jason von Nieda
Dec 28, 2024, 11:13:51 AM12/28/24
to OpenPnP
Hi Mark,
Thank you dearly for all you have done for the OpenPnP project, and for so many of it's users, and for me. I am so impressed with what OpenPnP has become and it is primarily thanks to you and your steadfast commitment to quality. I hope that you are also very proud of your work here. It stands as a monument in Open Source dedication.
I hope that you get the rest that you need, and come out stronger and healthier than ever.
Jason
--You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.To view this discussion visit https://groups.google.com/d/msgid/openpnp/1936da63-c6ba-4682-a1f9-3e50bf29bf2cn%40googlegroups.com.
Toby Dickenson
Dec 28, 2024, 2:00:06 PM12/28/24
to ope...@googlegroups.com
I agree with everything Jan wrote.....
> This would result in a stable release every three month.
I suggest it would be useful to have feedback from the wider user
community on what versions are currently in use, the desired frequency
of openpnp releases, and longevity of maintenance for each release.
Users please speak up! We should ask again when everyone is back from
their holiday shutdown.
There is a daily build from the test branch, but I can't imagine that
anyone updates their machine daily. I am running test branch plus some
custom patches. I update my test snapshot approximately monthly
intervals, and that feels like I am on the bleeding edge. There isnt
much of a margin between that, and a 3 monthly "stable" release.
We update software for our other manufacturing equipment annually at most.
Lots of lumenpnp users are still using an April 2023 test snapshot as
recommended by opulo, so someone there sees a value in slower release
cadence. Even knowing that lots of traffic on the lumenpnp discord is
about problems that are already fixed in test.
But the immediate priority should be to cut the first stable
maintained release based on the current test branch. Deciding the
interval between successive releases can come later.
> As a starting point, I'd suggest to merge the current test version into
> the stable branch.
I think it is better to avoid doing that. The stable branch has a
reputation of belonging in a museum, and it can happily stay like
that. "202502_release_branch" (or whatever) can fork from "test".
Right?
Toby
> This would result in a stable release every three month.
community on what versions are currently in use, the desired frequency
of openpnp releases, and longevity of maintenance for each release.
Users please speak up! We should ask again when everyone is back from
their holiday shutdown.
There is a daily build from the test branch, but I can't imagine that
anyone updates their machine daily. I am running test branch plus some
custom patches. I update my test snapshot approximately monthly
intervals, and that feels like I am on the bleeding edge. There isnt
much of a margin between that, and a 3 monthly "stable" release.
We update software for our other manufacturing equipment annually at most.
Lots of lumenpnp users are still using an April 2023 test snapshot as
recommended by opulo, so someone there sees a value in slower release
cadence. Even knowing that lots of traffic on the lumenpnp discord is
about problems that are already fixed in test.
But the immediate priority should be to cut the first stable
maintained release based on the current test branch. Deciding the
interval between successive releases can come later.
> As a starting point, I'd suggest to merge the current test version into
> the stable branch.
reputation of belonging in a museum, and it can happily stay like
that. "202502_release_branch" (or whatever) can fork from "test".
Right?
Toby
jbussmann
Dec 28, 2024, 3:05:01 PM12/28/24
to OpenPnP
LumenPnP user here.
When I entered the world of PnP maybe a month or so ago, I was looking for downloads of the stable branch. I then learned that stable is legacy and develop is recommended. This had me scratching my head a bit but since I have used Betaflight, I'm not new to the concept of "beta" being "stable". :) So I installed the latest develop version and found the support for the LumenPnP Feeder (PhotonFeeder) missing. So I went with what Opulo recommends from April 2023. I also had a look at the changelog which said no "major or notable changes" since 2022, so I'm fine with that. Just now I also looked at the changelog on the test branch and it looks similarly boring.
To be honest, I hate updates and avoid them, whenever in any way possible. Updates left me with the impression that they break things and at the very least features are changed, rearranged and put in places where I can't find them. So I will only update if the changlog lists a bugfix that affects me, a feature that I want or if I can't download this version anymore after a system reinstall. This is especially true for a machine I use for work, where I care 100% about it running reliably and 0% about new features that cost me adaption time without bringing added value.
Long story short: I agree with much of what Toby said. Release based on current test branch sounds reasonable and I will have to check if this supports the LumenPnP feeders. Also I would put renaming the branches even higher in priority. As for release interval, I think 3 months is much too short. 6 months should be the very least. Personally, I opt for 12 months with a good part of it in feature freeze. Then I might even break my no-updates policy and test a new release candidate in the name of supporting a project I find awesome.
When I entered the world of PnP maybe a month or so ago, I was looking for downloads of the stable branch. I then learned that stable is legacy and develop is recommended. This had me scratching my head a bit but since I have used Betaflight, I'm not new to the concept of "beta" being "stable". :) So I installed the latest develop version and found the support for the LumenPnP Feeder (PhotonFeeder) missing. So I went with what Opulo recommends from April 2023. I also had a look at the changelog which said no "major or notable changes" since 2022, so I'm fine with that. Just now I also looked at the changelog on the test branch and it looks similarly boring.
To be honest, I hate updates and avoid them, whenever in any way possible. Updates left me with the impression that they break things and at the very least features are changed, rearranged and put in places where I can't find them. So I will only update if the changlog lists a bugfix that affects me, a feature that I want or if I can't download this version anymore after a system reinstall. This is especially true for a machine I use for work, where I care 100% about it running reliably and 0% about new features that cost me adaption time without bringing added value.
Long story short: I agree with much of what Toby said. Release based on current test branch sounds reasonable and I will have to check if this supports the LumenPnP feeders. Also I would put renaming the branches even higher in priority. As for release interval, I think 3 months is much too short. 6 months should be the very least. Personally, I opt for 12 months with a good part of it in feature freeze. Then I might even break my no-updates policy and test a new release candidate in the name of supporting a project I find awesome.
Toby Dickenson
Dec 28, 2024, 3:45:53 PM12/28/24
to ope...@googlegroups.com
One important outstanding task is reverse-engineering a change log... Changes going back to several previous milestones.
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/56f8a41d-7f5d-44bb-a766-fae730a44a5cn%40googlegroups.com.
Mike Menci
Dec 28, 2024, 3:47:55 PM12/28/24
to OpenPnP
I am un old user of Open PnP and I do updates every 2 month or if there is a major update earlier. I am not a software guy, I would say I am a user. To it seam reasonable if there is a major point that people using PnP really need the update should be ASAP, if not every 2-3 months is a reasonable timing...
Test branch can remain - normal user does normally not install it, people who wish to test can use that when they will...
My 1 cent/€
Test branch can remain - normal user does normally not install it, people who wish to test can use that when they will...
My 1 cent/€
Thanks to all that contribute !! Happy New Year is here - we take it Day by Day!
BR
Mike
vespaman
Dec 28, 2024, 5:02:12 PM12/28/24
to OpenPnP
For me (a user in this context), the interval of a stable version isn't important. But my fear is that, if the test version gets to be more of a real "test" version, i.e. missing the current quality level (which has been tremendous), some of us might not dare to use it, hence it might not receive as much test before going stable, and then stable is not really stable anymore.
But if there needs to be a fixed timeline of releases, once a year would be fine with me, certainly no more than twice a year. If anyone wants to update more frequent, there's still the test version for the early adopters.
I sincerely hope someone finds it interesting to pick up the code review (and some kind of conceptual review as well). Maybe this is not one person, but a few.
Regardless, it is exiting to see that lately, there has been more contributions to OpenPnP.
- Micael
Jan
Dec 28, 2024, 5:32:21 PM12/28/24
to ope...@googlegroups.com
Hi jbussmann!
Unfortunately the changelog is a file just like every other except that
it is not updated very often. There where a few updates that should have
been listed there:
- support for new MAC silicon
- multi-shot bottom vision (for large parts)
- parallax fiducial vision
- enhanced panel/board management
- more options for bottom vision Z
- performance improvements for multi-nozzle-machines
- exposed parameters for bottom vision
- bottom vision inheritance model
- improved sprocket hole and fiducial detection due to CircularSymmetry
This are just a few I remember which where IIRC all added after 2023.
Just to repeat my point: I fully understand that updating manufacturing
equipment that is supposed to "just" work, is usually not desirable. To
improve OpenPnP we're relying on user feedback that only works if
someone tries the new software. Unfortunately this new software might
fail requiring to either wait for a fix or downgrading to a known good
version. This might be a no-go for some. I do understand that. But I
still hope, that there are others out there, that can effort it. I
consider this an equal contribution as providing PRs, taking part in
discussions like this or reviewing code, or...
Jan
> <https://groups.google.com/d/msgid/openpnp/56f8a41d-7f5d-44bb-a766-
> fae730a44a5cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Unfortunately the changelog is a file just like every other except that
it is not updated very often. There where a few updates that should have
been listed there:
- support for new MAC silicon
- multi-shot bottom vision (for large parts)
- parallax fiducial vision
- enhanced panel/board management
- more options for bottom vision Z
- performance improvements for multi-nozzle-machines
- exposed parameters for bottom vision
- bottom vision inheritance model
- improved sprocket hole and fiducial detection due to CircularSymmetry
This are just a few I remember which where IIRC all added after 2023.
Just to repeat my point: I fully understand that updating manufacturing
equipment that is supposed to "just" work, is usually not desirable. To
improve OpenPnP we're relying on user feedback that only works if
someone tries the new software. Unfortunately this new software might
fail requiring to either wait for a fix or downgrading to a known good
version. This might be a no-go for some. I do understand that. But I
still hope, that there are others out there, that can effort it. I
consider this an equal contribution as providing PRs, taking part in
discussions like this or reviewing code, or...
Jan
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/56f8a41d-7f5d-44bb-a766-fae730a44a5cn%40googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/openpnp/56f8a41d-7f5d-44bb-a766-
> fae730a44a5cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
nic...@hedhman.org
Dec 30, 2024, 2:02:37 AM12/30/24
to ope...@googlegroups.com
On 2024-12-28 22:42, 'Jan' via OpenPnP wrote:
> Dear Mark!
> I'm very sorry to read this! You are such a wealth of knowledge and so
> willing to share it with everyone that you will for sure leave a great
> hole behind. Many thanks for letting us participate! All the best to
> you and your family! Hope to see you back some time.
Lurker here; I have been amazed at how much effort Mark has put in, even
> Dear Mark!
> I'm very sorry to read this! You are such a wealth of knowledge and so
> willing to share it with everyone that you will for sure leave a great
> hole behind. Many thanks for letting us participate! All the best to
> you and your family! Hope to see you back some time.
compared to OSS projects with full-time employed people. Mark deserves
all the praise and a break.
> Dear fellow developers! Dear users!
> Unfortunately downgrading to a stable version is not that easy due the
> simplexml framework
> that does not handle excessive tags/attributes gracefully and some
> features may not be easily
> downgraded. IIRC some month back someone started working on replacing
> it. Unfortunately I have
> not heard about the progress or if there are show stopper. Without such
> a downgrade path,
> manual machine.xml editing would be required making this a rocky
> path...
Not sure if you are referring to me. I brought it up ~2-3 years ago, and
> simplexml framework
> that does not handle excessive tags/attributes gracefully and some
> features may not be easily
> downgraded. IIRC some month back someone started working on replacing
> it. Unfortunately I have
> not heard about the progress or if there are show stopper. Without such
> a downgrade path,
> manual machine.xml editing would be required making this a rocky
> path...
replacement is possible, but somewhat tedious and one should ask "what
will the gain be?".
I took on a too large chunk, modularizing the codebase in the same
breath and ran out of steam, because there are non-trivial structural
"challenges" to reach "modularity" in a way where everything are
pluggable components. IIRC, mostly with I&S being dependent on
"everything" and "everything" being dependent on I&S. (I might remember
incorrectly)
Cheers
Niclas
Jan
Dec 30, 2024, 9:36:28 AM12/30/24
to ope...@googlegroups.com
Hi Niclas!
On 30.12.2024 08:02, nic...@hedhman.org wrote:
[...]
still around!
I'm sorry, I was not aware, that you tried to refactor the code in
parallel with replacing the xml parser. Yes, I can confirm, that I&S is
very deep integrated and caused me some pain extending it...
To me the simplexml parser causes a major issue when switching
branches. It's inability to just ignore excessive tags/attributes
requires to either setup a separate debug environment per branch or
edit/copy the machine.xml.
Now I'm trying to encourage more users to help test new features and to
provide them with a fallback scenario, an easier downgrade path is one
option. I do admit, that some changes transform content of the
machine.xml into something new, which makes downgrading even harder. In
addition a new xml framework might be able to not write content marked
deprecated back, which would make downgrading more or less impossible.
Unfortunately everything we do now will be only effective until a stable
version is available that uses it. So downgrading to any older version
still using simplexml will not be possible...
Do you think it would be possible to eg. automatically try to load a
backup machine.xml in case the current one has issues?
Do you have any other ideas?
Jan
On 30.12.2024 08:02, nic...@hedhman.org wrote:
[...]
>
> Not sure if you are referring to me. I brought it up ~2-3 years ago, and
> replacement is possible, but somewhat tedious and one should ask "what
> will the gain be?".
> I took on a too large chunk, modularizing the codebase in the same
> breath and ran out of steam, because there are non-trivial structural
> "challenges" to reach "modularity" in a way where everything are
> pluggable components. IIRC, mostly with I&S being dependent on
> "everything" and "everything" being dependent on I&S. (I might remember
> incorrectly)
>
As I read you name, I remembered it was indeed You. Good to see you're
> Not sure if you are referring to me. I brought it up ~2-3 years ago, and
> replacement is possible, but somewhat tedious and one should ask "what
> will the gain be?".
> I took on a too large chunk, modularizing the codebase in the same
> breath and ran out of steam, because there are non-trivial structural
> "challenges" to reach "modularity" in a way where everything are
> pluggable components. IIRC, mostly with I&S being dependent on
> "everything" and "everything" being dependent on I&S. (I might remember
> incorrectly)
>
still around!
I'm sorry, I was not aware, that you tried to refactor the code in
parallel with replacing the xml parser. Yes, I can confirm, that I&S is
very deep integrated and caused me some pain extending it...
To me the simplexml parser causes a major issue when switching
branches. It's inability to just ignore excessive tags/attributes
requires to either setup a separate debug environment per branch or
edit/copy the machine.xml.
Now I'm trying to encourage more users to help test new features and to
provide them with a fallback scenario, an easier downgrade path is one
option. I do admit, that some changes transform content of the
machine.xml into something new, which makes downgrading even harder. In
addition a new xml framework might be able to not write content marked
deprecated back, which would make downgrading more or less impossible.
Unfortunately everything we do now will be only effective until a stable
version is available that uses it. So downgrading to any older version
still using simplexml will not be possible...
Do you think it would be possible to eg. automatically try to load a
backup machine.xml in case the current one has issues?
Do you have any other ideas?
Jan
nic...@hedhman.org
Dec 31, 2024, 10:31:17 PM12/31/24
to ope...@googlegroups.com
On 2024-12-30 22:36, 'Jan' via OpenPnP wrote:
> Do you think it would be possible to eg. automatically try to load a
> backup machine.xml in case the current one has issues?
I can't fully answer that, since I have no experience running an actual
> Do you think it would be possible to eg. automatically try to load a
> backup machine.xml in case the current one has issues?
machine (I gave up on my build and bought a Siplace 80 F3).
> Do you have any other ideas?
(and probably allow JSON), and break the single file into a smaller
number of independent files, also to promote modularity, for instance,
any plugin (say, Z- and C-axes handling) would come with its own default
configuration in a file that is installed together with a jar file (long
way to get there).
Capable serialization frameworks, such as Jackson, have heaps of
features on how "extra" and "missing" entries should be handled, and one
can plug in custom (de)serialization for any type in a quite straight
forward way.
The downside of such approach is of course the pain of transition and it
has been expressed many times that such change is unacceptable...
If staying with machine.xml, I would probably look into a process of
"read old machine.xml, then apply overrides from X" (where X could be
another file, a database, many source even online). As people do more
and more overrides, eventually the machine.xml will be irrelevant to
each individual. For that to work, the tight coupling between actual
Java types and XML tags need to be broken, and that is a big
undertaking.
I am first and foremost a professional Java programmer, so perhaps this
is "doable" from my PoV, but might not be reasonable if you are just an
enthusiast programmer.
HTH
Niclas
Jan
Jan 1, 2025, 9:41:20 AM1/1/25
to ope...@googlegroups.com
Hi Niclas!
On 01.01.2025 04:31, nic...@hedhman.org wrote:
> On 2024-12-30 22:36, 'Jan' via OpenPnP wrote:
>> Do you think it would be possible to eg. automatically try to load a
>> backup machine.xml in case the current one has issues?
>
> I can't fully answer that, since I have no experience running an actual
> machine (I gave up on my build and bought a Siplace 80 F3).
>
Oh! That's a beast compared to the home-brewed machines most of us use.
How fast is it on average?
>
>> Do you have any other ideas?
> Well, personally, I would choose to move away from XML and go with YAML
> (and probably allow JSON), and break the single file into a smaller
> number of independent files, also to promote modularity, for instance,
> any plugin (say, Z- and C-axes handling) would come with its own default
> configuration in a file that is installed together with a jar file (long
> way to get there).
>
That sounds like a good idea!
> Capable serialization frameworks, such as Jackson, have heaps of
> features on how "extra" and "missing" entries should be handled, and one
> can plug in custom (de)serialization for any type in a quite straight
> forward way.
>
> The downside of such approach is of course the pain of transition and it
> has been expressed many times that such change is unacceptable...
>
Yes, an easy upgrade path is considered mandatory here... Just counted
134 occurrences of "@Deprecated" which indicates to me a big bag of
historic stuff still carried around.
Anyhow, if Jackson could be extended by a custom deserializer, couldn't
we use that to import the machine.xml and later serialize it into
something new? That would break the downgrade path, but that's broken
anyhow with any new attribute/tag added. If Jackson imports a single
machine.xml and writes multiple new files, we'd get closes to the
modularity to talked about. This process could likely be repeated in a
later state to split off more stuff into individual modules. (I remember
you mentioned, that I&S is a problem because it's everywhere.)
> If staying with machine.xml, I would probably look into a process of
> "read old machine.xml, then apply overrides from X" (where X could be
> another file, a database, many source even online). As people do more
> and more overrides, eventually the machine.xml will be irrelevant to
> each individual. For that to work, the tight coupling between actual
> Java types and XML tags need to be broken, and that is a big undertaking.
>
I've implemented that a few times. Works very well and is easy to
maintain. Downside it, that you need a copy of the default data to
compare against to only write changes back.
Something like that has probably been done already: vision, parts,
packages and panels are already separate files, but I'm not sure if they
where ever actually part of machine.xml.
Personally I'd love to see that machine.xml would be split into machine
configuration and run-time data. At present it contains things like
feedcount which generates a new version on every feed action.
> I am first and foremost a professional Java programmer, so perhaps this
> is "doable" from my PoV, but might not be reasonable if you are just an
> enthusiast programmer.
>
That's what I remembered and what made me hope that something would
change... I'm an embedded programmer which by nature tries to avoid
"objects", "inheritance" and any kind of dynamic memory where ever
possible. Even printf() with it's "excessive" stack usage is something I
try to avoid. Anyhow, I made my self comfortable modifying, adjusting
and enhancing the existing code but I'm fare away from being an expert
that could restructure the project. I understand in which direction it
shall go to but I'm not enough of a Java expert to see the language
features that are most promising for that.
Jan
On 01.01.2025 04:31, nic...@hedhman.org wrote:
> On 2024-12-30 22:36, 'Jan' via OpenPnP wrote:
>> Do you think it would be possible to eg. automatically try to load a
>> backup machine.xml in case the current one has issues?
>
> I can't fully answer that, since I have no experience running an actual
> machine (I gave up on my build and bought a Siplace 80 F3).
>
How fast is it on average?
>
>> Do you have any other ideas?
> Well, personally, I would choose to move away from XML and go with YAML
> (and probably allow JSON), and break the single file into a smaller
> number of independent files, also to promote modularity, for instance,
> any plugin (say, Z- and C-axes handling) would come with its own default
> configuration in a file that is installed together with a jar file (long
> way to get there).
>
> Capable serialization frameworks, such as Jackson, have heaps of
> features on how "extra" and "missing" entries should be handled, and one
> can plug in custom (de)serialization for any type in a quite straight
> forward way.
>
> The downside of such approach is of course the pain of transition and it
> has been expressed many times that such change is unacceptable...
>
134 occurrences of "@Deprecated" which indicates to me a big bag of
historic stuff still carried around.
Anyhow, if Jackson could be extended by a custom deserializer, couldn't
we use that to import the machine.xml and later serialize it into
something new? That would break the downgrade path, but that's broken
anyhow with any new attribute/tag added. If Jackson imports a single
machine.xml and writes multiple new files, we'd get closes to the
modularity to talked about. This process could likely be repeated in a
later state to split off more stuff into individual modules. (I remember
you mentioned, that I&S is a problem because it's everywhere.)
> If staying with machine.xml, I would probably look into a process of
> "read old machine.xml, then apply overrides from X" (where X could be
> another file, a database, many source even online). As people do more
> and more overrides, eventually the machine.xml will be irrelevant to
> each individual. For that to work, the tight coupling between actual
> Java types and XML tags need to be broken, and that is a big undertaking.
>
maintain. Downside it, that you need a copy of the default data to
compare against to only write changes back.
Something like that has probably been done already: vision, parts,
packages and panels are already separate files, but I'm not sure if they
where ever actually part of machine.xml.
Personally I'd love to see that machine.xml would be split into machine
configuration and run-time data. At present it contains things like
feedcount which generates a new version on every feed action.
> I am first and foremost a professional Java programmer, so perhaps this
> is "doable" from my PoV, but might not be reasonable if you are just an
> enthusiast programmer.
>
change... I'm an embedded programmer which by nature tries to avoid
"objects", "inheritance" and any kind of dynamic memory where ever
possible. Even printf() with it's "excessive" stack usage is something I
try to avoid. Anyhow, I made my self comfortable modifying, adjusting
and enhancing the existing code but I'm fare away from being an expert
that could restructure the project. I understand in which direction it
shall go to but I'm not enough of a Java expert to see the language
features that are most promising for that.
Jan
Mike Menci
Jan 1, 2025, 10:38:17 AM1/1/25
to OpenPnP
nic...@hedhman.org
Jan 1, 2025, 9:47:57 PM1/1/25
to ope...@googlegroups.com
On 2025-01-01 22:41, 'Jan' via OpenPnP wrote:
>> I can't fully answer that, since I have no experience running an
>> actual machine (I gave up on my build and bought a Siplace 80 F3).
>>
> Oh! That's a beast compared to the home-brewed machines most of us use.
> How fast is it on average?
You assume I have it up and running ;-) I have had so many auxiliary
>> I can't fully answer that, since I have no experience running an
>> actual machine (I gave up on my build and bought a Siplace 80 F3).
>>
> Oh! That's a beast compared to the home-brewed machines most of us use.
> How fast is it on average?
issues, renovating space, fixing roof, not enough electric power,
getting a big ass compressor. I am now in Malaysia on long
"vacation"/"working remotely", during the winter, and just before
leaving all the above was sorted out and machine was powered on for
first time, and I didn't have time to do the installation procedure.
I'll get back to you when it is running.
As for your comments below, there is nothing that I disagree with, and
nothing to add at the moment. Maybe(!!!) I will take a new, but much
smaller stab (i.e. only serialization) when I am bored on my "vacation".
No promises.
Niclas
nic...@hedhman.org
Jan 1, 2025, 9:55:07 PM1/1/25
to ope...@googlegroups.com
On 2025-01-01 22:41, 'Jan' via OpenPnP wrote:
> Oh! That's a beast compared to the home-brewed machines most of us use.
> How fast is it on average?
The seller (lurker here) posted this video on the machine;
> How fast is it on average?
https://www.youtube.com/watch?v=jcpKHl-zYgM
Head has 12 nozzles, and I see ~10 travels/min ==> ~7000 comp/hour.
IIRC, he said this was operating at a lower speed to improve
reliability.
Niclas
bert shivaan
Jan 2, 2025, 1:36:24 PM1/2/25
to ope...@googlegroups.com
From a VERY non professional programmer POV, Could we have the updater store a copy of the XML as a part of the update. Then if one wants to roll back, we need a "roll backer" that will go and save the now new XML and restore the old one. Maybe even store the Backup XML in the new XML file when updating. That way the roll backer will know the correct XML to roll back to.
It seems to me in this fashion one could freely move around from one version/rev to the next and the XML files would be intact. Of course I think you can only move 1 version at a time this way, for instance you could not roll back to a version that you did not upgrade from or the XML would still be broken. Not an idel solution but maybe simple enough to get rid of the current issue? In theory we could easily do this manually by keeping our XML's in some configuration at all times. But let's face it, we will screw it up over time.
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/5c15aa45211fe13aed801c6004013f86%40hedhman.org.
nic...@hedhman.org
Jan 15, 2025, 11:01:52 PM1/15/25
to ope...@googlegroups.com
A quick heads-up...
I have replaced simpleframework-xml with com.fasterxml.jackson and
currently working through details in the handling. Status report;
1. Hyphen-case is called Kebab-case in jackson and is supported
without custom code.
2. @Persist and @Commit annotations doesn't exist directly in jackson.
But I have created
custom @PreSerialization and @PostDeserialization annotations and
figured out how to
hook that into the ObjectMapper. Still having some issues on this
though...
3. The use of class="" xml attributes for instantiation of subclasses
is supported.
4. Constructs like "<solder-paste-pads> <board-pad ...." could be
supported with
additional @JacksonXmlElementWrapper(useWrapping = true)
annotation.
5. java.awt.Color was having a converter per usage, that is supported
with @JsonSerialize( using=ColorSerializer.class)
6. Some package.xml contains an unused <outline> and in Jackson that
is handled by
@JsonIgnoreProperties({"outline"})
public class Package extends AbstractPartSettingsHolder {
7. Not relying on jackson to use all getters as properties, and
instead setting
@JsonAutoDetect(fieldVisibility=ANY, getterVisibility=NONE,
setterVisibility=NONE)
and then mark each field with @JacksonXmlProperty (and other
annotations) to get the
exact behavior wanted.
8. Part of the effort is also to support Java 17 and later. The main
issue is
reflection requiring "opening" packages for access.
I am currently looking at deserialization of
<calibration enabled="false">
<camera-matrix length="9">0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
0.0</camera-matrix>
<distortion-coefficients length="5">0.0, 0.0, 0.0, 0.0,
0.0</distortion-coefficients>
</calibration>
where the values end up inside a double[].
I am sure much more will surface as I slowly figure out each thing. But
all-in-all, I think it is fairly doable (is it worth doing?). I will
keep chugging at this over the next couple of weeks, while traveling in
Asia so progress is intermittent...
Niclas
On 2025-01-01 22:41, 'Jan' via OpenPnP wrote:
I have replaced simpleframework-xml with com.fasterxml.jackson and
currently working through details in the handling. Status report;
1. Hyphen-case is called Kebab-case in jackson and is supported
without custom code.
2. @Persist and @Commit annotations doesn't exist directly in jackson.
But I have created
custom @PreSerialization and @PostDeserialization annotations and
figured out how to
hook that into the ObjectMapper. Still having some issues on this
though...
3. The use of class="" xml attributes for instantiation of subclasses
is supported.
4. Constructs like "<solder-paste-pads> <board-pad ...." could be
supported with
additional @JacksonXmlElementWrapper(useWrapping = true)
annotation.
5. java.awt.Color was having a converter per usage, that is supported
with @JsonSerialize( using=ColorSerializer.class)
6. Some package.xml contains an unused <outline> and in Jackson that
is handled by
@JsonIgnoreProperties({"outline"})
public class Package extends AbstractPartSettingsHolder {
7. Not relying on jackson to use all getters as properties, and
instead setting
@JsonAutoDetect(fieldVisibility=ANY, getterVisibility=NONE,
setterVisibility=NONE)
and then mark each field with @JacksonXmlProperty (and other
annotations) to get the
exact behavior wanted.
8. Part of the effort is also to support Java 17 and later. The main
issue is
reflection requiring "opening" packages for access.
I am currently looking at deserialization of
<calibration enabled="false">
<camera-matrix length="9">0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
0.0</camera-matrix>
<distortion-coefficients length="5">0.0, 0.0, 0.0, 0.0,
0.0</distortion-coefficients>
</calibration>
where the values end up inside a double[].
I am sure much more will surface as I slowly figure out each thing. But
all-in-all, I think it is fairly doable (is it worth doing?). I will
keep chugging at this over the next couple of weeks, while traveling in
Asia so progress is intermittent...
Niclas
On 2025-01-01 22:41, 'Jan' via OpenPnP wrote:
Message has been deleted
Jan
Jan 16, 2025, 8:25:27 AM1/16/25
to ope...@googlegroups.com
Hi Niclas!
That's great news! I'm confident there will be a big benefit in
replacing simple.xml. This shall at least support to remove all
deprecated properties.
If you say "mark each field with @JacksonXmlProperty" does that mean,
that you have to edit the entire source code to update the annotation of
each and every property? That would be a huge change...
If you don't mind, please open a PR so that we can have a look what you
already archived.
Many thanks for your effort! Please keep up posted.
Jan
That's great news! I'm confident there will be a big benefit in
replacing simple.xml. This shall at least support to remove all
deprecated properties.
If you say "mark each field with @JacksonXmlProperty" does that mean,
that you have to edit the entire source code to update the annotation of
each and every property? That would be a huge change...
If you don't mind, please open a PR so that we can have a look what you
already archived.
Many thanks for your effort! Please keep up posted.
Jan
Jan
Jan 16, 2025, 8:46:27 AM1/16/25
to ope...@googlegroups.com
Hi All!
I'd like to follow up on this topic and kindly ask you for your
opinion. As you can read in this thread, there is some restructuring
required to keep OpenPnP alive. It'll only stay alive if you and we all
participate and that means - IMHO - that we shall agree on how to continue.
It was discussed:
- That the current test version is quite stable and shall become the
next stable version.
- As Mark can not review each PR thoroughly anymore, a new
version/branch shall be initialized that receives new features quickly
and hence may be less stable compared the current test-version.
- This new branch needs testing and reviewing to make it stable.
- Once the new branch has collected a set of new features, this shall
stabilize and flow back creating a new stable version.
Help, participation, opinions and feedback on all this points is very
much appreciated.
Finally I'd kindly ask the senior members to explain how the process of
adding new features could be handled in the future. I'm aware that
OpenPnP still accepts PRs which are available for public review and
discussion. What I don't see yet is how this PRs will be merged. In the
past Mark and Tony where doing the reviewing and merging. Whats the
established procedure (if any) you're following? Are others allowed to
do the same? How could that be handled in the future?
Jan
I'd like to follow up on this topic and kindly ask you for your
opinion. As you can read in this thread, there is some restructuring
required to keep OpenPnP alive. It'll only stay alive if you and we all
participate and that means - IMHO - that we shall agree on how to continue.
It was discussed:
- That the current test version is quite stable and shall become the
next stable version.
- As Mark can not review each PR thoroughly anymore, a new
version/branch shall be initialized that receives new features quickly
and hence may be less stable compared the current test-version.
- This new branch needs testing and reviewing to make it stable.
- Once the new branch has collected a set of new features, this shall
stabilize and flow back creating a new stable version.
Help, participation, opinions and feedback on all this points is very
much appreciated.
Finally I'd kindly ask the senior members to explain how the process of
adding new features could be handled in the future. I'm aware that
OpenPnP still accepts PRs which are available for public review and
discussion. What I don't see yet is how this PRs will be merged. In the
past Mark and Tony where doing the reviewing and merging. Whats the
established procedure (if any) you're following? Are others allowed to
do the same? How could that be handled in the future?
Jan
Toby Dickenson
Jan 18, 2025, 5:05:44 AM1/18/25
to ope...@googlegroups.com
> I'd like to follow up on this topic
All agreed.
> - That the current test version is quite stable and shall become the next stable version.
branch as the best version for most users, so we have been unknowingly
treating it as a release candidate. A formal feature-freeze for this
release makes sense.
But there are some changes required for this release. I thought it
would be useful to start a list:
1. Version number. develop branch was 2.0 (right?) and the test branch
is still using that same number. 2.1?
2. Copyright date
3. Release notes - I made https://github.com/openpnp/openpnp/pull/1723
4. Updating https://openpnp.org/downloads/
5. How are the files linked from that page maintained?
6. What else?
> - As Mark can not review each PR thoroughly anymore
Reply all
Reply to author
Forward
0 new messages