Clojurians Log v2

{ password: '#DXXXX&QZZZZ', username: 'junk' }

"errorType": "Error",
    "errorMessage": "No protocol method IAssociative.-assoc defined for type object: [object Object]",
    "message": "No protocol method IAssociative.-assoc defined for type object: [object Object]",
    "data": {...
TONS of junk
 "cause": {
        "errorType": "Error",
        "errorMessage": "No protocol method IAssociative.-assoc defined for type object: [object Object]",
        "stack": [
            "Error: No protocol method IAssociative.-assoc defined for type object: [object Object]",
            "    at $APP.Cb (file:///var/task/node_modules/nbb/lib/nbb_core.js:27:47)",
            "    at $APP.bc (file:///var/task/node_modules/nbb/lib/nbb_core.js:33:233)",
            "    at $APP.Gj.j (file:///var/task/node_modules/nbb/lib/nbb_core.js:723:379)",
            "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:560:322",
            "    at R (file:///var/task/node_modules/nbb/lib/nbb_core.js:309:469)",
            "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:559:317",
            "    at R (file:///var/task/node_modules/nbb/lib/nbb_core.js:309:469)",
            "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:558:423",
            "    at R (file:///var/task/node_modules/nbb/lib/nbb_core.js:309:469)",
            "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:559:305"
        ]
    },
    "name": "Error",
    "stack": [
        "Error: No protocol method IAssociative.-assoc defined for type object: [object Object]",
        "    at new Al (file:///var/task/node_modules/nbb/lib/nbb_core.js:176:80)",
        "    at $APP.xn.j (file:///var/task/node_modules/nbb/lib/nbb_core.js:1257:319)",
        "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:333:364",
        "    at ss (file:///var/task/node_modules/nbb/lib/nbb_core.js:333:373)",
        "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:560:397",
        "    at R (file:///var/task/node_modules/nbb/lib/nbb_core.js:309:469)",
        "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:559:317",
        "    at R (file:///var/task/node_modules/nbb/lib/nbb_core.js:309:469)",
        "    at file:///var/task/node_modules/nbb/lib/nbb_core.js:558:423",
        "    at R (file:///var/task/node_modules/nbb/lib/nbb_core.js:309:469)"
    ]

FWIW this gives me an error on Firefox too

much other JSON passing the same function works a treat

if this is related to JSON, you should probably give a more minimal repro related to parsing JSON

here is what I get on Firefox… added quotes around the keys so it is valid JSON.

so I would be interested in seeing how you are consuming JSON from Nbb… I dont have information on it, and Firefox fails when I try similar data

ah, no ... this is parsed JSON ... it will give you an error if you try to parse it

E.g. e repro like:

user=> (js/JSON.parse "{ password: '#DXXXX&QZZZZ', username: 'junk' }")
"SyntaxError: Unexpected token p in JSON at position 2"

"This is parsed JSON", then it's not JSON, it's just an object

the problem is running ->clj on it

Please make a complete repro, then I'll have another look

sorry ... yes I was in the middle of explaining 🙂

thing I'm trying to work out is what makes js->clj or ->clj barf so cannot reproduce yet. It's data coming from an AWS secret manager so it's fun to debug 😅

other secrets work fine, this one not so 🤷🏼‍♂️

could be related to the ampersand?

scrap this thread ... was something else completely. One of the joys of async interop. I was trying to (:x x) on a vector. Hence the IAssociative problem. I guess that's the most common cause. So something like this ...

(let [x (some-call)]
  {:k (:user x) :l (:pass x}) <--- oops

(let [[user pass] (some-call-that-I-should-have-known-results-in-a-vector)]
  {:k user :l pass}) <-- all fine

just to demo that any string is fine

user=> (def x (js/JSON.stringify (clj->js {:x "#Y&c"})))
#'user/x
user=> x
"{\"x\":\"#Y&c\"}"
user=> (-> x js/JSON.parse)
#js {:x "#Y&c"}
user=> (-> x js/JSON.parse ->clj)
{:x "#Y&c"}
user=> 

ok, good to hear it's resolved

as well as that one, it was YAB (yet another bug) but still - thanks for the therapy 😅

one thing I learned is that tap> is bad for debug cos it adds async to async ... prn works a lot better

https://github.com/nextjournal/nbb-test-runner

That's roughly what I have atm, only difference is I used run-all-tests with a regex to match namespaces that end in -test

Ah cool! Might switch to that

nice!

I still think it should support .cljc files too, so might require a PR if you're using that

currently it only looks for .cljs files

https://github.com/nextjournal/nbb-test-runner/commit/60ed57aa04bca8d604f5ba6b28848bd887109347#diff-2c6cb37f19a3c6f32f9ebbea734077b55ed5044ae287d4cf0ee8406d77318659R90

Not sure I want to add bb to the prerequisites just for this though. Since nbb is explicitly server-side, why not build it in like the other systems do? Just a thought 😇

It seems like that library is just cljs targeting nbb. Where are you seeing the bb dependency?

I thought nbb.edn was resolved by bb

$ nbb -cp test -m nextjournal.test-runner      
----- Error --------------------------------------
Message:  Could not find namespace: nextjournal.test-runner
Could not find namespace: nextjournal.test-runner
$ cat nbb.edn 
{:deps
 {io.github.nextjournal/nbb-test-runner {:git/sha "b9cb088adb9f406cb29c559cc6c59f68eb295916"}}}                                                                                                                                                                                                                            

yes

Ah thanks, all this time I thought nbb itself was using the nbb.edn, sounds like it just uses it for paths currently?

dependencies are resolved via deps.clj which needs a JVM to run

and it's used via babashka to copy dependencies into .nbb/.cache or something

and from there on, the local file system is used, no more JVM necessary

In theory could someone port that part to nbb or is the jvm absolutely required?

for tools.build/maven stuff a JVM is required, unless you port ALL of that to node.js

That sounds very fun and extremely daunting

That sounds like a reasonable stop gap