jepler: you ought to set DEBEMAIL in your environment
cradek: I guess so
hmm... if an incremental build fails, should I force the next one to be a full build? (with make clean)
if an incremental build fails, it might even make sense to force an immediate full build, without waiting for another commit
that's tough - it depends what caused the failure. sometimes we have to make clean, especially after adding/removing files etc.
maybe you have to think about what exactly you want the compile farm to test
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
or ten changes
ten at once isn't so bad
(maybe you need another machine)
but two separated by 10 minutes will result in twice as much thrashing
moving all the VMs would be easy
you want to give me a fast box?
thats not the answer anyway
ok, just a thought
wouldn't have to be that fast, but it would sure need ram
waiting for 2 hours for the damn thing to build isn't good anyway
the incremental builds are good I think - that should really knock down the time needed to get results
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
I'm already nested three levels deep
1) testing gecko/stepgen interaction
2) fixing a halscope bug
3) fixing the farm so when I commit (2) it won't thrash for 2 hours
trigger level is messed up when using offset on the channel you are triggering on
95% sure its a - where there should be a +, change made
I'm only two deep: 1) G76, 2) get emacs to indent C code right
haven't tested yet, got into the farm stuff while it was building
it would be nice to fix the display bug one of these days too (retrace lines)
I was looking at the extra horizontal lines and I didn't see any problem
needs a new damper tube, haha
it needs eyes that aren't mine
I might try it if I'm still interested after a couple stack pops
cradek: what retrace lines?
jmkasunich: sometimes in halscope there are spurious horizontal lines across the whole display area, one for each trace shown
um, sometimes it doesn't "blank" when the "beam" goes back to the left side
don't recall seeing that
interesting - I see it frequently
I just recall seeing weird flickering and such if the mouse is in the display area
hope it's not gtk-version-specific
(or something - I don't trust my memory)
we probably all have the same gtk version
it used to flicker badly, I added double-buffering for gtk2 only
jmkasunich: do you have antialiased fonts on halscope?
that's the easy to spot gtk2 change
when I pop stack once and get back to halscope I'll look at a few things
gotta get this farm thing right tho
how to treat a failed incremental build is the question
1) nothing special - next build will also be incremental, unless its been 12 hours since a full build
2) make the next build full
3) make the next build full, and start it right away
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
changes that require a make clean aren't common
how's the weather down there?
Hi, Steve! Umm, actually warm (relatively) today, 40 F
compared to here anyway. it was a balmy "above freezing" for a while yesterday :)
I was out there with crane cable and a come-a-long trying to lift a tree back to vertical.
sounds like - um - fun
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
elson, yes, the checking for signals with RW + write pins was made less forgiving
that may be what's getting you
show sig to see what is connected to it
OK, maybe I need to post the file and see what I need to do with it.
[21:30:20] <SWPadnos> http://pastebin.ca
John, it is a bidirectional signal. I am trying to connect an out to it.
can't do that
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
what out are you trying to hook to it?
out as in "let's indicate to the world what the signal state is" or out as in "some-component.output-pin"? ...
elson: see #12: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?UPDATING
OK, here is the operative snippet http://www.pastebin.ca/362502
heh - interesting problem :)
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
Yeah, really. The design of the encoder index function requires something like this.
everyone, read my link please
read #12 on that link...
the changes required for 2.1 are carefully documented on that UPDATING page
the not block was a hack, and is no longer needed
is that document part of the .debs?
there should be a readme / updating link in the EMC2 menu
OK, I agree this whole arrangement DID feel like a hack.
[21:41:24] <jmkasunich> http://www.youtube.com/watch?v=I_NwAU3mdO8
oops, wrong channel
Thanks for the pointer to the new docs, Chris! I'll check it out.
Ahh, not only does it work, it appears to work BETTER than before!
It sometimes took a while to sync up to the spindle (missed revs) not it seems to hit it every time.
--now it seems...
I wonder if the function order for the thread the 'not' is in was wrong ...
well I'm glad it works - jmk made me change it extensively a few days before 2.1.0...
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
it's funny the unnoticed bugs you sometimes know about, when you wrote it
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
I haven't tried them on a real machine yet
cradek: not words to inspire confidence
it "should" work though
well I managed to bork something
doing some HAL stuff, halrun printed a segfault message, and now I can't unload hal_lib