http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+NREPL+AND+fixVersion+%3D+%220.2.0-beta9%22 An XML representation of a search request en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/NREPL-26 tools.nrepl NREPL-26

Middleware metadata + collection of middleware names => well-formed handler

Enhancement Blocker Closed Completed Chas Emerick Chas Emerick Fri, 10 Aug 2012 23:32:50 -0500 Mon, 20 Aug 2012 15:48:26 -0500 Mon, 20 Aug 2012 15:48:26 -0500 0.2.0-beta9 0 0 <p>See <tt>clojure.tools.nrepl.middleware</tt>, the metadata descriptors described there, etc.</p> Global Rank http://dev.clojure.org/jira/browse/NREPL-25 tools.nrepl NREPL-25

Metadata -> middleware/handler documentation

Enhancement Blocker Closed Completed Chas Emerick Chas Emerick Fri, 10 Aug 2012 23:31:46 -0500 Mon, 13 Aug 2012 23:31:47 -0500 Mon, 13 Aug 2012 23:31:11 -0500 0.2.0-beta9 0 0 <p>See <tt>clojure.tools.nrepl.middleware/wrap-describe</tt>, <tt>set-descriptor!</tt>, etc.</p> Global Rank http://dev.clojure.org/jira/browse/NREPL-23 tools.nrepl <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedHeader panelHeader" style="border-bottom-width: 1px;"><b>Stack Trace</b></div><div class="preformattedContent panelContent"> <pre>Exception in thread "nREPL-worker-2" java.lang.NullPointerException at clojure.core$refer.doInvoke(core.clj:3779) at clojure.lang.RestFn.applyTo(RestFn.java:139) at clojure.core$apply.invoke(core.clj:603) at clojure.core$load_lib.doInvoke(core.clj:5279) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:603) at clojure.core$load_libs.doInvoke(core.clj:5298) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:605) at clojure.core$use.doInvoke(core.clj:5392) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.main$repl.doInvoke(main.clj:259) at clojure.lang.RestFn.invoke(RestFn.java:1096) at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__337.invoke(interruptible_eval.clj:51) at clojure.lang.AFn.applyToHelper(AFn.java:159) at clojure.lang.AFn.applyTo(AFn.java:151) at clojure.core$apply.invoke(core.clj:601) at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1771) at clojure.lang.RestFn.invoke(RestFn.java:425) at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:36) at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__374$fn__376.invoke(interruptible_eval.clj:162) at clojure.core$comp$fn__4034.invoke(core.clj:2278) at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__367.invoke(interruptible_eval.clj:129) at clojure.lang.AFn.run(AFn.java:24) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) </pre> </div></div> NREPL-23

NPE when interruptible-eval/evaluate is passed a non-existant namespace

Defect Major Closed Completed Chas Emerick Joe Snikeris Sun, 22 Jul 2012 11:19:08 -0500 Mon, 20 Aug 2012 21:40:11 -0500 Mon, 20 Aug 2012 21:40:11 -0500 0.2.0 0.2.0-beta9 0 0 <p>I'm not sure which would be better: behave as if one wasn't passed in or return an error on the transport.</p> <p>Fixed to send an error with a <tt>status</tt> of <tt>"namespace-not-found"</tt>.</p> Global Rank http://dev.clojure.org/jira/browse/NREPL-11 tools.nrepl <p>In particular, no boxing of individual bytes or multiple en/decoding steps should be involved.</p> <p>This implies that:</p> <p>1. all string values should remain <tt>byte[]</tt> coming out of the bencode protocol support (which makes it more compliant with bencode anyway)<br/> 2. the string decoding should occur in the bencode transport impl<br/> 3. all string values should be decoded, <em>except</em> for those named in a reserved slot (say, <tt>"-unencoded"</tt>)</p> <p>All map keys should always be decoded to Strings.</p> <p>While nREPL should continue to be fully compatible with Clojure 1.2.x, let's not kill ourselves trying to optimize for 1.2.x as well as Clojure &gt;= 1.3.0; if necessary, just make sure the latter is fast. If 1.2.x benefits as well, then good.</p> NREPL-11

Ensure efficient bytestring (byte[]) support in bencode transport

Enhancement Major Closed Completed Chas Emerick Chas Emerick Tue, 21 Feb 2012 19:33:08 -0600 Tue, 21 Aug 2012 20:26:25 -0500 Tue, 21 Aug 2012 20:26:25 -0500 0.2.0-beta9 0 0 <p>How about “<tt>nrepl/unencoded</tt>” re point 3?</p> <p>Is that intended to become a namespaced keyword at some point (further up in the stack than the bencode parser or transport, of course)?</p> <p>If so, does that imply that other keys (perhaps "nonstandard" ones defined by middlewares) should be namespaced as well?</p> <p>Also, this is actually impacting the protocol; <tt>nrepl/*</tt> makes me think the slot is related to an "application-level" handler provided by nREPL.</p> <p>FWIW, my suggestion of <tt>-unencoded</tt> was a nod to Python's <tt>_foo</tt> and Clojure's <tt>-foo</tt> to denote private / internal members. &#42;shrug&#42;</p> <p>Namespaced keywords are indeed the inspiration. So that it should probably be more like <tt>clojure.tools.nrepl.transport/unencoded</tt> rather than just <tt>nrepl/unencoded</tt>. However it is not a requirement to be a real keyword. A qualified string works just as well. There could be a middleware which turns the map keys into keywords (considering also a possible namespace). ring has a similar middleware, IIRC. I think that qualified operation and result field values (in some form or the other) are a best practise in this respect.</p> <p>However your argument of <tt>unencoded</tt> being part of the protocol is valid. But then why should it be private? Document it in the official protocol spec and let middlewares also add fields to it. The question is then: what happens with nested structures (eg. <tt>:status</tt>, which has to be traversed now painfully)? If middlewares weren't allowed to add to it, then only <tt>:value</tt> would be an interesting target for <tt>unencoded</tt>. So a simple flag would suffice.</p> <p>In general, I still think a tagged protocol would have been the better solution since it also allows nesting and each slot knows whether it's encoded or not.</p> <p>Maybe we should clarify what middlewares are allowed to do. Is there already some documentation on this? (I'm must confess I'm not up-to-date with all the design changes.)</p> <p>Re: encoding, I've started to think perhaps nothing should be decoded by default, and middlewares can independently handle such things. The standard middlewares will stake out one approach, but that at least leaves open the possibility of a different convention emerging over time that can be adopted later.</p> <p>Opinions?</p> <p>Sorry, where is the code for this? No .patch here, and nothing in bitbucket looks right.</p> <p>Leaving aside the code for now, defaulting to unencoded strings continues to seem reasonable; a default <tt>Transport</tt> impl/substrate can perform the en/decoding, as well as establish a default convention for indicating that some fields values should be left unencoded and should not be decoded.</p> <p>The code is here: <a href="https://github.com/kotarak/tools.nrepl/tree/bencode-improvements2">https://github.com/kotarak/tools.nrepl/tree/bencode-improvements2</a></p> <p>Looks good, patch applied.</p> <p>I'm less and less sure re: <tt>-unencoded</tt>. Thinking back to your "tagged protocol" comment, adopting a convention of keys like <tt>"value/binary"</tt> (or something similar) would be quite a bit more flexible and somewhat simpler to handle.</p> <p>(Thinking of rich content, mime types could then be sent in e.g. <tt>"value/mime"</tt> — not that the transport would care about that, but it would at least be easy to pair up data with its "tag".)</p> <p>Thoughts?</p> <p>Releasing -beta9 now; further discussion of unencoded value semantics can continue elsewhere…</p> Global Rank http://dev.clojure.org/jira/browse/NREPL-8 tools.nrepl <p>If you want to use nREPL on Android (currently only possible with sattvik's fork of Clojure) then you need bigger stack sizes than Android's default 8k to eval even moderately complex expressions. For comparison: A regular JVM on a PC has default stack sizes around 256k ... 512k depending on platform.</p> <p>In nrepl.clj, modify</p> <p>(doto (Thread. r)<br/> (.setDaemon true))))))</p> <p>to read</p> <p>(doto (Thread. (.getThreadGroup (Thread/currentThread)) r "nREPL" 524288) ; 512k generous stack size<br/> (.setDaemon true))))))</p> <p>Note: There are warnings here <a href="http://bit.ly/u86tF1">http://bit.ly/u86tF1</a> about choosing a good stack size but since in practice nREPL seems to have &lt;10 threads running with 1 active client connection we can be generous here.</p> <p>The more advanced version would be to make this somehow configurable but that'd probably be over-engineering things.</p> Android NREPL-8

set stack size for Android

Enhancement Minor Closed Completed Chas Emerick Hank Android Fri, 30 Dec 2011 09:05:19 -0600 Wed, 3 Oct 2012 07:03:59 -0500 Wed, 3 Oct 2012 07:03:59 -0500 0.0.5 0.2.0-beta9 0 0 <p>Noted, thank you. I'll try to make sure a provision for this gets into the next significant release.</p> <p>My first inclination is to ensure that the stack size is configurable; a hardcoded size would likely be just as inappropriate in some environments as the system default.</p> <p>nREPL is now using Clojure's built-in agent threadpools. This should theoretically simplify things for you, correct? i.e. Isn't a patched build of Clojure necessary for use on Android for this stack size issue, among other reasons?</p> <p>The patched build is only necessary for the JVM byte code that the Clojure compiler dynamically generates to be converted to Dalvik bytecode. However adding additional android patches such as configuring the agent threadpool with a larger stack size do make sense. I'm not the official Android Clojure maintainer though &#8211; I guess there isn't an official one really &#8211; so my opinion on this only goes so far.</p> <p>Well, I think you have a solid case for expanding the scope of the android fork, or even for a change to parameterize the threadpools in Clojure itself.</p> <p>I'm going to close this; there's really nothing to be done from within nREPL given that it doesn't maintain its own threadpool anymore.</p> <p>Reopening; since the use of agents was a fool's errand, parameterizing stack size needs to happen.</p> <p>Now that I look at this again, there are a number of options in nREPL to solve this.</p> <p>First, you can provide an <tt>:executor</tt> argument to the <tt>interruptible-eval</tt> middleware. This could be any <tt>java.util.concurrent.Executor</tt>, so you can configure it to use whatever threads you want.</p> <p>Second, and if you want to minimize work and retain as much of nREPL's default configuration otherwise, you can patch in your own thread pool by binding <tt>#'clojure.tools.nrepl.middleware.interruptible-eval/configure-thread-factory</tt> like so:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">(def thread-group ...) (def stack-size ...) (defn android-thread-factory "Returns a <span class="code-keyword">new</span> ThreadFactory suitable <span class="code-keyword">for</span> use with android. This implementation generates daemon threads, with names that include the session id." [] (let [session-thread-counter (AtomicLong. 0)] (reify ThreadFactory (newThread [_ runnable] (doto (<span class="code-object">Thread</span>. thread-group runnable (format <span class="code-quote">"nREPL-worker-%s"</span> (.getAndIncrement session-thread-counter)) stack-size) (.setDaemon <span class="code-keyword">true</span>)))))) (with-bindings {#'clojure.tools.nrepl.middleware.interruptible-eval/configure-thread-factory android-thread-factory} (clojure.tools.nrepl.server/start-server ...))</pre> </div></div> <p>The above totally untested, but I hope you get the idea. Give it a shot, and let me know how it goes. I'm going to take off this issue's fix target for now.</p> <p>I hear good things at this point about people connecting to nREPL endpoints running on Android. Please file another issue if this or other Android-specific problems arise in the future.</p> Global Rank