Back
[07:06:35] <lair82> Good Morning Gentlemen, I seem to be hitting a wall when updating my latest machine. Last week I did the same course of events on another machine, and had no issues, now I keep getting faults about " File "/home/cinci12mo/linuxcnc/python/toplevel.py", line 19, in <module> import remap ImportError: No module named remap Python plugin configure() failed, status = -11"
[07:08:10] <lair82> I have done a complete re-install twice of the software, and keep getting this. I have went thru and double checked the foldr paths and names and everything is correct.
[07:15:17] <jepler> when the environment variable PYTHONVERBOSE is set to 2, Python will print each location it searches for a module to import (as well as reporting a lot of other things). I recommend running: PYTHONVERBOSE=2 linuxcnc path/to/your/config.ini, then inspecting the output for where it tries to import remap. The location where you've placed remap.py must not be the one that linuxcnc expects.
[07:16:01] <jepler> the output may be lengthy, so if you can't scroll back that far in your terminal, google how to use output redirection to save the output to a file
[07:17:08] <jepler> and note that relative paths are relative to the configuration directory unless you've done something really unusual.
[07:17:44] <jepler> so for instance I see this when running the sample config axis/remap/getting-stated/demo.ini in master branch from a RIP install
http://paste.debian.net/119128/
[07:18:13] <lair82> i set that in the INI?
[07:18:35] <jepler> no, PYTHONVERBOSE is an environment setting; I showed you a shell command to set it temporarily just for one invocation of linuxcnc
[07:18:45] <jepler> PYTHONVERBOSE=2 linuxcnc
[07:18:55] <lair82> Oh, got it
[07:23:30] <jepler> afk
[09:53:02] <lair82> I have noticed a few things, first on one of my other machines, I did the same thing, copied it to gedit, and looked for where it accepted the file and found the following,
http://pastebin.com/raw.php?i=zk0xPDKw
[09:55:03] <lair82> Now looking at the current machine, which is faulting, here is what I get,
http://pastebin.com/raw.php?i=LW8CzvRS
[09:58:05] <lair82> I am not sure why it starts going to #trying /home/cinci12mo/linuxcnc-dev/lib/python/traceback.so , when on the other machine it goes to # trying /home/cinci15cc/linuxcnc/python/remap.so , finds the file, then life is good.
[10:00:05] <pcw_home> probably because it loads the traceback when it cant find remap.py
[10:01:19] <pcw_home> (it needs the traceback module to trace/print the error)
[10:01:45] <lair82> It doesn't make sense though, all the files are in the python folder
[10:02:02] <pcw_home> what does
[10:02:03] <pcw_home> locate remap.py
[10:02:05] <pcw_home> show
[10:03:00] <lair82> cinci12mo@cinci12mo:~/linuxcnc/python$ ls remap.py stdglue.py toplevel.py
[10:05:07] <lair82> And here is my INI entry, TOPLEVEL= /home/cinci12mo/linuxcnc/python/toplevel.py , APPEND= /home/cinci12mo/linuxcnc/python
[10:05:15] <pcw_home> You must have an ini setting somewhere (in the working config) that told linuxcnc to look for the remap file there
[10:07:09] <pcw_home> you can see that the non working config never looks there
[10:08:30] <pcw_home> maybe a RIP issue:
[10:08:31] <pcw_home> trying /home/cinci12mo/linuxcnc-dev/lib/python/remap.py
[10:10:04] <lair82> That file is not in that directory.
[10:10:14] <pcw_home> so you could poke it there 'till someone smarter figures out the real issue
[10:11:51] <lair82> I did do that, and it worked, I did not know if that was a good idea though.
[10:12:32] <pcw_home> is this a RIP build?
[10:13:42] <lair82> yep
[10:14:32] <pcw_home> probably install would fix it
[10:14:50] <lair82> Install what?
[10:15:10] <pcw_home> instead of RIP
[10:15:21] <jepler> I'm going to interrupt with some "no"
[10:15:58] <jepler> two things -- first, if something works with an installed version and not with a RIP version, then we want to know what's going on and get it fixed
[10:16:44] <jepler> second, we recommend to use RIP *or* a package version, but we never recommend for a user to "make install" from their source tree; it seriously trashes the system.
[10:16:57] <jepler> http://mid.gmane.org/20140817171953.GC86118%40unpythonic.net
[10:17:24] <jepler> (you can build your own package and install it via dpkg, that's great and supported too -- but "make install" is never something to invoke directly)
[10:18:17] <lair82> I do know that the sim configs start up no problem
[10:18:27] <lair82> if thats of any help
[10:19:29] <lair82> In regards to the remap, I set this up line for line from the integrators manual
[10:20:06] <lair82> Thats why I am lost, it has never failed like this before
[10:20:36] <jepler> do you have [PYTHON]PATH_PREPEND ?
[10:24:01] <lair82> no
[10:24:19] <lair82> never have
[10:31:45] <lair82> Think I got it, in the past it looks like APPEND was all that was needed, now it needs to be PATH_APPEND,after I changed it, it starts fine.
[10:33:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 b5442ee 06linuxcnc 10src/Makefile build system: remove useless assert * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b5442ee
[10:36:49] <lair82> Is PATH_PREPEND required?
[10:42:20] <skunkworks> jepler, can you take a picture of your setup? odroid+board+mesa?
[11:02:54] <jepler> skunkworks:
http://emergent.unpythonic.net/files/sandbox/img_4910.jpg with bonus artsy soft focus
[11:03:26] <skunkworks> jepler, awesome!
[11:03:45] <skunkworks> so - you are only using 2 or so pins of the ribbon cable?
[11:04:04] <jepler> 4 pins + all the grounds (about 8)
[11:05:31] <jepler> also we tested last night that communication is not disrupted with a vacuum cleaner 2' away :-P
[11:07:31] <jepler> I see APPEND is mentioned in the docs. I'll fix that.
[11:09:16] <jepler> lair82: the Python import statement looks in an ordered list of paths. In remap, [PYTHON]PATH_PREPEND puts items at the start, and [PYTHON]PATH_APPEND puts them at the end. The distinction is important if the same module could be found in multiple locations..
[11:10:00] <lair82> Ok, Thought I was losing it for the last day and a half, how long ago did that change?
[11:10:10] <jepler> no idea
[11:10:29] <lair82> Ok, no big deal,
[11:10:47] <lair82> Thanks for the help though,
[11:11:13] <jepler> OK
[11:11:29] <jepler> I don't actually see any evidence in git history that [PYTHON]APPEND ever did anything
[11:12:13] <KGB-linuxcnc> 03Jeff Epler 052.6 34a59fd 06linuxcnc 10docs/src/remap/structure.txt remap docs: The inifile var is PYTHON_APPEND * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=34a59fd
[11:14:17] <lair82> The config i'm working on worked last week before I did a fresh install, I installed a new MB with a new A4-4020 processor, and the software wouldnot start up, so I re-installed the software, and this is where I ended up.
[14:21:53] <KGB-linuxcnc> 03Jeff Epler 05master e8de7f5 06linuxcnc 10src/Makefile Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e8de7f5
[14:32:30] <jepler> wow, I just discovered a mistake in the Makefile which trims 18 CPU seconds off a build from clean
[14:32:58] <jepler> on my beefy machine it turns a (fully ccached) build from 10 wall-clock seconds to 4
[14:34:44] <PCW> Ha! the Smootherator works!
[14:35:31] <jepler> PCW: cool!
[14:36:14] <jepler> is it a "you can hear the difference" or a "you can scope the difference"?
[14:36:32] <PCW> now the stepgen is tunable to <100 u error at 30 IPS
[14:37:25] <PCW> no raspy "following error" which is really just sampling time error
[14:38:06] <jepler> It occurs to me that hm2's write function could in principle wait for a certain time within the period
[14:38:22] <jepler> .. reducing the variation in write time by some amount, at the expense of CPU utilization
[14:38:41] <jepler> easier to do if I get around to introducing a get nominal thread start time API
[14:39:50] <PCW> yeah but on feedback systems the write time is less important then the read (sample) time
[14:41:12] <PCW> i had to set the sample time to 50 usec before nominal linuxcnc read time to account for worst case baseline wander
[14:42:38] <PCW> (and raw write the stepgen DPLL sample enable register/timer channel select register)
[14:44:27] <jepler> bbl
[14:44:45] <jepler> I'd better get mesaflash spi working, then I can try one of these firmwares
[14:45:00] <jepler> see what it takes to get the DPLL activation working in the hal driver
[14:45:27] <PCW> you can flash via EPP
[14:50:14] <PCW> DPLL already works (at least on hm2_eth)
[14:50:15] <PCW> only added feature is global 4 bit register 15 downto 12) =
[14:50:17] <PCW> DPLL_SAMPLE_ENABLE, 3 select bits to specify which DPLL timer channels is selected
[14:51:35] <skunkworks> smootherator?
[14:52:45] <PCW> Have you noticed the latency related hash on the stepgen position feedback with hm2_eth?
[14:53:41] <PCW> (and magnitude proportional to velocity)
[14:57:08] <PCW> Just added the option of sampling the stepgens feedback with the DPLL instead of
[14:57:10] <PCW> when linuxcnc does the read. This removes almost all of the sampling jitter
[14:58:56] <PCW> you do need to add a bit more FF2 to the PID since the time between sampling the position and applying the correction is longer
[15:08:21] <skunkworks> cool!
[15:08:35] <skunkworks> The things you do for those darn stepper people!
[15:08:38] <skunkworks> ;)
[15:09:02] <Tom_itx> oh hush
[15:14:20] <PCW> eventually I will add this option to the encoder as well :-)
[15:17:13] <PCW> on Ethernet I was able to reduce the ferror settings from 2 and 5 mills to 0.5 and 1.0 mills (for 30 IPS max)
[15:18:13] <PCW> (and can probably go lower)
[15:53:46] <jepler> PCW: yes, I actually used the stepgen fb position derivative as a check on latency
[15:54:32] <jepler> stepgen fb as a timestamp I trusted
[16:01:25] <PCW> should be a big improvement on Preemt_RT systems (bogus stepgen velocity corrections reduced substantially)
[16:02:44] <PCW> even say 1/2 ms delay could be tolerated on a 1 KHz loop
[16:03:14] <PCW> just makes things a lot less picky
[16:07:00] <PCW> theres' a (global) bit you can set/clear to enable/disable the DPLL sampling so you dont lose the ability to use the stepgen for latency checking
[16:33:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 130b19d 06linuxcnc 10docs/src/Submakefile build: only do docclean when doc building enabled * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=130b19d
[16:33:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 099ebfa 06linuxcnc 10src/Makefile build: give EXTRAFLAGS an empty definition * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=099ebfa
[16:33:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 3e2dc97 06linuxcnc 10src/Makefile build: Unconditionally enable -fno-strict-aliasing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3e2dc97
[16:33:28] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master eed53cb 06linuxcnc 10src/Makefile build: compute EXTRA_CFLAGS just once * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eed53cb
[16:33:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 0bb3018 06linuxcnc 10src/Makefile build: Warn about use of undefined variables * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0bb3018
[16:33:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 6600418 06linuxcnc 10src/Makefile build: correctly check for 'make -s' silent build * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6600418
[16:33:40] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master bd6bb34 06linuxcnc 10src/Makefile build: Honor silent mode when it comes to informing about dependency info * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bd6bb34
[16:33:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 87f9c52 06linuxcnc 10src/Makefile build: don't bother reading legacy (2.5)-style dependencies * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=87f9c52
[16:33:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 47e9e1f 06linuxcnc 10src/Makefile build: provide empty EXTRA_DEBUG by default, but allow overriding from make commandline * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=47e9e1f
[16:34:03] <jepler> another 70 kiloseconds of good spi behavior
[16:34:06] <jepler> at 44MHz no less
[16:36:55] <PCW> with direct 1.8V SPI I/O (and a direct connection) >50 MHz should be possible (assuming you can generate the clocks)
[16:37:57] <PCW> on the other hand unless you have a _lot_ of I/O 44 Mbits/sec is plenty for motion control
[16:38:17] <jepler> it sems that 44MHz is the top clock I can select. Every clock I have seen seems to be 220MHz/k for some k
[16:38:34] <jepler> and also at this point the overhead is longer than the transmission time by a fair bit
[16:38:51] <PCW> some division of the CPU clock?
[16:38:54] <jepler> I think I'm reading 27 or 28 words, which shold be about 20us
[16:39:06] <jepler> but the typical write time is still around 80us
[16:39:24] <jepler> so going up to 50/60/80MHz is not going to make a difference
[16:39:28] <PCW> yeah that the disadvantage of using the driver
[16:40:42] <jepler> PCW: I haven't studied the clock distribution system in this thing much but dmesg says the "M" clock is 880MHz. Not particularly related to the CPU frequency of 1704000MHz
[16:41:43] <PCW> Yeah normally there are pretty fancy clock trees in these cell-phone/tablet SOCs for power management
[16:43:55] <PCW> The SPI slave could do full duplex with some futzing, not sure if its worth the trouble though
[16:44:40] <PCW> (since it does not fit in the read/process/write model very well)
[16:44:58] <jepler> yeah
[16:45:39] <jepler> I wonder if we can shift feedback by another servo period, so do the write and read all at once
[16:47:59] <PCW> a bit painful unless you lose a lot of overhead
[16:48:14] <jepler> maybe 50us?
[16:48:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deps e3ae8e7 06linuxcnc 10src/Makefile build system: remove the unused DEP variable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e3ae8e7
[16:48:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deps 5160825 06linuxcnc 10src/Makefile build system: explicitly generate dependency files when needed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5160825
[16:49:13] <seb_kuzminsky> i'd appreciate more eyes on the seb/master/deps branch. it fixes a build problem when switching from 2.6 to master for me
[16:51:04] <jepler> seb_kuzminsky: I'd rather find a different way to solve the problem; I believe your change probably makes builds measurably slower.
[16:51:45] <jepler> seb_kuzminsky: I believe the real problem is that we have a lot of unqualified rules like this:
[16:51:48] <jepler> emc/motion/Submakefile:../include/%.h: ./emc/motion/%.h
[16:51:50] <jepler> emc/nml_intf/Submakefile:../include/%.h: ./emc/nml_intf/%.h
[16:51:50] <jepler> emc/nml_intf/Submakefile:../include/%.hh: ./emc/nml_intf/%.hh
[16:51:53] <jepler> emc/motion/Submakefile:../include/%.hh: ./emc/motion/%.hh
[16:52:10] <jepler> (before the first : is the filename where the line is, that's a grep)
[16:52:36] <jepler> those should all be corrected so that they say $(INCLUDES_THAT_CAN_BE_GENERATED_FROM_EMC_MOTION) : ../include/%.h : emc/motion/%.h
[16:53:16] <jepler> what happens is that the .d file has a dummy rule for each .h file; this induces make to choose the wrong location to copy tc.c from
[16:53:30] <jepler> .. because there's some rule in a .d file which says emc/kinematics/tc.h can be re-made by executing no command
[16:53:52] <jepler> with your change the .d is regenerated before it considers this, and disaster is averted
[17:17:24] <jepler> +$(patsubst ./emc/kinematics/%,../include/%,$(wildcard ./emc/kinematics/*.h)): ../include/%.h: ./emc/kinematics/%.h
[17:17:36] <jepler> if you think that's a fine line, try writing a sed script to make it
[17:17:44] <jepler> s@^\.\./include/%\.hh\?: \([^%]*\)%\.\(hh\?\)@$(patsubst \1%,../include/%,$(wildcard \1*.\2)): \0@'
[17:17:58] <jepler> ... patience ...
[17:20:53] <jepler> nah my change didn't actually fix the error
[17:21:38] <jepler> nah I didn't actually test with my change in effect
[17:31:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 19d770c 06linuxcnc 10src/Makefile build: provide empty EXTRA_DEBUG by default, but allow overriding from make commandline * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=19d770c
[17:31:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 57b40d5 06linuxcnc 10(18 files in 18 dirs) build: fix 'cannot stat tc.h' build error when switching branches * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=57b40d5
[17:31:15] <jepler> seb_kuzminsky: I believe my proposed-master branch fixes the problem and prefer my solution (how typical is that)
[17:31:37] <skunkworks_> control freak!!! ;)
[17:32:37] <skunkworks_> into the overnight
[17:32:46] <skunkworks_> heh - wrong window
[17:46:32] <jepler> if not it was super enigmatic
[17:47:26] <jepler> if not, it was super enigmatic
[19:47:55] <jepler> anyone know if there's a real reason that hm2-stepper/7i90.ini uses keystick for its ui?
[19:56:24] <jepler> well I guess I should have tried earlier to actually run linuxcnc
[19:56:33] <jepler> with hm2_spi
[19:56:43] <jepler> turns out that stepgen won't go backwards
[19:57:30] <jepler> velocity-fb duly goes to e.g., -1 but dbg_step_rate sticks at 0 and never goes negative
[20:20:04] <jepler> hmmm there's an interesting difference between this code's behavior on x86 and arm
[20:21:38] <jepler> http://paste.debian.net/119254/
[20:22:10] <jepler> converting a negative double to an integer gives 0 on arm, in contrast to the result on x86 where you get an "as though signed" conversion
[20:22:38] <cradek_> eww
[20:26:35] <pcw_home> oops
[20:27:20] <jepler> I can find neither a "DWIM" option, nor a "warn me please" option
[20:36:10] <jepler> now it works
[20:36:35] <jepler> opengl is shipping bitmaps over the network, so axis is slow (and it's slow locally, because opengl's unaccelerated)
[20:36:46] <jepler> there's probably at least one more bad cast, in pwmgen...
[20:40:19] <jepler> no, pwmgen seems to give both positive and negative outputs, at least 'scoping' the gpio-in
[20:45:02] <jepler> yay, HM2-Stepper is running properly now
[20:45:22] <jepler> boo for lurking bugs. at least the behavior in this case was to ferror right away
[20:59:49] <pcw_home> seems like a rather serious compiler bug
[20:59:54] <cradek_> unsigned int a = -4; surely invokes undefined behavior
[20:59:54] <cradek> where did I get those underscores
[20:59:54] <pcw_home> Oh didn't notice is was only broken on assignment to unsigned
[21:01:12] <seb_kuzminsky> jepler: without the seb/master/deps fix, make still runs with out-of-date .d files, which bothers me
[21:04:47] <seb_kuzminsky> the .d files are from the previous invocation of make, not the current one. it's like the pid error fix that went into 2.6, but for the build system
[21:05:12] <jepler> seb_kuzminsky: make always runs with out-of-date .d files
[21:05:28] <jepler> hm now my console is spewing "spidev: I/O error" and linuxcnc stopped with a following error
[21:05:38] <jepler> and my tmaxes are on the order of 60ms
[21:06:11] <seb_kuzminsky> in seb/master/deps there are rules for regenerating the .d files which src/Makefile includes, and make re-execs itself after regenerating the .d files (if needed)
[21:06:32] <seb_kuzminsky> unless i'm misreading
https://www.gnu.org/software/make/manual/html_node/Include.html
[21:06:44] <jepler> seb_kuzminsky: think for a minute what it means for a .d file to be "out of date"
[21:07:13] <jepler> seb_kuzminsky: i.e., how do you know if a .d needs to be re-made?
[21:08:07] <jepler> seb_kuzminsky: if it doesn't become clear I'm happy to elucidate
[21:14:15] <seb_kuzminsky> jepler: i assume i'm being dense, but i dont see how
[21:14:19] <seb_kuzminsky> objects/%.d: %.c
[21:14:30] <seb_kuzminsky> so the .d is out of date if it's older than its .c
[21:14:43] <seb_kuzminsky> which seems right to me
[21:14:46] <seb_kuzminsky> what am i missing?
[21:15:01] <cradek> deps can become wrong when files included by that .c change
[21:15:39] <jepler> suppose x.c includes y.h. a change to y.h could newly include z.h.
[21:15:43] <cradek> so that's at least an inadequate test
[21:15:49] <jepler> that's why you use a .d file to determine when a .o file needs to be regenerated
[21:16:11] <jepler> but that same test for when a .o file needs to be regenerated is equally adequate to tell you when the .d file needs to be regenerated
[21:16:14] <seb_kuzminsky> hmm, right
[21:16:58] <jepler> (there are blind spots: when a Make variable like CFLAGS changes; or when an include file like y.h is created in a location that is earlier in the search path than the one that was found on the previous run)
[21:17:25] <seb_kuzminsky> yeah
[21:18:25] <jepler> so that's why the approach of generating the .o and the .d files in one invocation of gcc is adequate
[21:18:41] <jepler> and it's a timesaver, because you invoke the compiler half as often, and read dependency information half as many times per make invocation
[21:18:54] <cradek> by adequate do you just mean you can't do any better?
[21:19:09] <jepler> cradek: because of those blind spots, yes
[21:19:27] <cradek> (I always clean when I switch branches)
[21:19:48] <seb_kuzminsky> i never do, i expect the build system to do the right thing
[21:20:02] <jepler> anyway, the problem seb encountered is because of the dummy rules requested by gcc ... -MP
[21:20:13] <jepler> if file foo.h is included, a dummy rule 'foo.h:' is written into the .d file
[21:20:23] <seb_kuzminsky> there's a -Msomething flag to not generate those empty dummy rules
[21:21:03] <seb_kuzminsky> oh right, jepler just said it's -MP
[21:21:07] <jepler> this combined with those header-copying rules caused make to think 'oh, I know how to make emc/kinematics/tc.h, there's a rule right here for that'
[21:21:35] <jepler> because the header-copying rules were insufficiently specific -- they all have the % wildcard
[21:21:51] <seb_kuzminsky> yeah that seems wrong
[21:21:58] * seb_kuzminsky trying to fix bugs: http://stream1.gifsoup.com/view/309016/how-not-to-catch-a-spider-o.gif
[21:22:05] <jepler> that's why I propose to make them all specific by using $(wildcard) to have each make invocation apply that rule only to existing header files
[21:23:02] <jepler> it also makes the specific sequence that seb documented in his change message (thanks!) work properly
[21:23:41] <seb_kuzminsky> i confirm that jepler/master-proposed fixes the problem i ran in to
[21:29:35] <seb_kuzminsky> i like how the static pattern rules in 57b40d55 get rid of the over-inclusive rules they replace
[21:30:18] <jepler> someday we should actually think about which headers are public headers of linuxcnc instead of whatever set we've been shipping for all these years
[21:30:45] <jepler> I think one of the runtests is effectively testing "can you build a realtime component using those headers"
[21:31:06] <seb_kuzminsky> i remember when you(?) wrote that test
[21:31:08] <jepler> but "can you build a NML client" and "can you build a userspace component" tests would also be keen to have
[21:31:36] <seb_kuzminsky> so i agree to drop seb/master/deps, but what about seb/master/deps^? e3ae8e72
[21:31:44] <seb_kuzminsky> i dont think i botched that one
[21:32:07] <jepler> I agree it looks unused
[21:32:22] <jepler> I think it's a correct change
[21:32:34] <jepler> particularly if, when merged with my branch, you can confirm you don't get any new make undefined variable warnings
[21:32:50] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master e3ae8e7 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e3ae8e7
[21:32:54] <KGB-linuxcnc> 05seb/master/deps 5160825 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5160825
[21:33:02] <seb_kuzminsky> at least i accomplished something today :-/
[21:33:16] <seb_kuzminsky> thanks for the proper fix (and the education)
[21:33:18] <seb_kuzminsky> good night folks
[21:33:24] <jepler> you got me to get off my *** and fix a problem I knew about too :-/
[21:33:25] <jepler> see you
[21:39:18] <jepler> $ clang -fsanitize=undefined dua.c; ./a.out
[21:39:18] <jepler> /home/jepler/a.out:0x40ea9d: runtime error: value -1000 is outside the range of representable values of type 'unsigned int'
[21:39:26] <jepler> I can have clang tell me about this at runtime; that's more than nothing.
[21:41:44] <jepler> that's assuming there aren't undefined behaviors by the ton of course
[21:41:48] <jepler> something for another day
