#linuxcnc-devel Logs

Jun 13 2019

02:42 AM -!- #linuxcnc-devel mode set to +v by ChanServ
12:30 PM memfrob: Hi, I found a problem with LinuxCNC: LinuxCNC does not actually require python-vte nor python-glade2, and these packages have been deprecated in sid: https://packages.debian.org/sid/python-glade2 https://packages.debian.org/sid/python-vte
12:32 PM andypugh: What does Python-glade2 do? It seems like it might be needed for GladeVCP ?
12:32 PM andypugh: (ie I imagine that LinuxCNC might compile without it, but might also need it)
12:32 PM memfrob: the sim axis runs?
12:34 PM andypugh: sim-axis-gladevcp ?
12:34 PM memfrob: Maybe not that one, just sim-axis
12:34 PM memfrob: haven't tried that one.
12:34 PM memfrob: What does regular sim-axis use? pyvcp?
12:35 PM andypugh: Without an extra panel, neither.
12:35 PM andypugh: I don’t know, I am just guessing.
12:35 PM memfrob: so sim axis just uses tcl/tk?
12:35 PM memfrob: with bwidget and whatever else?
12:36 PM andypugh: Not sure
12:38 PM andypugh: A _lot_ of stuff disappears when you apt-get remove python-glade2
12:38 PM andypugh: (including bwwidget..)
12:38 PM memfrob: Maybe on buster or stretch
12:38 PM memfrob: python-glade2 is leftover cruft in sid lol
12:40 PM memfrob: This patch allows me to build for sid, and the basic fundamentals of linuxcnc works: http://dpaste.com/30DF8AE
12:40 PM andypugh: But: Machine configuration directory is '/home/andypugh/linuxcnc-dev/configs/sim/axis/gladevcp'
12:41 PM andypugh: ImportError: No module named glade
12:41 PM andypugh: Can you quickly try the gladevcp sample config?
12:42 PM memfrob: ImportError: No module named glade
12:42 PM memfrob: :)
12:43 PM andypugh: Reinstall python-glade2 and it works agin (without compile_
12:43 PM memfrob: So we're not using glade and you are, so linuxcnc built this way will work for us but not you.
12:43 PM andypugh: Looks to be a run-time rependency not a compile-time one
12:43 PM memfrob: How to force install a debports package?
12:45 PM andypugh: Maybe we should:
12:45 PM andypugh: This package is deprecated, you should migrate to using
12:45 PM andypugh: gobject-introspection (GIR) based python bindings instead (PyGObject).
12:45 PM andypugh: https://wiki.gnome.org/Projects/PyGObject/IntrospectionPorting
12:46 PM memfrob: Weird, python-glade2 just installed fine.
12:46 PM memfrob: python-vte will be a bigger pain.
12:48 PM memfrob: Oh, python-imaging-tk was the one I had problems installing, that and python-vte
12:49 PM memfrob: Note, selecting 'python-pil.imagetk' instead of 'python-imaging-tk'
12:49 PM memfrob: Package python2.7-imaging-tk is not available, but is referred to by another package.
12:49 PM memfrob: python-pil.imagetk is already the newest version (5.4.1-2).
02:24 PM cerna: memfrob: Are you actively developing/using the Xenomai RT system?
02:38 PM CaptHindsight: no, just preempt_rt
02:41 PM cerna: Ah, I have been going by that memfrob posted link to http://dpaste.com/30DF8AE which contains numerous references to libxenomai.
04:03 PM andypugh: memfrob: I tried doing what they say here: https://wiki.gnome.org/Projects/PyGObject/IntrospectionPorting
04:03 PM andypugh: And i was making progress but eventually hit: File "/usr/lib/python2.7/dist-packages/gi/__init__.py", line 64, in __getattr__
04:03 PM andypugh: raise AttributeError(_static_binding_error)
04:03 PM andypugh: AttributeError: When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject"
04:04 PM andypugh: mozmck: Ping?
04:04 PM andypugh: mozmck_m:
04:04 PM mozmck: hi andypugh
04:04 PM andypugh: Did you see what memfrob said about python-glade2?
04:04 PM andypugh: (sounds like a 2.9 change, though)
04:06 PM mozmck: Yes. I haven't done any testing with buster yet. seb_kuzminsky has though.
04:06 PM andypugh: You can uininstall it and sim-axis-gladevcp configs fail, then reinstall it and they run again.
04:07 PM andypugh: I see that some files are already using “from gi.repository import GObject, Gtk"
04:08 PM mozmck: Yes, that's the python interface for glade2 which is needed for most guis in linuxcnc so far. I think porting to PyGObject would be more than major - probably require python3 and/or gtk3 as well.
04:08 PM andypugh: We might need from gi.repository import Gtk as gtk, GObject as gobject
04:09 PM andypugh: (or lots of search and replace)
04:10 PM andypugh: Actually, it loos like on some levels porting to PyGobject is trivial: https://wiki.gnome.org/Projects/PyGObject/IntrospectionPorting
04:11 PM mozmck: Yeah, I'm not sure. Eventually I think the way forward is something Qt based.
04:11 PM andypugh: I managed to make all the _linuxCNC_ code run without python-glade2 with abotu 15 minutes work, then found a naughty file in /usr/lib/python2.7
04:12 PM mozmck: It looks like from that page that it may require moving to gtk3?
04:12 PM mozmck: Well, I wouldn't expect the linuxCNC code to use glade at all - just interfaces using glade such as gladevcp, gscreen, gmoccapy and???
04:16 PM mozmck: andypugh: yeah, from that link "(Porting from PyGTK 2 to PyGI GTK 3) is recommended as GTK2 still has a lot of breakage with PyGI."
04:17 PM mozmck: But several people have worked on that and nothing ever finished. I believe CMorley and hazzy-m both started out working on GTK3 ports and gave up and switched to QT instead.
04:18 PM andypugh: I think we need help from someone who knows this stuff. Though Chris seems to have moved over to QtPy and might not want to be bothered with Glade.
04:19 PM andypugh: I am not really happy with the idea of telling folk “Oh, by the way, your Glade panels won’t work any more”
04:19 PM hazzy-m: What needs looking at with Glade?
04:23 PM andypugh: Apparently python-glade2 is deprecated. It might not even exist for much longer
04:24 PM andypugh: And whilst it isn’t a buiild dependency for LinuxCNC the Glade panels won’t run without it.
04:24 PM andypugh: (you can test this, apt-get remove it, try to run a sim with glade, then re-install it and it all works again.
04:28 PM mozmck: glade2 has been deprecated for a long time.
04:30 PM mozmck: buster is not even released yet though, so I don't see a need to panic over it. I do think we should look seriously at replacing everything that uses glade2/gtk2 with either gtk3 or qt based interfaces for the 2.9 release.
04:39 PM mozmck: mmm, that could sound bad - sorry andy. It does look like python-glade2 will be in buster so that gives us some time for now. The glade 2 screen builder though I think has not been installable for several releases of debian.
04:48 PM mozmck: andypugh: looks like even wheezy did not have the older version of glade-gtk2 required - I think cradek put it on the livecd though.
05:20 PM andypugh: It’s a level of detail I have never really looked at.
05:20 PM andypugh: (I only ventured outside HAL for the first time a couple of years ago)
05:21 PM andypugh: We probably do need to decide what kernels (kernels?) and OS 2.8 will be tageted at, and packaged with.
05:21 PM mozmck: agreed.
05:22 PM mozmck: I would like to do some testing with RTAI again. I see others using 5.2, so it must work for someone.
05:23 PM andypugh: I think that it might be an order og magnitude harder to make a working distro than to make it work on a particular machine.
05:23 PM cerna: RT extensions are topic which highly interests me. Pleaso, who is running RTAI 5.2?
05:24 PM andypugh: We _could_ try to make Jessie work. That’s on a 3.x kernel. Maybe even try a 32 bit Jessie
05:24 PM mozmck: andypugh: true. I compiled the kernel and rtai for ubuntu 10.04 and tested on a number of different computers.
05:24 PM memfrob: andypugh and mozmck, thank you for looking into this gobject stuff.
05:25 PM andypugh: cerna: Building 5.2 is pretty easy (the patch takes cleanly and compiles). Having it actually not crash when you try to use realtime has so far defeated me.
05:26 PM mozmck: memfrob: no problem. It is something that will have to be changed at some point. I think Qt is probably the way forward though.
05:26 PM andypugh: memfrob: I think that the gobject stuff is just a big search and replace. I am pretty close with about 30 minutes looking at it.
05:26 PM memfrob: I haven't played with RTAI 5.2 yet. andypugh, considering my tree doesn't work for you either, I'd advise you not running RTAI on your particular hardware.
05:26 PM andypugh: But it goes too deep for 2,8 release. That should now be at the “polishing” stage
05:27 PM cerna: andypugh: Ah. So nobody was able to run rtapi on it yet, I take it?
05:27 PM andypugh: rtapi yes, but only with prempt-rt
05:28 PM andypugh: Ah, you mean LinuCNC rtapi on RTAI 5.2?
05:28 PM andypugh: yes, that seems to be a problem, for me, on my hardware.
05:28 PM memfrob: cerna, if you are interested in RTAI 5.2 the first step would be running the RTAI testsuite on it.
05:28 PM memfrob: Make sure rtai_hal.ko and rtai_sched.ko load, and don't cause a panic. Once you get that far, build linuxcnc against it.
05:29 PM cerna: Sorry, I am a lot more familiar with Machinekit's codebase than LinuxCNC's. So I might get the terminology a little bit off.
05:29 PM mozmck: andypugh: so you are not having to switch to gtk3?
05:29 PM andypugh: cerna: It’s really easy to try. As I said, the patch takes cleanly and the compile / install of the kernel and compile of RTAI is straightforward. Maybe it will :just work” on uyour hardware, and that would be a real encouragemet.
05:29 PM cerna: memfrob: I am planning on it after I get the userspace RTOSes working.
05:29 PM memfrob: cerna, LinuxCNC has not been known to work at all with any release of RTAI 5.X yet, except maybe seb_kuzminsky on some system of his.
05:30 PM memfrob: cerna, what distribution are you on? Some distros have a preempt_rt kernel package, just install that and build linuxcnc with ./configure --with-realtime=uspace
05:31 PM andypugh: mozmck: No, it looks like most of our code will _probably_ work as-is with changes to the imports at the top pt Python files.
05:32 PM cerna: I am on Debian. But I am looking into the Xenomai/v3.0.x/next support.
05:32 PM andypugh: Swap “import gtk / import gobject” for “from gi.repository import Gtk as gtk, GObject as gobject” seems to get you 90% of the way there.
05:32 PM cerna: memfrob: Preempt_rt works quite well already, so I am not looking into it.
05:34 PM memfrob: cerna, you just said you'd be trying to get RTAI working after you get userspace RTOS working, but you said you already did, so I'm now confused.
05:34 PM andypugh: This is where there is an issu. Preempt-RT works like a dream for me too. My test PC manages 3k latency with preempt-rt. That’s better than I have ever seen with RTAI. But other users report 75k latency on machines running RTAI at <20k
05:34 PM memfrob: andypugh, you just described my systems.
05:35 PM memfrob: preempt_rt is around 100k, rtai less than 20, even without isolcpus etc
05:35 PM mozmck: That seems especially true on lower end systems
05:36 PM andypugh: Unless we chose to drop the parport (:-) I think we need to offer RTAI in some form or another. This could be Wheezy, but that would make us look bad :-)
05:37 PM memfrob: Well I'm running this on a Ryzen CPU.
05:37 PM cerna: memfrob: The Preempt_RT rtapi is working -> almost everybody is using it. But Xenomai version 3 is not working currently (and it is also able to run as a userspace RTOS extrension). And you can use the native Alchemy flavor of Xenomai or some other "skins" which are trying to emulate for example VxWorks and so on.
05:38 PM memfrob: Does LinuxCNC support Xenomai 3 with cobalt, or only MachineKit?
05:38 PM memfrob: cobalt specifically, the one with IPIPE.
05:39 PM cerna: memfrob : LinuxCNC nor Machinekit doesn't support it. As far as I know. I was able to run Machinekit over Cobalt.
05:43 PM andypugh: LinuxCNC has _some_ support for Xenomai. I am fuzzy on the details.
05:43 PM cerna: Problem is, the Xenomai project and it's keeps shifting in it's core intentions. With adding of the Mercury and Cobalt distinctions they are trying to create general framework for abstracting the RT layer. So the application would not care and maybe even know if it is running over Cobalt, Mercury or Vanilla Kernel.
05:43 PM memfrob: You said it doesn't support it, but you also say you have machinekit working over cobalt.
05:43 PM cerna: andypugh: Xenomai 2, I think. Quite different animal.
05:44 PM cerna: memfrob: Extremely ugly development version.
05:44 PM cerna: Not ready for merge in a long stretch.
05:44 PM andypugh: I think that LinuxCNC can use Xenomai as a “uspace” kernel instead of preempt-rt. But, as I said, I am fuzzy on the details.
05:44 PM memfrob: cerna, you have xenomai 2 or 3, with or without cobalt, working with machinekit?
05:45 PM memfrob: I'm trying to keep it straight but you keep jumping around.
05:47 PM cerna: memfrob: OK, the Xenomai 2, now EOL and with no support from Xenomai development team, is possible to run on Machinekit and I think on LinuxCNC as is. The Xenomai3, I have been trying to get running and have somewhat experimental and ugly version of it. (Think of it like LinuxCNC versions: RTAI, Xenomai2, Xenomai3, Preempt_RT).
05:48 PM CaptHindsight: andypugh: I'm running 2.7 on Stretch with preempt_rt with LPT. Jitter is ~14us with dial core celeron 784
05:48 PM CaptHindsight: andypugh: dial/dual
05:48 PM andypugh: Yes, it can work really well.
05:48 PM cerna: memfrob: With Cobalt, but now for Xenomai library, it is not really that big distinction. Xenomai nowadays is trying to isolate it from you.
05:49 PM cerna: memfrob: You would write one application and it would run over Cobalt and Mercury without any changes.
05:50 PM andypugh: Unfortunately the guys with the bad PCs seem to not be the same ones as could build is an RTAI kernel to solve their problem (and ours). Which leaves those of us without the problem trying to fix it.
05:50 PM CaptHindsight: andypugh: maybe just linux-3.16.52 RTAI for Stretch and then only preempt_rt for any newer releases
05:51 PM cerna: memfrob: So you could run LinuxCNC over Xenomai, but you would be actually running your LinuxCNC over Preempt RT.
05:51 PM cerna: Which is problem or could be problem. Depending at how one looks at it.
05:51 PM memfrob: Xenomai sounds like too much of a train wreck for me to even think about at this point.
05:52 PM CaptHindsight: andypugh: I'm not really interested in supporting someone that doesn't want to pay extra for a FPGA card
05:52 PM cerna: memfrob: I consider it fun.
05:52 PM JT-Shop: andypugh: I've built so many kernels lately I wrote a bash script to make the unpacking and patching easy
05:52 PM memfrob: I always saw Xenomai as a cleaner interface to IPIPE than RTAI, but with all these core infrastructure changes, it just gives me a headache.
05:52 PM andypugh: CaptHindsight: A choice _you_ are free to make.
05:53 PM CaptHindsight: andypugh: can't afford is another story
05:53 PM andypugh: CaptHindsight: Does Stretch run on 3.16. ? I can’t recall if I tried that.
05:54 PM memfrob: Distro and kernel are irrelevant.
05:54 PM CaptHindsight: compulsive obsessive money collecting doesn't not mean can't
05:54 PM memfrob: I'm going to start wearing a t-shirt that says that, and bring a box of them to the next LinuxCNC fest.
05:54 PM memfrob: What size are you guys?
05:55 PM CaptHindsight: andypugh: you can run a 5.x kernel on wheezy
05:56 PM cerna: memfrob: Yeah, well they decided to go this way. If it is good or bad decision only history will tell. For a new project it could be actually helpful as it would mean Xenomai would carry you over some big designing choices.
05:56 PM JT-Shop: depending on the hardware 5.x may not be a good choice as far as latency is concerned
05:56 PM andypugh: LinuxCNC actually has a 3.16 kernel package. But it’s flaky. http://www.linuxcnc.org/dists/jessie/base/binary-amd64/
05:57 PM memfrob: JT-Shop, why do you say that? I'm running 5.x preempt_rt here.
05:57 PM andypugh: “depending on the hardware"
05:57 PM JT-Shop: because on my J1900 5.x I got ~250us latency
05:57 PM JT-Shop: 4.19 ~150us
05:57 PM JT-Shop: 4.4 ~30us
05:59 PM memfrob: Heh, we were actually trying to find a J1900 for a good deal because latency is always amazing on the celerons.
05:59 PM memfrob: It might have been the features enabled in the kernel, there is no 5.x preempt_rt package, at least not for debian,
06:00 PM JT-Shop: that was on Lubuntu 19.04
06:00 PM JT-Shop: is on
06:00 PM memfrob: ubuntu repos have a 5.x preempt_rt package?
06:00 PM mozmck: JT-Shop: I've seen similar with the J1900. Newer kernels give worse latency.
06:01 PM JT-Shop: I build all my kernels
06:01 PM CaptHindsight: *ubunt is that linux-like distro that changes the name of all the system files and relocates them in the file system :)
06:01 PM memfrob: Do you use make tinyconfig and build from there?
06:02 PM memfrob: JT-Shop, using nohz_full rcu_nocbs idle=poll and isolcpus might fix that latency issue.
06:02 PM memfrob: Example kernel config: https://github.com/NTULINUX/aggressive_kernel_patches/blob/master/ryzen_quadcore_rt.config
06:03 PM mozmck: CaptHindsight: which files are you referring to?
06:04 PM memfrob: CONFIG_NO_HZ_FULL=y CONFIG_CPU_ISOLATION=y CONFIG_RCU_NOCB_CPU=y
06:04 PM mozmck: memfrob: I use isolcpus on j1900 preempt-rt, but I still see the trend JT-Shop mentions. I think with 4.19 my worst case latency was more like 120us
06:05 PM memfrob: What about nohz_full and rcu_nocbs and idle=poll ? There is more to latency tuning than isolcpus
06:05 PM JT-Shop: what do those options do?
06:06 PM JT-Shop: I have managed to set the governor to performance
06:06 PM memfrob: https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt -> Omit scheduling-clock ticks on CPUs that are either idle or that have only one runnable task (CONFIG_NO_HZ_FULL=y).
06:06 PM mozmck: I'm not sure idle=poll helps with preempt-rt from what I've read.
06:07 PM memfrob: If you're able to set the governor, then you have CONFIG_PM on, which should be off.
06:07 PM CaptHindsight: mozmck: most all of em :)
06:07 PM mozmck: nohz_full was broken until more recent kernels so I wasn't using it. I need to try it on the latest ones though.
06:07 PM memfrob: ACPI_PROCESSOR should be disabled too.
06:09 PM memfrob: rcu_nocbs a list of the CPUs in your system that should have their RCU callbacks offloaded to threads. Normally, people use it to fence off a few CPUs from the random interruptions of softirq RCU callbacks.
06:09 PM memfrob: https://utcc.utoronto.ca/~cks/space/blog/linux/KernelRcuNocbsMeaning
06:11 PM memfrob: Using rcu_nocbs=1,2,3 nohz_full=1,2,3 isolcpus=1,2,3 and idle=poll gives me the best latency on a quad-core CPU. isolcpus=3 still allows cache sharing and multi-threading, so it matters, even though linuxcnc only runs on core 3.
06:11 PM mozmck: Thanks for the links - I will be trying out some of those! Apparently you can get RCU stalls when you use rcu_nocbs, but the redhat article that tells how to fix it is for subscribers only: https://access.redhat.com/solutions/2260151
06:11 PM memfrob: Or in bios, turn your quad-core into a dual core, then replace =1,2,3 with just =1 and it'll be just as low latency.
06:12 PM memfrob: I don't have any RCU stalls on my system
06:12 PM mozmck: You mean by turning off hyperthreading?
06:13 PM memfrob: Disabling hyperthreading isn't exactly the same, although that should be done too.
06:14 PM memfrob: In order to disable hyperthreading in the kernel, you need this patch: https://github.com/NTULINUX/aggressive_kernel_patches/blob/master/5.0-rt/0005-arch-x86-Kconfig-Make-SCHED_SMT-optional-again.patch
06:14 PM memfrob: I'm doing all of this on the 5.x preempt_rt kernel from this tree: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=linux-5.0.y-rt
06:16 PM memfrob: Disabling hyperthreading and multi-core processing are two different things. Isolating all the cores except for one disables multi-core processing. Hyperthreading hurts performance too, but so does SMP.
06:17 PM memfrob: The best way I found to get the absolute lowest latency is to have Linux and your RT threads only have access to one core, whether it's disabling all but 2 cores in the BIOS, then using isolcpus=1 rcu_nocbs=1 nohz_full=1 OR.. having all cores enabled in BIOS then filling all values with 1,2,3
06:19 PM memfrob: Regardless of which approach you take, hyperthreading should also _ALWAYS_ be off, as well as CONFIG_SCHED_MT and CONFIG_SCHED_SMT
06:19 PM memfrob: (hyperthreading disabled in both kernel and BIOS)
06:26 PM mozmck: I think for most people using preempt-rt disabling multi-core processing would cause poor performance for little gain. Might as well just buy a dual-core proc instead of wasting the rest.
06:53 PM pcw_mesa: Not sure why you would care much about latency unless you are running a parallel port or there's an issue at 1 KHz servo thread
06:55 PM pcw_mesa: ( or is this because of problems with RTAI that leave parallel port users stuck with Preempt-RT on newer hardware/OS's )
06:56 PM andypugh: yes, the second point
06:57 PM pcw_mesa: no one having luck with newer RTAI kernels?
06:58 PM CaptHindsight: no RTAI for new hardware and software stepping
06:59 PM CaptHindsight: not so much luck as no funding :)
07:01 PM memfrob: Indeed you are better off buying a dual core instead of a quad core and turning off half the cores lol.
07:01 PM CaptHindsight: there is new RTAI 5.x sources up at rtai.org but it's not going to work well without a bunch of cleanup
07:01 PM pcw_mesa: Preempt-RT is as good or better jitter wise than RTAI but only on some hardware, RTAI is decent on a much wider range of hardware (esp lower power hardware)
07:02 PM CaptHindsight: 1.1GHz celeron 784 with preempt_rt is at 13.8uS jitter, RTAI ~28uS from the old wheezy install
07:02 PM CaptHindsight: yeah, depends on hardware
07:03 PM pcw_mesa: Yeah I get about 7 usec on a G3258
07:03 PM CaptHindsight: the new Ryzens share cache between all cores so that is why isolcpus set to turn it into 2 cores helps latency so much
07:03 PM pcw_mesa: but 150 usec on a J3355
07:04 PM pcw_mesa: and there are new-new Ryzens...
07:04 PM CaptHindsight: the cheapest ryzen cpu currently has 4 cores
07:07 PM pcw_mesa: wonder if anyone has tried that new-fangled cache locking scheme that some new CPUs have
07:10 PM cerna: pcw_mesa: Could you post a link? THanks.
07:13 PM pcw_mesa: I was thinking of Intels CAT, not sure if AMD has an equivalent
07:14 PM CaptHindsight: the new Ryzens out next month will have up to 70MB (bytes) of cache
07:14 PM CaptHindsight: enough for kernel and application to run in L3 cache
07:16 PM pcw_mesa: certainly the real time portions would fit
07:35 PM memfrob: The trickiest part about getting RTAI 5 working with LinuxCNC will be getting the new math code working: https://github.com/NTULINUX/RTAI/tree/dissect/base/math
07:35 PM memfrob: RTAI used to include all it's own math funcs but now it asks for an exact path to the glibc/musl etc shared library, and LinuxCNC doesn't know about this change yet.
07:37 PM andypugh: Hmm, RTAPI defines its owbn thread-safe maths functions
07:37 PM andypugh: So that might be easy, or imposible, or something in between.
07:37 PM memfrob: You need RTAI math enabled, I know that much.
07:39 PM andypugh: LinuxCNC code should be using rtapi_math functions, it is possible that RTAI will never see any maths calls.
07:39 PM memfrob: Oh crap, RTAI removed support for GLIBC it seems.
07:41 PM memfrob: https://github.com/NTULINUX/RTAI/commit/040f2463393518c34ce6fa7e29449dde3e42e234#diff-9ce7ca257230e32f52e368e7b443157a
07:42 PM memfrob: So in order to compile RTAI, and your distro uses glibc (which is most of them) you must compile a separate c library, just for RTAI to use for it's math symbols
07:43 PM andypugh: So….. is Xenomai any good :-)
07:43 PM memfrob: newlib or musl is the question then. I think newlib is more standardized and embeddable.
07:43 PM memfrob: Well, I can fork RTAI 5 like I did with 3 and 4, and add newlib to the RTAI source tree and have it build that along with it.
07:44 PM andypugh: More seriously, linuxcnc provides rtapi_math. Is that equivalent?
07:45 PM memfrob: rtapi_math is not 100% standalone, not with RTAI anyway
07:45 PM memfrob: I don't know, jepler knew all this stuff.
07:45 PM andypugh: He stil does.
07:45 PM memfrob: Haha, yes he does.
07:45 PM memfrob: let me read rtapi_math..
07:46 PM andypugh: He would probably answer specific questions.
07:46 PM memfrob: Ok, so rtapi_math at a quick glance are the math functions that linuxcnc uses.
07:47 PM andypugh: They are the ones that LinuxCNC deems thread-safe and therefore acceptable.
07:47 PM memfrob: but symbols such as acos, fmin, fmax etc are not declared
07:47 PM andypugh: Indeed. I have alwats assumed we are meant to do without.
07:48 PM memfrob: without what?
07:48 PM andypugh: (you can get the same answers with included functions)
07:49 PM andypugh: “If it’s not on rtapi_math then find another way to calculate your answer”
07:50 PM memfrob: I don't really know C very well so I don't know how any of this works. This is the source for acos for example: https://github.com/NTULINUX/RTAI/blob/master/base/math/e_acos.c
07:50 PM andypugh: For example, write your own fmin sub, which should be thread-safe, and could potentially split the task in time for long inputs)
07:51 PM memfrob: instead of RTAI providing e_acos.c, these are just exported symbols now from the external C library
07:51 PM memfrob: old RTAI math: https://github.com/NTULINUX/RTAI/blob/master/base/math/libm.c
07:52 PM andypugh: Hmm. If I was a proper programmer I wouldknow what that meant.
07:52 PM memfrob: And all of those EXPORT_SYMBOL lines are internal RTAI functions that are just copied from netbsd and other 1980s math projects
07:52 PM Tom_L: did math change over the years?
07:53 PM memfrob: The current RTAI code links to the C shared library and are exported just like they were before.
07:53 PM memfrob: https://github.com/NTULINUX/RTAI/blob/dissect/base/math/libm.c
07:53 PM andypugh: e_acos.c looks like it is doing acos on an FP operand usong only integer operations.
07:53 PM memfrob: No, I'm just saying that RTAI has always re-used 20 year old code.
07:53 PM CaptHindsight: Tom_L: if you ask Chicago public school teachers in the 2000's they would say YES
07:54 PM andypugh: No, I am wrong. It’s not _that_ clever
07:54 PM memfrob: Now they've adapted to the modern way of providing IEEE 754 FP -- without copy and pasting 1980s code from netbsd and AT&T
07:55 PM memfrob: The C libraries themselves do everything RTAI used to do. For example, this is musl's e_acos.c: https://git.musl-libc.org/cgit/musl/tree/src/math/acos.c
07:56 PM memfrob: SO instead of that file being in RTAI directly, it uses musl to provide the e_acos func
07:58 PM memfrob: so LinuxCNC would just need to accept the fact that math is no longer in RTAI directly, but instead exported from said C library
07:59 PM memfrob: You just can't use your system's C library if you're using GLIBC, as this was apparently always broken with RTAI on x86_64 platforms, so Paolo said screw it, I'm removing it.
08:01 PM memfrob: Adding newlib to RTAI would be really easy for me to do after some trial and error.
08:01 PM andypugh: I am guessing that is why LinuxCNC had rtapi_math, a collection of not-broken cunctions.
08:02 PM memfrob: cd RTAI && git clone newlib ; echo "cd newlib && ./configure && make" >> ../GNUmakefile ; then fix the tree up to take math from tree's internal newlib
08:04 PM memfrob: in between echo and git clone should be cd newlib
08:04 PM memfrob: you get the idea.
08:05 PM memfrob: Then I modify RTAI's ./configure and Kconfig and hard-code RTAI_MATH_LIBM_DIR and RTAI_MATH_LIBM_TO_USE
08:08 PM memfrob: I could also just copy all the old RTAI math code in place of what's there now, be really easy.
08:09 PM memfrob: rm -rf RTAI_5.2/base/math && mv RTAI_old_stable/base/math RTAI_5.2/base/math ; minor fixes to Kconfig configure and maybe some other makefile ; done
08:12 PM andypugh: No, actually, I don’t get the idea. Perhaps you should work on the assumption that we are all 4.5 x less clever than you?
08:13 PM andypugh: I barely understand the problems, the solutions are way out of my cognizance.
08:17 PM memfrob: The problem is that RTAI stopped including 500 separate math files and now relies on the C library to do so.
08:18 PM memfrob: But in order to properly package RTAI, you'd need to package a C library for it to use along with it, since most distributions use glibc.
08:19 PM memfrob: You either include newlib with RTAI, or only package RTAI for musl or newlib-based distros.
08:21 PM memfrob: Ah seb_kuzminsky already kinda does this: https://github.com/SebKuzminsky/rtai/blob/vulcano-debs-2017-05-19/debian/rules.in
08:22 PM memfrob: I don't see where he's grabbing newlib though
08:24 PM memfrob: cd /tmp/newlib; tar -xJf /usr/src/newlib/newlib-*.tar.xz --- Where is this tarball coming from?
08:30 PM memfrob: debian/control.in has this in it: debian/control.in:Build-Depends: debhelper, newlib-source, @KERNEL_HEADERS@
08:31 PM memfrob: that's just the dependency.. apt-get install newlib-source won't automatically put it in /usr/src/newlib will it?
08:32 PM memfrob: Oh, it does!
08:33 PM memfrob: rules.in: CONFIGURE += CONFIG_RTAI_MATH_LIBM_DIR=/tmp/newlib/build/libm/libm.a
08:34 PM memfrob: Got it, so yeah, seb basically does what I thought of doing, except instead of doing it in-tree, he builds newlib out-of-tree, which is great for a deb package, but if all you want to do is run make && make install then you'd want RTAI
08:34 PM memfrob: RTAI's autotools to build newlib for you.
08:55 PM andypugh: To start a different question:
08:56 PM andypugh: The docs don’t mention [TRAJ] AXES. http://linuxcnc.org/docs/2.8/html/config/ini-config.html
08:57 PM andypugh: A brief search dodn’t show anything looking for [TRAJ] AXES
08:57 PM andypugh: But if you leave it out: ./test_setup.hal:6: Ini variable '[TRAJ]AXES' not found.
08:58 PM andypugh: OK, now I have asked the question abd read the error message, I see the problem. _HAL_ uses it. Or can.
08:59 PM andypugh: loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
08:59 PM andypugh: That’s wrong, isn’t it?
09:03 PM andypugh: Odd, the regex ought to already me making that swap.
09:04 PM andypugh: 'num_joints=\[TRAJ\]AXES': 'num_joints=[KINS]JOINTS',
09:06 PM andypugh: Hmm, regexr.com indicates that the regex is right, so this is a job for tomorrow.