Back
[00:11:05] <linuxcnc-build> build #4449 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4449 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:47:39] <linuxcnc-build> build #4466 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4466 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[07:24:47] <jepler> one idea I had after bailing last night was, maybe a checkresult script that only checks certain lines of the output, avoiding the "on an edge" lines
[08:00:42] <skunkworks> zlog
[10:42:27] <seb_kuzminsky> linux 4.1.18 + rtai 5.0~test2 debs available at: deb
http://highlab.com/~seb/linuxcnc/ jessie main
[10:43:02] <seb_kuzminsky> 686-pae and amd64
[10:43:39] <seb_kuzminsky> i'm running my "build rip & runtests in a loop" test on them now
[10:43:57] <seb_kuzminsky> in VMs with 2 cpus each
[10:52:04] <skunkworks> oh - exciting. Going better?
[10:52:11] <seb_kuzminsky> too soon to tell
[10:52:26] <seb_kuzminsky> no crashes or problems yet, but it's only been running a few minutes
[10:52:41] <seb_kuzminsky> the 3.18 rtai debs would sometimes run for hours before crashing
[10:52:47] <seb_kuzminsky> ask me again tomorrow ;-)
[10:52:55] <skunkworks> heh - what did you change?
[10:53:17] <seb_kuzminsky> it's a new kernel patch from rtai.org
[10:53:54] <skunkworks> ah - cool!
[10:54:42] <seb_kuzminsky> they did not address the lxrt_list (resource hash table) bugs i reported, but it's use-case dependent and our particular usecase does not trigger it
[11:01:14] <seb_kuzminsky> this morning's coffee-break read:
https://motherboard.vice.com/read/sgt-augmento
[11:41:09] <seb_kuzminsky> aaand, it stalled :-(
[12:10:23] <jepler> seb_kuzminsky: :(
[12:11:20] <jepler> today's crazy idea: adapter from (micro)SD card to Mesa SPI-on-DB25/2x13 header. of course, you probably need that SD card slot for your OS, so it won't really work out
[12:36:58] <skunkworks> mozmck, I know not a great test - but the program ran over and over 500 times with no issues.
[12:40:34] <skunkworks> http://www.cnczone.com/forums/uccnc-control-software/315602-cnc-software.html
[13:47:25] <pcw_home> seems like at the minimum you would want to turn off windows updates on an embedded controller (like a CNC machine)
[13:48:23] <pcw_home> ( wonder if you can still do that on subscription windows versions like 10 )
[13:49:50] <skunkworks> not that I know of. Unless you have enterprise 10. (maybe)
[13:50:39] <skunkworks> I don't understand why you wouldn't use linuxcnc :) mature - bug fixes - inexpensive hardware - yadayadayada
[13:51:47] <pcw_home> because its "hard"
[14:10:56] <CaptHindsight> pcw_home: yeah, you can remove the update services
[14:11:54] <CaptHindsight> it's more hacking than an official procedure
[14:13:22] <CaptHindsight> I can't imagine trying to run a CNC on Win10 without pulling out several services first
[14:14:36] <pcw_mesa> Windows is slowly disappearing here
[14:14:38] <pcw_mesa> If it weren't for accounting using QuickBooks it would be gone by now
[14:16:11] <CaptHindsight> I still need it for CAD
[14:19:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek reopened issue #23: joints _axes: cannot home in Axis GUI 02
https://github.com/LinuxCNC/linuxcnc/issues/23
[14:40:38] <mozmck> pcw_mesa: there are some pretty good accounting packages in linux these days.
[14:42:27] <mozmck> skunkworks: thanks for running that testing. I have not had it happen to me, but apparently it does happen occasionally. Almost as bad as that uccnc not stopping ;-)
[14:48:16] <skunkworks> Bite your tongue!
[14:48:19] <skunkworks> ;)
[14:48:37] <mozmck> ouch!
[14:50:09] <mozmck> I think I'm getting over my head in gitignore - or maybe it can't do what I want?
[14:50:49] <seb_kuzminsky> what do you want it to do?
[14:50:51] <mozmck> I'm excluding everything and then using ! to include just the files I want.
[14:51:12] <seb_kuzminsky> that sounds crazy, but i think it should work
[14:51:17] <cradek> why?
[14:51:18] <mozmck> Works great so far, but I want to exclude files of the format pa.*.tcl
[14:51:25] <mozmck> but include all other .tcl files
[14:51:40] <mozmck> why? because for a xilinx project it is a *lot* smaller and cleaner
[14:52:04] <cradek> ah
[14:52:19] <cradek> I hate when a build craps stuff into the source directory
[14:52:24] <mozmck> Here's an example gitignore done the straightforward way:
https://www.gitignore.io/api/xilinxise
[14:52:27] <seb_kuzminsky> out-of-tree builds ftw
[14:52:40] <mozmck> That site looks neat btw
[14:53:09] <mozmck> Mine looks like this
[14:53:30] <mozmck> *
[14:53:30] <mozmck> !utils
[14:53:30] <mozmck> !*.ucf
[14:53:30] <mozmck> !*.v
[14:53:30] <mozmck> !*.vhd
[14:53:30] <mozmck> !*.wcfg
[14:53:30] <mozmck> !*.xco
[14:53:31] <mozmck> !*.xise
[14:53:46] <mozmck> except for the tcl stuff.
[14:54:06] <seb_kuzminsky> my reading of the gitignore manpage suggests you can't do wha tyou want
[14:54:13] <seb_kuzminsky> pa.*.tcl
[14:54:16] <seb_kuzminsky> !*.tcl
[14:54:24] <mozmck> I tried that :-)
[14:54:36] <seb_kuzminsky> would mean: ignore pa.*.tcl, but then un-ignore *.tcl (which includes pa.*.tcl)
[14:54:44] <mozmck> yep
[14:55:33] <mozmck> certain tools generate tcl files, but I might conceivably make my own as well. I could always include those manually I guess.
[14:55:44] <seb_kuzminsky> hmm, support of ** suggests to me that it's using extended globs...
[14:56:04] <mozmck> globs of what?
[14:57:03] <seb_kuzminsky> this sort of works for me:
[14:57:04] <seb_kuzminsky> pa.*.tcl
[14:57:04] <seb_kuzminsky> ![^p][^a][^.]*.tcl
[14:58:38] <mozmck> Hey, that's close! I missed ^ in the docs...
[14:58:59] <seb_kuzminsky> it's not in gitignore.5, it's in glob.7...
[14:59:56] <mozmck> oh - I guess I need to figure out what glob is
[15:00:31] <seb_kuzminsky> it's the thing you type in the shell to match multiple files, like "ls *.c" or "ls foo.?"
[15:00:59] <mozmck> I see - I haven't done much of that either.
[15:02:01] <mozmck> I recently learned enough regular expressions to do something I needed, but it fades fast if I don't use it more.
[15:02:15] <seb_kuzminsky> mmm, regexes
[15:03:54] <seb_kuzminsky> Some people, when they have a problem, think "I know! I'll write a regex!". Now they have two problems.
[15:04:17] <seb_kuzminsky> but seriously, regexes are awesome and i love them, and they love me back, thought it's a bit of an abusive relationship
[15:07:48] <seb_kuzminsky> mozmck: after some more testing i think this might work for you:
[15:07:50] <seb_kuzminsky> *
[15:07:50] <seb_kuzminsky> ![^p][^a][^.]*.tcl
[15:07:50] <seb_kuzminsky> !??.tcl
[15:07:50] <seb_kuzminsky> !?.tcl
[15:08:00] <seb_kuzminsky> the first line says "ignore everything"
[15:08:28] <seb_kuzminsky> the second line says "un-ignore anything that doesn't begin with "pa.", then has any characters followed by ".tcl"
[15:08:57] <mozmck> that partly works, but it also ignores patest.tcl
[15:09:03] <seb_kuzminsky> the third and fourth lines say "un-ignore any one- and two-character strings followed by .tcl"
[15:09:17] <seb_kuzminsky> ah, right
[15:10:07] <mozmck> why does it do that? I would think the [^.] would fix that
[15:11:28] <mozmck> not that I need a file named patest.tcl, but I made it to test my ingor(anc)e
[15:11:49] <seb_kuzminsky> how's this:
[15:11:52] <seb_kuzminsky> *
[15:11:52] <seb_kuzminsky> ![^p]??*.tcl
[15:11:52] <seb_kuzminsky> !?[^a]?*.tcl
[15:11:52] <seb_kuzminsky> !??[^.]*.tcl
[15:11:52] <seb_kuzminsky> !??.tcl
[15:11:54] <seb_kuzminsky> !?.tcl
[15:14:39] <mozmck> haha! Starting to look like chinese - but that works for this.
[15:14:48] <seb_kuzminsky> oh wait, i think it's !, not ^
[15:15:09] <seb_kuzminsky> yeah
[15:15:16] <seb_kuzminsky> i was thinking regexes, not globs ;-)
[15:15:35] <mozmck> Thanks for the help! I might just add the tcl files I make if I make any.
[15:15:52] <mozmck> Didn't mean to take up a bunch of your time
[15:16:00] <seb_kuzminsky> it's fine :-)
[15:16:11] <seb_kuzminsky> i'd have ignored you if i was busy ;-)
[15:16:47] <mozmck> ok, thanks :-)
[15:47:07] <pcw_mesa> the "Y" tcl bug seem to be tcl version related, not 64 bit related
[15:47:08] <pcw_mesa> (2.7 works fine on Mint 17.3 64 bit but not Mint 18 64 bit)
[15:52:38] <cradek> pcw_mesa: cool - could you add that information to bug 23?
[16:00:01] <alex4nder> pcw_mesa: that sounds like it's related to the bug that's causing this...
[16:00:06] <alex4nder> https://gist.github.com/alexanderguy/2e8997b6d63188852728a0f39d918e88
[16:00:13] <alex4nder> which was tcl version related
[16:04:09] <cradek> that fix is pretty horrifying :-/
[16:05:29] <jepler> things are broken and I would like for them not to be.
[16:05:52] <jepler> that's at least a less invasive fix than one I saw offered from machinekit's git
[16:06:45] <alex4nder> cradek: it sucks
[16:07:04] <jepler> somebody really ought to distill the problem down to a test case and get it filed with Python
[16:07:10] <jepler> and/or with Tcl
[16:07:21] <jepler> and/or with debian, mint, ubuntu
[16:07:26] <alex4nder> I dove into the underlying bindings, and it was pretty far down the rabbit hole
[16:07:38] <jepler> once somebody's done that, then we can be pragmatic and take a workaround fix
[16:09:26] <pcw_mesa> The issue I see is not #23 AFAIK (thats JA related)
[16:10:21] <pcw_mesa> I dont see the issue on master, only 2.7 on Mint 18 (Ubuntu 16.04 based)
[16:11:27] <jepler> yes, I agree, issue #23 is something else
[16:11:47] <cradek> I screwed that up
[16:11:47] <jepler> seb_kuzminsky has said something about this "y" problem being worked around by accident in our master branch due to JA changes
[16:11:55] <cradek> it looked the same...
[16:18:28] <seb_kuzminsky> i can home Y on master on stretch, but when i try to home Y on 2.7 on stretch i get that error (using Axis)
[16:18:58] <cradek> still, after you load a gcode program?
[16:22:55] <seb_kuzminsky> didn't try that
[16:27:30] <andypugh> http://codepad.org/G9J5Lf23
[16:27:34] <andypugh> This has me baffled
[16:28:33] <andypugh> The substitutions (347 onwards) work for axis.0.jog-scale as both a setp and a net. But not for jog-enable or jog-vel-mode
[16:30:15] <andypugh> New paste:
http://codepad.org/G9J5Lf23
[16:30:59] <andypugh> That has the results at the bottom. See how the “net” substitutions have a spurious “setp” added below them.
[16:31:34] <andypugh> (in the next stage @ax1@ gets changed to axix.y and suchlike)
[16:32:53] <andypugh> Actually, I can’t add the output.
[16:33:27] <andypugh> It’s here instead:
http://codepad.org/f6AvIc2u
[16:34:07] <andypugh> The comment lines are what was substituted, with the dots foubled to miss the regex
[16:44:52] <andypugh> Can anyone see through the code in a way that I can’t to see what is different about jog-scale?
[17:00:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #138: @SebKuzminsky, you're right, motion doesn't know about coordinate systems, but real-time program execution is limited by how fast motion plays out trajectories, whereas interp can queue up commands as fast as it can until hitting either EOF or a queue buster. Running the example from the first comment, `nc_files/systems.ngc`, you can see interp and canon getting out of synch: the modelin
[17:08:24] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #134: I have prepared a [branch][1] based on the latest 2.7 with the latest set of updates. It fixes the issues @cradek reported in the two above-mentioned SF issues, and also fixes #138, where interp and canon states can be out of synch after abort, which is related to @cradek's additional concern about restore-on-abort.... 02
https://github.com/LinuxCNC/linuxcnc/issues/134#issuecomment-24086
[17:46:42] <andypugh> I worked it out. The wierdness was due to the random order of the dictionary, but basically comes down to me not understanding regex
[18:24:36] <seb_kuzminsky> Gilles Chanteperdrix of Xenomai died :-(
[18:32:18] <pcw_mesa> yeah terrible news :-(
[19:55:59] <andypugh> Does the forum server need a kick?
[19:58:49] <jepler> andypugh: checking
[19:59:17] <jepler> forum responds to ping, not to http or ssh
[19:59:53] <jepler> console shows kernel errors, rebooting
[19:59:57] <andypugh> Thanks
[20:00:36] <jepler> hm it may be a problem at the hoster. it shows "event processing" on the virtual machine, reboot button unavailable
[20:00:52] <jepler> it appears it has started the weekly backup 6 minutes ago
[20:01:20] <jepler> in the last three instances the backup took 6, 6, and 11 minutes
[20:01:29] <andypugh> Ah well.
[20:01:32] <jepler> but .. I expect the system to be available during the backup!
[20:02:22] <jepler> > However, copy-on-write implementations do take a performance hit on new writes that occur after the snapshot is taken until the backup process is complete. This happens because, for every new write, a system using copy-on-write must read the original data, write it to a new location, and then write the new changes to the original data location. This can significantly impact performance on busy, I/
[20:02:29] <jepler> O bound workloads. The performance impact disappears when the snapshot is automatically deleted after the backup operation.
[20:02:46] <jepler> so it is instant and has no effect on the running droplet, except for the fine print which says it's not :-P
[20:03:57] <jepler> cycling power
[20:04:45] <jepler> and it's bak
[20:04:47] <jepler> back
[20:17:21] <andypugh> Thanks
[20:42:48] <jepler> OK, no big surprise, reproduced with 2.7.6 in debian testing (in a chroot in my case)
[20:42:51] <jepler> File "/home/jepler/src/linuxcnc/2.7-squeeze/bin/axis", line 2356, in home_axis
[20:42:54] <jepler> if s.homed["xyzabcuvw".index(vars.current_axis.get())]:
[20:42:56] <jepler> ValueError: substring not found
[21:24:51] <jepler> Installing version 2.7.8-2+b1 of python-tk (from jessie/main) makes the
[21:24:55] <jepler> script succeed, so I believe the problem was introduced between
[21:24:59] <jepler> 2.7.8-2+b1 and 2.7.11-2.
[21:26:12] <jepler> (I wish I knew why my pastes sometimes got so much trailing whitespace on them)
[21:29:34] <jepler> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834783
[21:32:55] <jepler> > - Issue #21526: Tkinter now supports new boolean type in Tcl 8.5. [2.7.10]
[21:38:44] <cradek> difference of 0.0.3 is a fine place to find new features that break backward-compatibility
[21:47:33] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #146: linuxcnc triggers bug in python 2.7.11-2; work around it 02
https://github.com/LinuxCNC/linuxcnc/issues/146
[21:47:39] <jepler> linuxcnc 2.7.5 means we shouldn't throw stones
[21:54:16] <KGB-linuxcnc> 03Jeff Epler 052.6 1bec919 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis: work around python-tk "True" bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1bec919
[21:54:32] <KGB-linuxcnc> 03Jeff Epler 052.7 8eba5bb 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8eba5bb
[21:56:22] <KGB-linuxcnc> 03Jeff Epler 05master 8804854 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py 10src/emc/usr_intf/halui.cc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8804854
[21:59:31] <jepler> brb
[22:03:38] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed issue #146: linuxcnc triggers bug in python 2.7.11-2; work around it 02
https://github.com/LinuxCNC/linuxcnc/issues/146
[22:05:17] <jepler> cradek's on fire tonight1
[22:07:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #23: The 'substring not found' bug is different, see #146 02
https://github.com/LinuxCNC/linuxcnc/issues/23#issuecomment-240913211
[22:40:54] <linuxcnc-build> build #4452 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4452 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:40:54] <linuxcnc-build> build #4467 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4467 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:41:54] <jepler> command timed out: 1200 seconds without output, attempting to kill
[22:41:56] <jepler> grgrnagrag
[22:47:44] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/precise-amd64-screenshot.png
[23:06:19] <linuxcnc-build> build #4453 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4453 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:43:29] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #126: @SebKuzminsky, I see #138 may be a duplicate of this issue, my apologies.... 02
https://github.com/LinuxCNC/linuxcnc/issues/126#issuecomment-240923760
