Re: Problem with JDEE 2.3.4

[Paul Kinnucan]

Jason Baker writes:
 > I have an idea for speeding up jde-open-source and
 > jde-find-and-import.  I'd like to see them read classes of the form
 > : from the minibuffer with standard emacs
 > completion.
 > 
 > Suppose you are trying to import the name C where p1.p2.p3.C and
 > p1.p4.p5.C are defined.  jde-find-and-import should prompt with.
 > `Choose a class to import: C:'  From there, one can type the first
 > letter of p1, , the first letter of p4, , , and get
 > an import of p1.p4.p5.C.  This is a lot faster than reaching for a
 > mouse, or any other option jde currently provides.

What happens if p2 and p4 begin with the same letter? In any event,
I'd be happy to see tab completion when a user has to choose 
among qualified class names. I've a lot of other things I'd
rather do at the moment, however, so it won't happen soon unless
someelse contributes the necessary Lisp.

Paul

Re: Problem with JDEE 2.3.4

[Jason Baker]

Paul Kinnucan <[EMAIL PROTECTED]> writes:

> Jon Schewe writes:
>  > Can you please not override efc-query-options-function with a function
>  > that creates a dialog box even if the user has asked XEmacs not to
>  > display them under any circumstances?  Please rewrite this to pay
>  > attention to the use-dialog-box variable.
>  > 
>  > `use-dialog-box' is a variable declared in Lisp.
>  >   -- loaded from "/usr/share/xemacs/21.4.15/lisp/minibuf.elc"
>  > 
>  > Value: nil
>  > 
>  > Documentation:
>  > *Variable controlling usage of the dialog box.
>  > If nil, the dialog box will never be used, even in response to mouse
>  > events.

I've been using the following.
Index: efc.el
===
RCS file: /p/sss/cvs/jde/lisp/efc.el,v
retrieving revision 1.1.1.1
diff -c -c -r1.1.1.1 efc.el
*** efc.el  31 Oct 2004 23:58:41 -  1.1.1.1
--- efc.el  4 Nov 2004 20:14:14 -
***
*** 40,45 
--- 40,64 
"If non-nil the function to use for interactively querying options.
  If nil then the default efc custom-based dialogs will be used.")
  
+ ;;; Minibuffer interface
+ (defvar efc-query-options-history nil
+   "History of efc option values selected through the minibuffer")
+ 
+ (defun efc-query-options-with-minibuffer (&optional disable)
+   "Choose whether to enter efc options through a dialog box or the minibuffer.
+ By default this function sets `efc-query-options-function' to use read 
+ input from the minibuffer.  With a prefix argument, this function clears
+ `efc-query-option-function' to re-enable dialog boxes."
+   (interactive "P")
+   (setq efc-query-options-function
+   (if disable
+   nil
+ (lambda (options prompt title)
+   (completing-read prompt
+(mapcar (lambda (x) (cons x t)) options)
+nil t nil
+'efc-query-options-history)
+ 
  

  ;;
;; 
  ;; Dialog Class   
;;

and calling efc-query-options-with-minibuffer from .xemacs/init.el.

I did not submit this to the patches list because I don't think it is
the best solution for many efc-query-options clients.

I have an idea for speeding up jde-open-source and
jde-find-and-import.  I'd like to see them read classes of the form
: from the minibuffer with standard emacs
completion.

Suppose you are trying to import the name C where p1.p2.p3.C and
p1.p4.p5.C are defined.  jde-find-and-import should prompt with.
`Choose a class to import: C:'  From there, one can type the first
letter of p1, , the first letter of p4, , , and get
an import of p1.p4.p5.C.  This is a lot faster than reaching for a
mouse, or any other option jde currently provides.

Jason

Re: problem with JDEE

[Jon Schewe]

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 2>&1 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

Re: problem with JDEE

[Paul Kinnucan]

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 2>&1 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

[Jon Schewe]

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 2>&1 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

[Paul Kinnucan]

Jon Schewe writes:
 > Thanks.  I tried that by adding " 2>&1 " 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 2>&1 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
 > > > > 
 > > > > 
 > > > > 
 > > > >   
 > > > >   
 > > > > 
 > > > > 
 > > > > 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 an

Re: problem with JDEE

[Matthew Smith]

Jon Schewe wrote:
Thanks.  I tried that by adding " 2>&1 " 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 2>&1 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
> 
> 
> 
>   
>   
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> Your mouse has moved.
> Windows must restart for change to take effect.
> Reboot now? [OK]
> http://web-unix.htc.honeywell.com/people/jschewe"_ >_http://web-unix.htc.honeywell.com/people/jschewe_ [Honeywell Intranet Only]
> *My views may not represent those of my employers
> 
> 
> 
> 
> 
> 

 
/


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 2>&1'  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]

Thanks.  I tried that by adding " 2>&1 " 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 2>&1 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
> > 
> > 
> > 
> >   
> >   
> > 
> > 
> > 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.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Your mouse has moved.
> > Windows must restart for change to take effect.
> > Reboot now? [OK]
> > http://web-unix.htc.honeywell.com/people/jschewe">http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only]
> > *My views may not represent those of my employers
> > 
> > 
> > 
> > 
> > 
> > 
>
>  
>







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

[Matthew Smith]

I am having the same problem.  If I add 2>&1 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
> 
> 
> 
>   
>   
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> Your mouse has moved.
> Windows must restart for change to take effect.
> Reboot now? [OK]
> http://web-unix.htc.honeywell.com/people/jschewe";>http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet Only]
> *My views may not represent those of my employers
> 
> 
> 
> 
> 
> 

 

Re: Problem with JDEE

[YAMANO Yuji]

On Tue, 09 Sep 2003 10:55:37 +0200
Manal Habbouche <[EMAIL PROTECTED]> wrote:

> Can you help me with this problem.
> I am using  GNU Emacs 20.7.1, JDE 2.3.2, speedbar 0.14beta4, eioeio
> 0.17, semantic 1.4.4 and elib-1.0.
> 
>  On Emacs startup, I get the error 
>  Signaling: (file-error "Cannot open load file" "eieio")
>require(eieio)
>eval-buffer(#> nil "beanshell")

Did you add the eieio directory to the emacs load-path?
If not, see http://jdee.sunsite.dk/_emacs_jde.

-- 
YAMANO Yuji <[EMAIL PROTECTED]>
Everybody's got a little light under the sun. --George Clinton