RE: spontaneous C-L and RE: jde glitches
I was able to repeatably cause the behavior by starting a new method and not providing the closing brace. Removing the closing brace also triggered the behavior. It happened every few seconds when reparsing (semantic) or updating font lock (as seen when a string is open and not completed). I had to have enough code in the buffer to be bigger than the screen size (to trigger scrolling). In the attached file if I remove the closing brace of testit1() I see the spontaneous C-L behavior. A while back (26 Mar) there was also a message about getting a stack overflow in the messages buffer from semantic parsing (RE: jde glitches). When I created a new file to test out the spontaneous C-L behavior I also encountered the stack overflow problem. Saving the file, closing, and re-opening the file cured the problem. GNU Emacs 21.1 on Win2k, jde 2.2.9beta9.1, elib-1.0, eieio-0.17beta4, speedbar-0.14beta4, and semantic-1.4beta14 with semantic-imenu.el v 1.39.2.5 from CVS (to include Eric Ludlams patch) -- Craig Kelley -Original Message- From: Rory Molinari [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 3:46 PM To: [EMAIL PROTECTED] Subject: Re: spontaneous C-L Mark Abrams writes: > "Berndl, Klaus" wrote: > >> The ECB versions >= 1.60 contain code for better handling eshell. >> My first question: Do you use the eshell package in combination with >> ECB? > > No I am not using eshell, unless it is part of a package that I am not > aware of. There is no eshell.el in my lisp directories. > > Mark I am not using it either, and sometimes see the refresh problem. jde-version: 2.2.9beta9.1 semantic-version: 1.4beta14 eieio-version:0.17beta4 I found myself having this problem yesterday, while editing a java class too large to post to the group. In trying (and failing - see below) to boil my class down to a small example I found the following: 1) The refresh occurred (repeatedly) while I was editing an unterminated string, which was followed by another string, like this (cursor shown with >|<): String string1 = "A test" + "case >|< String string2 = "Another" + "string"; 2) The autorefresh reliably goes away when I terminate the first string with another double quote. 3) I successively removed chunks of the original file, each time verifying that the auto-refresh still happened. This worked until I made a deletion (somewhat before the first string above) which stopped the autorefresh. Confusingly, undoing the deletion, returning the buffer to the previous state (in which the autorefresh occurred), did not make the autorefresh start up again. Reloading the file, from the last "broken" state, did not make the autorefresh start up again. 4) When it happens, the autofresh takes place regularly, at a frequency I have come to associate with the auto-reparse (semantic, I think) that takes place after changes in the buffer. I don't have hard evidence for it being a semantic issue, though, as I didn't see any messages in the *Messages* buffer. I have not included the file which causes this problem, as the problem does not occur when the file is simply loaded up. I am sorry that this report is not more helpful. Rory TestCtrlL.java Description: Binary data
Re: spontaneous C-L
Mark Abrams writes: > "Berndl, Klaus" wrote: > >> The ECB versions >= 1.60 contain code for better handling eshell. >> My first question: Do you use the eshell package in combination with >> ECB? > > No I am not using eshell, unless it is part of a package that I am not > aware of. There is no eshell.el in my lisp directories. > > Mark I am not using it either, and sometimes see the refresh problem. jde-version: 2.2.9beta9.1 semantic-version: 1.4beta14 eieio-version:0.17beta4 I found myself having this problem yesterday, while editing a java class too large to post to the group. In trying (and failing - see below) to boil my class down to a small example I found the following: 1) The refresh occurred (repeatedly) while I was editing an unterminated string, which was followed by another string, like this (cursor shown with >|<): String string1 = "A test" + "case >|< String string2 = "Another" + "string"; 2) The autorefresh reliably goes away when I terminate the first string with another double quote. 3) I successively removed chunks of the original file, each time verifying that the auto-refresh still happened. This worked until I made a deletion (somewhat before the first string above) which stopped the autorefresh. Confusingly, undoing the deletion, returning the buffer to the previous state (in which the autorefresh occurred), did not make the autorefresh start up again. Reloading the file, from the last "broken" state, did not make the autorefresh start up again. 4) When it happens, the autofresh takes place regularly, at a frequency I have come to associate with the auto-reparse (semantic, I think) that takes place after changes in the buffer. I don't have hard evidence for it being a semantic issue, though, as I didn't see any messages in the *Messages* buffer. I have not included the file which causes this problem, as the problem does not occur when the file is simply loaded up. I am sorry that this report is not more helpful. Rory
RE: Speeding up the BeanShell?
Lowell, Charles (Thoughtworks) writes: > > Hi all, > > Since most of the time I use the normal emacs text completion anyway this > hasn't been much of an issue for me, but I too have had performance issues > with field/method completion. My classpath is absolutely enormous, yet > import, and navigating to source are pretty much instantaneous. In fact, so > is completion, with the exceptionof the first time that I try it within a > class. All subsequent times I use completion, the menu appears with no > appreciable delay. This is expected behavior. The first time you do completion, the JDEE builds and caches a hash table of all the classes on the classpath. Successive completions require only a hash table lookup, which is very fast even for large classpaths. - Paul > Don't know if this is relevant at all to your problem or > not, but I figured I'd mention it. > > cheers, > Charles > > > -Original Message- > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > > Sent: 12 April 2002 14:41 > > To: Elias Biris > > Cc: Paul Kinnucan; JDE List (E-mail) > > Subject: RE: Speeding up the BeanShell? > > > > > > Elias Biris writes: > > > thanks for the reply: > > > > > > The changes that you suggest do not sort my problem. Even > > without the jars in the classpath the Beanshell cannot find > > the requested classes promptly enough. Also my code base is > > already quite large. > > > > I don't know why this should be so. It works quite promptly > > on my system > > for finding JDK source files. Does your application include > > more classes > > than the JDK? > > > > Also do you have the same performance problem with the import class > > command (C-c C-v C-z)? The only thing that the source file finder uses > > the Beanshell for is to find the qualified name of the class. If the > > Beanshell is the problem, you should see the same problem with all > > JDE commands that use the Beanshell, including the import command > > and field and method completion. > > > > > > > > On another aspect, the invocation of the beanshell is done > > via the command: > > > > > > > > Q:\Dir_1;Q:\dir_2;Q:\dir_3;Q:\dir_4;f:/Programs/emacs/site_lis > > p/jde/jde-2.2.9beta9.1/java/bsh > > commands;c:/jdk1.3.1/lib/tools.jar;f:/Programs/emacs/site_lisp > > /jde/jde-2.2.9beta9.1/java/lib/checkstyle.jar;f:/Programs/emac > > s/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jakarta-regexp.jar;f > > :/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jde.j > > ar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/bsh.jar > > > > > > > > > Does that mean that the Beanshell picks all the jars in > > that classpath as well for searching? > > > > Yes. > > > > >In that case removing the extraneous jars from my classpath > > does not make any difference as they get picked up from the command > > > > It would make a difference because they would be included > > twice, once by you and once > > by the JDE (bsh.jar and jde.jar) and once by the JDK > > (rt.jar). I'm not convinced yet > > that the problem is the Beanshell. > > > > - Paul > > >
RE: Speeding up the BeanShell?
Hi all, Since most of the time I use the normal emacs text completion anyway this hasn't been much of an issue for me, but I too have had performance issues with field/method completion. My classpath is absolutely enormous, yet import, and navigating to source are pretty much instantaneous. In fact, so is completion, with the exceptionof the first time that I try it within a class. All subsequent times I use completion, the menu appears with no appreciable delay. Don't know if this is relevant at all to your problem or not, but I figured I'd mention it. cheers, Charles > -Original Message- > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > Sent: 12 April 2002 14:41 > To: Elias Biris > Cc: Paul Kinnucan; JDE List (E-mail) > Subject: RE: Speeding up the BeanShell? > > > Elias Biris writes: > > thanks for the reply: > > > > The changes that you suggest do not sort my problem. Even > without the jars in the classpath the Beanshell cannot find > the requested classes promptly enough. Also my code base is > already quite large. > > I don't know why this should be so. It works quite promptly > on my system > for finding JDK source files. Does your application include > more classes > than the JDK? > > Also do you have the same performance problem with the import class > command (C-c C-v C-z)? The only thing that the source file finder uses > the Beanshell for is to find the qualified name of the class. If the > Beanshell is the problem, you should see the same problem with all > JDE commands that use the Beanshell, including the import command > and field and method completion. > > > > > On another aspect, the invocation of the beanshell is done > via the command: > > > > > Q:\Dir_1;Q:\dir_2;Q:\dir_3;Q:\dir_4;f:/Programs/emacs/site_lis > p/jde/jde-2.2.9beta9.1/java/bsh > commands;c:/jdk1.3.1/lib/tools.jar;f:/Programs/emacs/site_lisp > /jde/jde-2.2.9beta9.1/java/lib/checkstyle.jar;f:/Programs/emac > s/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jakarta-regexp.jar;f > :/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jde.j > ar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/bsh.jar > > > > > > Does that mean that the Beanshell picks all the jars in > that classpath as well for searching? > > Yes. > > >In that case removing the extraneous jars from my classpath > does not make any difference as they get picked up from the command > > It would make a difference because they would be included > twice, once by you and once > by the JDE (bsh.jar and jde.jar) and once by the JDK > (rt.jar). I'm not convinced yet > that the problem is the Beanshell. > > - Paul >
updating project file
Hi, I wrote a lot of project specific information directly to my .emacs file. Is there a way to quickly extract project-specific stuff from .emacs and put it in the project file? Or do I have to go and hand-edit both files? Thanks Heather M. Buch Java Analyst Programmer II Information Systems [EMAIL PROTECTED] (617) 253-9801 N42-240K Support open-source software. Oppose the SSSCA! http://judiciary.senate.gov/special/input_form.cfm
Re: spontaneous C-L
"Berndl, Klaus" wrote: > The ECB versions >= 1.60 contain code for better handling eshell. > My first question: Do you use the eshell package in combination with > ECB? No I am not using eshell, unless it is part of a package that I am not aware of. There is no eshell.el in my lisp directories. Mark
jtags
Hi,
After tagging a
bunch of source files with jtags, I discovered that not all the methods had been
tagged. After investigation, I discovered that those methods were declared like
this:
protected
intsendCommand(String commandCode){
instead
of:
protected int
sendCommand(String commandCode){
I looked at the
regular expression for methods returning classes and primitive types but I have
to admit that it looks like chinese to me so I wonder if someone could tell me
if there's a way to tag methods defined as above.
Thanks,
Jean
RE: Speeding up the BeanShell?
Elias Biris writes: > thanks for the reply: > > The changes that you suggest do not sort my problem. Even without the jars in the >classpath the Beanshell cannot find the requested classes promptly enough. Also my >code base is already quite large. I don't know why this should be so. It works quite promptly on my system for finding JDK source files. Does your application include more classes than the JDK? Also do you have the same performance problem with the import class command (C-c C-v C-z)? The only thing that the source file finder uses the Beanshell for is to find the qualified name of the class. If the Beanshell is the problem, you should see the same problem with all JDE commands that use the Beanshell, including the import command and field and method completion. > > On another aspect, the invocation of the beanshell is done via the command: > > >Q:\Dir_1;Q:\dir_2;Q:\dir_3;Q:\dir_4;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/bsh > >commands;c:/jdk1.3.1/lib/tools.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/checkstyle.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jakarta-regexp.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jde.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/bsh.jar > > > > Does that mean that the Beanshell picks all the jars in that classpath as well for >searching? Yes. >In that case removing the extraneous jars from my classpath does not make any >difference as they get picked up from the command It would make a difference because they would be included twice, once by you and once by the JDE (bsh.jar and jde.jar) and once by the JDK (rt.jar). I'm not convinced yet that the problem is the Beanshell. - Paul
RE: Speeding up the BeanShell?
thanks for the reply: The changes that you suggest do not sort my problem. Even without the jars in the classpath the Beanshell cannot find the requested classes promptly enough. Also my code base is already quite large. On another aspect, the invocation of the beanshell is done via the command: Q:\Dir_1;Q:\dir_2;Q:\dir_3;Q:\dir_4;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/bsh commands;c:/jdk1.3.1/lib/tools.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/checkstyle.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jakarta-regexp.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/jde.jar;f:/Programs/emacs/site_lisp/jde/jde-2.2.9beta9.1/java/lib/bsh.jar Does that mean that the Beanshell picks all the jars in that classpath as well for searching? In that case removing the extraneous jars from my classpath does not make any difference as they get picked up from the command Am I right? Sorry for the ignorance, I am just trying to work this out well. Thanks > -Original Message- > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 12, 2002 1:11 PM > To: Elias Biris > Cc: Paul Kinnucan; JDE List (E-mail) > Subject: RE: Speeding up the BeanShell? > > > Elias Biris writes: > > Okdok. Attached is the report generated. thanks for the patience. > > > > I notice in your report that you are using JDE 2.2.9beta9.1 > but you have > the jde.jar and bsh.jar for JDE 2.2.8 in your jde-global-classpath. > This is not good, using an earlier version of the JDE's jar > files with a a later version of the JDE. Further, there is no need > anyway for you to include either jar file in jde-global-classpath. > Nor is there a need for you to include the JDK's rt.jar > file in jde-global-classpath. rt.jar is autoamtically included > in the vm's boot classpath. The JDE's source file searching > command has to search the classpath. You've needlessly created > a huge classpath for it to search, at least twice the size that > it needs to be. > > - Paul > >
RE: Speeding up the BeanShell?
Elias Biris writes: > Okdok. Attached is the report generated. thanks for the patience. > I notice in your report that you are using JDE 2.2.9beta9.1 but you have the jde.jar and bsh.jar for JDE 2.2.8 in your jde-global-classpath. This is not good, using an earlier version of the JDE's jar files with a a later version of the JDE. Further, there is no need anyway for you to include either jar file in jde-global-classpath. Nor is there a need for you to include the JDK's rt.jar file in jde-global-classpath. rt.jar is autoamtically included in the vm's boot classpath. The JDE's source file searching command has to search the classpath. You've needlessly created a huge classpath for it to search, at least twice the size that it needs to be. - Paul
RE: Speeding up the BeanShell?
Okdok. Attached is the report generated. thanks for the patience. > -Original Message- > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 12, 2002 12:18 PM > To: Elias Biris > Cc: JDE List (E-mail) > Subject: Speeding up the BeanShell? > > > Elias, > > It is important that you use the JDEE's Submit Problem Report > command to generate a snapshot of your setup and include > this snapshot when filing a report. This saves us the time > of having to engage you in a time-consuming email dialog just > to get the information that might be relevant to your problem. > > - Paul > > > Elias Biris writes: > > Hi, > > > > I am trying to understand how the BeanShell works, for > finding a class whose name is under the cursor. > > > > the Beanshell is configured correctly and loads fine but > its response time is a bit of an issue: Many times it sends > no reply, and I need to retry again and again till it finally > 'finds' the source for the class I am asking and brings it on. > > > > Is there a way to speed it up? I also noticed that while > the beanshell is 'processing' my request my emacs is unusable > (freezes), and stays so for 30 seconds or so till the > Beanshell replies > > > > I am using emacs 21.1 on Windows 2000 Pro (service pack > 2). Sun JDK 1.3.1 > > > > Any tips will be appreciated. The Beanshell functionality > for finding source code for classes in a large code base is > very important. > > > > thanks > > > > Elias Biris, System-Level Design R&D > > Cadence Design Systems Ltd,SOC Design Centre > > 1 The Alba Campus TEL: +44 (0)1506595036 > > Livingston, EH54 7HH FAX: +44 (0)1506595959 > > > > report_jde Description: report_jde
Speeding up the BeanShell?
Elias, It is important that you use the JDEE's Submit Problem Report command to generate a snapshot of your setup and include this snapshot when filing a report. This saves us the time of having to engage you in a time-consuming email dialog just to get the information that might be relevant to your problem. - Paul Elias Biris writes: > Hi, > > I am trying to understand how the BeanShell works, for finding a class whose name is >under the cursor. > > the Beanshell is configured correctly and loads fine but its response time is a bit >of an issue: Many times it sends no reply, and I need to retry again and again till >it finally 'finds' the source for the class I am asking and brings it on. > > Is there a way to speed it up? I also noticed that while the beanshell is >'processing' my request my emacs is unusable (freezes), and stays so for 30 seconds >or so till the Beanshell replies > > I am using emacs 21.1 on Windows 2000 Pro (service pack 2). Sun JDK 1.3.1 > > Any tips will be appreciated. The Beanshell functionality for finding source code >for classes in a large code base is very important. > > thanks > > Elias Biris, System-Level Design R&D > Cadence Design Systems Ltd, SOC Design Centre > 1 The Alba CampusTEL: +44 (0)1506595036 > Livingston, EH54 7HH FAX: +44 (0)1506595959 >
Speeding up the BeanShell?
Hi, I am trying to understand how the BeanShell works, for finding a class whose name is under the cursor. the Beanshell is configured correctly and loads fine but its response time is a bit of an issue: Many times it sends no reply, and I need to retry again and again till it finally 'finds' the source for the class I am asking and brings it on. Is there a way to speed it up? I also noticed that while the beanshell is 'processing' my request my emacs is unusable (freezes), and stays so for 30 seconds or so till the Beanshell replies I am using emacs 21.1 on Windows 2000 Pro (service pack 2). Sun JDK 1.3.1 Any tips will be appreciated. The Beanshell functionality for finding source code for classes in a large code base is very important. thanks Elias Biris,System-Level Design R&D Cadence Design Systems Ltd, SOC Design Centre 1 The Alba Campus TEL: +44 (0)1506595036 Livingston, EH54 7HHFAX: +44 (0)1506595959
Spaces in filenames/folders?
Daniel Hegyi writes: > Paul, any plans on upgrading JDEE to handle spaces in paths? I'm using > WebSphere Studio Application Developer to test and deploy my J2EE code. > Since WSAD's editor is inferior to JDEE I wanted to use JDEE to edit the > code. Unfortunately, I can't, since WSAD puts the sources in "C:\Program > Files\IBM\Application Developer\workspace\..." I could make copies of the > sources and edit those, but then I would have to propagate the changes back > to WSAD. This is a little cumbersome. Yes, I plan to fix this problem soon. - Paul
