This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # beginners (306)
- # boot (191)
- # bristol-clojurians (4)
- # business (3)
- # cbus (4)
- # cider (6)
- # cljsrn (51)
- # clojure (147)
- # clojure-canada (1)
- # clojure-conj (6)
- # clojure-japan (2)
- # clojure-poland (8)
- # clojure-russia (57)
- # clojure-sg (1)
- # clojurecup (1)
- # clojurescript (229)
- # core-async (4)
- # cursive (47)
- # data-science (2)
- # datomic (3)
- # emacs (6)
- # events (1)
- # hoplon (16)
- # immutant (33)
- # jobs (1)
- # ldnclj (7)
- # off-topic (25)
- # om (69)
- # onyx (7)
- # re-frame (35)
- # reagent (3)
- # yada (4)
To get figwheel to pick up new dependencies, do you need to do something other than :cljs/quit, lein clean, lein figwheel ? I'm woking through the figwheel quickstart and figwheel isn't seeing sablono when I add it.
@nathansmutz: you need to restart figwheel. There is an experimental command to add it from the REPL, but IIRC that is deprecated now
Hi guys, we are looking for a ClojureScript guy who is also looking for a team to participate in #C09TMSH7G. Let me know if you’re interested.
@maio note that if you’re at a REPL and reloading code it’s easy to run into that problem
after that you have dependency on goog.dom, without this line you can’t use it. from browser console for example
@thheller: changing from dot syntax to to normal ".-" syntax didn't do anything to help closure in advanced mode - it still garbles the closest method
@dnolen: ok, that might be the problem. It's om app with record in shared state and I'm doing
instance? after figwheel reload.
@maio I would move your records into another namespace or not use records if you’re set on live coding with Figwheel
@honza Cider + CLJS is expert level stuff from what I’ve seen so far, very few people can get that setup to work
@dnolen: actually it’s not that bad 😊 Sure it’s not as simple as it might be, but won’t call that “expert level” either
@malch not saying it can’t be made to work, but as somebody who watches nearly every ClojureScript communication channel I have a good sense of how many people struggle with it and how long they struggle with it.
@lvh: take a look at my production goog.dom object - https://www.dropbox.com/s/ojla8mc2af2hs6q/Screenshot%202015-11-18%2023.31.30.png?dl=0
@malch and I think it’s a big source of frustration because it “just works” with Clojure
my experience with getting stuff to work in one browser and then sending it to users has been less than perfect, plus I’m too lazy to write them in the first place
@dnolen: Was thinking for some time now about creating “CIDER cljs” template, which would serve as a starting point for cljs users
delaguardo: I don’t understand why that’s special though; dead code gets eliminated the same way regardless of if it’s in a clojurescript ns or a goog.whatever module
(mostly because cljs gets compiled to js before the Closure compiler does the dead code elimination
happy to see someone start a tooling page on the ClojureScript wiki for stuff like this
@lhv: https://closure-library.googlecode.com/git-history/docs/local_closure_goog_dom_dom.js.source.html#line2033, after that line you need goog.dom.getAncestorByTagNameAndClass and Element type
@dnolen: There is, actually. But it’s not in the one place. https://github.com/bhauman/lein-figwheel/wiki/Using-the-Figwheel-REPL-within-NRepl
normally this isn’t a good idea, but too many people want to accomplish the same thing
@dnolen I was thinking that public repo would be a slightly better idea. Since anyone will be able to just run “lein new” and try it out
Is it possible to write an es6 generator (`function*`) in clojurescript? I miss
<!! in core.async
hi! 👋 long time lurker. i was wondering if there had been any previous discussion about removing cljs’ dep. on
Why would you want to remove the standard library (unused parts are stripped during compilation)?
no concrete reason, just curious if it had been discussed. seemed like from the outset an unusual dependency and kind of goes against the grain of the rest of the JS ecosystem these days
Hey, is there anything special about :resource-paths when compiling ClojureScript? I’m trying to assert something about the production build in my tests, so I’m running
lein cljsbuild … to produce the js file and then running
lein doo to run my tests against Phantom. I have a macro to read the file as a resource (it’s a macro so that it’s read in Clojure). This works fine in development mode, but not in the test build 😕
fortunately (?) since it’s a compile-time thing I can reproduce with just
lein cljsbuild test once.
Caused by: java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #' which is mostly an opaque way of saying “that thing io/resource gave you was nil, so no, you can’t
I have a js object which has a
readonly maplike interface. Can I use this as a cljs map in some way, whichout converting it by hand?
It’s from the Web MIDI api: https://webaudio.github.io/web-midi-api/#idl-def-MIDIOutputMap
you could use
specify (for the constructor or specific instances) to implement the proper protocols
Where does the compiler get its resource paths from when doing macroexpansion (in Clojure, not in the bootstrapped compiler)? Is there anything else going on with that classloader? I can’t seem to use http://clojure.data.io/resource in macros being expanded for clojurescript; it doesn’t find said resources 😞
@nullptr’s talk was excellent, btw — though i disagree with some of his justifications
i see the biggest hurdle to using clojurescript in serious products being the lein + jvm + closure compiler module system + google closure libs
when asking programmers to pick up an entirely new syntax i think it’s tough having to ask them to pick up new build tools + libs
i’d love being able to use clojurescript to be as easy as using coffeescript, for instance
yeah, his attitude in the talk was “these things suck, but they’re ultimately good for you” which is totally reasonable. i agree that they’re good, but are additionally good from clojurescript itself.
But you basically want to take everything away from Clojurescript that constitutes it; I don't think that's ever gonna happen. Maybe something that looks like Clojurescript enough would make more sense for you? And by that I mean this - https://github.com/Gozala/wisp
Of course you lose things like core.async, reagent and whatnot, but you also lose the parts that you don't like.
That’s really interesting, thanks for the link. I haven’t looked at core.async, but is there an obvious reason why it doesn’t work with wisp?
Just to add in my personal and limited experience with cljs I have only really had to worry about learning lein
Well, wisp is not Clojure, so that's sort of a question like why C# lib won't work with Java, even though at first glance they look similar.
And core.async depends on implementation details of Clojure, using it's analyzer and whatnot
curious, why do you see clojure lib + compiler + lein being the best parts of clojurescript?
Maybe I phrased it wrong, what I've meant is you can't really part with it simply. You'd probably have to rewrite everything from scratch.
And I don't really like lein all that much either, I've moved over to boot and I am pretty happy with it.
something equivalent to the closure compiler is something that is still lacking in the JS ecosystem afaik. removal of unused code and cross module code motion being some of it’s most significant features.
@jaen: i’d love to get clojurescript to be usable in a webpack loader. i could write one that shells out to a jvm proc. but that’s going to blow out already slow build times on large apps
it doesn’t seems like there’s much to clojurescript which inherently tied to the jvm other than clojure itself
But if you lose Closure compiler you will end up with a couple of megs of generated code. You don't want your application to weight this much.
it’s always possible to run the closure compiler over any js code and get the same optimization, super easy with webpack.
(again, don’t know the details, just curious) i think @mrg has summed up how i think of clojurescript (as a lang) vs. the rest of the community well.
@chrislloyd: ClojureScript doesn’t actually have any problems being adopted at big companies
I have some macros to get access to Clojure-land stuff (specifically
slurp). I’m getting
nil back from
io/resource, so I’m trying to debug stuff the classpath on the Clojure side by printing stuff to stdout (with timbre, like so:
(spy name) et cetera). I’m seeing the following error when building Clojurescript:
Am I reading that correctly? It looks like stdout from the Java/Clojure side is what gets piped to the JS output?
SEVERE: /Users/lvh/Projects/rackspace/crunch/target/base+system+user+dev-common+dev-overrides/cljsbuild-compiler-2/crunch/ctk_test.js:12: ERROR - Parse error. Semi-colon expected 15-Nov-18 16:41:02 zygalski.local DEBUG [crunch.test-macros] - name => core-samples/sample1.html ^
I love ClojureScript tooling. Avoiding the npm toolchain and just using lein for everything makes things a lot simpler to manage for me. And figwheel is just amazing.
Alas, no closer to debugging my problem though. Correct dirs are on the classpath, io/resource still returning nil. Does the clojurescript compiler do anything funny to the classloader?
i love the clojurescript tooling too, figwheel+devcards is awesome just trying to think about how i can introduce om-next at my org without having to ask 100+ programmers to totally re-tool
@chrislloyd: going back to your original question, no there’s no interest at all in removing anything related to JVM beyond what we already did for bootstrapped
and bootstrapped just doesn’t solve the minification issues - there’s nothing in the JS world that can make ClojureScript generated code palatably small
I don't think you can avoid the retooling as things are. Though you might try to introduce them to boot instead of lein. It's considerably simpler to use.
Here’s what I’m trying to accomplish. I’m writing a userscript (as in Greasemonkey) with Clojurescript. That wants a very specific kind of metadata header to be present in the output JS to work. I’m trying to test that by reading:
userscript.js resource, which is just the header
2. a production built file
however, whenever I do
(slurp (io/resource ...)) from the macro, I get an exception, because io/resource is returning nil, which seems to mean that said file is not on the classpath
what I found interesting at the Conj this year was how many people told me “I started using Clojure because I tried ClojureScript and thought it was awesome"
Maybe I should just rewrite this test in plain old Clojure; but I don’t think I can avoid this for all cases, because e.g. I have some tests that rely on running in CLJS because they use the browser dom; I’m using the resource mechanism to store the HTML those tests start from
@dnolen: n wasn’t aware of
cljs-bootstrap — awesome work, basically what I was looking for
@chrislloyd: that’s just an example. but yes via
cljs.js ClojureScript can compile itself
@lvh: re: printing in cljs macro expansion I think this might do - https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/util.cljc#L177
It sounds like either the folder isn’t on the classpath or you are referencing the resource by the wrong path.
on the plus side, jaen’s excellent suggestion was actually necessary for me to see the issue properly, and it is definitely only happening with one file
hey all - im trying to figure out how to make a production build of a cljs project: https://github.com/samuraisam/om-next-starter
I'm having trouble adding a
cljs.test/assert-expr. Has anyone successfully done this? I can see the multimethod is defined here (https://github.com/clojure/clojurescript/blob/c72e9c52156b3b348aa66857830c2ed1f0179e8c/src/main/cljs/cljs/test.clj#L65-L70)
i’ve edited the project.clj file such that
lein cljsbuild once min should create a singular
main.js file - but it doesn’t
I found some info here about using multimethods defined in clj files here https://groups.google.com/forum/#!searchin/clojurescript/assert-expr/clojurescript/uFnrOlHKpTc/K0vw7qZFuOUJ but it did not seem to work for me
@bbrinck: I think you need to make a
my_asserts.clj and implement the defmethod there. Then in
(ns my-test (:require-macros [my-asserts])).
Is it still the case that
:closure-defines requires an
:optimization setting greater than
:none? (as stated in this thread by @dnolen : https://groups.google.com/forum/#!topic/clojurescript/7wAO_GzsITM )
@noonian: Thanks a bunch for the idea! I'm having some other issues getting my clj file to show up, but I think this is promising.
This seems to say imply that defines will work with
:none optimizations (final 2 paragraphs): http://www.martinklepsch.org/posts/parameterizing-clojurescript-builds.html
Hmm, I guess I'm still confused. Why would i need
Yes, but generally I like my #defines to be specified in a compiler setting file (a la
project.clj) rather than in the src code itself
@johanatan: goog-define defines a thing (with a default) that can be overridden by passing a different value to
So, you can't just use
:closure-defines without a corresponding
@johanatan: you can but then you need to manually add the jsdoc
@define comment + it will only work with
@martinklepsch: interesting. This seems a bit of a kludge to me-- it's good that it can be made to work but still not ideal (i.e., not DRY).
eh - it’s just that 390kb before all application code and other libraries is a lot for a little mobile processor to parse and execute before the app can run
@johanatan: what’s not DRY about it? are you suggesting not to have a goog-define statement at all and just use the compiler option?
goog-define is useful for providing a default value and declaring a thing in code. Google Closure defines work exactly the same way
maybe it’s not perfectly DRY but I it seems like a good pro-documentation tradeoff
But you don't need a default if the values are provided in build sections-- each build corresponds to exactly one value of the define.
I suppose the default would be nice if you forgot to place the value in one of your build sections (but that should be avoided IMO)
Well, in my case there will only ever be one define: BUILD- it will have a value DEBUG, RELEASE etc. All other divergence will hinge on the value of that one define.
Sure, but I don't have to look at them. At least until I do for whatever random incidental reason happens to pop up
I don't necessarily care how Google's code provides values to me- they can be hardcoded, have cascading defaults, anything really. As long as the value is there when I need to read it. However, with
goog-define now I'm forced to specify a default when I know that all cases will specify their own value.
@johanatan: closure defines need defaults to be able to be used from code that does not care about those defines. I.e. you don’t want to set all the 500 closure-defines in openlayers (a closure mapping lib). In an application context this might be different but I guess this is the reason.