RE: _Long_ pause after each new directory is noticed. . .
Henry S. Thompson wrote: [EMAIL PROTECTED] (Henry S. Thompson) writes: With [Klaus's conservative semantic settings] added, problem doesn't occur immediately on editing a file, because Directory buffer/window is never painted. And it doesn't seem to happen after synchronising windows, which _does_ paint the Directory window. Oops, wrong, just didn't wait long enough -- a bit later, it did freeze again. I'll try to remove some of your stuff to try to narrow things down. . . However, looking at Klaus's subsequent message, and yes, I _am_ using cygwin xemacs build, (setq ecb-prescan-directories-for-emptyness nil ecb-vc-enable-support nil) Do not know if you work with version-controlled files... but if yes i would recommend only switching off the empty-dir-check (i.e. setting ecb-prescan-directories-for-emptyness to nil) and try if ecb-vc-enable-support switched on (recommended-value is 'unless-remote) is ok for you. switch the latter one only off when the problem still is there... Ciao, Klaus P.S. I think i should write a problem-report to the XEmacs-list about the really slow and delayed response-time of (input-pending-p) in combination with cygwin-file-operations.
RE: _Long_ pause after each new directory is noticed. . .
Henry S. Thompson wrote: [EMAIL PROTECTED] writes: Hmm, could be - do you know semantic-imenu-auto-rebuild-directory-indexes for example - and do you know (see INSTALL-file in semantic-subdir of cedet): t semantic-load-enable-minimum-features semantic-load-enable-code-helpers semantic-load-enable-excessive-code-helpers semantic-load-enable-semantic-debugging-helpers Those don't seem to be bound? I have the following in my semantic-setup: With all that added, problem doesn't occur immediately on editing a file, because Directory buffer/window is never painted. Huuh, which window/buffer is never painted...the ECB-directory-buffer?? And it doesn't seem to happen after synchronising windows, which _does_ paint the Directory window. I'll try to remove some of your stuff to try to narrow things down. . . I'm not really sure if i have understood your mail right - or i'm quite sure i haven't understood it right ;-) Klaus ht
Re: _Long_ pause after each new directory is noticed. . .
[EMAIL PROTECTED] writes: Henry S. Thompson wrote: . . . With all that added, problem doesn't occur immediately on editing a file, because Directory buffer/window is never painted. Huuh, which window/buffer is never painted...the ECB-directory-buffer?? Yes. I don't understand why not. And it doesn't seem to happen after synchronising windows, which _does_ paint the Directory window. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
RE: _Long_ pause after each new directory is noticed. . .
Henry S. Thompson wrote: [EMAIL PROTECTED] writes: Henry S. Thompson wrote: . . . With all that added, problem doesn't occur immediately on editing a file, because Directory buffer/window is never painted. Huuh, which window/buffer is never painted...the ECB-directory-buffer?? Yes. I don't understand why not. to tell you why not i need a fukll problem-report with `ecb-submit-problem-report' and the full semantic-setup you currently use! Klaus And it doesn't seem to happen after synchronising windows, which _does_ paint the Directory window. ht
Re: _Long_ pause after each new directory is noticed. . .
[EMAIL PROTECTED] writes: to tell you why not i need a fukll problem-report with `ecb-submit-problem-report' and the full semantic-setup you currently use! Done. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
Re: _Long_ pause after each new directory is noticed. . .
OK, so Klaus's guess _appears_ to be backwards. To recap: I had gotten rid of the problem by setting both ecb-prescan-directories-for-emptyness nil ecb-vc-enable-support nil Klaus said he suspected prescan, so I turned vc-support back on -- hang comes back! So I turned it off again, and enabled the emptyness scan -- no hang. So my current belief is that it's the vc support that's the problem, not the emptyness check. Which is slightly more plausible if only because vc support is new and emptyness is not, right? ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
RE: _Long_ pause after each new directory is noticed. . .
Henry S. Thompson wrote: OK, so Klaus's guess _appears_ to be backwards. To recap: I had gotten rid of the problem by setting both ecb-prescan-directories-for-emptyness nil ecb-vc-enable-support nil Klaus said he suspected prescan, so I turned vc-support back on -- hang comes back! So I turned it off again, and enabled the emptyness scan -- no hang. So my current belief is that it's the vc support that's the problem, not the emptyness check. Which is slightly more plausible if only because vc support is new and emptyness is not, right? well, are you working with CVS?? If yes, do you use a remote repository (e.g. something like :ext:[EMAIL PROTECTED]:/cvsroot/ecb)?? If yes and you use XEmacs then you have the bad luck, that the VC-package (vc.el et.al.) of XEmacs is fully outdated - compared to the GNU Emacs one really ... bad programmed and not really powerful concering customizing... You can make a test for me - Please do: M-x (ecb-vc-dir-managed-by-CVS full/directory/name/of/a/dir/managed/by/a/VC) RET and tell me the result and tell me if this call takes a long time? GNU Emacs allows to stay local for remote CVS-repositores and to compute the VC-state in a heuristic approach which is not really 100% correct but is sufficient for most situations and is much faster than sending real CVS-commands like cvs status to a remote repository - XEmacs does this - and therefore checking the VC-state of each file in a directory (done by ECB) takes a long long time for a single file and a log long long long time for the whole dir - ECB does this stealthy but here we have that problem wit cygwin-XEmacs i have tried to describe in one of my postings yesterday... Klaus ht
Re: _Long_ pause after each new directory is noticed. . .
[EMAIL PROTECTED] writes: Henry S. Thompson wrote: OK, so Klaus's guess _appears_ to be backwards. . . . So my current belief is that it's the vc support that's the problem, not the emptyness check. Which is slightly more plausible if only because vc support is new and emptyness is not, right? well, are you working with CVS?? Yes. If yes, do you use a remote repository (e.g. something like :ext:[EMAIL PROTECTED]:/cvsroot/ecb)?? Yes. If yes and you use XEmacs then you have the bad luck, that the VC-package (vc.el et.al.) of XEmacs is fully outdated - compared to the GNU Emacs one really ... bad programmed and not really powerful concering customizing... Sigh :-( You can make a test for me - Please do: M-x (ecb-vc-dir-managed-by-CVS full/directory/name/of/a/dir/managed/by/a/VC) RET and tell me the result and tell me if this call takes a long time? CVS, and no, but not for any interesting reason: You check the cvs root for @.*:, but although my root is remote, it doesn't match because, per your comment in line, it has no username, i.e. it looks like mhost.mydom:/home/cvsroot So I patched the pattern and still no pause -- ah -- on cygwin you need (setq ecb-ping-options '(-s 1)) to avoid an error. OK, so finally, a modest pause followed by 'CVS GNU Emacs allows to stay local for remote CVS-repositores and to compute the VC-state in a heuristic approach which is not really 100% correct but is sufficient for most situations and is much faster than sending real CVS-commands like cvs status to a remote repository - XEmacs does this - and therefore checking the VC-state of each file in a directory (done by ECB) takes a long long time for a single file and a log long long long time for the whole dir - ECB does this stealthy but here we have that problem wit cygwin-XEmacs i have tried to describe in one of my postings yesterday... Understood. The above errors cancelled themselves out, ecb thinks I'm using CVS (which I am), so it goes into this long uninterruptable sequence. So the _principled_ solution is to find a way to get VC improved for XEmacs and/or to fix the cygwin interruptability pblm. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
RE: _Long_ pause after each new directory is noticed. . .
OK, so Klaus's guess _appears_ to be backwards. . . . So my current belief is that it's the vc support that's the problem, not the emptyness check. Which is slightly more plausible if only because vc support is new and emptyness is not, right? well, are you working with CVS?? Yes. If yes, do you use a remote repository (e.g. something like :ext:[EMAIL PROTECTED]:/cvsroot/ecb)?? Yes. If yes and you use XEmacs then you have the bad luck, that the VC-package (vc.el et.al.) of XEmacs is fully outdated - compared to the GNU Emacs one really ... bad programmed and not really powerful concering customizing... Sigh :-( You can make a test for me - Please do: M-x (ecb-vc-dir-managed-by-CVS full/directory/name/of/a/dir/managed/by/a/VC) RET and tell me the result and tell me if this call takes a long time? CVS, and no, but not for any interesting reason: You check the cvs root for @.*:, but although my root is remote, it doesn't match because, per your comment in line, it has no username, i.e. it looks like mhost.mydom:/home/cvsroot So I patched the pattern and still no pause -- ah -- on cygwin you how do you have patched the pattern?? maybe i should patch the pattern in ECB too!! need (setq ecb-ping-options '(-s 1)) to avoid an error. OK, so finally, a modest pause followed by 'CVS OK, then ECB has checked if the remote host is accesible... GNU Emacs allows to stay local for remote CVS-repositores and to compute the VC-state in a heuristic approach which is not really 100% correct but is sufficient for most situations and is much faster than sending real CVS-commands like cvs status to a remote repository - XEmacs does this - and therefore checking the VC-state of each file in a directory (done by ECB) takes a long long time for a single file and a log long long long time for the whole dir - ECB does this stealthy but here we have that problem wit cygwin-XEmacs i have tried to describe in one of my postings yesterday... Understood. The above errors cancelled themselves out, ecb thinks I'm using CVS (which I am), so it goes into this long uninterruptable sequence. So the _principled_ solution is to find a way to get VC improved for XEmacs and/or to fix the cygwin interruptability pblm. The former one is in progress - at least AFAIK - Ville Skyttä is working on synching XEmacs VC with GNU Emacs VC - but i would not hold my breath until it is ready for release ;-)) The latter one: Hmm, maybe i write a report to XEmacs-team - but somehow this problem is hard to catch and to describe.. Klaus
Re: _Long_ pause after each new directory is noticed. . .
[EMAIL PROTECTED] writes: HST: So I patched the pattern and still no pause -- ah -- on cygwin you how do you have patched the pattern?? maybe i should patch the pattern in ECB too!! I just removed the @, but that leaves the pattern pretty weak. Something like (and Root-content (string-match \\(@\\(.+\\)\\|^\\([-.0-9a-zA-Z]+\\)\\): Root-content) (or (string-match 2 Root-content) (string-match 3 Root-content))) might be OK (not tested). ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
RE: _Long_ pause after each new directory is noticed. . .
Henry S. Thompson wrote: [EMAIL PROTECTED] writes: HST: So I patched the pattern and still no pause -- ah -- on cygwin you how do you have patched the pattern?? maybe i should patch the pattern in ECB too!! I just removed the @, but that leaves the pattern pretty weak. Something like (and Root-content (string-match \\(@\\(.+\\)\\|^\\([-.0-9a-zA-Z]+\\)\\): Root-content) (or (string-match 2 Root-content) (string-match 3 Root-content))) Hmm, better but not good enough ;-) What do you think about this function for testing if rep. is remote or not: (defun ecb-vc-cvs-root-remote-p (root) (if (string-match ^:local: root) nil (and (string-match ^\\(:ext:\\|:server:\\)?\\([EMAIL PROTECTED]@\\)?\\([^:]+\\): root) (match-string 3 root Can you please test this a little bit - if it is ok, i would add this for the next ECB-release... Thanks a lot! Klaus
Re: _Long_ pause after each new directory is noticed. . .
[EMAIL PROTECTED] writes: What do you think about this function for testing if rep. is remote or not: (defun ecb-vc-cvs-root-remote-p (root) (if (string-match ^:local: root) nil (and (string-match ^\\(:ext:\\|:server:\\)?\\([EMAIL PROTECTED]@\\)?\\([^:]+\\): root) (match-string 3 root Can you please test this a little bit - if it is ok, i would add this for the next ECB-release... Yes, that works for a reasonable sample of my CVS Root files. Thanks a lot! You're welcome, but mostly thank _you_ for prompt and helpful replies, to say nothing of ecb in the first place! ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
RE: _Long_ pause after each new directory is noticed. . .
Nascif Abousalh-Neto writes: I am having a similar problem, but it is not deterministic. Had it yesterday but can't reproduce today. On the face of it, it would appear that this is a problem with ecb as it tries to build lists of what's in directories whereas the JDEE does not. The first thing I would do is try to pinpoint the problem to one package or the other and to one file type another, i.e., to use the JDEE and ECB separately to determine if the problem occurs with one but not the other, with Java files but not other types of files, or with both packages and only Java files, both packages and nonJava files, etc. Paul Using ECB 2.30 and JDE 2.3.4. Debug-on-error doesn't work for this one, and the long breaks are *very* disruptive. Any idea on how to debug something like that? -Original Message- From: Henry S. Thompson [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:34 AM To: jde Subject: _Long_ pause after each new directory is noticed. . . Just upgraded both jde and ecb (can't tell which is the problem, sorry) to latest versions (ecb 2.30.1 and jcb 2.3.4) Whenever I read or save a .java file to a particular package directory for the first time in a given session, xemacs goes away for a long (several minutes) time. It's not responsive to Ctrl-G during this time. Not sure this is new, but it seems worse. . . Any clues? ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
RE: _Long_ pause after each new directory is noticed. . .
Paul Kinnucan wrote: Nascif Abousalh-Neto writes: I am having a similar problem, but it is not deterministic. Had it yesterday but can't reproduce today. On the face of it, it would appear that this is a problem with ecb as it tries to build lists of what's in directories whereas the JDEE does not. The first thing I would do is try to pinpoint the problem to one package or the other and to one file type another, i.e., to use the JDEE and ECB separately to determine if the problem occurs with one but not the other, with Java files but not other types of files, or with both packages and only Java files, both packages and nonJava files, etc. Paul Using ECB 2.30 and JDE 2.3.4. Debug-on-error doesn't work for this one, and the long breaks are *very* disruptive. Any idea on how to debug something like that? -Original Message- From: Henry S. Thompson [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:34 AM To: jde Subject: _Long_ pause after each new directory is noticed. . . Just upgraded both jde and ecb (can't tell which is the problem, sorry) to latest versions (ecb 2.30.1 and jcb 2.3.4) Whenever I read or save a .java file to a particular package directory for the first time in a given session, xemacs goes away for a long (several minutes) time. It's not responsive to Ctrl-G during this time. Please send a problem-report to the ECB-list with `ecb-submit-problem-report'! Do you use XEmacs cygwin-build?? Do you know the options - ecb-stealthy-tasks-delay - ecb-prescan-directories-for-emptyness and ecb-prescan-directories-exclude-regexps - ecb-vc-enable-support and ecb-vc-directory-exclude-regexps - ecb-sources-perform-read-only-check and ecb-read-only-check-exclude-regexps Especially with Xemacs cygwin-build (which file-operations are incredible slow compared to native-XEmacs-build) the empty-dir check can block XEmacs - evebn if this check is runned stealthy in idle-time and also interruptable by any(!) key-press or mouse-click the XEmacs-cygwin-build seems to responf / react to such an interrupt very delayed / slow - with native XEmacs or GNU Emacs all this work fine! IMHO (input-pending-p) does not work very well with cygwin-XEmacs (at least not when running a lot file-operations for a lot of files...)... so you can try to set ecb-prescan-directories-for-emptyness to nil or exclude some dirs with ecb-prescan-directories-exclude-regexps and then check if the situation is now better - also for the other stealthy tasks ecb-vc-enable-support and ecb-sources-perform-read-only-check wheres the latter one should not be a problem Klaus Not sure this is new, but it seems worse. . . Any clues? ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
Re: _Long_ pause after each new directory is noticed. . .
[EMAIL PROTECTED] writes: Hmm, could be - do you know semantic-imenu-auto-rebuild-directory-indexes for example - and do you know (see INSTALL-file in semantic-subdir of cedet): t semantic-load-enable-minimum-features semantic-load-enable-code-helpers semantic-load-enable-excessive-code-helpers semantic-load-enable-semantic-debugging-helpers Those don't seem to be bound? I have the following in my semantic-setup: With all that added, problem doesn't occur immediately on editing a file, because Directory buffer/window is never painted. And it doesn't seem to happen after synchronising windows, which _does_ paint the Directory window. I'll try to remove some of your stuff to try to narrow things down. . . ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
Re: _Long_ pause after each new directory is noticed. . .
[EMAIL PROTECTED] (Henry S. Thompson) writes: With [Klaus's conservative semantic settings] added, problem doesn't occur immediately on editing a file, because Directory buffer/window is never painted. And it doesn't seem to happen after synchronising windows, which _does_ paint the Directory window. Oops, wrong, just didn't wait long enough -- a bit later, it did freeze again. I'll try to remove some of your stuff to try to narrow things down. . . However, looking at Klaus's subsequent message, and yes, I _am_ using cygwin xemacs build, (setq ecb-prescan-directories-for-emptyness nil ecb-vc-enable-support nil) really _does_ seem to have solved the problem. Thanks! ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED] URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
