Back
[06:39:25] <KGB-linuxcnc> 03Norbert Schechner 052.6 60689e3 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/notification.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_3_1 - fixed serious bug PAUSE / RESUME / STOP * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=60689e3
[06:42:23] <KGB-linuxcnc> 03Norbert Schechner 05master 32e7737 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/notification.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_3_1 - fixed PAUSE / RESUME / STOP bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=32e7737
[06:42:24] <KGB-linuxcnc> 03Norbert Schechner 05master 859c53a 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=859c53a
[09:49:20] <jepler> linuxcnc-build_: force build --branch=liblinuxcnc-ui 0000.checkin
[09:49:21] <linuxcnc-build_> build forced [ETA 1h19m53s]
[09:49:22] <linuxcnc-build_> I'll give a shout when the build finishes
[09:49:56] <jepler> no failures after an hour of running in a qemu --enable-kvm -smp 1 with 8 md5sum /dev/zeros running outside qemu
[09:50:07] <jepler> .. qemu typically gets 8-15% CPU (host is 4 threads)
[10:13:59] <linuxcnc-build_> build #240 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/240
[10:32:40] <linuxcnc-build_> build #2582 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2582
[11:49:41] <jepler> and why is it always the halui-jogging test, and not any of the other halui-using tests?
[11:50:33] <archivist> timing/race condition?
[11:53:41] <jepler> this line appears in a successful run as well, shouldn't be relevant: emc/iotask/ioControl.cc 768: can't load tool table.
[11:54:00] <jepler> archivist: I assume it's something along those lines, need to know more specifics before I can fix it though
[12:07:19] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 660e879 06linuxcnc 10src/emc/usr_intf/emclcd.cc 10src/emc/usr_intf/emcrsh.cc 10src/emc/usr_intf/emcsh.cc 10src/emc/usr_intf/schedrmt.cc UIs: It's OK to lui_free(NULL) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=660e879
[12:07:19] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui cba0825 06linuxcnc 10(10 files in 2 dirs) lui: introduce, use get_command_channel_nml * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cba0825
[12:07:19] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 1f174b2 06linuxcnc 10src/liblinuxcnc-ui/connect.cc lui: after failure to connect, print details * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1f174b2
[12:14:13] <jepler> hmmm have I run all my local tests at the wrong ref?
[13:19:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 76a6844 06linuxcnc 10src/emc/usr_intf/shcom.cc fixup! lui: introduce, use get_command_channel_nml * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=76a6844
[14:01:48] <linuxcnc-build_> build #242 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/242 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:11:24] <jepler> so so that loop in lui_connect_to_status_nml should be going for about 10 * 1000 * 100 usec = 1 second
[14:11:31] <jepler> could it just be too little time?
[14:15:07] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui afb6242 06linuxcnc 10src/liblinuxcnc-ui/connect.cc lui: additional debugging information in lui_connect * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=afb6242
[14:15:07] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 75d35cb 06linuxcnc 10src/liblinuxcnc-ui/connect.cc lui: wait substantially longer for a status buffer * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75d35cb
[14:23:31] <linuxcnc-build_> build #2584 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2584 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:24:32] <skunkworks> logger[psha],
[14:24:33] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-10-26.html
[14:26:16] <linuxcnc-build_> build #2574 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2574 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:27:01] <linuxcnc-build_> build #2576 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2576 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:27:22] <linuxcnc-build_> build #1776 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1776 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:27:35] <linuxcnc-build_> build #2575 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2575 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:27:48] <linuxcnc-build_> build #2575 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2575 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:28:55] <linuxcnc-build_> build #2575 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2575 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:30:08] <linuxcnc-build_> build #2574 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2574 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:30:10] <KGB-linuxcnc> 03Chris Morley 05master 5f36422 06linuxcnc 10src/emc/usr_intf/stepconf/build_HAL.py 03src/hal/components/sim_parport.comp replace parport component with sim_parport * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f36422
[14:30:10] <KGB-linuxcnc> 03Chris Morley 05master 68912a8 06linuxcnc 04src/hal/components/parport.comp remove parport component * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=68912a8
[14:30:10] <KGB-linuxcnc> 03Chris Morley 05master b4f5ce0 06linuxcnc 10src/hal/components/sim_axis_hardware.comp sim_axis_hardware -remove home-all selection pins, add docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b4f5ce0
[14:32:31] <linuxcnc-build_> build #2372 of 1901.clang-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2372 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:33:53] <linuxcnc-build_> build #732 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/732 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:34:07] <linuxcnc-build_> build #923 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/923 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:34:19] <linuxcnc-build_> build #732 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/732 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:35:21] <linuxcnc-build_> build #243 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/243 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:35:27] <linuxcnc-build_> build #389 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/389 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:42:11] <linuxcnc-build_> build #762 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/762 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:42:11] <linuxcnc-build_> build #2585 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2585 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:59:19] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui ab3c047 06linuxcnc 10src/liblinuxcnc-ui/connect.cc lui: additional debugging information in lui_connect * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ab3c047
[14:59:19] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui c4fadbb 06linuxcnc 10src/liblinuxcnc-ui/connect.cc lui: wait substantially longer for a status buffer * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c4fadbb
[15:01:28] <jepler> cmorley: thank you!
[15:01:51] <cmorley> your welcome of course :)
[15:19:26] <CaptHindsight> how does one make edits to docs like this one?
http://linuxcnc.org/docs/html/common/python-interface.html
[15:21:09] <jepler> CaptHindsight: the source code is at docs/src/common/python-interface.txt
[15:21:19] <jepler> CaptHindsight: configure with --enable-build-documentation to build it locally
[15:23:00] <CaptHindsight> I'll have to try. I've only edited the wiki so far
[15:23:05] <CaptHindsight> thanks
[15:23:21] <jepler> linuxcnc.org/docs/html/ is built from the current release branch, so 2.6 at the moment
[16:43:37] <jepler> lui_connect_to_status_nml start 1414357678.433515
[16:43:38] <jepler> lui_connect_to_status_nml end 1414357678.837314
[16:43:51] <jepler> so it connected in <.5s
[16:43:53] <jepler> .. in this run
[16:44:01] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/245/steps/runtests/logs/stdio
[16:44:05] <seb_kuzminsky> that's order-of-magnitude of the old 1s timeout
[16:44:45] <jepler> true
[16:45:37] <jepler> lui_connect_to_status_nml start 1414358751.280913
[16:45:37] <jepler> Waiting for component 'trivkins' to become ready........Waited 3 seconds for master. giving up.
[16:45:40] <jepler> cannot gain I/O privileges - forgot 'sudo make setuid'?
[16:45:40] <jepler> hm in a local run I just got this
[16:45:43] <jepler> Note: Using POSIX non-realtime
[16:45:45] <jepler> lui_connect_to_status_nml end 1414358754.486901
[16:45:48] <jepler> much more than 1s
[16:46:12] <jepler> so maybe it is just slow to start
[16:46:32] <jepler> seb_kuzminsky: did you copy the timeout logic from somewhere, or was it new?
[16:47:14] <seb_kuzminsky> i rewrote it using inspiration from some old code, i'll look for it
[16:47:43] <jepler> ('Waited 3 seconds for master' is rtapi_app deciding whether it's a new session or not in the case where a previous rtapi_app died uncleanly)
[16:47:55] <jepler> but we don't see a message like that in the failed logs
[16:48:39] <jepler> lui_connect_to_status_nml start 1414358935.414692
[16:48:42] <jepler> lui_connect_to_status_nml end 1414358937.783704
[16:49:01] <jepler> this one after sudo sysctl vm.drop_caches=3 to make everything have to be read from disk
[16:49:22] <jepler> maybe disk/memory pressure, more than CPU pressure, is what made it failure-prone on a vm?
[16:49:48] <jepler> in the normal test order, halui-jogging is the first linuxcnc test after a number of hal-only tests
[16:50:44] <seb_kuzminsky> that's an interesting observation
[16:52:13] <seb_kuzminsky> jepler: i think i first tried no timeout, then i realized that the "wait for first status" needs to spin to wait for Task
[16:52:28] <seb_kuzminsky> the original timeout was in eg halui.cc:tryNml()
[16:53:05] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 43d3f99 06linuxcnc 10(10 files in 2 dirs) lui: introduce, use get_command_channel_nml * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=43d3f99
[16:53:05] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui e067885 06linuxcnc 10src/liblinuxcnc-ui/connect.cc lui: after failure to connect, print details * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e067885
[16:53:05] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 8a0da21 06linuxcnc 10src/liblinuxcnc-ui/connect.cc lui: wait substantially longer for a status buffer * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a0da21
[16:53:10] <jepler> yup, #define RETRY_TIME 10.0 // seconds to wait for subsystems to come up
[16:53:34] <jepler> I feel better now that I could cause the failure on my own system
[16:54:28] <jepler> too bad the weekend went by while I tried to figure it out
[16:54:40] <jepler> I think there are just a few getters left to work on, I'll try to get back to that evenings this week
[16:54:40] <seb_kuzminsky> that drop_caches trick made it fail on your machine?
[16:54:44] <jepler> seb_kuzminsky: yes
[16:55:14] <jepler> .. with the original 1s timeout
[16:55:46] <seb_kuzminsky> maybe task should daemonize itself after the first status message gets emitted?
[16:56:35] <jepler> we are cloes to being able to do that, I think
[16:56:54] <jepler> 55ec5eb runscript: EMCTASK is a HAL component now
[16:57:03] <jepler> it's now loaded with loadusr -Wn inihal
[16:57:21] <jepler> by moving the hal_ready call to the right place, we should be able to ensure that any connecting UI will always have a valid status buffer ready
[16:57:32] <jepler> an interesting thought
[16:57:40] <jepler> bbl
[17:02:48] <seb_kuzminsky> the first ui would get that first status message and mark it as read, but the later UIs might still need to poll for the next status message
[17:06:36] <Roguish> hey gentlemen, I am working on my bldc setup, one motor keeps throwing a bldc.xx.hall-error problem is there does not seem to be a way to reset the error without shutting down the 7I39 board.
[17:07:10] <seb_kuzminsky> maybe status messages should have a serial number too, instead of the uis racing to set the "has been read" bit
[17:07:39] <Roguish> not even shutting down lcnc and restarting.
[17:08:28] <seb_kuzminsky> Roguish: try asking andy pugh on the emc-developers list
[17:08:44] <Roguish> the mail list?
[17:09:03] <seb_kuzminsky> yeah
[17:09:07] <Roguish> doesn't he ever hang out here?
[17:09:22] <Roguish> i'm not sure what his nickname is.
[17:09:24] <seb_kuzminsky> very sporadically, lately
[17:09:30] <seb_kuzminsky> it's "andypugh"
[17:09:39] <Roguish> clever.
[17:09:59] <Roguish> ok, i'll write some up and sent to the list.
[17:10:24] <Roguish> hey i see you guys are working on the 'packaging'
[17:10:41] <pcw_home> If the halls are just used for initial alignment you might try debouncing them
[17:10:54] <seb_kuzminsky> yeah, trying to figure out what to do with the new "uspace" packages
[17:11:04] <pcw_home> (since that sounds like a noise issue)
[17:11:06] <Roguish> pwc_home: no they are used for comuation.
[17:11:48] <Roguish> seb: thanks for moving away from ubuntu. getting way too bloaed.
[17:11:57] <pcw_home> if you use QH mode you can do sinusoidal commutation
[17:12:10] <pcw_home> (which is better)
[17:12:29] <pcw_home> less "ticky"
[17:12:43] <seb_kuzminsky> Roguish: i too am glad we're focusing on debian now, but i don't think it's quite right to say we're moving away from ubuntu
[17:12:58] <Roguish> pwc_home: using h mode. just happens on 1 of 4 channels. channel 2 of 2 boards.
[17:13:06] <seb_kuzminsky> we ship an rtai kernel for Ubuntu Precise 12.04, and i hope to do the same for future releases
[17:13:36] <seb_kuzminsky> i bet there are lots of people who percieve ubuntu to be more user-friendly that debian
[17:13:49] <Roguish> seb: for the iso's, i just don't see any reason to include games, and office and such.
[17:13:56] <seb_kuzminsky> haha yeah
[17:14:47] <Roguish> for machine control i like is really, really simple. i don't want an operator playing solitair.... or cruizing porn.
[17:16:54] <Roguish> pcw_home: i have tried switching cabling, motors, cabling and motors. still throws the error.
[17:17:10] <Roguish> same channel every time.
[17:18:01] <pcw_home> probably coupling from PWM to hall signals, are the separated and shielded?
[17:18:55] <Roguish> pcw_home: is it ok to hot plug the 50pin connector on the 7i39? i always shut the motor power off.
[17:19:17] <pcw_home> Its not a great idea
[17:19:44] <pcw_home> unless you remove 5V cable power first
[17:19:53] <pcw_home> (5I20 jumper)
[17:20:18] <Roguish> do you mean the power pwm to the motor? the motor has a single dsub 15
[17:21:05] <Roguish> if I un-jumper the 5i20 that will kill the 5v ?
[17:21:18] <pcw_home> You mighy try some .01 uf capacitors from HALL input to ground at the 7I39
[17:22:04] <pcw_home> really sounds like noise in the HALL lines
[17:25:05] <Roguish> well, the hall inputs go thru the 10 pin header on ribbon cable 6" long, spliced to individual wires to the dsub, another 6"
[17:25:44] <Roguish> splices are soldered with heat shrink
[17:26:37] <Roguish> maybe Frys has some caps
[17:36:30] <pcw_home> also a hal error should just be a transient error that probably a BLDC bug/misfeature
[17:38:50] <Roguish> I will try to look into the code, but my programming skill is weak at best. I would think the 'error' should be cleared on starting the 'bldc' comp. yes?
[17:39:16] <Roguish> and maybe even including something to 'reset' an 'error'?
[17:39:44] <seb_kuzminsky> you should talk with andy about it, i bet he knows how an error reset mechanism can fit into the bldc driver code
[17:42:39] <Roguish> i will try to start a discussion with andy
[19:06:44] <andypugh> I am trying to use feed-per rev in a hobbing config on my mill. But I am seeign some really strange results.
[19:07:49] <andypugh> To try to get to the bottom of it I put the gearbox in neutral, with a feed-per-rev of 0.1mm.
[19:08:43] <andypugh> The table moved slowly, probably at about .1mm per rev. (though the spindle wasn’t turning, so no change in motion.spindle-revs _or_ motion.spindle-speed-in )
[19:09:55] <andypugh> The wierd thing was when I moved the actual spindle by hand, the table moves very rapidly (and not at 60x 0.1mm/rev, in case you were wondering).
[19:10:41] <andypugh> I suppose the main question is which input controls feed-per-rev, speed or position?
[19:16:14] <andypugh> It may be important that the machine appears to be running an old verson of JA4 with a jog-while-paused patch.
[19:18:20] <andypugh> motion.spindle-revs increases by 1.00 per rev, just in case you were wondering.
[19:19:37] <jepler> andypugh: docs say this:
[19:19:38] <jepler> G95 - is Units per Revolution Mode In units per revolution mode, an F word is interpreted to mean the controlled point should move a certain number of inches per revolution of the spindle, depending on what length units are being used and which axis or axes are moving. G95 is not suitable for threading, for threading use G33 or G76. G95 requires that motion.spindle-speed-in to be connected.
[19:21:03] <andypugh> Hmm, OK.
[19:21:15] <jepler> (of course despite the inch-specific wording it should obey G20/G21)
[19:22:17] <andypugh> I think my motion.spindle-speed in might be in rpm
[19:22:55] <andypugh> But the magnitude of the eror seems larger than that, and the axes seem to move even with a stationary spindle (motor turning but gearbox in neutral).
[19:23:08] <andypugh> I will have to look in more detail tomorrow. (late here)
[19:23:37] <andypugh> I have not noticed this with the lathe, so it might well be a JA4 thing,
[19:24:02] <jepler> it sure is possible ja had to touch this code and introduced a bug
[19:24:23] <andypugh> (I don’t really fancy reverting my configs, I didn’t make a script to go that way)
[19:24:42] <andypugh> But I ought to try something a bit more mainstream.
[19:25:09] <jepler> A smart guy wrote the conversion script
[19:25:19] <andypugh> (I think I compile this particular version to test a jog-while-paused patch)
[19:25:20] <jepler> maybe you should ask if he'll write the reverse conversion script:-/
[19:25:38] <jepler> bbl .. remember to sleep
[19:26:10] <andypugh> I had rather assumed that the script would only need to go one way (and I imagined it was going to be needed imminently, too)
[20:33:03] <cradek> andypugh: lathes seemed really broken when I tested jaN recently. any missing/nonconsecutive axis (also tried XYZB) seemed to futz it all up
[20:33:13] <cradek> that was the main kind of problem I saw
[21:36:15] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 0e4d777 06linuxcnc 10src/emc/usr_intf/xemc.cc fixup! lui: introduce, use get_command_channel_nml * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e4d777
[21:36:15] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui f03eca0 06linuxcnc 10src/liblinuxcnc-ui/linuxcnc-ui-private.h 10src/liblinuxcnc-ui/luigetter.py 10src/liblinuxcnc-ui/status-nml-update.cc fixup! lui: framework to autogenerate getters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f03eca0