Fork me on GitHub
#clojurescript
<
2016-02-06
>
mheld01:02:55

I have a {x: [1 2 3 4], y: [a b c d]} and I want it to become [{x: 1, y:a}, {x:2, y:b}… ]

mheld01:02:00

is there a built-in function that does this

mheld01:02:43

eh screw it, I’ll just (map vector (:x DATA) (y: DATA))

mheld01:02:47

that seems to be o

mfikes01:02:22

If you have

(defn f [^boolean b]
  (loop [x b]
    (if x
      (recur 0)
      :done)))
then (f true) should never return, right?

comamitc02:02:35

0 in JS is a false-y condition. So it will return on the second loop.

mfikes02:02:14

Is x known to be Boolean-valued?

mdhaney03:02:49

@mheld: zipmap

danielsz05:02:58

@nha I use cljs-ajax. It's excellent.

danielsz05:02:58

@cjmurphy: For UI, I prefer to use js interop directly from the react based wrapper rather than a component library built on top of a react wrapper. For me that's the abstraction level that fits. Component libraries above react wrappers bring another cognitive load that I can do without.

danielsz05:02:46

@cjmurphy: Here's how I reuse notifications for example: https://github.com/danielsz/om-flash-bootstrap

niwinz11:02:20

Someone knows https://github.com/ptaoussanis/nippy like library for clojurescript?

oskarth13:02:12

Does anyone know why (inc :1) => "`:11` (and :foo => ":foo1" ) in Clojurescript?

jaen13:02:23

Possibly because IIRC keywords are represented as strings internally in Clojurescript?

oskarth13:02:20

And in JS strings can be incremented by appending +1

oskarth13:02:59

makes sense

jaen13:02:23

Yeah, the 1 will be cast to "1" and concatenated.

oskarth13:02:30

is it by design that you can perform string operations on keywords or is it more a matter of not being worth the effort/perf hit to disallow it?

oskarth13:02:01

I seem to recall reading/hearing something about keywords representation but can't find it

jaen13:02:55

I think it's just like w namespaces being GClosure modules or aget working for objects

jaen13:02:59

An abstraction leaking through

jaen13:02:57

Hm, just checked, because I was not 100% sure

jaen13:02:31

I think it's true that at some point they were plain strings, but right now they are cljs.core.Keywords.

jaen13:02:16

But they do have a toString method which when you do keyword + 1 due to some Javascript coercion trickery, coerces both to string and concatenates them.

oskarth13:02:52

so it's not really feasible to make it into a no-op

oskarth13:02:06

since you need the toString method for some things, presumably

jaen13:02:38

Yeah, not with all those implicit coercions abound.

bruno.bonacci13:02:49

@niwinz you might want to look at https://github.com/cognitect/transit-cljs is on top of json but it is fast and eventually it will support MessagePack as well

niwinz13:02:26

thanks @bruno.bonacci , I know about transit-cljs, but the readme warns about it should not be used for persistence

niwinz13:02:38

just for message transmission...

niwinz13:02:09

And I finding something faster than edn for serialize objects and persist them

bruno.bonacci13:02:59

you want to persist data from ClojureScript on the browser?

niwinz13:02:23

yes, this is one of the use cases...

bruno.bonacci13:02:29

you could use transit for the browser->server communication and then use https://github.com/clojure/data.fressian for on the server to persist the data

jaen13:02:45

To be fair I use it for just that; the docs warn about not using it for persistence

jaen13:02:52

But the data you're going to persist on the browser

bruno.bonacci13:02:59

fressian in the format used by Datomic on the persistence layer

jaen13:02:14

Are either transient to some approximation, or you would probably synchronise them to the backend anyway.

niwinz13:02:28

I prefer nippy on the server side, is much faster and the format layout is stable...

jaen13:02:33

So I think using transit for, say, persisting into local storage doesn't sound bad.

niwinz13:02:23

The concrete use case is serialize some maybe bit data tree using some serialization library and compress it using xz in frontend

niwinz13:02:41

some of that data will go to the server already using transit other goes to local storage

niwinz13:02:51

the server does not knows nothing about this "blob"

niwinz13:02:00

only the frontend manages it

bruno.bonacci13:02:17

@niwinz: did you compared the performances of fressian vs nippy?

jaen13:02:26

But that's something you don't mind going away?

jaen13:02:33

Like a cache or something?

bruno.bonacci13:02:29

in my benchmarks there was only very little difference (fressian 1-2% slower) like the THAW

jaen13:02:09

For write-heavy workloads though freeze performance is also important.

niwinz13:02:18

@jaen Frontend manages a data structure (that can be big) and the approach for persist that is just take a snapshot and persist it...

niwinz13:02:32

the backend knows nothing about that and it does not care about it

jaen13:02:13

But what I mean, if this structure is something that you do not send to the backend

jaen13:02:20

It means it's something you're prepared to lose, isn't it?

jaen13:02:41

Because even the same user using the application from different browser

jaen13:02:48

Won't be able to access the same structure

jaen13:02:54

If you don't store it on the server, right?

niwinz13:02:16

it depends... on the applicatin logic, explain everything will take time

niwinz13:02:38

if you are interested I can explain it in separated room for avoid spam here

bruno.bonacci14:02:16

You could store it on the client but just roundtrip to the backend to get the data serialized/deserialized.

niwinz14:02:38

this is just I want to avoid

niwinz14:02:03

I just want to send the backend already serialized and compressed blob

niwinz14:02:12

or just store it locally in localstorage

jaen14:02:43

Hah, you don't have to and I don't have time right now unfortunately. What I was trying to say is, if it's something you story only in the browser and not on the server, it seems like something you can just use transit with because it seems transient.

jaen14:02:47

But now that you say

jaen14:02:55

You store it on the server after serialisation

jaen14:02:03

I can see why you're not eager to use transit.

niwinz14:02:37

I can use transit but I will lock me always to the v8 (the current version) of the transit spec

niwinz14:02:05

if something is changed on transit spec... i do not be able upgrade...

jaen14:02:32

Yeah, that's what I mean here - upgrading to newer version of the spec would be a major pain; you'd have to read each blob and write it out again.

jaen14:02:36

In that case...

niwinz14:02:50

transit is perfect for me, but the warning about the spec can change...

jaen14:02:58

You say you already has some compression code on the frontend if I understand properly?

bruno.bonacci14:02:42

what you really want is a high-performance edn serializer/reader which doesn’t exists yet

bruno.bonacci14:02:04

that would be perfect

niwinz14:02:06

i really want something like fressian/nippy on cljs 😉

jaen14:02:26

And would be hard/impossible to write honestly; JSON/transit are only so fast because they run native code.

niwinz14:02:46

I think that the solution will go to be: enable compresson on the transport protocol (http) and just serialize/compress on the backend.

jaen14:02:20

Yeah, that was why I asked if you already have some compression routines, since that's what I was going to suggest

niwinz14:02:24

and just use transit to transfer it to backend

jaen14:02:27

Just compress on the front and serialise later.

niwinz14:02:19

Thanks to both for the suggestions 😉

mfikes14:02:30

@viebel: I’d be interested if your cljs.core$macros issue is resolved with the patch in http://dev.clojure.org/jira/browse/CLJS-1541

dnolen15:02:14

@oskarth: that’s just undefined behavior, you should get a warning about trying to use inc on anything that isn’t a number (unless it’s a higher order call)

dnolen15:02:53

@mfikes you shouldn’t lie about type hints like that - still that’s an interesting edge case since type hints flow across let bindings

oskarth15:02:17

@dnolen: ah indeed, tried it without tooling and got an error. planck seems to have swallowed the warning

oskarth15:02:11

fixed in planck 1.9, was still running on 1.8

isaac_cambron17:02:05

I’m cutting over my lein-cljsbuild stuff to using cljs.build.api, mostly because my build has some complexity better served by direct scripting than trying to trick cljsbuild into fitting my needs. But I’d still like to manage dependencies by magic, so I’m using lein deps to get the jars. What I don’t know is how to tell the compiler where to find them. Do I need to add each lib to the classpath or is there a better way?

mfikes17:02:03

@isaac_cambron: lein classpath is worth checking out

isaac_cambron17:02:15

ah, so i would call that, grab the output, add it to my java command to run the compiler, and then I’m good to go?

mfikes17:02:56

Yep it works with java -cp

isaac_cambron17:02:42

makes perfect sense. i’ll try that. thanks!

pre22:02:33

Garden, the awesome css lib, is up with v1.3.1—bugfixes, parity with libs —> https://github.com/noprompt/garden