This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (32)
- # boot (15)
- # cljs-dev (200)
- # cljsjs (1)
- # cljsrn (18)
- # clojure (4)
- # clojure-austin (2)
- # clojure-spec (6)
- # clojure-uk (8)
- # clojurescript (69)
- # cloverage (1)
- # cursive (12)
- # datomic (1)
- # dirac (37)
- # emacs (1)
- # hoplon (38)
- # off-topic (3)
- # om (19)
- # om-next (1)
- # onyx (4)
- # parinfer (2)
- # perun (27)
- # protorepl (4)
- # re-frame (5)
- # rum (9)
- # spacemacs (8)
- # untangled (2)
when you eval something that has an infinite loop in a bootstrap env like planck or klipse, you stuck the browser or the process
yeah so my idea was to tweak the compiler so it emits
guard() function calls to check how much time has elapsed
@mfikes seemed interested by such a feature of the compiler when we discussed it yesterday
@dnolen possibly forgotten in Slack history, did you look at this? https://github.com/anmonteiro/clojurescript/commit/e905d3bafa1530697d617fa77cc4174c1049296f
@anmonteiro seems ok, but missing collecting those files? (or did we already do that?)
the only problem is that it includes the ones coming from
data_readers.cljc, and we might want only the ones coming from the latter
in case that it's OK to allow support for
data_readers.clj, I think we'd only need to worry about loading those files in a self-host context where there's no Clojure involved
those were the questions that arose when I was trying to make it work yesterday, which is why I wanted to run it by you before cleaning it up in a patch
@dnolen so in practice we need to explicitly look for
data_readers.cljc when finding CLJS sources, right?
I’m playing around with ES6 stuff, seems like watching and recompiling ES6 sources just works
hrm, but wouldn't that mean they'd need to transform their (e.g. JSX) code with an external tool before feeding it to ClojureScript?
@dnolen AFAICT, that means React needs to be properly consumed by Google Closure for us to deliver on that
@dnolen I tested it and if I feed all deps of React to Closure, it will give something like 100 parse errors
Probably Closure people will anyways work on this once they have the basics working
But the Circle.js uses Closure npm logic: https://github.com/Deraen/circle-color/blob/object-assign/cljsjs.npm/node_modules/Circle.js#L1
No changes necessary to Cljs compiler, just need to pass list of all files in node_modules as foreign-libs
Though we will probably want to change the path the processed modules are written in output-dir
@dnolen another thing - did u have time to take a look at my port of core.match to bootstrapped cljs - http://dev.clojure.org/jira/browse/MATCH-116 ?
I believe it thinks ns wasn’t required or something probably because Figwheel probably doesn’t understand these kinds of deps yet
./script/build to install locally but I have a hunch you already know that :wink:
yep :slightly_smiling_face: but its been a while so I appreciate the refresher thanks!
@anmonteiro actually whats the easiest way to get to a java command with the maven workflow in this demo repo? I always use lein.
I poked around a bit, it doesn’t work because Figwheel doesn’t know the name that the ES6 module will be given
in general it’s going to be quite brittle to assume anything about the names of these processed JS files
that is treat the Goog dep index as source of truth - and don’t try to add any cleverness here
since other stuff seems to be relying on the ns name instead of the URL to resolve what to load
struggling to get my dev workflow going, what version of google.closure should I be seeing?
I'm seeing : WARNING: Unsupported preprocess value :jsx for foreign library src/js/Components.js. ERROR: JSC_PARSE_ERROR. Parse error. primary expression expected at src/js/Components.js line 14 : 7
it's a slow sunday morning for me and getting the cobwebs out of my way has been difficult
Hopefully I won't have to change my namespace identity assumptions though.... It made things sooo much easier when I switched to namespaces and away from urls... relative urls hurt in so many ways especially before :main
ok, I’m just discouraging doing anything that depends on ClojureScript compiler stuff to figure this out
ok cool, just note that this isn't really about ES6 or anything - that’s just a nice example
AMD, CommonJS, Node.js - and how the real module names get constructed can’t necessarily be expected to be consistent
well the real problem with JS is we can’t rely on the classpath to simplify the problem
so there’s no straightforward translation from namespace on disk to the namespace you see in JS environment
this is all very helpful information, I haven't been following this so I really appreciate it
hrm I guess that’s the issue is ES6 supports custom resolution algorithms, and Node.js works a specific way
so mixing ES6 modules / Closure namespaces just seems to work - https://github.com/swannodette/es6-demo/blob/c61e2de45b89195458d81ae0ff67fbd9054dea9b/src/js/Components.js#L1-L2
@juhoteperi sorry maybe I missed this about your solution for NPM, does that involve creating custom packages for each thing on npm?
@juhoteperi did you look at the Closure changeset? Does it look like it wouldn’t work for some reason?
@dnolen I see a way forward :slightly_smiling_face: I have a busy week so ... probably won't have a proof of concept until the end of the week