Umgebungs- und Versionsinformationen
CIDER-Versionsinformationen
;; Verbunden mit nREPL-Server - nrepl://localhost :59990
;; CIDER 0.17.0Snapshot (Paket: 20180413.51), nREPL 0.2.13
;; Clojure 1.8.0, Java 9.0.4
Lein/Boot-Version
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.7.2
Emacs-Version
27.0.50
Betriebssystem
Mac OS
Wie Sie sehen, wird das Symbol auch fälschlicherweise für java.lang.Character/toUpperCase anstelle von lang.String aufgelöst.
Sie werden nicht gefragt, welche Version Sie wählen sollen?
@bbatsov Seltsamerweise ist es heute so (was viel besser ist 😂):
Ich habe es überprüft und erhalte die Eingabeaufforderung, wenn ich den Standard-Hotkey verwende (in Spacemacs ist es , h h
im bösen-normalen-Zustand), aber nicht, wenn ich diesen Hotkey verwende, den ich selbst konfiguriert habe:
(key-chord-define-global "fd" '(lambda () (interactive "")
(cond
((or (eq evil-state 'normal) (eq evil-state 'visual)) (execute-kbd-macro (kbd "<escape> , h h")))
((eq evil-state 'insert) (execute-kbd-macro(kbd "<escape> l , h h i"))))))
Dieser Hotkey überspringt irgendwie die Eingabeaufforderung und zeigt nur die Dokumente für das Zeichen an.
Übrigens, der Hinweis von eldoc könnte auch etwas Arbeit gebrauchen, z. B. eine Trennung zwischen den Argumenten der verschiedenen Methoden:
Wir konnten keine gute Trennung herausfinden, deshalb haben wir einfach die Signaturen aller möglichen Versionen gemischt. Es ist ideal, aber leider kann ich auch nicht sehen, wie das verbessert werden kann. Eldoc muss eine ver-String-Struktur haben, sonst würde die Hervorhebung von Parametern dort brechen.
@bbatsov Ich habe gerade meinen Emacs neu gestartet und die Javadocs sind wieder verschwunden. :(
Ich frage mich, ob sich die Dinge für Sie ändern, wenn Sie Java 8 anstelle von 9 ausprobieren. Ich hatte nicht viel Zeit, um mit Java 9 zu spielen, und ich frage mich, ob einige der Klassenpfad-Manipulationen, die wir durchführen, dort nicht richtig funktionieren oder so. Stellen Sie außerdem sicher, dass der Codepuffer ausgewertet wurde, bevor Sie eldoc/cider-doc ausprobieren).
@bbatsov Ich bin auf Java 8
Und ich habe gerade verstanden, dass du die Person bist, die diesen Vortrag hält ^__^ Irgendwie sah dein Avatar auf mich so aggressiv aus und das hat mich irgendwie überrascht :)) Danke für deine Arbeit ;)
Haha!
Und ich dachte, das wäre mein glückliches Gesicht! 😄
Hallo, (Emacs/Cider Anfänger hier)
Wo in der allgemeinen Cider/ROADMAP ist dieser Fehler positioniert?
Ist es mehr
Jedes Mal, wenn ich etwas Zeit damit verbringe, clj/emacs zu lernen, möchte ich am Ende nach einer Klasse suchen und bin frustriert - was ganz bei mir liegt, aber ich frage mich immer wieder:
Ist mein Setup falsch oder kaputt, oder müssen "echte" Clojure-Entwickler nie ein Javadoc nachschlagen - was für mich ziemlich verblüffend wäre.
Mein Testfall soll über cider-doc
java.util.concurrent.PriorityBlockingQueue
suchen, was zu https://imgur.com/a/TaQXfpS führt .
Kurzum: Ist das nur für mich oder für alle kaputt und wie kommen die Leute ohne zurecht?
PPS: Ich habe es mit Java 8 - 11 versucht, wobei java-doc und java-src installiert sind
Ausgänge:
in einer klasse
java.util.concurrent.PriorityBlockingQueue
Extends: java.util.AbstractQueue
Implements: java.util.concurrent.BlockingQueue
java.io.Serializable
Not documented.
For additional documentation, see the Javadoc.
Definition location unavailable.
auf eine Methode
java.util.concurrent.PriorityBlockingQueue/add
[this java.lang.Object]
Not documented.
For additional documentation, see the Javadoc.
Definition location unavailable.
Fortschritt !
Ich denke folgendes passiert
Prämisse: Ich verwende spacemacs, das Cider von MELPA verwendet, derzeit 0.20.0 + Cider-nrepl 0.20.0
Apfelwein-nrepl 0.20.0 verwendet Obstgarten 0.3.1
Problem:
orchard erkennt Java-Quellen mittels jdk-sources
-> jdk-resource-url
und kritisch -> jdk-root
(def jdk-root
"The JDK root directory (parent of the `java.home` JRE directory)"
(-> (io/file (System/getProperty "java.home"))
(.getParentFile)))
(https://github.com/clojure-emacs/orchard/blob/v0.3.1/src/orchard/java.clj#L47)
Auf meinem System (archlinux) und im Ubuntus openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64
Paket scheint es, dass die Javas als Ordner unter /usr/lib/jvm
dh
# ~/Downloads/openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64/data $ tree usr/lib/jvm/ -L 2
usr/lib/jvm/
├── java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
└── java-11-openjdk-amd64
oder archlinux
# ~ $ tree /usr/lib/jvm/ -L 2
/usr/lib/jvm/
├── default -> java-11-openjdk
├── default-runtime -> java-11-openjdk
├── java-11-openjdk
├── java-8-openjdk
└── java-default-runtime -> default
in einer Demo ist emacs/cider repl java.home
zB:
(System/getProperty "java.home")
; => /usr/lib/jvm/java-11-openjdk
_Ich weiß nicht, ob etwas von außen dies durchgibt oder ob es das Standard-Home des aktuellen Javas ist._
Wenn ich mich nicht irre, würde das bedeuten, dass auf meinem System jdk-root ist
(-> (io/file (System/getProperty "java.home"))
(.getParentFile)))
; => /usr/lib/jvm/
was dazu führt, dass jdk-resource-url
Dinge im falschen (übergeordneten) Ordner nachschlägt
Abschluss:
jdk-roots
"Das JDK-Stammverzeichnis (übergeordnet des java.home
JRE-Verzeichnisses)" Kommentar / Prämisse scheint falsch zu sein (ich habe schnell online nachgesehen und es scheint keinen "Standard" zu geben, was java. Zuhause soll es wirklich sein)
Hilft das jemandem?
Ja, es hilft! Durch Java 8 zeigt die Systemeigenschaft java.home
auf eine JRE im JDK-Root. Dies wird gemäß https://docs.oracle.com/javase/7/docs/technotes/tools/linux/jdkfiles.html erwartet
user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-8-openjdk-amd64/jre"
Ab Java 9 ist das JRE-Unterverzeichnis weg und sein Inhalt wird eine Ebene höher im JDK-Root zusammengeführt, auf das java.home
jetzt zeigt:
user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-11-openjdk-amd64"
(siehe https://docs.oracle.com/en/java/javase/11/install/installed-directory-structure-jdk.html)
Als Nebenbemerkung für Benutzer von Debian-abgeleiteten Distributionen installiert das openjdk-11-source
Paket einen defekten Symlink zu src.zip
(siehe https://bugs.launchpad.net/ubuntu/+source/openjdk-lts /+Fehler/1791219)
Nach der Installation habe ich:
$ pwd
/usr/lib/jvm
$ ls -l java-11-openjdk-amd64/src.zip
lrwxrwxrwx 1 root root 21 Nov 20 04:13 java-11-openjdk-amd64/src.zip -> ../openjdk-11/src.zip
$ find openjdk-11 -type f
openjdk-11/lib/src.zip
Es scheint, als ob orchard an beiden Stellen überprüfen sollte, ob src.zip
lesbar ist. Es wäre auch schön, wenn nicht eine Squelchable-Warnung an STDERR auszugeben.
Ich würde gerne eine PR einreichen, wenn das vernünftig klingt.
In der Zwischenzeit können Sie Ihre Kopie von finden src.zip
und fügen Sie den Classpath manuell, zB mit einem :local/root
deps.edn Eintrag (wenn Sie auf tools.deps https geschehen sein: / /clojure.org/reference/deps_and_cli#_dependencies).
hm, es scheint, dass die Aufrufkette jdk-sources -> jdk-root
nur im Boot-Class-Loader aufgerufen wird, ansonsten ist es (.getContextClassLoader (Thread/currentThread))
,
Ich habe die ZIP-Datei im Klassenpfad mithilfe von project.clj . erzwungen
:profiles {:repl {:resource-paths ["/usr/lib/jvm/default/lib/src.zip"]}}
und überprüft über
> (System/getProperty "java.class.path") ; in repl buffer
; "/home/_/Projekte/repos/temp/test/test:/_/patrik/Projekte/repos/temp/test/src:
/usr/lib/jvm/default/lib/src.zip: <snip>
immer noch kein doc
Es sieht so aus, als ob dies unter Java 11 kaputt geht, bis https://github.com/clojure-emacs/orchard/issues/20 behoben ist.
Java 8 sollte aber funktionieren. Sie benötigen sowohl src.zip
als auch tools.jar
im Klassenpfad, der automatisch hinzugefügt werden soll. Dann könnten Sie etwas wie Folgendes versuchen (auf Cider v0.21.1):
(clojure.java.io/resource "java/util/AbstractQueue.java")
;; => #object[java.net.URL 0x2e00bc76 "jar:file:/usr/lib/jvm/java-8-openjdk-amd64/src.zip!/java/util/AbstractQueue.java"]
(require '[mranderson049.orchard.v0v4v0.orchard.java.parser :as ojp])
(keys (ojp/source-info 'java.util.AbstractQueue))
;; => (:class :doc :line :column :members :file :path)
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihren Beitrag und Ihr Verständnis!
@jeffvalk hat kürzlich das verlinkte Orchard-Problem angesprochen, also denke ich, dass wir dieses schließen können.
Unter Debian 10 musste ich nur openjdk-11-source
installieren. Ich versuchte, src.zip
zu symbolisieren und stellte fest, dass es bereits erstellt wurde.
Unter Ubuntu 18.04 mit Emacs 26.3 CIDER 0.24.0 nREPL 0.6.0 Java 1.8.0_242 habe ich ein Verzeichnis mit einer ZIP-Datei mit Java-Quellen als Ressource zum Leiningen-Profil hinzugefügt ( ~/.lein/profiles.clj
):
{:user {:resource-paths ["/usr/lib/jvm/openjdk-8"]}}