Back
[01:19:36] <cradek> jepler: you ought to set DEBEMAIL in your environment
[01:35:16] <jepler> cradek: I guess so
[01:46:07] <jmkasunich> hmm... if an incremental build fails, should I force the next one to be a full build? (with make clean)
[01:48:16] <jmkasunich> if an incremental build fails, it might even make sense to force an immediate full build, without waiting for another commit
[01:50:23] <cradek> that's tough - it depends what caused the failure. sometimes we have to make clean, especially after adding/removing files etc.
[01:51:18] <cradek> maybe you have to think about what exactly you want the compile farm to test
[01:52:03] <jmkasunich> what I don't want it to do is thrash my machine for 2 hours after somebody commits a change to a commit or a deb file or a py script that doesn't even get compiled
[01:52:21] <cradek> or ten changes
[01:52:31] <jmkasunich> ten at once isn't so bad
[01:52:42] <cradek> (maybe you need another machine)
[01:52:49] <jmkasunich> but two separated by 10 minutes will result in twice as much thrashing
[01:52:52] <cradek> moving all the VMs would be easy
[01:53:05] <jmkasunich> you want to give me a fast box?
[01:53:16] <jmkasunich> thats not the answer anyway
[01:53:23] <cradek> ok, just a thought
[01:53:36] <cradek> wouldn't have to be that fast, but it would sure need ram
[01:53:36] <jmkasunich> waiting for 2 hours for the damn thing to build isn't good anyway
[01:54:19] <jmkasunich> the incremental builds are good I think - that should really knock down the time needed to get results
[01:54:47] <jmkasunich> even better would be a way to stagger the running of the vms, but that would be much more involved than I want to mess with right now
[01:55:01] <jmkasunich> I'm already nested three levels deep
[01:55:12] <jmkasunich> 1) testing gecko/stepgen interaction
[01:55:17] <jmkasunich> 2) fixing a halscope bug
[01:55:34] <jmkasunich> 3) fixing the farm so when I commit (2) it won't thrash for 2 hours
[01:55:57] <cradek> what's #2?
[01:56:21] <jmkasunich> trigger level is messed up when using offset on the channel you are triggering on
[01:56:36] <jmkasunich> 95% sure its a - where there should be a +, change made
[01:56:39] <cradek> I'm only two deep: 1) G76, 2) get emacs to indent C code right
[01:56:52] <jmkasunich> haven't tested yet, got into the farm stuff while it was building
[01:57:00] <cradek> cool
[01:57:19] <cradek> it would be nice to fix the display bug one of these days too (retrace lines)
[01:57:34] <jepler> I was looking at the extra horizontal lines and I didn't see any problem
[01:57:36] <cradek> needs a new damper tube, haha
[01:57:37] <jepler> it needs eyes that aren't mine
[01:58:10] <cradek> I might try it if I'm still interested after a couple stack pops
[01:58:14] <jmkasunich> cradek: what retrace lines?
[01:58:42] <jepler> jmkasunich: sometimes in halscope there are spurious horizontal lines across the whole display area, one for each trace shown
[01:58:43] <cradek> um, sometimes it doesn't "blank" when the "beam" goes back to the left side
[01:58:57] <jmkasunich> don't recall seeing that
[01:59:11] <cradek> interesting - I see it frequently
[01:59:19] <jmkasunich> I just recall seeing weird flickering and such if the mouse is in the display area
[01:59:25] <cradek> hope it's not gtk-version-specific
[01:59:30] <jmkasunich> (or something - I don't trust my memory)
[01:59:33] <jepler> we probably all have the same gtk version
[01:59:45] <jepler> it used to flicker badly, I added double-buffering for gtk2 only
[02:00:13] <cradek> jmkasunich: do you have antialiased fonts on halscope?
[02:00:23] <jmkasunich> damfino
[02:00:45] <cradek> that's the easy to spot gtk2 change
[02:01:21] <jmkasunich> when I pop stack once and get back to halscope I'll look at a few things
[02:01:30] <jmkasunich> gotta get this farm thing right tho
[02:03:06] <jmkasunich> how to treat a failed incremental build is the question
[02:03:37] <jmkasunich> 1) nothing special - next build will also be incremental, unless its been 12 hours since a full build
[02:03:46] <jmkasunich> 2) make the next build full
[02:03:56] <jmkasunich> 3) make the next build full, and start it right away
[02:04:49] <jmkasunich> 3 is bad - if someone sees the first fail message and commits a fix, they'll have to wait for the full build to finish before it will build (again) with their fix
[02:06:07] <jmkasunich> changes that require a make clean aren't common
[21:24:59] <elson> Hello, all!
[21:25:32] <SWPadnos> hi Jon
[21:25:42] <SWPadnos> how's the weather down there?
[21:27:00] <elson> Hi, Steve! Umm, actually warm (relatively) today, 40 F
[21:27:07] <SWPadnos> nice
[21:27:19] <cradek> hi jon
[21:27:32] <SWPadnos> compared to here anyway. it was a balmy "above freezing" for a while yesterday :)
[21:27:39] <elson> I was out there with crane cable and a come-a-long trying to lift a tree back to vertical.
[21:28:00] <SWPadnos> sounds like - um - fun
[21:29:13] <elson> Anyway, seems something may have changed in hal, or something. I have a set of hal files for threading, and now get a "spindle-index-en" already has output pin
[21:29:15] <alex_joni> hi Jon
[21:29:21] <elson> Hello, Alex!
[21:29:40] <SWPadnos> elson, yes, the checking for signals with RW + write pins was made less forgiving
[21:29:47] <SWPadnos> that may be what's getting you
[21:29:52] <jmkasunich> show sig to see what is connected to it
[21:30:07] <elson> OK, maybe I need to post the file and see what I need to do with it.
[21:30:19] <jmkasunich> use halcmd
[21:30:20] <SWPadnos> http://pastebin.ca
[21:30:42] <elson> John, it is a bidirectional signal. I am trying to connect an out to it.
[21:30:48] <jmkasunich> can't do that
[21:31:29] <jmkasunich> thats equivalent to hooking the output of a 7400 to a tri-state bus where everything else on the bus is a 74245 or the like
[21:31:44] <jmkasunich> what out are you trying to hook to it?
[21:31:48] <SWPadnos> out as in "let's indicate to the world what the signal state is" or out as in "some-component.output-pin"? ...
[21:33:12] <cradek> elson: see #12:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?UPDATING
[21:33:23] <elson> OK, here is the operative snippet
http://www.pastebin.ca/362502
[21:34:06] <SWPadnos> heh - interesting problem :)
[21:34:41] <SWPadnos> why do you need to use the not? if it's just a matter of inverting a bit for the hardware, the driver can do it
[21:34:42] <elson> Yeah, really. The design of the encoder index function requires something like this.
[21:35:01] <cradek> everyone, read my link please
[21:35:06] <jmkasunich> read #12 on that link...
[21:35:12] <cradek> the changes required for 2.1 are carefully documented on that UPDATING page
[21:35:36] <jmkasunich> the not block was a hack, and is no longer needed
[21:35:53] <SWPadnos> is that document part of the .debs?
[21:36:08] <cradek> yes
[21:36:09] <SWPadnos> there should be a readme / updating link in the EMC2 menu
[21:36:09] <SWPadnos> ok
[21:36:13] <elson> OK, I agree this whole arrangement DID feel like a hack.
[21:41:24] <jmkasunich> http://www.youtube.com/watch?v=I_NwAU3mdO8
[21:42:28] <jmkasunich> oops, wrong channel
[21:43:55] <elson> Thanks for the pointer to the new docs, Chris! I'll check it out.
[21:48:32] <cradek> welcome
[21:58:42] <elson> Ahh, not only does it work, it appears to work BETTER than before!
[21:58:57] <SWPadnos> good deal!
[21:59:03] <cradek> better how?
[21:59:32] <elson> It sometimes took a while to sync up to the spindle (missed revs) not it seems to hit it every time.
[21:59:45] <elson> --now it seems...
[21:59:47] <cradek> huh, strange
[22:00:14] <SWPadnos> I wonder if the function order for the thread the 'not' is in was wrong ...
[22:00:33] <cradek> well I'm glad it works - jmk made me change it extensively a few days before 2.1.0...
[22:01:43] <cradek> there was a bug the old way that nobody ever noticed - if you happened to start waiting for index at count=0, it would have never triggered
[22:03:14] <cradek> it's funny the unnoticed bugs you sometimes know about, when you wrote it
[22:04:46] <cradek> elson: if you're threading, it would be great if you could test the new g76 features for me - I fixed them up just yesterday
[22:05:07] <cradek> I haven't tried them on a real machine yet
[22:40:37] <jmkasunich> cradek: not words to inspire confidence
[22:41:10] <alex_joni> heh
[22:41:18] <alex_joni> it "should" work though
[22:41:52] <jmkasunich> well I managed to bork something
[22:42:25] <jmkasunich> doing some HAL stuff, halrun printed a segfault message, and now I can't unload hal_lib