This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-30
Channels
- # 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)
@dnolen what do you think of an interruptible version of cljs.js/eval
?
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
this is what I did + I had to override cljs.compiler/emits
and use with-redefs
ok. thx
@dnolen possibly forgotten in Slack history, did you look at this? https://github.com/anmonteiro/clojurescript/commit/e905d3bafa1530697d617fa77cc4174c1049296f
it's a first attempt at data-readers (no self-host support yet)
@anmonteiro seems ok, but missing collecting those files? (or did we already do that?)
@dnolen right I was thinking about that too, but Clojure does that for us already
so they're in *data-readers*
already
the only problem is that it includes the ones coming from data_readers.clj
and 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
oh.. like cljs.reader
stuff?
right, that's what I was missing, doh!
yeah, that's going to be much trickier
@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
@juhoteperi I think we get this Node.js resolution stuff working
oh nice
yeah, just need that option for custom transforms of .js
files
@anmonteiro I think we should nix that idea now
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?
oh that's awesome
@dnolen AFAICT, that means React needs to be properly consumed by Google Closure for us to deliver on that
which I'm not sure is the case
@anmonteiro you just need externs
@dnolen I tested it and if I feed all deps of React to Closure, it will give something like 100 parse errors
I hope that's true, but I think it might be a bit more complicated than that
and that only when I skip core-js dep which causes NPE
Probably Closure people will anyways work on this once they have the basics working
https://github.com/Deraen/circle-color/blob/object-assign/src/circle_color/core.cljs
object-assign is one of deps of React, and using that alone works
Cljs ns uses the deps.cljs provides to resolve object-assign
require
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
Currently they use foreign-lib logic and and written to root of output-dir
What will probably cause conflicts
@anmonteiro I though you made a ticket for this ^?
I did indeed, let me dig it
Probably enough to add :closure-lib true
to ijs map when processing modules
Maybe there are two problems
Handling the regular foreign-libs, and those using module processing
Because processed modules become Closure modules
@viebel JavaScript engines are probably the appropriate place for interruptibility. JavaScriptCore ticket 24478 also leads to same for SpiderMonkey and V8.
@mfikes do u have link to the JavaScriptCore ticket?
@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 ?
@dnolen ok - take your time
I believe it thinks ns wasn’t required or something probably because Figwheel probably doesn’t understand these kinds of deps yet
@bhauman it needs current ClojureScript master
@anmonteiro thanks 🙂
@bhauman ./script/bootstrap
and ./script/build
to install locally but I have a hunch you already know that 😉
@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
@bhauman so the really cool thing here is that we’ll have better hot loading of React than anything in JavaScript 🙂
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?