Back
[08:27:57] <jepler> yay, the nice folks at digitalocean let me transfer a bunch of referral credits from my personal account to the linuxcnc.org account. This is the system where we run the forum now, and the credits are enough to keep the lights on for months and months.
[09:28:58] <seb_kuzminsky> yay!!
[09:33:28] <cradek> nifty
[09:51:17] <mozmck> jepler: thinking about your objection to reading hal pins from gcode. what I'm using that for is reading user entered values in the screen from subroutines, and I'm I can't think of a cleaner way to do what I want. One sub basically calls this: G53 G0 X#<_hal[gscreen.loadmat_x-f]> Y#<_hal[gscreen.loadmat_y-f]> The XY values are entered in boxes in the screen and then they just press a button to move to an out-of-the-way location for loading materia
[09:52:33] <mozmck> To do that with motion.analog-in pins would require a lot more code and be less clear IMO
[09:55:49] <jepler> Because you can just use the #<> notation to get the value, not issue a M66, right?
[09:56:40] <jepler> M66 ... / #<x>=#5399 / M66 ... / #<y>=#5399 / G53 G0 ...
[09:57:31] <mozmck> Yes, my current method is one line as well.
[09:57:46] <mozmck> With M66 I would need about 5 right?
[09:58:10] <mozmck> Plus the hal signal connections and all.
[09:58:41] <jepler> but if there were something in #<> notation that read the value from motion.analog-in, doesn't that get at the problem you perceive with M66?
[09:58:54] <mozmck> Is there a way to set parameters from a GUI?
[09:59:12] <jepler> it is an advantage that you would then be able to use HAL signals to decide where the value really comes from
[09:59:17] <mozmck> I suppose it would mostly - I would still need to make hal connections.
[09:59:34] <mozmck> Yes, that could be an advantage instead of "hard-wiring" it
[10:01:22] <cradek> > I copied the whole /usr/lib/firefox-esr tree to /usr/lib/iceweasel
[10:01:41] <cradek> gene sure finds creative ways to make his system not work right
[10:02:03] <jepler> making the iceweasel -> firefox-esr transition in a "stable" debian release was a honking big mistake by debian.
[10:02:04] <lair82> Good Morning Guys, I am wondering if it is possible to work on the operating system of an externally connected SSD using one of these,
http://www.newegg.com/Product/Product.aspx?Item=N82E16817707380, basically go from my mint desktop, and start working in the wheezy environment that is on the ssd, without rebooting into the ssd?
[10:03:16] <jepler> lair82: that is more of a generic debian or linux question, you will probably find better answers in a different venue.
[10:05:14] <lair82> Ok, I was just wondering, I already have the OS installed on the ssd, but I need to make all the other modifications to the system on the ssd, and I thought I was on the user chat, not the dev chat, sorry jepler
[11:07:58] <seb_kuzminsky> mozmck: you want a gui window with text entry fields that lets the user type in the coordinates for the machine to go to, that gets displayed and read from while in the middle of running a gcode program? an interactive gui for a gcode program, if you will?
[11:09:01] <seb_kuzminsky> some folks at the local hackspace really like having gui front-ends for small simple mdi commands (like G53 G0 XYZ), and they implemented that with pyvcp and gladevcp, but of course it's only usable while not running a program
[11:09:37] <mozmck> Yes, that's what I'm doing basically
[11:10:09] <mozmck> I do have a probing subroutine that uses a couple of values from the GUI as well.
[11:10:42] <mozmck> and that subroutine is used in the programs as well as from a button on screen
[11:12:32] <mozmck> F#<_hal[gscreen.toffrate-s]>
[11:12:32] <mozmck> G38.2 Z#<_hal[gscreen.tofflimit-f]> ;Probe Touch-Off
[11:13:54] <mozmck> My thought is that the more of these kinds of things someone wants to do the messier and more work it will be to connect hal signals for all of it.
[11:14:43] <mozmck> If there was a way to set user parameters from the gui that would work just as well though. Named parameters would be great.
[11:16:06] <jepler> you're talking about gcode #<...> "parameters" now, not HAL parameters?
[11:19:53] <jepler> what does the name toffrate-s mean anyhow?
[11:20:52] <jepler> I assume that it means touch off rate, and the suffix -s has something to do with the specifics of the on-screen widget
[11:22:06] <jepler> anyhow, what do you do when a user comes to you and says: I want to have a physical switch that overrides the GUI touch off speed and always performs touch off at F6
[11:22:27] <mozmck> yes, touch-off rate - and the hal_spinbutton makes a pin for signed values and one for floating point.
[11:22:57] <jepler> .. if the value that eventually comes to your F number comes from a motion pin, then you can accomodate this user by changing hal files. You'll add a mux and some net statements
[11:23:20] <mozmck> Well, I would just tell them to enter a different number in the box on screen
[11:23:21] <jepler> .. in your design, it is difficult to accomodate the user request, because you have to go in these part programs and change _hal[gscreen.toffrate-s] to something else
[11:23:55] <mozmck> For this use case I don't think that is an issue, but I can see that it would be for others.
[11:24:30] <jepler> this design means you can't switch something between being a virtual control and a real control without rewriting part programs
[11:24:32] <mozmck> yes, I was talking about gcode parameters
[11:25:00] <jepler> using signals connected to motion pins, you can accomplish changes like that by just changing hal files
[11:25:26] <mozmck> true. I would probably need to change a number of things in the gui to handle that as well though.
[11:26:14] <jepler> sure, in my hypothetical case you would ideally change the GUI so that the spinbox becomes inactive when the switch is the one position
[11:30:57] <mozmck> That's a good point about part programs. I am currently doing the screen stuff in external subroutines which get called from the part programs, so all that has to change is the subroutine.
[11:35:37] <jepler> (or even: take that thing off my screen, one time a guy on the floor typed a number in there and broke a tool)
[11:39:33] <mozmck> For that kind of thing what I probably need is a password protected settings page.
[14:20:18] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #49: @SebKuzminsky, this is looking great. The issue I had was related to the state tags work, so it doesn't apply to LinuxCNC. I really appreciate the fix! 02
https://github.com/LinuxCNC/linuxcnc/issues/49#issuecomment-226579200
[14:56:26] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/posix_timer 706a658 06linuxcnc 10src/rtapi/rtapi_uspace.hh 10src/rtapi/uspace_rtapi_app.cc uspace: let RtapiApp subclasses subclass rtapi_task * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=706a658
[14:56:26] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/posix_timer be8fabd 06linuxcnc 10src/rtapi/rtapi_uspace.hh 10src/rtapi/uspace_rtapi_app.cc uspace: move pthread-specific data to new PosixTask type * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=be8fabd
[14:56:26] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/posix_timer 1f44419 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: use posix timers instead of clock_nanosleep TIMER_ABSTIME * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1f44419
[15:31:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 3b82074 06linuxcnc 10(6 files) add a test to reproduce the preview-strangeness reported by Zultron * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3b82074
[15:31:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 16eec37 06linuxcnc 10(8 files in 2 dirs) add a test of STARTUP_GCODE vs Abort * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=16eec37
[15:31:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 ba334e3 06linuxcnc 04tests/motion-logger/basic/expected.builtin-startup 03tests/motion-logger/basic/expected.builtin-startup.in 10tests/motion-logger/basic/test.sh tests/motion-logger/basic: allow comments in expected files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba334e3
[15:31:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 1b7a523 06linuxcnc 10tests/motion-logger/basic/expected.builtin-startup.in tests/motion-logger/basic: comment 'expected' file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1b7a523
[15:31:50] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 3ad1ea2 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh 10src/emc/rs274ngc/rs274ngc_pre.cc interp: move end-of-program cleanup code to its own function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3ad1ea2
[15:31:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 991984e 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc 10tests/motion-logger/basic/expected.builtin-startup.in 10tests/motion-logger/mountaindew/expected.motion-logger interp: reset Interp and Canon state on Abort * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=991984e
[15:32:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 516deae 06linuxcnc 10src/emc/task/emctaskmain.cc Task: simplify handling of emcCommand * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=516deae
[15:32:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 402c27b 06linuxcnc 10(5 files in 3 dirs) Task: add drain_interp_list * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=402c27b
[15:32:07] <KGB-linuxcnc> 05seb/2.6/task-abort-fix 402c27b 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=402c27b
[15:32:26] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #73: Using POSIX timers instead of clock_nanosleep (06master...06jepler/master/posix_timer) 02
https://github.com/LinuxCNC/linuxcnc/pull/73
[15:32:43] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky closed issue #49: 2.6: abort during startup interrupts startup 02
https://github.com/LinuxCNC/linuxcnc/issues/49
[15:39:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #67: Seb/2.6/task abort fix (062.6...06seb/2.6/task-abort-fix) 02
https://github.com/LinuxCNC/linuxcnc/pull/67
[15:43:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 27bc840 06linuxcnc 10(9 files in 5 dirs) Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=27bc840
[15:47:31] <jepler> seb_kuzminsky: whee
[15:59:01] <skunkworks> now that z is fixed - y sounds loud.. ;0
[16:01:38] <seb_kuzminsky> the squeaky joint gets the grease
[16:16:17] <linuxcnc-build_> build #4217 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/4217 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[16:17:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 f281232 06linuxcnc 10tests/motion-logger/startup-gcode-abort/expected.motion-logger.in update startup-gcode-abort test for the new TP in 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f281232
[16:19:46] <seb_kuzminsky> hmm, that test failure in 2.6 was unexpected
[16:20:23] <seb_kuzminsky> wonder if this is related: task: main loop took 1.361840 seconds
[16:21:44] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 d607a26 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: set_motion_teleop() with update() poll JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d607a26
[16:21:44] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 7236b99 06linuxcnc 10(82 files in 35 dirs) xlinuxcnc gui removal JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7236b99
[16:39:33] <andypugh> How does one use gdb with LinuxCNC? (You might be surprised to find that, so far, I have not used a debugger)
[16:40:10] <andypugh> The info online assumes a single executable file, and LinuxCNC isn’t like that.
[16:47:30] <mozmck> I think there is a wiki page with some info on it.
[16:48:09] <mozmck> Here's the one I was thinking of:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?DebuggingRtapi
[16:48:34] <mozmck> I have seldom used a debugger either, and gdb very little.
[16:49:29] <andypugh> I use the graphical debugger in Excel VBA all the time, and it’s great.
[16:49:56] <andypugh> But with LinuxCNC I have so-far got by with printing to terminal.
[16:50:29] <andypugh> Anyway, I have decided to ignore the question I was investigating for now.
[16:51:28] <seb_kuzminsky> i usually start linuxcnc the normal way, then attach the debugger to the process i want to look into
[16:51:51] <andypugh> You make it sound so easy
[16:52:10] <mozmck> you just have to learn 967 new command line commands :-)
[16:52:22] <seb_kuzminsky> something like: gdb bin/milltask -p $(pidof milltask)
[16:52:38] <seb_kuzminsky> yeah, it's a whole new thing to learn, and it's pretty hairy
[16:52:44] <seb_kuzminsky> i only know like 1% of it
[16:52:48] <andypugh> Also, I am interested in the initialisation sequence, mainly
[16:53:11] <mozmck> that's what I thought every time I tried to use gdb. I usually get farther with print statements.
[16:53:18] <seb_kuzminsky> i can set breakpoints, inspect code & variables, single-step, and uh that's about it
[16:53:59] <andypugh> Well, I was hoping to use the Eclipse debugger really, but can’t persuade Eclipse to even compile linuxCNC
[16:54:19] <seb_kuzminsky> oh, the other handy thing you can do is attach a debugger and then cause it to crash, and gdb lets you inspect the place where it crashed
[16:54:40] <mozmck> I can do a compile in Eclipse, but have not tried debugging.
[16:54:41] <seb_kuzminsky> that's super handy - looking at the code that faulted and the variables set at the time often takes you right to the bug
[16:55:12] <andypugh> On a system that compiles just fine with “make” the Eclipse “build-all” fails with “can’t find rtapi_mutex.h"
[16:56:07] <mozmck> Hmm, I may just have Eclipse run make
[16:56:18] <jepler> what unix command does Eclipse "build-all", and what directory does it invoke it in?
[16:56:40] <andypugh> Some info here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Eclipse
[16:57:00] <andypugh> I may need to work through it carefully and not just think “done that”
[16:57:26] <jepler> I notice that advice is 4 years old, so it may need some tlc before it'll work
[16:58:11] <jepler> ... remove "all" from "Build(Incremental build)"
[16:58:20] <jepler> this is important, because we do not have a "make" target called "all"
[16:58:43] <jepler> ... In the next Tab: Set debugger command from "gdb" to "sudo gdb"
[16:59:26] <jepler> this advice may have worked at the time, but I don't think it will now. If you aren't debugging hardware drivers, then skip 'sudo make setuid' and don't try to 'sudo gdb' either
[17:01:39] <jepler> (hm it might work for 'attach to existing process')
[17:02:11] <andypugh> Yeah, it’s besically hard advice to follow as all the tabs and setting in Eclipse are different now
[17:02:36] <andypugh> For example, it does not seem to be possible to change the Build Directory
[17:04:05] <seb_kuzminsky> vim4lyfe
[17:04:07] <mozmck> I'm using the latest Eclipse, and under C/C++ Build, I have "Use default build command" checked, but un-check "Generate Makefiles automatically"
[17:04:26] <seb_kuzminsky> andypugh: can you make the build command "cd src; make"?
[17:04:38] <mozmck> That enables the "Build directory" setting.
[17:05:06] <mozmck> For "build directory" I have ${workspace_loc:/Linuxcnc/src}
[17:05:21] <andypugh> mozmck: Aha! That makes the Build Directory editable
[17:05:27] <mozmck> Linuxcnc would be replaced with whatever you named the project
[17:05:33] <mozmck> yep!
[17:05:47] <andypugh> And it seems to be working...
[17:05:57] <mozmck> In the Behavior tab you can enable parallel builds
[17:07:06] <mozmck> I mostly use eclipse for the code reading and finding advantages with linuxcnc
[17:08:04] <andypugh> Yes, just the automatic finding of what sort of “thing” a variable and what its classes and structure members are is invaluable
[17:09:13] <mozmck> Yes, and I found that I can do a C++ search for something like CLASS::member and it will find every instance of that in the project.
[17:10:09] <andypugh> jepler: It fell over with “make: *** No rule to make target `all'. Stop.” just as you predicted.
[17:10:53] <andypugh> Now to find out what the current version of “... remove "all" from "Build(Incremental build)" is
[17:11:39] <mozmck> In mine it is in the Behavior tab
[17:11:53] <mozmck> what version of eclipse are you running? mine is 4.2
[17:12:52] <andypugh> 3.8 :-)
[17:13:13] <mozmck> might be a little different then.
[17:13:24] <andypugh> I downloaded the new version the other day but simply couldn’t get the instlaller to run and gave up
[17:13:34] <andypugh> But yes, it was in “Behaviour”
[17:13:57] <mozmck> is this on a Mac? On linux I just unzip it and it's "installed"
[17:14:13] <andypugh> No, Linux (runing in a VM on my Mac)
[17:14:20] <mozmck> huh
[17:14:56] <mozmck> eclipse is quite handy, and sometimes quite annoying at the same time.
[17:16:16] <andypugh> Ah, yes, I remember now: I stalled at “Version 1.6.0_35 of the JVM is not suitable for this product. Version: 1.7 or greater is required"
[17:16:20] <mozmck> 4.x now finally has a way to save preferences across workspaces, but instead of making certain things system preferences as should have been done, they made an elaborate system to record and copy preferences across workspaces.
[17:16:55] <mozmck> I see. I use the webupd8team ppa to get the latest java. I run Mint on my dev machine.
[17:17:27] <andypugh> Synaptic seemes to know very little about JVM
[17:17:41] <mozmck> is that a wheezy VM
[17:17:43] <mozmck> ?
[17:19:50] <andypugh> Yes
[17:21:16] <andypugh> Anyway, back to hacking. Currently num_joints is pulled out of the [KINS]JOINTS INI section. Where would be a sensible place to keep num_spindles? I was expecting it to propagate up from the motion modparam (assuming that num_joints did).
[17:21:20] <mozmck> look for openjdk. I don't know if they will have a newer one there or not.
[17:22:16] <andypugh> But rather than re-invent that particular wheel, I will pull num_soindles out of the INI for the time being. But where would it belong?
[17:22:38] <andypugh> [KINS]? [TRAJ]?
[17:22:39] <mozmck> I would think the ini file is the best place for system setup like that.
[17:23:01] <andypugh> mozmck: Except that not all configs have an INI file.
[17:23:13] <mozmck> oh?
[17:23:29] <mozmck> I didn't know that was possible.
[17:23:32] <andypugh> It’s perfectly possible to have a HAL-only system.
[17:23:47] <andypugh> Not necessarily one that runs motmod, I haven’t tried.
[17:23:57] <mozmck> I see, but then that would not be running a typical machine would it?
[17:24:35] <andypugh> No, but I try not to assume.
[17:24:53] <mozmck> true.
[17:25:30] <andypugh> Anyway, motion (in my dev branch) now takes a num_spindles modparam, and for the time-being I am just going to require that it matches the INI value
[17:26:46] <andypugh> It can live in [TRAJ] I think. Not the perfect home, but it will do.
[17:26:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 9509874 06linuxcnc 10(8 files in 6 dirs) Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9509874
[17:33:38] <linuxcnc-build_> build #4230 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4230 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:38:22] <KGB-linuxcnc> 03Jeff Epler 05joints_axes14 0352f59 06linuxcnc 10debian/control.in packaging: remove deps related to removed UIs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0352f59
[18:46:12] <dgarr> mozmck: a quick example using an mcode file and m66 to interactively set gcode readable values, might be a starting point, see the README
[18:46:14] <dgarr> http://www.panix.com/~dgarrett/stuff/usem66.tar
[18:48:37] <mozmck> Hi dgarr, thanks.
[18:49:51] <mozmck> I haven't parsed it all yet, but how is it different than connected an entry box's hal pin to motion.analog-in-NN and using M66 to read that?
[18:54:29] <mozmck> dgarr: that looks basically like what I'm doing in one subroutine. I can do this, but if I need to keep adding more then I may wind up with a lot of motion input pins, and M66 to read them all.
[18:55:50] <dgarr> the example only uses 1 motion pin -- it is just used over and over again
[18:56:32] <mozmck> oh! I'll have to convert the ini file so I can run it. thanks again for the example.
[19:08:51] <jepler> linuxcnc-build_: force build --branch=2.6 0000.checkin
[19:08:57] <linuxcnc-build_> The build has been queued, I'll give a shout when it starts
[19:16:03] <dgarr> mozmck: a version that runs on 2.7.x:
http://www.panix.com/~dgarrett/stuff/usem66_2.7.tar
[19:48:12] <linuxcnc-build_> build #2378 of 1400.rip-wheezy-i386 is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2378 blamelist: Jeff Epler <jepler@unpythonic.net>, Dewey Garrett <dgarrett@panix.com>
[19:53:04] <jepler> hm
[19:57:24] <KGB-linuxcnc> 03Jeff Epler 05joints_axes14 6e93f70 06linuxcnc 10debian/control.in packaging: Removing libXaw stopped indirectly depending on libXmu * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6e93f70
[20:15:19] <linuxcnc-build_> build #4232 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4232 blamelist: Jeff Epler <jepler@unpythonic.net>, Dewey Garrett <dgarrett@panix.com>
[20:17:57] <mozmck> dgarr: thanks!
[20:43:10] <linuxcnc-build_> build #2379 of 1400.rip-wheezy-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2379 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:51:06] <linuxcnc-build_> build #4233 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4233 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:51:06] <linuxcnc-build_> build forced [ETA 1h08m51s]
[20:51:07] <linuxcnc-build_> I'll give a shout when the build finishes
[21:50:06] <seb_kuzminsky> master passes for me on wheezy/uspace
[21:50:14] <seb_kuzminsky> glitchy fucking buildbot
[22:03:09] <jepler> at $DAY_JOB I fixed a weird event-driven-hell problem that has been irritating our automated tests for years, then looked in our collection of externally-generated crash reports and found out it's been eating user data all this time too.
[22:03:41] <jepler> (a 'please wait' type screen pops up, reenters the event loop before it's fully initialized, and then can in rare circumstances try to dismiss itself in this state)
[22:07:29] <linuxcnc-build_> Hey! build 0000.checkin #4234 is complete: Success [3build successful]
[22:07:40] <linuxcnc-build_> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4234
[22:07:42] <linuxcnc-build_> build #396 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/396
[22:14:25] <jepler> it's not your night
[22:14:42] <jepler> linuxcnc-build_: go home, you've overheated
[23:24:57] <linuxcnc-build_> build #3407 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/3407 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:37:39] <linuxcnc-build_> build #3407 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3407 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:40:04] <linuxcnc-build_> build #2235 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/2235 blamelist: Jeff Epler <jepler@unpythonic.net>