Fork me on GitHub
#clojurescript
<
2017-05-19
>
richiardiandrea00:05:12

maybe a bit offtopic here, but I am using transit-js and if I understand correctly it seems like it is not supporting json streams, can anybody confirm?

richiardiandrea00:05:41

I was hoping to go "append-only" all the way but I got:

...node_modules/transit-js/transit.js:2671
  return this.decoder.decode(JSON.parse(a), b);
                                  ^
SyntaxError: Unexpected token { in JSON at position 213

noisesmith00:05:21

transit should be able to decode the stream of data, JSON.parse returns objects doesn’t it?

noisesmith00:05:40

oh, wait, I misunderstood

richiardiandrea00:05:19

yeah I am reading a stream, I think the clojure one does it

noisesmith00:05:57

yeah, that’s a really weird error

richiardiandrea00:05:48

Oh I found: > Unlike the Java and Clojure implementations it relies on the non-streaming JSON parsing mechanism of the host JavaScript environment.

noisesmith00:05:00

I guess that answers it then

richiardiandrea00:05:41

yep, too bad, thanks for sharing the pain 😄

john00:05:52

So I was thinking that the reason functions like (constantly 1) couldn't be sent over to a web worker with their string versions was because CLJS somehow decomposed some functions into separate functions. I finally grokked that CLJS is creating a JS closure. And after some research, there is no way to reflect/introspect to get a JS closure's values.

john00:05:34

Eventually, you've gotta learn the host platform either way 😕

john00:05:51

I'm starting to get it though 🙂

tbaldridge03:05:52

Sending closures over a network connection is a bad idea anyways

tbaldridge03:05:01

Either you send just the function and hope the environment exists on the other end, or you try to send the environment and may end up transmitting the entire state of your vim.

tbaldridge03:05:27

Send data, that's what it's there for

john05:05:50

Yeah, that's pretty much the tradeoff I've settled on. Only sending a limited class of functions and the rest is data.

giovaferra07:05:26

@metametadata thank you, I will opt for a global registry. I want to write test-code that is more clojurian as possible, and using fixture seems to be recommended :thinking_face: do you know where I can find some test code well written? Or any books or documentation either? 🙂

kurt-o-sys09:05:08

Hey all, ES7 has the await for working with promises, instead of using .then and callbacks. If using a js library that returns promises (or uses .then), is core.async the way to go to avoid callbacks? Or can await be translated to cljs in another way?

(defn some-fn []
  (let [ch (chan)]
    (go 
      (-> something 
          (.js-method #js {< bunch-of-pars >})
          (.then #(>! ch %)))
      (<! ch))))
Or would there be a (better) way? (e.g. using https://github.com/dm3/manifold-cljs - not sure if it makes sense) Or should I be updating some kind of state and have a listener on that state, instead of returning values?

kurt-o-sys09:05:25

(Using core.async-channels looks nice, but I suppose they add quite some overhead and garbage - I may be wrong and I maybe shouldn't worry about it)

metametadata09:05:49

@giovaferra surprisingly, fixtures can also be considered a bad practice because they make reading test cases harder (you have to keep in mind the implicit execution context and jump to the top of the file to figure out what's going on), e.g. see this post by one the authors of NUnit - http://jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html Books I always recommend on the topic: "Test Driven Development: By Example" by Kent Beck "Growing Object-Oriented Software, Guided by Tests" by Steve Freeman and Nat Pryce "xUnit Test Patterns: Refactoring Test Code" by Gerard Meszaros

metametadata09:05:08

@kurt-o-sys recently I tried using core.async for async AJAX functions and return channels kinda like in your example but then opted out to simply passing callbacks. It looks just fine because I don't need some more complex scenarios/orchestration of async stuff.

darwin09:05:25

or maybe scratch my note about multiple puts, maybe your version also supports that now when I think about it more

darwin09:05:10

anyways my version is more straightforward, because you don’t need to create the wrapping go block

kurt-o-sys09:05:10

@darwin You're returning only the channel here, right? So changing the last line with (<! ch) would return the value.

kurt-o-sys09:05:21

I actually don't need a go-block?

darwin09:05:06

your original function returned a channel, go returns a channel with last evaluated form as value

kurt-o-sys09:05:20

oh, the go-block will result in problems, I see.

darwin09:05:28

no, it won’t result in problem

darwin09:05:45

go just returns a channel, which was the thing returned from your fn

darwin09:05:56

it is perfectly fine to pass channels around

couchemar09:05:32

Can one show more complex example with core.async? How it would be with "promises chain"?

kurt-o-sys09:05:43

@metametadata yeah, I've been thinking about it as well... but I wanted to avoid that 🙂

kurt-o-sys09:05:34

@darwin Yeah, its fine to return channels, although I wanted to avoid to require core.async everywhere in my code. But than again, maybe that's not really possible.

darwin10:05:50

@kurt-o-sys yes, in general core.async is infectious, similar way as callbacks are - it forces other code to use it as well

darwin10:05:38

but there are ways around it and that is pretty deep topic, you might want to watch recent @tbaldridge’s talk about this: https://www.youtube.com/watch?v=096pIlA3GDo

kurt-o-sys10:05:16

allright, thx!

darwin10:05:04

btw. if anyone wanted to see real-world cljs core.async code for inspiration, you could look at my chrome extension code, most chrome extension apis are async (callbacks), and I decided to convert them to core.async channels and write my code in core.async-style: https://github.com/binaryage/dirac/tree/master/src/background/dirac

giovaferra10:05:20

@metametadata mmm really interesting :thinking_face: , I will make some try to see what's better, it is the only solution, thanks! 😉

dm311:05:59

@kurt-o-sys I created manifold-cljs in order to implement some cross-platform manifold-based functionality. If you’re not already using manifold on the backend, going with core.async is a better idea for cljs

kurt-o-sys11:05:55

@dm3 yeah, I saw your library. nice work!

fdserr13:05:10

hi there. Which package should I add to :dependencies in order to be able to :require cljs.spec.alpha please? I'm using cljs 1.9.521.

thheller13:05:02

cljs 1.9.542 😉

dnolen13:05:42

@fdserr we didn’t break out spec nses into a separate dep like Clojure did

fdserr13:05:35

Solved, thanks Thomas @thheller! David, get some sleep ffs 😜

dominicm15:05:29

Reading the cljs pprinter, it seems like it's impossible to override the default (simple-dispatch) to include custom records, is that correct?

dnolen15:05:57

@dominicm not familiar so can’t say, but if it’s not a limitation of clj pprint then it shouldn’t be in cljs

dnolen15:05:33

@dominicm looks pretty simple to fix though, so patch welcome

dominicm15:05:49

@dnolen what is the class equivalent in cljs? type?

dominicm15:05:57

@dnolen IPersistentMap doesn't directly translate & it seems that clojure's respects IPersistentMap for PersistentArrayMap (I guess through the inheritance chain somehow? Not sure on that). I think I recall that cljs doesn't have I* equivalents, does it also switch between implementations for {} etc. automatically?

dnolen15:05:14

@dominicm you can’t cover protocols in multimethod like that in ClojureScript - that’s a fundamental limitation

dnolen15:05:24

if you want a catch all for records then it needs to be added

dnolen15:05:38

the other option is to write one for each record type you care about

dnolen15:05:54

you could remove the boilerplate with a macro of course

dominicm15:05:32

@dnolen Hmm, don't think I am fully grasping your solution. I don't think it will work with the record type cared about, as these are in clients. Unless there's a general way to match records to turn them over to another dispatch?

dnolen15:05:15

you can’t capture interface like Clojure can

dnolen15:05:46

that’s why there’s hard coded dispatch in ClojureScript but that’s actually a bit of a mistake

dnolen15:05:56

the final clase of the dispatcher should be type

dnolen15:05:13

but if you want to cover a protocol then it needs to be hard coded

dnolen15:05:17

IRecord is a protocol btw

dominicm15:05:57

Oh, derp. Got it.

dnolen15:05:43

happy to take a patch that does both of these enhancements at once

dominicm15:05:38

The current behaviour for records pprints the same as Clojure (at a glance).

john16:05:26

Hey folks, I'm looking for some advice/critique on this tau.call namespace. It's super hacky at the moment and I suspect that most of the namespace can probably be reduced to something much simpler and more resilient. I'm literally rewriting pr-stred functions. Is there a less hacky way to do (apply (fancy-translation (pr-str my-fn)) args)? https://gitlab.com/johnmn3/tau/blob/master/src/tau/call.cljs

miikka16:05:33

I don't know but this strongly resembles my attempts to extract deftype field names after advanced compilation 😎

john16:05:56

A lot of the current complexity of the namespace has to do with trying to clean up escaped characters in the pr-stred output, but that's probably a lot of unnecessary code.

john16:05:21

@miika yeah, I basically banged on it till it worked. Didn't bother cleaning it up too much since I doubt the whole method is going to be the "right way" anyway.

john17:05:36

I should note that in another namespace I'm doing this: (cljs.reader/register-tag-parser! "object" #(str "#object" %))

john17:05:50

And with respect to JS closures making some CLJS functions un-round-tripable, I've been reading on SO at least a half a dozen ways to define JS closures such that their private variables can be made accessible from the outside. If CLJS emitted such code, it would definitely make CLJS more reflective/introspectable/round-trippable and would align closer with the "code is data" philosophy. No idea about the performance tradeoffs though.

thheller18:05:18

could use a few more brave alpha testers 😉

madstap18:05:31

I'm thinking of writing a library in cljc. Are there any recomended lein templates or similar with the basic setup (testing, cljs build (for browser and node) etc.). I found https://github.com/magomimmo/cljs-start on github, but it uses a 0.0-xxxx cljs version, so I'm a bit wary of that.

dnolen19:05:48

cljs.core.async/promise-chan never really worked correctly, I believe the issue is finally solved in master - https://github.com/clojure/core.async/commit/52f6bc19b599623a247539311e81336c5979b19f

dnolen19:05:26

if you have time to take it for spin that would be great

noisesmith19:05:16

honest question - what does this when check do that doseq alone wouldn’t ?

+              (when (seq take-cbs)
 +                (doseq [f take-cbs]
 +                  (dispatch/run f)))

kurt-o-sys19:05:09

I'm trying to use goog-define/`:closure-defines` to read config at compile-time, but it doesn't work. In my project.clj:

:profiles {:dev {:dependencies [[figwheel-sidecar "0.5.8"]
                  [com.cemerick/piggieback "0.2.1"]]
          :source-paths ["src" "env/dev"]
          :cljsbuild
          {:builds [{:id      "ios"
                     < ... >}}
                    {:id      "android"
                     < ... >
                     :compiler {:output-to   "target/android/not-used.js"
                                :main     "env.android.main"
                                :output-dir  "target/android"
                                :optimizations :none
                                :closure-defines {conf "from project.clj"}}}]}
I'd expect that the output of (goog-define conf "from code") in my code would set conf to from project.clj. It doesn't. It shows from code.
(defn init []
 (goog-define conf "from code")
 (.log js/console conf)
 (mount-app)
 (.registerComponent < ... >)
What am I missing?

thheller19:05:35

move the goog-define out of init, it is basically a def

kurt-o-sys19:05:32

did that, same result.

noisesmith19:05:28

thanks for confirming

dnolen19:05:00

in this case just taking care to match the Clojure implementation for future patchers

dnolen20:05:42

there’s definitely a lot of low-hanging fruit if people want to jump in and help. I’ll be checking on this repo at least on Fridays along with my usual combing through ClojureScript JIRA - so if you want to contribute this is a great place to start.

norman23:05:58

Is it possible to force the use of a foreign-libs :file-min for a build that isn’t using advanced compilation?

norman23:05:59

I don’t see any way to override it besides forking the cljsjs package, which seems a bit drastic