Fork me on GitHub
#clojurescript
<
2018-07-14
>
thheller08:07:20

@bocaj cljs.main works via clojure.main. so you mainClass clojure.main and then as args -m cljs.main ...

Karol Wójcik12:07:10

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. 🙂

billyr14:07:11

Works for me, pretty sure your running into cljs macro limitations of your env. Trying to define the macro in a repl session?

Karol Wójcik14:07:54

@UA12E0JEM Nothing is print to the console.

billyr14:07:15

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.

billyr14:07:57

Don't know whats your environment like but for new macros to work I have to both recompile and restart the repl

Karol Wójcik14:07:49

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?

billyr14:07:07

I wouldnt know sorry

justinlee15:07:36

@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

❤️ 4
roti13:07:48

clojure.edn does not seem to be available in clojurescript. am i missing something?

jjttjj14:07:22

The tldr being that you want cljs.reader/read-string

carocad18:07:02

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 ... ?

carocad18:07:57

I have checked my inferred externs and it seems to catch every interop that I do and Mark it as "object". Is that bad?

justinlee21:07:58

@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)

justinlee21:07:45

at any rate, the difference is about space, not time

carocad21:07:27

@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

justinlee21:07:01

“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

justinlee21:07:36

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

justinlee21:07:23

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

carocad22:07:47

Ok I think I'm starting to get a better idea about it :) thanks a lot for your explanation it helped me a lot

dnolen23:07:06

@carocad there’s no downside really