clojure-emacs / orchard Goto Github PK

Currently the eldoc type is either function or variable:

(defn- extract-eldoc
  [info]
  (if-let [arglists (seq (-> info extract-arglists format-arglists))]
    {:eldoc arglists :type "function"}
    {:type "variable"}))

This means that the result users see is not particularly accurate, not to mention that the function check is pretty primitive. We should add types like macro, special-form, etc.

Basically we need to setup Travis in a similar way we've set it up for cider-nrepl, but without cljs support at this point. This includes things like code coderage, some linting, etc.

Perhaps our resident expert @gonewest818 would be interested in helping out with that?

When using the latest cider-nrepl with the latest Orchard, and after recompiling namespaces with tools.namespace, pressing M-. on a function name from one of the recompiled namespaces jumps not to the actual file, but to the "temporary" cache file that Boot creates in ~/.boot/tmp/....

Looks like the commit that broke it is b83826f

A bit more context:

Long story short:

• We don't support the latest version of dynapath (1.0)
• The version we're using (0.2.5) is going to stop working with Java 10, as it relied on implementation details that are going to be changed

We need to come up with some solution for this soon, otherwise it's going to cause problems for many people.

More details here clojure-emacs/cider-nrepl#482

Summary

Middleware is loaded in a different classloader context than user interactions with that middleware. The latter shares no modifiable classloader parent with the former, so changes made to the classpath when middleware is loaded are not seen by user interactions.

Impact

The primary example of this is in java.clj, which adds the JDK src.zip to the classpath and sets the jdk-sources variable to the zip file's path if found. In-editor JDK class/method docstrings (and argument names, etc) depends on this feature, as does source navigation (jumping) for JDK classes.

The following issues appear to describe this bug:

• clojure-emacs/cider#2732
• clojure-emacs/cider#2687
• clojure-emacs/cider-nrepl#687

Scope

This behavior happens on both JDK8 and 9+. dynapath formerly hacked java.net.URLClassLoader to allow it to be modifiable on JDK8 and below, which would have prevented this issue on JDK8 (albeit in an unsupported way), but recent versions of dynapath removed this hack, so all JDK versions behave the same wrt this issue.

Investigation

Below are the values of jdk-sources, the classpath, and the classloader hierarchy at middleware load time (via print statements in the java middleware), and at runtime in a user REPL session. Note that:

1. Both contexts reflect that src.zip has been found (jdk-sources is set); however
2. src.zip is visible on the classpath at load time, but not at runtime in the REPL session, because
3. there is no shared DynamicClassLoader in their respective classloader hierarchies. The lowest common ancestor of the context classloader for these contexts is an AppClassLoader, which is not modifiable. Hence, any modification to the highest modifiable classloader in the first context is not visible in the second.

At load time:

;; jdk-sources
#object[java.net.URL 0x2199cb1b file:/usr/lib/jvm/java-11-openjdk/lib/src.zip]

;; classpath
(;; ...all identical to below, except this entry is present:
 #object[java.net.URL 0x2199cb1b "file:/usr/lib/jvm/java-11-openjdk/lib/src.zip"])

;; classloaders
(#object[clojure.lang.DynamicClassLoader 0x6d6bc158 "clojure.lang.DynamicClassLoader@6d6bc158"]
 #object[jdk.internal.loader.ClassLoaders$AppClassLoader 0x277050dc "jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc"]
 #object[jdk.internal.loader.ClassLoaders$PlatformClassLoader 0x5825f15a "jdk.internal.loader.ClassLoaders$PlatformClassLoader@5825f15a"])

And at runtime, via the REPL:

;; jdk-sources
#object[java.net.URL 0x2199cb1b file:/usr/lib/jvm/java-11-openjdk/lib/src.zip]

;; classpath
(;; ...all identical to above, but missing the added src.zip classpath entry
)

;; classloaders
(#object[clojure.lang.DynamicClassLoader 0x8424570 "clojure.lang.DynamicClassLoader@8424570"]
 #object[clojure.lang.DynamicClassLoader 0x69433f24 "clojure.lang.DynamicClassLoader@69433f24"]
 #object[clojure.lang.DynamicClassLoader 0x48d3a104 "clojure.lang.DynamicClassLoader@48d3a104"]
 #object[clojure.lang.DynamicClassLoader 0x5367dcfe "clojure.lang.DynamicClassLoader@5367dcfe"]
 #object[jdk.internal.loader.ClassLoaders$AppClassLoader 0x277050dc "jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc"]
 #object[jdk.internal.loader.ClassLoaders$PlatformClassLoader 0x5825f15a "jdk.internal.loader.ClassLoaders$PlatformClassLoader@5825f15a"])

Analysis

This may be as much an nREPL discussion as an orchard one. I suspect it may have to do with *bindings* (including the clojure.lang.Compiler/LOADER) being stored and passed as the :session for nREPL messages -- essentially that these contexts are intentionally separated.

If so, testing for correct behavior requires both contexts. It can't be tested purely within a CIDER/nREPL session (as one would do in development), nor would our current approach to unit tests catch any breakage.

At a high level, there seem to be two ways to make this behave as intended:

1. Propagate changes to the classpath made at load time into each new nREPL session (likely by pushing the classloader or a descendant classloader into the session); or
2. Change the logic in orchard such that each nREPL session makes its own changes to the classpath.

@bbatsov What do you think of this?

Cognitect recently released a new version of REBL that has a find usages feature. @SevereOverfl0w asked Rich about the implementation and Rich was kind enough to share the crux of it:

(defn fdeps [val]
    (set (some->> val class .getDeclaredFields
                  (keep (fn [^java.lang.reflect.Field f]
                          (or (and (identical? clojure.lang.Var (.getType f))
                                   (java.lang.reflect.Modifier/isPublic (.getModifiers f))
                                   (java.lang.reflect.Modifier/isStatic (.getModifiers f))
                                   (-> f .getName (.startsWith "const__"))                                  
                                   (.get f val))
                              nil))))))

Some notes from Rich:

It reflects against the fn classes themselves, every closure put fields in for vars,
that’s what makes vars fast.
So these are ‘runtime’ deps, not source deps. You won’t see inlined fns or macros.
fdeps works on the fn value, not the var.

So people have already been building cool things with that idea https://gist.github.com/vlaaad/0350b61e127e82165d195b490999ec0a

So, what we need to do now is add this to Orchard and then wrap it in CIDER nREPL. That should be pretty easy and have a huge impact for the end users.

A couple of people have experienced problems trying to use cider-nrepl when not connected to the internet or behind a corporate firewall, because the download of the ClojureDocs export locks up. We should figure out some solution to this. Some options:

• Do the download in the background
• Try to detect if we have access to the remote host
• Ship some fallback data with orchard

@liquidz Any thoughts on this?

With JDK15, the Standard Doclet no longer generates pre-compressed index files.

This line generates a NPE with JDK15.

java.lang.NullPointerException: Cannot invoke "jdk.javadoc.internal.doclets.formats.html.HtmlConfiguration.getOptions()" because "this.configuration" is null
        at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.getSupportedOptions(HtmlDoclet.java:292)
        at jdk.javadoc/jdk.javadoc.doclet.StandardDoclet.getSupportedOptions(StandardDoclet.java:93)
        at cider.nrepl.inlined_deps.orchard.v0v6v0.orchard.java.parser$parse_java$reify__12158.getSupportedOptions(parser.clj:77) 

Hello there. I like volunteering to help open source projects. I'm a graphic designer. I want to design a logo for the readme file. Dou you like?. I will make a gift.

I guess we should help people figure out how to use our library.

@gonewest818 Can you help with this?

Expected behavior

shadow-cljs watch my-project runs without warnings.

Actual behavior

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval8306$fn__8307 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval8306$fn__8307
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Steps to reproduce the problem

The easiest way to reproduce the bug is:

• install shadow-cljs
• clone my repository here
• run shadow-cljs watch boodle

Environment & Version information

Clojure version

1.10.0

Java version

openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment (build 11.0.1+13-Ubuntu-3ubuntu118.04ppa1)
OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-3ubuntu118.04ppa1, mixed mode, sharing)

Operating system

Ubuntu 18.04

Note

I reported this here because I saw orchard in the messages. Feel free to close the issue (and/or tell me where to open it instead) if I'm in the wrong place.

A library like Orchard should have zero runtime deps, as people would normally be using it alongside their running app and dependency conflicts would be likely.

Here it doesn't make sense to employ dependency rewriting, as we've done in cider-nrepl, and given the simplicity of our usage of java.classpath it be best if we simply reimplemented whatever functionality we need from it in a namespace like orchard.java.classpath or something like this.

The updated Java parser (added in 33f0791) works with JDK9+, but currently only supports non-modular sources. Practically speaking, it can parse everything except the Java 9+ platform sources in src.zip -- but this is primary use case.

The machinery for parsing modular sources is in place. The issue is the new access policies enforced for modules. Need to figure out how to have the compiler read these without throwing up.

You get a NPE on the call to inlined-dependency?. This is because load-project-ns returns namespaces that have failed to load, so find-ns is unable to find it.

If we can determine the correct behavior, this would make a good first issue.

I noticed a potential typo in the README. Or maybe I'm not reading the intent correctly.

Presently it reads:

API Optimized for Editors

Code editors can't know what symbols resolve to without consulting a REPL that's why they would typically send a combination of a symbol name and some ns (e.g. the current namespace), so they can't be resolved to some var on which an operation would be invoked.

But I expected to read can instead of can't. The suspect word is bolded above and below:

API Optimized for Editors

Code editors can't know what symbols resolve to without consulting a REPL that's why they would typically send a combination of a symbol name and some ns (e.g. the current namespace), so they can be resolved to some var on which an operation would be invoked.

I've noticed that from time to time we get the following test failure https://app.circleci.com/pipelines/github/clojure-emacs/orchard/248/workflows/bcb49435-2c56-44f3-ad19-78d3bde2715b/jobs/2124

I guess we should investigate this at some point.

In newer JDKs (I am using 13), you can add the following to enable warnings around illegal reflection in project.clj:

:jvm-opts ["--illegal-access=warn"]

On make test this will be reported:

WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.value
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.value
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.value
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.value
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.value
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.value
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.value
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Number.serialVersionUID
WARNING: Illegal reflective access by orchard.inspect$eval3198$fn__3199$field_val__3209$fn__3210 to field java.lang.Long.serialVersionUID

I don't think I understand enough about the code base and the warning at the moment but this should probably be somehow addressed at some point.

Expected behavior

lein repl will launch.

Actual behavior

ERROR: Unhandled REPL handler exception processing message {:code (clojure.core/binding [clojure.core/*ns* (clojure.core/or (clojure.core/find-ns (clojure.core/symbol "reply.eval-mode
s.nrepl")) clojure.core/*ns*)] (set! *print-length* nil)), :id d9e84203-70ce-4144-8d6c-8c8aa8994446, :op eval, :session 71e6dc37-2c17-48a9-b70e-b42454c30d3d}
Syntax error compiling at (cider/nrepl/inlined_deps/orchard/v0v6v0/orchard/java/legacy_parser.clj:1:1).

Full error messages are here
https://gist.github.com/liquidz/6c2da4394b3a238947ad493c604e0d7a

Steps to reproduce the problem

• create project

docker run --rm -it clojure:openjdk-8-lein bash
lein new foo
cd foo

• edit project.clj

(defproject foo "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
            :url "https://www.eclipse.org/legal/epl-2.0/"}
  :dependencies [[org.clojure/clojure "1.10.1"]
                 [nrepl "0.8.0"]]
  :plugins [[cider/cider-nrepl "0.25.3"]]
  :repl-options {:init-ns foo.core})

• run lein repl

Environment & Version information

Clojure version

• 1.10.1

Java version

• 1.8

Operating system

• Debian (Docker image: clojure:openjdk-8-lein)
• macOS Catalina

See clojure-emacs/cider-nrepl#495 for details.

Same issues in this project.

Related to #71

Expected behavior

CIDER stacktraces should return relatively quickly even when ClojureDocs cache is missing and all internet traffic is set to time out.

Actual behavior

CIDER stacktrace takes 1 second per special form due to the 1-second timeout being repeated for every call to see-also attempting to load the cache file.

Steps to reproduce the problem

Set all internet traffic to drop.

If using a VPN, look for a killswitch setting or ability to stop all traffic when not connected and then disconnect from VPN. (Some VPNs with killswitches: https://www.vpnmentor.com/blog/kill-switch-features/)

If using iptables:

# NOTE: this will drop all internet traffic. To re-enable, use ACCEPT in place of DROP
sudo iptables -F
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT DROP
sudo iptables -P FORWARD DROP

Delete orchard subdirectory from the cache directory (as specified in https://github.com/clojure-emacs/orchard/blob/master/src/orchard/util/os.clj#L58).

Open a CIDER nREPL in any Clojure project and execute code that spawns an error. This was tested in Emacs with the current version of cider.

;; Error shows immediately in REPL window, but took ~15 seconds to show error buffer in Emacs
(/ 1 0)

Environment & Version information

Orchard 0.5.7, Cider 20200308.1030

Clojure version

Tested with 1.10.1

Java version

Tested with Java 8 and 11

Operating system

Tested on Linux and MacOS

Expected behavior

When calling orchard.info/info on a Java member or non-existent fully qualified symbol, the unqualified symbol should not be used to resolve a var in the current namespace.

(orchard.info/info 'user 'Integer/max)
(orchard.info/info 'user 'non-existing-ns/get)

should return the info for the Integer.max Java static member and nil respectively.

Actual behavior

Instead the unqualified symbols max and get are resolved to the clojure.core functions and produces an incorrect info response.

I traced it to this line in clj-meta:

Even though sym is fully qualified, the processing step normalise-params added the key :unqualified-sym. I don't know enough to say if it's a predecence issue or if there should be an additional condition to not resolve unqualified-sym if the sym is fully qualified.

Steps to reproduce the problem

In Emacs, call cider-doc on the symbol Integer/max or observe the eldoc which displays the wrong arglists for clojure.core/max.

Environment & Version information

Clojure version

E.g. 1.10.2

Java version

E.g. 1.11

Operating system

macOS 10.15

Basically we need to obfuscate orchard's deps, so they wouldn't conflict with the deps of projects that are using it (we can't obfuscate only dynapath).

It'd be nice if we can do this obfuscation automatically on TravisCI. //cc @gonewest818

Hi there I am putting this here as reminder and ask for help 😄

Expected behavior

I expected make test-watch which is basically just an alias for test-refresh would work. I found it very useful for the info tests but we might want to delete it if we cannot find a solution.

Actual behavior

It does not work and the workaround seems to completely comment out the namespace together with this line.

My guess is that test-refresh always tries to load orchard.java.legacy-parser which is dynamically loaded otherwise and depends on the JDK. Not too sure if there is another fix cause I haven't paid too much attention to the JDK doc PRs 😄

Steps to reproduce the problem

make test-watch

Environment & Version information

Clojure version

any

Java version

• Not too sure, I haven't had the time to try it -

Mostly a matter of figuring out what image to use for the build as it seems there's no openjdk-15-lein-2.9.1.

That's related to #100.

Just reporting here what has been discovered in clojure-emacs/cider-nrepl#621 for traceability.

From @xificurC's comment:

I see I forgot that info* calls clj-meta which calls into various orchard.meta functions depending on the supplied map. I recall I had crashes yesterday when my cursor was on finally:

cider.nrepl.inlined-deps.orchard.v0v5v0-beta8.orchard.info> (clj-meta {:dialect :clj :ns 'clojure.core :sym 'finally})
{:forms [(try expr* catch-clause* finally-clause?)],
 :doc
 "catch-clause => (catch classname name expr*)\n  finally-clause => (finally expr*)\n\n  Catches and handles Java exceptions.",
 :name finally,
 :special-form true,
 :url "https://clojure.org/special_forms#finally"}

There's no :file there. Based on this observation I would say the (update :file code is incorrect and should be checked whether :file is actually not nil.

Thanks to him now we have an easy fix, plus I will add a test 😄

Expected behavior

No exception gets thrown and the export.edn from clojuredocs gets used when avialable.

Actual behavior

When something like info should be evaluated bä the nrepl i get the exception:
java.io.FileNotFoundException: ?C:\Users\KStehn\AppData\Local\orchard\clojuredocs\export.edn (Syntax for filname, directoryname or volume label is wrong)

Steps to reproduce the problem

For this iam not entirely sure sadly.
Just using cider-nrepl inside of calva to get info about a symbol.

Environment & Version information

• VSCode 1.38.1
• cider-nrepl 0.22.3
• Calva v2.0.40-release-candidate-3

Clojure version

v2.0.40-release-candidate-3

Java version

OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.1+12)

Operating system

Windows 7

Hello, I'm trying to use the cider-xref-fn-refs function to scan for uses of a function, and getting the error below.

There is indeed no "basis" namespace (but there are a number sub-namespaces inside it). I do use namespaced keys in various places like ":basis/version", etc, so wondering if this might be the source of the error.

I'm happy to try to debug this further, if you can point me in the right direction.

Cheers,

Matt.

;; CIDER 0.23.0 (Lima), nREPL 0.6.0
;; Clojure 1.10.0, Java 12.0.1

1. Unhandled java.lang.IllegalArgumentException
   No such namespace: basis

                  Var.java:  146  clojure.lang.Var/find
                  core.clj: 2020  clojure.core/find-var
                  core.clj: 2015  clojure.core/find-var
                  xref.clj:   13  cider.nrepl.inlined-deps.orchard.v0v5v0.orchard.xref/as-val
                  xref.clj:    8  cider.nrepl.inlined-deps.orchard.v0v5v0.orchard.xref/as-val
                  xref.clj:   21  cider.nrepl.inlined-deps.orchard.v0v5v0.orchard.xref/fn-deps
                  xref.clj:   16  cider.nrepl.inlined-deps.orchard.v0v5v0.orchard.xref/fn-deps
                  core.clj: 2755  clojure.core/map/fn
              LazySeq.java:   42  clojure.lang.LazySeq/sval
              LazySeq.java:   51  clojure.lang.LazySeq/seq
                 Cons.java:   39  clojure.lang.Cons/next
                   RT.java:  709  clojure.lang.RT/next
                  core.clj:   64  clojure.core/next
                  core.clj: 3079  clojure.core/zipmap
                  core.clj: 3071  clojure.core/zipmap
                  xref.clj:   52  cider.nrepl.inlined-deps.orchard.v0v5v0.orchard.xref/fn-refs
                  xref.clj:   44  cider.nrepl.inlined-deps.orchard.v0v5v0.orchard.xref/fn-refs
                  xref.clj:   22  cider.nrepl.middleware.xref/fn-refs-reply
                  xref.clj:   20  cider.nrepl.middleware.xref/fn-refs-reply
        error_handling.clj:  160  cider.nrepl.middleware.util.error-handling/eval6545/fn
              MultiFn.java:  234  clojure.lang.MultiFn/invoke
                  xref.clj:   29  cider.nrepl.middleware.xref/handle-xref
                  xref.clj:   28  cider.nrepl.middleware.xref/handle-xref
                  Var.java:  388  clojure.lang.Var/invoke
                 nrepl.clj:  466  cider.nrepl/wrap-xref/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:  299  cider.nrepl/wrap-profile/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:  243  cider.nrepl/wrap-macroexpand/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
    interruptible_eval.clj:  144  nrepl.middleware.interruptible-eval/interruptible-eval/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
               session.clj:  326  nrepl.middleware.session/add-stdin/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
             load_file.clj:   81  nrepl.middleware.load-file/wrap-load-file/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:  199  cider.nrepl/wrap-inspect/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                caught.clj:   97  nrepl.middleware.caught/wrap-caught/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:  437  cider.nrepl/wrap-tracker/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:  136  cider.nrepl/wrap-debug/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:  162  cider.nrepl/wrap-enlighten/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:   82  cider.nrepl/wrap-content-type/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 print.clj:  234  nrepl.middleware.print/wrap-print/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                 nrepl.clj:  290  cider.nrepl/wrap-out/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
               session.clj:  272  nrepl.middleware.session/session/fn
            middleware.clj:   16  nrepl.middleware/wrap-conj-descriptor/fn
                server.clj:   18  nrepl.server/handle*
                server.clj:   15  nrepl.server/handle*
                server.clj:   27  nrepl.server/handle/fn
                  core.clj: 2030  clojure.core/binding-conveyor-fn/fn
                  AFn.java:   18  clojure.lang.AFn/call
           FutureTask.java:  264  java.util.concurrent.FutureTask/run
   ThreadPoolExecutor.java: 1128  java.util.concurrent.ThreadPoolExecutor/runWorker
   ThreadPoolExecutor.java:  628  java.util.concurrent.ThreadPoolExecutor$Worker/run
               Thread.java:  835  java.lang.Thread/run

A library like Orchard should have zero runtime deps, as people would normally be using it alongside their running app and dependency conflicts would be likely.

Here it doesn't make sense to employ dependency rewriting, as we've done in cider-nrepl, and given the simplicity of our usage of tools.namespace it be best if we simply reimplemented whatever functionality we need from it in a namespace like orchard.namespace or something like this.

Expected behavior

No warning.

Actual behavior

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval3309$fn__3310 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval3309$fn__3310
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Steps to reproduce the problem

It is actually part of the tests in cljs-tooling but I know I should produce a minimal repro repo.

At the moment the only repro I have is to:

git clone https://github.com/clojure-emacs/cljs-tooling.git
cd cljs-tooling
./scripts/test-lumo

Expected behavior

Can show java class method doc in Emacs buffer
Can jump to java class method doc in browser

Actual behavior

cider-doc emacs buffer shows

Not documented.

For additional documentation, see the Javadoc.

Definition location unavailable.

Click Javadoc link or use "C-c C-d j" only opens class doc in browser but doesn't jump to the method.

Steps to reproduce the problem

"C-c C-d d" then type ".toUpperCase"
or
"C-c C-d j" then type ".toUpperCase"

Environment & Version information

;; CIDER 0.18.1snapshot (package: 20180929.818), nREPL 0.4.5

Clojure version

1.9.0

Java version

OpenJDK 10

If I run with openjdk9 then browser can directly jump to method. Apparently the URLs are slightly different in Java10 (java9 doc uses - as separator but 10 uses '()')

cider-doc doesn't work even in openjdk9

Operating system

Windows 10 x64

Hello folks! 😸

Expected behavior

No errors.

Actual behavior

                      (.setSilent true)
                      (set-field! "showAccess" access))
           source   (proxy [SimpleJavaFileObject]
-                       [(URI. path) JavaFileObject$Kind/SOURCE]
+                          [(URI. path) JavaFileObject$Kind/SOURCE]
                      (getCharContent [_] (slurp res)))
           tree     (.parse compiler source)
           classes  (->> (.defs tree)
src/orchard/java/parser.clj has incorrect formatting
--- a/src/orchard/java/parser.clj
+++ b/src/orchard/java/parser.clj
@@ -52,7 +52,7 @@
   (when-let [res (io/resource path)]
     (let [compiler (ToolProvider/getSystemDocumentationTool)
           source   (proxy [SimpleJavaFileObject]
-                       [(URI. path) JavaFileObject$Kind/SOURCE]
+                          [(URI. path) JavaFileObject$Kind/SOURCE]
                      (getCharContent [_] (slurp res)))

After rebasing my patch on master, CI is failing with the above. Is this a fix that should go to master?

Unsure about the fix here because my emacs indents the same as the current code...

Expected behavior

REPL starts with Orchard 0.5.9 and Clojure 1.9.0 normally.

Actual behavior

Exception in thread "main" java.lang.ExceptionInInitializerError
        at clojure.main.<clinit>(main.java:20)
Caused by: java.lang.RuntimeException: Unable to find static field: REQUIRE_LOCK in class clojure.lang.RT, compiling:(clojure/core.clj:6079:3)
        at clojure.lang.Compiler.analyze(Compiler.java:6792)
        at clojure.lang.Compiler.access$300(Compiler.java:38)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6368)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003)
        at clojure.lang.Compiler.analyze(Compiler.java:6773)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6991)
        at clojure.lang.Compiler.analyze(Compiler.java:6773)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6991)
        at clojure.lang.Compiler.analyze(Compiler.java:6773)
        at clojure.lang.Compiler.analyze(Compiler.java:6729)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6100)
        at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5460)
        at clojure.lang.Compiler$FnExpr.parse(Compiler.java:4022)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:7001)
        at clojure.lang.Compiler.analyze(Compiler.java:6773)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6991)
        at clojure.lang.Compiler.analyze(Compiler.java:6773)
        at clojure.lang.Compiler.access$300(Compiler.java:38)
        at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:595)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003)
        at clojure.lang.Compiler.analyze(Compiler.java:6773)
        at clojure.lang.Compiler.analyze(Compiler.java:6729)
        at clojure.lang.Compiler.eval(Compiler.java:7066)
        at clojure.lang.Compiler.load(Compiler.java:7514)
        at clojure.lang.RT.loadResourceScript(RT.java:379)
        at clojure.lang.RT.loadResourceScript(RT.java:370)
        at clojure.lang.RT.load(RT.java:460)
        at clojure.lang.RT.load(RT.java:426)
        at clojure.lang.RT.doInit(RT.java:468)
        at clojure.lang.RT.<clinit>(RT.java:336)
        ... 1 more
Caused by: java.lang.RuntimeException: Unable to find static field: REQUIRE_LOCK in class clojure.lang.RT
        at clojure.lang.Util.runtimeException(Util.java:221)
        at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7196)
        at clojure.lang.Compiler.analyze(Compiler.java:6752)
        ... 30 more
Subprocess failed (exit code: 1)

Steps to reproduce the problem

• lein new foo
• cd foo
• Edit project.clj like below

(defproject foo "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
            :url "https://www.eclipse.org/legal/epl-2.0/"}
  :dependencies [[org.clojure/clojure "1.9.0"]
                 [cider/orchard "0.5.9"]]
  :repl-options {:init-ns foo.core})

• lein repl

Environment & Version information

Clojure version

1.9.0

Java version

1.8

Operating system

macOS Catalina

see-also.edn is an export from clojuredocs.org and we need to regenerate it from time to time. The steps to export it are described here and should be put in some lein task that we run around new releases.

Currently, the cloverage job is skipped on CircleCI, as it's been failing for the last while. The thinking is that let's rather be used to the build going green, as to avoid a broken window effect.

However, we should probably either fix that job, or abandon the capability (too much effort for not enough gain).

(Feature request)

It would be good to have a way of viewing and navigating to all the methods for a multimethod.

Two things I've seen before (in LispWorks for Common Lisp) are:

• After M-. shows a multimethod, another command can be invoked repeatedly to navigate to each of the methods.
• Something that lists all the methods for a multimethod and supports navigation to a chosen method (perhaps a sequence to cycle through in the minibuffer, perhaps an "inspector" buffer) .

Expected behavior

(throw (ex-info "Help!" {}) should be handled by cider and show cider-error

Actual behavior

Execution error (ExceptionInfo) at user/eval9510 (REPL:1265).
Helo!
ERROR: Unhandled REPL handler exception processing message {:nrepl.middleware.print/stream? 1, :nrepl.middleware.print/print cider.nrepl.pprint/pprint, :nrepl.middleware.print/quota 1048576, :nrepl.middleware.print/buffer-size 4096, :nrepl.middleware.print/options {:right-margin 70}, :op stacktrace, :session a739d2ab-eec5-42ae-8e35-01b1ea428624, :id 234}
java.lang.ClassNotFoundException: com.sun.tools.javac.util.List
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:69)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at clojure.lang.DynamicClassLoader.loadClass(DynamicClassLoader.java:77)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at clojure.lang.RT.classForName(RT.java:2211)
at clojure.lang.RT.classForName(RT.java:2220)
at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java.legacy_parser$parse_java.invokeStatic(legacy_parser.clj:88)
at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java.legacy_parser$parse_java.invoke(legacy_parser.clj:66)

Steps to reproduce the problem

1. Set up a new tools.deps project.
2. Throw an error

Environment & Version information

Clojure version

1.10.1

Java version

java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_275-b01)

Operating system

Mac OS X 10.15.7

Emacs version

GNU Emacs 27.1 (build 1, x86_64-apple-darwin19.6.0, Carbon Version 162 AppKit 1894.6) of 2021-02-02

Notes

The class it's looking for is in tools.jar, which is in $JAVA_HOME/lib.

To run all tests, the CI Docker image needs to include:

1. src.zip for all JDKs; and
2. tools.jar for JDK8.

Both of these should be located either in the JDK root, or in the lib directory under this.

If I have a file foo.clj without any defs in it. For instance if it has only this content

(ns foo)

And then ask for info on it. I get no :file path in the response.

But if I have this:

(ns foo)

(def foo 42)

Then I get the :file path for this file in the response.

Steps to reproduce the problem

I'm not sure how to reproduce this in any other way than creating the files in a Clojure project:

foo.clj with contents:

(ns foo)

bar.clj with contents

(ns bar
  (:require foo))

Then I load bar.clj and use my favorite nREPL tool, Calva, to peek at the definion of foo (alt+F12). Calva shows an info hover saying ”No definition found for foo”.

Then If I add (def foo 42) to foo.clj, I can peek at the definition from bar.clj.

Environment & Version information

Clojure version

1.10.0

Java version

1.12

Operating system

MacOS Mojave

Splitting out this request from the discussion in #2:

I was wondering if you know how to setup some auto-publishing of snapshots to Travis. I find it very annoying that I manually have to push each update. Probably the only real problem is how to stuff some credentials securely in the build step. Would be nice for both orchard and cider-nrepl if possible and would get rid of the common problem of forgetting to push some new snapshot release.

Run now we've hardcoded the dep, which is bad for end users. It should go to all profiles the way we've done for other projects (e.g. https://github.com/clojure-emacs/cider-nrepl/blob/master/project.clj).

@arichiardi The current code will work with older ClojureScript releases, right?

The latest (and some older versions) of the documentation is now showing - it's just showing API import failed in build #28834, and it points to https://cljdoc.org/builds/28834

Is it something easy to fix? Or is there any way to build the documentation locally, so we can explore the API?

Expected behavior

(ns foo.core
  (:require clojure.string
            [orchard.info :as info]))

(defn -main []
  (clojure.pprint/pprint
   (info/info 'foo.core 'clojure.string/replace)))

The above code should print clojure.string/replace information.

Actual behavior

0.5.0-beta3:

{:ns #object[clojure.lang.Namespace 0x5fef2aac "clojure.string"],
 :name replace,
 :doc
 "Replaces all instance of match with replacement in s.\n\n   match/replacement can be:\n\n   string / string\n   char / char\n   pattern / (string or function of match).\n\n   See also replace-first.\n\n   The replacement is literal (i.e. none of its characters are treated\n   specially) for all cases above except pattern / string.\n\n   For pattern / string, $1, $2, etc. in the replacement string are\n
  substituted with the string that matched the corresponding\n   parenthesized group in the pattern.  If you wish your replacement\n   string r to be used literally, use (re-quote-replacement r) as the\n
  replacement argument.  See also documentation for\n   java.util.regex.Matcher's appendReplacement method.\n\n   Example:\n   (clojure.string/replace \"Almost Pig Latin\" #\"\\b(\\w)(\\w+)\\b\" \"$2$1ay\")\n   -> \"lmostAay igPay atinLay\"",
 :file "clojure/string.clj",
 :arglists ([s match replacement]),
 :line 75,
 :column 1,
 :added "1.2"}

0.5.0-beta4:

{:added "1.0",
 :ns clojure.core,
 :name replace,
 :file "clojure/core.clj",
 :static true,
 :column 1,
 :line 5058,
 :arglists ([smap] [smap coll]),
 :see-also
 (clojure.walk/prewalk-replace
  clojure.walk/postwalk-replace
  clojure.core/map
  clojure.string/replace),
 :doc
 "Given a map of replacement pairs and a vector/collection, returns a\n  vector/seq with any elements = a key in smap replaced with the\n  corresponding val in smap.  Returns a transducer when no collection\n  is provided."}

Steps to reproduce the problem

Run the above code.

project.clj is here.

(defproject foo "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
            :url "https://www.eclipse.org/legal/epl-2.0/"}
  :dependencies [[org.clojure/clojure "1.10.0"]
                 [cider/orchard
                  ;; "0.5.0-beta3"
                  "0.5.0-beta4"]]
  :repl-options {:init-ns foo.core}
  :main foo.core)

Environment & Version information

0.5.0-beta3 and beta4

Clojure version

1.10.0

Java version

openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

Operating system

macOS High Sierra

Hi,

I'm curious if the intent of the class-info function was to work with 3rd party java libraries or not?

It works tremendously for java classes however I tried executing class-info on a class from libgdx and although it was able to find the class' members etc. it wasn't able to load the source or javadoc data despite having the the sources and javadoc jars on the classpath for libgdx.

EDIT: It seems there were multiple source jars I needed to include in my project, all working fine now :)

Hi!
Is any plans to use ztellman/riddley for macro expansion and debugging?

Related to

• clojure-emacs/cider#1775
• clojure-emacs/cider-nrepl#372

Use the template below when reporting bugs. Please, make sure that
you're running the latest stable release or the latest snapshot of
orchard and that the problem you're reporting hasn't been
reported (and potentially fixed) already.

Expected behavior

When doing cider-javadoc on a Kafka method, it should go to the right API version.

Actual behavior

At the moment it goes to https://kafka.apache.org/090/javadoc/index.html which gives a 404.

It's easy to see why, from these lines in master:

;; TODO: Seems those were hardcoded here accidentally - we should
;; probably provide a simple API to register remote JavaDocs.
(javadoc/add-remote-javadoc "com.amazonaws." "http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/")
(javadoc/add-remote-javadoc "org.apache.kafka." "https://kafka.apache.org/090/javadoc/index.html?")

Would be great to jump to the right API version, but if that's too hard we could maybe update it to the latest stable API?

The feature-request has been posted on "cider"

clojure-emacs/cider#1969

Creating an issue here to send a pull request and start a discussion about the solution.

Expected behavior

Successfully loading the orchard.java namespace.

Actual behavior

Fails to load the namespace (and which causes cider-jack-in to crash).

Steps to reproduce the problem

$ clj -Srepro -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.1"} cider/orchard {:mvn/version "0.5.0-beta6"}}}' -e "(require 'orchard.java)"                                                                                                                              [~/private/jise]
Execution error (IllegalArgumentException) at orchard.java/fn (java.clj:65).
No matching field found: getJarFileURL for class sun.net.www.protocol.jrt.JavaRuntimeURLConnection

Full report at:
/var/folders/mr/bf82sldd78g9822yxqgzd12h0000gn/T/clojure-1254707421438656643.edn
$

The same thing happens with 0.5.0-beta4 and beta5 as well.

The following is the line that the error message is pointing to:

(or (some-> (io/resource "com/sun/javadoc/Doc.class")
            (.. openConnection getJarFileURL))
    (some-> (jdk-find "tools.jar") cp/add-classpath!))

And when I dug into those expressions, I saw (.openConnection ...) returning JavaRuntimeURLConnection, which doesn't have .getJarFileURL() method.

=> (.openConnection (io/resource "com/sun/javadoc/Doc.class"))
#object[sun.net.www.protocol.jrt.JavaRuntimeURLConnection 0x2d84cb86 "sun.net.www.protocol.jrt.JavaRuntimeURLConnection:jrt:/jdk.javadoc/com/sun/javadoc/Doc.class"]
=> (.getJarFileURL *1)
Execution error (IllegalArgumentException) at user/eval8 (REPL:1).
No matching field found: getJarFileURL for class sun.net.www.protocol.jrt.JavaRuntimeURLConnection

The above error happens when I try on OpenJDK 11, but NOT on Oracle JDK 1.8.

Environment & Version information

Clojure version

• 1.9.0
• 1.10.0
• 1.10.1

Java version

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

Operating system

macOS Mojave (10.14.5)

Hi all!

I was wondering how to proceed in the case I wanted to use, for instance, spec.clj in the context of ClojureScript code and in general how to enable, possibly port, some code over.

Is orchard going to have a layer targeting each or this is just a lib and how to use it will always need to be handled elsewhere?

Thanks a lot in advance for the answers!

From a comment on Slack, I decided to open an issue so that we can track it.

I just noticed Cider is returning Java member docs and eldoc for unresolved symbols without a period, eg. (shift |) being interpreted as java.lang.StringBuffer/shift

Expected behavior

It should not return an entry.

Actual behavior

It seems it does, will double check.

We should probably add a least a couple of sections regarding the high-level usage of orchard and the goals of the project.