This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-22
Channels
- # arachne (8)
- # bangalore-clj (1)
- # beginners (72)
- # boot (95)
- # braveandtrue (5)
- # business (1)
- # capetown (1)
- # cider (180)
- # cljs-dev (8)
- # cljsrn (20)
- # clojure (104)
- # clojure-art (1)
- # clojure-brasil (8)
- # clojure-czech (1)
- # clojure-greece (15)
- # clojure-korea (13)
- # clojure-poland (2)
- # clojure-russia (53)
- # clojure-sg (5)
- # clojure-spec (60)
- # clojure-uk (35)
- # clojurescript (186)
- # community-development (3)
- # core-async (24)
- # cursive (18)
- # datascript (11)
- # datomic (39)
- # devcards (4)
- # emacs (2)
- # events (1)
- # funcool (23)
- # hoplon (148)
- # juxt (1)
- # ldnclj (2)
- # luminus (1)
- # off-topic (22)
- # om (27)
- # onyx (35)
- # overtone (2)
- # pedestal (7)
- # perun (8)
- # protorepl (2)
- # rdf (6)
- # re-frame (15)
- # reagent (2)
- # ring-swagger (10)
- # untangled (54)
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?
In Clojure, (repeat 1.3 :a)
=> '(:a). In ClojureScript, this yields '(:a :a). Is this a known inconsistency? (Same goes for take, drop, etc)
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
you need to gensym
a symbol
Thank you
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
I think it is cljs.spec.impl.gen
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])
@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
oh, I see, thanks for the explanation
@doglooksgood can you clarify what you are asking?
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?
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: …
@doglooksgood I think you’re mixing up a few things here
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
.
@doglooksgood I would bring up the idea in #cljsrn 🙂
just released Lumo 1.0.0: https://twitter.com/anmonteiro90/status/801124209745338368
@anmonteiro nice on the socket REPL bit
@dnolen it's a very cool addition that I'm really excited for. credit to @jmf though, who put a PR together
everyone go :thumbsup: this -> https://github.com/Homebrew/homebrew-core/pull/6885#issuecomment-262317610
@anmonteiro @mfikes what are the differences between lumo and planck use cases?
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?
@misha Lumo covers more platforms and supports the Node ecosystem, and has implemented most of the stuff in Planck
@misha Planck currently has some ClojureScript wrappers around I/O facilities, etc. but Lumo will likely gain those as well.
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.
@mlatu the most popular React bindings should work fine with React Native, Om or Reagent - it’s possible others
@mlatu there’s a channel dedicated to React Native - #cljsrn, might want to ask questions there
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
@misha The question of whether to use Planck or Lumo will likely drive a lot of people crazy 🙂
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
@misha merging into a single project is a non-goal since the target JS platforms are different
(and that's a good thing!)
@misha: its maybe subtle in the sense of when u write a word doc on either mac or win and its ok
But becomes less subtle if you want to do syscalls and then those are different on the platforms
What i mean is (= 3 (+ 1 2)) on both but if you're doing something dependent on the ecosystem then it matters
@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?
And generally you can write your code such that the parts that are agnostic of things can be reused elsewhere
@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
(I am talking about UX, not platforms: things like autocompletion, parinfer integration, colors, etc.)
@misha: having multiple ones as opposed to merging the ones ppl make or killing some of them?
@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
I think doing something generic like you’re describing is probably way more work then it sounds
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
@dnolen seeing very smart people not delivering this working on it that long - is discouraging for compiler/platforms noob like me
@misha people work on what they want to work - and usually whatever that is 10X the amount effort everyone else perceive it to be
@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
@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
@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 )
@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
one day this might become a reality: https://github.com/binaryage/cljs-devtools/issues/11, one REPL to rule them all 😛
@misha too much? Its 1 plugin on Atom, then however you install Planck/Lumo. Way easier than some intense emacs config file, imho
@mikebelanger either you are asking me to switch to atom, or I did not fully understand the solution
@misha yeah the first one 🙂
@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!
@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.
@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?
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
@borkdude depends on the platform you're on?
I'd probably go with Transit + some compression algorithm. lzw seems promising
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).
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
also try to test it under Canary, DevTools has been under heavy development, so some things might be fixed (and others broken again :)
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.
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
using exceptions in non-exceptional situations is a code smell, this sounds to me as a poor choice of libraries in the first place
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
ah. I often need to enable it because I get better exceptions when working with async calls
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?
Is this the best way to search google closure? http://google.github.io/closure-library/api/
@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.
It’s just my recommendation after years of working on projects. I never pull in convenience deps for production.
dependencies always need vetting and I’m not going to spend anytime vetting anything that has a built-in solution in ClojureScript itself
you can of course figure out this lesson the hard way yourself - and you’re welcome to it 🙂
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.
nobody wants to write code like this by hand 😉 https://github.com/binaryage/cljs-oops/blob/master/test/transcripts/expected/oget_dev.js
don’t come complaining if we write specs for this stuff and all your tests start failing
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 🙂
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.
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?
indeed, it has a merit to limit your dependencies and consider every new added dependency
and writing them seems like a step back, I’d rather write more clojurescript than javascript
that is why I’m promoting string names and writing your own wrapping macros instead of externs
@kenny one huge value prop in ClojureScript which experienced ClojureScript people tend to value now is
I’m fine with stuff like figwheel, lein-doo, cljs-devtools - all the dev time stuff rocks
Totally agree. Of course most production builds end up with lots of 3rd party deps because no one wants to re-invent the wheel.
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