Back
[00:55:03] <mhaberler> well sure. the source to overview.eps wasnt lost, it was a .dia file sitting right in the paper directory. Duh.
[01:00:51] <mhaberler> jepler: I am all for merging jepler/c99, since it's flags cleanup season ;) btw I think BITOPS_DEFINE isnt used in the code anymore
[08:41:09] <KGB-linuxcnc> 03jepler 05master 92ce7f7 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c * axis: Don't directly use trp->result
[08:41:10] <KGB-linuxcnc> 03jepler 05master 37c70c2 06linuxcnc 10src/emc/usr_intf/emcsh.cc * emcsh: don't directly write to interp->result
[09:13:18] <mhaberler> hi jepler! around?
[09:14:02] <mhaberler> jepler/c99 would be great to get merged; BITOPS_DEFINE is unused now btw
[11:05:37] <jepler_> mhaberler: that branch led to weird link errors that I don't understand at all, so it's not suitable for pushing to master.
[11:05:41] <jepler_> http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1373/steps/compile/logs/stdio
[11:05:48] <jepler_> ../lib/liblinuxcnchal.so.0: undefined reference to `pthread_attr_setstacksize'
[11:05:51] <jepler_> ../lib/liblinuxcnchal.so.0: undefined reference to `pthread_create'
[11:05:53] <jepler_> ../lib/liblinuxcnchal.so.0: undefined reference to `pthread_join'
[11:05:56] <jepler_> collect2: ld returned 1 exit status
[11:05:58] <jepler_> ^^^ e.g.,
[11:06:44] <jepler_> there was another build error on hardy, but at least I understand what that one was about (makefile quoting that was ok for CC=gcc but wrong for CC=gcc -std=c99)
[11:09:02] <jepler_> this is master branch targeting rtai, so I don't have the slightest idea why liblinuxcnchal would end up referring to pthread functions
[11:13:34] <kwallace> cradek: It looks like we had a patch that got the work offsets out of interp-convert, which will likely get dusted off again. Apparently, Mach has a table with editable real time offsets, so it must be possible.
[11:21:06] <jepler_> yes, enabling -std=c99 causes objects/rtapi/rtai_ulapi.o to refer to pthread identifiers when it didn't before
[11:22:52] <jepler_> .. because it changes the semantics of "extern inline", and rtai_lxrt.h has extern inlines that refer to pthread_create et al
[11:30:04] <KGB-linuxcnc> 03jepler 05jepler/c99 459a20b 06linuxcnc 10src/ 10Makefile 10configure.in * build: Require C99, and no longer forbid declaration-after-statement
[11:37:57] <linuxcnc-build> build #586 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/586 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[11:40:19] <linuxcnc-build> build #1385 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/1385 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[11:42:16] <jepler> well that didn't work out
[11:43:54] <linuxcnc-build> build #1381 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1381 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[12:08:58] <linuxcnc-build> build #1381 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1381 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[12:09:06] <linuxcnc-build> build #1379 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1379 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[12:23:44] <cradek> dummy
[12:28:04] <kwallace> dummy?
[12:32:18] <kwallace> Oh I see, dummy is on the blame list... dummy.
[12:34:17] <mhaberler> yeah, some RTAI headers are a tarpit
[12:37:21] <mhaberler> possibly inlined but not static math funcs? I had do the full exercise for xeno_math (xenomai-kernel) to remove and userland math.h refs, that was a similar moving target
[12:49:00] <jepler> I think I have a combo that works on lucid/rtai, just rebasing it on master now..
[13:02:15] <mhaberler> re jwp/axis.py: while I got your patch to apply, it is based on master, and axis.py in ja3 already differs a bit, which produced a merge conflict; not sure if I resolved this one properly (the incr jog does work, but the axis selection and jog incr dropdown are grayed out, so likely no); it does emit jog_incrs though - if I can ask you a favor, would you merge that patch onto ja3 or a temp branch?
[13:13:32] <KGB-linuxcnc> 03git 05jepler/c99 8f615e9 06linuxcnc 10src/emc/ 10rs274ngc/interp_array.cc 10rs274ngc/rs274ngc_interp.hh 10rs274ngc/rs274ngc_pre.cc * interp: no more static _setup
[13:13:32] <KGB-linuxcnc> 03git 05jepler/c99 68476fd 06linuxcnc 10src/emc/rs274ngc/interpmodule.cc * interp: adapt exposure of _setup members
[13:13:36] <KGB-linuxcnc> 03git 05jepler/c99 c113e5b 06linuxcnc 10tests/remap/ 10introspect/expected 10introspect/oword.py * tests/interp: adapt remap/introspect
[13:13:43] <KGB-linuxcnc> 03git 05jepler/c99 726527c 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp/setup_struct: add ctor, dtor declaration
[13:13:49] <KGB-linuxcnc> 03git 05jepler/c99 c8ea07d 06linuxcnc 03src/emc/rs274ngc/interp_setup.cc * interp/setup_struct: constructor definition
[13:13:56] <KGB-linuxcnc> 03git 05jepler/c99 87434c2 06linuxcnc 10src/emc/rs274ngc/Submakefile * interp/Submakefile: add interp_setup.cc
[13:14:02] <KGB-linuxcnc> 03git 05jepler/c99 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
[13:14:10] <KGB-linuxcnc> 03jepler 05jepler/c99 bbf90da 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * interp: fix interpretation of ambiguous "bind"
[13:14:17] <KGB-linuxcnc> 03jepler 05jepler/c99 aa08fad 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * Avoid use of C++11 feature to initialize arrays and aggregates
[13:14:22] <KGB-linuxcnc> 03jepler 05jepler/c99 787f893 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp: provide a constructor for block_struct
[13:14:30] <KGB-linuxcnc> 03jepler 05jepler/c99 d4d4b07 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * interp: rely on zero-arg constructor of setup_struct::blocks
[13:14:37] <KGB-linuxcnc> 03jepler 05jepler/c99 92ce7f7 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c * axis: Don't directly use trp->result
[13:14:43] <KGB-linuxcnc> 03jepler 05jepler/c99 37c70c2 06linuxcnc 10src/emc/usr_intf/emcsh.cc * emcsh: don't directly write to interp->result
[13:14:50] <KGB-linuxcnc> 03jepler 05jepler/c99 d410e61 06linuxcnc 10src/Makefile * remove unused BITOPS_DEFINE
[13:14:56] <KGB-linuxcnc> 03jepler 05jepler/c99 47ad5cd 06linuxcnc 10src/Makefile * build: Enable C99, and no longer forbid declaration-after-statement
[13:15:22] <mhaberler> super, thanks
[13:16:24] <jepler> mhaberler: hopefully this time it is golden
[13:16:38] <mhaberler> you got hardy to put up with the change?
[13:17:19] <jepler> It's lucid I've been coddling. Have to find out about hardy from the buildbot
[13:29:17] <mhaberler> finding the cause for a runtests failure in bb output is an art form
[13:58:08] <linuxcnc-build> build #1054 of deb-precise-sim-binary-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-i386/builds/1054 blamelist: dummy, Michael Haberler <git@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>
[13:58:14] <linuxcnc-build> build #1053 of deb-precise-sim-binary-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-amd64/builds/1053 blamelist: dummy, Michael Haberler <git@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>
[14:15:59] <KGB-linuxcnc> 03jepler 05master d410e61 06linuxcnc 10src/Makefile * remove unused BITOPS_DEFINE
[14:15:59] <KGB-linuxcnc> 03jepler 05master 89407af 06linuxcnc 10src/Makefile * build: Enable C99, and no longer forbid declaration-after-statement
[14:25:59] <mhaberler> well I guess I'll merge this into a ubc3-based tmp branch and see what the arm etc builds say to this, usually they are harmless
[14:28:50] <mhaberler> wtf:: -fgnu89-inline ;)
[14:38:07] <cradek> I am against any automatic motion upon pausing, especially if it reintroduces a different kind of jogging/motion based on motion hal pins
[14:39:06] <cradek> IMO it is a solution looking for a problem
[14:39:49] <cradek> I think the simple straight-line-to-resume-point is the only automatic motion we want, since it can't be avoided
[14:45:31] <mhaberler> the automatic motion-on-pause happens only if the pause-offset is non-zero
[14:45:41] <mhaberler> btw not my idea - that was requested on the list;)
[14:45:59] <cradek> well if you read closer he said mach does it but he doesn't use it because it's safer not to
[14:46:00] <mhaberler> I tend to separate those two moves by different offsets, too
[14:46:05] <cradek> that's a pretty weak request
[14:46:27] <cradek> I think we shouldn't copy misfeatures for the sake of having them
[14:46:46] <cradek> it'll be hard enough already when we want to add changing offsets :-/
[14:47:34] <mhaberler> the issue with straight line to resume point was that some want that aligned to an axis to the resume point, even if they arent currently
[14:47:48] <mhaberler> that sounded reasonable eg for mills, resume along z
[14:48:19] <cradek> yes I saw that request
[14:48:34] <cradek> but that's totally different from automatic motion upon pausing
[14:48:34] <mhaberler> how would you say reenter a bore exactly if kbd jogged around?
[14:49:17] <mhaberler> say pause in bore, jog out along z, then jog random x,y
[14:49:26] <mhaberler> how you're going to hit original x y
[14:49:39] <mhaberler> before plunging
[14:49:39] <cradek> I was talking about automatic motion upon pausing
[14:49:45] <mhaberler> oh ok
[14:50:05] <cradek> as far as I can tell, it was never requested
[14:50:13] <cradek> (the other thing you are talking about WAS requested)
[14:50:24] <mhaberler> so the reentry from offset is the one you agree with
[14:51:09] <mhaberler> well fine, its at least one state less, and 11 states is a tad much for my taste anyway
[14:52:11] <cradek> brb
[14:52:14] <mhaberler> sure
[14:55:31] <jepler> $ time git clone --reference linuxcnc git://git.linuxcnc.org/git/linuxcnc.git linuxcnc-clone-of-the-minute
[14:55:34] <jepler> Initialized empty Git repository in /usr/local/jepler/src/linuxcnc-clone-of-the-minute/.git/
[14:55:37] <jepler> real 0m0.986s
[14:55:39] <jepler> wow that's really quite fast
[14:58:59] <cradek> sorry, darn work gets in the way
[14:59:14] <mhaberler> actually I use a script which references several local repos, so I dont have several object trees - reduces disk usage a lot
[14:59:41] <cradek> I'd still rather have simple straight line reentry
[15:00:01] <mhaberler> how would you handle that bore example?
[15:00:29] <cradek> well I'd never jog away from over it, or if I did, I'd jog back
[15:00:29] <mhaberler> (I think that be a rather common situation)
[15:01:07] <mhaberler> how go back, write down position?
[15:01:09] <cradek> moving straight up would be fine for the common situations as I understand them, such as stringer removal
[15:01:23] <mhaberler> right
[15:01:31] <cradek> well it depends why you left the position in the first place. you could use incremental jog to leave it, then also to come back
[15:01:47] <cradek> why would you jog sideways if you needed to reenter from above? can you give me an example?
[15:01:54] <mhaberler> now by accident Joe Chipcutter jogs x instead of z once out of the bore, and there is no way to get back
[15:02:07] <mhaberler> he didnt write down the initial pause x y
[15:02:18] <cradek> meh
[15:02:36] <cradek> abort and restart, I don't care about fixing accidents that clumsy operators make
[15:02:52] <mhaberler> that's the whole point I think; assure its aligned along an axis no matter what happens
[15:02:53] <cradek> your clumsy guy is not going to pull up halcmd and set some pins
[15:03:21] <jepler> the direction of boring or drilling might not be along any axis letter on a 5-axis machine
[15:03:36] <cradek> sure or even on a boring 2 axis lathe
[15:03:40] <cradek> haha "boring"
[15:03:52] <cradek> I'm accidentally punny
[15:03:54] <mhaberler> my route would be to give them a rope to hang themself on if it adds usabiliy in common situations
[15:04:54] <cradek> I think the use case is questionable, and the idea of having a pose offset in hal pins is a poor approach to solving it
[15:05:13] <mhaberler> got a better one?
[15:06:20] <cradek> if you think the use case is important, and I don't, a better solution would be to have an ini? gui? configuration that says which axis to move last and alone, and make the reentry two predictable moves (all but last axis coordinated, then last axis only)
[15:07:07] <mhaberler> I see, interesting idea
[15:07:19] <cradek> an offset is going to be crashy if your hole is deep, and is going to sometimes be invalid depending on how close your workpiece is to the axis limit
[15:07:29] <mhaberler> you basically reserve an axis for the reentry move
[15:07:38] <cradek> yes
[15:07:51] <mhaberler> that sounds a lot cooler
[15:07:54] <cradek> but it'll still be wrong half the time on a lathe, and you really almost always want a diagonal move
[15:08:07] <cradek> otherwise you rub your cutter on something you didn't want to
[15:08:21] <mhaberler> does an axis set address the issue?
[15:08:34] <cradek> axis set?
[15:08:52] <jepler> A set of axis letters like {X,Y,U,V} ?
[15:08:58] <mhaberler> right
[15:09:16] <mhaberler> that would cover diagonal I think
[15:09:28] <cradek> I don't see how that would work
[15:10:26] <mhaberler> well you give a set like {X,Y,U,V} and the first move will be to {X,Y,U,V} of the initial pause positon, the other axes unchanged
[15:10:36] <mhaberler> the reentry move moves the remaining axes
[15:10:36] <cradek> I've seen talk of "save points"
[15:11:04] <cradek> or why not record the jogs and replay them backwards
[15:11:35] <mhaberler> hm, that was exactly what was possible by a HAL usercomp with my original HAL-pin based approach
[15:11:38] <cradek> it comes down to what problem are we trying to solve, and I don't know that
[15:12:26] <mhaberler> basically that approach at pause handed over control to HAL pins, and there you can play any sort of games
[15:12:36] <mhaberler> including recording
[15:12:47] <cradek> I think you should do straight line resume, not make it more complicated, then start working on mdi/touchoff/offset changes because that's the very important use case
[15:13:44] <mhaberler> well I dont mind; I just would ask you to suggest that on the list, I'll confirm that be too ambitious for a first round, done
[15:13:58] <cradek> hm you really could record the jog messages...
[15:14:13] <mhaberler> caveat, we're coming full circle here
[15:14:24] <cradek> it's still a solution looking for a problem, but what a cool solution, haha
[15:14:35] <jepler> the full circle we don't want to come back to is the car with two steering wheels
[15:14:42] <mhaberler> right
[15:14:49] <cradek> oh forget it - it'd be hard or impossible to record wheel jogs
[15:15:31] <mhaberler> you know, I dont think so. the model needs a bit of thinking but it's not out of reach
[15:15:37] <mhaberler> but not for this round
[15:15:49] <mhaberler> and I want to go back to my noNML djihad
[15:16:45] <mhaberler> before, I would like to talk through (not make coding plans yet) how to adress step 1, namely moving offset application to motion
[15:17:53] <mhaberler> the reason why: it could be (I think we were there already) we'll have to limit certain language features, programs modifying offsets on the fly
[15:18:20] <mhaberler> it could help to start with implementing a warning in the interp that a change here is pending, and watch the fallout
[15:18:21] <cradek> nahhh, we just need a design that works with gcode as she is spoke
[15:18:43] <cradek> it's utterly normal for programs to change offsets
[15:19:39] <mhaberler> well fine: if step one is moving offset and rotation application to motion, then lets talk possible fallout
[15:20:00] <mhaberler> would you agree offset application to be the first goal?
[15:20:11] <mhaberler> dia is second IMO
[15:20:12] <cradek> an offset change is always applied during a move, so you never get a step change
[15:20:41] <cradek> dia change in post-processing is a zillion times harder and also unnecessary
[15:21:24] <mhaberler> right, its an easier first step to move offset forward
[15:21:24] <cradek> again, I think the answer to that is to not queue past, and reread the tool table, at every g41/g42
[15:21:45] <cradek> anything else leads to doom
[15:21:57] <mhaberler> new queue busters, hm
[15:22:04] <mhaberler> well why not
[15:22:42] <cradek> andy's work might make the reread step easy/different
[15:22:58] <mhaberler> what is going on there?
[15:23:01] <cradek> just saying I don't think this is a thing we have to worry about for jwp+offsets
[15:23:14] <cradek> I have no idea but he's doing some tool table stuff
[15:23:23] <mhaberler> ok, I'll ask him
[15:23:24] <cradek> arg, work again, brb
[15:23:51] <mhaberler> anyway, can/must offset + rotation applied in one go, meaning both move to motion (I assume yes)?
[15:23:57] <jepler> he wants the tool table to be backed by an arbitrary datastore, possibly via Python and by with a default implementation using a sql database
[15:24:18] <jepler> (by with?)
[15:24:32] <mhaberler> oh
[15:24:59] <mhaberler> that was just a design method, it was thinking about what the API would require
[15:25:38] <mhaberler> I did talk with him about that, and I suggested the relational model for design, without suggesting this be a requirement for a toolstore
[15:25:52] <mhaberler> nb right now the 'table' is -3th normal form ;)
[15:25:59] <mhaberler> -3rd
[15:33:21] <mhaberler> not sure what this means for feedback into canon if required
[15:54:35] <mhaberler> well lets take a step back for a minute; I see two strategies
[15:54:56] <mhaberler> one being: moving bits from canon piecemeal to motion.command-handler
[15:55:40] <mhaberler> second: bite the bullet, make motion.command-handler a userland process, dumb down emccanon.cc completely and move it to that user process
[15:56:52] <mhaberler> it depends on timeframe; 2) is some upfront effort, in particular there is a nasty synchronisation issue I dont have a solution for, but it would make the warp forward and any features thereon a lot easier
[15:57:22] <mhaberler> as a minor bonus, rs274ngc output will match what motion sees
[15:58:59] <cradek> do you think you understand the problem? have you done the experimenting I suggested?
[15:59:37] <mhaberler> I think I did understand the problem
[16:00:33] <mhaberler> once you start moving piecemeal, you have two places where state is kept - canon and motion upper half, and that is an - if not the - issue
[16:01:58] <mhaberler> assume for a minute all bells and whistles of emccanon.cc are in a user process which encompasses motion.command-handler - do you see how this gets around that state syncing problem?
[16:03:24] <cradek> no, not at all
[16:03:34] <cradek> the main offset handling is in the interpreter
[16:03:57] <mhaberler> well first, offset application is where we need it so it can be changed on the fly if needed
[16:04:07] <mhaberler> second, crc is where it can be redone if needed
[16:04:16] <mhaberler> no 'backing up the queue'
[16:04:32] <cradek> I'm not taking those leaps of faith with you
[16:04:58] <mhaberler> I know, we are talking 'in principle'
[16:05:05] <cradek> offset application isn't some atomic thing you can just move around, it's a part of gcode, and I don't think you understand it yet
[16:06:57] <cradek> it's throughout the interpreter, not just at the canon level, because the interp has to know the current position
[16:07:11] <mhaberler> well that is what I mean by possibly restricting language features - I dont think you will get the full flexibility of current rs274ngc while making parts of it runtime changeable
[16:07:55] <cradek> I refuse to start with the assumption that we'll break ngc
[16:08:24] <cradek> sorry, I'm getting fighty, I'm going to take a break
[16:08:36] <mhaberler> I fear the conclusion is that certain decision are to be considered frozen at readahead time
[16:08:42] <mhaberler> sure
[16:08:50] <mhaberler> I know that feeling ;)
[16:11:33] <mhaberler> it's a tradeoff - language flexibility versus ability to change certain state at runtime; you can take any position in this continuum
[16:12:17] <cradek> I don't think we know yet that there is this tradeoff to be made
[16:13:36] <mhaberler> well simple example - disable modification of offsets and rotation at program start; bang, much easier change during pause
[16:14:10] <cradek> sure, but you don't have a control that runs ngc programs anymore
[16:14:33] <cradek> I know there is a design that runs ngc programs and also lets you change offsets during pause
[16:14:44] <cradek> more than one even, I bet :-)
[16:14:56] <mhaberler> maybe opinions vary on that, why do you think this is a must-have-at-all-cost feature?
[16:15:08] <mhaberler> which design are you referring to?
[16:16:07] <mhaberler> btw I will replicate your 'I'm getting fighty, I'll take a break' method, it seems to work ;)
[16:16:08] <cradek> ok, imagine the interpreter is moved into realtime and run just-in-time, one gcode line at a time. that's one design that would let you change offsets (or run any mdi commands) during pause
[16:16:17] <mhaberler> right
[16:16:21] <mhaberler> no readahead
[16:16:35] <mhaberler> so no state syncing issue
[16:16:46] <mhaberler> aka sledgehammer method ;)
[16:16:52] <cradek> so we agree there's at least one working design, haha
[16:16:55] <mhaberler> yes
[16:17:20] <mhaberler> certainly - it is a state syncing issue caused by readahead - kill readahead, issue closed
[16:17:59] <mhaberler> no if you retain readahead, we're talking assumptions on which readahead takes place, and thats where language features come in
[16:18:21] <mhaberler> no/now
[16:18:25] <cradek> (with sadness I realize that design was utterly possible before we had seeking...)
[16:18:45] <mhaberler> yes, big trauma
[16:19:05] <mhaberler> the turing machine is a bitch
[16:20:19] <cradek> sometimes I've been tempted to make the sai into "g2g" that unrolls and simplifies a program (like the STRAIGHT_FEED call would print a simple G1, etc)
[16:20:55] <mhaberler> yes, but that that wont be equivalent because of conditionals based on queue busters
[16:21:07] <mhaberler> probe, read pin etc
[16:21:08] <cradek> that idea combined with your idea of allowing an axis word to be NULL is interesting
[16:21:33] <mhaberler> which idea, jwp axis sets? this is the same thing, yes
[16:21:34] <cradek> yeah you're right, but you could g2g each between-queuebuster segment?
[16:22:02] <jepler> (incidentally I'm lurking over here and after re-thinking what cradek said about non-specified axis words finally makes me see why offsets are not "just" a transformation matrix in which we enforce some of the elements to always be zero)
[16:22:15] <mhaberler> as long as you can assume position prediction in that segment works
[16:23:09] <cradek> you mean the G10 R ... G1 [with not all words] situation?
[16:23:21] <cradek> (which is not peculiar to R; offsets work the same way)
[16:23:22] <mhaberler> (me?)
[16:23:28] <cradek> jepler: ^
[16:23:31] <jepler> cradek: yes
[16:24:25] <cradek> jepler: I think understanding that is really the key to understanding the hard part here
[16:25:18] <mhaberler> jepler: merged master into ubc3, bb, rtai/i386/10.04, rt-preempt/amd64/wheezy builds and runtests fine, much less warnings
[16:25:19] <cradek> perhaps the interpreter being able to issue NULL words in its moves can allow piecemeal application of a new offset, but even that doesn't seem like the full solution
[16:25:48] <cradek> like g1 y1 => STRAIGHT_FEED(NULL, 1, NULL)
[16:26:32] <mhaberler> how does that differ from STRAIGHT_FEED(<currentvalue>, 1, <currentvalue>)
[16:26:57] <cradek> you'd have two offsets then -- the one currently applied to each axis, and the 'candidate' that will be applied as soon as an axis is issued non-NULL
[16:27:51] <cradek> mhaberler: it's different if the offsets change between the previous STRAIGHT_FEED and this one
[16:28:57] <jepler> mhaberler: good
[16:29:13] <mhaberler> yes, very much so, I'll make the merge permanent now
[16:30:15] <mhaberler> great job btw, I mean even considering -fgnu89-inline is a serious leap for me
[16:32:17] <mhaberler> I need to sleep over this NULL thing so I get a chance to understand how this changes the playing field
[16:34:12] <mhaberler> any example sequence sequence how this brings us forward?
[16:55:47] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 ccbef9c 06linuxcnc 10debian/configure * fix tcl/tk version for debian 7.x
[16:55:48] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 00307a5 06linuxcnc 10debian/configure * remove debugging print accidentally committed earlier
[16:55:49] <KGB-linuxcnc> 03git 05unified-build-candidate-3 8f615e9 06linuxcnc 10src/emc/ 10rs274ngc/interp_array.cc 10rs274ngc/rs274ngc_interp.hh 10rs274ngc/rs274ngc_pre.cc * interp: no more static _setup
[16:55:58] <KGB-linuxcnc> 03git 05unified-build-candidate-3 68476fd 06linuxcnc 10src/emc/rs274ngc/interpmodule.cc * interp: adapt exposure of _setup members
[16:56:05] <KGB-linuxcnc> 03git 05unified-build-candidate-3 c113e5b 06linuxcnc 10tests/remap/ 10introspect/expected 10introspect/oword.py * tests/interp: adapt remap/introspect
[16:56:12] <KGB-linuxcnc> 03git 05unified-build-candidate-3 726527c 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp/setup_struct: add ctor, dtor declaration
[16:56:19] <KGB-linuxcnc> 03git 05unified-build-candidate-3 c8ea07d 06linuxcnc 03src/emc/rs274ngc/interp_setup.cc * interp/setup_struct: constructor definition
[16:56:26] <KGB-linuxcnc> 03git 05unified-build-candidate-3 87434c2 06linuxcnc 10src/emc/rs274ngc/Submakefile * interp/Submakefile: add interp_setup.cc
[16:56:32] <KGB-linuxcnc> 03git 05unified-build-candidate-3 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
[16:56:40] <KGB-linuxcnc> 03git 05unified-build-candidate-3 5c51a0b 06linuxcnc 10(5 files in 3 dirs) * Merge remote-tracking branch 'origin/master' into unified-build-candidate-3
[16:56:47] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 bbf90da 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * interp: fix interpretation of ambiguous "bind"
[16:56:56] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 aa08fad 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * Avoid use of C++11 feature to initialize arrays and aggregates
[16:57:01] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 787f893 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp: provide a constructor for block_struct
[16:57:08] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 d4d4b07 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * interp: rely on zero-arg constructor of setup_struct::blocks
[16:57:15] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 92ce7f7 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c * axis: Don't directly use trp->result
[16:57:21] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 37c70c2 06linuxcnc 10src/emc/usr_intf/emcsh.cc * emcsh: don't directly write to interp->result
[16:57:28] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 d410e61 06linuxcnc 10src/Makefile * remove unused BITOPS_DEFINE
[16:57:34] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 89407af 06linuxcnc 10src/Makefile * build: Enable C99, and no longer forbid declaration-after-statement
[16:57:41] <KGB-linuxcnc> 03git 05unified-build-candidate-3 b1fa6b4 06linuxcnc 10src/Makefile * Merge remote-tracking branch 'origin/master' into unified-build-candidate-3
[16:57:48] <KGB-linuxcnc> 03git 05unified-build-candidate-3 901f806 06linuxcnc 10src/rtapi/rtapi_app.cc * rtapi_app: disambiguate bind()
[17:05:30] <andypugh> Reading back: If you _did_ want to record the jog-out move, then would it suffice to record the locus of points where the velocity was zero?
[17:07:00] <linuxcnc-build> build #1389 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1389 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[17:07:08] <linuxcnc-build> build #1384 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1384 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[17:07:15] <linuxcnc-build> build #1387 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1387 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[17:08:13] <andypugh> Secondly, perhaps line-at-atime G-code s something you can fall back to? Much of the time is it hardly any penalty at all. I think what I am saying is that being willing to dump the queue and start again at the slightest provocation might not be the end of the word. Possibly even feed-override can be a queue-recalc.
[17:11:28] <mhaberler> re recording moves: it boils down to 'who records' - some halcomp or the UI, but certainly possible; UI's would need to clue up what to do during a pause - replaying should be possible with incremental jogs if this is what you want
[17:12:06] <mhaberler> that would be quite convenient I'd think
[17:12:28] <mhaberler> it reduces the job within motion which is a plus
[17:12:30] <andypugh> Having said that, if there is a well-documented "final dive to IPP" behaviour, then folk can learn to live with it, I am sure.
[17:13:14] <andypugh> It may be a feature where we need an imperfect implementation to allow people to work out what they need of the perfect implementation.
[17:14:05] <andypugh> With reference to the issue of there not being a straight-line move back into the IPP. If that is the case, then how did they jog out in the first place?
[17:14:11] <mhaberler> actually position recording and UI-based replay is potentially much more flexible than any motion based method
[17:14:20] <mhaberler> right
[17:16:00] <mhaberler> actually record/replay need not even be in the base UI like axis, this could well be say in a gladevcp tab, suit to fit (maybe even the EDM folk)
[17:16:30] <mhaberler> I didnt like the feature accretion in motion anyway
[17:16:49] <mhaberler> because it is always going to be limited and a compromise
[17:18:28] <andypugh> I am not crazy about the move-on-pause thing. (though given that it can be set to zero as the default, and may be something that people think they want, I am OK with it, I think). But if I press "Pause" I expect motion to stop, not something odd to happen.
[17:18:55] <mhaberler> that motion was optional anyway
[17:19:14] <mhaberler> is it safe to assume linear moves between stopped points? I dont see how any other way
[17:19:19] <andypugh> But I just thought of a use-case. I am pretty sure you want to retract the wheel on a grinder if you press pause. You do _not_ want the wheel rolling against the work as it stops.
[17:19:53] <andypugh> It's pretty hard to do curved jogs. I am not saying it is impossible, but it's unusual.
[17:20:21] <mhaberler> actually even if somebody just died to have a retract move on pause, she even could do that because the pause state is exposed in the linuxcnc module
[17:20:33] <andypugh> If you have multiple jog-wheels you can do it. But otherwise you can't
[17:21:24] <mhaberler> I am not sure wheel jogging in motion is a great idea except for low delay
[17:21:48] <mhaberler> its this 'steering with multiple wheels' thing jepler referred to
[17:22:46] <mhaberler> well even if somebody came up with curved jogs - nobody keeps a UI writer from recording samples
[17:23:03] <Tom_itx> put a mixer on it like a model helicopter has for the pitch
[17:23:06] <andypugh> I wonder how much of linuxCNC is in the realtime layers because realtime is the LinuxCNC "Special thing"
[17:23:10] <Tom_itx> then you need a single one
[17:23:56] <mhaberler> whats so special except being a pretty retarded programming environment ;-?
[17:24:29] <mhaberler> I think we should try wheel jog via nml
[17:24:56] <mhaberler> it might be too slow, this is the only downside I can think of
[17:25:26] <mhaberler> but we have a single driving path, and not having that creates issues
[17:25:39] <andypugh> I actually thought it was a a joke. :-)
[17:25:48] <mhaberler> no it isnt
[17:26:01] <mhaberler> a jog wheel is a UI component
[17:26:09] <mhaberler> soft or hard
[17:26:51] <andypugh> It ought to work. If a destination gets delayed, so what? The danger-scenario is getting a destination too far, but that can't happen.
[17:28:47] <mhaberler> yes, I think so too. Now if that comes in time for 2.6 is a different question, but I think it settles the question what is need in motion, which isnt much beyond what is in my jwp branch right now
[17:29:43] <mhaberler> the motion mods certainly can be in time; but the rest can be hinted at by say a gladevcp demo config showing how recording, replay and wheel jog can be done
[17:30:03] <mhaberler> which is fine for a release I think
[17:30:09] <andypugh> loadusr hal_jogwheel. net hal_jogwheel.0.axis-sel multiswitch.0.out
[17:31:03] <andypugh> back in a bit
[17:31:14] <mhaberler> that was a very good idea
[17:46:30] <linuxcnc-build> build #1382 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1382 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[18:16:37] <seb_kuzminsky> linuxcnc-build: force build --branch=master docs
[18:16:37] <linuxcnc-build> build #1064 forced
[18:16:37] <linuxcnc-build> I'll give a shout when the build finishes
[18:31:29] <linuxcnc-build> Hey! build docs #1064 is complete: Warnings [8warnings compile]
[18:31:29] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1064
[18:34:00] <seb_kuzminsky> linuxcnc-build: force build --branch=master docs
[18:34:01] <linuxcnc-build> build #1065 forced
[18:34:01] <linuxcnc-build> I'll give a shout when the build finishes
[18:35:43] <andypugh> This is intersting.
[18:38:33] <andypugh> I have a problem with the SSI driver crashing the system if config goes wrong and it aborts from an unusual state. It's problem with the cleanup code, I guess. The curious thing is that if I insert "FIXME: quitting without cleanup"; return; then it prints the message and quits cleanly. If I have, instead "FIXME: I bet this will crash; (and no return) then it doesn't print the message. But it does crash. Which seem
[18:38:33] <andypugh> tad peculiar.
[18:44:38] <andypugh> I think I have found the problem, but I am puzzled as to why I don't see the printk in the second case.
[18:47:42] <linuxcnc-build> build #1065 of docs is complete: Failure [4failed compile rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1065
[19:57:10] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll c451127 06linuxcnc 10src/hal/drivers/mesa-hostmot2/abs_encoder.c
[19:57:11] <KGB-linuxcnc> Re-order the FPGA reads, error-check the gray-code modifier, suppress spurious start-up errors
[20:33:06] <seb_kuzminsky> linuxcnc-build: force build --branch=master docs
[20:33:07] <linuxcnc-build> build #1066 forced
[20:33:08] <linuxcnc-build> I'll give a shout when the build finishes
[20:49:26] <linuxcnc-build> Hey! build docs #1066 is complete: Warnings [8warnings compile]
[20:49:26] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1066
[21:15:00] <cradek> seb_kuzminsky: that'll sure be cool
[21:18:33] <seb_kuzminsky> cradek: what are we talking about?
[21:20:04] <cradek> auto doc updating
[21:20:28] <seb_kuzminsky> ah yes :-)
[21:20:34] <seb_kuzminsky> http://www.linuxcnc.org/stage-docs/master/v2.6.0-pre0-4769-g89407af/html/
[21:20:45] <seb_kuzminsky> that's rsynced from the buildbot
[21:21:08] <seb_kuzminsky> still needs to be sorted better, and old ones cleaned up, but it shouldnt be hard
[21:21:20] <cradek> mhaberler: the first implementation of jogwheel was nonrealtime in a UI, and it sucked, it wasn't put in motion without both thought and regret
[21:22:13] <cradek> seb_kuzminsky: that's a thing the doc writers will really appreciate, I bet
[21:22:19] <cradek> seb_kuzminsky: thanks for doing the work
[21:23:41] <seb_kuzminsky> jepler used to run a doc builder that built the stuff at w.l.o/docs, but it went away recently(?), so it'll be good to have one back up
[21:24:15] <cradek> push-based is better than polling, anyway
[21:26:12] <seb_kuzminsky> agreed
[21:31:29] <jepler> that's true