Back
[00:44:21] <memleak> 3.4.51-RTAI works with linuxcnc master branch :D
[00:59:38] <memleak> https://github.com/ShabbyX/RTAI I just made the tree a bit more LinuxCNC friendly out of the box in case anyone is interested (also pushed 3.4.51 support in)
[01:22:59] <mhaberler> in case anybody sees psha around: let him know mail to shramov@mexmat.net is currently broken
[03:00:41] <KGB-linuxcnc> 03seb 05linuxcncrsh-debugging-master 4e95937 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * dont bail on write errors in parseCommand
[03:00:53] <seb_kuzminsky> i think that fixes it for good ^^^
[11:27:22] <KGB-linuxcnc> 03TODO: deletor 05linuxcncrsh-debugging c85d558 06linuxcnc 04. * branch deleted
[11:30:44] <KGB-linuxcnc> 03seb 05master 29717f8 06linuxcnc 10bin/.gitignore * don't ignore a file we're tracking
[11:31:22] <seb_kuzminsky> oh, err, that will probably fail in the linuxcncrsh way, i should push the fix before pushing more stuff like that
[11:36:07] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-2 f61eb97 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * use the non-deprecated way to specify signal handlers
[11:36:07] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-2 409c73c 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * un-race-ify the linuxcncrsh client connection logic
[11:36:11] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-2 255b7e6 06linuxcnc 10tests/ 10(5 files in 5 dirs) * now that connecting to linuxcncrsh is not racy, we dont need sleep
[11:36:18] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-2 489a2c9 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * dont bail on write errors in parseCommand
[12:18:05] <linuxcnc-build> build #1180 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1180 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:18:36] <linuxcnc-build> build #1177 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1177 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:19:14] <linuxcnc-build> build #1180 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1180 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:19:48] <seb_kuzminsky> those failures are from the .gitignore i foolishly pushed
[12:20:03] <seb_kuzminsky> there should be no more, and the next build (of linuxcncrsh-debug-2) should pass
[12:22:38] <linuxcnc-build> build #1175 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1175 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:32:48] <seb_kuzminsky> that's the checkin builder, which just noticed that some of the builds it had triggered have failed (so it's re-reporting the three failures above)
[12:33:42] <mhaberler> stop excusing, now that you've found it we'll suffer through the fallout patiently ;)
[12:33:52] <seb_kuzminsky> i'm not excusing, i'm explainint
[12:34:18] <mhaberler> was that signal thing 'it'?
[12:39:37] <seb_kuzminsky> no, that was me mis-reading strace :-(
[12:39:53] <seb_kuzminsky> turns out, blocked signals still show up in strace, they're just not delivered to the application
[12:39:56] <mhaberler> ui.. tough one
[12:40:12] <seb_kuzminsky> so all that hoopla about "i found a bug in the lucid kernel and/or libc" turned out (as usual) to be operator error ;-)
[12:40:31] <mhaberler> if you script with python. does it work ok?
[12:40:46] <seb_kuzminsky> the bug was improper handling of write(2) returning EPIPE in some (but not all) of the various linuxcncrsh write paths
[12:41:04] <mhaberler> so you found the reason?
[12:41:09] <seb_kuzminsky> afaik the python ui module has no issues
[12:41:19] <seb_kuzminsky> and after i polish up the fix, linuxcncrsh will not have any known issues ;-)
[12:41:33] <mhaberler> RFC: let's bury linuxcncrsh
[12:41:35] <seb_kuzminsky> yeah i found the root cause and i fixed it
[12:41:45] <mhaberler> great, that was a long hunt
[12:41:55] <seb_kuzminsky> it's sure an annoying piece of software to debug/maintain
[12:42:08] <seb_kuzminsky> but it provides valuable functionality that i dont want to discard lightly
[12:42:37] <seb_kuzminsky> if that same functionality could be provided by some better interface, or by a better-written ui program, i would be happy
[12:42:42] <mhaberler> well maybe adding the missing bits to existing or new python module is more promising
[12:43:03] <mhaberler> what is it that you can do with linuxcncrsh and not via python?
[12:43:04] <seb_kuzminsky> writing a thin network interface to the python ui module might be a good way to do it
[12:43:59] <seb_kuzminsky> i like how flexible and quick-to-use linuxcncrsh is - just netcat a bunch of commands and linuxcnc does stuff for you
[12:44:02] <seb_kuzminsky> that's pretty awesome
[12:44:05] <mhaberler> suggestion: postpone that to the end of the year, this should be much easier with the new middleware stack
[12:44:18] <seb_kuzminsky> sounds reasonable and promising!
[12:44:50] <mhaberler> right, but interactive command parser packages for python - there are quite a few out there and thats the only missing piece
[12:44:59] <mhaberler> let me see, I used one recently..
[12:45:03] <seb_kuzminsky> i've got my plate full with other linuxcnc stuff - this bug hunt was a distraction from the joints/axes work i'd rather be doing
[12:46:18] <seb_kuzminsky> i'll try to clean this fix up and push it to 2.5 & master tonight, then back to my regularly scheduled programming ;-)
[12:46:29] <mhaberler> cmd2 was the name:
http://pythonhosted.org/cmd2/ , that's quite nice
[12:48:33] <seb_kuzminsky> i love python
[12:48:37] <mhaberler> so you go for merging ja3? great.. I tried to prod micges several times, but he's very busy and now father ontop
[12:53:26] <seb_kuzminsky> i'm not sure yet
[12:53:36] <seb_kuzminsky> i'd like to, but i need to review it more closely
[12:54:12] <seb_kuzminsky> i'm rebasing the branch and cleaning it up so it's easier to review, for me and you and everyone else who wants to look at it
[12:54:23] <seb_kuzminsky> i'm almost done, should have something ready next week some time
[12:55:06] <mhaberler> if I remember correctly the accel and vel limits for non-trivial kins were missing
[12:56:00] <mhaberler> I found some code relating to that in the cisst project, but I'm not deep enough into that to make a sensible contribution
[12:56:47] <mhaberler> it was here I think:
https://trac.lcsr.jhu.edu/cisst/wiki/cisstRobotTutorial
[12:56:56] <mhaberler> (passing the buck ;)
[13:00:45] <seb_kuzminsky> ok, noted, thanks
[13:03:43] <mhaberler> not sure I understand the problem correctly, but I think the 'Joint Space Inverse Dynamics' is the starting point
[14:34:48] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-3 7c18ad3 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: use the non-deprecated way to specify signal handlers
[14:34:48] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-3 2ece1ac 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: ignore SIGPIPE at startup, not after thread creation
[14:34:51] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-3 d37fa8b 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * un-race-ify the linuxcncrsh client connection logic
[14:34:58] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-3 3885e41 06linuxcnc 10tests/ 10(5 files in 5 dirs) * now that connecting to linuxcncrsh is not racy, we dont need sleep
[14:35:05] <KGB-linuxcnc> 03seb 05linuxcncrsh-debug-3 07d34ad 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: dont bail on errors from parseCommand
[14:35:14] <seb_kuzminsky> linuxcncrsh-debug-3 is my candidate for merging into 2.5
[15:21:11] <KimK> seb_kuzminsky: I saw you say that you would like to work more on ja3, so would I. There's plenty to do right now so I don't know when either of us will get around to ja3, but I just wanted you to know I'm interested in it too. I'll be in the shop, I'll check back later. Congrats on your fixes, and thanks!
[17:14:16] <KGB-linuxcnc> 03seb 05v2.5_branch 7c18ad3 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: use the non-deprecated way to specify signal handlers
[17:14:17] <KGB-linuxcnc> 03seb 05v2.5_branch 2ece1ac 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: ignore SIGPIPE at startup, not after thread creation
[17:14:20] <KGB-linuxcnc> 03seb 05v2.5_branch d37fa8b 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * un-race-ify the linuxcncrsh client connection logic
[17:14:27] <KGB-linuxcnc> 03seb 05v2.5_branch 3885e41 06linuxcnc 10tests/ 10(5 files in 5 dirs) * now that connecting to linuxcncrsh is not racy, we dont need sleep
[17:14:33] <KGB-linuxcnc> 03seb 05v2.5_branch 07d34ad 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: dont bail on errors from parseCommand
[17:19:14] <KGB-linuxcnc> 03jepler 05master 399d48e 06linuxcnc 10src/hal/components/abs_s32.comp * get rid of FP use where it is unneeded
[17:19:14] <KGB-linuxcnc> 03seb 05master 7c18ad3 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: use the non-deprecated way to specify signal handlers
[17:19:18] <KGB-linuxcnc> 03seb 05master 2ece1ac 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: ignore SIGPIPE at startup, not after thread creation
[17:19:24] <KGB-linuxcnc> 03seb 05master d37fa8b 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * un-race-ify the linuxcncrsh client connection logic
[17:19:31] <KGB-linuxcnc> 03seb 05master 3885e41 06linuxcnc 10tests/ 10(5 files in 5 dirs) * now that connecting to linuxcncrsh is not racy, we dont need sleep
[17:19:37] <KGB-linuxcnc> 03seb 05master 07d34ad 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * linuxcncrsh: dont bail on errors from parseCommand
[17:19:44] <KGB-linuxcnc> 03seb 05master e501e37 06linuxcnc 10src/emc/usr_intf/emcrsh.cc * Merge branch 'v2.5_branch'
[19:12:11] <cradek> seb_kuzminsky: your dogged persistence amazes me
[20:27:12] <KGB-linuxcnc> 03chrisinnanaimo 05master 90a843f 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py * gscreen - fix no-jog-increments entry in INI error
[20:27:12] <KGB-linuxcnc> 03chrisinnanaimo 05master a4a02af 06linuxcnc 10lib/python/gladevcp/offsetpage.glade 10lib/python/gladevcp/offsetpage_widget.py 10src/emc/usr_intf/gscreen/gscreen.py * gladevcp -change the layout and control functions of offsetpage_widget
[20:27:18] <KGB-linuxcnc> 03chrisinnanaimo 05master e764987 06linuxcnc 10configs/sim/ 10gscreen_custom/gscreen_handler.py 10gscreen_custom/industrial_handler.py * gscreen config -hide the G5x row on the offsetpage widget
[20:27:26] <KGB-linuxcnc> 03chrisinnanaimo 05master 437aac6 06linuxcnc 10configs/sim/gscreen_custom/industrial.glade * gscreen config -move the onboard keyboard to the center tab
[21:57:15] <KGB-linuxcnc> 03elson 05master d933b48 06linuxcnc 10docs/src/drivers/pico_ppmc.txt * correct a few typos and descriptions
[21:57:15] <KGB-linuxcnc> 03elson 05master dc00503 06linuxcnc 10docs/src/drivers/pico_ppmc.txt * Merge branch 'master' of ssh://git.linuxcnc.org/git/linuxcnc
[22:10:26] <KGB-linuxcnc> 03elson 05master b7cdceb 06linuxcnc 10docs/src/drivers/pico_ppmc.txt * give range of values for some USC step timing parameters.