Open smoe opened 2 years ago
Le dim. 14 août 2022 à 19:17, Steffen Möller @.***> a écrit :
I feel that libnml is a gem of LinuxCNC that is not finding the recognition it deserves. Just as a hunch, I could for instance imagine that BOINC would want to use that, too. Would it be well-perceived in the community if libnml moves into https://github.com/LinuxCNC/libnml?
I'd support this as I would for HAL separation 👍🙏 This fits perfectly the meta-NC nature of the project.
I guess that the community would not be ready yet for a separation of HAL. Something more low-level-ish like libnml may be a good exercise to learn how it goes. If there are no adopters of that technology then we can just leave it all as it is. Just, we already know that HAL has adopters that are external to LinuxCNC. This effectively means that we also have external adopters of libnml, but we have not singled that library out, yet.
Le dim. 14 août 2022 à 20:22, Steffen Möller @.***> a écrit :
I guess that the community would not be ready yet for a separation of HAL.
Not as a whole, but MachinKit having already done it means some of us are, or at least have been!
@hansu , could you please put this on the agend for the next Open Mike session?
@hansu , could you please put this on the agend for the next Open Mike session?
:heavy_check_mark:
Personally, I believe splitting up the code base should only be done on request by someone already using the particular fraction of linuxcnc today. Is there such request? To me, splitting out the library is way down on the priority list, below integrating new components added to machinekit but not linuxcnc, below making it reproducible, below regular live ISO build, automated GUI testing and a lot of other development work that need to take place.
This is not to say that those that want to spend time on the split should not do so, but that they should have a clear idea of the advantage of it and be willing to spend time on maintaining such separate git repo.
-- Happy hacking Petter Reinholdtsen
I disagree, obviously. We should find if any of the points you mentioned do somehow benefit from LinuxCNC being external to the source tree. From how I perceive libnml, this is mostly invariant and the oldest code base in the project: It is already separated, just not formally so.
There was actually a lot of talk (at one time) to replace NML. If your serious about putting in work to separate it, then maybe discussing replacing it would be pertinent.
[c-morley]
There was actually a lot of talk (at one time) to replace NML.
What could it be replaced with? Where was this discussed?
-- Happy hacking Petter Reinholdtsen
it was a goal of machinekit to replace nml with something based on some other tech, zeromq. Doing a local search of my personal maiing list archive, it looks like "zeromq" as a search term brings up a number of vintage posts.
Le sam. 20 août 2022 à 16:35, Jeff Epler @.***> a écrit :
it was a goal of machinekit to replace nml with something based on some other tech, zeromq. Doing a local search of my personal maiing list archive, it looks like "zeromq" as a search term brings up a number of vintage posts.
Interesting, thanks 👍
it was a goal of machinekit to replace nml with something based on some other tech, zeromq. Doing a local search of my personal maiing list archive, it looks like "zeromq" as a search term brings up a number of vintage posts.
Didn't you and Seb start on something similar at a fest once too?
The thing Seb & I started was a "plain C" API to LinuxCNC, but it didn't necessarily get rid of libnml .. it was about the problem that the "most native API" was C++-only and that's a bad fit for exposing to scripting languages as well (today) to trendy young languages like rust. It didn't get very far.
I found https://stackshare.io/stackups/mqtt-vs-zeromq helpful. I did not know that there was a motivation to see libnml completely removed.
On Sun, 21 Aug 2022 at 00:50, Steffen Möller @.***> wrote:
I found https://stackshare.io/stackups/mqtt-vs-zeromq helpful. I did not know that there was a motivation to see libnml completely removed.
Message ID: @.***>
-- atp
Le lun. 22 août 2022 à 01:56, andypugh @.***> a écrit :
On Sun, 21 Aug 2022 at 00:50, Steffen Möller @.***> wrote:
I found https://stackshare.io/stackups/mqtt-vs-zeromq helpful. I did not know that there was a motivation to see libnml completely removed.
See:
So much interesting stuff there! 😲🤩👍
Le lun. 22 août 2022 à 03:48, Jérémie Tarot @.***> a écrit :
Le lun. 22 août 2022 à 01:56, andypugh @.***> a écrit :
See:
Definitely a lot of things squeeze out of this thread after reading the second half!
It's also somehow good to see that components independency and distributability (ie network and sync), programming interfaces upgrade and standardization (zmq, and orocos IIUC), and other architectural choices are shared vision by many community members and for a long time...
Clever folks in this discussion raised a lot of technical and planning points I'll gather in some form of document...
A significant part of tve messages also deal with licensing issues. Specially, a potential legal incompatibility with ZeroMQ GPLv3 is raised, notably due to parts of LinuxCNC being GPLv2 only. Work on upgrading this situation to get all code GPLv2+ is said to be needed... Has this been done? What's our current licences portfolio?
PS: as my tech understanding and prog skills are still both in their early infancy, please correct any error or misunderstanding. Thanks in advance 🙏
Le lun. 15 août 2022 à 13:41, Hans @.***> a écrit :
@hansu https://github.com/hansu , could you please put this on the agend for the next Open Mike session?
✔️
Could we use:
Would also allow linking in projects if we come to put them to use
Le sam. 20 août 2022 à 10:42, petterreinholdtsen @.***> a écrit :
[c-morley]
There was actually a lot of talk (at one time) to replace NML.
What could it be replaced with? Where was this discussed?
I'm curious too!
Michael Haberler was keen to replace NML with (I think) ZeroMQ. Or maybe Redis. Or possibly a combination of the two. (This was before the Machinekit split) If you search the email archiive for 0MQ, zeromq and redis you should be able to get some context.
Le mar. 11 oct. 2022 à 10:08, andypugh @.***> a écrit :
Michael Haberler was keen to replace NML with (I think) ZeroMQ. Or maybe Redis. Or possibly a combination of the two. (This was before the Machinekit split) If you search the email archiive for 0MQ, zeromq and redis you should be able to get some context.
Thanks for the reference.
For ease: https://sourceforge.net/p/emc/mailman/search/?q=0mq&mail_list=all&limit=100 https://sourceforge.net/p/emc/mailman/search/?q=zeromq&mail_list=all&limit=100 https://sourceforge.net/p/emc/mailman/search/?q=redis&mail_list=all&limit=100
Also Wiki pages: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNCVersion2 http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MessagingLayer http://wiki.linuxcnc.org/cgi-bin/wiki.pl?CustomNMLMessage http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Dbus_Vs_NML http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Halui
I feel that libnml is a gem of LinuxCNC that is not finding the recognition it deserves. Just as a hunch, I could for instance imagine that BOINC would want to use that, too. Would it be well-perceived in the community if libnml moves into https://github.com/LinuxCNC/libnml?
Disadvantage:
Advantages:
Supporting (if this works out as I hope):