This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-30
Channels
- # announcements (12)
- # babashka (25)
- # biff (30)
- # cherry (34)
- # cider (46)
- # clj-kondo (23)
- # clojure (37)
- # clojure-berlin (6)
- # clojure-europe (12)
- # clojure-nl (4)
- # clojure-norway (6)
- # clojure-uk (2)
- # clojurescript (8)
- # conjure (1)
- # cursive (4)
- # data-science (11)
- # datalevin (12)
- # datascript (15)
- # emacs (2)
- # events (1)
- # fulcro (14)
- # graalvm (16)
- # gratitude (23)
- # honeysql (11)
- # jobs (2)
- # jobs-discuss (14)
- # kaocha (1)
- # leiningen (8)
- # nbb (45)
- # off-topic (7)
- # portal (8)
- # re-frame (9)
- # releases (2)
- # shadow-cljs (24)
- # squint (5)
- # tools-build (17)
- # tools-deps (7)
- # vim (5)
I'm hoping to use the com.stuartsierra/component library with nbb. (I'm also pretty new to nbb.) I can't seem to load it directly.
npx nbb --classpath $(clojure -Sdeps '{:deps {com.stuartsierra/component {:mvn/version "1.1.0"}}}' -Spath) -e "(require 'com.stuartsierra.component)"
----- Error --------------------------------------
Message: Could not find namespace: com.stuartsierra.component
Could not find namespace: com.stuartsierra.component
Taking a look at the component library itself, I see there's a cljs.core/type->str
function used in com.stuartsierra.component.platform namespace. I think this might not be available in nbb.
As a way to confirm, I translated the component project.clj to deps.edn and ran:
npx nbb --classpath $(clojure -Spath) -e "(require 'com.stuartsierra.component.platform)"
----- Error --------------------------------------
Message: Could not resolve symbol: type->str
Phase: analysis
Could not resolve symbol: type->str
Is this likely the root of why the component library can't be loaded? I didn't see any other nbb error logging, but I haven't dug in further.
(for easier reference:) https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L328-L331
The issue is that nbb doesn't load jar files. This is documented in the README. You can use nbb.edn though
What that does is copy the jar files to a working directory and unzips them, then adds them to the classpath
The next error after type->str
I get is:
user=> (require '[com.stuartsierra.component :as component])
"#error {:message \"No protocol method IDeref.-deref defined for type null
Ah this hinges on IPrintWithWriter
on line 185. When I remove this, then it all seems to work
re: jars vs nbb. Thanks for the reminder. I knew that a couple of weeks ago and forgot it in the interregnum.
re: type->str is this a case of "nbb doesn't have support yet" or "this isn't something nbb is likely to support in the future and we could look at an upstream patch to component"?
What's the path for IPrintWithWriter
support? It looks like SciRecord implements it, but there's a piece I must be missing: https://github.com/babashka/sci/blob/3288e2988594a20daaadb4ee0662e0c2b2a8ca01/src/sci/impl/records.cljc#L223-L226
@U0EHU1800 Hmyeah. For the JVM Clojure path, there is hard-coded support for print-method
(which is the JVM equivalent of IPrintWithWriter
). We should probably do something similar for the CLJS path. Haven't looked into this that much yet
But I have ran into this a couple of times, so it's probably good to address this sooner than later
I noticed it came up in one of my first SCI issues 😉 https://github.com/babashka/sci/issues/684
And (as always happens) you rightly pointed out a better solution to what I was actually trying to do.
Been seeing how frustrated I can make myself how much I can learn by poking around and trying to implement this. I've got a failing test (as expected) and would like to confirm the behavior of my local SCI build (from master including the type->str
fix) in nbb with the component library. Would you say this is a reasonable thing to do? Or is there a shorter, more direct approach you'd recommend?
(Here's the test I've written, unfinished, but minimal which shows a failure):
(ns sci.core-protocols-test ,,,)
,,,
#?(:cljs
(deftest iprint-with-writer-test
(is (= "#<Foo>" (eval* "(defrecord Foo [])
(extend-protocol IPrintWithWriter
Foo
(-pr-writer [this writer opts]
(-write writer \"#<Foo>\")))")))))
And it even fails 🙂
% script/test/node -n sci.core-protocols-test
Running CLJS test in Node with optimizations :none
Testing sci.core-protocols-test
ERROR in (iprint-with-writer-test) (/Users/grzm/dev/sci/test/sci/core_protocols_test.cljc:118:10)
expected: (= "#<Foo>" (eval* "(defrecord Foo [])\n (extend-protocol IPrintWithWriter\n Foo\n (-pr-writer [this writer opts]\n (-write writer \"#<Foo>\")))"))
actual: #error {:message "No protocol method IDeref.-deref defined for type null: ", :data {:type :sci/error, :line 2, :column 30, :message "No protocol method IDeref.-deref defined for type null: ", :sci.impl/callstack #object[cljs.core.Volatile {:val ({:line 2, :column 30, :ns #object[sci.lang.Namespace], :file nil} {:line 2, :column 30, :ns #object[sci.lang.Namespace], :file nil, :sci.impl/f-meta {:ns #object[sci.lang.Namespace], :macro true, :sci/built-in true, :name extend-protocol}})}], :file nil}, :cause #object[Error Error: No protocol method IDeref.-deref defined for type null: ]}
Ran 5 tests containing 9 assertions.
0 failures, 1 errors.
Cheers. What's your development workflow for, say, testing the behavior of a sci change in nbb? For example, when you added clj->str in sci, and confirmed that the next issue for component was IPrintWithWriter, what was your setup? I assume you made a local sci build, used that in a local nbb build, and then used that nbb build on either the component source directly or via nbb.edn.
Right. My goal was to confirm that I was seeing the same deref error in nbb that I'm seeing in the failing sci test (to replicate what you did to find the next failure make sure I was setting up the test correctly, given I'm really cargo-culting/learning by example here)
What I did to test with component, was, I added it in nbb.edn, added test->str in nbb and then commented out the IPrintWithWriter in the .nbb directory
(The deref error appears "odd" enough—far enough removed from the IPrintWithWriter protocol stuff—that I wasn't sure I wasn't just screwing up writing the test.)
@U0EHU1800 75693266c6690b0971155bd6139d9854e2b1289a fixes the weird deref error message and gives a better error message
Nice. Good error messages are so helpful. I spent a couple of hours yesterday and the day before improving some in some internal tool that I released after Real Users™ found the edge cases I didn't catch.
ERROR in (iprint-with-writer-test) (/Users/grzm/dev/sci/test/sci/core_protocols_test.cljc:118:10)
expected: (= "#<Foo>" (eval* "(defrecord Foo [])\n (extend-protocol IPrintWithWriter\n Foo\n (-pr-writer [this writer opts]\n (-write writer \"#<Foo>\")))\n (pr-str (->Foo))"))
actual: #error {:message "Protocol not found: IPrintWithWriter", :data {:type :sci/error, :line 2, :column 30, :message "Protocol not found: IPrintWithWriter", :sci.impl/callstack #object[cljs.core.Volatile {:val ({:line 2, :column 30, :ns #object[sci.lang.Namespace], :file nil} {:line 2, :column 30, :ns #object[sci.lang.Namespace], :file nil, :sci.impl/f-meta {:ns #object[sci.lang.Namespace], :macro true, :sci/built-in true, :name extend-protocol}})}], :file nil}, :cause #error {:message "Protocol not found: IPrintWithWriter", :data {:type :sci/error, :line 2, :column 30, :file nil}}}
😄