Fork me on GitHub
#clojurescript
<
2016-11-22
>
chriscraws00:11:24

Hi guys, total clojure noob here. (about 75% through reading Brave Clojure, but no real experience). Bitwig Studio is a DAW (digital audio workstation) with a JS API, currently I am able to send strings to be evaluated by Bitwig over TCP from a normal clojure app - but it would be nice to send compiled clojurescript from the clojure repl. What should I read about to get this set up?

cdine01:11:45

whats the nodejs equivalent of 'done'? in clojurescript ?

cemerick04:11:43

In Clojure, (repeat 1.3 :a) => '(:a). In ClojureScript, this yields '(:a :a). Is this a known inconsistency? (Same goes for take, drop, etc)

cemerick04:11:09

nvm, the inconsistency exists only for repeat AFAICT

danielgrosse10:11:13

Okay i written it all in the same cljs file. Know I created a clj file with the macro and implemented it via require-macro. But now the compiler throws a

(call-tour-action ".rotateTo" ath atv)))
        ^--- Invalid local name: vr-secondview.utils.macros/e at line 32

anmonteiro10:11:00

you need to gensym a symbol

chris-andrews16:11:38

Is anyone able to use the clojure.spec.gen namespace in clojurescript? I’m getting No such namespace: clojure.spec.gen…when I try to require it. Also tried cljs.spec.gen

Alex Miller (Clojure team)16:11:13

I think it is cljs.spec.impl.gen

chris-andrews16:11:01

thanks @alexmiller that namespace seems to work. is this cljs specific, or is that the namespace in clojure too? the clojure.spec guide page has (require '[clojure.spec.gen :as gen])

anmonteiro16:11:12

@chris-andrews it's specific to ClojureScript. It's impossible to have a cljs.spec.gen namespace given we have a cljs.spec/gen var

chris-andrews16:11:38

oh, I see, thanks for the explanation

tianshu16:11:17

Is it possible to have a clojurescript compiler works like babel for ecmascript?

dnolen16:11:04

@doglooksgood can you clarify what you are asking?

tianshu16:11:45

I mean, when I writing ReactNative, the RN packager server use babel to transform my js code to ES5. And the packager provide hot-reloading. It works fine. But If I want to use ClojureScript, the Figwheel need some shim to work with the RN packager, this will cause the terrible error stack and complex development environment. What if I want to compile ClojureScript just like transform ES with babel?

chris-andrews16:11:48

follow up regarding using cljs.spec.impl.gen. when I try (gen/generate (s/gen int?)) I get Error: No protocol method IRandom.split defined for type null: …

tianshu16:11:34

maybe what I need is just cljsbuild auto?

dnolen16:11:55

@doglooksgood I think you’re mixing up a few things here

dnolen16:11:08

RN has it’s own package manager - Babel isn't really relevant

dnolen16:11:39

the solution would be to provide a custom package manager for RN + ClojureScript

dnolen16:11:52

but this isn’t really the right channel for that discussion

tianshu17:11:44

If there's a babel-plugin-transform-cljs, all I need for writing RN in cljs is just one line in .babelrc file. I'm not sure if this is the correct way, but feels pretty simple, compared with re-natal or boot-react-native.

dnolen17:11:52

@doglooksgood I would bring up the idea in #cljsrn 🙂

dnolen18:11:01

@anmonteiro nice on the socket REPL bit

anmonteiro18:11:43

@dnolen it's a very cool addition that I'm really excited for. credit to @jmf though, who put a PR together

misha20:11:54

@anmonteiro @mfikes what are the differences between lumo and planck use cases?

mlatu20:11:46

I'm trying to start with react-native on clojurescript (new to react). Before I got om working. Can I get om with react-native or should I use something else?

mfikes20:11:00

@misha The use cases are likely very similar right now.

misha20:11:10

@mlatu #om-next #cljsrn #re-frame

misha20:11:36

@mfikes will it change? or will it be a matter of one's preference which repl to use?

misha20:11:22

@mlatu give a read to web pages linked in channels' descriptions

mfikes20:11:38

@misha Lumo covers more platforms and supports the Node ecosystem, and has implemented most of the stuff in Planck

mfikes20:11:31

@misha Planck currently has some ClojureScript wrappers around I/O facilities, etc. but Lumo will likely gain those as well.

mfikes20:11:04

In the end, I think the main difference is going to be JavaScriptCore for one, V8 and Node capability for the other—those will be the salient differences.

misha20:11:05

are you going to consolidate the effort and "merge" into single project?

dnolen20:11:25

@mlatu the most popular React bindings should work fine with React Native, Om or Reagent - it’s possible others

dnolen20:11:42

@mlatu there’s a channel dedicated to React Native - #cljsrn, might want to ask questions there

mfikes20:11:05

But, Lumo and Planck may share a common set of ClojureScript I/O wrappers to ease moving between the two, but that would be in the future

mfikes20:11:04

@misha The question of whether to use Planck or Lumo will likely drive a lot of people crazy 🙂

misha20:11:00

that's what upsets me right now - another (un)educated guess I'd need to make for, what it seems like, very subtle difference in outcome

anmonteiro20:11:16

@misha merging into a single project is a non-goal since the target JS platforms are different

anmonteiro20:11:21

(and that's a good thing!)

nikki20:11:23

@misha: its maybe subtle in the sense of when u write a word doc on either mac or win and its ok

nikki20:11:37

But becomes less subtle if you want to do syscalls and then those are different on the platforms

nikki20:11:28

What i mean is (= 3 (+ 1 2)) on both but if you're doing something dependent on the ecosystem then it matters

nikki20:11:48

And there is a spectrum there

misha20:11:57

@anmonteiro how hard is it to have multiple platform back-ends? or rather: how much harder it is to support both platform subsets under single project, than maintaining similar UX in 2 projects?

nikki20:11:10

And generally you can write your code such that the parts that are agnostic of things can be reused elsewhere

nikki20:11:45

I think at a certain point doing a full vertical quickly on both platforms

nikki20:11:01

Pays off higher in terms of info gained particular to ur use case

nikki20:11:07

Vs thinking about it etc

nikki20:11:20

May be worth it to take the plunge, try both for a day each

misha20:11:21

@nikki I think my questions originate from a frustration of having multiple independent repls, which all have similar but not identical UX, and you need to struggle one way or another with each of them: figwheel, cursive, lein, nrepl, planck, lumo. I get the unavoidable(?) need to have separate repls for clj and cljs, but having multiple ones per lang - is pain

dnolen20:11:51

@misha the JVM stuff isn’t like the bootstrapped stuff

dnolen20:11:58

lumping these together doesn’t make any sense to me

misha20:11:42

(I am talking about UX, not platforms: things like autocompletion, parinfer integration, colors, etc.)

nikki20:11:15

@misha: having multiple ones as opposed to merging the ones ppl make or killing some of them?

dnolen20:11:47

@misha why should the UX be the same?

dnolen20:11:54

Cursive is inside an IDE not a terminal

misha20:11:25

@dnolen I think it is safe to assume, that majority of devs would not say no to those 3 features. I'm not saying it is trivial to implement, it just makes me sad, that one repl has one subset of those, and another - has different one

misha20:11:58

meaning it is possible to have all of them at the same time

dnolen20:11:52

I think doing something generic like you’re describing is probably way more work then it sounds

dnolen20:11:11

you can’t just paper over the differences between IDE/Terminal, nREPL/socket

misha20:11:50

I still believe there is an implementation possibility, which consolidates all of the high level UX goodies 🌈 with different backends. or at least "as a re-usable library", which different back-ends can use to become similar looking/behaving but with required differences under the hood to account for platform differences

dnolen20:11:05

@misha maybe you will work on this! 🙂

misha20:11:42

@dnolen seeing very smart people not delivering this working on it that long - is discouraging for compiler/platforms noob like me

dnolen20:11:27

@misha people work on what they want to work - and usually whatever that is 10X the amount effort everyone else perceive it to be

dnolen20:11:19

very little with being smart

dnolen20:11:30

probably a lot more to do with self-flaggelation 😉

mikebelanger20:11:29

@misha regarding parinfer, colors Atom basically does this regardless of the Clojure(script) implementation. Autocompletion is admittedly still inconsistent, but there's encouraging developments now that Atom has cleared up its UI refractor

mikebelanger20:11:53

@misha personally, I find just getting a terminal emulator for Atom and starting the REPLs in that to be 90% of what I need anyways

misha20:11:15

@dnolen what I mean is: much more than a single person have been working on this for a long time with all the compiler/platform specific stuff figured out and preloaded to the brain, and the "single awesome repl" is not even close to exist )

dnolen20:11:47

@misha anyways - I’ve said my piece

dnolen20:11:52

stuff gets done when you work on it

misha20:11:17

@mikebelanger using ide/editor to planck/lumo is too much ) it might be a viable solution as of now, but not as an end-goal

darwin20:11:34

one day this might become a reality: https://github.com/binaryage/cljs-devtools/issues/11, one REPL to rule them all 😛

mikebelanger20:11:01

@misha too much? Its 1 plugin on Atom, then however you install Planck/Lumo. Way easier than some intense emacs config file, imho

misha20:11:24

@mikebelanger either you are asking me to switch to atom, or I did not fully understand the solution

mikebelanger20:11:46

@misha yeah the first one 🙂

misha20:11:16

@darwin unfortunately github issue and 1 dude (me) complaining about it online is not enough : ) but some day soon I will get pissed off enough to dig into why exactly this is such a difficult problem and might even end up helping!

darwin20:11:32

@misha well, that’s my TODO list after I retire 🙂

mikebelanger20:11:50

@misha one-repl-to-rule-them-all is an interesting goal, I also happen to think knowing which implementation you're running on (ie JavascriptCore, V8) is still relevant.

misha21:11:25

@darwin in such case I hope you are 70 years old already kappa

misha21:11:29

@darwin > in a similar way how cljs-devtools work for ClojureScript. do you have a design document/diagram? or I'd need to read the source?

darwin21:11:46

but @misha has a point, UI/UX can be decoupled from underlying “REPL engine"

darwin21:11:06

this is what I did in Dirac REPL, it can use Cursive REPL as GUI: https://github.com/binaryage/dirac/blob/master/docs/integration.md

darwin21:11:21

for people who prefer it this way

darwin21:11:27

but implementing something like this as a robust solution is… well… non-trivial

borkdude21:11:58

What is the best way to convert a clojurescript object to a compressed string?

anmonteiro21:11:23

@borkdude depends on the platform you're on?

anmonteiro21:11:01

I'd probably go with Transit + some compression algorithm. lzw seems promising

borkdude21:11:36

I was thinking about Transit too

kenny21:11:38

Does anyone else have the problem where they enable "Pause On Caught Exceptions" in Chrome, refresh their cljs app and have to click through a ton of exceptions before the page actually runs your code? Also, all of the exceptions are coming from various minified files (coming from my project deps, I guess) and none of the exceptions are actually logged to the console (e.g. If I disable "pause on caught exceptions" and refresh the page, it loads fine with no exceptions thrown).

darwin21:11:17

not sure about the inconsistency you are describing, but you should able to use script blackboxing feature of DevTools to ignore noisy exceptions from library code

darwin21:11:20

also try to test it under Canary, DevTools has been under heavy development, so some things might be fixed (and others broken again :)

kenny21:11:49

I've had this problem in cljs dev for as long as I can remember. The workaround I do is only enable the pausing after the page has loaded.

kenny21:11:51

I'll try the blackboxing feature to see if it'll help. My only worry with that is if a real exception is thrown from that file, I won't get notified about it

darwin21:11:09

using exceptions in non-exceptional situations is a code smell, this sounds to me as a poor choice of libraries in the first place

kenny21:11:43

One of the libraries is jquery. I'm not using it but I guess one of my dependencies is

dnolen21:11:02

@kenny you almost never want “Pause on Caught Exceptions"

dnolen21:11:13

too many rando JS libs, use exceptions for flow control

dnolen21:11:39

you have this problem in JS too, nothing to do with ClojureScript

darwin21:11:07

btw. internally blackboxing is implemented on file+line-range chunks, so it might be possible to blackbox only some misbehaving functions, but that is still not a good solution when you update the library sources or lose devtools state

darwin21:11:31

not sure if devtools expose such finegrained controls tough

darwin21:11:39

I don’t use it myself

kenny21:11:32

ah. I often need to enable it because I get better exceptions when working with async calls

kenny21:11:26

Good to know @darwin. Thanks for the info guys!

samedhi21:11:57

I have two functions video.play() and video.pause() that I need to call on video (an HTML5 video element). I know of externs but am just wondering if there is some way other than using externs to be able to call play() and pause() on a video element without getting my play() and pause() munged in advanced compilation?

dnolen21:11:37

@samedhi Google Closure should have externs for that now

dnolen21:11:48

if not just write the extern yourself

dnolen21:11:57

people have come up with a bunch of hacks - none of these things I recommend

dnolen21:11:23

Object.pause; Object.play;

dnolen21:11:23

absolutely everyone writing ClojureScript should know how to write an extern file

darwin21:11:27

IMO using string names is the way to go 🙂 externs is a hack

dnolen21:11:52

you’re not going to hear me ever recommend anything else

dnolen21:11:00

and you will hear me repeat this advice a lot

darwin21:11:12

with cljs-oops, you can live happily using string names: (ocall! video “play”)

darwin21:11:38

have to promote my baby, you know 🙂

dnolen21:11:05

taking on an dependency to avoid writing a extern - do not want 🙂

samedhi21:11:25

Is this the best way to search google closure? http://google.github.io/closure-library/api/

dnolen21:11:38

@samedhi yes but not for externs

dnolen22:11:35

however this is master - so it might not have what you’re looking for

dnolen22:11:38

however HTML Video is old

dnolen22:11:45

@samedhi already there ^ nothing to do

samedhi22:11:55

@dnolen Yep, I see that, thank you.

kenny22:11:30

@dnolen Could you explain why you recommend writing externs over using cljs-oops? (or point me to a previous conv you had explaining it) I have started using it in my libs and it seems like a super lightweight wrapper of aget. It is a pain to manage externs because it is somewhat of a context switch. I don't want to have to think about having to writing externs when I am deep into programming some UI using a chart library -- I can just write the code verbatim using cljs-oops and know my advanced compilation will "just work." Not to mention having to double check everyone's work when pulling in a 3rd party extern (see cljsjs). It is clear that you have a strong opinion about this and I am very curious as to why.

dnolen22:11:59

It’s just my recommendation after years of working on projects. I never pull in convenience deps for production.

dnolen22:11:22

dependencies always need vetting and I’m not going to spend anytime vetting anything that has a built-in solution in ClojureScript itself

dnolen22:11:52

you can of course figure out this lesson the hard way yourself - and you’re welcome to it 🙂

darwin22:11:55

I would also add that cljs-oops macros generate safe-checking boilerplate code you typically want in dev mode and want it elided in advanced mode. It is hard to beat this by using aget straight.

dnolen22:11:24

You shouldn’t be using aget anyway

dnolen22:11:32

so there’s no interesting argument there

kenny22:11:42

Why no aget?

darwin22:11:49

s/aget/goog.object.get/

dnolen22:11:54

aget is only for arrays

dnolen22:11:19

people have been abusing it for years - it can stop working at anytime

dnolen22:11:35

for example

dnolen22:11:44

don’t come complaining if we write specs for this stuff and all your tests start failing

dnolen22:11:46

there’s also a plan to add type information from declared specs

dnolen22:11:54

your build will fail advanced compilation

dnolen22:11:14

if you want type checking support

kenny22:11:35

I thought accessing object properties using the bracket notation was okay?

dnolen22:11:51

@kenny if you’re writing JavaScript

dnolen22:11:00

nobody said that’s what aget does

dnolen22:11:09

what we compile to is an implementation detail

darwin22:11:03

in case of a disaster, writing your own aget replacement is a one-liner, don’t forget that we have pretty powerful require system with aliases 🙂

dnolen22:11:17

yes if you want to write bad code, nothing I say will stop you

dnolen22:11:21

but I will have no sympathy 🙂

kenny22:11:36

It seems like the tradeoff here is whether you think the time lost due to the context switch is greater or less than the time it would take to debug a problem in cljs-oops implementation.

dnolen22:11:36

I’ll take a context switch over a dependency any day

dnolen22:11:47

but your calculus may be different

kenny22:11:22

And is that because you have used convenience deps in the past which have had some sort of bug causing you to have to spend time on a problem that wouldn't exist if you had just used the built in tools?

darwin22:11:26

indeed, it has a merit to limit your dependencies and consider every new added dependency

darwin22:11:36

but I would not want to depend on other’s people externs

darwin22:11:15

and writing them seems like a step back, I’d rather write more clojurescript than javascript

darwin22:11:30

that is why I’m promoting string names and writing your own wrapping macros instead of externs

dnolen22:11:47

@kenny one huge value prop in ClojureScript which experienced ClojureScript people tend to value now is

dnolen22:11:52

Google Closure Library

dnolen22:11:05

that’s 300,000+ lines of functionality, it requires no additional dependencies

dnolen22:11:19

it’s battle tested, deployed in all of Google’s major user facing applications

dnolen22:11:34

no way some random NPM lib is as vetted

dnolen22:11:13

ClojureScript let’s you get more done with fewer deps

dnolen22:11:17

this is a good thing

darwin22:11:37

definitely, goog is a gold mine, best decision ever!

dnolen22:11:27

and to be clear

dnolen22:11:40

I’m fine with stuff like figwheel, lein-doo, cljs-devtools - all the dev time stuff rocks

dnolen22:11:53

I just don’t personally like adding things which are production deps

kenny22:11:42

Totally agree. Of course most production builds end up with lots of 3rd party deps because no one wants to re-invent the wheel.

kenny22:11:13

Anyway, thanks for the discussion 🙂

darwin22:11:05

I also agree, but in case of cljs-oops, it is not a typical library, it “disappears” in advanced mode build, by default it warns you to use static compile-time selectors only and whole dev-mode support code gets DCE-ed in advanced mode and you end up with raw aget or goog.object.get calls