Re[2]: Refactoring with JDE?
Andrew Hyatt [EMAIL PROTECTED] seems to think that: [ ... ] I would be very interested if someone who really knew semantic well could tell us if it could do the kind of parsing necessary for these more advanced features. It seems to have more then the advertised API, since you can get the speedbar to know about types of local variables, while the advertised API does not go into within-method information. Hi, Semantic 1.4 local variable parsing depends on programmers having some mysterious need to declare all local variables before writing any code. As such, it can use the regular tagging parser within a method body scope and do a reasonable job. That particular function is advertised in the manual under context parsing, not under the general tagging information. As Paul mentioned, Semantic 2.0 includes David Ponce's full bison port, and a Java parser that can parse an entire Java file, including method code, faster than the Semantic 1.4 parser could tag the same file. The new incremental parser handles about 90% of common edits without a full reparse. My long term goals include indentation and font lock engines, underlining bad syntax, and all that good stuff. My long term goals could probably keep several people busy for several decades. When I wrote semantic 1.0 I was learning what a parser is as I wrote it, so the road to semantic 2.0 includes a massive renaming campaign to give all the nouns the correct names and reduce confusion. I wrote the thing and it confused me. Now it does not. Anyway, all that's done. The parser API is an elegant thing to behold. The new tag searching and completion engines bring joy to my heart. The parser construction process will bring new languages into the fold. All the wacky new minor modes will lure the young-uns to the glory of Emacs. Well, something like that. Paul gave me a little too much credit perhaps. Your other question was when?. Here is the inside scoop on Semantic 2.0. Scoop 1: Semantic, EIEIO, Speedbar, EDE, and Corge will all be shipped together as one package called CEDET 1.0 and have one master Makefile, but each will maintain their own version number and identity, and can be installed one chunk at a time. It cuts down on maintenance since they are all co-dependent. Version number dependencies will be enfoced with a new inversion package. Scoop 2: We've been trying to bring the Doc to be at least vaguely relevant to what's in CVS, and get the build harness working to desired parameters (a bit of EDE development there.) That's it before a CEDET 1.0 beta1 is built and published. Note 1: Most major API functions had their names changed. We devised a nice obsoletion mechanism that lets ECB and the JDE work fine with the new version. They just throw lots of warnings during byte-compilation time. (At least I think the JDE works. Isn't that so David?) Note 2: This beta version of semantic will have no indentation or font lock magic in it. The substructure is there, but little attention has been placed on it yet. Note 3: I owe David Ponce a huge debt of gratitude for the amazing things he has done to bring Semantic 2.0 to where it is today. I am also indebted to Richard Kim who has been instrumental to much of the new documentation, and for writing the python parser. Have fun Eric -- Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED] Home: http://www.ludlam.netSiege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
Re: Refactoring with JDE?
Andrew Hyatt writes: [snip] Using a third party Java-based backend might be easiest, but I'm afraid that such a loose integration wouldn't give us many of the cool features we would want. My personal view, that is not shared by many I fear, is that we should do as much as humanly possible in elisp. The more we do in elisp, the faster and better integrated it will be. I share Andy's bias toward elisp. Regarding semantic, my long-range plan, as stated before, is to provide a parse data API that seamlessly (from the point of view of elisp clients) integrates the classpath (based on Java reflection and perhaps Andy's classfile parser) with the source parse database generated by semantic. The idea is the the API would look first in the semantic database for the requested parse info, then possible in Andy's xref database, and then in the classpath. This would allow completion on fields and methods for which only source code exists or for which only class files exist. My hope is that the Java parser generated by David Ponce's new yacc-style parser generator will be fast enough and complete enough to allow on-the-fly expression syntax error highlighting and other advanced features. Paul
RE: Refactoring with JDE?
Where can I find information on how to use jde-xref ? -Original Message- From: Andrew Hyatt [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 10:03 PM To: Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: Re: Refactoring with JDE? On Wednesday, September 3, 2003, at 07:19 PM, Nascif Abousalh-Neto wrote: Good point. What do you think should be the way to go with support for refactorings in JDE? I can see three major directions: 1) Expanding on the jde-xref functionality 2) Using the new semantic 2.0 - assuming it has all the necessary functionality 3) Use a Java-based backend or C-based, like Transmogrify or xrefactory. I think that using an approach similar to the JDE compile server, which keeps an instance of the java compiler running at all times, the Java approach may be feasible in terms of performance. Then again I don't know how Lisp-based grammars compare in terms of speed and memory usage with Java-based ones. I would think using semantic 2.0 is what we would want. From Paul's earlier email, I think he also is waiting on this. If semantic does not replicate the jde-xref functionality, we can change jde-xref to work on source files rather than class files by using semantic 2.0 to do the parsing. I'm certain it will be slower than what we have now, but it might be worth it. If we don't want to wait for semantic 2.0 we can implement some simple refactorings that use that functionality such as rename method with jde-xref. I had previously worked on such a system for doing refactorings, but ran up against a problem where I wasn't sure whether we should update the xref db based on the new refactoring or not. It's one of the strange issues that arise from us parsing class files instead of source file. Using a third party Java-based backend might be easiest, but I'm afraid that such a loose integration wouldn't give us many of the cool features we would want. My personal view, that is not shared by many I fear, is that we should do as much as humanly possible in elisp. The more we do in elisp, the faster and better integrated it will be.
RE: Refactoring with JDE?
Jayakrishnan Nair writes: Where can I find information on how to use jde-xref ? In the JDEE User's Guide under Cross-Referencing Classes. Paul -Original Message- From: Andrew Hyatt [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 10:03 PM To: Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: Re: Refactoring with JDE? On Wednesday, September 3, 2003, at 07:19 PM, Nascif Abousalh-Neto wrote: Good point. What do you think should be the way to go with support for refactorings in JDE? I can see three major directions: 1) Expanding on the jde-xref functionality 2) Using the new semantic 2.0 - assuming it has all the necessary functionality 3) Use a Java-based backend or C-based, like Transmogrify or xrefactory. I think that using an approach similar to the JDE compile server, which keeps an instance of the java compiler running at all times, the Java approach may be feasible in terms of performance. Then again I don't know how Lisp-based grammars compare in terms of speed and memory usage with Java-based ones. I would think using semantic 2.0 is what we would want. From Paul's earlier email, I think he also is waiting on this. If semantic does not replicate the jde-xref functionality, we can change jde-xref to work on source files rather than class files by using semantic 2.0 to do the parsing. I'm certain it will be slower than what we have now, but it might be worth it. If we don't want to wait for semantic 2.0 we can implement some simple refactorings that use that functionality such as rename method with jde-xref. I had previously worked on such a system for doing refactorings, but ran up against a problem where I wasn't sure whether we should update the xref db based on the new refactoring or not. It's one of the strange issues that arise from us parsing class files instead of source file. Using a third party Java-based backend might be easiest, but I'm afraid that such a loose integration wouldn't give us many of the cool features we would want. My personal view, that is not shared by many I fear, is that we should do as much as humanly possible in elisp. The more we do in elisp, the faster and better integrated it will be.
RE: [work] How can JDEbug evaluate expression be extended?
Hi, I think this is not particularly easy to do. The steps that are needed on the Java side are: 1. Create a new command object (jde.debugger.command.X) - piece of cake 2. Add it to the DebugCommandFactory list of prototypes - piece of cake 3. The hard part: make it do what you want. It's easy to use the list of StackFrame:s to figure out the value of a variable (see the GetLocals command), but it's quite hard to simulate execution of a function call in a detailed way. I am not at all sure how best to execute a call that could involve access to global variables, synchronization, etc. On top of that, there is the fact that you need to execute the call inside the debuggee VM, not the debugger VM, to ensure that class loading, etc., is all done in the same way. And normally, the debugee VM will be suspended by the debugger when stepping through the code, so I think you'd have to create a new thread with the same context as the current one and execute your call in that scope. It seems to quickly run out of hand here. I tried looking a bit at the JDI interface, but I couldn't see any way to do step 3. I didn't spend a lot of time on it, but it may be something that is not well supported at this level at least. Best regards, Petter -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: den 1 september 2003 04:37 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [work] How can JDEbug evaluate expression be extended? Jeff VanBaalen writes: Does anyone have an extension for the JDEbug Evaluate Expression command that enables one to examine the result of calling a method on some variable in the current context? If not, can anyone give me some hints on how hard this would be to do and how to do it? Its been a while, but I have hacked elisp before. Hi Jeff, This would require work on the Java side of JDEbug, not the Lisp side. You would have to enhance JDEbug's rather primitive expression interpreter to parse and evaluate method expressions. Paul
RE: [work] How can JDEbug evaluate expression be extended?
Petter Måhlén writes: Hi, I think this is not particularly easy to do. The steps that are needed on the Java side are: 1. Create a new command object (jde.debugger.command.X) - piece of cake 2. Add it to the DebugCommandFactory list of prototypes - piece of cake 3. The hard part: make it do what you want. It's easy to use the list of StackFrame:s to figure out the value of a variable (see the GetLocals command), but it's quite hard to simulate execution of a function call in a detailed way. I am not at all sure how best to execute a call that could involve access to global variables, synchronization, etc. On top of that, there is the fact that you need to execute the call inside the debuggee VM, not the debugger VM, to ensure that class loading, etc., is all done in the same way. And normally, the debugee VM will be suspended by the debugger when stepping through the code, so I think you'd have to create a new thread with the same context as the current one and execute your call in that scope. It seems to quickly run out of hand here. I tried looking a bit at the JDI interface, but I couldn't see any way to do step 3. I didn't spend a lot of time on it, but it may be something that is not well supported at this level at least. Hi Petter, I believe the JDI supports method evaluation in the debuggee vm. Certainly, jdb, which is base on JDE, supports method evaluation. For example, it is possible with the current JDEE interface to jdb to evaluation expressions such as obj.toString() The LValue class in JDEbug expr package contains two methods, operation() and booleanOperation(), that evaluate simple binary expressions, e.g., a + b a b in the debuggee vm. That would be a good starting point to study how to extend the JDEE's current expression interpretation capabilities to handle method expressions. Paul Best regards, Petter -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: den 1 september 2003 04:37 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [work] How can JDEbug evaluate expression be extended? Jeff VanBaalen writes: Does anyone have an extension for the JDEbug Evaluate Expression command that enables one to examine the result of calling a method on some variable in the current context? If not, can anyone give me some hints on how hard this would be to do and how to do it? Its been a while, but I have hacked elisp before. Hi Jeff, This would require work on the Java side of JDEbug, not the Lisp side. You would have to enhance JDEbug's rather primitive expression interpreter to parse and evaluate method expressions. Paul
