Cider: لا يعرض CIDER مستندات لـ Java

كما ترى ، تم أيضًا حل الرمز عن طريق الخطأ لـ java.lang.Character / toUpperCase بدلاً من lang.String.

ألا تحصل على مطالبة تسألك عن الإصدار الذي تختاره؟

bbatsov الغريب ، اليوم هو مثل هذا (وهو أفضل بكثير 😂):

لقد تحققت ، وحصلت على المطالبة عندما أستخدم مفتاح الاختصار الافتراضي (في Spacemacs يكون , h h في حالة الشر - العادي) ، ولكن ليس عند استخدام مفتاح التشغيل السريع هذا ، لقد قمت بتكوين نفسي:

(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"))))))

يتخطى مفتاح التشغيل السريع هذا الموجه بطريقة ما ويعرض المستندات الخاصة بالشخصية.

راجع للشغل ، تلميح eldoc يمكن أيضًا أن يستخدم بعض الأعمال ، على سبيل المثال ، الفصل بين أرجس الطرق المختلفة:

لم نتمكن من إيجاد فصل جيد ، ولهذا السبب قمنا فقط بخلط تواقيع جميع الإصدارات الممكنة. إنه مثالي ، لكن لسوء الحظ لا يمكنني رؤية كيف يمكن تحسين ذلك أيضًا. يجب أن يكون لدى Eldoc بنية سلسلة ver ، وإلا فإن تمييز المعلمات هناك سيتعطل.

bbatsov لقد

أتساءل عما إذا كانت الأشياء تتغير بالنسبة لك إذا جربت Java 8 بدلاً من 9. لم يكن لدي الكثير من الوقت للعب مع Java 9 وأتساءل عما إذا كانت بعض عمليات التلاعب في مسار الفصل التي نقوم بها لا تعمل بشكل صحيح هناك أو شيء من هذا القبيل. أيضًا - تأكد من تقييم المخزن المؤقت للشفرة قبل تجربة eldoc / cider-doc).

bbatsov لقد تحولت إلى Java 8 ، وما زلت لم أواجه أية مشكلات (لكني لم أفعل الكثير من الترميز منذ ذلك الحين ، فمن يدري).
لقد فهمت للتو أنك الشخص الذي يلقي هذا الحديث ^ __ ^ بطريقة ما بدت صورتك الرمزية عدوانية جدًا بالنسبة لي وهذا النوع من فاجأني :)) شكرًا لك على عملك ؛) أنا أشاهد حديث Clojure Bad Parts الآن 😊

هاها!

واعتقدت أن هذا كان وجهي السعيد! 😄

مرحبًا (emacs / cider للمبتدئين هنا)

أين يقع هذا الخطأ في عصير التفاح / خريطة الطريق العامة؟

هل هو أكثر

• لا أحد لديه الوقت للعمل على هذا
• سيتم حلها مع / عن طريق البستان
• يعمل على النحو المنشود
• ليس من المفترض أن تعمل الآن؟

في كل مرة أقضي فيها بعض الوقت في تعلم clj / emacs ، ينتهي بي الأمر بالرغبة في البحث عن فصل دراسي والإحباط - وهو أمر يخصني تمامًا ، لكني أسأل نفسي باستمرار:

هل الإعداد الخاص بي خاطئ أو معطل ، أو أن مطوري clojure "الحقيقيين" لا يحتاجون أبدًا إلى البحث عن javadoc - وهو الأمر الذي قد يكون محيرًا للغاية بالنسبة لي.

حقيبة الاختبار الخاصة بي هي البحث عبر cider-doc java.util.concurrent.PriorityBlockingQueue والذي ينتج عنه https://imgur.com/a/TaQXfpS .

باختصار: هل هذا معطل فقط بالنسبة لي أم للجميع وكيف يتعامل الناس بدونه؟

PPS: لقد حاولت مع java 8-11 مع تثبيت java-doc و java-src

المخرجات:

في الفصل

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.

على طريقة

java.util.concurrent.PriorityBlockingQueue/add
 [this java.lang.Object]
Not documented.

For additional documentation, see the Javadoc.

Definition location unavailable.

تقدم !

أعتقد أن ما يلي يحدث

الفرضية: أستخدم spacemacs ، والذي يستخدم عصير التفاح من MELPA ، حاليًا 0.20.0 + cider-nrepl 0.20.0

يستخدم cider-nrepl 0.20.0 البستان 0.3.1

مشكلة:

يكتشف orchard مصادر جافا عن طريق jdk-sources -> jdk-resource-url وبشكل حاسم -> 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)

في نظامي (archlinux) وفي حزمة ubuntus openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64 يبدو أن جافا هي تخطيط كمجلدات تحت /usr/lib/jvm

بمعنى آخر

# ~/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

أو 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

في العرض التوضيحي emacs / cider repl java.home هو مثال:

(System/getProperty "java.home") 
; =>  /usr/lib/jvm/java-11-openjdk

_لا أعرف ما إذا كان هناك شيء من الخارج يمر بهذا ، أو ما إذا كان هو الصفحة الرئيسية الافتراضية الحالية لجافا ._

إذا لم أكن مخطئًا ، فهذا يعني على نظامي jdk-root

(-> (io/file (System/getProperty "java.home"))
      (.getParentFile))) 
; => /usr/lib/jvm/

مما أدى إلى ظهور jdk-resource-url للأشياء في المجلد (الأصل) الخطأ

استنتاج:

يبدو أن تعليق / فرضية jdk-roots "الدليل الجذر لـ JDK (أصل دليل java.home JRE)" خاطئ (لقد تحققت بسرعة عبر الإنترنت ويبدو أنه لا يوجد "قياسي" مثل ما هو جافا. من المفترض أن يكون المنزل حقًا)

هل هذا يساعد أحدا؟

نعم ، إنها تساعد! من خلال جافا 8 ، تشير خاصية النظام java.home إلى JRE داخل جذر JDK. هذا متوقع في https://docs.oracle.com/javase/7/docs/technotes/tools/linux/jdkfiles.html. لا يمكنني العثور على رابط لـ javase / 8 ولكني أراقب بشكل تجريبي (على دبيان):

user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-8-openjdk-amd64/jre"

من جافا 9 فصاعدًا ، اختفى دليل JRE الفرعي وتم دمج محتوياته بمستوى واحد في جذر JDK ، والذي يشير الآن java.home إلى:

user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-11-openjdk-amd64"

(انظر https://docs.oracle.com/en/java/javase/11/install/installed-directory-structure-jdk.html)

جانباً لمستخدمي التوزيعات المشتقة من دبيان ، تقوم الحزمة openjdk-11-source بتثبيت ارتباط رمزي معطل لـ src.zip (انظر https://bugs.launchpad.net/ubuntu/+source/openjdk-lts / + علة / 1791219)
بعد تثبيته ، لدي:

$ 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

يبدو أنه يجب على البستان التحقق من كلا المكانين واختبار ما إذا كان src.zip يمكن قراءته. سيكون من الجيد أيضًا طباعة تحذير قابل للإسقاط إلى STDERR إذا لم يكن كذلك.
سأكون سعيدًا لتقديم العلاقات العامة إذا كان هذا يبدو معقولًا.

في غضون ذلك ، يمكنك العثور على نسختك من src.zip وإضافتها إلى مسار الفصل يدويًا ، على سبيل المثال باستخدام إدخال :local/root deps.edn (إذا كنت على tools.deps https: / /clojure.org/reference/deps_and_cli#_dependencies).

حسنًا ، يبدو أن سلسلة الاستدعاء jdk-sources -> jdk-root يتم استدعاؤها فقط عندما تكون في محمل فئة التمهيد وإلا فهي (.getContextClassLoader (Thread/currentThread)) ،

لقد فرضت ملف zip على classpath عن طريق project.clj

:profiles {:repl {:resource-paths ["/usr/lib/jvm/default/lib/src.zip"]}}

والتحقق عبر

> (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>

لا يزال لا يوجد وثيقة

يبدو أنه سيتم كسر هذا على Java 11 حتى يتم إصلاح https://github.com/clojure-emacs/orchard/issues/20 .
يجب أن تعمل Java 8 بالرغم من ذلك. ستحتاج إلى كل من src.zip و tools.jar على مسار الفصل الذي يجب إضافته تلقائيًا. ثم يمكنك تجربة ما يلي (على 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)

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة نظرًا لعدم وجود نشاط حديث لها. سيتم إغلاقه إذا لم يحدث أي نشاط آخر. شكرا لمساهمتك وتفهمك!

jeffvalk تناول مؤخرًا مشكلة Orchard المرتبطة ، لذا أعتقد أنه يمكننا إغلاق هذه المشكلة.

في دبيان 10 ، كل ما كان علي فعله هو تثبيت openjdk-11-source . ذهبت لمحاولة إنشاء رابط رمزي src.zip ووجدت أنه قد تم إنشاؤه بالفعل.

على Ubuntu 18.04 مع Emacs 26.3 CIDER 0.24.0 nREPL 0.6.0 Java 1.8.0_242 أضفت dir يحتوي على ملف zip مع مصادر Java كمورد لملف تعريف Leiningen ( ~/.lein/profiles.clj ):

{:user {:resource-paths ["/usr/lib/jvm/openjdk-8"]}}