Re: Proposed New Structure (starter for 10)
Troy Daniels <[email protected]> Tue, 27 Oct 2015 21:49:04 -0400
| Newsgroups | gmane.emacs.jdee.devel |
|---|---|
| Message-ID | <CALSS3zOHd1LA8A3eUBhjZSEJPfPsdCjHw3YBu8gK73EKcnaK3Q@mail.gmail.com> |
--===============8765983393345659670== Content-Type: multipart/alternative; boundary=001a1141b8726434fd052320674e --001a1141b8726434fd052320674e Content-Type: text/plain; charset=UTF-8 On Tue, Oct 27, 2015 at 6:38 AM, Phillip Lord <[email protected]> wrote: > > That's straight-forward, since the JVM knows about the classpath. > In fact, it should work already. I *think* calling > > (cider-classpath) > That was pretty simple. I had already found that, and just needed to be sure that functions called by the user would call the method that was calling cider. That is working, at least for imports. I just created an import in a file that did not have a prj.el. The first import was pretty slow, since it started the nrepl *and* the beanshell, but it is connected. > > should do this for the current-buffer. > > If I remember correctly, the stacktrace handling from cider works as > well. At least, those are the two bits of middleware that I have added > direct from cider. > > Is there other middleware that is likely to be useful? Troy > The issue with source is that the running JVM doesn't need to know where > the source code is -- this is not an issue in Clojure since (generally), > the JVM *does* know where the source code is. Still, there are some > pretty obvious heuristics to find the source, especially as the class > name gives you the filename. > > > > Phil > > > Troy Daniels <[email protected]> writes: > > > We also need to know about the classpath, so we can do completion and > > imports. Although tying in the classpath is the main focus of what I am > > doing at the moment. > > Troy > > > > On Mon, Oct 26, 2015 at 12:43 PM, Phillip Lord < > [email protected]> > > wrote: > > > >> > >> Yes, if I wanted to make a standalone jar, that's how I'd do it. For use > >> within ant or from a shell-script/batch this would be a good way to go. > >> For projects already using maven, then I'd leave it as. > >> > >> For me, at the moment, though, this is not an issue. My code is not > >> maven-centric, it's just where I have started. Support other mechanisms > >> of launch I do not think is hard. > >> > >> As I have said, the issue comes when we need to know about stuff > >> the project knows about, but the JVM doesn't -- source paths being the > >> obvious one. Are there many other settings like this? At the moment, I > >> don't know for sure, but nothing leaps to mind. > >> > >> > >> > >> > >> Paul Landes <[email protected]> writes: > >> > >> > If we're tightly coupling with clojure we _could_ also make it a > >> leiningen > >> > project, bake in the repl (add deps and API call in main) and compile > an > >> AOT > >> > uberjar. > >> > > >> > > >> > On Oct 26, 2015, at 6:56 AM, Phillip Lord <[email protected] > > > >> wrote: > >> > > >> >> > >> >> > >> >> It's worth noting that the only thing I am using maven for is > pulling in > >> >> the clojure dependencies and launch the JVM with the appropriate > project > >> >> settings. > >> >> > >> >> Getting another build tool to do the same thing would be > >> >> straight-forward enough. Even a shell script would work with a > prebuilt > >> >> jar (of clojure and the nrepl server). The current code is not really > >> >> maven-centric. I just happen to have used maven. > >> >> > >> >> Phil > >> >> > >> >> Paul Landes <[email protected]> writes: > >> >> > >> >>> I agree with Phillip writes and add that supporting two back ends at > >> >>> this point would be burdensome. > >> >>> > >> >>> For those that dislike maven there isn't any reason some template > >> config (pom) > >> >>> file couldn't be used in a temp directory (or even memory). Either > way > >> it > >> >>> would be pretty small since at best you'd only be (re)configuring > the > >> >>> source/build/test paths. > >> >>> > >> >>> > >> >>> On Oct 23, 2015, at 4:00 AM, Phillip Lord < > [email protected]> > >> wrote: > >> >>> > >> >>>> Troy Daniels <[email protected]> writes: > >> >>>> > >> >>>>> I checked out the clojure backend branch last night and played > >> around with > >> >>>>> it some. I had some trouble getting it to build, but eventually > >> solved > >> >>>>> those problems. I submitted a pull request with the changes I > made, > >> if you > >> >>>>> want to incorporate them. > >> >>>> > >> >>>> Bit spammed at the moment, but will do this. I tend not to use > melpa > >> >>>> but melpa stable, though, so there many be some version issues. > >> >>>> > >> >>>> > >> >>>>> I'd like to start integrating this into the main code base. > >> >>>>> > >> >>>>> I did have an idea for transition as well. The code that Phillip > >> wrote is > >> >>>>> maven-centric, and will not work without additional effort in a > >> project > >> >>>>> with an ant build, or various other build tools. So my idea was > to > >> use the > >> >>>>> nrepl if we can find a pom file, but otherwise fall back to the > >> existing > >> >>>>> code. This also means that functionality can be converted > piecemeal. > >> >>>> > >> >>>> This sounds reasonable, but I would say that maintaining two > backends > >> is > >> >>>> going to be a pain. I've tried in my code to separate out the > >> >>>> "maven-centric" and "everything else" part. This is why > "jde-nrepl" is > >> >>>> in a different package. > >> >>>> > >> >>>> Ultimately, I think a decision needs to be made. If this is the > root > >> we > >> >>>> go, then I would say it should be on the basis that we move > >> >>>> functionality out of the existing setup and into the clojure based > on. > >> >>>> > >> >>>> An alternative transition path would be to run beanshell from > inside > >> the > >> >>>> clojure middleware. Not thought that through, but maybe it would > work. > >> >>>> > >> >>>> > >> >>>>> For example, there is a cider function to get the classpath, so > >> >>>>> replacing jdee-*-classpath is fairly simple. Replacing the import > and > >> >>>>> completion functionality is more complicated, so would take > longer to > >> >>>>> replace. > >> >>>> > >> >>>> One issue I have is whether to run nrepl in the project > environment or > >> >>>> the maven environment. Unfortunately this makes a difference -- > maven, > >> >>>> for example, knows about source locations while the project does > not > >> (it > >> >>>> only needs the classpath). > >> >>>> > >> >>>> > >> >>>>> Phillips branch also has three (non-test) projects in a single > >> repository: > >> >>>>> java, lisp and clojure. I think this makes sense for several > >> reasons. It > >> >>>>> makes it obvious which version of the java code works with which > >> version of > >> >>>>> the lisp code. It also makes it simple to package the jars and > >> clojure > >> >>>>> with the lisp code to put on MELPA. It would be good to have > >> something > >> >>>>> better than the current top level build script, which is just a > shell > >> >>>>> script. > >> >>>> > >> >>>> Actually, there's a bunch of make files in there which work pretty > >> well. > >> >>>> > >> >>>> > >> >>>>> Does this all make sense? > >> >>>> > >> >>>> It does. > >> >>>> > >> >>>> Phil > >> >>>> > >> >>>> > >> > ------------------------------------------------------------------------------ > >> >>>> _______________________________________________ > >> >>>> jdee-devel mailing list > >> >>>> [email protected] > >> >>>> https://lists.sourceforge.net/lists/listinfo/jdee-devel > >> > --001a1141b8726434fd052320674e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Tue, Oct 27, 2015 at 6:38 AM, Phillip Lord <span dir=3D"ltr"><<a = href=3D"mailto:[email protected]" target=3D"_blank">phillip.lord@r= usset.org.uk</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> That's straight-forward, since the JVM knows about the classpath.<br> In fact, it should work already. I *think* calling<br> <br> =C2=A0 =C2=A0 =C2=A0(cider-classpath)<br></blockquote><div><br></div><div>T= hat was pretty simple.=C2=A0 I had already found that, and just needed to b= e sure that functions called by the user would call the method that was cal= ling cider.</div><div><br></div><div>That is working, at least for imports.= =C2=A0 I just created an import in a file that did not have a prj.el.=C2=A0= The first import was pretty slow, since it started the nrepl *and* the bea= nshell, but it is connected. =C2=A0</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <br> should do this for the current-buffer.<br> <br> If I remember correctly, the stacktrace handling from cider works as<br> well. At least, those are the two bits of middleware that I have added<br> direct from cider.<br> <br></blockquote><div><br></div><div>Is there other middleware that is like= ly to be useful?</div><div><br></div><div>Troy</div><div>=C2=A0</div><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> The issue with source is that the running JVM doesn't need to know wher= e<br> the source code is -- this is not an issue in Clojure since (generally),<br= > the JVM *does* know where the source code is. Still, there are some<br> pretty obvious heuristics to find the source, especially as the class<br> name gives you the filename.<br> <span class=3D"im HOEnZb"><br></span></blockquote><div><br></div><div><br><= /div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"im HOEn= Zb"> <br> Phil<br> <br> <br> Troy Daniels <<a href=3D"mailto:[email protected]">udalrich.sc= [email protected]</a>> writes:<br> <br> </span><div class=3D"HOEnZb"><div class=3D"h5">> We also need to know ab= out the classpath, so we can do completion and<br> > imports.=C2=A0 Although tying in the classpath is the main focus of wh= at I am<br> > doing at the moment.<br> > Troy<br> ><br> > On Mon, Oct 26, 2015 at 12:43 PM, Phillip Lord <<a href=3D"mailto:p= [email protected]">[email protected]</a>><br> > wrote:<br> ><br> >><br> >> Yes, if I wanted to make a standalone jar, that's how I'd = do it. For use<br> >> within ant or from a shell-script/batch this would be a good way t= o go.<br> >> For projects already using maven, then I'd leave it as.<br> >><br> >> For me, at the moment, though, this is not an issue. My code is no= t<br> >> maven-centric, it's just where I have started. Support other m= echanisms<br> >> of launch I do not think is hard.<br> >><br> >> As I have said, the issue comes when we need to know about stuff<b= r> >> the project knows about, but the JVM doesn't -- source paths b= eing the<br> >> obvious one. Are there many other settings like this? At the momen= t, I<br> >> don't know for sure, but nothing leaps to mind.<br> >><br> >><br> >><br> >><br> >> Paul Landes <<a href=3D"mailto:[email protected]">[email protected]= et</a>> writes:<br> >><br> >> > If we're tightly coupling with clojure we _could_ also ma= ke it a<br> >> leiningen<br> >> > project, bake in the repl (add deps and API call in main) and= compile an<br> >> AOT<br> >> > uberjar.<br> >> ><br> >> ><br> >> > On Oct 26, 2015, at 6:56 AM, Phillip Lord <<a href=3D"mail= to:[email protected]">[email protected]</a>><br> >> wrote:<br> >> ><br> >> >><br> >> >><br> >> >> It's worth noting that the only thing I am using mave= n for is pulling in<br> >> >> the clojure dependencies and launch the JVM with the appr= opriate project<br> >> >> settings.<br> >> >><br> >> >> Getting another build tool to do the same thing would be<= br> >> >> straight-forward enough. Even a shell script would work w= ith a prebuilt<br> >> >> jar (of clojure and the nrepl server). The current code i= s not really<br> >> >> maven-centric. I just happen to have used maven.<br> >> >><br> >> >> Phil<br> >> >><br> >> >> Paul Landes <<a href=3D"mailto:[email protected]">lande= [email protected]</a>> writes:<br> >> >><br> >> >>> I agree with Phillip writes and add that supporting t= wo back ends at<br> >> >>> this point would be burdensome.<br> >> >>><br> >> >>> For those that dislike maven there isn't any reas= on some template<br> >> config (pom)<br> >> >>> file couldn't be used in a temp directory (or eve= n memory). Either way<br> >> it<br> >> >>> would be pretty small since at best you'd only be= (re)configuring the<br> >> >>> source/build/test paths.<br> >> >>><br> >> >>><br> >> >>> On Oct 23, 2015, at 4:00 AM, Phillip Lord <<a href= =3D"mailto:[email protected]">[email protected]</a>><b= r> >> wrote:<br> >> >>><br> >> >>>> Troy Daniels <<a href=3D"mailto:udalrich.scher= [email protected]">[email protected]</a>> writes:<br> >> >>>><br> >> >>>>> I checked out the clojure backend branch last= night and played<br> >> around with<br> >> >>>>> it some.=C2=A0 I had some trouble getting it = to build, but eventually<br> >> solved<br> >> >>>>> those problems.=C2=A0 I submitted a pull requ= est with the changes I made,<br> >> if you<br> >> >>>>> want to incorporate them.<br> >> >>>><br> >> >>>> Bit spammed at the moment, but will do this. I te= nd not to use melpa<br> >> >>>> but melpa stable, though, so there many be some v= ersion issues.<br> >> >>>><br> >> >>>><br> >> >>>>> I'd like to start integrating this into t= he main code base.<br> >> >>>>><br> >> >>>>> I did have an idea for transition as well.=C2= =A0 The code that Phillip<br> >> wrote is<br> >> >>>>> maven-centric, and will not work without addi= tional effort in a<br> >> project<br> >> >>>>> with an ant build, or various other build too= ls.=C2=A0 So my idea was to<br> >> use the<br> >> >>>>> nrepl if we can find a pom file, but otherwis= e fall back to the<br> >> existing<br> >> >>>>> code. This also means that functionality can = be converted piecemeal.<br> >> >>>><br> >> >>>> This sounds reasonable, but I would say that main= taining two backends<br> >> is<br> >> >>>> going to be a pain. I've tried in my code to = separate out the<br> >> >>>> "maven-centric" and "everything el= se" part. This is why "jde-nrepl" is<br> >> >>>> in a different package.<br> >> >>>><br> >> >>>> Ultimately, I think a decision needs to be made. = If this is the root<br> >> we<br> >> >>>> go, then I would say it should be on the basis th= at we move<br> >> >>>> functionality out of the existing setup and into = the clojure based on.<br> >> >>>><br> >> >>>> An alternative transition path would be to run be= anshell from inside<br> >> the<br> >> >>>> clojure middleware. Not thought that through, but= maybe it would work.<br> >> >>>><br> >> >>>><br> >> >>>>> For example, there is a cider function to get= the classpath, so<br> >> >>>>> replacing jdee-*-classpath is fairly simple. = Replacing the import and<br> >> >>>>> completion functionality is more complicated,= so would take longer to<br> >> >>>>> replace.<br> >> >>>><br> >> >>>> One issue I have is whether to run nrepl in the p= roject environment or<br> >> >>>> the maven environment. Unfortunately this makes a= difference -- maven,<br> >> >>>> for example, knows about source locations while t= he project does not<br> >> (it<br> >> >>>> only needs the classpath).<br> >> >>>><br> >> >>>><br> >> >>>>> Phillips branch also has three (non-test) pro= jects in a single<br> >> repository:<br> >> >>>>> java, lisp and clojure.=C2=A0 I think this ma= kes sense for several<br> >> reasons.=C2=A0 It<br> >> >>>>> makes it obvious which version of the java co= de works with which<br> >> version of<br> >> >>>>> the lisp code.=C2=A0 It also makes it simple = to package the jars and<br> >> clojure<br> >> >>>>> with the lisp code to put on MELPA.=C2=A0 It = would be good to have<br> >> something<br> >> >>>>> better than the current top level build scrip= t, which is just a shell<br> >> >>>>> script.<br> >> >>>><br> >> >>>> Actually, there's a bunch of make files in th= ere which work pretty<br> >> well.<br> >> >>>><br> >> >>>><br> >> >>>>> Does this all make sense?<br> >> >>>><br> >> >>>> It does.<br> >> >>>><br> >> >>>> Phil<br> >> >>>><br> >> >>>><br> >> ------------------------------------------------------------------= ------------<br> >> >>>> _______________________________________________<b= r> >> >>>> jdee-devel mailing list<br> >> >>>> <a href=3D"mailto:[email protected]= t">[email protected]</a><br> >> >>>> <a href=3D"https://lists.sourceforge.net/lists/li= stinfo/jdee-devel" rel=3D"noreferrer" target=3D"_blank">https://lists.sourc= eforge.net/lists/listinfo/jdee-devel</a><br> >><br> </div></div></blockquote></div><br></div></div> --001a1141b8726434fd052320674e-- --===============8765983393345659670== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ --===============8765983393345659670== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ jdee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jdee-devel --===============8765983393345659670==--