does anyone know of any webrtc libraries for clojurescript?

@olivergeorge the tradeoff has been assessed and it’s not something we’re interested in pursuing.

@dnolen fair enough. Thanks.

@dnolen It feels like adding a new key to the destructing macro would be safe. let [{:jobj [a b]} someobj] would be safe but no doubt there's more to that sort of decision.

@andrewboltachev NP-complete problem is not impossible to compute, it just a kind of “hard” problem where you essentially have to try to test all possibilities

@darwin aha, so should be just one that requires tremendous amount of memory/speed

yep, for big inputs you need a lot of computation, not necessarily memory

Hello, where can I find browser support for clojurescript? Or is it just the same as for closure compiled code?

@adammunoz: ES3 (Very good support): https://github.com/clojure/clojurescript/wiki/FAQ-%28for-JavaScript-developers%29#does-clojurescript-work-in-old-browsers

@vikeri Oh O.K. thank you 🙂 I didn't see that in the docs

@adammunoz np!

reposted from #reagent:

(ns foo
    (:require [cljsjs.react :as react]
              [reagent.core :as reagent]))
  (reagent/adapt-react-class react/ReactCSSTransitionGroup)

question: should the reference to react/… work when I depend on cljsjs/react-with-addons?

@borkdude you should use js/React

aliasing foreign libs has no effect at this point

only if they’re consumed via the modules option

(and CLJSJS libs aren’t)

ah

https://github.com/clojure/clojurescript/wiki/Dependencies#bundling-foreign-javascript-code

^ here are the relevant docs

thanks

hey guys, does anyone use something like http://sentry.io or raygun with cljs? i’m curious how they got source-maps to work. in the case of sentry, you can pre-upload compiled + sourcemap files so that at runtime an error doesn’t trigger a GET /main.js.map to a huge sourcemap. the problem is, though, that sentry (and im not sure if this is a sentry problem or a misunderstanding of source maps) wants to fetch things like /main.out/foo/bar.cljs but can't

does this mean that my sourcemap is pointing from /main.js -> main.js.map -> main.out/foo/bar.js -> main.out/foo/bar.cljs, and that’s why the GET is attempted? how are all these files rolled into the main output of the closure compiler?

anyone using transit to send edn to a web worker? would it work without going to a string?

looks like no

@isak the only way to talk to workers is via string serialization

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer is a proposal - but I don’t believe any browser has implemented it

@olivergeorge yeah we’re just not going to bother - that’s the answer 🙂

@dnolen : here they say "Data passed between the main page and workers is copied, not shared. Objects are serialized as they're handed to the worker, and subsequently, de-serialized on the other end. The page and worker do not share the same instance, so the end result is that a duplicate is created on each end. Most browsers implement this feature as structured cloning." , so i wonder if it is possible to do better than cljs->json-str->json-obj->cljs

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers#Transferring_data_to_and_from_workers_further_details

Not that I'm aware of sorry

ok

hmm, I think there’s a way of transferring ownership between main process and webworkers

unless something else is being discussed here

that is only for special types of objects like ArrayBuffers, isn't it? and in 2 browsers

> Google Chrome 17+ and Firefox 18+ contain an additional way to pass certain types of objects (transferable objects, that is objects implementing the Transferable interface) to or from a worker with high performance. Transferable objects are transferred from one context to another with a zero-copy operation, which results in a vast performance improvement when sending large data sets.

yeah, but may be you could serialize cljs->edn->postMessage->edn->cljs

I use super big arraybuffers in one of my projects and it seems to work in all sane browsers.

what about having a json-object reader and writer for transit, instead of a json-string reader/writer?

maybe it would be faster

I’d prefer arraybuffer reader/writer so I can turn them into opaque data and throw it across worker boundaries.

@verma : wait are you transmitting edn that way? how?

no I am not, but large amounts of binary data

sorry if my comment indicated otherwise

I was suggesting we could do something like that

ah i see. unfortunately i have to use normal clojure data structures

I thought transit could do clj->binary .. sorry I don’t know very much about it.

I mean its definitely better than having JSON in the middle there and then losing some type info/data types.

yeah, that is the problem i have now

but may be cljs->pr-str->arraybuffer->postMessage->read-string->cljs ?

like on large objects you can transfer ownership instead of having it make a copy.

yea that would work, though might be costly for the ui thread

and just normal transit would be faster

but array buffer might help

yeah, I guess there’s a tradeoff, the JSON transit emits seems to have hinting to recover the type/data info. so you could use transit to encode your clj data and then send it over but I don’t think its transferrable.

and for supposedly larger sets of data you could go the transferable route by converting things to arraybuffer.

the transit json object would be transferrable, since the stuff that is transferable is actually a superset of json

hmm

interesting, I am not aware of that

so the problem is it is not exposed

I thought only arraybuffers were transferrable: https://developer.mozilla.org/en-US/docs/Web/API/Transferable

someone should tell them about persistent data structures

@isak I had a similar problem a year ago, there was no solution, ended up using transit for serialization, even if you had shared-memory json object kinda feature, you could not pass cljs values across javascript contexts, I learned the hard way using shared js contexts between iframes. the problem is that both js contexts typically end up with different cljs code, imagine one context has older cljs version than other. But it can be more subtle than that. For example in advanced mode you end up with completely different field names.

@darwin : ah makes sense, thanks

to be more precise, you could not pass cljs values across javascript contexts easily, you would have to be super careful, that both contexts strictly use code from the same :advanced build

to touch that shared object

right

as a side note, I happened to be sharing an object between two javascript contexts, ended up serializing them as plain js object with original serialized as string edn, but there was one pesky problem, the shared structure contained functions (callbacks), core.async channels and promises

but the story ended happily, I wrote a generic function which serialized all “callable” stuff to callbacks and included it in plain js-obj passed across, and that worked just fine

https://github.com/binaryage/dirac/blob/7be0089ff0db7c9de8a1c2fc3c85f59eea1af426/src/implant/dirac/implant/automation.cljs#L193-L196 https://github.com/binaryage/dirac/blob/7be0089ff0db7c9de8a1c2fc3c85f59eea1af426/src/shared/dirac/utils.cljs#L71