This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-03
Channels
- # admin-announcements (241)
- # beginners (53)
- # boot (134)
- # cider (20)
- # clara (3)
- # clojure (170)
- # clojure-argentina (13)
- # clojure-brasil (1)
- # clojure-canada (3)
- # clojure-italy (9)
- # clojure-nl (3)
- # clojure-russia (55)
- # clojurescript (115)
- # code-reviews (18)
- # cursive (8)
- # datomic (14)
- # events (8)
- # hoplon (51)
- # immutant (38)
- # jobs (8)
- # ldnclj (11)
- # melbourne (6)
- # off-topic (2)
- # om (5)
- # onyx (9)
- # re-frame (3)
- # reagent (8)
- # sneer-br (1)
- # sydney (1)
- # testing (14)
has anyone built clojurescript with the latest google closure that can handle UMD modules? (https://github.com/google/closure-compiler/commit/aa0a99cf380b05b2185156735d023b6fa78ec4ac) I tried building the latest clojurescript, but the part about bootstrapping with the latest of google closure didn't work. maybe I'm doing it wrong.
Upgrading to ClojureScript 1.7.122 seems to have broken figwheel 0.3.7/0.3.8. I get a not required: (“/applicationname/core.js”)
when the main cljs source is modified. It’s all fine with 1.7.107. Anyone else?
@ricardo: when reporting errors it’s usually more useful to give complete stack traces and describe whether they are in the browser or happened during compilation. If it’s the case there isn’t a stack trace then say so
@dnolen: Haven’t reported it since I’m not sure if it’s an error or a known incompatibility. It’s also not an exception - just figwheel reporting that it doesn’t need to load a file after rebuild since it doesn’t believe it was required.
Similar to this: https://github.com/bhauman/lein-figwheel/issues/202 Only that in that issue report, it was a case of the namespace not having been required on core.
@ricardo not talking about reporting, just that more information is a good thing, and I see people consistently just say “it doesn’t work”. when reporting problems report more not less information
@dnolen: any schedule for updating closure-library?
@dnolen: ignore , seeing you just bumped it
@ricardo: I looked back at the ClojureScript change log and I don’t see anything obvious. One change that broke some people unintentionally was making clojure.string/replace
match Clojure’s version.
thanks!
@martinklepsch: bumped the compiler, do you also need a library bump?
@dnolen: Understood. In this case, that’s all the information so far. figwheel just doesn’t re-load the main namespace if I’m using ClojureScript 1.7.122, reporting it’s “not required”.
@dnolen: uh, yeah. actually library was the more relevant part
They added file upload progress events
@martinklepsch: is there some recent change you want?
https://github.com/google/closure-library/commit/1e0c8103ae97a0e568e63bf5d6906597b25a4544
@martinklepsch: cutting a release of GCL now and will release to Maven today.
@dnolen: btw, did you see the @-mentions on github? Is that a valid way to ping you about such stuff?
@dnolen: sweet
@martinklepsch: I always check my @-mentions, I’m also always logged into IRC on my phone and I get pings there.
ok, wasn’t sure if you got the github ones
I often have a problem compiling clojurescript on windows. I get
java.lang.IllegalArgumentException: character to be escaped is missing
at java.util.regex.Matcher.appendReplacement (:-1)
I'm currently experiencing this with the cljs-ajax
library, but someone else has found it in chord (https://github.com/jarohen/chord/issues/43). I suspect it's a Windows problem. The problem goes away with :optimizations :whitespace
instead of :none
, but that's no good for figwheel. Seems to be fixed in current pre-release versions.@martinklepsch: GCL releases going out
@dnolen: ok, good to know, thanks!
@dnolen: GCL is going to maven central right?
@ricardo: in the meantime you might want to annotate your main namespace with ^:figwheel-always and restart the build process
@conan: Are you trying to compile the cljs-ajax
library from source, or is it part of the project you are trying to compile? I can see if I run into any problems on my Windows setup.
It's part of the project I'm trying to compile, I've just used it as a dependency in the normal way.
I wouldn't worry about it too much, having tried the latest pre-release version of clojurescript I don't experience the problem, so it's presumably been fixed.
Oh yeah, the newer versions fixed a different Windows problem for me
It's also possible to get round it by downgrading to an earlier version of clojurescript.
of course, my figwheel isn't working at all at the moment, which is a much bigger problem! figwheel on windows is pretty much a lost cause at the moment unfortunately.
@conan: How so? I've been running on figwheel for months without any problems, running on the newest release candidate right now with no issues
@ricardo: can't seem to reproduce with cljs 1.7.122. Please try 0.3.9-SNAPSHOT and see if you still have the problem.
@ricardo: one thing to check in the dev console is figwheel.client.file_reloading.provided_QMARK_('example.core')
(with your ns of course) and see if it returns true
I can try and corral it a bit more with 0.3.7 later, but I guess it’s good that it seems to have been something peculiar here.
@shaun-mahood: about once a month i hit a breaking problem in windows. currently it's not printing any compilation output to the console (despite compiling the files), and the browser can't reload changed files so i have to refresh the page. this same configuration works as-is for my colleagues when checked out from git on osx or linux. that's the general story i find: what works for others doesn't work on windows. if i start a project myself on windows then it's fine, but as soon as a user of another OS gets involved, things start breaking for me.
sadly there is no useful output ever, so it's very difficult to debug. i generally fire up a VM and run it in linux, because the time taken to constantly fix things on windows is too great.
don't get me wrong - it's an extremely powerful tool trying (mainly successfully) to do a lot of awesome stuff - but that complexity makes it difficult to fix when it breaks.
@conan: Strange. I know for my projects I'm the only developer and it is all Windows, so maybe that's where the problem is. If you ever run into any problems that you can share, let me know and I will be happy to test them on my machine and dig in to them a bit.
Anyone knowing how to write a schema for “a set of strings” with th-ing/validate (https://github.com/thi-ng/validate/blob/master/src/cljx/thi/ng/validate/core.cljx) ?
Can macros in Clojure write out cljc? I’d like to write a macro which expands to a match
expression that can be used in clojure and clojurescript code
so I can write the macro in a clj file… but it needs to expand to cljc syntax or something like that
the macro itself needs to know whether its expanding as a clojure file or a clojurescript one
Found it: {:notifications {:* (v/string)}}
it feels like it’d be sufficient if there was just a runtime global flag like *destination*
probably not.. it’s likely a relatively rare use case—but a significant detractor from cross platform macro use
@tel: you said that ^:figwheel-no-load wasn't working for you is that still the case?
this was at the same time I was on 3.7 and facing issues with interaction between weasel and figwheel
With module support in cljs will we be able to use native :require
in node instead of (def fs (js/require "fs”))
?
@andrewh: @clojuregeek said you were here
@andrewhr: I'm thinking about doing a CLJS equiv to http://dev.clojure.org/jira/browse/CLJ-1449
I though that some issue existed, but after talking a bit with @clojuregeek I believe it was a mistake from my part... so no, no ticket AFAIK
:thumbsup:
I'm getting a warning WARNING: Use of undeclared Var domkm.silk.pattern/*assert*
but it looks like ClojureScript defines *assert*
(https://github.com/clojure/clojurescript/blob/1b7390450243693d0b24e8d3ad085c6da4eef204/src/main/cljs/cljs/core.cljs#L39-L41) What's going on?