Re: use w3 instead of wget?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Knut Wannheden <[EMAIL PROTECTED]> writes: > I have a small comment regarding jde-help. I've seen that the > function jde-help-symbol makes use of the function > jde-help-find-javadoc which checks whether a certain url exists. It > does that by invoking the shell command wget. I think wget is a nice > utility but I think it would be even nicer to use the w3 package. w3 has performance issues. It would be better to toggle between wget/lynx. I have a lynx-mode.el if anyone is interested... http://relativity.yi.org/emacs - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 Never under estimate the power of a hacker! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6zJeWAwM6xb2dfE0RAq4eAJwJCKmQK6S6TtskVeonk02xiwl0jACgvW9m ttK7fd22Nqa2sVmG0Ou4fF8= =lbjy -END PGP SIGNATURE-
RE: jde-save-project misses some jde variables
NS> OK, here's one. Do you still have the old project file handy? If NS> so, can you check the lines that contain the above variables and NS> verify that they look like this: NS> NS> '( t) NS> ^ NS> | NS> The presence of `t' here is what tells JDE to put the value into NS> the customized-value property upon load. If it is missing, then NS> that's your reason why the new project file doesn't contain those NS> variables. Great advice, Nick. Thank you! Indeed this prj.el file has been carried along for several jde revs and many of my customized variables (all customized using the recommended emacs interface) were not marked. This problem is now fixed. Thanks again! -- Robert
RE: jde-save-project misses some jde variables
> From: Robert Mecklenburg [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 12:51 PM > > > RM> jde-compile-option-sourcepath > RM> jde-compile-option-directory > RM> jde-gen-cflow-if > RM> jde-gen-cflow-else > RM> jde-gen-cflow-elseif > RM> jde-gen-cflow-while > RM> jde-gen-cflow-for > RM> [ are not being saved ] > > It seems possible that reading a prj.el from 2.2.6 doesn't generate > the correct properties. Do I need to abandon my last prj.el file and > build a new one. I have a lot of customizations which would be > painful to merge by hand. Any suggestions? OK, here's one. Do you still have the old project file handy? If so, can you check the lines that contain the above variables and verify that they look like this: '( t) ^ | The presence of `t' here is what tells JDE to put the value into the customized-value property upon load. If it is missing, then that's your reason why the new project file doesn't contain those variables. /Nick
RE: jde-save-project misses some jde variables
At 11:50 AM 4/5/01 -0600, Robert Mecklenburg wrote:
>RM> jde-compile-option-sourcepath
>RM> jde-compile-option-directory
>RM> jde-gen-cflow-if
>RM> jde-gen-cflow-else
>RM> jde-gen-cflow-elseif
>RM> jde-gen-cflow-while
>RM> jde-gen-cflow-for
>RM> [ are not being saved ]
>
>RM> Notice that jde-gen-cflow-* aren't being saved for me and those
>RM> are not in my .emacs customization.
>
>NS> Let me understand - are you customizing jde-compile-option-* and
>NS> jde-gen-cflow-* at the project level?
>
>Okay, here is some more information. I have been saving my jde
>customizations in the file prj.el (using jde-save-project) at the top
>level of my project. When I upgraded from 2.2.6 I did not alter or
>delete my existing prj.el file. I just let jde read the file and
>decide for itself which variables have been customize and which have
>not.
>
>After a little more investigation, here's what I've learned. From my
>*scratch* buffer:
>
>;;; this is modified from the defaults
>jde-gen-cflow-if
>("(if (jde-parse-comment-or-quoted-p)" "'(l \"if\")" "'(l '> \"if (\" (p
>\"if-clause: \" clause) \" )\"" "(if jde-gen-k&r " "()" "'>'n)"
>"\"{\"'>'n'>'r'n" "\"}\"'>'n'>)" ")")
>
>;;; the custom-type matches the defcustom sexp
>(get 'jde-gen-cflow-if 'custom-type)
>(repeat string)
>
>;;; Oops, shouldn't this be non-ni?
>(get 'jde-gen-cflow-if 'customized-value)
>nil
It should be, IF you used customize to set the value and the customization
was valid. However, if you used a setq statement somewhere, say in your
.emacs file, to set this variable, the 'customized-value property would
not be set. Certainly
get 'jde-gen-cflow-if 'customized-value)
returns the customized value on my system.
- Paul
>
>
>It seems possible that reading a prj.el from 2.2.6 doesn't generate
>the correct properties. Do I need to abandon my last prj.el file and
>build a new one. I have a lot of customizations which would be
>painful to merge by hand. Any suggestions?
>
>
>NS> Maybe you should submit a problem report at this point.
>
>Actually, my first message was a problem report. I hesitate to repost
>it since Paul obviously got it.
>
>Thanks again!
>--
>Robert
RE: jde-save-project misses some jde variables
RM> jde-compile-option-sourcepath
RM> jde-compile-option-directory
RM> jde-gen-cflow-if
RM> jde-gen-cflow-else
RM> jde-gen-cflow-elseif
RM> jde-gen-cflow-while
RM> jde-gen-cflow-for
RM> [ are not being saved ]
RM> Notice that jde-gen-cflow-* aren't being saved for me and those
RM> are not in my .emacs customization.
NS> Let me understand - are you customizing jde-compile-option-* and
NS> jde-gen-cflow-* at the project level?
Okay, here is some more information. I have been saving my jde
customizations in the file prj.el (using jde-save-project) at the top
level of my project. When I upgraded from 2.2.6 I did not alter or
delete my existing prj.el file. I just let jde read the file and
decide for itself which variables have been customize and which have
not.
After a little more investigation, here's what I've learned. From my
*scratch* buffer:
;;; this is modified from the defaults
jde-gen-cflow-if
("(if (jde-parse-comment-or-quoted-p)" "'(l \"if\")" "'(l '> \"if (\" (p \"if-clause:
\" clause) \" )\"" "(if jde-gen-k&r " "()" "'>'n)" "\"{\"'>'n'>'r'n" "\"}\"'>'n'>)"
")")
;;; the custom-type matches the defcustom sexp
(get 'jde-gen-cflow-if 'custom-type)
(repeat string)
;;; Oops, shouldn't this be non-ni?
(get 'jde-gen-cflow-if 'customized-value)
nil
It seems possible that reading a prj.el from 2.2.6 doesn't generate
the correct properties. Do I need to abandon my last prj.el file and
build a new one. I have a lot of customizations which would be
painful to merge by hand. Any suggestions?
NS> Maybe you should submit a problem report at this point.
Actually, my first message was a problem report. I hesitate to repost
it since Paul obviously got it.
Thanks again!
--
Robert
RE: jde-save-project misses some jde variables
> From: Robert Mecklenburg [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 12:11 PM > > > RM> jde-compile-option-sourcepath > RM> jde-compile-option-directory > RM> jde-gen-cflow-if > RM> jde-gen-cflow-else > RM> jde-gen-cflow-elseif > RM> jde-gen-cflow-while > RM> jde-gen-cflow-for > RM> [ are not being saved ] > > Wow, thanks for the speedy reply. > > Yes, I saw that fix but my problem seems to occur with variables that > do not appear in my .emacs customization. I worked around the most > severe problems by placing jde-compile-option-directory and > jde-compile-option-sourcepath in my .emacs only _after_ I discovered > they weren't being saved. Notice that jde-gen-cflow-* aren't being > saved for me and those are not in my .emacs customization. Let me understand - are you customizing jde-compile-option-* and jde-gen-cflow-* at the project level? If not, then this is the intended behavior that was implemented recently - beta6 I think - where non-customized values are excluded from the project file. If you are customizing them, and they're still not being saved, then maybe we have another bug. Maybe you should submit a problem report at this point. /Nick
Re: jde-save-project misses some jde variables
At 11:11 AM 4/5/01 -0600, Robert Mecklenburg wrote: >RM> jde-compile-option-sourcepath >RM> jde-compile-option-directory I just saved both of the above in a project file without any problems. I didn't bother with the others because I have no reason to assume they wouldn't work as well. I am using Emacs 20.7.1, JDE-2.2.7beta6+ on Windows NT. - Paul
Re: jde-save-project misses some jde variables
RM> jde-compile-option-sourcepath RM> jde-compile-option-directory RM> jde-gen-cflow-if RM> jde-gen-cflow-else RM> jde-gen-cflow-elseif RM> jde-gen-cflow-while RM> jde-gen-cflow-for RM> [ are not being saved ] PK> There is a bug (and a fix) for the case where the JDE fails to PK> save a customization in a project file that overrides a PK> customizaiton in the .emacs file. See the mailing list archive for PK> details. Wow, thanks for the speedy reply. Yes, I saw that fix but my problem seems to occur with variables that do not appear in my .emacs customization. I worked around the most severe problems by placing jde-compile-option-directory and jde-compile-option-sourcepath in my .emacs only _after_ I discovered they weren't being saved. Notice that jde-gen-cflow-* aren't being saved for me and those are not in my .emacs customization. Thanks again, -- Robert
Re: jde-save-project misses some jde variables
Hi,
There is a bug (and a fix) for the case where the JDE fails to save a
customization in a project file that overrides a customizaiton in the
.emacs file. See the mailing list archive for details.
- Paul
At 10:48 AM 4/5/01 -0600, Robert Mecklenburg <[EMAIL PROTECTED]> wrote:
>I love jde and appreciate all the work you've put into it. Good work!
>
>I've been using 2.2.7beta6 and found that my prj.el file is now
>missing several variables I've customized. The ones I've noticed so
>far are:
>
> jde-compile-option-sourcepath
> jde-compile-option-directory
> jde-gen-cflow-if
> jde-gen-cflow-else
> jde-gen-cflow-elseif
> jde-gen-cflow-while
> jde-gen-cflow-for
>
>Does anyone else see this?
>
>Thanks!
>
>
>
>Emacs : GNU Emacs 20.7.1 (i386-*-nt5.0.2195)
> of Tue Jun 13 2000 on buffy
>Package: JDE version 2.2.7beta6
>
>current state:
>==
>(setq
> jde-gen-session-bean-template '("(jde-import-insert-imports-into-buffer
>(list \"javax.ejb.*\"\n\"java.rmi.RemoteException\"))"
>"(jde-wiz-update-implements-clause \"SessionBean\")" "'> \"public void
>ejbActivate() throws RemoteException {\"'>'n \"}\"'>'n\n'>'n" "'> \"public
>void ejbPassivate() throws RemoteException {\"'>'n \"}\"'>'n\n'>'n" "'>
>\"public void ejbRemove() throws RemoteException {\"'>'n \"}\"'>'n '>'n" "'>
>\"public void setSessionContext(SessionContext ctx) throws\nRemoteException
>{\"" "'>'n \"}\"'>'n '>'n" "'> \"public void unsetSessionContext() throws
>RemoteException {\"'>'n\n\"}\"'>'n '>'n'>")
> jde-gen-beep '("(end-of-line) '&"
>"\"Toolkit.getDefaultToolkit().beep();\"'>'n'>")
> jde-project-name "quixote"
> jde-which-method-format '("[" jde-which-method-current "]")
> jde-run-classic-mode-vm t
> jde-javadoc-gen-nodeprecatedlist nil
> jde-which-method-max-length 20
> jde-package-search-classpath-variables '(jde-compile-option-classpath
>jde-global-classpath)
> jde-imenu-include-classdef t
> jde-javadoc-gen-link-online nil
> jde-gen-code-templates '(("Get Set Pair" . jde-gen-get-set)
> ("toString method" . jde-gen-to-string-method)
> ("Action Listener" . jde-gen-action-listener)
> ("Window Listener" . jde-gen-window-listener)
> ("Mouse Listener" . jde-gen-mouse-listener)
> ("Mouse Motion Listener" . jde-gen-mouse-motion-listener)
> ("Inner Class" . jde-gen-inner-class) ("println" .
>jde-gen-println)
> ("beep" . jde-gen-beep)
> ("property change support" . jde-gen-property-change-support)
> ("EJB Entity Bean" . jde-gen-entity-bean)
> ("EJB Session Bean" . jde-gen-session-bean))
> jde-gen-cflow-else '("(if (jde-parse-comment-or-quoted-p)" "'(l \"else\")"
>"'(l '> \"else \""
> "(if jde-gen-k&r " "()" "'>'n)" "\"{\"'>'n'>'r'n"
> "\"} // end of else\"'>'n'>)" ")")
> jde-make-args ""
> jde-javadoc-gen-destination-directory "JavaDoc"
> jde-mode-line-format '("-" mode-line-mule-info mode-line-modified
>mode-line-frame-identification
> mode-line-buffer-identification " " global-mode-string "
>%[("
> mode-name mode-line-process minor-mode-alist "%n" ")%]--"
> (line-number-mode "L%l--") (column-number-mode "C%c--") (-3 .
>"%p")
> (jde-which-method-mode ("--" jde-which-method-format "--"))
>"-%-")
> jde-mode-abbreviations '(("ab" . "abstract") ("bo" . "boolean") ("br" .
>"break") ("by" . "byte")
> ("byv" . "byvalue") ("cas" . "cast") ("ca" . "catch") ("ch"
>. "char")
> ("cl" . "class") ("co" . "const") ("con" . "continue")
> ("de" . "default") ("dou" . "double") ("el" . "else") ("ex"
>. "extends")
> ("fa" . "false") ("fi" . "final") ("fin" . "finally") ("fl"
>. "float")
> ("fo" . "for") ("fu" . "future") ("ge" . "generic") ("go" .
>"goto")
> ("impl" . "implements") ("impo" . "import") ("ins" .
>"instanceof")
> ("in" . "int") ("inte" . "interface") ("lo" . "long") ("na"
>. "native")
> ("ne" . "new") ("nu" . "null") ("pa" . "package") ("pri" .
>"private")
> ("pro" . "protected") ("pu" . "public") ("re" . "return")
> ("sh" . "short") ("st" . "static") ("su" . "super") ("sw" .
>"switch")
> ("sy" . "synchronized") ("th" . "this") ("thr" . "throw")
> ("throw" . "throws") ("tra" . "transient") ("tr" . "true")
> ("vo" . "void") ("vol" . "volatile") ("wh" . "while"))
> jde-imenu-enable t
> jde-compile-option-verbose nil
> jde-db-option-heap-size '((1 . "megabytes") (16 . "megabytes"))
> jde-bug-debugger-host-add
jde-save-project misses some jde variables
I love jde and appreciate all the work you've put into it. Good work!
I've been using 2.2.7beta6 and found that my prj.el file is now
missing several variables I've customized. The ones I've noticed so
far are:
jde-compile-option-sourcepath
jde-compile-option-directory
jde-gen-cflow-if
jde-gen-cflow-else
jde-gen-cflow-elseif
jde-gen-cflow-while
jde-gen-cflow-for
Does anyone else see this?
Thanks!
Emacs : GNU Emacs 20.7.1 (i386-*-nt5.0.2195)
of Tue Jun 13 2000 on buffy
Package: JDE version 2.2.7beta6
current state:
==
(setq
jde-gen-session-bean-template '("(jde-import-insert-imports-into-buffer (list
\"javax.ejb.*\"\n\"java.rmi.RemoteException\"))" "(jde-wiz-update-implements-clause
\"SessionBean\")" "'> \"public void ejbActivate() throws RemoteException {\"'>'n
\"}\"'>'n\n'>'n" "'> \"public void ejbPassivate() throws RemoteException {\"'>'n
\"}\"'>'n\n'>'n" "'> \"public void ejbRemove() throws RemoteException {\"'>'n
\"}\"'>'n '>'n" "'> \"public void setSessionContext(SessionContext ctx)
throws\nRemoteException {\"" "'>'n \"}\"'>'n '>'n" "'> \"public void
unsetSessionContext() throws RemoteException {\"'>'n\n\"}\"'>'n '>'n'>")
jde-gen-beep '("(end-of-line) '&" "\"Toolkit.getDefaultToolkit().beep();\"'>'n'>")
jde-project-name "quixote"
jde-which-method-format '("[" jde-which-method-current "]")
jde-run-classic-mode-vm t
jde-javadoc-gen-nodeprecatedlist nil
jde-which-method-max-length 20
jde-package-search-classpath-variables '(jde-compile-option-classpath
jde-global-classpath)
jde-imenu-include-classdef t
jde-javadoc-gen-link-online nil
jde-gen-code-templates '(("Get Set Pair" . jde-gen-get-set)
("toString method" . jde-gen-to-string-method)
("Action Listener" . jde-gen-action-listener)
("Window Listener" . jde-gen-window-listener)
("Mouse Listener" . jde-gen-mouse-listener)
("Mouse Motion Listener" . jde-gen-mouse-motion-listener)
("Inner Class" . jde-gen-inner-class) ("println" .
jde-gen-println)
("beep" . jde-gen-beep)
("property change support" . jde-gen-property-change-support)
("EJB Entity Bean" . jde-gen-entity-bean)
("EJB Session Bean" . jde-gen-session-bean))
jde-gen-cflow-else '("(if (jde-parse-comment-or-quoted-p)" "'(l \"else\")" "'(l '>
\"else \""
"(if jde-gen-k&r " "()" "'>'n)" "\"{\"'>'n'>'r'n"
"\"} // end of else\"'>'n'>)" ")")
jde-make-args ""
jde-javadoc-gen-destination-directory "JavaDoc"
jde-mode-line-format '("-" mode-line-mule-info mode-line-modified
mode-line-frame-identification
mode-line-buffer-identification " " global-mode-string "
%[("
mode-name mode-line-process minor-mode-alist "%n" ")%]--"
(line-number-mode "L%l--") (column-number-mode "C%c--") (-3 .
"%p")
(jde-which-method-mode ("--" jde-which-method-format "--"))
"-%-")
jde-mode-abbreviations '(("ab" . "abstract") ("bo" . "boolean") ("br" . "break")
("by" . "byte")
("byv" . "byvalue") ("cas" . "cast") ("ca" . "catch") ("ch"
. "char")
("cl" . "class") ("co" . "const") ("con" . "continue")
("de" . "default") ("dou" . "double") ("el" . "else") ("ex"
. "extends")
("fa" . "false") ("fi" . "final") ("fin" . "finally") ("fl"
. "float")
("fo" . "for") ("fu" . "future") ("ge" . "generic") ("go" .
"goto")
("impl" . "implements") ("impo" . "import") ("ins" .
"instanceof")
("in" . "int") ("inte" . "interface") ("lo" . "long") ("na"
. "native")
("ne" . "new") ("nu" . "null") ("pa" . "package") ("pri" .
"private")
("pro" . "protected") ("pu" . "public") ("re" . "return")
("sh" . "short") ("st" . "static") ("su" . "super") ("sw" .
"switch")
("sy" . "synchronized") ("th" . "this") ("thr" . "throw")
("throw" . "throws") ("tra" . "transient") ("tr" . "true")
("vo" . "void") ("vol" . "volatile") ("wh" . "while"))
jde-imenu-enable t
jde-compile-option-verbose nil
jde-db-option-heap-size '((1 . "megabytes") (16 . "megabytes"))
jde-bug-debugger-host-address "OOPS"
jde-make-working-directory ""
jde-bug-breakpoint-marker-colors '("red" . "yellow")
jde-javadoc-gen-use nil
jde-gen-buffer-boilerplate nil
jde-bug-raise-frame-p t
jde-db-option-application-args nil
jde-javadoc-gen-nonavbar nil
jde-javadoc-gen-nohelp nil
jde-bug-vm-includes-jpda-p nil
jde-gen-jfc-app-buffer-template '("(funcall j
Re: senator.el is gone from CVS
At 06:23 PM 4/5/01 +0200, you wrote: >I don't get the lisp/senator.el package from CVS, but it was included >in the 2.2.6 distribution. The missing .el file results in: The JDE CVS repository is intended to facilitate development of the JDE. It is not intended to serve as a source for independently developed packages required by and, in some cases, distributed with the JDE. You appear to be upgrading your installation from the JDE CVS respository. This is a very bad idea as the CVS repository is not guaranteed to be stable. It contains work-in-progress that may break other features. I occasionally make between-release bug fixes available via the CVS repository. You should only download the specific file or files that I indicate when announcing such bug fixes. - Paul
RE: Generating javadoc for an entire project...
It would be nice to have a way to generate javadocs for every package below a given package. I don't know about most of you, but we have a huge package structure & I don't want to have to change that jde-javadoc-gen-packages variable every time I add a new sub-package. Is there a way to do this in the current JDE? For now I just take the output of the single file javadoc generation & replace the filename with: `find . -name '*.java'` Of course I have to do this at the command line. -Jeremy > -- > From: Paul Kinnucan[SMTP:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 5:00 AM > To: Marc Brooks; JDE Mailing list > Subject: Re: Generating javadoc for an entire project... > > At 05:53 PM 4/4/2001 -0400, Marc Brooks wrote: > >Hi all - Is it possible to generate javadoc for an entire project at > >once? > > > > 1. Type M-x customize-variable jde-gen-javadoc-packages. > > 2. Enter the packages in your project that you want to document. > > 3. Switch back to a source buffer. > > 4. Select JDE->Project->Project File->Save (or type C-c C-v C-p) to >save the project file for the project. > > From now on, the JDE will generate documentation for your entire project > whenever you execute JDE->Documentation->Generate (M-x jde-javadoc-make). > > - Paul >
RE: AW: AW: JDebug Improvement Suggestion
At 10:54 AM 4/5/01 -0500, "Nick Sieger" <[EMAIL PROTECTED]> wrote:
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, April 05, 2001 10:45 AM
>
>[...]
>
>> trying out more of the commands and helping with debugging. My favorite
>> command would be a fully functional "evaluate expression". I know you
>> have said in the past that JPDA doesn't support this, but there must be
>> some way to at kludge it as I know of other JPDA based debuggers, e.g.
>> JBuilder Professional, that support this functionality.
>>
>
>My apologies if this has been thought of, but it seems like a perfect fit
>and a relatively quick implementation to simply use the beanshell (or some
>subset of the beanshell classes) inside the same JVM as JDEbug for
>expression evaluation. Of course, now that I've mentioned it, I should
>probably put my money where my mouth is and code it up myself. Maybe if I
>get time... Anyway, just wanted to throw that out there as it seems like a
>good solution with a minimal amount of new code to write.
This won't work. The expression evaluator has to use JPDA functions to
access the values of variables defined by the debuggee process. JDEbug has
a simple arithmetic expression parser. Here is how it works:
1. Parse expression (e.g., a+b) to determine operator and operands, e.g.,
op = "+"; opl = "a"; opr = "b";
2. Use JPDA method to obtain value of operands in the debuggee process.
3. Apply operand to operands, using a switch statement based on operand
type, e.g.
switch (op) {
case plus:
result = opl + opr;
case mult:
result = opl * opr;
default:
error("Unknown operand");
}
4. Display result to user.
My plan is to enhance the expression evaluator to handle most Java
expressions, using a parser generated by javacc. I started this work more
than a year ago but got sidetracked by editing engine enhancements.
- Paul
senator.el is gone from CVS
I don't get the lisp/senator.el package from CVS, but it was included
in the 2.2.6 distribution. The missing .el file results in:
While compiling toplevel forms in file
/u/serum/d2/share/gnu/emacs/site-lisp/jde-cvs/lisp/jde.el:
!! File error (("Cannot open load file" "senator"))
My CVS/Root file says:
:pserver:[EMAIL PROTECTED]:/pack/anoncvs
Should it be included, or should I obtain it from somewhere else?
(... which is not the 2.6 distribution.)
The semantic package documentation mentions Semantor, but it is not
included id semantic-1.3.3.tar.gz.
BTW, senator-isearch.el seems to be gone too.
Affi
RE: AW: AW: JDebug Improvement Suggestion
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 10:45 AM [...] > trying out more of the commands and helping with debugging. My favorite > command would be a fully functional "evaluate expression". I know you > have said in the past that JPDA doesn't support this, but there must be > some way to at kludge it as I know of other JPDA based debuggers, e.g. > JBuilder Professional, that support this functionality. > My apologies if this has been thought of, but it seems like a perfect fit and a relatively quick implementation to simply use the beanshell (or some subset of the beanshell classes) inside the same JVM as JDEbug for expression evaluation. Of course, now that I've mentioned it, I should probably put my money where my mouth is and code it up myself. Maybe if I get time... Anyway, just wanted to throw that out there as it seems like a good solution with a minimal amount of new code to write. /Nick
Re: website crashes browser
Oops... I guess you already have a non-java version. I turned off java in my Linux browser and the guide loaded fine... Jason Stell wrote: > I'm running Redhat 7 (with newer kernel 2.2.18) and NS 4.76 and my > browser freezes while trying to load the navigation applet. > My NT4 box with NS 4.76 manages to load the applet okay (after some > delay). Paul -- could you add a non-java option for the user guide > link? > > V/R > Jason Stell > > Peter Rooney wrote: > > > thanks for all the hard work! > > > > i'm running mandrake linux (2.2.12), using netscape 4.7, and the > > jde.sunsite.dk site totally crashes my browser, rendering the online > > docs powerless to help me out. frames make lynx a pain. > > > > i've wget'ed stuff down to my local machine so it's not urgent but > > thought i'd let you know. > > > > regards, > > peter begin:vcard n:Stell;Jason tel;pager:800-724-3329 PIN 382-8028 tel;work:(703) 471-2529 x-mozilla-html:FALSE url:http://www.intelixinc.com adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Consultant (Intelix, Inc.) fn:Jason Stell end:vcard
Re: website crashes browser
I'm running Redhat 7 (with newer kernel 2.2.18) and NS 4.76 and my browser freezes while trying to load the navigation applet. My NT4 box with NS 4.76 manages to load the applet okay (after some delay). Paul -- could you add a non-java option for the user guide link? V/R Jason Stell Peter Rooney wrote: > thanks for all the hard work! > > i'm running mandrake linux (2.2.12), using netscape 4.7, and the > jde.sunsite.dk site totally crashes my browser, rendering the online > docs powerless to help me out. frames make lynx a pain. > > i've wget'ed stuff down to my local machine so it's not urgent but > thought i'd let you know. > > regards, > peter begin:vcard n:Stell;Jason tel;pager:800-724-3329 PIN 382-8028 tel;work:(703) 471-2529 x-mozilla-html:FALSE url:http://www.intelixinc.com adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Consultant (Intelix, Inc.) fn:Jason Stell end:vcard
RE: AW: AW: JDebug Improvement Suggestion
Hi Paul, I'm using version JDE-2.2.6 and use JDEbug on a regular basis and experience no problems. I also would be more interested in seeing further JDEbug enhancements over coding engine enhancements. On my wish list is having brief documentation describing each debugging command and whether or not it is thought to be fully functional. With this information, I would start trying out more of the commands and helping with debugging. My favorite command would be a fully functional "evaluate expression". I know you have said in the past that JPDA doesn't support this, but there must be some way to at kludge it as I know of other JPDA based debuggers, e.g. JBuilder Professional, that support this functionality. Thanks so much for your efforts. Chuck > -Original Message- > From: paulk [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 10:21 AM > To: klaus.berndl; klaus.berndl; jde > Cc: paulk > Subject: Re: AW: AW: JDebug Improvement Suggestion > > > At 10:45 AM 4/5/01 +0200, [EMAIL PROTECTED] wrote: > [snip] > >No, you are definitely not the only guy able to use JDEBug :-) > >IMHO the problems JDEBUG getting startet will go to nearly zero > >because many of these problems are related not using the most > >recent JDK (means < 1.3.0), some problems getting the > >classic-VM with JDK 1.3 under Windows NT to run and some > >problems with the Hotspot-VM under Solaris. Also the JPDA-debugging > >standard of Sun is realtive new. > >But lets wait soem month and most people will use JDK >= 1.3.02, > >problems oh hotspot-vms will reduce and JDEBug will start for most > >user without any problems. At least i hope so...:-) > >Any other opinion? > > > > You and I have the same hope and expectation. > > >But: For a really good IDE (for any language) a good > (graphical if possible) > >debugger is essential so please do not stop development of JDEBug. > >In contrary: Please correct me but IMO you have much more > enhanced and > >improved in the last months the "coding-engine" of JDE (means adding > >features for > >most conveniant editing and compiling java-code) than the > JDEbug. IMHO the > >"coding-engine" is good enough (of course nothing is good > enough, but i > >believe you know > >what i mean :-) and now some of your power should flow back > into the JDEBug > >because > >IMHO (please correct me if i say nonsens) it seems there is > a little bit > >develoment-stagnancy for JDEBug??!! > > Absolutely, about a year ago, the advent of semantic plus a host of > contributions from JDE users diverted my attention from > JDEbug. I have > felt very bad all along about neglecting JDEbug, which I regard as > basically an early beta version, and have been anxious all > along to get > back to it. But the recent string of reports of JDEbug > hanging at startup > plus the absence of feature requests and comments (contrasted > with the many > requests in the editing area) made me wonder if anyone was > using JDEbug > and, if not, whether it was worthwhile investing any further time in > JDEbug. Your response plus that of many others has renewed my > determination > to develop JDEbug into a robust and easy-to-use debugging tool. > > - Paul >
AW: AW: AW: JDebug Improvement Suggestion
> >IMHO (please correct me if i say nonsens) it seems there is > >a little bit > >develoment-stagnancy for JDEBug??!! > > Absolutely, about a year ago, the advent of semantic plus a host of > contributions from JDE users diverted my attention from > JDEbug. I have > felt very bad all along about neglecting JDEbug, which I regard as > basically an early beta version, and have been anxious all > along to get > back to it. But the recent string of reports of JDEbug > hanging at startup > plus the absence of feature requests and comments (contrasted > with the many > requests in the editing area) made me wonder if anyone was > using JDEbug > and, if not, whether it was worthwhile investing any further time in > JDEbug. Your response plus that of many others has renewed my > determination > to develop JDEbug into a robust and easy-to-use debugging tool. This would be great! If JDEBug enhances to this robust and easy-to-use debugging tool, then IMHO the combination of Emacs, JDE, semantic, JDEBug and ECB (a little bit act of promoting for our Emacs Code browser :-) needn´t conceal oneself behind any commercial product in contrary it´s much better and much more (easy, means not only for hardcore Emacser!) customizable to personal tastes as the other IDE´s. Of course some of them are not bad and have really nice features (e.g. JBuilder) but over all considered...No Chance! :-)
RE: CONTRIB: recursive search in files of the current JDE project
joel, Oups, sorry about that, I had not restarted by emacs since I tested it and so the default value of the jde-grep-file-regexp variable was never reassigned. I quoted it, I hope it works better now. I learned one more "always test your stuff from a fresh emacs process" :-) Here is the updated version, let me know if this works for you. Thanks for your feedback, Guillaume. > -Original Message- > From: Joel Metelius [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 5:18 PM > To: Berche, Guillaume > Subject: RE: CONTRIB: recursive search in files of the current JDE > project > > > I have had the debug-on-error set to true all the time, but I > don't get > a trace from this error... > > sorry, > > joel > > > -Original Message- > > From: Berche, Guillaume [mailto:[EMAIL PROTECTED]] > > Sent: den 5 april 2001 17:06 > > To: Joel Metelius > > Subject: RE: CONTRIB: recursive search in files of the current JDE > > project > > > > > > Hum... I'm sorry to read this. I'm lacking a stack trace to > > debug this problem as it does not appear on my machine. > > > > Could you please add the following statement before the > > load-file so that emacs dumps a stack trace: > > (setq debug-on-error t) > > > > elisp intro provides more info about this at: > > http://www.gnu.org/manual/emacs-lisp-intro/html_chapter/emacs- > > lisp-intro_18.html#SEC196 > > > > Regards, > > > > Guillaume. > > > > > > > -Original Message- > > > From: Joel Metelius [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, April 05, 2001 4:53 PM > > > To: Berche, Guillaume > > > Subject: RE: CONTRIB: recursive search in files of the current JDE > > > project > > > > > > > > > Same error... > > > > > > Loading c:/prog/home/emacs/site/lisp/jde-grep.el (source)... > > > Error in init file: Invalid function: "*.java" > > > Loading cl-seq... > > > Loading cl-seq...done > > > File mode specification error: (invalid-function "*.java") > > > > > > > -Original Message- > > > > From: Berche, Guillaume [mailto:[EMAIL PROTECTED]] > > > > Sent: den 5 april 2001 13:22 > > > > To: Joel Metelius > > > > Subject: RE: CONTRIB: recursive search in files of the > current JDE > > > > project > > > > > > > > > > > > Joel, > > > > > > > > Can you try it using > > > > > > > > (load-file "/jde-grep.el") instead of (require > > > > 'jde-grep) > > > > > > > > I did not declare this as a feature so I'm not sure that > > > > "require" would work. Tell me if this solves your problem. > > > > > > > > Thanks, > > > > > > > > Guillaume. > > > > > > > > > > > > > -Original Message- > > > > > From: Joel Metelius [mailto:[EMAIL PROTECTED]] > > > > > Sent: Thursday, April 05, 2001 12:55 PM > > > > > To: Guillaume Berche > > > > > Subject: RE: CONTRIB: recursive search in files of the > > current JDE > > > > > project > > > > > > > > > > > > > > > thanks I would love the functionality, but: > > > > > > > > > > jde-java-font-lock: building names cache... > > > > > jde-java-font-lock: building names cache...empty > > > > > Error in init file: Invalid function: "*.java" > > > > > Loading cl-seq... > > > > > Loading cl-seq...done > > > > > File mode specification error: (invalid-function "*.java") > > > > > > > > > > .emacs: > > > > > ;; Tell Emacs to load the entire JDE package at startup > > > (only once). > > > > > (require 'jde) > > > > > > > > > > ;; The Emacs code browser (ECB) > > > > > (require 'ecb) > > > > > > > > > > ;; > > > > > (require 'jde-grep) > > > > > > > > > > > > > > > /joel > > > > > jde-grep.el
website crashes browser
thanks for all the hard work! i'm running mandrake linux (2.2.12), using netscape 4.7, and the jde.sunsite.dk site totally crashes my browser, rendering the online docs powerless to help me out. frames make lynx a pain. i've wget'ed stuff down to my local machine so it's not urgent but thought i'd let you know. regards, peter
Re: AW: AW: JDebug Improvement Suggestion
At 10:45 AM 4/5/01 +0200, [EMAIL PROTECTED] wrote: [snip] >No, you are definitely not the only guy able to use JDEBug :-) >IMHO the problems JDEBUG getting startet will go to nearly zero >because many of these problems are related not using the most >recent JDK (means < 1.3.0), some problems getting the >classic-VM with JDK 1.3 under Windows NT to run and some >problems with the Hotspot-VM under Solaris. Also the JPDA-debugging >standard of Sun is realtive new. >But lets wait soem month and most people will use JDK >= 1.3.02, >problems oh hotspot-vms will reduce and JDEBug will start for most >user without any problems. At least i hope so...:-) >Any other opinion? > You and I have the same hope and expectation. >But: For a really good IDE (for any language) a good (graphical if possible) >debugger is essential so please do not stop development of JDEBug. >In contrary: Please correct me but IMO you have much more enhanced and >improved in the last months the "coding-engine" of JDE (means adding >features for >most conveniant editing and compiling java-code) than the JDEbug. IMHO the >"coding-engine" is good enough (of course nothing is good enough, but i >believe you know >what i mean :-) and now some of your power should flow back into the JDEBug >because >IMHO (please correct me if i say nonsens) it seems there is a little bit >develoment-stagnancy for JDEBug??!! Absolutely, about a year ago, the advent of semantic plus a host of contributions from JDE users diverted my attention from JDEbug. I have felt very bad all along about neglecting JDEbug, which I regard as basically an early beta version, and have been anxious all along to get back to it. But the recent string of reports of JDEbug hanging at startup plus the absence of feature requests and comments (contrasted with the many requests in the editing area) made me wonder if anyone was using JDEbug and, if not, whether it was worthwhile investing any further time in JDEbug. Your response plus that of many others has renewed my determination to develop JDEbug into a robust and easy-to-use debugging tool. - Paul
Re: AW: use w3 instead of wget?
I will put this in the JDE sources. Thanks, Paul >At 03:18 PM 4/5/01 +0200, [EMAIL PROTECTED] wrote: >> I have a small comment regarding jde-help. I've seen that the >> function jde-help-symbol makes use of the function >> jde-help-find-javadoc which checks whether a certain url exists. It >> does that by invoking the shell command wget. I think wget is a nice >> utility but I think it would be even nicer to use the w3 package. For >> one thing I quite often use w3 anyways, but more important: using web >> proxies with authentication (which is used where I work) is far easier >> than with wget. You only have to set the variable url-proxy-service >> and w3 will prompt you for login (defaulting to user-login-name) and >> password the first time w3 is used to fetch a url in a emacs session. >> I know that you can have a .wgetrc file with that information in it, >> but I find that almost more inconvenient because I don't like entering >> my password in 20 places. > >I agree in all points. Good idea!! > >> >> So this is what I've done to use w3 (note that if w3 is not loaded >> wget will still be used): >> >> - put (load "w3" t t) somewhere near the top of jde-help.el > >I would not load the whole w3 only for this function. Try this near >the top of jde-help.el: > >(if (locate-library "url") > (autoload 'url-file-exists "url" nil nil nil)) > >> - changed jde-help-find-javadoc to the following: >> >> (defun jde-help-find-javadoc (class docset-dir) >> "Searches DOCSET-DIR for the javadoc HTML page >> for CLASS and, if found, returns the URL of the >> javadoc page for CLASS. This function uses >> wget to verify the existense of pages located >> on remote systems." >> (let ((class-path >> (concat (substitute ?/ ?. class) ".html")) >> url) >> (cond >> ((string-match "http:" docset-dir) >> (setq url (concat docset-dir "/" class-path)) >> (if (featurep 'w3) > >change the last line to: >(if (fboundp 'url-file-exits) > > >>(if (not >>(url-file-exists url)) >> (setq url nil)) >> (if (executable-find "wget") >> (if (not >> (string-match >> "200" >> (shell-command-to-string >>(concat "wget --spider " url >> (setq url nil)) >> (error >>(concat "Cannot find wget. This utility is needed " >>"to access javadoc on remote systems.") >> (t >> (let ((doc-path >> (expand-file-name class-path docset-dir))) >> (if (file-exists-p doc-path) >> (setq url (format "file://%s" doc-path)) >> url)) >> >> I am no elisper so I don't know what I did is absolutely correct, but >> the old behaviour should still be the same. > >See my little modifications but now it should work. Really good idea! > >Klaus
Re: JDE Debugging problem using JDB
Hi Andy, JDEbug is based on Sun's Java Platform Debug Architecture (JPDA). The initial version of the Java side of JDEbug was developed for the JDE by the team at Sun who developed JPDA. In particular, Sun approached me two years ago about creating a JPDA-based debugger for the JDE and offered to do the Java side. I agreed and they then hired a summer intern to do the Java implementation. The summer intern basically adapted the JPDA-based version of jdb to work with the JDE. So you can see that there is a very close connection between JDEbug and jdb. You should also be aware that both jdb and JDEbug (and JPDA-based commercial debuggers) are basically wrappers around JPDA. JPDA does most of the back-end work of implemening debug commands, like detecting breakpoints, etc. Thus, bugs in JPDA can cripple JDEbug and can be very hard for me to diagnose, let alone work around. It does not surprise me that JPDA may be sensitive to subtle differences in the various incarnations of Windows, especially in the area of sockets and threading. Windows threading and socket handling is pretty messy from what I understand. I've also had indications that the JPDA is very sensitive to hidden differences among the various Windows operating systems. For example, one JDEbug user could not get JDEbug to stop at breakpoints on a laptop running Windows 2000. He tried everything including reinstalling Windows 2000. The second time he installed Windows 2000, he omitted installing Service Pack 1 and, lo and behold,. JDEbug started working. He then tried JDEbug again with SP1 installed and not installed and confirmed that JDEbug worked without but not with SP1. So it seems that JPDA may have dependencies on Windows features that are peculiar to particular versions, perhaps the versions used by the JDPA team for development and testing. Regarding your data points, please note that the JDE launches JDEbug directly as a subprocess of Emacs. Therefore, I cannot see that cygwin would have anything do do with the problems you are having. Regarding the multiple prompts, I am not sure what is causing them but I wonder if this has anything to do with input echoing. I believe shells, including Emacs' comint buffer, can be configured to echo command prompts. Finally, I'd appreciate it if you would try JDEbug on the system on which jdb worked. - Paul At 09:34 AM 4/5/01 -0400, you wrote: >Paul, > >Here's a few more data points that might help explain what is going on. >I tried this last night on another system I have at home that runs NT4.0 >and an older version of Cygwin. Everything worked fine on that system. >And I noticed that the JDB output did not have any repeated debugger >prompts like I am seeing on the Windows 2000 system. > >I tried running jdb in both a Cygwin window and a DOS window on the >Windows 2000 system and I'm seeing the extra debugger prompts on both >windows. > >If I had to guess I'd say there seems to be something about the >threading in JDB that's not working correctly with Windows 2000, but I >have to say I find it hard to believe SUN wouldn't catch this. I don't >know if this could also affect the JPDA stuff to cause the problems I'm >seeing with JDEbug. > >What do you think? I assume you have some connections with the Java >developers at SUN - perhaps we should run this by them? > >Andy > >Andy Bennett wrote: >> >> > >> > Have you tried running jdb from a DOS command prompt? >> > >> >> Paul, >> >> I gave this a try and for the most part, everything appears to work just >> fine. There was one very peculiar thing about the output that I noticed >> which could be what is causing problems for the jdb. >> >> I am including the output from the debugger session below. >> >> What I noticed is that sometimes when I step I get an "extra" debugger >> prompt "main[1]" included in the output from the debugger and sometimes >> I don't. I really can't quite figure out when it happens or what is >> causing it to do this. However, if the jdb is either expecting or not >> expecting this behavior then I could see where it might get confused >> trying to process the output from the jdb. >> >> I'm not sure how this relates to the JDEbug problems I am seeing, but it >> sure seems like it could be causing the erratic behavior in the jdb. >> >> Let me know what you think... >> >> Andy >> >> java> jdb -classpath c:/work/jdetest/java/debug/ -tclassic >> -Djava.compiler=NONE >> jdetest.Test >> Initializing jdb... >> > stop in jdetest.Test.main >> Deferring breakpoint jdetest.Test.main. >> It will be set after the class is loaded. >> > run >> run jdetest.Test >> > >> VM Started: Set deferred breakpoint jdetest.Test.main >> >> Breakpoint hit: thread="main", jdetest.Test.main(), line=16, bci=0 >> 16 Test t = new Test(); >> >> main[1] next >> main[1] >> Step completed: thread="main", jdetest.Test.main(), line=17, bci=8 >> 17 t.run (args); >> >> main[1] step >> main[1] >> Step completed: thread="main", jdetest
Re: AW: JDebug Improvement Suggestion
Paul, Don't despair, JDebug has worked very nicely for me but, like you, I am running on a Windows NT system. An aside on debugging, in the past year I've adopted the unit test philosophy espoused by the XProgramming group and you know what has happened? My use of a debugger has almost disappeared. The unit tests allow me to focus in on a problem very quickly. For those not familiar with unit testing ideas see http://www.junit.org and http://www.xprogramming.com Erik Husby
AW: use w3 instead of wget?
> I have a small comment regarding jde-help. I've seen that the > function jde-help-symbol makes use of the function > jde-help-find-javadoc which checks whether a certain url exists. It > does that by invoking the shell command wget. I think wget is a nice > utility but I think it would be even nicer to use the w3 package. For > one thing I quite often use w3 anyways, but more important: using web > proxies with authentication (which is used where I work) is far easier > than with wget. You only have to set the variable url-proxy-service > and w3 will prompt you for login (defaulting to user-login-name) and > password the first time w3 is used to fetch a url in a emacs session. > I know that you can have a .wgetrc file with that information in it, > but I find that almost more inconvenient because I don't like entering > my password in 20 places. I agree in all points. Good idea!! > > So this is what I've done to use w3 (note that if w3 is not loaded > wget will still be used): > > - put (load "w3" t t) somewhere near the top of jde-help.el I would not load the whole w3 only for this function. Try this near the top of jde-help.el: (if (locate-library "url") (autoload 'url-file-exists "url" nil nil nil)) > - changed jde-help-find-javadoc to the following: > > (defun jde-help-find-javadoc (class docset-dir) > "Searches DOCSET-DIR for the javadoc HTML page > for CLASS and, if found, returns the URL of the > javadoc page for CLASS. This function uses > wget to verify the existense of pages located > on remote systems." > (let ((class-path >(concat (substitute ?/ ?. class) ".html")) > url) > (cond > ((string-match "http:" docset-dir) > (setq url (concat docset-dir "/" class-path)) > (if (featurep 'w3) change the last line to: (if (fboundp 'url-file-exits) > (if (not >(url-file-exists url)) > (setq url nil)) > (if (executable-find "wget") > (if (not > (string-match > "200" > (shell-command-to-string >(concat "wget --spider " url > (setq url nil)) > (error >(concat "Cannot find wget. This utility is needed " >"to access javadoc on remote systems.") > (t > (let ((doc-path >(expand-file-name class-path docset-dir))) > (if (file-exists-p doc-path) > (setq url (format "file://%s" doc-path)) > url)) > > I am no elisper so I don't know what I did is absolutely correct, but > the old behaviour should still be the same. See my little modifications but now it should work. Really good idea! Klaus
RE: CONTRIB: recursive search in files of the current JDE project
As someone who's thought about learning elisp, I'd say your first effort sets a high standard! :) I have a suggested modification: I think the line "find %s %s -type f | xargs grep %s -n \"%s\"" is improved by this "find %s %s -type f | xargs grep %s -n \"%s\" /dev/null" (not sure if you need to escape the slashes.) This way, grep won't miss any hits in the last file that find produces. Also, I think there is a way to handle file names with spaces in them by using a print0 argument to find, but I have never been able to get that to work on my NT / cygwin box. > -Original Message- > From: Guillaume Berche [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 5:50 AM > To: [EMAIL PROTECTED] > Subject: CONTRIB: recursive search in files of the current > JDE project > > > Hello, > > I eventually got some time to spend learning emacs-lisp (by > the way the > elisp-introduction available at > http://www.gnu.org/manual/emacs-lisp-intro/emacs-lisp-intro.html is > really a great document to start learning elisp), and finally started > implementing a new feature that I had been wishing the JDE to have. > > So attached, it my first lisp function to search a string into all of > the current JDE project files. It is merely a customization of the > standard "grep" command to use the JDE customization variables (mainly > the path to the source files). Please let me know what you > think and how > to improve it! > > To use it, include the file in your .emacs file (after > loading the jde) > and type "M-x jde-grep-find" > Its behavior can be customized, type "C-h f jde-grep-find" > for details. > > Cheers, > > Guillaume. >
