Re: Decompiler elisp connector

2001-06-07 Thread Dmitri Colebatch

On Thu,  7 Jun 2001 08:23, you wrote:
   - I have no publicly available host that I can dump source code
 for people to download from.
if you need one for this sort of thing in future drop me a line and I might 
be able to provide a temporary hosting of something.

cheers
dim



 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 cheesy_tag.h
 +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


Content-Type: Application/Octet-stream; charset=us-ascii; 
name=decompile.el.gz
Content-Transfer-Encoding: BASE64
Content-Description: 




Re: Decompiler elisp connector

2001-06-07 Thread Paul Kinnucan

I plan to post this on the JDE's Contributed Software page. Interested JDE 
users can download it from there.

- Paul

At 08:23 AM 6/7/2001 +1000, Craig McGeachie wrote:
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 cheesy_tag.h
+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




Decompiler elisp connector

2001-06-06 Thread Craig McGeachie

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 cheesy_tag.h
+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