On Wed, Feb 15, 2006 at 11:12:25PM -0500, Matt Timmermans wrote:
Is there a known problem running axis under xfce? It starts up and eats cpu, but there's no window. My screen resolution ix 800x600, if that could possibly make a difference.
I haven't used xfce, but AXIS should work just fine on 800x600 screens. If you start emc from a terminal, then hit control-c after AXIS has started, do you get a Python traceback? If so, what does it say? It might look something like this, and I want to see all the lines from 'Traceback' to 'KeyboardInterrupt': Traceback (most recent call last): File "/usr/bin/axis", line 2068, in ? o.mainloop() File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 965, in mainloop self.tk.mainloop(n) File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1340, in __call__ def __call__(self, *args): KeyboardInterrupt (this is a traceback from a version of AXIS that was running normally at the time I hit control-c) On my own system (Ubuntu 5.10, emc2 CVS HEAD, AXIS 1.2a2, 1920x1200 screen), AXIS seems to work normally if I choose the 'xfce' session when I log in. However, this system is very differeent from a bdi system, so it may not be a very useful data point. Unfortunately, my only bdi system doesn't have an attached monitor, so it's difficult for me to test your configuration myself. Jeff
----- Original Message ----- From: <[email protected]>
If you start emc from a terminal, then hit control-c after AXIS has started, do you get a Python traceback?
Hey, that's a useful feature! The trace I got is included below. It looks like the problem is a call in line 640-something in axis, in the update method. It tells something to call the same method again in 20ms and then does the update. If it takes more than 20ms to do the update, bad things ensue, including deadlocks on some semaphores. You might be able to replicate the problem by setting the delay to 1ms or so. When I moved the enqueing call to the end of the update method, axis started to work just fine. I don't know whether or not even that is completely safe, however. Are "TkIntr" callbacks single-threaded? In any case, that's a lovely UI you have there. -- Matt Here's the trace. ALL this stuff came out when I hit Ctrl-C -- even the two lines before "Exception in Tkinter". ---- _sem.c 72: semctl(1409026,0,0) failed: (errno = 1) Operation not permitted _sem.c 72: semctl(1376257,0,0) failed: (errno = 1) Operation not permitted Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 456, in callit func(*args) File "plat/nonrealtime/bin/axis", line 646, in update self.win.set_current_line(self.stat.read_line) File "plat/nonrealtime/bin/axis", line 251, in set_current_line vupdate(vars.running_line, -1) File "plat/nonrealtime/bin/axis", line 571, in vupdate if var.get() == val: return File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 254, in get return getint(self._tk.globalgetvar(self._name)) KeyboardInterrupt MT> Ctrl-C didn't actually bring the UI down, so I killed it here. ./generic.run: line 605: 7681 Terminated plat/nonrealtime/bin/$display -ini $INIFILE quickstep.ini was not changed. generic.var was not changed. Removing shared memory 2490383 resource(s) deleted Removing semaphore 1507333 resource(s) deleted Removing shared memory 2523153 resource(s) deleted Removing semaphore 1540102 resource(s) deleted Removing shared memory 2326535 resource(s) deleted Removing semaphore 1343488 resource(s) deleted Removing shared memory 2359304 resource(s) deleted Removing semaphore 1376257 resource(s) deleted Removing shared memory 2392073 resource(s) deleted Removing semaphore 1409026 resource(s) deleted
participants (2)
-
jepler＠unpythonic.net -
Matt Timmermans