Back
[03:21:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 815cd31 06linuxcnc 10src/Makefile install the new axis icons in the deb * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=815cd31
[04:31:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05v2.5_branch 57b9882 06linuxcnc 10(11 files in 7 dirs) tests: rename files so dh_clean doesn't eat them * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=57b9882
[04:31:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 88aafee 06linuxcnc Merge branch 'v2.5_branch' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=88aafee
[09:05:27] <cradek> seb_kuzminsky: thanks for fixing that
[09:07:58] <jepler> seb_kuzminsky: as well as my screwup
[09:08:09] <jepler> I looked at debian/*files but I didn't check the install rule :-/
[09:08:38] <cradek> I sure like that kgb gives the url now
[09:08:43] <jepler> it's convenient
[09:14:28] <skunkworks> I bet most kids now don't know why the KGB is a funny name for something that keeps track
[09:15:00] <skunkworks> Kids these days!
[09:18:40] <archivist> rename it to NSA :)
[09:18:54] <skunkworks> now that isn't funny... ;)
[09:23:00] <archivist> I wonder if they track the term NSA and check every instance
[09:24:00] <cradek> reminds me of M-x spook
[09:24:04] <cradek> wonder if anyone has updated it lately
[09:40:48] <seb_kuzminsky> when we got a netapp filer at the undergraduate computing lab in the early 90s we named it CIA
[09:41:24] <seb_kuzminsky> ugh this conversation is making me feel old
[09:41:33] <skunkworks> heh
[09:41:34] <seb_kuzminsky> well, that, and the fact that i'm getting old
[09:41:46] <skunkworks> we all are...
[09:41:55] <skunkworks> you are not alone...
[09:42:24] <seb_kuzminsky> i'm thinking of adding an item to the agenda that violates our "i propose" srule
[09:42:37] <skunkworks> I demand?
[09:42:50] <seb_kuzminsky> something like "state of the 2.6 release, where we're at, what we need"
[09:42:52] <archivist> you shall
[09:44:23] <seb_kuzminsky> it's all out in the open, on the Todo-2.6 wiki page, but maybe talking about it wouldnt hurt
[09:45:01] <cradek> do you think doing it at the meeting would be better than on the devel list?
[09:45:15] <cradek> (today's the agenda-freeze day)
[09:45:21] <seb_kuzminsky> yeah today's the day
[09:45:39] <cradek> my thumb's on the big red button
[09:45:43] <seb_kuzminsky> i think it might be useful to have regular updates, and the only clock we have is the monthly meeting
[09:45:58] <seb_kuzminsky> but maybe i should just use that clock and not use the meeting
[09:46:18] <archivist> cradek, late in the day not early in the day for freezing methinks
[09:46:33] <cradek> I think I'm on the side of keeping the meeting for propose/vote
[09:47:02] <seb_kuzminsky> that's fair enough
[09:47:04] <skunkworks> I think on the devel list. more people...
[09:47:16] <seb_kuzminsky> ok, i'll send an email and we'll see how it goes
[09:47:18] <cradek> archivist: I've always done it in the (US) morning - I don't think it matters. there's a whole month - there's no reason to race and get something in at the last minute
[09:47:35] <seb_kuzminsky> i dont have much to add, beyond the todo list
[09:52:15] <jepler> cradek: the only reason would be to have the least warning possible, i.e., acting like an asshole
[09:52:22] <cradek> wiki update done, no november meeting
[09:53:51] <cradek> jepler: yes, considering we have the reminder email, I think you're right - I can't think of any other reason to sneak in at the last second.
[09:54:04] * cradek shrugs
[10:22:52] <psha> logger[psha]: .
[10:22:52] <logger[psha]> psha: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2013-11-20.html
[13:09:46] <andypugh> I propose that Seb gives us a project update :-)
[13:38:26] <skunkworks> hmm - took out 2 shorted diodes - jumper 2 open 0 ohm resisstors.. Hard drive spins up and works.
[13:47:17] <cradek> I can sense from here that your backup scheme is inadequate
[13:48:35] <skunkworks> heh
[13:49:13] <skunkworks> yes - we should have an image of every computer... We don't
[13:49:53] <cradek> or an OS that has zfs, or at least does mirroring
[13:50:34] <cradek> what happened to it to burn out the 0 ohm resistors?
[13:50:36] <skunkworks> well - this system - the power supply failed in a not so graceful way. Took out everything
[13:50:41] <cradek> ahh
[13:50:49] <cradek> kablooie
[13:50:54] <cradek> what brand of power supply?
[13:51:12] <skunkworks> yes - don't ever buy black steel power supplies. Every one has failed in that manner
[13:51:26] <cradek> is "black steel" the brand?
[13:51:27] <skunkworks> (and we thought we had gotten rid of them all.)
[13:51:45] <skunkworks> I think so. something from newegg I am sure
[13:54:14] <andypugh> This may be a stupid question, but where would the rtapi_print_msg output in iocontrol.cc end up? That's userspace code isn't it?
[13:54:58] <cradek> what branch? sim or rt?
[13:55:15] <andypugh> rt
[13:55:59] <andypugh> Tha answer appears to be that rtapi_print goes to stdout, and rtapi_print_msg(DEBUG,...) goes nowhere at all.
[13:56:15] <andypugh> (even with debug set to 5)
[13:56:26] <cradek> hmm
[13:57:20] <skunkworks> andypugh, is this xnoamai?
[13:57:32] <andypugh> RTAI
[13:58:26] <jepler> in master branch the debug level setting facility only works on the realtime portion; each userspace process has its own independent idea of the message level
[13:58:30] <skunkworks> then mever mind. (messaging was changed in the unified builds)
[13:58:32] <jepler> for userspace just use printf
[13:59:10] <jepler> yeah, in the new realtime branch messaging is different and I haven't become familiar with the details yet.
[13:59:57] <tjtr33> any news on alex's 'shield' for the BBB?
[14:01:35] <andypugh> I wonder how one sets the debug level for iocontrol.cc ?
[14:01:58] <andypugh> (Not that it matters, I can trivially insert my own. I guess I could even learb gdb ! )
[16:17:07] <andypugh> Hmm, now, should toolchanger randomness be a tool-database property?
[16:19:54] <mhaberler> no, it's a property of a changer, not a tool
[16:20:28] <mhaberler> I would think a particular change has its own properties and methods which are disjoint from a tool
[16:21:03] <mhaberler> a separate first-class object IMO, not dependent on tool instances
[16:29:28] <andypugh> OK, so I will leave it in the only changer we have, iocontrol (very much only for the time being)
[17:00:44] <somenewguy> I noticed in a lot of the example code I have seen ship with linuxcnc, named parameters are not used, almost solely numbers are used
[17:01:00] <somenewguy> is this best practice or a vestigial practice?
[17:01:32] <somenewguy> I ask as I am trying to contribute some improvements and don't want to break things, but would rather use named vars
[17:05:55] <andypugh> named params are new. They have only been there for about 3 years. Many examples are older
[17:09:38] <somenewguy> ok, so it is ok to start including them? while they do look a little out of place as I am not fully updating all vars to be named, it seems silly to intentionally make my code less readable
[17:10:18] <andypugh> No, use them. They are valid now, and they will not become not-valid in the future :-)
[17:10:58] <somenewguy> cool
[17:11:17] <somenewguy> I will submit my "improvements" over the weekend when they are 200% tested
[17:11:24] <somenewguy> all 4 lines of em lol
[17:11:27] <andypugh> Bear in mind that nobody will get your new stuff without also getting the new LinuxCNC at the same time.
[17:12:12] <somenewguy> yeah, but they also wont be lost to annuls of time when I finally lose interest in this stuff/die in a mysterious accident
[17:18:17] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 6a09a8e 06linuxcnc 10src/rtapi/rt-preempt.c rtapi/rt-preempt: use distinct RTAPI module id's in ULAPI * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6a09a8e
[17:18:18] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 d3d4fb8 06linuxcnc 10src/rtapi/rtapi.h 10src/rtapi/rtapi_compat.h rtapi/simple_strtoul(): move to rtapi.h, make visible for UL builds only * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d3d4fb8
[17:18:18] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 27e48d5 06linuxcnc 10src/hal/components/lcd.c components/lcd.c: fix warning about abs() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=27e48d5
[17:34:00] <linuxcnc-build> build #1494 of hardy-amd64-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1494 blamelist: Michael Haberler <git@mah.priv.at>
[17:34:01] <linuxcnc-build> build #1489 of hardy-i386-realtime-rip is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1489 blamelist: Michael Haberler <git@mah.priv.at>
[17:35:18] <linuxcnc-build> build #1492 of hardy-i386-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1492 blamelist: Michael Haberler <git@mah.priv.at>
[18:03:17] <linuxcnc-build> build #1491 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1491 blamelist: Michael Haberler <git@mah.priv.at>
[18:04:25] <linuxcnc-build> build #589 of precise-x86-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/589 blamelist: Michael Haberler <git@mah.priv.at>
[18:04:44] <linuxcnc-build> build #1493 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1493 blamelist: Michael Haberler <git@mah.priv.at>
[18:07:18] <linuxcnc-build> build #573 of precise-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/573 blamelist: Michael Haberler <git@mah.priv.at>
[18:07:25] <linuxcnc-build> build #1490 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1490 blamelist: Michael Haberler <git@mah.priv.at>
[18:07:47] <linuxcnc-build> build #1492 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1492 blamelist: Michael Haberler <git@mah.priv.at>
[18:13:36] <linuxcnc-build> build #1494 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1494 blamelist: Michael Haberler <git@mah.priv.at>
[18:40:25] <andypugh> Hmm, well this is an unhelpful compiler error message:
http://pastebin.com/Dvgt1ZZq
[18:41:21] <andypugh> Ah, no, perhaps the very last line there does refer to a file I have actually changed...
[18:42:57] <andypugh> Though I was assumng that bp::error_already_set was outside my perimiter.