Re: problem with JDEE
I am having the same problem. If I add 21 to the compile command it works OK. This just started happening since I upgraded my JDEE. Looks like some problem handling STD ERR. Paul Kinnucan wrote: Jon Schewe writes: I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0. I've also filed a bug report with Sun and sent this test case to one of their engineers. If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside JDEE. If you run it from the commandline it's just fine. Here's the commandline I'm using. java -classpath /net/users/jschewe/projects/test/build/ -Xmx256m -ea bugs.jdk.code129.SplitDB If I comment out the setIcon call in DatabaseDialog, then it's just fine. So my guess is that there's something with the signal handling when the image finishes loading. Do you have any ideas as to what JDEE/XEmacs may be doing when it executes the java process that would cause this to occur? Thanks for any input you have. Until then I'll have to resort to the commandline. BTW this happens also when running ant inside JDEE. Hi Jon, I have no problem running the test case that you sent from the JDEE on Windows XP with Emacs 21.3.1. The icon loads just fine. The problem thus cannot be the JDEE. You say you can run the program from the command line. Do you mean from an external shell or from an XEmacs shell buffer? If you cannot run it from a shell buffer in XEmacs or from the JDEE but you can run it from a Linux shell, that would indicate that the problem is with XEmacs. If so, I'd try to find out what code129 means. Paul Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.0.10 /HEAD BODY I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0.nbsp; I've also filed a bug report with Sun and sent this test case to one of their engineers.BR BR If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside JDEE.nbsp; If you run it from the commandline it's just fine. BR BR Here's the commandline I'm using.BR java -classpath /net/users/jschewe/projects/test/build/ -Xmx256m -ea bugs.jdk.code129.SplitDBBR BR If I comment out the setIcon call in DatabaseDialog, then it's just fine.nbsp; So my guess is that there's something with the signal handling when the image finishes loading.BR BR Do you have any ideas as to what JDEE/XEmacs may be doing when it executes the java process that would cause this to occur?BR BR Thanks for any input you have.nbsp; Until then I'll have to resort to the commandline.nbsp; BR BR BTW this happens also when running ant inside JDEE.BR BR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD HR BR Your mouse has moved.BR Windows must restart for change to take effect.BR Reboot now? [OK]BR A HREF=http://web-unix.htc.honeywell.com/people/jschewe;Uhttp://web-unix.htc.honeywell.com/people/jschewe/U/A [Honeywell Intranet Only]BR *My views may not represent those of my employers /TD /TR /TABLE /BODY /HTML
Re: problem with JDEE
Thanks. I tried that by adding 21 to the end of prop-args in jde-run-vm-launch, but that didn't help. Got any other ideas? On Tue, 2004-10-12 at 08:32, Matthew Smith wrote: I am having the same problem. If I add 21 to the compile command it works OK. This just started happening since I upgraded my JDEE. Looks like some problem handling STD ERR. Paul Kinnucan wrote: Jon Schewe writes: I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0. I've also filed a bug report with Sun and sent this test case to one of their engineers. If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside JDEE. If you run it from the commandline it's just fine. Here's the commandline I'm using. java -classpath /net/users/jschewe/projects/test/build/ -Xmx256m -ea bugs.jdk.code129.SplitDB If I comment out the setIcon call in DatabaseDialog, then it's just fine. So my guess is that there's something with the signal handling when the image finishes loading. Do you have any ideas as to what JDEE/XEmacs may be doing when it executes the java process that would cause this to occur? Thanks for any input you have. Until then I'll have to resort to the commandline. BTW this happens also when running ant inside JDEE. Hi Jon, I have no problem running the test case that you sent from the JDEE on Windows XP with Emacs 21.3.1. The icon loads just fine. The problem thus cannot be the JDEE. You say you can run the program from the command line. Do you mean from an external shell or from an XEmacs shell buffer? If you cannot run it from a shell buffer in XEmacs or from the JDEE but you can run it from a Linux shell, that would indicate that the problem is with XEmacs. If so, I'd try to find out what code129 means. Paul Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.0.10 /HEAD BODY I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0.nbsp; I've also filed a bug report with Sun and sent this test case to one of their engineers.BR BR If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside JDEE.nbsp; If you run it from the commandline it's just fine. BR BR Here's the commandline I'm using.BR java -classpath /net/users/jschewe/projects/test/build/ -Xmx256m -ea bugs.jdk.code129.SplitDBBR BR If I comment out the setIcon call in DatabaseDialog, then it's just fine.nbsp; So my guess is that there's something with the signal handling when the image finishes loading.BR BR Do you have any ideas as to what JDEE/XEmacs may be doing when it executes the java process that would cause this to occur?BR BR Thanks for any input you have.nbsp; Until then I'll have to resort to the commandline.nbsp; BR BR BTW this happens also when running ant inside JDEE.BR BR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD HR BR Your mouse has moved.BR Windows must restart for change to take effect.BR Reboot now? [OK]BR A HREF="">http://web-unix.htc.honeywell.com/people/jscheweUhttp://web-unix.htc.honeywell.com/people/jschewe/U/A [Honeywell Intranet Only]BR *My views may not represent those of my employers /TD /TR /TABLE /BODY /HTML Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers
Re: problem with JDEE
Jon Schewe wrote: Thanks. I tried that by adding 21 to the end of prop-args in jde-run-vm-launch, but that didn't help. Got any other ideas? On Tue, 2004-10-12 at 08:32, Matthew Smith wrote: /I am having the same problem. If I add 21 to the compile command it works OK. This just started happening since I upgraded my JDEE. Looks like some problem handling STD ERR. Paul Kinnucan wrote: Jon Schewe writes: I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0. I've also filed a bug report with Sun and sent this test case to one of their engineers. If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside JDEE. If you run it from the commandline it's just fine. Here's the commandline I'm using. java -classpath /net/users/jschewe/projects/test/build/ -Xmx256m -ea bugs.jdk.code129.SplitDB If I comment out the setIcon call in DatabaseDialog, then it's just fine. So my guess is that there's something with the signal handling when the image finishes loading. Do you have any ideas as to what JDEE/XEmacs may be doing when it executes the java process that would cause this to occur? Thanks for any input you have. Until then I'll have to resort to the commandline. BTW this happens also when running ant inside JDEE. Hi Jon, I have no problem running the test case that you sent from the JDEE on Windows XP with Emacs 21.3.1. The icon loads just fine. The problem thus cannot be the JDEE. You say you can run the program from the command line. Do you mean from an external shell or from an XEmacs shell buffer? If you cannot run it from a shell buffer in XEmacs or from the JDEE but you can run it from a Linux shell, that would indicate that the problem is with XEmacs. If so, I'd try to find out what code129 means. Paul Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] //_http://web-unix.htc.honeywell.com/people/jschewe_ [Honeywell Intranet Only] *My views may not represent those of my employers !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.0.10 /HEAD BODY I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0.nbsp; I've also filed a bug report with Sun and sent this test case to one of their engineers.BR BR If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside JDEE.nbsp; If you run it from the commandline it's just fine. BR BR Here's the commandline I'm using.BR java -classpath /net/users/jschewe/projects/test/build/ -Xmx256m -ea bugs.jdk.code129.SplitDBBR BR If I comment out the setIcon call in DatabaseDialog, then it's just fine.nbsp; So my guess is that there's something with the signal handling when the image finishes loading.BR BR Do you have any ideas as to what JDEE/XEmacs may be doing when it executes the java process that would cause this to occur?BR BR Thanks for any input you have.nbsp; Until then I'll have to resort to the commandline.nbsp; BR BR BTW this happens also when running ant inside JDEE.BR BR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD HR BR Your mouse has moved.BR Windows must restart for change to take effect.BR Reboot now? [OK]BR A HREF=_http://web-unix.htc.honeywell.com/people/jschewe_ http://web-unix.htc.honeywell.com/people/jscheweU_http://web-unix.htc.honeywell.com/people/jschewe_/U/A [Honeywell Intranet Only]BR *My views may not represent those of my employers /TD /TR /TABLE /BODY /HTML / Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] _http://web-unix.htc.honeywell.com/people/jschewe_ [Honeywell Intranet Only] *My views may not represent those of my employers I use the 'compile' command in emacs. Then on the command line I use 'ant -emacs -find build.xml target 21' I'm not sure if that is of any help. I wonder if going back to an older JDEE would help.
Re: problem with JDEE
Jon Schewe writes: Thanks. I tried that by adding 21 to the end of prop-args in jde-run-vm-launch, but that didn't help. Got any other ideas? Hi Jon, The JDEE launches a Java process (see jde-run.el) by calling (save-w32-show-window (comint-exec run-buffer prog-name prog-path nil prog-args)) where save-w32-show-window is defined as: (defmacro save-w32-show-window (rest body) Saves the value of the w32-start-process-show-window variable before evaluating body and restores the value afterwards. `(let ((win32-start-process-show-window t) (w32-start-process-show-window t) (windowed-process-io t)) ,@body)) comint-exec is a standard Emacs/XEmacs function that is used by the compile command, the shell command, and other standard Emacs commands that allow the user to launch and interact with external processes. At some point, I don't recall when or by who, somebody added a binding for the variable windowed-process-io, which is defined by the XEmacs C code (i.e., it is a built-in XEmacs variable) and is not defined by Emacs, to save-w32-show-window macro. The doc says this variable should only be set if you have a Microsoft Windows GUI app that does standard I/O (GUI Windows apps typically do not do standard I/O). It would seem to me that this variable should not be set to t unconditionally as the JDEE currently does. There should be some JDEE variable that would allow you to specify whether the app you are about to launch is an app of the appropriate type. At any rate, the doc also says that this variable has no effect on Unix. Despite this, the facts that this variable affects process I/O under some circumstances and that the variable is only used by XEmacs seem to correlate strongly with the problem you are having. So I would suggest that you comment out the binding of this variable in the save-w32-show-window macro in jde-run.el, recompile jde-run.el if necessary, and see if that makes a difference. Paul On Tue, 2004-10-12 at 08:32, Matthew Smith wrote: I am having the same problem. If I add 21 to the compile command it works OK. This just started happening since I upgraded my JDEE. Looks like some problem handling STD ERR. Paul Kinnucan wrote: Jon Schewe writes: I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0. I've also filed a bug report with Sun and sent this test case to one of their engineers. If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside JDEE. If you run it from the commandline it's just fine. Here's the commandline I'm using. java -classpath /net/users/jschewe/projects/test/build/ -Xmx256m -ea bugs.jdk.code129.SplitDB If I comment out the setIcon call in DatabaseDialog, then it's just fine. So my guess is that there's something with the signal handling when the image finishes loading. Do you have any ideas as to what JDEE/XEmacs may be doing when it executes the java process that would cause this to occur? Thanks for any input you have. Until then I'll have to resort to the commandline. BTW this happens also when running ant inside JDEE. Hi Jon, I have no problem running the test case that you sent from the JDEE on Windows XP with Emacs 21.3.1. The icon loads just fine. The problem thus cannot be the JDEE. You say you can run the program from the command line. Do you mean from an external shell or from an XEmacs shell buffer? If you cannot run it from a shell buffer in XEmacs or from the JDEE but you can run it from a Linux shell, that would indicate that the problem is with XEmacs. If so, I'd try to find out what code129 means. Paul Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.0.10 /HEAD BODY I've noticed this problem under JDEE 2.3.4beta5 and 2.3.2 using XEmacs 21.4.15 on Linux kernel 2.6.5 and JDK 1.4.2_05 and JDK 1.5.0.nbsp; I've also filed a bug report with Sun and sent this test case to one of their engineers.BR BR If you compile and run bugs.jdk.code129.SplitDB and just wait, you don't have to press anything and it errors out with a code 129 when run from inside
JDEE release status?
Any update on when the next version of JDE will be released? Java 5.0 (aka 1.5) is released, so I'm sure people would love to have support for that in either a new release or beta (2.3.4beta5 is a bit old and not ready for prime-time). I realize the CVS heads is available Thanks!
Re: problem with JDEE
On Tue, 2004-10-12 at 11:00, Paul Kinnucan wrote: The doc says this variable should only be set if you have a Microsoft Windows GUI app that does standard I/O (GUI Windows apps typically do not do standard I/O). It would seem to me that this variable should not be set to t unconditionally as the JDEE currently does. There should be some JDEE variable that would allow you to specify whether the app you are about to launch is an app of the appropriate type. At The app here is defined as java or javaw, not the Java application being written, so I suspect the current JDEE behavior is correct. any rate, the doc also says that this variable has no effect on Unix. Despite this, the facts that this variable affects process I/O under some circumstances and that the variable is only used by XEmacs seem to correlate strongly with the problem you are having. So I would suggest that you comment out the binding of this variable in the save-w32-show-window macro in jde-run.el, recompile jde-run.el if necessary, and see if that makes a difference. I tried that and it doesn't help. I even commented out the call to the macro and evaluated the method again and still the same behavior. I tried adding 21 onto the end of my execution line and that doesn't seem to help either. Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers
Re: problem with JDEE
Jon Schewe writes: On Tue, 2004-10-12 at 11:00, Paul Kinnucan wrote: The doc says this variable should only be set if you have a Microsoft Windows GUI app that does standard I/O (GUI Windows apps typically do not do standard I/O). It would seem to me that this variable should not be set to t unconditionally as the JDEE currently does. There should be some JDEE variable that would allow you to specify whether the app you are about to launch is an app of the appropriate type. At The app here is defined as java or javaw, not the Java application being written, so I suspect the current JDEE behavior is correct. any rate, the doc also says that this variable has no effect on Unix. Despite this, the facts that this variable affects process I/O under some circumstances and that the variable is only used by XEmacs seem to correlate strongly with the problem you are having. So I would suggest that you comment out the binding of this variable in the save-w32-show-window macro in jde-run.el, recompile jde-run.el if necessary, and see if that makes a difference. I tried that and it doesn't help. I even commented out the call to the macro and evaluated the method again and still the same behavior. I tried adding 21 onto the end of my execution line and that doesn't seem to help either. I'm grasping at straws here but you could try adding (setq process-connection-type nil) to your .emacs file. This variable is set to t by default on XEmacs. If I understand the doc correctly, this tells XEmacs to use pseudo terminal (pty) commands to connect to the external process. I believe Java uses pipes for interprocess communications. Thus if XEmacs is using pty and Java is expecting pipes, there could be a problem. Paul Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers
Re: problem with JDEE
On Tue, 2004-10-12 at 13:07, Paul Kinnucan wrote: Jon Schewe writes: On Tue, 2004-10-12 at 11:00, Paul Kinnucan wrote: The doc says this variable should only be set if you have a Microsoft Windows GUI app that does standard I/O (GUI Windows apps typically do not do standard I/O). It would seem to me that this variable should not be set to t unconditionally as the JDEE currently does. There should be some JDEE variable that would allow you to specify whether the app you are about to launch is an app of the appropriate type. At The app here is defined as java or javaw, not the Java application being written, so I suspect the current JDEE behavior is correct. any rate, the doc also says that this variable has no effect on Unix. Despite this, the facts that this variable affects process I/O under some circumstances and that the variable is only used by XEmacs seem to correlate strongly with the problem you are having. So I would suggest that you comment out the binding of this variable in the save-w32-show-window macro in jde-run.el, recompile jde-run.el if necessary, and see if that makes a difference. I tried that and it doesn't help. I even commented out the call to the macro and evaluated the method again and still the same behavior. I tried adding 21 onto the end of my execution line and that doesn't seem to help either. I'm grasping at straws here but you could try adding (setq process-connection-type nil) to your .emacs file. This variable is set to t by default on XEmacs. If I understand the doc correctly, this tells XEmacs to use pseudo terminal (pty) commands to connect to the external process. I believe Java uses pipes for interprocess communications. Thus if XEmacs is using pty and Java is expecting pipes, there could be a problem. That's it! I turned that off and now it's happy. Now the question is, what's the best way to get this into JDEE without breaking everyone else's applications? Your mouse has moved. Windows must restart for change to take effect. Reboot now? [OK] http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers
[ANNOUNCEMENT] JDEE 2.3.4beta6 available at ...
http://jdee.sunsite.dk/rootpage.html#Downloading JDE 2.3.4beta6 *** * PLEASE READ * *** * * * This release requires cedet 1.0beta2 or later. cedet* * includes semantic, eieio, speedbar, and senator, all* * packages required by the JDEE. You can obtain cedet * * at http://cedet.sourceforge.net * * * * Please note that your .emacs file must load cedet.el, * * not require cedet. See the installation instructions * * that come with the cedet package for more information. * * * * This release requires version 1.2.2 (or later) of the * * JDK.* * * * This release also requires avltree.el, which is part of the * * elib 1.0 package. You can obtain elib at the JDE web site * * in compressed tar (http://jdee.sunsite.dk/elib.tar.gz) * * or zip (http://sunsite.dk/jde/elib.zip) format. * * * * JDEbug runs on Windows 2000 only if Service Pack 2 (or * * later) is installed.* * * * If syntax-coloring does not work, download and install * * overlay-fix.el from the semantic web site. * * * *** * Moved JUnit templates to a separate package jde-junit.el and added some contributed commands for starting unit tests. This restructuring is preparatory to providing more systematic support for unit testing in the JDEE in future releases. * Configured the JDEE to always use pipes (rather than pseudo terminals) to communicate with external processes (see process-connection-type for more info). This change assumes that Java processes expect to use pipes. This change fixes a Code 129 error with XEmacs on some Linux operating systems and may fix similar errors on Linux with Emacs. * Fixed Emacs interface to JDEbug so that it handles chunked responses to debugger commands. Thanks to Brian Rumple. * If jde-run-application-class is a jar file, expand any environment variables or relative path indicators in the jar file path. Thanks to Joshua Spiewak. * The JDEE now supports use of emacs-w3m to browse Javadoc files. To use emacs-w3m, set jde-help-browser-function to w3m-browse-url. * Fixes bug that caused the generation of an extraneous slash in Javadoc URLs on UNIX systems. * Adds an Import submenu to the Code Generation menu. The submenu contains all of the JDEE's import-related commands. * JDEE now allows the plugins directory to be under CVS or RCS version control, i.e., to contain a directory named CVS or RCS. * Fixes regressions that broke applet debugging. * Upgrades BeanShell from version 1.2.7 to version 2.0b2. * Update the class list used by completion and by code generation wizards after compiling a class or building a project. This should ensure that completion and the wizards work for new classes and changes to existing classes after compiling new or changed classes. * This release includes the following enhancements to the JDEE's class import wizard. - A new customization variable: jde-import-excluded-classes. The new variable replaces jde-import-excluded-packages, which the JDEE no longer defines. The new variable provides the following new class exclusion options. - It allows you to use Lisp functions as well as regular expressions to specify exclusion rules. - It allows you to specify that a rule excludes all unqualified synonyms of a class that meets the rule. For example, one of the default rules specifed by this variable excludes java.lang.String as well as any other class whose unqualified name is String. - This release adds the jde-import-expand-imports command. This command replaces package imports, e.g., java.io.* with imports of the classes specifically referenced by the current buffer. - The following commands now include a prefix argument that causes all classes to be imported, regardless of the setting of jde-import-excluded-classes. - jde-import-find-and-import - jde-import-all-filter - jde-import-all - This release includes a new import organization option: jde-import-blank-line-between-groups. Thanks to Martin Schwamberger for these enhancements. * Fixed bugs that caused
