Back
[00:16:12] <KGB-linuxcnc> 03jthornton 05master b538aa7 06linuxcnc 10docs/src/examples/mpg.txt
[00:16:12] <KGB-linuxcnc> Docs: fix example code
[00:16:12] <KGB-linuxcnc> Thanks to Tom for spotting this and fixing the example
[00:16:12] <KGB-linuxcnc> Signed-off-by: John Thornton <jthornton@gnipsel.com>
[00:16:23] <KGB-linuxcnc> 03jepler 05master 8c87823 06linuxcnc 10src/po/zh_CN.po * l10n: fix translation of combobox contents
[00:16:30] <KGB-linuxcnc> 03elson 05master ad2a8b7 06linuxcnc 10src/hal/drivers/hal_ppmc.c * add encoder filter clock selection parameter to loadrt command line
[00:16:37] <KGB-linuxcnc> 03elson 05master 241586a 06linuxcnc
[00:16:39] <KGB-linuxcnc> Merge branch 'v2.5_branch' of ssh://jmelson@git.linuxcnc.org/git/emc2 into v2.5_branch
[00:16:48] <KGB-linuxcnc> 03seb 05master c110802 06linuxcnc 10src/ 10hal/drivers/hal_ppmc.c 10po/zh_CN.po * Merge remote-tracking branch 'origin/v2.5_branch'
[01:21:32] <seb_kuzminsky> this is cool: a xenomai kernel that i built using zultron's kernel builder + master-rtos-v0 branch + hm2 firmwares from the buildbot = blinky lights off the 5i20
[01:28:34] <KGB-linuxcnc> 03seb 05master ccf857a 06linuxcnc 10debian/configure * deb: libmodbus-dev is always a build dependency now
[05:10:28] <mhaberler> sourceforge bugtracker: can someone please add me so I can close bugs which I already fixed?
[07:03:12] <jepler> mhaberler: I don't know your sf id
[07:03:22] <jepler> the obvious didn't work
[07:05:17] <jepler> and if they have a user search function I have overlooked it
[09:28:59] <JT-Shop> stepgen is limited to 8, how do you run 9 steppers?
[09:38:21] <cradek> change it to 9 and rebuild?
[09:38:36] <JT-Shop> ok
[09:45:11] <cradek> if you do that and it tests ok, I'd think doing that in master would be smart.
[09:45:29] <cradek> the limit of 8 was surely from before we had 9 axes
[09:45:53] <JT-Shop> I asked for a guy on the forum, but I can test it out this weekend to see
[09:45:54] <cradek> someone probably thought "a few more than the number of axes should be plenty"
[09:46:18] <JT-Shop> did we start with 6 axes?
[09:46:32] <cradek> yes emc2 always had 6 (emc1 had just 3 originally)
[09:55:35] <mhaberler> sourceforge bugtracker: can someone please add me so I can close bugs which I already fixed?
[09:55:42] <cradek> mhaberler: read back
[09:56:13] <mhaberler> my userid is mahsofo
[09:56:51] <jepler> working on it..
[09:56:59] <mhaberler> thanks!
[09:57:31] <mhaberler> I thought I was 'in', did sf change something? the UI looks revamped
[09:57:32] <jepler> I apparently do not understand sf permissions
[09:57:33] <cradek> interestingly it looks like they now gateway both ways between the bug and the email thread
[09:57:36] <jepler> yes they changed something
[09:57:51] <jepler> bear with me
[09:58:16] <cradek> I think they changed everything actually
[10:00:01] <jepler> I found permissions for the tracker but not the documentation that explains what each permission allows
[10:01:06] <jepler> mhaberler: I've tried adding the "update" permission to "developer", please see whether that lets you make the bug change you want to do.
[10:01:18] <mhaberler> ok, will try
[10:03:15] <mhaberler> yep, that worked - closed a bug fixed since 2011
[10:03:18] <mhaberler> thanks!
[10:03:22] <cradek> wheee
[10:09:59] <mhaberler> jepler: thanks to this exception upcall, and threadflavor-specific handling now being possible, RT fault messages become a bit more meaningful - this is an example from the rtmon.comp HAL comp:
http://hastebin.com/kihiwoqoro.sm
[10:10:36] <mhaberler> plus, no compiled in HAL pins
[10:10:56] <mhaberler> (and hal_lib.c need not become a comp)
[10:11:24] <jepler> I didn't take the time to look at the code, but that sounds promising to me.
[10:11:47] <pcw_home> JT-Shop: it might be better to bump the max stepgens to 16 or so (since they are useful for tool changers and other non synchronized motion things) I dont think there is any downside except a bit more allocated memory
[10:12:21] <mhaberler> I'll ask once the branch is cleaned; this is all ontop of the ub already
[10:15:21] <JT-Shop> pcw_home: I don't have enough experiance to know if bumping the max stepgens to 16 will cause a problem. I would much rather pass that off to someone that knows what their doing, but I can give it a try and see if it breaks anything as far as I can tell.
[10:15:57] <JT-Shop> it was not hard for me to find the #define MAX_CHAN 8 line :)
[10:16:19] <pcw_home> I notice PID has 16 max instances
[10:17:31] <JT-Shop> it looks like int step_type[MAX_CHAN] = { -1, -1, -1, -1, -1, -1, -1, -1 }; would need to be changed too
[10:18:10] <JT-Shop> and perhaps this too int user_step_type[MAX_CYCLE] = {-1,-1,-1,-1,-1,-1,-1,-1,-1,-1};
[10:18:12] <jepler> seb had some magic for that
[10:18:15] <jepler> something like
[10:18:16] <jepler> int step_type[MAX_CHAN] = { [0 ... MAX_CHAN] = -1 } ;
[10:18:44] <cradek> except that would be one too many
[10:18:51] <jepler> oh yeah except that
[10:18:56] <jepler> [0 ... (MAX_CHAN-1)] ?
[10:19:00] * cradek shrugs
[10:19:49] <JT-Shop> int step_type[MAX_CHAN] = { [1 ... MAX_CHAN] = -1 } ;
[10:19:54] <JT-Shop> can you skip 0?
[10:20:19] <cradek> heh nope
[10:20:47] <cradek> yay C
[10:23:13] <jepler> I wonder if we should implement rtapi_strtod so that we could pass floats (doubles) as loadrt parameters
[10:25:23] <zultron> seb_kuzminsky, AWESOME! I have to admit I haven't gotten that far. :P
[11:10:57] <cradek> seb_kuzminsky: thanks for responding to EBo about that
[11:17:17] <cradek> zultron: how's your UB work coming? it's been a couple weeks now since fest - do you have an updated estimate for when we could merge it?
[11:18:17] <seb_kuzminsky> ooh, i'm pretty excited about merging whatever we're calling the new rtos branch these days :-)
[11:19:02] <seb_kuzminsky> oh speaking of which, i ran into a problem building rtos-master-v0 last night: 'make -j' failed, but 'make' worked
[11:19:10] <seb_kuzminsky> so there's some dependency tracking that's off
[11:20:20] <cradek> not for the first or last time...
[11:20:47] <jepler> seb_kuzminsky: :( :(
[11:21:48] <cradek> jepler: strikes me that a delta should home like my gantry model (wait for all peers to finish homing phase N before simultaneously starting phase N+1)
[11:22:14] <jepler> unlike the gantry there's no problem if all axes proceed independently
[11:22:18] <jepler> .. within limits I suppose
[11:23:36] <seb_kuzminsky> jepler: are you building/buying a delta 3d printer?
[11:23:59] <jepler> seb_kuzminsky: I am thinking about buying one.
[11:24:16] <seb_kuzminsky> cool
[11:24:30] <jepler> I've been thinking mostly about
http://shop.seemecnc.com/Rostock-MAX-COMPLETE-3D-Printer-Kit-68398.htm
[11:24:46] <seb_kuzminsky> more because it's a nifty robot than because you want to squirty molten plastic, i bet
[11:24:46] <jepler> since I can buy it complete, not buy a set of printed parts and then chase down the remaining 99 items on the BOM
[11:25:02] <cradek> and I'm the one foolish enough to build one instead of buying it
[11:25:56] <seb_kuzminsky> a delta robot 3d printer?
[11:26:11] <seb_kuzminsky> wow, we're all going to end up with linuxcnc 3d printers after seeing charles' cool demo!
[11:26:39] <cradek> well ideally mine'll be a delta robot mill.
[11:27:16] <seb_kuzminsky> like this one?
https://www.youtube.com/watch?v=G_UmhUjZhNo
[11:29:27] <cradek> mine will be based on rotating joints, so will end up with a much smaller work volume
[11:30:06] <seb_kuzminsky> can't wait to see it :-)
[11:30:14] <cradek> um, me too
[11:30:18] <seb_kuzminsky> heh
[11:30:24] <cradek> you know how it is
[11:31:14] <seb_kuzminsky> about those intermittently failing linuxcncrsh tests... i think there's no way for the UI (linuxcncrsh) to know when motion has completed the command that task sent it
[11:31:15] <skunkworks_> with what charles is talking about 'probing' the table to set home.. Could that be done by then setting the corisponding 'joint' lengths or such of the kins?
[11:31:29] <cradek> (it's appealing to me to not have any slidey parts)
[11:31:36] <seb_kuzminsky> the best we can do is poll the motion part of the stat structure and see if the homing happened yet
[11:31:56] <seb_kuzminsky> but that's a giant pain in the ass to do within a shell script that talks to linuxcncrsh via nc :-/
[11:32:05] <cradek> ugh
[11:32:07] <jepler> seb_kuzminsky: yes I fear you're right
[11:32:15] <cradek> are you trying to test linuxcncrsh itself?
[11:32:21] <seb_kuzminsky> so i think the right approach is to not write tests using linuxcncrsh, and instead do it in python like the halui jogging test
[11:32:37] <cradek> yeah, that was going to be my point
[11:32:49] <seb_kuzminsky> i wrote one or two tests to test linuxcncrsh, and then i used linuxcncrsh to test a bunch of other stuff (tool table mainly, iirc)
[11:33:20] <seb_kuzminsky> so i'll try to rewrite the tests soonish
[11:33:33] <jepler> if you were using something like expect, instead of cat|telnet, seems like you could make it work
[11:33:35] <seb_kuzminsky> it's actually a huge relief - writing a custom UI in python is so much nicer than doing it in bash ;-)
[11:33:52] <jepler> but yeah except for testing linuxcncrsh I guess I'd prefer the python solution
[12:10:20] <cradek> jepler: how can I help you finish up the touchy change? do you need a wheel to test with?
[12:11:10] <cradek> oh hey, lunchtime
[12:11:14] <jepler> cradek: mostly I keep forgetting
[12:11:16] <jepler> so it's pinging I need
[12:11:23] <cradek> ok, I can do that too
[12:11:40] <cradek> crontab -e -u jepler
[12:39:08] <IchGuckLive> folks the motion.spindel-speed-out is this positiv negativ i need it always positiv
[12:39:49] <skunkworks_> IchGuckLive, look at abs
[12:40:17] <seb_kuzminsky> yes, look at skunkwork's abs
[12:40:39] <skunkworks_> heh
http://www.linuxcnc.org/docs/2.5/html/man/man9/abs.9.html
[12:40:51] <seb_kuzminsky> oh, that abs... ;-)
[12:40:57] <ssi> lol
[12:41:57] <skunkworks_> seb_kuzminsky, you can look at my abs - I still don't want any of your salty nuts...
[12:42:00] <skunkworks_> ;)
[12:42:28] <seb_kuzminsky> haha
[12:42:39] <IchGuckLive> i got a comp already in plase so igo for *-1
[12:43:01] <skunkworks_> what goes on at the fest - stays at the fest...
[12:44:02] <IchGuckLive> as i need a 6bit RPM manging
[12:44:52] <IchGuckLive> Bit 0 ads 500 RPM B1 1000 B2 2000 B4 4000 B5 8000 B6 16000
[12:45:08] <IchGuckLive> wotks fine
[12:45:34] <IchGuckLive> ok thanks
[12:46:18] <IchGuckLive> first time today as i put a left tool in and M4 and no RPM i got the - at the halmeter
[12:46:41] <IchGuckLive> so done linuxcnc best mach3,4 no way
[12:58:53] <IchGuckLive> one more question on abs.N (requires a floating-point thread)
[12:59:12] <IchGuckLive> dies this mean addf abs.0 floating-point thread
[12:59:26] <IchGuckLive> ??
[13:00:24] <IchGuckLive> in the man9 there shoudt be a example on all the options how to handle most at servo-tread required are missing that
[13:00:41] <IchGuckLive> if it where a short example below it woudt fell of all eys
[13:42:21] <KGB-linuxcnc> 03chris 05v2.5_branch 683c386 06linuxcnc 10tests/interp/ 03oword-bug315/README 03oword-bug315/expected 03oword-bug315/test.ngc 03oword-bug315/test.sh * New test for bug 315 part 1
[13:43:05] <KGB-linuxcnc> 03chris 05master 683c386 06linuxcnc 10tests/interp/ 03oword-bug315/README 03oword-bug315/expected 03oword-bug315/test.ngc 03oword-bug315/test.sh * New test for bug 315 part 1
[13:43:05] <KGB-linuxcnc> 03chris 05master bf7e41a 06linuxcnc * Merge branch 'v2.5_branch'
[14:10:08] <jthornton> well I got 9 stepgen's to work
[14:12:59] <jepler> whee, for linux on 32-bit x86 I think I have a solution to detect improper use of FP in a realtime thread that is marked nofp
[14:13:24] <jepler> (userspace rtapi_app that is)
[14:15:44] <cradek> cool!
[14:16:07] <jepler> now seeing whether anything in the testsuite gets hit
[14:18:20] <jepler> seb_kuzminsky: related to this, I happened to look at abs_s32 and I think it's needlessly using FP (but not tagged as nofp, so in that respect it's fine)
[14:18:36] <jepler> I can't see why you're comparing a s32 with .000001
[14:22:37] <jepler> http://pastebin.com/LXU2nq6m
[14:22:50] <jepler> whee
[15:39:06] <seb_kuzminsky> jepler: wow, that sure looks silly of me
[15:39:26] <seb_kuzminsky> cool fpe catcher, btw
[15:42:04] <linuxcnc-build> build #347 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/347 blamelist: Chris Radek <chris@timeguy.com>
[15:45:05] <seb_kuzminsky> that's expected to fail in master because of a real bug in interp, right?
[15:52:03] <linuxcnc-build> build #1147 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1147 blamelist: Chris Radek <chris@timeguy.com>
[15:55:14] <linuxcnc-build> build #1145 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1145 blamelist: Chris Radek <chris@timeguy.com>
[15:56:14] <linuxcnc-build> build #1149 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1149 blamelist: Chris Radek <chris@timeguy.com>
[16:06:38] <linuxcnc-build> build #1150 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1150 blamelist: Chris Radek <chris@timeguy.com>
[16:14:07] <linuxcnc-build> build #1146 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/1146 blamelist: Chris Radek <chris@timeguy.com>
[16:14:51] <linuxcnc-build> build #1148 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1148 blamelist: Chris Radek <chris@timeguy.com>
[16:16:07] <linuxcnc-build> build #1147 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1147 blamelist: Chris Radek <chris@timeguy.com>
[16:22:06] <linuxcnc-build> build #1146 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1146 blamelist: Chris Radek <chris@timeguy.com>
[16:22:06] <linuxcnc-build> build #1144 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1144 blamelist: Chris Radek <chris@timeguy.com>
[16:27:00] <jepler> seb_kuzminsky: yes, so probably an xfail turd should be dropped in there for now ... ?
[16:31:38] <seb_kuzminsky> i think cradek and maybe mhaberler are actively working on it, so let's wait and see what they want to do
[16:32:04] <seb_kuzminsky> nice thoughtful email re: hal packaging btw
[16:32:44] <seb_kuzminsky> i'm open to finer-grained packaging for 2.6
[16:42:53] <seb_kuzminsky> not sure where the new boundaries would be - is the driver here to get smaller packages for storage constrained systems?
[16:43:41] <seb_kuzminsky> so maybe a base linuxcnc package with few dependencies, and another package that adds all the tcl/tk stuff (and depends on tcl/tk)
[16:49:12] <zultron> cradek, sorry I missed your question this morning.
[16:50:06] <zultron> UB is coming along OK. It seems like it's about two days away from being done, but it's been like that for a week now. :P
[16:50:58] <zultron> I'd say realistically it'll be done in a week.
[16:51:58] <zultron> mhaberler said he tried merging the ub branch onto his -v0 branch and it wasn't too horrible, which brings me great relief....
[16:55:02] <jepler> seb_kuzminsky: I hope you're not the only one to think so
[16:57:33] <seb_kuzminsky> zultron: do you still think ub + rtos-master-v0 are candidates for 2.6?
[16:58:13] <zultron> I think so, yes.
[16:58:19] <seb_kuzminsky> great :-)
[16:58:59] <seb_kuzminsky> i spent a bunch of time at the hackfest looking at rtos-master-v0 and got sort of a feel for it, and i think most of it can go in
[16:59:05] <zultron> I'm at that annoying phase where it's so close I can just taste it.... But then I hit another mini-snag. And then another...
[16:59:47] <seb_kuzminsky> though i'd love to see some of the more egregious stuff cleaned up, but i dont know if that's included in yours and/or michaels plans
[16:59:48] <zultron> Ok, great. I remember you saying something about EMC branding.
[17:00:06] <seb_kuzminsky> yeah there's a web server in there called emcweb, which won't fly
[17:00:25] <seb_kuzminsky> but i'm also thinking of some obvious blooper commits containing merge conflict markers and stuff like that
[17:00:29] <zultron> What's the egregious stuff?
[17:00:36] <zultron> Oh, ok.
[17:01:03] <seb_kuzminsky> as the recent bisect fiasco showed, having unbuildable commits in our history can slow down debugging later
[17:01:10] <zultron> I hope you won't find much of that in my commits, but I'll happily clean mine up.
[17:01:30] <seb_kuzminsky> thanks! i didn't see any of that in the commits with your name on them
[17:01:47] <zultron> Actually, it would be helpful for me to understand what to do in that case.
[17:02:11] <zultron> After cradek's comment about 'git hygiene' I googled around a little bit.
[17:02:21] <seb_kuzminsky> imo a feature branch that's slated for merge into mainline shouldnt have merge commits in it
[17:02:52] <seb_kuzminsky> but i think i may be in a minority on this point (i'm more ocd than most of our peers in terms of vc hygiene)
[17:04:27] <zultron> I don't exactly like the idea of squashing lots commits together, since history is lost. On the other hand, I agree with cradek that each commit should be buildable so that bisecting is useful.
[17:05:15] <zultron> It occurred to me that merging 'chunks' might be a solution, but I haven't experimented, and as you say you have issues with that.
[17:05:29] <zultron> So I'm a bit lost. :)
[17:06:00] <seb_kuzminsky> i'm not proposing squashing all commits into one, because i too love history
[17:06:21] <seb_kuzminsky> i'm advocating a workflow like this:
[17:07:02] <seb_kuzminsky> when a developer is working on a new feature, they should do so on a branch other than master or the release branches (just like you guys did with the rtos work)
[17:07:40] <seb_kuzminsky> when you want to synchronize with the mainline, use 'git fetch && git rebase' instead of 'git pull' or 'git fetch && git merge'
[17:08:16] <seb_kuzminsky> if someone else is working on a feature branch that builds on *your* feature branch, they would fetch your work and rebase --onto your rebased feature branch
[17:08:23] <seb_kuzminsky> that's the workflow, in a nutshell
[17:08:36] <seb_kuzminsky> it has a couple of big benefits over a merge-based workflow
[17:08:54] <zultron> And what about if your branch has commits that are unbuildable? Then cradek will start to fume while bisecting. ;)
[17:09:08] <seb_kuzminsky> one is that you get to continuously re-evaluate early commits in the light of later commits, and clean them up as needed
[17:09:26] <seb_kuzminsky> if an early commit fails to build, you can re-write it to correct the error next time you rebase
[17:09:47] <zultron> Interactive rebase, maybe?
[17:09:55] <zultron> (Just learned about that one)
[17:09:58] <seb_kuzminsky> and if an early commit starts down a path you later determine is wrong, you can drop it, or re-write it so it points in the right direction
[17:10:06] <seb_kuzminsky> yes, this is all "git rebase --interactive"
[17:10:26] <seb_kuzminsky> so that's one benefit: you can make it look like you knew what you were doing all along, and never made any mistakes ;-)
[17:10:48] <zultron> Heh, yeah, I do that already to some degree.
[17:10:50] <seb_kuzminsky> which also has a second benefit: it makes it very easy for reviewers to tell what you did
[17:11:31] <seb_kuzminsky> that's good, i do too, because i'm clumsy and i dont want anyone to notice ;-)
[17:12:26] <seb_kuzminsky> another win with rebase over merge is that when the mainline moves ahead and you use rebase to synchronize, merge conflicts happen in the context of your commit that has the conflict, not in the context of your branch head (if that makes any sense)
[17:12:35] <zultron> Yep. I definitely keep that in mind as I go along. However, I do know that there are places where I started some new thrust and committed unbuildable stuff. It won't be much fun figuring out where those are now. :(
[17:13:06] <seb_kuzminsky> it may be that it's not worth it to clean up at this point, and i'm not going to make a fuss about it
[17:13:36] <seb_kuzminsky> the end result is so awesome and valuable that the bad smell in the history is worth it
[17:13:37] <zultron> I think there aren't many of those, though. cradek wouldn't have to sift around much to find a buildable commit.
[17:13:57] <seb_kuzminsky> or me, or you, or whoever is doing the bisecting ;-)
[17:14:49] <zultron> Yeah, I'm kidding around. I know exactly how he felt earlier.
[17:15:10] <seb_kuzminsky> ok, i'm going to get off my soapbox. i really like the new rtos support and i appreciate all the hard work you've put into making linuxcnc awsomer
[17:15:24] <zultron> Thanks, Seb!
[17:15:57] <seb_kuzminsky> i'm looking forward to a new branch to review & merge :-)
[17:20:17] <zultron> Me too, if I can finally clear the last snags.... ;(
[17:22:07] <seb_kuzminsky> oh! i almost forgot another benefit of rebasing, but something you said up above prodded my memory
[17:22:27] <seb_kuzminsky> you mentioned 'merging chunks'
[17:22:45] <seb_kuzminsky> one thing interactive rebase lets you do is reorder commits
[17:23:36] <seb_kuzminsky> so if you get halfway through your feature and you realize you want to make a little bugfix or a little refactor of master to make your new feature easier, you can commit it, then rebase it to the beginning of your branch, and push just those few commits to master
[17:23:46] <seb_kuzminsky> incremental integration
[17:24:16] <seb_kuzminsky> this is one thing i think we talked about at the hackfest, getting the rtos support into master before ub
[17:25:00] <seb_kuzminsky> ok, back to $DAYJOB for me
[21:39:03] <cradek> I'm not working on fixing that bug 315, I only made the test to help mhaberler
[21:39:35] <cradek> I asked him to share his insights on -devel about which change caused the regression, if he doesn't want to work on it himself.
[21:55:40] <KGB-linuxcnc> 03jepler 05master f980aa4 06linuxcnc 10lib/python/gladevcp/hal_gremlin_plus.py * gladevcp: only 32-bit signed integers are OK here
[22:04:49] <seb_kuzminsky> cradek: ok, that makes sense
[22:38:24] <linuxcnc-build> build #1150 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1150 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:39:10] <linuxcnc-build> build #1151 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1151 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:39:30] <linuxcnc-build> build #1148 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:41:06] <linuxcnc-build> build #1148 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:42:29] <linuxcnc-build> build #1146 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1146 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:43:23] <linuxcnc-build> build #1147 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/1147 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:44:02] <linuxcnc-build> build #1149 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1149 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:44:13] <KGB-linuxcnc> 03jepler 05master 55fec86 06linuxcnc 10src/emc/usr_intf/touchy/listing.py * touchy: allow optional counts argument to scroll operations
[22:44:14] <KGB-linuxcnc> 03jepler 05master 9bf54b3 06linuxcnc 10src/emc/ 10usr_intf/touchy/touchy.glade 10usr_intf/touchy/touchy.py * touchy: allow wheel scrolling of program start point
[22:44:17] <KGB-linuxcnc> 03jepler 05master e8cd18f 06linuxcnc 10src/emc/usr_intf/touchy/touchy.py * Merge branch 'touchy-mpg-scrolling'
[22:44:47] <linuxcnc-build> build #348 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/348 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:46:29] <linuxcnc-build> build #1147 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1147 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:46:30] <linuxcnc-build> build #1145 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1145 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:22:38] <KGB-linuxcnc> 03elson 05v2.5_branch 069894e 06linuxcnc 10docs/src/drivers/pico_ppmc.txt
[23:22:38] <KGB-linuxcnc> 23:08:49 up 15 days, 0 min, 4 users, load average: 0.02, 0.08, 0.09
[23:22:38] <KGB-linuxcnc> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
[23:22:38] <KGB-linuxcnc> elson :-3 - 23Jun13 ?xdm? 4:29m 0.96s /usr/bin/gnome-
[23:22:39] <KGB-linuxcnc> elson pts/1 :0.0 24Jun13 0.00s 55:28 0.29s git commit pico
[23:22:42] <KGB-linuxcnc> elson pts/2 :0.0 26Jun13 22.00s 0.86s 0.03s info vi
[23:22:44] <KGB-linuxcnc> elson pts/3 :0.0 Sun19 25:30m 0.07s 0.07s bash
[23:22:47] <KGB-linuxcnc> Please enter the commit message for your changes. Lines starting
[23:28:11] <linuxcnc-build> build #1151 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1151 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:30:26] <linuxcnc-build> build #1149 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1149 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:31:03] <linuxcnc-build> build #1152 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1152 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:32:02] <linuxcnc-build> build #349 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/349 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:33:59] <linuxcnc-build> build #1148 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:34:01] <linuxcnc-build> build #1147 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1147 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:34:25] <linuxcnc-build> build #1149 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1149 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:35:39] <linuxcnc-build> build #1150 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1150 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:36:16] <linuxcnc-build> build #1148 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/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:36:16] <linuxcnc-build> build #1146 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1146 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:41:10] <KGB-linuxcnc> 03elson 05master 01efc2d 06linuxcnc 10docs/src/drivers/pico_ppmc.txt * describe command line options