RE: jde-make-working-directory
> However, the problem I'm having seems to be caused by the cd
> command having no effect, as with the person you previously responded
> to. I was able to cut and paste that command (from the build's
> compilation buffer) into a regular emacs shell, and see it not work
> there either:
>
> e.g.
> cd c:/src/depot/JavaBrowser/Current/build
> does not work in a regular emacs shell using a w2k cmd prompt, but
> cd c:\src\depot\JavaBrowser\Current\build
> and
> cd "c:/src/depot/JavaBrowser/Current/build"
> both work...
>
> I figure this is the reason that it's not working for the build, it's
> all a bit puzzling to me...
Righto. I've done a bit of research. No real fixes, but this is
about as much time as I should spend on it today. Acutally, I've
spent more than I should, but this was interesting.
The problem is due to an evil and unfortunate interaction between the
function jde-normalize-path (defined in jde.el) and the compilation
buffer when cmd.exe or command.exe is your shell; this would probably
be the default situation for a lot of Win32 users, despite the web
site recommendation that Cygwin and bash be installed and used.
jde-normalize-path calls a couple of standard emacs functions:
substitute-in-file-name
expand-file-name
These functions do the bulk of processing by substituting environment
varibles, (which works very nicely, and I might start using), and
expanding ~ to be the current home directory. The majority of extra
work done by jde-normalize-path is to convert relative paths based on
locations of prj.el, and then call jde-convert-cygwin-path, which may
or may not make further conversions.
jde-normalize-path is not an interactive function, but you can
experiment with its behaviour interactively using ielm. '[M-x]ielm'
should do it. Here some example output.
*** Welcome to IELM *** Type (describe-mode) for help.
ELISP> (jde-normalize-path "d:\\home\\craig")
"d:/home/craig"
ELISP>
This mode has tab completion of currently defined elisp functions and
variables, and external file names, so is very nice to use.
Emacs strings require \ to be quoted with \, hence the \\ in the
string that I pass to jde-normalize-path. Note that jde-normalize-
path returns a string with / as the path separator. This is because
internally, jde-normalize-path forces the varible directory-sep-char
to / (?/ in emacs representation if you want to look at the source)
before calling the standard emacs functions I mentioned earlier.
Setting directory-sep-char changes the behaviour of those functions,
and they return the path with /.
This is what is happening. Why it is like this, I don't know.
Next, try opening a standard windows command shell. I use NT4.0, so
I have cmd.exe as my example. Use the path string that jde-normalize-
path is returning in a cd command.
D:\cygwin>cd d:/home/craig
D:\cygwin
D:\cygwin>
And there is the exact behaviour that is mystifying everyone. cmd's
internal cd implementation (for cd is an 'internal command' in
Microsoft parlance) is ignoring 'd:/home/craig' because it doesn't
recognise it, and is performing its standard behaviour when given no
arguments; it is reporting the current directory.
If you set bash as your shell for emacs, then it will cope with the
forward slashes.
I'm too lazy to actually try and think of a reliable and robust fix
(actually I have no idea what all of the possible combinations are,
and am frightened of touching anything in case I break what is
already working), but there is a reliable work around. Install
Cygwin, and set bash as the default shell. Here are the relevant
entries from my .emacs, which I think I copied off of the JDE site
somewhere.
(setq binary-process-input t)
(setq w32-quote-process-args ?\")
(setq shell-file-name "bash")
(setenv "SHELL" shell-file-name)
(setq explicit-shell-file-name shell-file-name)
(setq explicit-sh-args '("-login" "-i"))
-+---
Craig McGeachie | #include
+61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents;
-+---
Re: jde-make-working-directory
> Did you have any luck getting the make directory to work for JDE? I > have the exact same problem as you... Er, what problem? I have no problem. I did respond once to someone who did. In general, I am using ant, although I'm not using the new Ant specific build functions in JDE. I am setting the following varibles in my prj.el file '(jde-make-args "compile") '(jde-make-working-directory "./build/all_classes/") '(jde-make-program "ant") When I run the command jde-build (on my computer this is bound to the key [C-f5]), the compile window is created and I see my build process running more or less as if I had done the following in a command shell (note the "cmd#:dir_name$" for the prompt, I'm a Unix/Bash junkie): 924:config$ cd ../all_classes/ 925:all_classes$ ant compile Searching for build.xml ... [ lots of output cut, mostly because this run was full of embarrassing compile errors ] Incidentally, note that my working directory varible uses the relative path notation. The prj.el file this is defined in is two directories above all_classes, in the project root directory. While I set these values in a local prj.el, setting them in .emacs, and using absolute pathnames should be just fine. I might check this myself, but it is currently 7.30am, I've just got to work, and I'm still feeling sluggish. I don't set a lot of jde varibles, and in fact, I think the three I listed above are the only ones you need worry about. Certainly the jde-compile-option-* varibles will have no effect. They only apply when running jde-compile which compile the Java file in the current buffer. Beyond the three make variables, the only settings that will really matter are the contents of you Makefile, build.xml, batch file, whatever. -+--- Craig McGeachie | #include +61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents; -+---
Re: Fountain of youth found!!
My fault for using reply-to in general emails. Oooh, this is so embarrassing. My apologies. On 13 Jun 2001, at 14:20, Dmitri Colebatch wrote: > are we all invited? (o: > > On Wed, 13 Jun 2001 14:11, Eliza Gruszecka - SunPS Quality Manager > wrote: > OK, give us a time, and I'll agree on Jacqueline's behalf > since she's > gone home sick. > > See you Friday. > > E > > Craig > McGeachie wrote: > > Friday lunchtime at the Metro sounds good to me. > Just have to make > > sure that Grant doesn't ask for a demo of what > I'm doing just then. > > > > > -+--- > > > Craig McGeachie | #include > > +61 (410) 774902 | > while (!inebriated) c2h5oh = (++bottle)->contents; > > > -+--- -+--- Craig McGeachie | #include +61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents; -+---
Patch for jde.wizards.MethodFactory
Attached is a patch file made with 'diff -up'. I modified the class
so that when jde-wiz-implement-interface is invoked, the default
generated return statements return correct literals instead of simply
null. After using jde-wiz-implement-interface, the class should now
save and compile without further work.
-+-------
Craig McGeachie | #include
+61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents;
-+---
--- MethodFactory.orig Wed May 23 23:22:12 2001
+++ MethodFactory.java Wed Jun 13 07:36:27 2001
@@ -158,6 +158,9 @@ public class MethodFactory
}
+ private String[] numericTypesArray =
+{"char","byte","short","int","long","float","double"};
+ private java.util.List numericTypesList =
+java.util.Arrays.asList(numericTypesArray);
+
public String getMethodSkeleton(Signature sig,
boolean javadoc,
boolean newline,
@@ -180,8 +183,13 @@ public class MethodFactory
Method m = sig.getMethod();
Class cl = m.getReturnType();
-if (! cl.getName().equals("void"))
+if (numericTypesList.contains(cl.getName())) {
+ res += " return 0;\n";
+} else if (cl.getName().equals("boolean")) {
+ res += " return false;\n";
+} else if (! cl.getName().equals("void")) {
res += " return null;\n";
+}
res += "}\n";
return res;
BUG: maybe
Any reason beanshell.el contains defcustom declarations refering to to the customisation group 'bsh', but no matching defgroup declaration? I can't find group bsh defined in any of the lisp files. -+--- Craig McGeachie | #include +61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents; -+---
Decompiler elisp connector
Here it is, on the off chance that anyone else may want to play with
it. I have attached the file directly, rather than providing a
download link, because:
- it's smaller than some of the messages that appear on this list
- I have no publicly available host that I can dump source code
for people to download from.
This is a elisp package that will detect that Emacs has opened a
class file, run the class data through a decompiler, and then replace
the class data in the buffer with a Java source representation. The
package can optionally create an editable buffer, constructing a
.java based name from the original .class based name, that is easily
saved to disk.
To use, place decompile.el somewhere on your elisp path. Place
(require 'decompile) in your .emacs file.
The package is intended to be used with Jad, but if you have another
decompiler that obeys various assumptions built into decompile.el,
then you should be able to use it by changing the executable name and
command line option customisation variables.
With a fair degree of chutzpah, I have parented the customisation
group under the main JDE group.
The source is originally based on a package that was written by Ingo
Koch, but I have modified it somewhat. Note that the comments
identify Ingo as the maintainer. I'm not sure how accurate this is
given that while the structure is much the same, I have almost
completely rewritten everything.
It is not as complete as I would like. Things that I would like to
do, or see done (hint hint), are:
- The package assumes the byte comes from a .class file on
disk and therefore the .java buffer name can be constructed
from this. The byte code should be decompiled, and the
.java buffer name constructed by parsing the source for the
class declaration.
- The package demands that the decompiler output source code to
standard out. This should be made more flexible.
- There is a flag that, if set, means that the source code is placed
in a buffer that is modifable, associated with a Java filename,
and marked as modified. The buffer isn't saved, so the Java file
isn't written to. The flag should be extended to include a third
option to automatically save the reconstructed Java source.
Some thought is needed, about what to do if the intended Java file
already exists.
- I wish the programming style was less imperative, and more
functional, by it's been a while, and my Lisp skills are rusty.
- I've seen another package that links with jar and zip files to
automatically view Java source representations of the contained
files. When I have time, I'll steal the idea and put it here.
-+---
Craig McGeachie | #include
+61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents;
-+---
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
File information ---
File: decompile.el.gz
Date: 7 Jun 2001, 7:49
Size: 2516 bytes.
Type: Unknown
decompile.el.gz
Re: Debugging JDK source
On 22 May 2001, at 15:50, Ben Speakmon wrote: > 1) Sun doesn't compile the Java core classes with -g, which JPDA needs > to see breakpoints. 2) You can't compile the Java sources in src.jar > and get rt.jar, since there are all kinds of native classes and code > to deal with the low-level stuff. > Of course, I would *love* to be proved wrong here, but until then this > is another great reason to support Classpath. :) I can't actually _prove_ you wrong, since I'm not about to attach a 10MB file to this message, but I can tell you that I have compiled the contents of src.jar and recreated rt.jar with -g. Well, that's not strictly true. I have compiled some of src.jar, some of the more critical components like java.lang.*, java.util.*, java.io.*, java.text.*, and java.net.*. Not everything compiles, and I can't recall why. It's been a while since I did this. I do know that Java packages specific to the Sun implmentation of the Java runtime are left out of src.jar. Specifically, sun.* is not in src.jar, and contains things like all the handlers for URL protocols. I also know that I am compiling code that has native implementations, but this is not a problem. The methods that are native will recompile since only the interface is in Java, and the actual implementations are still in the DLLs or shared objects. Without laboriously sitting down and actually testing what I write, here is a quick overview of adding debugging info to rt.jar. Extract rt.jar to a directory somewhere. Delete the packages that you wish to recompile. I would suggest the ones above, plus any that you wish to try. No real guarentees on what will and will not compile. Try your luck. Extract src.jar to a directory somewhere. Compile the packages that you deleted from the rt.jar extraction. Use the extracted src.jar as your source path. I found that making an Ant build.xml file here helped condsiderably. Use the extracted rt.jar as your destination. Put the extracted rt.jar on the classpath of you compilation. Increase the initial and maximum heapsize values of your javac process; it's about to do a lot of work. I would suggest 256MB and 512MB. Compiling more packages will need more memory. Don't forget to include the -g flag. Jar up the compiliation destination directory into new_rt.jar. You now have two options for your new_rt.jar. You can replace the existing rt.jar with it, taking care to keep the old rt.jar. You can specify the new_rt.jar, plus any i18n.jar file you care for, on the boot class path of your new Java processes. Specify the directory root of the extracted src.jar, and you can use JDEbug, or what ever debugger you care to name, and step into the Java API. -----+--- Craig McGeachie | #include +61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents; -+---
