Clojurians
#cljs-dev
<
2016-10-19
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

richiardiandrea14:10:36

Sooo :asset-path is relative and I can customize it, but what if I want to serve my entire .out folder from some other place (for dev purposes and to mimic serving assets from somewhere else), how can I do it?

richiardiandrea14:10:42

And is this something you would accept a patch for? in boot-reload there is a :asset-host key that does kind of that Not true, sorry.

dnolen17:10:44

ok I’m about to cut a release - doing the changes and forging the email now

dnolen17:10:52

if you want to test now would be a good time

viebel19:10:57

@dnolen can you share more details about data literals support and how it relates to the new require macro?

dnolen19:10:21

those files don’t need ns forms - that’s it

viebel19:10:23

what files?

anmonteiro19:10:27

@viebel e.g. data_readers.cljc

viebel19:10:46

@anmonteiro where is this file?

dnolen19:10:32

search for data_readers.clj and see what it says

viebel19:10:43

interesting stuff...

dnolen20:10:56

@bhagany we can clarify int but the other fns are really an orthogonal conversation entirely

dnolen20:10:05

they only exist to ease porting - not for any semantic reason

dnolen20:10:42

you could in fact summarize nearly all of ClojureScript’s numerics this way

bhagany20:10:02

okay. I’m a bit unclear on what int is really supposed to do, semantically

bhagany20:10:14

for long and unchecked-long I think it’s easier - just removing the “Identical to `int’” part would resolve it

dnolen21:10:41

int just coerces to int

dnolen21:10:54

clamping via bit-or is the only reasonable way to do that

dnolen21:10:42

re: the others, @bhagany I agree, though we could be perhaps a bit more clear in those that they are there to ease portability not semantics

bhagany21:10:26

okay, I think I understand. Though, I do think that this particular behavior of int is more likely to cause undetected bugs when porting than it is to ease it. It gets weird for larger numbers.

bhagany21:10:29

cljs.user> (int 1000000000)
1000000000
cljs.user> (int 10000000000)
1410065408

dnolen21:10:43

@bhagany there’s nothing for it

dnolen21:10:56

we didn’t write the specs or the JS engines

dnolen21:10:05

and we’re not going to eat any perf losses in this area

dnolen21:10:20

@bhagany if you look around you’ll see that int is on many critical paths

dnolen21:10:43

the pattern of N | 0 is used by JS engines thanks to asm.js/webasm as an optimization hint

dnolen21:10:05

so unless you have a brilliant idea how not damage hashing and the data structures there’s nothing to do

bhagany21:10:05

I don’t, and I’m not trying to argue that you should. I do think that the goal of easing portability isn’t well-served, but if there’s nothing to do, then there’s nothing to do.

dnolen21:10:06

portability of numerics and other host-y things isn’t a goal, never was

dnolen21:10:26

by ease of portability I just mean "hey it runs”, not “all my tests pass"

dnolen21:10:53

the latter is unrealistic given the early performance goals - and now water under the bridge

dnolen21:10:17

any changes here for whatever time you may have lost has to be weighed against how much time everyone else will lose

dnolen21:10:23

figuratively and literally in this case

bhagany21:10:00

I really just wanted documentation changes

dnolen21:10:34

yes, I’m all for that

bhagany21:10:16

okay, I’ll give it a go