EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: use excepthook to show the user the message that has been encountered
EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: from TRUNK: use excepthook to show the user the message that has been encountered
EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note change
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2.2branch/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2.2branch_slot1_log.txt
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2.2branch/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2.2branch_slot2_log.txt
EMC: 03compile-farm 07BDI-4.51 (22.214.171.124-rtai) * 10emc2.2branch/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2.2branch_slot6_log.txt
I wonder if excepthook doesn't exist on older systems
SWPadnos: nope, it's a merge error it seems
what the heck? I didn't think you could check in a file with a merge error!
EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix earlier commit
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2.2branch/: build PASSED
EMC: 03compile-farm 07BDI-4.51 (126.96.36.199-rtai) * 10emc2.2branch/: build PASSED
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2.2branch/: build PASSED
yep - I noticed the <<<<<<< in the error log :)
I see there is an update to apport
looks like the last update was Apr 29. It fixed only this bug: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/224168
I don't see that any of the changes in apport 0.108.1 or 0.108.2 are relevant to our problems
oh is there a .2? when I got the source, I got .1
.2 has been published in -proposed: https://launchpad.net/ubuntu/hardy/+source/apport/0.108.2
you never got any answer to your question did you
that's too bad
I was trying to use the executable rs274 to test a, b, c commands and the nml message created but it doesn't want to take anything but x,y,z
I see there is a -n arg
skip that last thought.
Is there a way to enable A,B,
don't you need to pass it an ini file?
I'm surprised to see that it doesn't allow a,b,c
but I also see that behavior here
It doesn't seem to read an ini file only tbl and var.
I see the buglet
buglet I like that.
EMC: 03cradek 07TRUNK * 10emc2/src/emc/sai/ (driver.cc saicanon.cc): tell sai where to find some default files and remind it that it has 6 axes
That was quick!
very simple fix
will that work for RIP?
no, the defaults won't
I'm not happy with that part, but it's better than never working and I'm apparently too lazy to do it right
ok (thought so :) )
the not working pat anyway
pat doesn't work either.
oh, the pat I know does, for sure! :)
I assume that I can not commit from an anon checkout?
just sent a new ssh to chris cause I tried to fix all the ssh's on my net.
rayh: I thought you had already sent me a new one.
I think I redid it all.
There was something goofy going on with that box after the one I sent. Sorry for the trouble.'
No hurry getting it going though.
rs274 works now.
Creates a whole new batch of questions for me about the 9 axis stuff.
yeah sai is definitely not 9-axis complete
rayh: I added your new key.
Does the 9 simply expand the NML message to the extra three.
the canon calls are all expanded
Okay. I'll leave you alone. The key works.
is part of atra209's issue where if the mouse is already over the button - you cannot click on it until the mouse is moved off and back on again? (gnome issue?)
sounds like it could be related
I see that same thing when switching from x to y to z.
I see a similar sort of thing with synaptic if I mouse over the search before synaptic is ready.
yes - but if you mouse off the button - then back on - it works.
isn't that fixed in hardy?
I thought it was.. but I really have not payed attention.
it's a gnome bug, which I think is marked "wedontcare" or something
the buttons in there do not come to life unless you cross the boundary.
too bad hardy introduced desktop effects that break real apps, instead of fixing important usability bugs
I hope they are not trying to race Vista into being the most bloated windows manager
nah that's kde
it appears to be marked "too tired to fix". 10+ years, 100+ comments, 10+ patches, still open. http://bugzilla.gnome.org/show_bug.cgi?id=56070
Why don't I see it in tk when I change the function of a button but leave the mouse in place.
rayh: because it's a bug in gtk+, not in tk
(what I'm a bit more surprised by is the fact that ubuntu haven't fixed it themselves and damn the upstream)
cradek: I can't apply that in stepconf, because the "Forward" button is hidden inside the GnomeDruid widget; I can't access it directly.
can't you hide/show the whole widget?
I dunno, maybe
I'd much rather camp outside a lead gtk developer's house until the bug is fixed (and I don't really want to do that)
that would set a bad precedent. remember, we have users too.
Some of our users "camp" as we'll see in a few weeks at fest.
* alex_joni waits for people to camp outside his house
I've had about enough of thread milling.
(that'll be the day)
rayh: so? what'cha gonna do? mill the thread?
* jepler groans
I'm with jepler
(but now I'm trying to come up with a worse pun about turning the thread)
my machine would be perfect if you want a thread with four flat spots at the quadrants
that's be hard to do on a lathe, you must admit
fenn_ is now known as fenn