Re: IPlanet serverside debugging?
On 02 Apr 2003, [EMAIL PROTECTED] wrote: > Galen Boyer <[EMAIL PROTECTED]> writes: > >> Is this doable within the jdee? > > Which iPlanet? App Server and Web Server are completely > different products. I think iAS uses a standard JVM, in which > case using the remote debugging options would work. Okay. I'll look around and see how to connect the JDEE up to an app server. The information needed might be similar, or at least send me down a particular path. > But I think iWS uses its own JVM (from the Kiva days) and > implements part of the Servlet API as native code, so it might > be more difficult. The servlets as well as EJBs are executed within iAS. > If you are trying to debug something general in your servlet, > running it under Tomcat (or JBoss if you need more than just > servlets/JSPs) is probably easiest. If you are trying to debug > something specific to iPlanet, and can't run under a debugger, > System.out.print() is your friend. We can't control how it starts, but we still might be able to connect to the running process. Our problem is we don't know how to get our the JDEE into those hooks. What parameters and such does it expect... -- Galen Boyer
Re: IPlanet serverside debugging?
On Wed, 02 Apr 2003, [EMAIL PROTECTED] wrote: > On JBoss you only have to start it using a debud flag. I've > used jdee to do remote debugging on JBoss successfully. IPlanet is not a java only app server. I think this throws a wrench into the mix. I was wondering if there was anybody who had successfully accomplished this with the JDEE. I'm not sure if it is doable. -- Galen Boyer
Re: Why the JDEE?
On Fri, 21 Feb 2003, [EMAIL PROTECTED] wrote: > It is hopeless for the JDEE to try to compete > feature-for-feature with dedicated Java IDE's, especially > commercial IDE's. Maybe to further this, create an email list called, jde-plugin, or something like it. Then, as people want to discuss this idea and try to make Emacs have an architecture to keep up with the other IDE's, you can monitor and consult on the direction but not feel compelled to answer the direct questions to this particular list. And, when questions of this sort hit the jdee list, we can point them to this particular branch of JDEE discussion. We, as users, can also feel that we won't be going against your wishes as to the focus of the jdee, and hence, the jdee mailing list itself. -- Galen Boyer
Re: JDEE plugins (was JUCI)
On Wed, 19 Feb 2003, [EMAIL PROTECTED] wrote: > this plugin architecture may require enough redesign to rethink the > way JDE works now. One thing that seems prevalent in these thoughts is that the JDE is the central point of focus for this plugin architecture and the plugin architecture is hardwired to the JDE only. This obviously is understandable, because, many plugins are specific for enhancing IDEs. But there are plugins, ant, for instance, which are used outside of java IDEs. Would it make more sense to think of plugins as plugins to Emacs and the JDE as a client of the functionality newly present in Emacs? I'm worried that we are making the JDE an "everything java server" for Emacs, when shouldn't it be "just a client" to the elisp version of the everything java VM (where the VM might be the beanshell)? To say in a different way, it seems that Emacs should be enveloping a JVM, and supporting plugin architecture irrespective of the JDE. Then, the JDE should be utilizing this new elisp functionality. Then, to get new java functionality would be like going to http://anc.ed.ac.uk/~stephen/emacs/ell.html and getting a new cool elisp package to add to your Emacs experience. So what its written in java, just plug it in to Emacs and it has an elisp interface for you. Okay, I know, I'm probably smoking something, ... -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Re: JDEE plugins (was JUCI)
On Tue, 18 Feb 2003, [EMAIL PROTECTED] wrote: > Sounds like a great idea! > > I would volunteer to re-write the Jalopy > (http://jalopy.sourceforge.net/) integration package I put > together. I could also take a stab at a re-write for the > integration package for PMD (http://pmd.sourceforge.net/). > > Those Elisp->Java packages have an awful lot of code in common, > and it would be really nice to create a standard way to create > them - specially the bit about a standard way to integrate with > the BeanShell. > > I would like to suggest also a standard way for those packages > to present their output. A lot of them generate warnings or > errors that go very well in a "compilation" mode buffer. I > think this behavior can be abstracted as well. Maybe the beanshell could be viewed as an application server. Let me work through my thoughts. Would it make sense that java code that is executed through the beanshell not have to "println(someElispString);" but instead, any java code that is to be executed by the beanshell and subsequently eval'd into elisp, return a "java datatypes transformable to elisp" set of objects, like hashmap, array, ... Then, the beanshell could offer a set of classes which take these particular return objects and transform them into println's of elisp strings to be eval'd by elisp. The only part that doesn't seem clear to me is how to have elisp not have to understand the java code, its structure and exact names as well as its exact syntax. I'm thinking, first an eieio interface to elisp be required to be implemented by the elisp code of the package. A mapping layer, maybe xml, or just elisp list, be used to wire elisp class/method names to java class/methods. Then, the elisp package integrates with a particular elisp interface and the java code integrates with a particular java interface and the elisp to java is the black box that none of the two sides of code knows about, taken care of by the beanshell's black box. This would also allow java requirements for some particular need of the JDEE to be given to a willing java coder and the elisp requirements given to a willing elisp coder and the two sides actually code in their respective VMs without having to hook the two, fairly incompatible VMs up during development. Of course, what I'm thinking is that a JDE user could integrate some jakarta package by working with Paul on the java interface needing to be implemented. Paul or another of the elisp studs, then codes up the elisp side of the house waiting for the java coder to finish his work. Then, elisp becomes a client and the java code becomes the middleware implementing interfaces the beanshell application server will be executing. -- Galen Boyer
Re: removing speedbar ?
On 28 Jan 2003, [EMAIL PROTECTED] wrote: > Well what is the way to remove earlier speedbar , and > especially how to do it correctly if I already installed > speedbar with almost tha default paths? Thanks in advance. First, try this for an example. At a command prompt type, "emacs --no-site-file --no-init-file" What you see in the Emacs instance with zero customizations. Now type "C-h v load-path [ret]" The answer you see in the mini-buffer is the default load-path for every Emacs instance. Now, in this default Emacs instance's *scratch* buffer, add the line, (add-to-list 'load-path "c:/emacs/site-lisp/speedbar") Now, at the end of that above line, type C-x C-e. See how the path you explicitly typed is added before the default one you saw before? Actually, do the C-x C-e again. See how nothing changed? So, use add-to-list on the load-path variable in your .emacs and whatever paths you add will be traversed before the default paths. The last thing you, of course, must make sure of is that the paths you specify point to the _exact_ path of the speedbar. -- Galen Boyer
Re: AW: jde and j2ee ...thanks giving !
On Thu, 6 Feb 2003, [EMAIL PROTECTED] wrote: > --- Galen Boyer <[EMAIL PROTECTED]> wrote: > The Zsh mailing list, which I'm also on is roughly set up like > this: > > zsh-announce -> zsh-users -> zsh-developers > > Messages fall through toward the right. i.e. anything sent to > zsh-announce will be received by all three, while anything sent > to zsh-developers, stays amongst developers. This way > zsh-announce subscribers aren't bombarded by a ton of messages. > > JDEE can use a similar structure: > > jde-anounce -> jde-java -> jde-users -> jde-developers But then this list would get the questions that Greg was specifically trying to avoid. Why not have people sign up for it seperately? P.S. You guys been checking out the newserver, gmane.org? It is an nntp interface for any public mailing list that either has been signed up or if you can't find it there, you can sign it up. I don't download emails anymore, I read everything through a newserver. SOME VERY PERTINENT EMAIL LISTS AND THEIR NNTP NAMES: jde list== gmane.emacs.jdee ntemacs list== gmane.emacs.windows xae list== gmane.emacs.xae bbdb list == gmane.emacs.bbdb.user There are 56 mailing lists with emacs in their names. http://gmane.org It was started and is admined by the fellow that coded Gnus. -- Galen Boyer
Re: AW: jde and j2ee ...thanks giving !
On Wed, 5 Feb 2003, [EMAIL PROTECTED] wrote: > From the JDEE website: > >The JDEE mailing list provides a technical support, design, and >news forum for JDEE. It has more than 600 members. If you are >having problems setting up or using the JDEE, would like to propose >and discuss enhancements, or simply be advised of the latest JDEE >developments, this is the place to turn. > > Nothing in there about "talking about Java". Maybe there can be another mailing list added [EMAIL PROTECTED]? Then, people who use the JDEE could discuss java together. I know that this might add value, at least those that are already Emacs users but just starting out in java. Starting a whole new programming paradigm seems a bit cumbersome with Emacs packages cause you not only are struggling with the language but you are also struggling with the package. Maybe as one migrates from another environment, like JBuilder, the analogy questions can be fielded in this list? Maybe people could use the JDEE to share/create java tutorials that teach how to program java while adding specifically how to do a specific programming operation more quickly in the JDEE? This could then be handed back to Paul as add-on documentation. Just a thought anyways. -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Re: BeanInfo wizard anyone?
On Fri, 06 Dec 2002, [EMAIL PROTECTED] wrote: > > If I could, then I would be able to make really powerful things > without lisp, in plain java. But then I may as well switch to > jedit altogether ;-) I won't, just teasing! This is probably the reason that Emacs seems like a neanderthal to the "modern" editor. The JVM is the rage, but Emacs is written in a virtual machine which isn't the rage. Making those two able to communicate is an issue the Paul is solving quite well, but the solution isn't the "sexy" java one. Its an Elisp one. Its too bad that alot of today's great java developers never turned to Emacs for their environment. I think Paul has shown that Emacs can, should and will keep up with almost any new technology. If we had even more java guys interested in Emacs, it would help a bunch. But, then, this is why your idea seems so appealing. Having an Elisp|Java interface would mean that java and elisp guys could partition what they are working on to the defined interfaces. -- Galen Boyer
Re: BanInfo wizard anyone?
On Fri, 6 Dec 2002, [EMAIL PROTECTED] wrote:
>
>> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Galen
>> Boyer Sent: Friday, December 06, 2002 8:45 AM To:
>> [EMAIL PROTECTED] Subject: Re: BanInfo wizard anyone?
[...]
>> The translation layer could handle things like the java method
>> signature returning, say, a hashmap. The layer could have a
>> hashmap to alist converter.
>
> I've actually got a working prototype of a generic
> interface/translation layer that does just that. For now, I'm
> calling it JUCI (JDEE Universal Communication Interface). It
> allows elisp to call java and java to call back to elisp in a
> standard manner. It's still very alpha. One (minor, IMHO)
> drawback is that it requires JDK 1.3 or greater, because I'm
> making use of the java.lang.reflect.Proxy mechanism.
>
> My plan in the near term is to use it to try to integrate
> Transmogrify, which requires that the editor implement a 'Hook'
> interface for getting info like the current position of the
> cursor, list of files in the project, etc.
>
> Calling java from elisp is straightforward; you create a java
> interface containing the methods you wish to call from elisp
> and an implementation of that interface that has a default
> constructor:
>
> public interface MyHelper {
> Object doSomething(Object arg);
> }
>
> public class MyHelperImpl implements MyHelper {
> public MyHelperImpl() {}
>
> public Object doSomething(Object arg) {
> // ...
> }
> }
>
> On the elisp side, all you would need to do is declare a defun
> like this:
>
> (defun my-helper-do-something (arg)
> (jde-juci-invoke-java "MyHelperImpl" "doSomething"))
>
>
> For java code that calls elisp, you declare just an interface.
> On the elisp side, you implement that interface by creating a
> defun with a name following certain conventions and a matching
> arglist:
>
> public interface MyPrompt {
> String getUserInput();
> }
>
> (defun my-prompt-get-user-input ()
> (read-from-minibuffer "Input: "))
>
>
> // java code that invokes elisp
>
> Prompt prompt = (Prompt)
> jde.juci.ConnectionFactory.getConnection(MyPrompt.class);
> String result = promt.getUserInput();
>
> This will cause emacs to enter the minibuffer, capture the
> user-entered string, and return it to the java code.
>
> My hope is that the JDEE community will find this approach
> useful and that I can find enough time to clean up the code,
> document it and make it robust. I'd appreciate any feedback.
I see. You aren't referencing the beanshell here. Are you
opening up a direct connection to a JVM?
--
Galen Boyer
Re: BanInfo wizard anyone?
On Fri, 6 Dec 2002, [EMAIL PROTECTED] wrote: > Another idea would be to add options to the jde-jeval > function or new commands to > > * evaluate a bsh expression (e.g., a script invocation) > and insert the result in a new Java source buffer > > * evaluate a bsh expression and insert the result at > point in the current buffer > > This would make it easey for users who are not proficient > in Lisp to use BeanShell scripts (i.e., Java) to > generate Java source code inside Emacs. Maybe there could be a translation layer from beanshell/java to elisp? If this were in place, the call for java help from the non-elisp guy could go something like, you could present a java interface that you would like implemented by someone. They could run off and code java and hand back their code. Your interface could then run through your beanshell-to-elisp translation layer and the elisp guys could make it happen in Emacs. The translation layer could handle things like the java method signature returning, say, a hashmap. The layer could have a hashmap to alist converter. Then, also, there could be cool things like Elisp debugging switching to java debugging when the debugger hits the translation layer. -- Galen Boyer
Re: JDEE installer?
On Wed, 04 Dec 2002, [EMAIL PROTECTED] wrote: > > Emacs IS changing. The question is, is the change fast enough. As far as I can tell, Gnus, in its infancy, used to be horrible. Other newsreaders blew it away. Now, it does things other newsreaders can't dream of doing. Emacs had the issue that it is written in an Elisp Virtual Machine, while its Java IDE development needed to talk to a Java Virtual Machine. I believe most popular java editors are written in java so they didn't have this issue. But, now, the JDEE is close to on-par with the best IDE's for java while giving the java development experience the Emacs flavor, which we can all appreciate. So, in the same view as Gnus, I can't imagine how powerful the JDE will be a year from now for coding java. -- Galen Boyer
Re: Refactoring Wish List
On Mon, 2 Dec 2002, [EMAIL PROTECTED] wrote: > Maybe we should have a page somewhere and vote? A system like > bugzilla to track requirements/bugs and get user input on the > most desirable ones would be nice. Maybe the wiki? -- Galen Boyer
This mailing list can be read through a newsreader.
There is a new service to provide access to public email lists through one's newsreader. The address is gmane.org. There is a gmane hierarchy, gmane.emacs which has lots of list dear to many. Inclusive of these are: gmane.emacs.jdee gmane.emacs.windows (This is the ntemacs list) gmane.emacs.xae This was started and is admin'd by the same fellow who authored Gnus. He "hates" mailing lists, so he decided to provide an nntp gateway to them. He also is providing support for removing spam, and I trust the he should know some of the best ways to get rid of spam. looking to provide a "proper" search engine as well. I think its a great idea cause now I can cancel my subscriptions to these lists and do not have to handle the pop downloads and other such self-service type stuff. -- Galen Boyer
Re: What's up with abbrev-mode getting too greedy?
On 12 Nov 2002, [EMAIL PROTECTED] wrote: > I put the following in my .emacs and nothing else. > > (add-to-list 'load-path "~/") (add-to-list 'load-path > "c:/emacs/site-lisp/packages/jde-2.2.9beta12/lisp") (add-to-list > 'load-path "c:/emacs/site-lisp/packages/eieio-0.17beta4") > (add-to-list 'load-path > "c:/emacs/site-lisp/packages/semantic-1.4beta14") (add-to-list > 'load-path "c:/emacs/site-lisp/packages/speedbar-0.14beta4") > (add-to-list 'load-path "c:/emacs/site-lisp/packages/elib-1.0") > > (require 'jde) > (jde-abbrev-mode) > > > After Emacs loaded (and I didn't even open a .java file), I did, M-x > list-abbrevs and got a bunch of jde abbrevs for both my fundamental > mode and elisp modes as well. > > Can somebody else try this out, with your correct load paths of > course. Okay, The problem lies in the function jde-init-abbrev-table, when it is called by the (jde-abbrev-mode) line. (defun jde-init-abbrev-table () "Load the abbrev table. Load it with a set of abbrevs that invoke an anonymous function that does the expansion only if point is not in a quoted string or a comment." ;; Note the use of lexical-let - must have the common lisp packages ;; around, since the anonymous function needs the closure provided by ;; lexical-let. (interactive) ;; (setq local-abbrev-table (make-abbrev-table)) (mapc (lambda (x) (lexical-let ((abbrev (car x)) ; this is the abbrev, lexically scoped (expansion (cdr x))) ; this is the expansion (define-abbrev local-abbrev-table abbrev "" (lambda () (if (jde-parse-comment-or-quoted-p) (insert abbrev) ; insert the abbrev in quote/comment (insert expansion))) ; proceed with expansion elsewhere 0))) jde-mode-abbreviations) (if jde-gen-cflow-enable (jde-gen-load-abbrev-templates)) (setq abbrevs-changed nil)) The line containing "(setq local-abbrev-table (make-abbrev-table))" was commented out (I downloaded 2.2.9 and the same commented section is there). I uncommented and retried my previously mentioned .emacs and nothing was set in the lisp-interaction-mode-abbrev-table on Emacs start. I haven't yet run Emacs fully with this line uncommented, but maybe it was commented inadvertently and nobody caught it? Anyways, I will recompile jde.el with this line uncommented and see how things go. I'm still going to be digging through elisp to understand the ramifications of the line as well. -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
What's up with abbrev-mode getting too greedy?
I put the following in my .emacs and nothing else. (add-to-list 'load-path "~/") (add-to-list 'load-path "c:/emacs/site-lisp/packages/jde-2.2.9beta12/lisp") (add-to-list 'load-path "c:/emacs/site-lisp/packages/eieio-0.17beta4") (add-to-list 'load-path "c:/emacs/site-lisp/packages/semantic-1.4beta14") (add-to-list 'load-path "c:/emacs/site-lisp/packages/speedbar-0.14beta4") (add-to-list 'load-path "c:/emacs/site-lisp/packages/elib-1.0") (require 'jde) (jde-abbrev-mode) After Emacs loaded (and I didn't even open a .java file), I did, M-x list-abbrevs and got a bunch of jde abbrevs for both my fundamental mode and elisp modes as well. Can somebody else try this out, with your correct load paths of course. -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Insert Javadoc for a whole bunch of files
Is there a way to turn off the prompting and just have the jde-javadoc-autodoc just assume it is correct for everything in a particular file? -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
The archives for this mailing list?
Is there anyplace to download a full archive, like the one found on the XAE site? I know the sunsite has an archive, but I like to open the whole thing and search with Emacs. -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Re: jde Digest 1 Nov 2002 18:19:07 -0000 Issue 553
On Sun, 3 Nov 2002, [EMAIL PROTECTED] wrote: > Galen Boyer writes: > > > > Along these lines, is there any EJB remote, home and bean > > generation help developed? > > > > Hi Galen, > > The latest version of the JDEE, 2.2.9beta12, has templates for > generating EJB session and entity beans automatically. For > example, to generate a session bean, select JDE New->EJB->Session > from the Emacs File menu. Hi Paul, I never actually looked there. I was trying to make this happen by JDE -> Code Generation -> Wizards -> Implement Interface Right now this drill isn't working correctly. I'm sure its a classpath issue. Question. You hardcoded these interface implementations outside of the above menu choices to allow for a user to customize what the defaults might be? I think this is probably pretty smart. Things like a default ejbActivate and ejbPassivate code would be shop specific. (BTW, your EntityBean default doesn't have the incantation of "implements EntityBean" in the generated code, very minor bug.) The functionality I was searching for is to be able to create one file which implemented an EJB interface, EntityBean or SessionBean and have Emacs jump in and also create the files for the remote and home interfaces as well. Even more extensive would be the ability for Emacs to create the XML descriptor files, maybe an XAE like dialog with gui dropdowns for the different choices based on the XML tags. I modified a test XAE file and put in the dtd incantation that Sun required. http://java.sun.com/dtd/ejb-jar_2_0.dtd";> This url wasn't found, so I modified the last line to point to the local dtd found in the unzipped version of the sdk: Then, I followed the menu items, DTD -> Parse DTD and vhalla, I had dropdowns for the EJBs. VERY, VERY, VERY, VERY, NICE Paul! Here was what I did next. Insert Element -> ejb-jar. My file then contained; Then, placing point in the middle of those tags, I did Insert Element -> Entity Bean. My file then contained; No matter what comes next, your XAE already supports the basis for what we would need to make this thing a one-stop, one file spawns the kitchen sink, EJB shopping environment. Your packages rock my Man! So, now, starting from implementing an EntityBean in java code, we could get the Remote, Home and XML Descriptors built automagically. For the XML descriptors, the and are the ones the user would need to enter (I'm only studying this architecture for close future professional coding, so I could be a bit off on the exact needs at this point). And, maybe the XAE could be hard-wired with the full list of entries for the tags which need to be typed and the XAE could be extended to make use of this list to prompt for the correct entries, so the user would get no misspellings. This would fit nicely with your prj.el structure, I'm sure. Where the files should be saved, what naming conventions for the files, ... -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Re: jde Digest 1 Nov 2002 18:19:07 -0000 Issue 553
On Sat, 02 Nov 2002, [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: >> Subject: [OT] Buffer loading magic? >> From: "James Higginbotham" <[EMAIL PROTECTED]> >> Date: Wed, 30 Oct 2002 17:22:05 -0600 > >> Can someone point me to something that would allow me to toggle >> between the source and unit test for a class, if my directory >> structure is usually something like: >> src >> com >> mycompany >> foo >> Bar.java >> test >> com >> mycompany >> foo >> BarTest.java >> Â…and my tests always end in 'Test.java'? >> Just wondering if someone has done this or something >> similar. If found an elisp snippet for C to header, but that >> assumes the same dir and I'm not elisp literate enough to >> determine how best to mod the code. > > Here's what I use on xemacs. I can't remember if I wrote these or > if I based them on code posted here... Along these lines, is there any EJB remote, home and bean generation help developed? -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Re: Question on how you coded JDE.
to the
> BeanShell for evaluation. jde-jeval-r assumes that the result of
> evaluating the Java statement is a Lisp expression and evaluates
> the Lisp expression. The idea here is that the JDEE speaks to Java
> (via the BeanShell) in Java and Java speaks back (via standard out on
> the BeanShell process) in Elisp. This, of course, assumes that the
> Java side of the dialogue has been written specifically to communicate
> with the Elisp side.
>
> For example, here is a complete implementation for an "Echo wizard" in
> which the Java side echod a string sent to it by the Elisp side in the
> Emacs minibuffer, using the Elisp "message" function.
>
>
> // Java file EchoWizard.java
> // compile this file and make sure that it
> // in jde-global-classpath (the BeanShell always
> // starts with jde-global-classpath
> package jde.wizard;
> public class EchoWizard {
>
> public static void echo(String msg) {
> System.out.println("(message \"" + msg + "\")");
> }
>
>}
>
> ;; echo-wizard.el
> (require 'jde)
> (jde-jeval-r "jde.wizard.EchoWizard.echo(\"sleepy hollow\");")
>
> You can find numerous instances of this "design pattern" in
> the JDE Elisp source code by searching for jde-jeval-r. The
> Java side of the dialog initiated by the Lisp code resides
> in the java subdirectory of the JDE directory.
>
> I hope this is clear. If not, I'd be happy to answer any further
> questions you have.
>
> - Paul
>
>
> Galen Boyer writes:
> > Paul,
> >
> > Have you written a simple elisp function and a couple of java
> > classes it calls that you could point me to in the JDE code?
> >
> > I'm starting a little project to use jdbc to build a dynamic sql
> > builder within Emacs and would like to use your code as my
> > blueprint. I've spent some time in your code and am a bit stumped.
> > I'm looking for an overall understanding of how and when you write
> > elisp versus java and how you keep a JVM running and available for
> > Emacs but your code is very sophisticated, which is hindering my
> > simplistic understanding needs. If there is a "sort of" simple
> > example where you have an elisp class, with methods that invoke a
> > simple java class I'd appreciate what their names are, and maybe a
> > couple of lines explaining the mapping. Actually, the examples
> > don't need to be simple as much as I need to know what the starting
> > elisp code is and when this elisp code actually ends for a
> > particular JDE behaviour. This would allow me to stay on track as
> > I gleam your strategies from your code.
> >
> > Thanks.
> > --
> > Galen deForest Boyer
> > Sweet dreams and flying machines in pieces on the ground.
> >
--
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.
Re: emacs JSP mode
On Wed, 31 Jul 2002, [EMAIL PROTECTED] wrote: > multimode switches between major modes (any major > modes; it is very flexible) based on tags you define. > So when you move past a <% it switches you to JDE. If > the most recent tag was a %>, then you will be in > html-mode. This is great, except that every time you > move past a <% it switches JDE, which takes some time. > I am still trying to decide if it is worth it. > Html-helper-mode is mcuh more powerful html editor, > and when you are inside <%-%> tags you can narrow to > that block and jde takes over. So you have to > "request" jde, which is les convenient. Take a look at mmm-mode.el It doesn't have the waiting issue and already has a jsp example found in mmm-sample.el. http://sourceforge.net/projects/mmm-mode I set up an SGML mode as my major mode and sql-mode as my minor mode and now I'm editing XSQL pages with commenting, abbrevs, highlighting ... and I see no performance degradation at all. -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Re: jsp/html/js environment
On Mon, 24 Jun 2002, [EMAIL PROTECTED] wrote: > On 18 Jun 2002, [EMAIL PROTECTED] wrote: > >>On Mon, 17 Jun 2002, [EMAIL PROTECTED] wrote: >> >>> Do you know of any work being done for .jsp files that involve >>> syntax highlighting, indenting, etc.? I'm currently using >>> html-helper-mode.el and works fine, but I could have thought I saw >>> an email awhile back >> >talking about JSP/HTML/JS derived from jdee. >> >>I just downloaded the mmm-mode.el package last night. I spent today >>using it. In it, you can define multiple modes by defining beginning, > ...snip... > > Do you mind posting the additions you made to your .emacs? (add-to-list 'load-path "c:/emacs/site-lisp/packages/mmm-mode-0.4.7") (require 'mmm-mode) (mmm-add-group 'xsql '((xsql-sql :submode sql-mode :front "\]*>" :back "
Re: Question on how you coded JDE.
On Mon, 3 Jun 2002, [EMAIL PROTECTED] wrote:
> The JDE uses Java primarily for tasks that require introspection,
> e.g., determining all the methods, fields, and ancestors of a
> class. Using Java for this purpose requires some scheme for
> interfacing the JDEE to a virtual machine.
>
> The approach that the JDE uses is based on the BeanShell. As you may
> know, the BeanShell is an interpreter that executes Java
> statements.
Your reply made me go play with beanshell a bit. Very, very slick. I
showed it around the office and now three of the java developers at the
company I'm contracting for are using it to do quick testing.
All I did was show the button example from the website and then changed
the text of the button with, button.setText("Galen"); and they
immediately downloaded it and put it in their classpath. Now, all I
need to do is get them to use the JDEE. Hey, the company is in Kendall
Square, want to make a field trip out and put on a JDEE show? :-)
> The JDE includes a command-line interface to the BeanShell that allows
> a user to start and terminate a BeanShell session and interact with
> the BeanShell in an Emacs buffer. The JDEE passes Java statements
> entered in the buffer to the BeanShell via interprocess I/O for
> evaluation and displays the result in the buffer.
>
> The JDEE also includes a function, jde-jeval-r, that allows a Lisp
> program to use the same interface to send Java statements to the
> BeanShell for evaluation. jde-jeval-r assumes that the result of
> evaluating the Java statement is a Lisp expression and evaluates
> the Lisp expression. The idea here is that the JDEE speaks to Java
> (via the BeanShell) in Java and Java speaks back (via standard out on
> the BeanShell process) in Elisp. This, of course, assumes that the
> Java side of the dialogue has been written specifically to communicate
> with the Elisp side.
>
> For example, here is a complete implementation for an "Echo wizard" in
> which the Java side echod a string sent to it by the Elisp side in the
> Emacs minibuffer, using the Elisp "message" function.
>
>
> // Java file EchoWizard.java
> // compile this file and make sure that it
> // in jde-global-classpath (the BeanShell always
> // starts with jde-global-classpath
> package jde.wizard;
> public class EchoWizard {
>
> public static void echo(String msg) {
> System.out.println("(message \"" + msg + "\")");
> }
>
>}
>
> ;; echo-wizard.el
> (require 'jde)
> (jde-jeval-r "jde.wizard.EchoWizard.echo(\"sleepy hollow\");")
This is elegantly simple.
> You can find numerous instances of this "design pattern" in
> the JDE Elisp source code by searching for jde-jeval-r. The
> Java side of the dialog initiated by the Lisp code resides
> in the java subdirectory of the JDE directory.
I will be perusing your code as I go. Now, I'll know the line where
elisp ends and java begins.
> I hope this is clear. If not, I'd be happy to answer any further
> questions you have.
It is quite clear. Thanks for the tutorial. It was exactly what I
needed.
--
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.
Re: JDK 1.4 JPDA enhancements.
On 08 Dec 2001, [EMAIL PROTECTED] wrote: > > Specifically the "HotSwap" class reloading is REALLY important > for me. Seems that the Visual Age claim to faim will be available for all now. I would bet Paul will jump on this when he gets the time. -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
Discussion from comp.lang.java.softwaretools on VAJ.
I think there are some things that VAJ does that the JDEE could do but doesn't right now. HERE IS A THREAD. From: [EMAIL PROTECTED] (Glenn G. D'mello) Newsgroups: comp.lang.java.softwaretools Date: 8 Aug 2001 10:57:25 -0500 User-Agent: Xnews/4.05.11 "George Duh-bya" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > [EMAIL PROTECTED] (Glenn G. D'mello) wrote in > news:[EMAIL PROTECTED]: > >> "Ingo Tolke" <[EMAIL PROTECTED]> wrote in >> news:9khu3i$lec$01$[EMAIL PROTECTED]: >> >>> I want to learn Java, and I am looking for the best (and free!!!) >>> IDE to do it. >> >> IBM VisualAge for Java: http://www.software.ibm.com/ad/vajava >> > > You are joking, right? VisualAge is the worst (by far) IDE for No I'm not. > beginners! You don't learn Java be using it, and can only use it if > you already know Java. Here's why I consider it the best IDE for beginners: 0. It gets the beginner thinking in terms of 'Objects' rather than 'files'. 1. No how do I create a package and how do I create classes in a package issues: Creating packages and classes/interfaces in a package is very intuitive. 2. No problems with 'classpath' issues: VisualAge allows you to group related packages in a 'project' and you only need to tweak the 'classpath' settings if your classes need to reference more than one 'user-created' project. 3. Hierarchical view of Package<->Classes. Right click on a class and select 'Open to Hierarchy' to view the inheritance (and implementation) hierarchy. 4. User defined visibility of methods: you can view all methods of the class you're working on, view all inherited methods, view inherited methods upto a named class 5. None of those 'Only one public class per java file issues'. VisualAge just gets out of the way and leaves you free to learn Java the language. And once you start using VAJ, a whole host of other benefits which file based IDEs can only dream about: 5. Method level source control VAJ tracks changes at the method level instead of at the 'file' level. This means that I can merge/diff code at the method level. This also allows multiple developers to work on the same java class (on different methods) without stepping on each others code. 6. Stack rollback in debugger VAJ gives me the ability to pause a running thread and roll back the stack to any point in the stack. 7. Incremental compilation VAJ gives me the ability to pause a thread, change code and restart the paused thread with the modified code without needing to recompile/ restart the application. Before VAJ, no other IDE let you do that (ok, Smalltalk developers can stop sniggering now). Incremental Compilation makes it possible to have a bug in a method in a class (such that that class will not compile under javac) and still have VAJ run that code because VAJ compiles the syntactically correct methods and flags all incorrect methods. Partially correct code compiles partially and runs, as long as the thread of control doesn't touch a missing (or incorrect) bit of code. 8. VCE (Visual Composition Editor) There isn't any better one for Java. VAJ's VCE is the only one I know of which can be used to build a non-visual application using Java Beans. It makes it possible to create an application without writing a single line of code. 9. Scrapbook VAJ's scrapbook acts like a java interpreter. You can type in a snippet (or a couple of pages) of java code and execute it without going to the trouble of creating a java file, compiling it and executing it. 10. Code Cross-referencing : VAJ lets me highlight an interface and shows me all classes that implement that interface. You can search/slice and dice your code in any way you can think of. 11. 'Problems page' VAJ has a 'problems page' that lists all compilation errors in the workspace. This feature is a lifesaver as you can see at a glance if your changes have impacted any other developer and what code needs to be changed. 12. 'Evaluation page' VAJ's debugger has an 'Evaluation page' where you can type in any bit of code that calls methods in any other class and have it operate on the variables (in the paused thread) currently visible in the debugger. Given all the benefits, I fail to see how file-based, 'non-java' aware (no, syntax highlighting does not make an IDE 'java aware') IDEs can be recommended. HTH, Glenn. -- Apologies. Due to the insane amounts of spam I get on every post to usenet, mail sent to the posting address is delivered to /dev/null. Post to the group or use my name at my sending domain for emailing. -- Galen Boyer It seems to me, I remember every single thing I know.
Re: Draft Response
On Thu, 19 Jul 2001, [EMAIL PROTECTED] wrote: > the web page should use the JDE name and expose the lawyer's > letter. I don't know. This could really backfire. I bet there are all sorts of legal ramifications if you make a private letter public. -- Galen Boyer It seems to me, I remember every single thing I know.
Re: Draft Response
On Thu, 19 Jul 2001, [EMAIL PROTECTED] wrote:
> I'd scrap the last paragraph.
I agree. I have already responded to this as well.
>
> Also, the second sentence ("...I was unaware that JDE was a
> trademark of ...") seems to say "yeah, sorry, you're right, but
> I didn't know..." My recollection from the earlier emails in
> this list is that JDE was NOT registered by them in 1996.
> Anyway, I think it concedes their point, which you shouldn't do
> (IMHO).
I agree with this point. Please, do not be apologetic about it.
Leave the door open, act as though you are reluctant, but still
considering a court case.
> Finally, The idea of putting a discaimer on your sight that you
> are not affiliated with JDEdwards (or JDPowers ;-) is a very
> good idea, and should perhaps be your primary response, not
> buried at the end.
Yes. This is a very good idea and shows that you are immediately
ready to work this out.
--
Galen Boyer
It seems to me, I remember every single thing I know.
Re: Draft Response
On Thu, 19 Jul 2001, [EMAIL PROTECTED] wrote: > Pending your reply, I have already desisted from using JDE on > the main web page for the Java Development Environment for > Emacs. If I receive a response from you denying my request, I > will remove JDE from subsidiary pages and from the > documentation as rapidly as I can. I like everything except this closing paragraph. It would be too easy for them to just say, well then decease. Don't threaten, but leave the door open for a fight, so that they would at least have the incentive to look at the web page and think about free software and such. They certainly aren't going to care about how many years you've put in, or that it is highly regarded or that it would cause confusion in the community... What they would care about would be something like. ,[ MAYBE YOU COULD WRITE SOMETHING LIKE ] | Many other open source software movements have had the same type | of threatening commands and they have decided to undergo a legal | battle to retain their rights. I do not want to do this, as it | would be very time consuming and costly, but please understand, | that if we were to have a legal battle over this, your reputation | could suffer, as it has in the previous legal battles with | free/open source software movements. ` Then quote them some examples. This would at least make them go through a process of discovery on what it is that they are threatening. -- Galen Boyer It seems to me, I remember every single thing I know.
Re: Name change
On Mon, 16 Jul 2001, [EMAIL PROTECTED] wrote: > The problem is that when people do searches and stuff, then > JDE will come up equally as JDE for Emacs and JDEdwards > (aren't they the ones who give out awards for best car and > what not)? But, who looking for JDEdwards will care about a java development environment? They will click on the JDEdwareds site. The JDE has nothing to do with JDEdwards business. It, in no way, is competing with their business model. I think there would be a good chance of winning this if we could find a pro bona attorney. -- Galen Boyer It seems to me, I remember every single thing I know.
Re: Renaming Proposal
On Wed, 18 Jul 2001, [EMAIL PROTECTED] wrote: > It all comes down to the fact that sending a cease and desist > letter seems to be a standard practice (and in fact is required > of a trademark owner to retain the rights to a trademark). > This doesn't mean that they will necessarily pursue litigation > if they find that you have a valid claim on the name. None of > that necessarily requires any court action. Interesting. Is there a point at which if you don't comply, then you will be pulled into court? Could you just hold off until that time to see if they are just doing this to cover their tracks? -- Galen Boyer It seems to me, I remember every single thing I know.
Re: Should the JDE require ECB?
On Fri, 15 Jun 2001, [EMAIL PROTECTED] wrote: > The combination of simple download and customizable layout will > probably bring in a lot of new users who are intimidated by the > install and/or emacs non-MS look. Is it the JDE or Emacs that intimidates people? I would say one cannot use the JDE until one understands how to use Emacs or any other package for that matter, and then, installing the JDE shouldn't be too much of an issue. -- Galen Boyer Don't know a thing if you ain't coded swing.
Can't crosspost to newsgroup (WAS) Re: Discussion about the ECB-layout - Development needs feedback from the users
This topic is also being discussed on the gnu newsgroups and this list can't see those responses. Is there anyway the JDE could get a gnu.emacs.jde group? In my estimation, it has established itself as deserving of this, but I don't know what one has to do to get this. Then, crossposting could be used for discussions like these and we could all benefit from the collective knowledge. -- Galen Boyer Don't know a thing if you ain't coded swing.
Re: Emacs JDE problem (possible bug)
On Fri, 27 Apr 2001, [EMAIL PROTECTED] wrote: > One fix might be for the user to create a file named > #jde_filesystem_root_dir# in the directory that the user wants > to be considered the root directory of the mounted > filesystem. The JDE prj file searching mechanism could then be > modified to stop its upwards search if it finds this file. Could you have a variable jde-root-directory-alist that the searching mechanism could compare against or would this be too expensive? -- Galen Boyer Don't know a thing if you ain't coded swing.
Re: ANN: XAE 1.0beta1 available...
On Thu, 25 Jan 2001, [EMAIL PROTECTED] wrote: > Please indulge me for a bit. I am in the process of setting up > another mailing list for the XAE. It should be ready within a > day or two. No problem at all. I should have just expected that you were doing that anyways. -- Galen Boyer New Orleans is sink'n man and I don't want to swim. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: ANN: XAE 1.0beta1 available...
Should we move our discussion to gnu.emacs.help? This isn't JDE specific and we could all use more eyes. -- Galen Boyer New Orleans is sink'n man and I don't want to swim. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
