Fork me on GitHub
#clojurescript
<
2016-01-08
>
virmundi00:01:22

the figwheel ring-handler doesn't appear to be working.

fappy00:01:01

@virmundi: if you're using lein, there is a lein-figwheel channel

eyelidlessness03:01:27

is there a reason (catch :default is allowed in cljs, but not in clj?

eyelidlessness03:01:51

it makes for some pretty awful cljc macros

alexmiller04:01:48

@eyelidlessness: there is a ticket for that, not sure where it's headed

alexmiller04:01:24

feel free to vote...

eyelidlessness04:01:13

interesting, it seems like broadly the semantics really don't line up, because of some Java peculiarities

eyelidlessness04:01:58

my instinct is that the JS version of Error wouldn't truly be catchable in any real-world runtime

eyelidlessness04:01:06

e.g. stack overflows

eyelidlessness04:01:08

but i haven't tested that

eyelidlessness04:01:10

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

eyelidlessness04:01:54

(actually trying... it turns out i'm wrong, max call size is indeed catchable in JS)

eyelidlessness04:01:02

@alexmiller: thanks for pointing me to the ticket... really not sure i know enough about the implications to back a particular solution

pupeno11:01:53

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

dnolen12:01:45

@pupeno there is an #C06DT2YSY channel

ragge13:01:47

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

dnolen13:01:14

@ragge not supported you are just getting lucky

dnolen13:01:27

there’s a ticket for supporting it - but someone needs to work on it

ragge13:01:46

@dnolen ok, thanks... found it in a library

dnolen13:01:00

right they are just getting lucky - lots of cases will not work

ragge13:01:48

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

dnolen13:01:01

there's no way to make it work

dnolen13:01:04

the functionality does not exist

dnolen13:01:34

your only real option is ES5 Object.create

ragge13:01:05

@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

dnolen13:01:30

@ragge yes make new work with whatever

dnolen13:01:41

the Clojure restriction is unnecessary and complicates interop

ragge13:01:01

ok, thanks

dnolen13:01:32

to be honest I’m surprised no-one has submitted about it before but I suspect

dnolen13:01:48

few people make custom types, new halfway works, and Object.create is an OK fallback

ragge13:01:13

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

dnolen13:01:55

right people less familiar with Clojure semantics tend to get this one wrong

dnolen16:01:45

easy way to contribute ^

anmonteiro16:01:48

getting No reader function for tag js when trying to use #js {} within a macro

anmonteiro16:01:58

am I doing something wrong?

anmonteiro16:01:05

it is supposed to be supported, right?

anmonteiro16:01:30

I suppose I can always use js-obj

dnolen17:01:09

@anmonteiro: it won’t work in your Clojure code unless you’ve installed that data reader

dnolen17:01:27

and yes js-obj is good enough for macros

anmonteiro17:01:41

@dnolen: makes sense thx

mbertheau17:01:58

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?

dnolen17:01:26

@mbertheau: this matters more for libraries, for applications not really all that relevant

mbertheau17:01:28

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

andrewmcveigh17:01:30

A huge map that is used to dispatch parsing/formatting functions.

andrewmcveigh17:01:19

If one of those functions in formatters is used anywhere, the whole thing is going to be compiled in

andrewmcveigh17:01:27

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

andrewmcveigh17:01:14

Even just :requiring namespaces written like this can add to your compiled js.

andrewmcveigh17:01:41

So for a lib, you’re affecting everyone who uses it.

andrewmcveigh17:01:50

There’s going to be a lot more ‘dead’ code in a library that you hardly use, vs. your app.

andrewmcveigh17:01:32

Unfortunately for me, the whole namespace needs to be re-written.

bhauman17:01:05

geez! good to know!

dnolen17:01:40

@mbertheau: it’s not a problem for apps

dnolen17:01:57

if you haven’t observed a problem in production then it’s safe to not assume anything

dnolen17:01:13

no one has ever reported a DCE issue around top level literals in their apps ever

dnolen17:01:53

for libs it’s problematic because the chances that you are using everything in some lib is close to zero

mbertheau17:01:37

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

mbertheau17:01:58

@dnolen: Alright, thanks!

andrewmcveigh18:01:01

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