Back
[00:00:23] <linuxcnc-build> build #1377 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1377 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:26:01] <linuxcnc-build> build #1371 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1371 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:38:34] <KGB-linuxcnc> 03git 05anti-static 284c44f 06linuxcnc 10src/ 10Makefile 10Makefile.inc.in 10configure.in 03m4/ax_cxx_compile_stdcxx_11.m4 * build: add C++11 standard detection, CXXFLAGS autoconf support
[03:42:51] <linuxcnc-build> build #1376 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1376 blamelist: dummy, Michael Haberler <git@mah.priv.at>
[03:43:09] <linuxcnc-build> build #1378 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1378 blamelist: dummy, Michael Haberler <git@mah.priv.at>
[03:45:09] <linuxcnc-build> build #1173 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1173 blamelist: dummy, Michael Haberler <git@mah.priv.at>
[03:46:02] <linuxcnc-build> build #1374 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1374 blamelist: dummy, Michael Haberler <git@mah.priv.at>
[03:46:04] <linuxcnc-build> build #1379 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1379 blamelist: dummy, Michael Haberler <git@mah.priv.at>
[03:46:17] <linuxcnc-build> build #1377 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1377 blamelist: dummy, Michael Haberler <git@mah.priv.at>
[04:14:06] <linuxcnc-build> build #1372 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1372 blamelist: dummy, Michael Haberler <git@mah.priv.at>
[07:40:31] <jepler> well those were an interesting collection of build errors I created last night.
[07:45:21] <jepler> the one I understand, but not how I could have introduced the linker errors I don't know yet
[07:46:11] <jepler> (that was a slightly muddled sentence, wasn't it)
[08:24:28] <jepler> sigh, most things about my recent upgrade to debian-kfreebsd on my "big server" are fine, but having no accelerated virtualization solution means I have to find a different way to work on this compile problem that pops up only on realtime systems when using -std=gnu99
[08:29:49] <cradek> jepler: you may have forgotten the Cc on that mail about pluto
[08:30:55] <jepler> cradek: argh, oops
[08:31:42] <jepler> weird, the one in my sent folder has To: emc-developers@lists.sourceforge.net
[08:31:46] <jepler> Cc: "W. Martinjak" <matsche@play-pla.net>
[08:31:49] <jepler> the one I received from the list has no Cc: header
[08:32:11] <cradek> huh, must be a "feature"
[08:33:02] <jepler> 2013-10-07 07:53:52 1VTAJf-000GOy-GD SMTP error from remote mail server after RCPT TO:<matsche@play-pla.net>: host mail.play-pla.net [212.186.185.170]: 451 4.7.1 Greylisting in action, please come back later
[08:33:08] <jepler> my system is working on delivering it
[08:33:15] <jepler> but yeah, what stupid is SF up to today?
[08:33:49] <cradek> maybe a mailman feature (some people think hiding email addresses in various situations is important)
[08:34:50] <jepler> I am surprised I never noticed that
[08:35:07] <jepler> it badly breaks the linux/git/debian style of courtesy cc to everyone in the discusison, just in case some are not on the list
[08:35:38] <jepler> .. which I'm sure is not universally popular, but it's certainly the culture of a lot of big communities that operate via e-mail
[08:35:39] <cradek> but that's obnoxious
[08:39:10] <jepler> as you know, it's a requirement that all linux developers be obnoxious
[08:39:19] <jepler> actually, that's not true, it's just the project leaders
[08:40:37] <cradek> I can't find a mailman option that might be responsible
[08:41:20] <cradek> (I didn't know that CC was normal, and with that new information I'll roll my eyes less when I get one, so thanks)
[08:47:00] <skunkworks> I noticed that on the rtnet mailing list. I got a message from one of the members that cc the rtnet mail list address. So I normally do just a reply not reply to all. so it never went to the list.
[08:47:19] <skunkworks> I don't like that.
[08:47:43] <cradek> mailman can set Reply-To the list or the user. the screen I just was digging through "strongly" suggests setting it to user, which I think is totally wrong
[08:47:56] <cradek> so there's a lot of wrongness out there, look out :-)
[08:48:31] <archivist> I absolutely hate reply to user being set on public lists
[09:02:31] <KGB-linuxcnc> 03git 05master 8f615e9 06linuxcnc 10src/emc/ 10rs274ngc/interp_array.cc 10rs274ngc/rs274ngc_interp.hh 10rs274ngc/rs274ngc_pre.cc * interp: no more static _setup
[09:02:31] <KGB-linuxcnc> 03git 05master 68476fd 06linuxcnc 10src/emc/rs274ngc/interpmodule.cc * interp: adapt exposure of _setup members
[09:02:34] <KGB-linuxcnc> 03git 05master c113e5b 06linuxcnc 10tests/remap/ 10introspect/expected 10introspect/oword.py * tests/interp: adapt remap/introspect
[09:02:41] <KGB-linuxcnc> 03git 05master 726527c 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp/setup_struct: add ctor, dtor declaration
[09:02:47] <KGB-linuxcnc> 03git 05master c8ea07d 06linuxcnc 03src/emc/rs274ngc/interp_setup.cc * interp/setup_struct: constructor definition
[09:02:54] <KGB-linuxcnc> 03git 05master 87434c2 06linuxcnc 10src/emc/rs274ngc/Submakefile * interp/Submakefile: add interp_setup.cc
[09:03:00] <KGB-linuxcnc> 03git 05master 7e8ae44 06linuxcnc 10src/ 10Makefile 10Makefile.inc.in 10configure.in 03m4/ax_cxx_compile_stdcxx_11.m4 * build: add C++11 standard detection, CXXFLAGS autoconf support
[09:07:11] <linuxcnc-build> build #1377 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1377 blamelist: Michael Haberler <git@mah.priv.at>
[09:07:26] <linuxcnc-build> build #1379 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1379 blamelist: Michael Haberler <git@mah.priv.at>
[09:08:54] <linuxcnc-build> build #1174 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1174 blamelist: Michael Haberler <git@mah.priv.at>
[09:09:56] <linuxcnc-build> build #1380 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1380 blamelist: Michael Haberler <git@mah.priv.at>
[09:10:33] <linuxcnc-build> build #1378 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1378 blamelist: Michael Haberler <git@mah.priv.at>
[09:11:08] <linuxcnc-build> build #1375 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1375 blamelist: Michael Haberler <git@mah.priv.at>
[09:13:51] <KGB-linuxcnc> 03TODO: deletor 05anti-static 284c44f 06linuxcnc 04. * branch deleted
[09:38:38] <linuxcnc-build> build #1373 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1373 blamelist: Michael Haberler <git@mah.priv.at>
[12:50:01] <skunkworks> micges, this other computer using the intel pro/100 is peaking at 430us for max servo thread
[12:56:10] <micges> skunkworks: thanks
[12:56:38] <skunkworks> this is using the ubc3 and the 7i80 stuff
[12:58:32] <micges> ubc3 and 7i80 doesn't compile in rt-preempt, I must ping mhaberler for help
[13:27:55] <jepler> so mah's anti-static branch had build errors on the buildbot and rather than correct them he pushed the branch to master?
[13:28:09] * jepler faceplam
[13:32:44] <jepler> as for the hardy failure .. that's because it has no support for C++11. As far as I know, nobody is a champion for retaining Hardy support so we should drop it in buildbot
[13:32:54] <jepler> unless that requires another irc monthly meeting in order to have due process
[13:33:23] <cradek> do we now depend on c++11 features that are hard to go without, or is it incidental?
[13:34:11] <jepler> the c++11 feature newly being used is avoidable
[13:34:26] <jepler> but there's no reason to bother unless somebody's fired up about hardy in 2.6 and I thought that was the null set
[13:34:53] <jepler> we agreed in an irc monthly meeting (didn't we?) that losing hardy support was not a reason to not merge the rtos branch, for instance..
[13:35:39] <cradek> iirc, we agreed to dump hardy when and where we merge ubc because hardy+ubc is hard
[13:36:16] <cradek> [btw I see master/precise is broken too, for a different reason]
[13:36:29] <jepler> yes
[13:36:36] <jepler> I don't know why mah didn't pay attention to buildbot before pushing
[13:38:11] <cradek> maybe he didn't care about hardy, and missed the other stuff in the noise
[13:39:36] <cradek> master builds for me on lucid
[13:39:56] <cradek> yay for c++
[13:39:57] <jepler> ironically, the reason precise fails is it has better support for c++11 than the others :-/
[13:40:30] <cradek> the gifts c++ give us never end
[13:41:14] <jepler> The c++11 subset supported by g++ on lucid (4.4.3) and on current systems (4.7 or 4.8) are quite different
[13:41:15] <archivist> I wonder why I prefer straight C
[13:49:18] <jepler> I can change mah's new code to use memset instead of the new initializer syntax if that makes somebody feel better
[13:50:17] <jepler> I can fix his other compile error too
[13:50:29] <jepler> I don't have the relevant systems handy to test on, but yay buildbot
[13:51:37] <jepler> Fn shall have a decay type which is move-constructible from fn.
[13:51:41] <jepler> ^^^ this is the real reason to prefer C
[13:51:55] <jepler> it's like C++ is radioactive
[13:53:33] <cradek> and also I have no idea what that means
[13:54:04] <jepler> I don't either
[13:54:10] <jepler> I think it's like radioactivity
[13:56:11] <KGB-linuxcnc> 03jepler 05jepler/static-ftbfs bbf90da 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * interp: fix interpretation of ambiguous "bind"
[14:03:50] <linuxcnc-build> build #1381 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1381 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:04:44] <linuxcnc-build> build #1379 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1379 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:04:48] <linuxcnc-build> build #1376 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1376 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:33:35] <linuxcnc-build> build #1374 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1374 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:37:12] <KGB-linuxcnc> 03jepler 05master bbf90da 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * interp: fix interpretation of ambiguous "bind"
[15:37:42] <mhaberler> ha
[15:38:55] <jepler> mhaberler: are any of those arrays or aggregates in _setup non-POD?
[15:39:32] <jepler> I am tempted to just change the use of the new-style initializers to memset(0) but didn't investigate this question yet
[15:40:07] <mhaberler> probably - a lot of editing
[15:40:46] <jepler> it looks like they are
[15:41:36] <jepler> well uh oh
[15:41:41] <mhaberler> the one I wasnt sure about was how to init arrays which contain a struct with non-POD data
[15:41:48] <jepler> you *already* memset(blocks, 0, sizeof(blocks))
[15:41:58] <jepler> but unfortunately for you, blocks is a std::set<>
[15:42:10] <mhaberler> yeah, the ones I didnt know better
[15:42:45] <jepler> er, block has a member std::set
[15:43:35] <mhaberler> not sure what to do about it, should we back it out? I'll get around to reworking it only wednesday, I'm busy with the OSADL paper
[15:45:03] <linuxcnc-build> build #1382 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1382 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:45:24] <mhaberler> I missed the buildbot fail in the noise
[15:45:25] <linuxcnc-build> build #1377 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1377 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:45:53] <linuxcnc-build> build #1380 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1380 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:51:12] <jepler> I'll fix it up
[15:51:25] <mhaberler> thanks a lot
[15:51:31] <jepler> you're welcome
[15:51:53] <mhaberler> back out the new cxxflags?
[15:52:32] <jepler> no, but dropping use of the C++11 construct for now
[15:53:12] <mhaberler> ok
[15:54:58] <jepler> and by supplying a zero-args constructor for block_struct
[16:05:08] <KGB-linuxcnc> 03jepler 05jepler/static-ftbfs aa08fad 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * Avoid use of C++11 feature to initialize arrays and aggregates
[16:05:08] <KGB-linuxcnc> 03jepler 05jepler/static-ftbfs 787f893 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp: provide a constructor for block_struct
[16:05:12] <KGB-linuxcnc> 03jepler 05jepler/static-ftbfs d4d4b07 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * interp: rely on zero-arg constructor of setup_struct::blocks
[16:06:03] <jepler> let's see what buildbot thinks of this one
[16:07:15] <mhaberler> sometimes c++ looks like a bad modem line with error correction off to me
[16:10:57] <cradek> I appreciate how you guys can actually fix it, a task which is indistinguishable from magic to me
[16:11:20] <jepler> cradek: remember to take into account that this is about step 8 of "actually fix[ing] it"...
[16:11:58] <cradek> well it's only been a week or two that you two have been working on ... I see your point now
[16:12:19] <mhaberler> there were some offlist iterations to reduce face blush
[16:12:20] <jepler> were you here for the part where we discussed that we weren't even sure what the language standard guaranteed?
[16:13:00] <mhaberler> I had no clue why my variant actually seemed to work, and Jeff couldnt find a justification in the bible
[16:13:25] <cradek> bleh
[16:14:42] <linuxcnc-build> build #1375 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1375 blamelist: Jeff Epler <jepler@unpythonic.net>
[16:15:22] <jepler> [that was the commit that fixed the "bind" issue which still, as expected, failed on hardy -- but it succeeded on lucid so that's good]
[16:15:30] <jepler> [the next one hopefully clears the board, but we won't know for an hour or more]
[16:15:44] <jepler> mhaberler: what are you presenting at OSADL?
[16:16:29] <mhaberler> abort the portable rtapi:
https://www.osadl.org/RTLWS-Submitted-Papers.rtlws15-submitted-papers.0.html
[16:17:18] <mhaberler> I need to fatten the abstract into an actual paper, deadline tomorrow
[16:17:38] <jepler> ah, do good work tonight then.
[16:17:41] <jepler> AFK
[16:17:48] <mhaberler> fighting latex.
[16:17:53] <mhaberler> prefer c++
[16:18:00] <cradek> ouch
[16:18:07] <cradek> \textbf{ouch}
[16:18:36] <mhaberler> textbf...
[16:18:41] <mhaberler> bold I guess?
[16:19:42] <cradek> are you new at latex, or trying to do something advanced?
[16:20:23] <mhaberler> I used some loong ago in academic years
[16:20:43] <mhaberler> nowadays its like the monkeys-on-typewriters approach to textformatting for me
[16:22:26] <cradek> in case you didn't know, [until recently was limited to RTAI and hence x86 platforms] is only true in the very recent past and perhaps not even then
[16:22:55] <mhaberler> because of rtlinux, sure
[16:23:01] <cradek> we primarily used rtlinux in the early years, and there were years of overlap
[16:23:15] <mhaberler> I guess that completely vanished, right?
[16:23:19] <cradek> I'm not sure if it still works
[16:23:29] <cradek> I think it's a commercial product now? they got weird somehow.
[16:24:07] <cradek> I never used it after 2.4-kernel time
[16:24:25] <cradek> bbl
[16:24:38] <mhaberler> cu!
[17:01:29] <jepler> They were bought by a commercial company, the source became hard to maintain and was possibly never released for kernel 2.6, and there was also some kind of patent FUD iirc
[17:02:29] <jepler> the original author apparently patented it; wikipedia points at a patent but doesn't say how it fits into anything. I prefer never to see patents so I didn't click through.
[17:06:01] <jepler> yeah, in 2001 there was patent controversy.
http://www.gnu.org/philosophy/rtlinux-patent.html
[17:08:31] <jepler> by 2007 we didn't care anymore, but they were bought by somebody else and at least for awhile it was unclear whether the status of the patent for gpl software was going to stay the same:
http://lwn.net/Articles/223065/
[17:33:42] <jepler> http://www.youtube.com/watch?v=pH-l7c0BSu0
[18:03:00] <andypugh> I guess that is harder to do than it looks.
[18:06:43] <andypugh> pcw_home: Any updates on Fanuc?
[18:06:44] <archivist> an extension of the servos talking to each other method
[18:18:59] <KGB-linuxcnc> 03jepler 05master aa08fad 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * Avoid use of C++11 feature to initialize arrays and aggregates
[18:18:59] <KGB-linuxcnc> 03jepler 05master 787f893 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp: provide a constructor for block_struct
[18:19:02] <KGB-linuxcnc> 03jepler 05master d4d4b07 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * interp: rely on zero-arg constructor of setup_struct::blocks
[18:28:30] <jepler> it looks like there are about 16 teeth. You probably don't want the misaligned by as much as 5% of a tooth, so you'd better control it to ~.1 degree positional accuracy. A following error of .1 degree at 28800 degree/s is 3.5us of travel or a following error of 3.5um at a 1m/s.
[18:28:35] <jepler> e
[18:28:37] <jepler> so yeah it seems like it would be a challeng
[19:00:36] <cradek_> at constant speed it seems easy (heck just hook them to the same driver)
[19:09:02] <jepler> somebody should try it to see if it's easy or hard
[20:23:27] <kwallace> It looks like the emc.var file doesn't get updated immediately after a work space has been changed. Also, only the active workspace has a link in the Python interface. Is there a good way to get all of the current work offsets?
[21:27:10] <cradek> nope
[21:27:22] <cradek> what are you trying to do?
[21:51:26] <kwallace> cradek: I'm not sure yet, but one scenario is to just have a table that shows all of the offsets. It would be in a tab along with a tab for tool offsets.
[21:52:19] <kwallace> I would think it should update when a change is made to a work space.
[21:53:17] <kwallace> Beyond that, maybe be able to edit the table, or maybe something I haven't thought of yet.
[21:56:44] <kwallace> I may be able to read the emc.var on loading LinuxCNC then track changes to the work spaces in the table as they are made.
[21:57:52] <cradek> I don't know a good way to do what you want.
[21:59:18] <kwallace> Okay, thanks for your time. We'll see how far I can get.
[22:00:23] <cradek> maybe you could put them all in the stat buffer.
[22:01:21] <cradek> I doubt reading or writing the var file as-is will work well
[22:05:15] <kwallace> I assume when LinuxCNC loads emc.var is read, so emc.var and LinuxCNC are in sync at this time. If I copy emc.var to the UI, I should be able to keep the copy in sync by tracking any changes? Or am I missing something?
[22:07:59] <cradek> how do you think you can track changes?
[22:16:02] <cradek> goodnight
[22:16:06] <kwallace> I suppose we will need to make sure we initiate any changes, but I may see what you mean, what if the user opened emc.var with gedit and made changes. Normally, a reload would need to be done. We are tracking other files and have a handler for these events, so maybe we can do something similar. I need to give this a lot more thought.
[22:16:17] <kwallace> Thank you, good night.
[22:17:06] <cradek> you can't control who initiates them - the user doesn't even have to be evil enough to change the file with gedit. his gcode program can call g10 or other codes that cause changes
[22:17:27] <cradek> you can't interpret those
[22:17:42] <cradek> if you must have this feature, you will have to add infrastructure to allow it
[22:19:30] <cradek> please be bold enough to do that - don't hack around it - you simply can't fix everything in the gui
[22:20:04] <kwallace> Okay, food for thought.
[22:20:43] <cradek> now, goodnight for real :-)