Fork me on GitHub
#nbb
<
2023-08-23
>
genRaiy08:08:03

I have a weird problem when parsing some seemingly innocent JSON 🧵

genRaiy08:08:29

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

genRaiy08:08:41

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

hifumi12308:08:44

FWIW this gives me an error on Firefox too

genRaiy08:08:14

much other JSON passing the same function works a treat

borkdude08:08:22

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

hifumi12308:08:03

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

hifumi12308:08:21

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

genRaiy08:08:55

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

borkdude08:08:01

E.g. e repro like:

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

borkdude08:08:23

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

genRaiy08:08:26

the problem is running ->clj on it

borkdude08:08:42

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

genRaiy08:08:50

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

👍 2
genRaiy08:08:39

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 😅

genRaiy08:08:15

other secrets work fine, this one not so :man-shrugging::skin-tone-3:

borkdude08:08:40

could be related to the ampersand?

genRaiy09:08:17

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

genRaiy10:08:10

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

borkdude10:08:56

ok, good to hear it's resolved

genRaiy11:08:08

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

genRaiy11:08:54

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

👀 2
genRaiy18:08:23

@jayzawrotny what is the current best practice for running tests? My way is via a runner.cljs that looks like this ... which requires some maintenance

(ns runner
  (:require
    [clojure.test :as t]
    [acme.lambda-support-test]
    [acme.api-gateway-test]
    [acme.kafka-test]
    [acme.webhook-test]))

(defmethod t/report [:cljs.test/default :end-run-tests] [m]
  (if (t/successful? m)
    (do (prn "Success!")
        (js/process.exit 0))
    (do (prn "FAIL")
        (js/process.exit 1))))

(t/run-tests
  'acme.api-gateway-test
  'acme.lambda-support-test
  'acme.kafka-test
  'acme.webhook-test)
which I then run via
npx nbb --classpath src:test test/runner.cljs

jaide18:08:15

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

jaide18:08:32

Ah cool! Might switch to that

borkdude18:08:00

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

borkdude18:08:23

currently it only looks for .cljs files

genRaiy22:08:35

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 😇

jaide23:08:26

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

genRaiy06:08:52

I thought nbb.edn was resolved by bb

genRaiy07:08:27

$ 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"}}}                                                                                                                                                                                                                            
See the https://github.com/babashka/nbb#clojure-dependencies for bb as a pre-requisite

jaide18:08:08

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

2
borkdude18:08:36

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

borkdude18:08:59

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

borkdude18:08:12

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

jaide18:08:43

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

borkdude18:08:51

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

jaide18:08:42

That sounds very fun and extremely daunting

borkdude18:08:44

you can also just git clone your deps and add them manually to the paths

jaide18:08:23

That sounds like a reasonable stop gap