Charles Hines <chuck.hines(a)baesystems.com> writes:
I've periodically seen problems in the past with ClearCase mode
up to the point of it essentially locking up waiting for the underlying
cleartool command to start, and after upgrading to the latest officially
released cleartool.el today I'm now hitting it pretty much universally in my
setup (including w/ -vanilla, eliminating my setup).
Basically, I think there is a race condition going on where cleartool is
starting (I can see the process running), but not seeing the command that the
mode is passing to it, so it doesn't give the expected response, so XEmacs
just sits there saying "waiting for cleartool to start".
Even reverting to the previous version of clearcase.el I have (and
the .elc of course) still exhibits the problem, so I'm thinking that one of
the other updated packages it requires is triggering this...and in fact it
appears to be tq.el because if I load the older version I had before loading
clearcase.el, everything is fine.
The delta between the previous tq.el and the current is pretty
--- tq.el.prev Thu Jan 20 17:08:03 2005
+++ tq.el Mon Nov 8 01:17:00 2004
＠＠ -23,7 +23,7 ＠＠
;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
;; 02111-1307, USA.
-;;; Synched up with: FSF 19.34.
+;;; Synched up with: FSF 21.3.
＠＠ -50,8 +50,8 ＠＠
(concat " tq-temp-"
- (`(lambda (proc string)
- (tq-filter '(, tq) string))))
+ `(lambda (proc string)
+ (tq-filter '(, tq) string)))
The change above looks like a bad synch to me. The FSF 21.3 version
does not seem to have this change to tq-create.
＠＠ -69,7 +69,7 ＠＠
(defun tq-queue-head-closure (tq) (car (cdr (car (tq-queue tq)))))
(defun tq-queue-empty (tq) (not (tq-queue tq)))
(defun tq-queue-pop (tq) (setcar tq (cdr (car tq))) (null (car tq)))
;;; must add to queue before sending!
(defun tq-enqueue (tq question regexp closure fn)
＠＠ -89,10 +89,10 ＠＠
(defun tq-filter (tq string)
"Append STRING to the TQ's buffer; then process the new data."
- (set-buffer (tq-buffer tq))
- (goto-char (point-max))
- (insert string)
- (tq-process-buffer tq))
+ (with-current-buffer (tq-buffer tq)
+ (goto-char (point-max))
+ (insert string)
+ (tq-process-buffer tq)))
(defun tq-process-buffer (tq)
"Check TQ's buffer for the regexp at the head of the queue."
＠＠ -110,10 +110,13 ＠＠
(if (re-search-forward (tq-queue-head-regexp tq) nil t)
(let ((answer (buffer-substring (point-min) (point))))
(delete-region (point-min) (point))
- (funcall (tq-queue-head-fn tq)
- (tq-queue-head-closure tq)
- (tq-queue-pop tq)
+ (condition-case nil
+ (funcall (tq-queue-head-fn tq)
+ (tq-queue-head-closure tq)
+ (error nil))
+ (tq-queue-pop tq))
I'm suspecting that last delta, but haven't been able to figure out enough
running under edebug yet to figure out exactly why. Figured I'd see if anyone
on the list would know just by visual inspection before I dove too much deeper
in...or if anyone had any advice on how to make debugging this easier?
I've only started running the current SUMO today. First test results
suggest that backing out the change to tq-create should fix the