#linuxcnc-devel | Logs for 2016-06-17

[00:02:55] <linuxcnc-build_> build #397 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/397 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:05:59] <linuxcnc-build_> build #1303 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1303 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:09:10] <linuxcnc-build_> build #1979 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1979 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:10:03] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 99c7691 06linuxcnc 10src/Makefile xlinuxcnc removal pkging: del app-defaults/XEmc JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=99c7691
[00:11:25] <linuxcnc-build_> build #1268 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1268 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:16:36] <linuxcnc-build_> build #1975 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1975 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:23:08] <linuxcnc-build_> build #646 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/646 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:24:26] <linuxcnc-build_> build #571 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/571 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:31:38] <linuxcnc-build_> build #647 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/647 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:34:26] <linuxcnc-build_> build #570 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/570 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:35:10] <linuxcnc-build_> build #1667 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1667 blamelist: Jeff Epler <jepler@unpythonic.net>
[06:30:31] <KGB-linuxcnc> 03John Thornton 052.7 26c9434 06linuxcnc 10docs/src/getting-started/getting-linuxcnc.txt Docs: add some detail so new users don't have to guess * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=26c9434
[07:07:33] <ikcalB> hey guys, I'm trying to port old sim-preview code, for our new HMI. what about /usr/include/linuxcnc/rs274ngc_interp.hh !? is this file not installed by accident - because it's still available in the sources 'emc/rs274ngc/rs274ngc_interp.hh'
[07:09:51] <ikcalB> what I'm missing, is the class definition for `class Interp: public InterpBase` which is now only `class Interp;` in 'rs274ngc.hh'
[07:17:29] <linuxcnc-build_> build #1270 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1270 blamelist: John Thornton <bjt128@gmail.com>
[07:34:19] <skunkworks_> Dad got the z axis back together and all the wiring hooked back up. I booted up the computer and started linuxcnc.. could not find the mesa card at
[07:34:40] <skunkworks_> went over to it - finally noticed it had the pwr fail led on
[07:34:51] <skunkworks_> replaced the power supply and still power fail..
[07:35:33] <skunkworks_> unplugged the 7i48 - then the 7i80 came up..
[07:36:05] <skunkworks_> started unplugging the encoders from the 7i48 - spindle encoder was causing the short.
[07:37:20] <skunkworks_> pulled the board out - and while we had it out - a piece of greasy carbon was between the + and - of the circuit board.
[07:37:45] <skunkworks_> wire brushed it and everything came back up.
[07:37:47] <skunkworks_> go figure
[07:38:11] <skunkworks_> I think it has been shorted out for at least a few days... Mesa equipment is awesome...
[07:38:43] <ikcalB> kind of solved it, like in gcodemodule.cc: `static InterpBase *pInterp;\#define interp_new (*pInterp)` - still idk whether this is acceptable, as I'm far away from understanding internals yet
[07:38:57] <skunkworks_> (This machine milled electrodes for edms in its previous life)
[07:40:01] <jepler> ikcalB: what version of linuxcnc did you last build against?
[07:42:45] <ikcalB> jepler: where the old HMI successfully built against? finding that out would take a couple of mins - still it was around 2013 (took this project from a collegaue, sry that im so vague)
[07:44:03] <jepler> OK, so this change in what is in our headers may not be recent at all.
[07:46:45] <jepler> anyway it may be as simple as including a new header in the list of headers that are supposed to be installed. However, since this may have silently been broken for as long as 3 years, I think it would also be a good idea to add a test to our automatic tests, to make sure that a program can declare an interpreter object using only our public headers.
[07:48:22] <ikcalB> jepler: tnx for the info, that'd ofc be the final solution.
[07:48:48] <jepler> If you do the work, please make a pull request on github with the needed changes in linuxcnc
[07:49:34] <jepler> if you look at tests/build/ui this is a test which we use to make sure that it is possible to build NML-using software outside of our source tree
[07:50:02] <jepler> I would use that style to write a test to make sure it's possible to build Interp-using software outside our source tree
[07:50:44] <jepler> it will probably have to contain a lot of CANON_CALL_IMPLEMENTATIONS_THAT_DO_NOTHING(...) {}
[07:51:35] <ikcalB> jepler: this is (unfortunately) only a quick-n-dirty fix of very ugly code. I'm planning to write a clean hmi, where I'm surely going to do so, though (not @ my current employer, probably)
[07:53:35] <jepler> I sympathize, it often feels like there's not time to do things "right".
[07:53:54] <jepler> afk
[08:03:36] <ikcalB> tnx for carying, in a nutshell!
[08:03:46] <ikcalB> caring* O.o
[08:19:06] <jepler> ikcalB: I think maybe you need: InterpBase *b = interp_from_shlib("librs274.so");
[08:19:54] <ikcalB> jepler: very well possible. debugging a segfault right now. testing...
[08:23:07] <ikcalB> jepler: i get an undefined reference. (also have got this, after including 'linuxcnc/canon.hh' for using `knot_vector_creator()`) - senior told me, headers & libs out of sync - still I' think I've got something diffrent wrong
[08:23:54] <jepler> that symbol has something to do with NURBS (G5.x codes in linuxcnc)
[08:24:35] <ikcalB> yes. generally speaking: I mean getting undefined references, just because using a non member function.
[08:25:03] <ikcalB> (for the moment i didnt want to bother anyone, we dont use nurbs. just commented out that part of the preview)
[08:28:55] <jepler> yeah it is looking like a rabbit hole from my POV
[08:30:49] <jepler> no, interp_from_shlib("librs274.so") does not work
[08:31:41] <ikcalB> what would i have to link against? the current config (automake, using libtool) does only link: /usr/lib/linuxcnc{.a,ini.so,hal,so,} and /usr/lib/nml.so - is there some lib missing?
[08:33:20] <jepler> gcc uib.cc -I /usr/include/python2.7 -I local/src/linuxcnc/include -L local/src/linuxcnc/lib -lrs274 -Wl,-rpath,`readlink -f local/src/linuxcnc/lib` && ./a.out
[08:33:26] <jepler> this is my little test I am working on
[08:38:58] <ikcalB> wow. thank you for your time. still im unable to follow these undefined refs...
[08:45:22] <jepler> https://emergent.unpythonic.net/files/sandbox/uib.cc -- this works, at least when built against a source directory, after applying a simple patch to define the makeInterp function
[08:46:16] <ikcalB> jepler: very well possible making a noob mistake here: `nm --demangle /usr/lib/lib{linuxcnc,nml}* | grep shlib` does not show this function to be in those libraries!?
[08:50:29] <ikcalB> does this mean, I'd have to build against the source tree - correct?
[08:51:42] <ikcalB> going to try your approach on monday, if you don't mind? should have left already
[09:24:08] <jepler> ikcalB: right, it only works after applying the patch https://emergent.unpythonic.net/files/sandbox/uib.cc
[09:24:13] <jepler> err https://emergent.unpythonic.net/files/sandbox/0001-WIP-rs274-implement-makeInterp-for-external-users-of.patch
[09:25:05] <ikcalB> jepler: got that. mny mny thanks, going to report back!
[10:00:29] <seb_kuzminsky> lol xkcd today
[10:04:02] <jepler> https://emergent.unpythonic.net/files/sandbox/hack-uib.cc is the terrible terrible hacked-up version that works against unmodified 2.7.x
[10:04:57] <seb_kuzminsky> just dont show it to the builbot
[10:05:01] <seb_kuzminsky> my garage will melt
[10:05:02] <seb_kuzminsky> bbl
[10:10:38] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #74: tests: hm2-idrom: exit early when a test fails (062.7...06jepler/2.7/test-hm2-idrom) 02https://github.com/LinuxCNC/linuxcnc/pull/74
[10:13:18] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #75: Jepler/2.7/external rs274 (062.7...06jepler/2.7/external-rs274) 02https://github.com/LinuxCNC/linuxcnc/pull/75
[10:21:16] <skunkworks_> pcw_home, can you thread with a single index with mesa if you tie the index to A and set it count mode to true?
[10:21:42] <jepler> eewh just don't
[10:21:43] <skunkworks_> (not that I am going to say anything - because he does have a 100 line encoder...)
[10:21:59] <skunkworks_> heh
[10:22:12] <KGB-linuxcnc> 03Dewey Garrett 052.7 48ea609 06linuxcnc 10lib/python/pyngcgui.py pyngcgui.py: chk for gcmc if not in ini on 1st use * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48ea609
[10:35:47] <pcw_home> Not currently because the hardware encoder driver does not support interpolated position
[10:36:54] <pcw_home> you can do it with the encoder comp but that likely requires a base thread
[10:39:43] <pcw_home> I guess 1 count/turn threading will work OK if you have a stable spindle speed but seems pretty iffy
[11:03:11] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #74: Missing SOB. 02https://github.com/LinuxCNC/linuxcnc/pull/74#issuecomment-226802814
[11:05:18] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #75: This is welcome in 2.7. Fixing the comment in use-rs274.cc is optional. Merge when ready. 02https://github.com/LinuxCNC/linuxcnc/pull/75#issuecomment-226803386
[11:14:23] <KGB-linuxcnc> 03Jeff Epler 052.7 d564572 06linuxcnc Merge branches 'jepler/2.7/external-rs274' and 'jepler/2.7/test-hm2-idrom' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d564572
[11:15:04] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #75: Jepler/2.7/external rs274 (062.7...06jepler/2.7/external-rs274) 02https://github.com/LinuxCNC/linuxcnc/pull/75
[11:15:18] <KGB-linuxcnc> 03Jeff Epler 05master edfcb03 06linuxcnc 10lib/python/pyngcgui.py 10src/emc/rs274ngc/rs274ngc_pre.cc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=edfcb03
[11:16:10] <seb_kuzminsky> is that our first octopus?
[11:16:22] <jepler> maybe, I don't use them often
[11:16:33] <seb_kuzminsky> right, because you're not crazu
[11:16:44] <jepler> :-P
[11:16:53] <jepler> what's wrong with octopus?
[11:16:58] <jepler> even worse for bisecting than merging?
[11:17:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #76: Consolidate "how to build" docs 02https://github.com/LinuxCNC/linuxcnc/issues/76
[11:17:56] <seb_kuzminsky> more potential for merge conflicts
[11:18:09] <seb_kuzminsky> i bet youre right the bisect gets harder too
[11:20:19] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: @nicokid when you get a chance, please look at #71 where I've fixed the signed-off-by for you. If that looks OK to you, I am prepared to merge it into our master branch. 02https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-226807404
[11:21:56] <jepler> I'm also hoping to hear trasz_ give some comments on those portability PRs I entered
[11:23:39] <jepler> seb_kuzminsky: what do you think about making it possible to have buildbot build a ref that is on an arbitrary github repo?
[11:24:10] <jepler> on the one hand it's clearly an enormous security flaw
[11:26:10] <seb_kuzminsky> yeah, especially since part of our build runs as root
[11:26:15] <seb_kuzminsky> sudo make setuid
[11:26:46] <seb_kuzminsky> i told myself it was ok since only folks with push access to glo could infect my home network
[11:27:05] <seb_kuzminsky> i'd prefer to keep it that way, sorry
[11:27:08] <jepler> I understand
[11:27:16] <seb_kuzminsky> push to glo and i'll build whatever you want
[11:27:40] <seb_kuzminsky> bbl work
[11:28:03] <jepler> if you are lucky and get a thousand spare tuits, maybe you can have a fresh VM instance you spin up for each build where you don't care if some jerkface runs something as root
[11:28:10] <jepler> yeah that too
[13:07:36] <linuxcnc-build_> build #1983 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1983 blamelist: Jeff Epler <jepler@unpythonic.net>
[13:21:15] <JT-Shop> PCW_: on a 7i76e with W2 down and W3 up is the card address like the 7i92?
[13:27:36] <PCW_> Yes
[13:28:27] <PCW_> ( unless you change the to something else )
[13:28:51] <JT-Shop> thanks
[13:31:27] <PCW_> that is, there is a fixed IP address (both jumpers down) and a programmable IP address
[13:31:29] <PCW_> ( jumpers left to right = down,up ) the programmable address is set to when cards are initialized here
[13:33:31] <PCW_> this is the same on all of our Ethernet FPGA cards
[13:35:16] <JT-Shop> Thanks
[14:08:27] <andypugh> I wonder what SET_FEED_REFERENCE does?
[14:10:51] <Tom_itx> i dunno but someone seems to be using it here: https://forum.linuxcnc.org/forum/20-g-code/29866-use-of-step-nc-with-linuxcnc?start=10
[14:11:06] <jepler> it appears that there are two defined values, CANON_XYZ and CANON_WORKPIECE
[14:11:33] <jepler> so it probably has something to do with (not implemented) F-numbers that are about actual movement in space of the controlled point
[14:21:08] <jepler> fwiw in master branch (v2.7.4-513-gedfcb03) configs/sim/axis/canterp.ini does work for me
[14:21:36] <jepler> the sample program it loads configs/sim/axis/canterp_example.can does produce a preview, and also does something when run
[14:22:40] <jepler> so one possibility is that it's broken in the package but not for RIPs
[14:23:13] <jepler> no, hmm, looks like arceye is using a RIP too
[14:25:47] <jepler> but in any case the format has two leading, ignored fields and seems to use space instead of comma for separator
[14:35:53] <andypugh> I ws wondering about useing SET_FEED_REFERENCE to decide which spindle was used in FPR mode. But decided against it.
[14:36:38] <andypugh> I am beginning to wish I hadn’t started, it isn’t like I actually have mutliple spindles, I just wanted to add spindles to the home sequence)
[14:38:44] <andypugh> I am wondering what is special about the D-word. Have you noticed that there is a _flag and a _number for all the spare letters, except for D-words which have d_flag and d_number_float
[14:40:25] <andypugh> Here they are: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_internal.hh#L376
[14:41:38] <andypugh> I am half-tempted to “fix” that
[14:41:53] <jepler> back in 2007....
[14:41:58] <jepler> - int d_number;
[14:41:58] <jepler> + double d_number_float;
[14:41:58] <jepler> + ON_OFF d_flag;
[14:42:22] <jepler> so I am *guessing* that this was somehow my idea of a way to make sure I fixed all sites that expected the d-number to be an integer
[14:42:28] <jepler> since they would all become compile errors
[14:42:40] <andypugh> I guess that the other flags might have been ints back then?
[14:42:53] <jepler> d877ee4 implement G41.1, G42.1 (tool radius compensation with dynamic radius and orentation) change G43 H-1 to G43.1 (tool length compensation with dynamic lengths)
[14:43:23] <andypugh> But that doesn’t really make sense, lots of the numbers are potentially not-int
[14:43:27] <jepler> ON_OFFs seem to have gotten converted to bools in 2010, if that's what you mean
[14:43:55] <andypugh> No, I meant “number” and typed “flag"
[14:43:58] <jepler> oh
[14:45:21] <andypugh> Anyway, it’s not actually a problem, I just got caught out by an assumption.
[14:46:08] <andypugh> There _might_ be an argument for having a _number and _number_float for every letter, parsed from the text file in different ways.
[14:46:40] <andypugh> But as it has so-fat not caused any known bugs, probably not.
[14:46:53] <jepler> I don't mind seeing it renamed for consistency, fwiw
[14:48:07] <andypugh> I will add it to the list. (an actual piece of paper)
[15:17:51] <andypugh> This code is laid out a bit funny: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_cycles.cc#L1090
[15:18:56] <andypugh> I there any reason not to make it look more normal? I am wondering if the lack of line-end ; characters is important to the CYCLE_MACRO in some way?
[15:23:20] <andypugh> Though even that wouldn’t explain the split between settings-> and cycle_p=block->p_number.
[15:23:30] <andypugh> However, an awful lot of the lines look like that.
[15:24:25] <andypugh> (I am only talking about reformatting the bits that I am changing)
[16:11:50] <jepler> I would change CYCLE_MACRO so that it has to be followed by a ;, just as though it were any old statement in C(+))
[16:11:53] <jepler> C(++)
[16:12:41] <andypugh> Ah, right, so it currently can’t be follwed by a ; ?
[16:12:48] <jepler> using the do { ... } while(0) style in the macro just above it in interp_internal.hh
[16:13:30] <andypugh> Given that I put in a whole bunch of ; during my edits, I reckon I will have to do that. THough it compiles.
[16:14:45] <jepler> I'm not sure why what would normally be on the next line has gotten "pulled up" on to the same line as CYCLE_MACRO in so many places
[16:14:51] <jepler> maybe a code-autoformatter gone wild?
[16:15:54] <andypugh> That was my guess
[16:16:13] <andypugh> Will the ; and line breaks I added cause propblems?
[16:16:43] <andypugh> (I would be surprised, but compiler macros have done that before)
[16:17:17] <jepler> I hesitate to say "absolutely not", but I think once you fix the compiler errors probably all will be fine
[16:17:51] <andypugh> The file now compiles without errors or warnings, with my edits.
[16:18:06] <jepler> this is the "why" of do-while-0, if you care: http://stackoverflow.com/questions/257418/do-while-0-what-is-it-good-for/257425#257425
[16:25:36] <andypugh> Sounds like I ought to be OK, as the macro is typically wrapped in a case rathe than single-line if
[16:27:29] <andypugh> So I don’t _think_ that the second(+) parts will fall out of the layer.
[16:36:27] <andypugh> jepler: If you are there, I now have an even more baffling (to me) compile error. I think it is my unfamiliarity with C++
[16:38:10] <jepler> andypugh: I am here
[16:39:58] <andypugh> http://codepad.org/Rj03n0i3
[16:40:40] <andypugh> So, the things I made into arrays cause errors, but things which look the same that were already there, don’t.
[16:41:44] <jepler> the line init_once(0) is the last line of the "initializer list" of setup_struct
[16:42:31] <jepler> so take for example when you changed the member spindle_mode from a single thing to an array of 8
[16:42:38] <jepler> now this initializer doesn't make sense:
[16:42:39] <jepler> spindle_mode(CONSTANT_RPM),
[16:43:27] <andypugh> Right, OK.
[16:43:53] <andypugh> So the initialiser needs to match the layout of the other “thing”
[16:44:12] <andypugh> I almost see it now.
[16:44:27] <jepler_> hm my home network just flaked out
[16:44:45] <jepler_> andypugh: anyway
[16:44:50] <andypugh> Wierd, you joined without leaving
[16:44:58] <jepler_> not sure what I said before I got cut off, but the error is about things in the initializer list of the class
[16:45:14] <andypugh> Yes, I think I see it now.
[16:45:15] <jepler_> my home internet picked that moment to freak out. I'm now connected from some other internet.
[16:46:03] <andypugh> I can copy the format of other array initialisers. (ie, I don’t need to understand it to do it ;-)
[16:46:17] <jepler_> like these
[16:46:18] <jepler_> parameters{},
[16:46:24] <jepler_> that sets it to all "zeros"
[16:46:59] <jepler_> it is lucky for us that CONSTANT_RPM happens to be zero, because it is the first item specified in enum SPINDLE_MODE
[16:47:03] <andypugh> I was interpreting init_once(0) as a function call, I think. C++ syntax has a great capacity to puzzle me. And as for boost::python…
[16:47:31] <jepler_> indeed
[16:48:07] <jepler_> spindle_turning is an interesting case
[16:48:28] <jepler_> it is set to 0 in the initializer list, but the valid values seem to be 1, 2 or 3 (CANON_STOPPED, etc)
[16:48:38] <jepler_> anyway afk, hope this gets you on track again!
[16:48:52] <jepler> oh hey this machine came back. yay.
[16:50:43] <jepler> if you need to fill an array with a non-0 value, you would have to go down to the {} just below init_once and use std::fill
[16:50:55] <jepler> for example
[16:50:55] <jepler> init_once(0)
[16:50:55] <jepler> {
[16:50:55] <jepler> std::fill(active_g_codes, std::end(active_g_codes), 97);// this is nonsense
[16:50:58] <jepler> }
[16:51:41] <jepler> personally I would still leave active_g_code{} in the initializer list
[16:51:44] <andypugh> Luckily for me zero is fine.
[16:52:15] <jepler> you could also write {97,97,/*total of MAX_SPINDLES times*/} but that will NOT be a compile error when MAX_SPINDLES changes, I don't think...
[16:52:22] <andypugh> I wrote this line of code with absolutely no idea what it does, just by copying the one above:
[16:52:25] <andypugh> +typedef pp::array_1_t< EMC_SPINDLE_STAT, EMCMOT_MAX_SPINDLES> spindle_array, (*spindle_w)( EMC_MOTION_STAT &m );
[16:53:05] <jepler> oh yeah, that stuff is nonsense I failed to really decypher either
[16:53:48] <andypugh> I guess a lot of too-clever macro expansions happen to it.
[16:54:28] <jepler> the presence of <> means you should switch from grousing that macros can be hard to understand to grousing that templates are hard to understand :)
[16:54:30] <andypugh> hmm, should I perhaps have defined it as array_2_t ?
[16:55:24] <andypugh> Job1: Make it compile. Job3: Test it.
[16:57:24] <jepler> I thought job 1 was quality
[16:58:02] <andypugh> I survived an ISO9001 audit on tuesday, by being away from my desk.
[16:59:18] <andypugh> We were debating whether ISO9001 was even applicable to our job, which is R&D and therefore much of what we do is done for the first time.
[17:03:26] <jepler> that inspires me to reimagine the ten plagues as taking place in a cubicle farm
[17:03:57] <jepler> you know, Moses went to Management and said: Let my People Go. But the Consultant hardened the Manager's heart.
[17:04:26] <jepler> And so Moses stretched out his hand, and a plague of software defects sprang up, and ate the productivity of the developers who dwelt in the land...
[17:05:15] <andypugh> My supervisor seemed almost serious today when he said “do you want to not bother coming in next week?”
[17:05:21] <jepler> finally, the Angle (sic) of ISO 9001 Compliance visits the land, killing the firstborn project of every software engineer, except those who had decorated the entrance to their cubicle with those irreverent office comics
[17:05:45] <jepler> and then Moses leads the Chosen Developers across the Red Sea to the Promised Startup
[17:06:04] <andypugh> You should probably work on that, it’s got promise
[17:06:15] <jepler> don't tempt me :)
[17:08:06] <andypugh> The car we expected in March, that they started to build in April, finally arrived last Tuesday. It arrived without the keys.
[17:08:40] <andypugh> The keys have been lost en-route from the USA (the car cost at least 200k to build and 10k to ship)
[17:09:10] <andypugh> There are 6 of us in our team, who can not do anything useful without the car. And have been idle since October.
[17:09:19] <jepler> that's awful
[17:09:43] <jepler> picking the lock / bypassing the key can't be that hard can it?
[17:09:44] <andypugh> It’s good for LinuxCNC forum support
[17:10:03] <andypugh> It’s an RFID chip type of key
[17:10:08] <jepler> oh :(
[17:10:30] <jepler> I am old enough that I think a key is an artifact made out of metal, and the important structures are all naked-eye visible
[17:10:57] <andypugh> Tempted to make one of these: http://www.instructables.com/id/A-Universal-RFID-Key/
[17:11:42] <jepler> just hotwire the dang car and get on with your job!
[17:12:25] <andypugh> Unfortunately car security is now so good that even the manucaturers can’t bypass it.
[17:13:21] <andypugh> We _think_ we can make a new key. Or we can replace all the modules with a matched pair and new key. (frankly we don’t care what that costs)
[17:14:14] <jepler> as well you shouldn't
[17:14:44] <andypugh> But we can’t buy more time. We are actually still expected to produce a config to run the next batch/level fo cars by the 27th June. That was pretty tight with a March delivery. Just crazy from here.
[17:15:56] <andypugh> The really depressing part? My employer is doing really well, all the others must be _even_worse_
[17:16:09] <jepler> :-/
[17:16:17] <jepler> that is a sobering thought
[17:16:31] <andypugh> Isn’t it?
[17:16:58] <andypugh> You have to be huge to make cars. And no huge companies work anywhere near efficiently.
[17:17:20] <jepler> I don't think the small ones do necessarily either
[17:17:38] <andypugh> It makes you wonder if manufacturoing, for example, interstellar spacecraft, is even possible.
[17:18:41] <jepler> yeah
[17:18:54] <andypugh> Maybe the organisation big enough to make a Ian M Banks-style GCU would be too big to even manage to make enough coffee for the staff.
[17:19:41] <jepler> sadly I think you're really onto something
[17:19:53] <jepler> that's why to get real space opera we also need post-human AIs
[17:21:26] <andypugh> Who were, of course, the best characters in the Banks novels
[17:22:12] <jepler> so you think it's even worse than: with N people, you can make stuff of complexity log N (say); you think there's a maximum N, and beyond that size organization the total output actually decreases the more people you add?
[17:23:34] <andypugh> I fear that is the case, yes
[17:23:57] <andypugh> Have you worked in a huge organisation?
[17:24:31] <jepler> While I was at university, I was an intern working for a sysadmin in a federal government office
[17:24:49] <andypugh> The problem ends up being finding out who is in charge of the widget that isn’t working in you meta-widget.
[17:25:01] <jepler> I never had the sense that any work was actually occuring, but I attributed that to not understanding the area of work (analysis of ground and surface water something)
[17:25:41] <jepler> actually that's not quite true; once or twice a year some staff actually went into the field and did something, like pouring dye in a river and measuring it 5 miles downstream
[17:27:33] <jepler> well hey by any measure of the word it's quittin' time here
[17:29:17] <jepler> nice talking to you, even if it's about the ultimate limits of human endeavour
[17:31:05] <andypugh> If we can clone enough Elon Musks we may be OK
[23:18:10] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes15 44e2529 06linuxcnc New branch with 457 commits pushed, 10827 files changed, 0344019(+), 0450509(-) since master/edfcb03