http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CLJ+AND+status+%3D+Resolved+ORDER+BY+priority+DESC An XML representation of a search request en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJ-1188 Clojure <p>Problem: Java consumers need an API into Clojure that does not drag in a ton of concrete implementation detail.</p> <p>Solution: Very small API class that allows looking up Vars (returning IFn), and reading data (as edn). Uses Clojure logic where possible, e.g. Var.intern.</p> <p>Current patch: <a href="http://dev.clojure.org/jira/browse/CLJ-1188" title="Public Java API"><del>CLJ-1188</del></a>-via-var-intern.patch</p> <p>Also considered:</p> <ul> <li>wrapper class (inconvenient for users, wrappers anathema in Clojure)</li> <li>common superinterface for IFn and Deref (unnecessary, might bloat vtable)</li> </ul> <p>See also <a href="http://dev.clojure.org/display/design/Improvements+to+interop+from+Java">http://dev.clojure.org/display/design/Improvements+to+interop+from+Java</a></p> CLJ-1188

Public Java API

Enhancement Major Resolved Completed Stuart Halloway Stuart Halloway Sat, 30 Mar 2013 08:37:15 -0500 Fri, 12 Apr 2013 13:51:46 -0500 Fri, 12 Apr 2013 13:51:46 -0500 Release 1.6 0 0 <p>the attached patch would turn</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>... public static Var ENQUEUE = RT.var("greenmail.smtp","enqueue"); ... ENQUEUE.fn().invoke(userManager, state.getMessage()); ... </pre> </div></div> <p>in to something like</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>... public static VRef ENQUEUE = API.vref("greenmail.smtp/enqueue"); ... ENQUEUE.fn().invoke(userManager, state.getMessage()); ... </pre> </div></div> <p>what is the value of VRefs over using Vars directly?</p> <p>using this from a java api, it looks like if the namespace the var is in is not loaded when you go to create a VRef it will return null, generally my java code that calls clojure looks something like</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>public static Var FOO = RT.var("namespace", "name"); public static NAMESPACE = Symbol.intern("namespace"); public static Var REQUIRE = RT.var("clojure", "require"); static { REQUIRE.invoke(NAMESPACE); } </pre> </div></div> <p>can you tell me without checking the java/jvm spec if FOO is null? does the static init block run before or after static fields are init'ed? returning null just seems like a bad idea.</p> <p>Per discussion on the ticket and with Rich, the wrapper-free approach (Apr 3 patch) is preferred.</p> <p>Hi Kevin,</p> <p>The purpose of not returning Vars is outlined in the <a href="http://dev.clojure.org/display/design/Improvements+to+interop+from+Java">design discussion</a>. That said, it is possible to return IFn, which does not drag in too much implementation detail (just a javadoc config tweak, see <a href="http://dev.clojure.org/jira/browse/CLJ-1190" title="Javadoc for public Java API">CLJ-1190</a>). Today's patch returns IFn, which addresses the wrapper ickiness demonstrated by your code examples.</p> <p>Java static initializers run in lexical order, and I trust Java programmers to know Java. </p> <p>I can think of several options other than returning null when a var is not available, and they are all complecting, inconsistent with Clojure, or both.</p> <p>Hey,</p> <p>Always returning the var is very consistent with clojure, it is what RT.var does. It is what the var lookups emitted by the compiler do. RT.var is most likely the point through which most java that calls clojure goes at the moment.</p> <p>As to "hiding" vars, how about creating a clojure.lang.ILink interface with both deref() and fn(), have Var implement it. The previous discussion I see linked all seems to presume hiding Var without discussion of why it should be hidden. What I see Rich saying is:</p> <blockquote> <p>So RT.var is the right idea. It would be nice to hide the Var class, <br/> but unfortunately we can't make ClojureAPI.var() return both IFn and <br/> IDeref without inventing a common subinterface. There are other <br/> similar details.</p></blockquote> <p>and</p> <blockquote> <p>We will need an interface unifying IDeref and IFn for the return type <br/> of API.var()</p></blockquote> <p>It seems like Rich is suggesting that ILink or whatever should also bring in IFn, but I wonder if having a fn() that does the cast for you is an acceptable alternative to that.</p> <p>The API should be called var, not fn, and should return IFn. Also, I really want the logic of RT.var (i.e. Var.intern) to be used, not this new logic. Please find another way to handle the string/symbol support.</p> Approval Ok Global Rank Patch Code and Test http://dev.clojure.org/jira/browse/CLJ-1174 Clojure <p>The API docs for Clojure 1.4 (<a href="http://clojure.github.com/clojure/branch-clojure-1.4.0/index.html">http://clojure.github.com/clojure/branch-clojure-1.4.0/index.html</a>), linked to from <a href="http://clojure.github.com/clojure/">http://clojure.github.com/clojure/</a>, returns a 404.</p> <p>I logged it under this category because I can't see anywhere else to log bugs about clojure.org.</p> All CLJ-1174

Website doc link for 1.4 api docs returns a 404

Defect Minor Resolved Completed Tom Faulhaber Ed O'Loughlin Tue, 5 Mar 2013 05:50:53 -0600 Tue, 5 Mar 2013 20:29:46 -0600 Tue, 5 Mar 2013 20:29:46 -0600 Release 1.4 0 0 <p>Fixed. Thanks for pointing this out.</p> Global Rank http://dev.clojure.org/jira/browse/CLJ-999 Clojure <p>The api-index.html includes wrong links for the following:</p> <ul class="alternate" type="square"> <li>All entries for all listed as part of clojure.test.tap</li> <li>All entries for all listed as part of clojure.test.junit</li> <li>All entries for all listed as part of clojure.core.protocols</li> </ul> <p>The links point to pages that do not exist. The problem is that the documentation for those entries is on a "parent" page, for example, the link clojure.core.protocols-api.html#clojure.core.protocols/internal-reduce should have been clojure.core-api.html#clojure.core.protocols/internal-reduce</p> <p>Not a huge bug for me, but you might want to get it fixed.</p> <p>And please give my huge thanks to whoever is in charge of the documentation, I'm the developer behind Dash, a Mac OS X documentation browser, and I was in the process of creating a documentation set for Clojure, and because you guys have an index, you made my work 1000 times easier.</p> CLJ-999

Wrong link in gh-pages index (api-index.html)

Defect Trivial Resolved Completed Tom Faulhaber Bogdan Popescu docs documentation Fri, 18 May 2012 21:58:46 -0500 Mon, 20 May 2013 16:24:12 -0500 Mon, 20 May 2013 16:18:25 -0500 Release 1.3 0 1 <p>Is this fixed now? Tom Faulhaber has regenerated the docs after the recent Clojure 1.5 release, and I think updated other things besides, so it might be.</p> <p>Nope, not fixed.</p> <p>This one either slipped by me or came in right when I was changing jobs so didn't stick in my brain.</p> <p>I'll take a look now. Thanks for the report, Bogdan, and thanks for the bump, Andy to get it on my radar.</p> <p>Tom, I'm happy to help if you need it. Could you document on a wiki page how autodoc is run here? I couldn't find such a page.</p> <p>This is fixed with gh-pages commit 919143e (autodoc doesn't follow the regular Clojure release path since it's a website built off the source checkins).</p> <p>Gabriel, Thanks for the offer. I fixed this one, but may take you up on it if more come up. </p> <p>There is currently no wiki page about the autodoc process but it's an excellent suggestion. I'll put it on my list to write something up. In the meantime source on the autodoc program itself is at <a href="https://github.com/tomfaulhaber/autodoc">https://github.com/tomfaulhaber/autodoc</a> and a description of how it works is at <a href="http://tomfaulhaber.github.io/autodoc">http://tomfaulhaber.github.io/autodoc</a>. Two caveats: (1) autodoc is currently undergoing a bunch of work (thus this bug fix) in preparation for a new release and (2) the documentation doesn't talk much about how it's used for documenting Clojure itself.</p> Global Rank Patch None