This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-06
Channels
- # announcements (1)
- # aws (36)
- # babashka (105)
- # beginners (53)
- # calva (27)
- # cider (5)
- # clj-kondo (10)
- # clojure (232)
- # clojure-europe (4)
- # clojure-italy (6)
- # clojure-losangeles (9)
- # clojure-nl (3)
- # clojure-sanfrancisco (3)
- # clojure-uk (124)
- # clojured (3)
- # clojurescript (57)
- # clojutre (1)
- # core-async (9)
- # core-logic (1)
- # cryogen (23)
- # cursive (35)
- # datomic (12)
- # duct (4)
- # events (1)
- # figwheel-main (3)
- # fulcro (9)
- # graalvm (31)
- # jobs (1)
- # jobs-discuss (85)
- # kaocha (11)
- # leiningen (11)
- # luminus (19)
- # malli (47)
- # meander (12)
- # nrepl (8)
- # off-topic (32)
- # pathom (4)
- # pedestal (2)
- # reagent (7)
- # ring-swagger (1)
- # schema (3)
- # sql (5)
- # tools-deps (114)
- # vim (17)
- # xtdb (12)
Added clojure.core/read-string
to bb:
$ bb "(ns foo (:require [clojure.string :as str])) (read-string \"::str/foo\")"
:clojure.string/foo
nice 🙂
btw, what do you think about adding eval
to sci? It would have the same limitations as the outer evalString
. Makes sense?
yeah that will probably work... I'm thinking about the security issues with :deny
and :allow
how do you mean? wouldn’t they be forwarded to the eval context?
so you wouldn’t be able to override it in eval. Just be able to do somethign dynamic
cool, let me know if you want me to do it
ok, if you read through this commit, you can see what should be moved to sci: https://github.com/borkdude/babashka/commit/aa4139931e8a66e3d1977339a08eff050d7e1aea
in sci this would need an additional test to see if it's safe with :deny and :allow etc.
ok maybe i should finish the apply stuff first, but I could do it later
1.5 day of work 🙂 @borkdude it’s ready for another review. Commits can be squashed probably https://github.com/borkdude/sci/pull/283
ah cool
I’ll start using read-string right away 🙂
i was already abusing evalString for that
my branch fails on Linux with No implementation of method: :unbind of protocol: #'sci.impl.vars/IVar
and this happened yesterday as well. Seems to be unrelated to my work. Is there some flakyness in that test that you are aware of? https://circleci.com/gh/borkdude/sci/4056?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
cannot find the failed build of yesterday now, but I remember seeing this before
yes, that's a flakiness that's been there for a long time and I can't discover what causes this. it never happens on babashka, but it does happen on sci CI
since I can't discover what this is caused by, just pressing run again will likely fix it
ok cool good to know
probably a redefinition of the protocol
the only relevant difference between sci and babashka i can see is that Babashka defines a :main
in project.clj. I’ve seen that :aot
and :main
make some namespaces be reloaded twice, which could cause a reloading of the namespace with the relevant protocol, which could cause this error message for all the namespaces that were loaded before the second reload. Not sure if that makes sense, but I’ve seen this type of error in the repl many times
haha yes indeed. I’ll save it for later. Now need to get something done with all those beautiful features you have added
I'll take a look at the PR tonight or tomorrow again, need to work on something else now
perfect, no rush. I have a locally compiled version
Is there a way use the babashka docker image to include deps as clojure is not installed by default?
The other way of doing it would be better depending on your problem. Use the clojure image as a base and install babashka binary only. The way that I think about these things is whats my primary use-case: if its linting before a clojrue build, id use clj as base image, if I need to use babashka to do some more fancier things, I'd use that as base etc. Hope this helps! 🙂
ah sorry, was having clj-kondo in mind 😛
execute some clj scripts before a clj build
Anyway. The babashka docker image is really thin, based on busy-box:musl. If you want to add more stuff, it's probably better to start over from an image like ubuntu or whatever and then download the binary into the image, add clojure, etc.
Or start with the clojure image, maybe easier. (cc @rahul080327 )
@borkdude makes sense to me. Thanks for Babashka. It is a very nice scale-down addition to the clojure world. Lots to think about.
JS challenge no. X:
(defn constructor-fn [class]
(let [constructor (js/Function.prototype.bind.apply class)]
(fn
([a] (new constructor a))
([a b] (new constructor a b c))
([a b c] (new constructor a b c d))
([a b c d] (new constructor a b c d e))
([a b c d e] (new constructor a b c d e))
([a b c d e f] (new constructor a b c d e f))
([a b c d e f g] (new constructor a b c d e f g))
([a b c d e f g & more]
(throw (ex-info "Constructors with more than 7 arguments are not supported" {:class class}))))))
(apply (constructor-fn js/EventSource) ["/yeah"])
🙈I have a macro like this (but more complicated) in interpreter.cljc which does the same for function invocations
ah cool, i’ll have a look
It’s has to be runtime i think
it cannot be a macro, but I’ll try
maybe yeah, i”m affraid new
is something special, but otherwise that is way better
yeah fingers crossed, stupid js
pooh this is so confusion haha. Looking at normal sci that looks like cljs, but in the background has those magic constructors. Let’s make this work and never think about it again
Is there a reason why sci fn’s are clojure fn’s and not javacscript functions? For better interop it would be easier if they were js functions (in some cases at least). Maybe a macro should be added that creates a js fn
E.g. this doesn’t work now because the fn is not a js fn: sci.evalString("(.addEventListener (js/EventSource. \"/aaa\") \"message\" (fn [e] (.log js/console e)))", {"classes": {"allow": "all", "js": window}})
sorry, I understand why fn’s are not plain js functions. I’m trying to think of a solution
functions returned from sci can be called in JS unless they are macros (because macros contain metadata), but toJS fixes that
The special case works now:
sci.evalString("(js/EventSource. \"/aaa\")", {"classes": {"allow": "all", "js": window}})
I’m trying to figure out how to add the event listener inline. Trying toJS now
sci.evalString("(.addEventListener (js/EventSource. \"/aaa\") \"message\" (to-js (fn [e] (.log js/console e))))", {"classes": {"allow": "all", "js": window}})
sci.min.js.map:400 Sci received opts {:bindings {to-js #object[yW]}, :namespaces {}, :allow [], :deny [], :preset nil, :realize-max nil, :classes {allow all, js #object[Window [object Window]], :allow all}, :env nil}
analyzer.cljc:175 Uncaught Nn {message: "Illegal invocation [at line 1, column 1]", data: k, Ac: TypeError: Illegal invocation
at Zh (…, name: "Error", description: undefined, …}
vQ @ analyzer.cljc:175
sW @ js.cljs:50
(anonymous) @ js.cljs:50
Z @ js.cljs:50
uW @ js.cljs:50
bW @ js.cljs:50
AW.b @ js.cljs:50
AW @ js.cljs:50
(anonymous) @ VM1156:1
I tried to add the to-js
via the bindings
it’s the same if I don’t use to-js
I’m trying it in steps now to see what’s wrong
This works 🙂
sse = sci.evalString("(js/EventSource. \"/sse\")", {"classes": {"allow": "all", "js": window}})
f = sci.evalString("(fn [e] (.log js/console e))", {"classes": {"allow": "all", "js": window}})
sse.addEventListener("message", f)
which is already quite something
so maybe the function isn't properly interpreted yet and you're adding just a sexpr?
it would be evaluated from left to right? Wouldn’t it be interpreted as a function?
right to left i mean
I’ll start debugging
I’m trying this now:
sci.evalString("(.addEventListener (js/EventSource. \"/sse\") \"message\" f)", {"classes": {"allow": "all", "js": window, "bindings": {f: function(e) { console.log(e) }}}} )
gives
Could not resolve symbol: f
not sure what that is
I feel like a guinea pig 🙂
ah wrong brackets
same error, so it is something at a different layer indeed. I see that the argument to the function is wrapped (message #object[f])
maybe I need to unwrap all args to interop calls?
ah yeah you call object-array. Maybe that’s the same indeed
thanks
Following works now , except for the read-string
version
(let [sse (js/EventSource. (ext dev-url))]
(.addEventListener sse "message"
(fn [e]
(js/console.log "Data 1" e)
(js/console.log "Data 2" (.-data e))
(js/console.log "Data 3" (eval (.-data e)))
(js/console.log "Data 3" (pr-str (.-data e)))
;; Fails
(js/console.log "Data 4" (read-string (.-data e)))
)))
it says ” “No protocol method HasName.getName defined for type null: ”
Maybe I broke something with all the interop 🙂
oh the eval doesn’t work either I see now. Maybe something wrong with the context. In simple cases read-string and eval work
oh wait eval expects a form. Never mind
code is here btw https://github.com/borkdude/sci/pull/286 I’ll revisit it later. Calling it a day now. Have a good weekend!
Does this mean I can ignore the previous PR then? I'll wait reviewing until you are done experimenting, since it seems you are still making progress. When you're done you can explain it all to me 😉
Yeah probably better. Basic interop has improved. If someone needs it, they can ask or checkout that branch. For the callback interop I'm still hitting walls. Also I was thinking that I can probably create better unit tests along the way as I start to get a better idea of how all this .apply stuff in js works. Maybe the browser tests could be postponed as well
Yeah, good idea. Also splitting up your improvements in smaller units (PRs with code and tests) is maybe an idea, so it's easier to understand and review?
Fully agree
If I pass read-string via bindings
"read-string": function(data){ return sci.evalString(data, {}) }
it does workOk really going now 🙂
I've tested eval + read-string on node, it seems to work there:
evalString('(eval (read-string "(+ 1 2 3)"))');
6
Also works in the playground: https://borkdude.github.io/sci.web/
Yeah same here. For some reason it doesn't work anymore in my js callback. I'm guessing it has to with all the js interop. I'm taking a small break on debugging. We'll look at it again next week