Back
[01:11:13] <KGB-linuxcnc> 03Chris S Morley 05pncconf_builder 5c328d4 06linuxcnc 10(5 files) pncconf -wip * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c328d4
[02:26:42] <linuxcnc-build> build #104 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/104 blamelist: Chris S Morley <chrisinnanaimo@hotmail.com>
[05:19:58] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 7f368cf 06linuxcnc 10docs/src/hal/rtcomps.txt 10docs/src/hal/rtcomps_de.txt 10docs/src/hal/rtcomps_es.txt 10docs/src/hal/rtcomps_pl.txt fix broken links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f368cf
[05:19:59] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch e213ae3 06linuxcnc 10(5 files) cleaning & fix broken links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e213ae3
[06:38:06] <jthornton> has anyone downloaded
http://linuxcnc.org/iso/ubuntu-10.04-linuxcnc3-i386.iso and burned it to a CD? The latest I have is ubuntu-10.04-linuxcnc2-i386.iso and I don't have any bandwidth left for the month so I can't try it
[06:38:58] <jthornton> http://linuxcnc.org/index.php/english/forum/9-installing-linuxcnc/27649-cant-seem-to-fit-the-iso-onto-a-cd#45272
[06:45:02] <linuxcnc-build> build #105 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/105 blamelist: Francis Tisserant <tissf@free.fr>
[07:43:32] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 06d45e2 06linuxcnc 10(5 files in 2 dirs) cleaning bad pastes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=06d45e2
[08:16:12] <skunkworks> will installing a linuxcnc deb on precise - then pull the correct rtai when doing a apt-get install -f?
[08:23:03] <skunkworks> so - something like this should not be a problem?
http://electronicsam.com/images/KandT/testing/linuxcncdebs/
[08:45:50] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 46ba766 06linuxcnc 10(5 files) fix another bad paste * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=46ba766
[09:09:06] <linuxcnc-build> build #106 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/106 blamelist: Francis Tisserant <tissf@free.fr>
[10:00:23] <jepler> was there a consensus whether I should push the -fwrapv and ilowpass overflow items to master branch?
[10:00:37] <jepler> .. did anyone else test or otherwise dredge up an opinion?
[10:17:40] <pcw_home> would that fix the deltas on wraps?
[10:21:05] <pcw_home> I guess Ilowpass needs a scale set so its not too crunchy but doesn't overflow too soon
[10:55:54] <seb_kuzminsky> jepler: i dont understand your patch
[10:56:16] <seb_kuzminsky> the first commit does the multiplication in double, then casts the answer to s64, then to int
[10:57:25] <jepler> seb_kuzminsky: yes, that's what it does
[10:57:41] <jepler> seb_kuzminsky: when the conversion from double to int is outside the range of int, the result is implementation-defined
[10:57:56] <jepler> on gcc/x86, the result is apparently always INT_MIN
[10:59:06] <jepler> the double->s64 and s64->int casts are also implementation-defined, but with -fwrapv the implementation defined conversion for s64->int is the good old fashioned "take the lower bits" one, and wrapping behavior is restored
[10:59:29] <jepler> so the problem of ilowpass clamping to INT_MIN is 2^32 times more counts away
[11:01:46] <jepler> (in fact, that point is already after you've lost precision in the double, because its mantissa is only 53 bits iirc)
[11:02:50] <jepler> pcw_home: yes, specifically after that patch ilowpass's output wraps around instead of clamping
[11:03:28] <jepler> seb_kuzminsky: would it help if I expand the commit message on the ilowpass change?
[11:03:35] <jepler> along the lines I was giving above
[11:08:20] <seb_kuzminsky> maybe i'm being dense here
[11:08:39] <seb_kuzminsky> if ilowpass's output wraps, won't that cause a giant jog to the other end of travel?
[11:09:21] <jepler> motion does this:
[11:09:22] <jepler> 09:27:42 < jepler> delta = new_jog_counts - joint->old_jog_counts;
[11:09:36] <jepler> with fwrapv, INT_MIN - INT_MAX is defined to be 1
[11:09:51] <seb_kuzminsky> maybe i should read the first time you explain instead of making you repeat yourself
[11:10:40] <jepler> so basically, in my testing, motion was already set up to handle the wraparound, ilowpass just wasn't wrapping around
[11:10:48] <seb_kuzminsky> gotcha
[11:10:49] <seb_kuzminsky> cool
[11:10:53] <jepler> .. and -fwrapv is a kick in the pants of gcc to make it promise us that behavior
[11:11:12] <seb_kuzminsky> i haven't tested it, but your explanation makes sense and if it passes your tests i say go ahead and push it
[11:11:21] <jepler> OK
[11:11:23] <seb_kuzminsky> i guess it belongs in 2.5?
[11:11:32] <linuxcnc-build> build #107 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/107 blamelist: Francis Tisserant <tissf@free.fr>
[11:11:32] <jepler> cradek: ^^ ??
[11:14:12] <seb_kuzminsky> there's some good stuff in v2.5_branch after v2.5.3, maybe a .4 would be valuable
[11:17:26] <seb_kuzminsky> m61 support, docs fixes, fixes to packaging, pncconf, misc components, touchy, an accel constraint violation, fixes to build on wheezy
[11:21:03] <seb_kuzminsky> cradek: i'm trying to get a wheezy-rtai-i386 buildslave up soonish, then you could release 2.5 (your favorite) on wheezy (your favorite) ;-)
[11:22:52] <cradek> jepler: yes definitely 2.5 if you tested it and it works better now
[11:30:18] <jepler> I'll add a test to prove it.
[11:30:25] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-ilowpass-test-for-wraparound-behavior.patch
[11:30:36] <cradek> that would be wizardly
[11:31:22] <seb_kuzminsky> i am pro-proof
[11:31:49] <cradek> we should have 12-bit encoder count types so we're forced to always get it right
[11:32:05] <cradek> or maybe signed 16 bit to make it all easy
[11:33:16] <seb_kuzminsky> that makes me think of when linus made the linux internal tick counter initialize at boot to "10 minutes before rollover" to get people to fix their rollover bugs
[11:43:28] <pcw_home> deltas from timers are easier since they only count one way
[11:43:35] <cradek> if I have a build depend of module-init-tools|kmod, how does buildbot (pbuilder?) choose?
[11:45:04] <seb_kuzminsky> cradek: use either module-init-tools or kmod depending on the DISTRIB_NAME
[11:45:59] <cradek> module-init-tools works for all of them today, but probably won't in the future.
[11:46:48] <cradek> I was hoping to do the thing that's simpler today but would also work in the future
[11:47:38] <cradek> I guess I'll just try module-init-tools for now (since wheezy has it)
[11:49:25] <seb_kuzminsky> i think the way i suggested will work now & in the future
[11:49:42] <cradek> hm
[11:49:52] <seb_kuzminsky> we already have per-distro build dependencies (EXTRA_BUILD in debian/configure), this fits neatly in that model
[11:49:56] <cradek> sure, it will if we update it when adding platforms
[11:50:07] <cradek> ok, you convinced me
[11:50:13] <seb_kuzminsky> yeah, that's the downside :-/
[11:50:25] <cradek> but the runtime dependency can be the |
[11:50:36] <seb_kuzminsky> you'll have to do something similar for the runtime dependency - or use |
[11:53:40] <KGB-linuxcnc> 03Jeff Epler 05v2.5_branch 72ff31d 06linuxcnc Merge branch 'ilowpass-wrap' into v2.5_branch * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=72ff31d
[11:53:40] <KGB-linuxcnc> 03Jeff Epler 05master 8a009cc 06linuxcnc 10src/Makefile Merge branch 'ilowpass-wrap' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a009cc
[12:01:51] <seb_kuzminsky> jepler: i think you meant to merge 2.5 into master, not ilowpass-wrap?
[12:02:55] <jepler> seb_kuzminsky: does it make a difference?
[12:03:20] <jepler> I can do it whichever way you prefer in the future.
[12:04:51] <jepler> I felt like merging ilowpass is more explicit
[12:06:34] <cradek> I don't think it makes a difference, but I like to see the explicit merging-upwards (there are two things you want the merge to show, and it can only really show one of them...)
[12:06:50] <cradek> thanks for fixing it; that's the important thing
[12:08:49] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim 7bd1a7a 06linuxcnc 10debian/control.in These are needed for building and running on all platforms * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7bd1a7a
[12:08:50] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim 5dc261d 06linuxcnc 10src/configure.in Fail on missing programs, instead of generating bogus scripts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5dc261d
[12:08:50] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim a82a6ab 06linuxcnc 10debian/configure 10debian/control.in Explicitly give the right build dependency for insmod/rmmod/etc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a82a6ab
[12:08:52] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim 610aaad 06linuxcnc 10debian/configure Debian testing is more like 7 than 6, today * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=610aaad
[12:10:43] <seb_kuzminsky> agreed, fixing it is the important thing -- thanks for figuring that one out
[12:11:41] <seb_kuzminsky> i slightly prefer merging upwards because it avoids the situation we're in now (well, the situation we'll be in after the next merge of 2.5 into master), where the ilowpass-wrap commits appear twice in the history of master
[12:12:50] <jepler> you're right, after merging 2.5 into master there will be two commits that say "merge ilowpass"
[12:12:55] <cradek> .... which is all conflicty
[12:12:58] <cradek> ick
[12:13:46] <cradek> asciidoc markup and git merge conflict markup look remarkably similar
[12:15:04] <seb_kuzminsky> i should have maybe asked francis tisserant to do his doc fixes in master instead of 2.5
[12:15:17] <seb_kuzminsky> or i should have put the fixed checkref in 2.5
[12:15:48] <cradek> Deleted merge conflict for 'docs/src/config/ini_config_de.txt':
[12:15:48] <cradek> {local}: deleted
[12:15:48] <cradek> {remote}: modified file
[12:15:48] <cradek> Use (m)odified or (d)eleted file, or (a)bort?
[12:15:56] <cradek> what does this mean?
[12:16:30] <jepler> v2.5_branch edited the file, master branch deleted it
[12:16:31] <cradek> I guess local means master (the branch I'm on)
[12:16:43] <cradek> ok
[12:19:55] <KGB-linuxcnc> 03Chris Radek 05master 53c9c63 06linuxcnc 10docs/src/config/ini_config.txt 10docs/src/hal/rtcomps_es.txt Merge branch 'v2.5_branch' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=53c9c63
[12:20:12] * cradek takes one for the team
[12:23:40] <jepler> cradek: thanks
[12:23:49] <jepler> (it's not even because the merge was hard that I did it the way I did)
[12:24:20] <cradek> heh, I was not accusing you of that
[12:25:15] <seb_kuzminsky> heh
[12:32:54] <memleak> for the past year working on rtai i've mainly been focusing on 64-bit support but as for the linuxcnc live cd, does the 3.4.55 kernel with recent version of gcc (4.7.3 or 4.8.2) work with 32-bit?
[12:41:41] <memleak> i guess if anyone here who uses 3.4.55 to run sudo apt-get install gcc && gcc --version would tell me :P
[13:10:32] <seb_kuzminsky> memleak: we currently ship 3.4.55 rtai on ubuntu precise, which has gcc 4.6.3
[13:11:17] <memleak> is that after the stack boundary 4 vs 8 or 16 or w/e stuff happened?
[13:11:28] <memleak> the stuff John was talking about
[13:12:45] <linuxcnc-build> build #108 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/108 blamelist: Jeff Epler <jepler@unpythonic.net>
[13:12:54] <memleak> http://article.gmane.org/gmane.linux.real-time.rtai/22724
[13:13:17] <memleak> That was Jan, whoops..
[13:13:50] <memleak> http://article.gmane.org/gmane.linux.real-time.rtai/26416
[13:14:17] <memleak> there it is!
[13:18:43] <seb_kuzminsky> errr... not sure
[13:40:36] <zultron> 3.5.7 & before isn't affected by the stack boundary issue; the following i-pipe patch, 3.8.13 or so, might be.
[13:42:53] <seb_kuzminsky> oh that's great, maybe we can dodge a bullet (for now)
[13:57:50] <zultron> Agh, confusing, I think this is it: Newer kernels *and* newer gcc, so linux 3.8.13+ and recent distro releases. If either kernel or gcc is older, there's no problem.
[13:58:29] <zultron> I ran into it on Fedora 19 or 20 when compiling RTAI with the 3.8.13 i-pipe patch.
[13:58:52] <zultron> (Or maybe Xenomai kernel threads)
[14:12:04] <memleak> zultron, thank you!
[14:12:17] <zultron> :)
[14:13:00] <memleak> zultron, seriously i cannot believe you figured that out! that's awesome!!!!!!
[15:05:30] <linuxcnc-build> build #109 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/109 blamelist: Jeff Epler <jepler@unpythonic.net>
[16:11:34] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 696e1e0 06linuxcnc 10(11 files in 6 dirs) fix some broken links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=696e1e0
[17:01:54] <linuxcnc-build> build #110 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/110 blamelist: dummy, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>
[17:24:56] <memleak> zultron, looks i just completed your theory:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=e2b34e311be3a57c9abcb927e37a57e38913714c
[17:26:01] <zultron> Yup, I saw that. Glad we get to save those wasted four-byte blocks.
[17:36:48] <memleak> so if we explicitly set -mpreferred-stack-boundary=4 in linuxcnc, would that fix it for modern kernel + gcc on amd64?
[17:37:23] <cradek> yay, looks like I finally got my wheezysim changes right
[17:39:49] <cradek> the buildbot sure keeps busy
[17:41:56] <memleak> i found the gcc commit too:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e24005a24f41165050220aba1cabd6da49d255fb
[17:42:46] <zultron> memleak, yes.
[17:43:40] <memleak> does boundary=4 mean 64?
[17:44:08] <memleak> that gcc commit says it needs to be 64 if 64 arch w/ SSE
[17:56:39] <zultron> it means 2^4 bytes
[17:57:57] <memleak> so it should really be =6
[17:58:40] <zultron> I don't know where you're reading that.
[17:59:08] <zultron> It should be =4.
[17:59:39] <memleak> but thats 16 and the kernel commit says SSE doesn't work with 16-byte aligned
[18:00:09] <memleak> 2^6 = 64 and thats what the GCC commit says works
[18:01:13] <memleak> ah thats for if SSE is disabled..
[18:01:28] <memleak> (MIN_STACK_BOUNDARY): Set to 64 for 64-bit
[18:04:27] <zultron> I don't think you need to worry about that. Go back and read the rtai list postings. IIRC, another person had success with this setting.
[18:06:06] <memleak> ok thanks!
[18:32:40] <JT-Shop> yuck G96 seems to be broken in master
[18:34:23] <cradek> yuck, howso?
[18:34:30] <JT-Shop> getting the link
[18:35:33] <JT-Shop> http://www.linuxcnc.org/index.php/english/forum/20-g-code/27648-g96-css-problem
[18:36:23] <JT-Shop> I finally got wise and asked him what version he was using'
[18:37:16] <cradek> I don't understand "but I do not get a spindle at speed and the joint sits."
[18:38:21] <JT-Shop> that is what I'd expect to happen when you don't get spindle at speed
[18:38:44] <cradek> yes, it won't move
[18:39:00] <cradek> a feature
[18:39:14] <cradek> have you reproduced a problem?
[18:39:48] <JT-Shop> no, I've not had time
[18:40:03] <cradek> I don't understand why he has a pid in there
[18:40:04] <JT-Shop> think of three legged cat in a litter box
[18:40:16] <cradek> you know tripod?
[18:40:31] <JT-Shop> tripod is my neighbors dog
[18:40:52] <JT-Shop> one rear leg and she has to climb up my legs to get in my lap
[18:41:06] <cradek> I would not necessarily conclude from this thread that master is broken... :-/
[18:41:39] <JT-Shop> not enough facts to conclude yet
[18:42:47] <JT-Shop> I'll ask him if he changed anything between 2.5 and master
[18:42:56] <cradek> a basic g96 test in sim/lathe works fine
[18:43:01] * JT-Shop heads inside to put on the chef hat
[18:43:11] <JT-Shop> that is good
[18:43:46] <cradek> g96s100d1000m3, g0x.5, speed is 382rpm; g0x0, speed is 1000rpm
[18:44:30] <JT-Shop> thanks for checking
[18:44:38] <cradek> I don't trust his setup with pid and near
[18:46:13] <JT-Shop> gotta go and start dinner
[18:46:18] <linuxcnc-build> build #111 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/111 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>, Francis Tisserant <tissf@free.fr>
[19:10:11] <andypugh> What issue were you discussing up there?
[19:11:51] <cradek> who where?
[19:12:51] <andypugh> In between the three-legged dog
[19:13:02] <cradek> http://www.linuxcnc.org/index.php/english/forum/20-g-code/27648-g96-css-problem
[19:13:11] <cradek> this report of css not working
[19:13:25] <cradek> I strongly suspect it's a config problem (my testing worked)
[19:15:28] <andypugh> Yes, I have never seen a problem, though I actually have no idea what version I am running on any of may machines. I think the mill is a jwp-ja4 combo….
[19:16:11] <andypugh> (And will probably stay that way until 2.7 as I don’t want the hassle of reverting the INI and HAL files.)
[20:39:15] <linuxcnc-build> build #112 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/112 blamelist: Francis Tisserant <tissf@free.fr>
[21:44:48] <KGB-linuxcnc> 03Chris Radek 05master 3b03cef 06linuxcnc 10debian/control.in These are needed for building and running on all platforms * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3b03cef
[21:44:48] <KGB-linuxcnc> 03Chris Radek 05master 0b5fba4 06linuxcnc 10src/configure.in Fail on missing programs, instead of generating bogus scripts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b5fba4
[21:44:48] <KGB-linuxcnc> 03Chris Radek 05master 39e36eb 06linuxcnc 10debian/configure 10debian/control.in Explicitly give the right build dependency for insmod/rmmod/etc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=39e36eb
[21:44:51] <KGB-linuxcnc> 03Chris Radek 05master 39cf169 06linuxcnc 10debian/configure Debian testing is more like 7 than 6, today * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=39cf169
[21:45:46] <KGB-linuxcnc> 05cradek/wheezysim 610aaad 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=610aaad
[23:05:04] <linuxcnc-build> build #113 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/113 blamelist: Chris Radek <chris@timeguy.com>