RE: Extending JDE using Java (WAS: Gosling interview)
Title: RE: Extending JDE using Java (WAS: Gosling interview) -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Matt Munz writes: Nascif, I have been curious about the BeanShell since I heard about it, but haven't tried it yet. It sounds like you're familiar with it. Nacif It is easy to have a Lisp function calling a Java method, using the BeanShell; not so much to do the reverse. Is this really true? It seems to me that your BeanShell app can spit out arbitrary lisp code as a text stream that could be dynamically loaded in emacs. Can you elaborate on what specifically makes it difficult to do 2-way interactions with BeanShell apps? This is what JDE beanshell apps do now. The JDE Lisp function bsh-eval-r accepts an arbitrary string of Java code as an argument, e.g., invocation of a static method defined by a JDE app, and sends it to the Beanshell's standard input. It then suspends Emacs until it receives a response from the Beanshell. bsh-eval-r assumes that the response is a Lisp form. When it receives the Lisp form, bsh-eval-r evaluates it. Although this approach is incredibly powerful, it is not generic enough. It allows an Elisp app to call a Java app, and allows that Java app to return an elisp expression for evaluation (thus affecting the JDE environment). But it does not allow the Java application to see the results of that evaluation; the elisp side of the logic would have to make an addittional call to pass back that result. It also does not address (as Paul said before) asynchronous calls. For example, what if you're trying to interface to a Java library that uses listeners/events? That goes from networks protocol libraries (packet received) to GUIs (button pushed). Also, it does not address already existing code that expects to have control of the information flux, making calls to the external container to obtain information when needed. To solve these problems you would need a true two-way communication path, meaning that somehow you would need Emacs to listen for and respond to commands from the Java side. I understand and agree with the statements that a framework like that would be really complex to implement due to the interprocess communication issues. On the other hand, the benefits are great: just look at the amount of plug-ins already written for the JBuilder Open Tools API (not to mention what is also being done for Eclipse, NetBeans, Elixir, JEdit, etc.): http://www.kylecordes.com/jbot/ http://www.borland.com/jbuilder/resources/jbopentools.html http://jbopentools.sourceforge.net/ Granted, some (maybe most) of these tools could also be ported to JDE/Emacs using plain elisp/BeanShell. But it would still require a lot of duplicated glue code that could be formalized (as Sandip suggested) to make it easier for non-Lisp programmers. Even if we forget about two-way communication capabilities for a while, having a more framework-oriented standard for adding Java extensions to JDE would be highly beneficial. JDE could have an /extensions directory where it would search for extension jar files. They would be automatically loaded at BeanShell start-up time, and appropriate menu entries/elisp wrappers would be generated using Java Reflection or a config file. When activating the extension code in response to a user command, JDE would pass to it the current environment info (file name, cursor position, text in the active region) - if two-way communication is implemented, an API would be provided to allow the Java code to ask for this information directly. There is a lot of cool stuff out there - code beautifiers, UML browsers, refactoring tools, lint tools, network protocol stacks - that could be integrated to JDE by regular Java developers *today* if only they had a framework like that. The challenge is big but so are the benefits... Regards (and sorry for yet another lengthy e-mail) Nascif - Paul
RE: Extending JDE using Java (WAS: Gosling interview)
I think it is practical to use Java to extend Emacs where not much interaction is required between Emacs and the extension, the wizards and the debugger are examples. It may even be possible to provide those extensions with a Java GUI. Pettar Maehlen and I have been discussing the possibility of creating a Java window for JDEbug to display local variable values when stepping through a program. Currently displaying local variables slows down stepping significantly because it involves sending significant amounts of text across the standard I/O channel to Emacs. A separate local variable window that lives in the debugger process instead of the Emacs process would eliminate this bottleneck. I think this would be great! JDE is already a very powerful IDE, that is, it has a great deal of functionality. But I'm concerned with the UI aspect of it. Emacs-ers are used to doing M-x all the time, however, I think it could benefit much from some GUI components instead of having to memorize so many functions. Regarding the inspection of local vars you may also want to consider displaying them in an ECB window. (Although ECB is not a mandatory component of JDE, it seems like a natural fit for the problem.) Maybe having the option of having either Java GUI or ECB inspection view? Regards, Daniel _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Extending JDE using Java (WAS: Gosling interview)
Daniel, If you read Paul's note, the problem he's trying to solve arises precisely because it is too expensive to have a lot of chatter across I/O between emacs and an external java process. The solution he's considering -- put the display logic into the java process so as to avoid the I/O -- addresses the problem. Your proposal - a different window layout managed by ECB - adds more complexity (by bringing ECB into the mix) without doing anything to reduce the high cost of I/O between the debugger and its display. Eric In message [EMAIL PROTECTED], Daniel Hegyi writes: : I think it is practical to use Java to extend Emacs where not much : interaction is required between Emacs and the extension, the wizards : and the debugger are examples. It may even be possible to provide : those extensions with a Java GUI. Pettar Maehlen and I have been : discussing the possibility of creating a Java window for JDEbug to display : local variable values when stepping through a program. Currently : displaying local variables slows down stepping significantly because : it involves sending significant amounts of text across the : standard I/O channel to Emacs. A separate local variable window : that lives in the debugger process instead of the Emacs process would : eliminate this bottleneck. : I think this would be great! JDE is already a very powerful IDE, that is, it : has a great deal of functionality. But I'm concerned with the UI aspect of : it. Emacs-ers are used to doing M-x all the time, however, I think it could : benefit much from some GUI components instead of having to memorize so many : functions. : : Regarding the inspection of local vars you may also want to consider : displaying them in an ECB window. (Although ECB is not a mandatory component : of JDE, it seems like a natural fit for the problem.) Maybe having the : option of having either Java GUI or ECB inspection view? : : : Regards, : Daniel : : _ : MSN Photos is the easiest way to share and print your photos: : http://photos.msn.com/support/worldwide.aspx :
Re: Extending JDE using Java (WAS: Gosling interview)
Daniel Hegyi [EMAIL PROTECTED] writes: I think this would be great! JDE is already a very powerful IDE, that is, it has a great deal of functionality. But I'm concerned with the UI aspect of it. Emacs-ers are used to doing M-x all the time, however, I think it could benefit much from some GUI components instead of having to memorize so many functions. You sound like you are unaware of the menu-bar that has been a feature of Emacs since the 18.x days. I don't remember the last time I needed to do anything in JDE that wasn't accessible from the menu-bar (even if I did find it quicker to use the keyboard). -- Jason Rumney
Re: Extending JDE using Java (WAS: Gosling interview)
That may be so. All I meant to say was that considering it from a UI perspective a natural fit to the problem would be putting the inspection view in an ECB window as opposed to having to ALT-TAB constantly or arranging the inspection window and Emacs frame. Neverthless, I find that having a Java GUI for this is still better than splitting the Emacs window into three parts, making the code window very slim. Regards, Daniel Daniel, If you read Paul's note, the problem he's trying to solve arises precisely because it is too expensive to have a lot of chatter across I/O between emacs and an external java process. The solution he's considering -- put the display logic into the java process so as to avoid the I/O -- addresses the problem. Your proposal - a different window layout managed by ECB - adds more complexity (by bringing ECB into the mix) without doing anything to reduce the high cost of I/O between the debugger and its display. Eric _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
RE: Extending JDE using Java (WAS: Gosling interview)
I just wanted to throw the idea out since I believe that having a Java-based open API would allow JDE to evolve much faster, since more tools would be automatically available for integration *and* a lot more designers would be able to contribute (nothing against learning Lisp, please don't take me wrong). I agree. That would open a whole new dimension of development. I guess that's why a Java-based Emacs project has been initiated. I think what you are suggesting is impractical. I don't see how you can provide a robust and efficient extension framework that runs in a separate process from Emacs itself. Interprocess communications and synchronization pose very great, perhaps insurmountable difficulties for such a framework. I agree with this also. Theoretically you could have a java2lisp compiler and have developers translate their Java code to lisp. But a java2elisp compiler... probably too far-fetched. Daniel _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
RE: Extending JDE using Java (WAS: Gosling interview)
In one letter Paul K. writes: Why not use Java to add GUIs for these tasks to Emacs. Again, I think the opposition Emacs versus IDE is more perception than reality. In another letter Paul K. writes: I think what you are suggesting is impractical. I don't see how you can provide a robust and efficient extension framework that runs in a separate process from Emacs itself. Interprocess communications and synchronization pose very great, perhaps insurmountable difficulties for such a framework. I don't quite understand what you mean. Are you saying that it is a good idea to do _GUI_ development for Emacs in Java, but it is a bad idea to do much generic development for Emacs in Java? Or are you saying that any type (i.e., not just GUI) and a large amount of Java development is certainly a possibility but you don't support the notion of Java APIs for Emacs and consider a better solution the use of the beanshell? Regards, Daniel _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: Extending JDE using Java (WAS: Gosling interview)
For what it's worth, there is an editor written in java that pretty much tries to emulate emacs. It is JEdit. I download the latest version every now and then just to see what they are doing, but I still stick to my old and dear friend emacs. I am pretty sure it claims to have most of the features of JDE. Naturally, being java based, its extention language is java. =eas= On 26 Jan, Daniel Hegyi wrote: In one letter Paul K. writes: Why not use Java to add GUIs for these tasks to Emacs. Again, I think the opposition Emacs versus IDE is more perception than reality. In another letter Paul K. writes: I think what you are suggesting is impractical. I don't see how you can provide a robust and efficient extension framework that runs in a separate process from Emacs itself. Interprocess communications and synchronization pose very great, perhaps insurmountable difficulties for such a framework. I don't quite understand what you mean. Are you saying that it is a good idea to do _GUI_ development for Emacs in Java, but it is a bad idea to do much generic development for Emacs in Java? Or are you saying that any type (i.e., not just GUI) and a large amount of Java development is certainly a possibility but you don't support the notion of Java APIs for Emacs and consider a better solution the use of the beanshell? Regards, Daniel _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
RE: Extending JDE using Java (WAS: Gosling interview)
Daniel Hegyi writes: In one letter Paul K. writes: Why not use Java to add GUIs for these tasks to Emacs. Again, I think the opposition Emacs versus IDE is more perception than reality. In another letter Paul K. writes: I think what you are suggesting is impractical. I don't see how you can provide a robust and efficient extension framework that runs in a separate process from Emacs itself. Interprocess communications and synchronization pose very great, perhaps insurmountable difficulties for such a framework. I don't quite understand what you mean. Are you saying that it is a good idea to do _GUI_ development for Emacs in Java, but it is a bad idea to do much generic development for Emacs in Java? Or are you saying that any type (i.e., not just GUI) and a large amount of Java development is certainly a possibility but you don't support the notion of Java APIs for Emacs and consider a better solution the use of the beanshell? I think it is practical to use Java to extend Emacs where not much interaction is required between Emacs and the extension, the wizards and the debugger are examples. It may even be possible to provide those extensions with a Java GUI. Pettar Maehlen and I have been discussing the possibility of creating a Java window for JDEbug to display local variable values when stepping through a program. Currently displaying local variables slows down stepping significantly because it involves sending significant amounts of text across the standard I/O channel to Emacs. A separate local variable window that lives in the debugger process instead of the Emacs process would eliminate this bottleneck. - Paul
RE: Extending JDE using Java (WAS: Gosling interview)
Nascif Abousalh-Neto writes: -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Nascif Abousalh-Neto writes: [snip] I had the impression you had not read my e-mail entirely; I had mentioned that JDE already uses Java for many tasks just two paragraphs below. I apologise for writing an e-mail so long. I did read your mail through but hastily as I was about to go out the door and wanted to fire off a quick reply. [snip] I just wanted to throw the idea out since I believe that having a Java-based open API would allow JDE to evolve much faster, since more tools would be automatically available for integration *and* a lot more designers would be able to contribute (nothing against learning Lisp, please don't take me wrong). I think what you are suggesting is impractical. I don't see how you can provide a robust and efficient extension framework that runs in a separate process from Emacs itself. Interprocess communications and synchronization pose very great, perhaps insurmountable difficulties for such a framework. - Paul
RE: Extending JDE using Java (WAS: Gosling interview)
Matt Munz writes: Nascif, I have been curious about the BeanShell since I heard about it, but haven't tried it yet. It sounds like you're familiar with it. Nacif It is easy to have a Lisp function calling a Java method, using the BeanShell; not so much to do the reverse. Is this really true? It seems to me that your BeanShell app can spit out arbitrary lisp code as a text stream that could be dynamically loaded in emacs. Can you elaborate on what specifically makes it difficult to do 2-way interactions with BeanShell apps? This is what JDE beanshell apps do now. The JDE Lisp function bsh-eval-r accepts an arbitrary string of Java code as an argument, e.g., invocation of a static method defined by a JDE app, and sends it to the Beanshell's standard input. It then suspends Emacs until it receives a response from the Beanshell. bsh-eval-r assumes that the response is a Lisp form. When it receives the Lisp form, bsh-eval-r evaluates it. - Paul
