This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-14
Channels
- # aleph (3)
- # beginners (25)
- # cider (12)
- # clojure (42)
- # clojure-canada (3)
- # clojure-nl (1)
- # clojure-russia (2)
- # clojure-spec (13)
- # clojure-uk (24)
- # clojurescript (23)
- # cloverage (1)
- # datomic (7)
- # figwheel-main (3)
- # jobs-discuss (14)
- # onyx (48)
- # parinfer (3)
- # re-frame (20)
- # reitit (28)
- # shadow-cljs (3)
- # testing (1)
- # vim (37)
@bocaj cljs.main
works via clojure.main
. so you mainClass
clojure.main
and then as args -m cljs.main ...
I am trying to write a very trivial macro which converts the promise to channel.
(ns cod-lambda.macros.async
(:require [clojure.core.async :refer [go <! >! chan]]))
(defmacro p->chan
"Convert promise p to channel"
[p]
`(let [c# (chan)]
(doto (.resolve js/Promise ~p)
(.then (fn [res#] (go (>! c# res#))))
(.catch (fn [err#] (go (>! c# err#)))))
c#))
then in cljs I want to use that macro as such
(go
(println (<! (p->chan {}))))
It seems bizzare for me that I received
Error: No protocol method ReadPort.take! defined for type cljs.core/Cons: (cljs.core/let [cod-lambda.macros.async/c (cljs.core.async/chan)] (cljs.core/doto (.resolve js/Promise nil) (.then (cljs.core/fn [res__20855__auto__] (cod-lambda.macros.async/go (cljs.core.async/>! cod-lambda.macros.async/c res__20855__auto__)))) (.catch (cljs.core/fn [err__20856__auto__] (cod-lambda.macros.async/go (cljs.core.async/>! cod-lambda.macros.async/c err__20856__auto__))))) cod-lambda.macros.async/c)
Something is wrong with my 'let but I do know what exactly. Highly appreciate your help. 🙂Works for me, pretty sure your running into cljs macro limitations of your env. Trying to define the macro in a repl session?
@UA12E0JEM Nothing is print to the console.
You can try a trivial macro to see if they're loading correctly at all. Remember to :require-macros in a separate ns and it should work.
Don't know whats your environment like but for new macros to work I have to both recompile and restart the repl
Ok it works, thank you very much @UA12E0JEM. But I have one question though, why do I have to require my macros using the :require macros while the core async macros are accessible using refer?
@U9ARBCP5K take a look at the three sections called “Sugar” “Implicit Sugar” and “Implicit Refer” to see how to do that http://blog.fikesfarm.com/posts/2016-03-01-clojurescript-macro-sugar.html
Thank you all
https://stackoverflow.com/questions/24661655/clojure-clojurescript-clojure-core-read-string-clojure-edn-read-string-and-c this seems to discuss that in depth
Hey guys, I'm a bit confused about externs inherence. What is the downside of it? I mean in Clojure it is clear that the code would be less efficient so in clojurescript it would mean ... ?
I have checked my inferred externs and it seems to catch every interop that I do and Mark it as "object". Is that bad?
@carocad it may be possible to write externs manually such that certain props can be munged in certain instances. i think that inferred externs get attached to object
, so it would have a global effect for any given prop. however, i seriously doubt the difference would amount to a hill of beans. if you really cared about that kind of space optimization, you’d be better off removing the need for externs all together by running your javascript through closure (which may require modifications)
@lee.justin.m so does that mean that externs inherence guarantees (as much as possible) the use of JavaScript interop without the need for manual work? Sorry for the ignorance but I'm not familiar with the closure compiler and I still read everywhere about the need for externs so in confuse whether I should care strongly about it or if those are just a nice to have
“externs” is a strange name: it’s really a list of symbols that is passed to the closure compiler which will not be minified. the closure compiler (in advanced compilation mode only), will minify the code by changing property accesses like user.firstName
to something like x.y
, so that the code is shorter. with external javascript that is not being run through the closure compiler, that obviously will break the code. so externs inference just figures out the list of symbols that closure should not munge for you. you should definitely be using it
if you do a lot of javascript interop, i’d suggest using shadow-cljs as your build tool. externs inference works really well with it
to answer your question: if you are just getting started, definitely use externs inference. it’s easier. to the extend there is any penalty for using it, it is microscopic