<< Back to previous view

[NREPL-45] Laziness-forcing loses *out* bindings Created: 10/Dec/13  Updated: 19/Aug/14  Resolved: 25/Feb/14

Status: Closed
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.2
Fix Version/s: 0.2.4

Type: Defect Priority: Minor
Reporter: Colin Jones Assignee: Chas Emerick
Resolution: Completed Votes: 1
Labels: None

Attachments: File NREPL-45.diff     Text File nrepl-45.patch    

 Description   

This was reported in https://github.com/trptcolin/reply/issues/129

My current theory, outlined there, is that nREPL sets up session bindings for `out`, which since we're creating a lazy seq are lost before nREPL goes to print out the seq for transport back to the nREPL client (REPLy, vim-fireplace, etc.).

user=> (defn foo [] (println "a") (map (fn [x] (println "b") (throw (Exception. "oops"))) [1 2 3]))
#'user/foo
user=> (foo)
a

Exception oops  user/foo/fn--699 (NO_SOURCE_FILE:1)
user=> (doall (foo))
a
b

Exception oops  user/foo/fn--699 (NO_SOURCE_FILE:1)

Don't have time at the moment to dig in, but can do so later if nobody else gets to it first.



 Comments   
Comment by Colin Jones [ 21/Feb/14 5:19 PM ]

OK, more data: this is happening because of https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/pr_values.clj#L23, where the (with-out-str (pr v)) could be the first time a lazy sequence gets forced, so any side effects' printing gets thrown away.

The trick is distinguishing the actual side-effect printing from the printable value when the sequence is being forced. It seems like it comes down to this: we need to force lazy sequences in the same way that printing does, while keeping the value and the print output distinct. The attached patch does this (I opted to make a local instead of using the private #'clojure.core/pr-on).

I think this is good, but wouldn't mind a review before I push it.

Comment by Chas Emerick [ 25/Feb/14 4:28 AM ]

I'm going to reply on the reply ticket :-P, as I think the issue probably isn't nREPL.

As for the patch itself, I'm suspicious of printing values twice as a fix for anything. If output isn't being captured properly, then we should find the problem with how we're capturing output, not throw more output at the problem.

Comment by Chas Emerick [ 25/Feb/14 9:36 AM ]

Take a look at this, Colin. Your solution was correct, but can just drop into pr-values; with-out-str was too crude a hammer for what pr-values needs.

If you can, verify that this makes REPL-y (and any other tools you're interested in) work as expected. Feel free to commit it, or I can (you should have privs IIRC).

Comment by Colin Jones [ 25/Feb/14 11:56 AM ]

Yeah, I definitely like it better in pr-values, where the rest of the printing logic already lives. Committed as bbc5e02b665356e7dc33fe1d78346f17b3dec452.

Thanks!

Comment by Chas Emerick [ 25/Feb/14 12:04 PM ]

Nope, thank you. I'll get a release out sometime this week.





[NREPL-42] Reflection warnings in users' projects Created: 10/Jun/13  Updated: 19/Aug/14  Resolved: 06/Aug/13

Status: Closed
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.2
Fix Version/s: 0.2.4

Type: Defect Priority: Minor
Reporter: John Hume Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: reflection

Attachments: Text File 0001-Eliminate-some-reflective-calls.patch    
Patch: Code

 Description   

In a project that uses clojure.tools.nrepl.server, we see a handful of reflection warnings from nrepl.

The attached patch eliminates those.



 Comments   
Comment by John Hume [ 11/Jun/13 9:14 AM ]

I should clarify that this is an issue in 0.2.3, but JIRA doesn't know about that version yet.

Comment by Chas Emerick [ 06/Aug/13 6:02 AM ]

Patch applied @ 1c53a172a8, thanks!

There is one remaining reflection warning, only because I culled the "fix" from your patch; the reflection in that case is helping us avoid the extra code IMO.





[NREPL-46] nREPL crashes when required more than one time with :reload-all Created: 21/Dec/13  Updated: 19/Aug/14

Status: Open
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.2
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Alex Fowler Assignee: Chas Emerick
Resolution: Unresolved Votes: 1
Labels: bug
Environment:

Irrelevant, but the provided test case project is for CounterClockWise on Eclipse. Although it should run just fine with vanilla lein.


Attachments: Zip Archive nrepl-test.zip    

 Description   

When the namespace "clojure.tools.nrepl.server" is required more than once with :reload-all option, nREPL crashes. Accrding to current info it occures because some protocol instances get re-evaluated and are no longer the same JVM classes as they were before reload-all.

Steps to reproduce the bug in CCW:
1) Import the project into the workspace
2) Go into the core.clj
3) Click Clojure -> Load file in REPL
4) After the evaluation is complete, try evaluating (+ 1 2) in the repl. You should see no response at all.
5) Try writing something with letters, like "nrepl". The autocompletion will try and freeze and fail with the above exception.
6) Play around more to get a full hang or kill the REPL/Java to revive Eclipse.

Upon trying CCW autocompetion, the following exception occures, what might give some hint as to why:

Exception in thread "nREPL-worker-2" java.lang.IllegalArgumentException: No implementation of method: :send of protocol: #'clojure.tools.nrepl.transport/Transport found for class: clojure.tools.nrepl.middleware.pr_values$pr_values$fn$reify__1283
at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541)
at clojure.tools.nrepl.transport$eval7291$fn_7292$G7280_7299.invoke(transport.clj:16)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn_7726$fn_7739.invoke(interruptible_eval.clj:75)
at clojure.main$repl$fn__6597.invoke(main.clj:279)
at clojure.main$repl.doInvoke(main.clj:277)
at clojure.lang.RestFn.invoke(RestFn.java:1096)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__7726.invoke(interruptible_eval.clj:56)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.core$apply.invoke(core.clj:617)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1788)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:41)
at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn_1345$fn_1348.invoke(interruptible_eval.clj:171)
at clojure.core$comp$fn__4154.invoke(core.clj:2330)
at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__7760.invoke(interruptible_eval.clj:138)
at clojure.lang.AFn.run(AFn.java:24)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)



 Comments   
Comment by Chas Emerick [ 19/Aug/14 8:56 PM ]

Confirmed. Using lein repl (though you're right that the particulars of the tooling shouldn't matter):

user=> 3
3
user=> (require '[clojure.tools.nrepl.server] :reload-all)
nil
user=> 2

user=> 1

Not sure if it's the protocol or the types that are implicated (or both), but resolving this is going to be unpleasant.

Comment by Chas Emerick [ 19/Aug/14 8:57 PM ]

Couple of questions:

  • Does the fact that this occurs matter to anyone in a meaningful way?
  • Would an acceptable solution be that reloading of the affected namespaces be no-ops?




[NREPL-44] Expose JMX MBean to provide list of available nREPL endpoints Created: 06/Aug/13  Updated: 19/Aug/14

Status: Open
Project: tools.nrepl
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Chas Emerick Assignee: Chas Emerick
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In a development environment, one often has many nREPL servers running, sometimes more than one per project. This means that it's sometimes difficult to keep track of which ports are associated with which projects / processes, and existing per-project REPL tracking mechanisms (e.g. Leiningen/reply's repl-port file) are generally not up the job.

It would be great if nREPL exposed a JMX MBean that provided information on each active nREPL server, what URL(s) they'll respond to, and perhaps other details (what middleware is installed on each, etc). Clients could then use JMX to discover all of the nREPL servers on a given host, and present that information in tool-appropriate 'connect' dialogs, etc.



 Comments   
Comment by Alan Effrig [ 08/Aug/13 7:50 PM ]

How do you envision clients discover which processes have nREPL servers? How would it work in practice from the client's point of view? Would the client be responsible for knowing the JMX port & associated configuration? Do you envision this feature applying mainly to clients on the local machine or to any number of hosts?

When I've worked with JMX, part of the battle is knowing the proper port and associated JMX configuration for each process so a client knows how to connect, especially with a variety of processes on a given host. It is even more problematic in the cloud with dozens of servers. And then there is the complication that locally one can sometimes use the Attach API, a mechanism that differs from how JMX is accessed remotely. At the risk of thinking too much, is there any other standard discovery mechanism that might be appropriate to share the JMX port & configuration with potential clients? Would some sort of multicast/cluster mechanism work here?





[NREPL-40] Thread leak in clojure.tools.nrepl.transport$fn_transport? Created: 11/Mar/13  Updated: 19/Aug/14  Resolved: 19/Aug/14

Status: Closed
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.1, 0.2.2
Fix Version/s: 0.2.4

Type: Defect Priority: Major
Reporter: David Lao Assignee: Chas Emerick
Resolution: Completed Votes: 0
Labels: None
Environment:

Windows 7 x64, Oracle JDK 1.7.0.11 x64, clojure 1.4.0



 Description   

When trying out remote eval using your sample in the README, ie

(with-open [conn (repl/connect :port 59258)]
(-> (repl/client conn 1000) ; message receive timeout required
(repl/message {:op "eval" :code "(+ 2 3)"})
repl/response-values))

I'm noticing that hosting process leaking a thread each time the remote eval is called. Jconsole shows a clojure-agent-send-off-pool-xxx thread got spawn as result of the call. The stack appears to be pointing to the "while true" loop inside fn_transport.

java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
java.util.concurrent.SynchronousQueue.put(SynchronousQueue.java:878)
clojure.tools.nrepl.transport$fn_transport$fn__3912.invoke(transport.clj:44)
clojure.core$binding_conveyor_fn$fn__3989.invoke(core.clj:1819)
clojure.lang.AFn.call(AFn.java:18)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
java.util.concurrent.FutureTask.run(FutureTask.java:166)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
java.lang.Thread.run(Thread.java:722)

What do you recommend as way to free the thread? I have server code that calls nrepl on behave of client connections and the number of call can pile up fairly quickly.



 Comments   
Comment by David Lao [ 12/Mar/13 3:37 PM ]

Here is my workaround.

— a/src/main/clojure/clojure/tools/nrepl/transport.clj
+++ b/src/main/clojure/clojure/tools/nrepl/transport.clj
@@ -36,12 +36,12 @@
to the 2 or 3 functions provided."
([read write] (fn-transport read write nil))
([read write close]

  • (let [read-queue (SynchronousQueue.)]
  • (future (try
  • (while true
  • (.put read-queue (read)))
  • (catch Throwable t
  • (.put read-queue t))))
    + (let [read-queue (SynchronousQueue.)
    + transport-thread (future (try
    + (while true
    + (.put read-queue (read)))
    + (catch Throwable t
    + (.put read-queue t))))]
    (FnTransport.
    (let [failure (atom nil)]
    #(if @failure
    @@ -51,7 +51,7 @@
    (do (reset! failure msg) (throw msg))
    msg))))
    write
  • close))))
    + (fn [] (close)(future-cancel transport-thread))))))
Comment by Chas Emerick [ 06/Aug/13 5:47 AM ]

Very nice catch. I'd love to have a patch from you; do you have a CA filed? (see http://clojure.org/contributing)

Comment by Chas Emerick [ 18/Apr/14 10:07 AM ]

Ping: did you send in a CA? Would love to apply a patch from you for this.

Comment by Chas Emerick [ 19/Aug/14 8:43 PM ]

I wanted to get this out as part of 0.2.4, so implemented my own patch, committed as 20a3d15. Thanks for the report!





[NREPL-53] Middleware linearization is nondeterministically wrong Created: 02/May/14  Updated: 19/Aug/14

Status: Open
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.3
Fix Version/s: None

Type: Defect Priority: Critical
Reporter: Gary Fredericks Assignee: Chas Emerick
Resolution: Unresolved Votes: 0
Labels: None
Environment:

clojure 1.6.0



 Description   

I've had trouble getting my middleware ordered correctly, and have wittled it down to the following example which seems to only fail in some processes. I.e., it is deterministic within a particular jvm, but across jvms the result can change. My guess is that this has to do with hashing vars.

This code prints true (signifying a correct result) roughly 1/3 of the time and false otherwise.

(ns chas.core
  (:require [clojure.tools.nrepl.middleware :as mid]
            [clojure.tools.nrepl.middleware.pr-values]
            [clojure.tools.nrepl.middleware.session]))

(def wrap-foo identity)
(mid/set-descriptor! #'wrap-foo
                     {:expects #{#'clojure.tools.nrepl.middleware.session/session "eval"}})

(def wrap-bar identity)
(mid/set-descriptor! #'wrap-bar
                     {:requires #{#'clojure.tools.nrepl.middleware.session/session},
                      :expects #{"describe" #'clojure.tools.nrepl.middleware.pr-values/pr-values},
                      :handles {"stacktrace" {}}})

(defn -main
  []
  (println
   ;; should return true, since #'wrap-foo belongs later in the stack than
   ;; #'clojure.tools.nrepl.middleware.session/session due to its :expects
   ;; clause
   (->> [#'wrap-foo
         #'wrap-bar
         #'clojure.tools.nrepl.middleware.session/session]
        (mid/linearize-middleware-stack)
        (filter #{#'clojure.tools.nrepl.middleware.session/session #'wrap-foo})
        (= [#'clojure.tools.nrepl.middleware.session/session #'wrap-foo]))))


 Comments   
Comment by Gary Fredericks [ 02/May/14 10:35 PM ]

Interesting followup observation I made with Alan Malloy in IRC: if we remove "eval" from the :expects clause, it seems to return consistently true. On the other hand if we instead add #'clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval to the middleware list, suddenly it returns consistently false.

Comment by Gary Trakhman [ 04/Jun/14 3:35 PM ]

I should add my own experience report with this, hope to dig in to it someday soon: https://groups.google.com/d/msg/clojure/nUBBbYZHuTE/ScLBH-A2HkoJ

In my case, it was incorrectness, not indeterminism.

Comment by Chas Emerick [ 19/Aug/14 1:59 PM ]

Half of the middleware linearization stuff is too clever, the other half is really dumb. :-/

I'd love a patch for this. Absent one, I'll have to dig into it, but I'm not going to hold up 0.2.4 any further for that opportunity to come around.

Comment by Gary Fredericks [ 19/Aug/14 2:12 PM ]

Is this a fair summary of the requirements?

1) Should be deterministic
2) Should only return a result that respects the :expects and :requires clauses – if this is impossible it should throw an exception explaining why

Comment by Chas Emerick [ 19/Aug/14 2:58 PM ]

Yes, that's fair. I might add (3) try to not break anything significant that might rely upon undocumented behaviour, but I doubt that's helpful.





[NREPL-58] Inconsistency between session and eval responses Created: 04/Jun/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

Status: Closed
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.4
Fix Version/s: 0.2.4

Type: Defect Priority: Major
Reporter: Jeff Valk Assignee: Chas Emerick
Resolution: Completed Votes: 1
Labels: bug, patch,

Attachments: Text File 0001-eval-session-consistency.patch    
Patch: Code

 Description   

At present, the interruptible-eval handler sends the :value or :eval-error status message before it updates the session to reflect the new binding result. This leaves the session values, particularly *e, *1, etc inconsistent with the state implied by those response messages.

As a practical example, if we want to wrap the "eval" op to check for an :eval-error and add error detail to the response from *e, (get @session #'*e) needs to hold the exception that resulted in the :eval-error. At present, however, it still holds the previous exception, leaving us no way to retrieve the current one in band.

The attached (minimal) patch makes ensures the session is updated before "eval" responses are sent.



 Comments   
Comment by Jeff Valk [ 04/Jun/14 1:00 PM ]

In the event that the attached patch seems a reasonable fix, I should probably add that my CA will be in the mail shortly.

Comment by Bozhidar Batsov [ 13/Jun/14 8:05 AM ]

I'm just here to pledge my support for Jeff's patch. Btw, Jeff, few days later and you could have signed the CA electronically.

Comment by Jeff Valk [ 13/Jun/14 9:32 AM ]

The irony did not escape me. Anyway, my CA (in dead tree form) is now on file.

Comment by Chas Emerick [ 19/Aug/14 1:56 PM ]

Looks good, thanks for the patch Applied as f02956d.





[NREPL-59] Tracking source form positions in eval Created: 19/Jun/14  Updated: 19/Aug/14

Status: Open
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.3
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Bozhidar Batsov Assignee: Chas Emerick
Resolution: Unresolved Votes: 0
Labels: enhancement


 Description   

Dev tools writers using nREPL's eval op face the following problem - using the `eval` op you cannot pass information regarding the filename and the file position of the form you're evaluating and therefore afterwards you can't use find its definition. Because of this most CIDER users reload their source buffers all the time with `load-file`. Another implication of this problem is that exception backtraces have meaningless information about the position of the problem (usually something like `NO_FILE:1`). I've noticed that LightTable has a custom middleware for this, ritz used to have one as well, probably others too. Now I'm contemplating doing something similar for CIDER, but it seems to me this is basic functionality that should be supported out-of-the-box.

I'd like to propose that the default eval middleware be augmented to support some form of source form tracking to spare tool writers from having to reinvent the wheel.



 Comments   
Comment by Chas Emerick [ 19/Aug/14 1:50 PM ]

I agree that this should be baked in. `:line` and `:column` are some optional slots eval could accept (but should not require), with the obvious effect on the reader passed along to the compiler. This may be trickier than it sounds, especially if you're aiming to keep things at parity for both Clojure and ClojureScript (as code to be eval'd is read well before it hits interruptible_eval, in piggieback).

In any case, patch quite welcome.





[NREPL-57] Add Java version info to op "describe"'s response Created: 29/May/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

Status: Closed
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.3
Fix Version/s: 0.2.4

Type: Enhancement Priority: Minor
Reporter: Bozhidar Batsov Assignee: Chas Emerick
Resolution: Completed Votes: 0
Labels: None


 Description   

Currently the describe op's reply features the relevant nREPL and Clojure versions. It'd be nice if the underlying JVM version was included as well.



 Comments   
Comment by Chas Emerick [ 19/Aug/14 1:45 PM ]

Added in cb7ce41





[NREPL-56] Test suite failing on JDK 1.8 Created: 23/May/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

Status: Closed
Project: tools.nrepl
Component/s: None
Affects Version/s: 0.2.3
Fix Version/s: 0.2.4

Type: Defect Priority: Major
Reporter: Chas Emerick Assignee: Chas Emerick
Resolution: Completed Votes: 0
Labels: None


 Description   

e.g. http://build.clojure.org/job/tools.nrepl-test-matrix/154/CLOJURE_VERSION=1.6.0,jdk=Oracle%20JDK%201.8/console



 Comments   
Comment by Chas Emerick [ 19/Aug/14 12:38 PM ]

Thanks for the heads-up, fixed in 9c41e346053d6c3dbd7ae127b37b6582f894e9d2





[NREPL-60] Tests failing in build "Unable to resolve var: clojure.pprint/use-method in this context" Created: 04/Aug/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

Status: Closed
Project: tools.nrepl
Component/s: None
Affects Version/s: None
Fix Version/s: 0.2.4

Type: Defect Priority: Major
Reporter: Alf Kristian Støyle Assignee: Chas Emerick
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Moving-the-require-into-the-ns-declaration-makes-tes.patch    

 Description   

The tools.nrepl build has been failing since April 18th (http://build.clojure.org/job/tools.nrepl/269/console):

[INFO] Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: clojure.pprint/use-method in this context, compiling:(clojure/tools/nrepl/server.clj:110:3)
[INFO] 	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
[INFO] 	at clojure.lang.Compiler.analyze(Compiler.java:6445)
[INFO] 	at clojure.lang.Compiler.analyze(Compiler.java:6406)
[INFO] 	at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3665)
[INFO] 	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
[INFO] 	at clojure.lang.Compiler.analyze(Compiler.java:6445)
[INFO] 	at clojure.lang.Compiler.analyze(Compiler.java:6406)
[INFO] 	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
[INFO] 	at clojure.lang.Compiler$TryExpr$Parser.parse(Compiler.java:2191)
[INFO] 	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
[INFO] 	at clojure.lang.Compiler.analyze(Compiler.java:6445)
[INFO] 	at clojure.lang.Compiler.analyze(Compiler.java:6406)
[INFO] 	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
[INFO] 	at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5217)
[INFO] 	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3846)
[INFO] 	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
[INFO] 	at clojure.lang.Compiler.analyze(Compiler.java:6445)
[INFO] 	at clojure.lang.Compiler.eval(Compiler.java:6700)
[INFO] 	at clojure.lang.Compiler.load(Compiler.java:7130)
[INFO] 	at clojure.lang.RT.loadResourceScript(RT.java:370)
[INFO] 	at clojure.lang.RT.loadResourceScript(RT.java:361)
[INFO] 	at clojure.lang.RT.load(RT.java:440)
[INFO] 	at clojure.lang.RT.load(RT.java:411)
[INFO] 	at clojure.core$load$fn__5066.invoke(core.clj:5641)
[INFO] 	at clojure.core$load.doInvoke(core.clj:5640)
[INFO] 	at clojure.lang.RestFn.invoke(RestFn.java:408)
[INFO] 	at clojure.core$load_one.invoke(core.clj:5446)
[INFO] 	at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
[INFO] 	at clojure.core$load_lib.doInvoke(core.clj:5485)
[INFO] 	at clojure.lang.RestFn.applyTo(RestFn.java:142)
[INFO] 	at clojure.core$apply.invoke(core.clj:626)
[INFO] 	at clojure.core$load_libs.doInvoke(core.clj:5528)
[INFO] 	at clojure.lang.RestFn.applyTo(RestFn.java:137)
[INFO] 	at clojure.core$apply.invoke(core.clj:626)
[INFO] 	at clojure.core$require.doInvoke(core.clj:5607)
[INFO] 	at clojure.lang.RestFn.invoke(RestFn.java:408)
[INFO] 	at clojure.tools.nrepl_test$eval5$loading__4958__auto____6.invoke(nrepl_test.clj:1)
[INFO] 	at clojure.tools.nrepl_test$eval5.invoke(nrepl_test.clj:1)
[INFO] 	at clojure.lang.Compiler.eval(Compiler.java:6703)
[INFO] 	at clojure.lang.Compiler.eval(Compiler.java:6692)
[INFO] 	at clojure.lang.Compiler.load(Compiler.java:7130)
[INFO] 	at clojure.lang.RT.loadResourceScript(RT.java:370)
[INFO] 	at clojure.lang.RT.loadResourceScript(RT.java:361)
[INFO] 	at clojure.lang.RT.load(RT.java:440)
[INFO] 	at clojure.lang.RT.load(RT.java:411)
[INFO] 	at clojure.core$load$fn__5066.invoke(core.clj:5641)
[INFO] 	at clojure.core$load.doInvoke(core.clj:5640)
[INFO] 	at clojure.lang.RestFn.invoke(RestFn.java:408)
[INFO] 	at clojure.core$load_one.invoke(core.clj:5446)
[INFO] 	at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
[INFO] 	at clojure.core$load_lib.doInvoke(core.clj:5485)
[INFO] 	at clojure.lang.RestFn.applyTo(RestFn.java:142)
[INFO] 	at clojure.core$apply.invoke(core.clj:626)
[INFO] 	at clojure.core$load_libs.doInvoke(core.clj:5524)
[INFO] 	at clojure.lang.RestFn.applyTo(RestFn.java:137)
[INFO] 	at clojure.core$apply.invoke(core.clj:626)
[INFO] 	at clojure.core$require.doInvoke(core.clj:5607)
[INFO] 	at clojure.lang.RestFn.invoke(RestFn.java:408)
[INFO] 	at user$eval1.invoke(run-test6023873211541663255.clj:1)
[INFO] 	at clojure.lang.Compiler.eval(Compiler.java:6703)
[INFO] 	at clojure.lang.Compiler.load(Compiler.java:7130)
[INFO] 	at clojure.lang.Compiler.loadFile(Compiler.java:7086)
[INFO] 	at clojure.main$load_script.invoke(main.clj:274)
[INFO] 	at clojure.main$script_opt.invoke(main.clj:336)
[INFO] 	at clojure.main$main.doInvoke(main.clj:420)
[INFO] 	at clojure.lang.RestFn.invoke(RestFn.java:408)
[INFO] 	at clojure.lang.Var.invoke(Var.java:379)
[INFO] 	at clojure.lang.AFn.applyToHelper(AFn.java:154)
[INFO] 	at clojure.lang.Var.applyTo(Var.java:700)
[INFO] 	at clojure.main.main(main.java:37)
[INFO] Caused by: java.lang.RuntimeException: Unable to resolve var: clojure.pprint/use-method in this context
[INFO] 	at clojure.lang.Util.runtimeException(Util.java:221)
[INFO] 	at clojure.lang.Compiler$TheVarExpr$Parser.parse(Compiler.java:659)
[INFO] 	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
[INFO] 	... 69 more

This is for the version

  • clojure-1.3.0
  • clojure-1.4.0
  • clojure-1.5.0
  • clojure-1.6


 Comments   
Comment by Alf Kristian Støyle [ 04/Aug/14 1:13 PM ]

Seems the require functions is "not called correctly" when inside the try special form. Moving it to top level, or into the ns declaration resolves the issue. Attached a patch.

Comment by Chas Emerick [ 19/Aug/14 12:36 PM ]

Yeah, whoops. I think I did that thinking I was still trying to maintain Clojure 1.1 compatibility. Thanks for the patch, but I had already fixed it locally.





Generated at Wed Aug 20 19:27:43 CDT 2014 using JIRA 4.4#649-r158309.