This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-08
Channels
- # admin-announcements (19)
- # announcements (1)
- # beginners (70)
- # boot (192)
- # braid-chat (55)
- # cider (3)
- # cljs-dev (42)
- # cljsjs (2)
- # cljsrn (25)
- # clojars (23)
- # clojure (162)
- # clojure-brasil (3)
- # clojure-czech (18)
- # clojure-russia (10)
- # clojurecup (3)
- # clojurescript (63)
- # code-reviews (6)
- # community-development (340)
- # core-async (7)
- # cursive (4)
- # datomic (20)
- # events (2)
- # funcool (3)
- # hoplon (20)
- # jobs (33)
- # ldnclj (11)
- # lein-figwheel (9)
- # leiningen (6)
- # off-topic (1)
- # om (79)
- # proton (4)
- # re-frame (39)
- # ring-swagger (4)
- # slack-help (2)
- # yada (2)
is there a reason (catch :default
is allowed in cljs, but not in clj?
it makes for some pretty awful cljc macros
@eyelidlessness: there is a ticket for that, not sure where it's headed
feel free to vote...
interesting, it seems like broadly the semantics really don't line up, because of some Java peculiarities
my instinct is that the JS version of Error
wouldn't truly be catchable in any real-world runtime
e.g. stack overflows
but i haven't tested that
i'm not sure what the semantics of :default
actually should be on the JVM, and i'm hesitant to get behind something that could be dangerous in that scenario
(actually trying... it turns out i'm wrong, max call size is indeed catchable in JS)
@alexmiller: thanks for pointing me to the ticket... really not sure i know enough about the implications to back a particular solution
In the Om Next quick start, it says "When writing a backend parser you will usually supply env yourself.” By backend, is it talking about Clojure running on the server (not ClojureScript running on the client)?
@dnolen: thanks.
hi! is a non-var first argument supported for new
? for example: (let [x js/Date] (new x))
? I get a warning about it but it still compiles into a working new Date(...)
call
@dnolen: ok.. is it the case that it could work (and "just" needs to be implemented) or is there another preferred way to call new for a javascript object?
@dnolen: tried to find the issue in jira to understand more but couldn't... is the intention to make new
work with things other than vars or is a different approach needed? i'd be interested to look deeper at this issue
maybe because it sometimes works... fyi the problem I found is in: https://github.com/andrewmcveigh/cljs-time/blob/master/src/cljs_time/format.cljs#L412
getting No reader function for tag js
when trying to use #js {}
within a macro
am I doing something wrong?
it is supposed to be supported, right?
I suppose I can always use js-obj
@anmonteiro: it won’t work in your Clojure code unless you’ve installed that data reader
@dnolen: makes sense thx
https://github.com/andrewmcveigh/cljs-time/issues/21#issue-53533513 has me wary of having (def section-base-order [:when :where :what])
on the top level. Is the concern still warranted?
@mbertheau: this matters more for libraries, for applications not really all that relevant
@dnolen: could you elaborate a bit on how exactly global persistent vectors defeat dce? I assumed that defeating DCE leads to dead code still in the output, which would increase the size of the resultant JS significantly. This would be a problem for apps as well. What am I missing?
@mbertheau: see https://github.com/andrewmcveigh/cljs-time/blob/master/src/cljs_time/format.cljs#L316
A huge map that is used to dispatch parsing/formatting functions.
If one of those functions in formatters
is used anywhere, the whole thing is going to be compiled in
And in this case the whole namespace uses formatters
, so if you use anything in this namespace you’re going to add 20+Kb to any js
Even just :requiring
namespaces written like this can add to your compiled js.
So for a lib, you’re affecting everyone who uses it.
There’s going to be a lot more ‘dead’ code in a library that you hardly use, vs. your app.
Unfortunately for me, the whole namespace needs to be re-written.
@mbertheau: it’s not a problem for apps
for libs it’s problematic because the chances that you are using everything in some lib is close to zero
@andrewmcveigh: That makes sense, thanks for the explanation. I was under the impression that the persistent map was the source of the problem, but it's that the functions are referenced.
@mbertheau: It is the map that is the problem, because DCE can’t look inside it. And in this case because of the size of the code generated for everything inside of it.