This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-22
Channels
- # beginners (240)
- # boot (23)
- # bristol-clojurians (3)
- # cider (101)
- # cljs-dev (52)
- # cljsrn (17)
- # clojure (212)
- # clojure-dusseldorf (2)
- # clojure-greece (2)
- # clojure-italy (9)
- # clojure-russia (1)
- # clojure-spec (91)
- # clojure-uk (33)
- # clojurescript (164)
- # community-development (23)
- # core-async (24)
- # core-logic (9)
- # cursive (18)
- # datavis (1)
- # datomic (119)
- # emacs (13)
- # events (1)
- # figwheel (2)
- # fulcro (86)
- # graphql (1)
- # immutant (5)
- # jobs-discuss (6)
- # leiningen (19)
- # lumo (46)
- # nyc (7)
- # off-topic (23)
- # parinfer (15)
- # pedestal (3)
- # planck (32)
- # re-frame (48)
- # reagent (75)
- # ring-swagger (13)
- # rum (32)
- # shadow-cljs (402)
- # spacemacs (5)
- # specter (3)
- # tools-deps (11)
- # unrepl (20)
- # vim (135)
- # yada (3)
Some example websocket stuff to kick the tires on: https://github.com/johnmn3/repl-ws
It's midway through implementation - probably going to move all the state in the http://cljs.repl.ws namespace into the WebSocketEnv object
relevant code: https://github.com/johnmn3/clojurescript/commit/9e3edeb976df632fe9442b32a7aaa8b8948b3db0
@r0man the reason your patch doesn’t make sense to me is that we don’t use JSON for returning results to the server - it’s currently just for sending JS evals and for communication between iframes - if you can show where you think JSON is being introduced on the way back that would be helpful
There are some places in cljs.main
where you can pass multiple things, separating them by colons. Another approach that could be nice is simply allowing the argument to be supplied more than once.
One (arguably less important) example might be putting -co
in an alias (via :main-opts
), and then when you go to use that alias, if you pass -co
that would be a second instance of -co
on the command line that could be merged into the results of the first.
(A way to watch multiple paths, related to https://dev.clojure.org/jira/browse/CLJS-2681)
I also wonder a little about the use of colon as the delimiter for -co
: Since you can pass paths to EDN files, it feels a little like a path delimiter as well, and if that's true, perhaps File/pathSeparator
is natural (less problematic?) in the Windows case.
It appears that the only places clj
accepts colons to delimit things is for aliases. (So paths don't come into play there.)
The other place that might be -Scp
in the future. Presumably on Windows, clj
will accept a Windows (semicolon-delimited) classpath in that case.
TL;DR perhaps clj
has no precedent / guidance
clj does not use colons as a delimiter - the alias opts take a concatenated set of keywords (which happen to be prefixed with colons)
-Scp is expected to take a platform-appropriate path separator
OK, I'll log a couple of tickets (one for File/pathSeparator
and one for inits merging
https://dev.clojure.org/jira/browse/CLJS-2687 https://dev.clojure.org/jira/browse/CLJS-2688
@dnolen Any idea if goog.require("some.cljs.ns");
should work from some CJS/ES6 modules? Someone mentioned on Clojureverse this used to work, but after Closure update this breaks due to those goog.require calls we now generate. Fix might be simple, but not sure if this should work.
Looks like Closure will detect those goog.require calls during module processing and adds the required modules to the module dependency information.
@juhoteperi goog.require
is no longer allowed in ES6. but you can do import cljs from "goog:cljs.core"; cljs.assoc(null, "foo", 1);
Doesn't work with Cljs currently because our code tries to resolve import calls into node modules
We should filter goog:
modules there, but I guess there would be other problems after that
Because we call Closure for module-processing with only the foreign-libs/node_module files, Closure can't resolve the requires to Cljs.core or other Cljs code (guess anyway)
Oh, nice, I was wrong. With simple change to filter code in our Node modules resolve logic, it seems to work.
Fix for goog:
module imports: https://dev.clojure.org/jira/browse/CLJS-2689
Works for :optimization :none
but :simple
etc. fails 😕
And fix to remove unncessary goog base requires from module processed files: https://dev.clojure.org/jira/browse/CLJS-2691
After these, I think this works the same as in 1.9. Optimization still fails if module-processed files use Cljs namespaces that aren't required by any other Cljs namespace, but that happened before also.
When Clojure's range was converted from a lazy seq to a LongRange
in CLJ-1515, LongRange
was made to implement IChunkedSeq
. On the surface it would seem that doing the same to ClojureScript's Range
could result in some perf benefits (like map
over a the result of a range
call). I wonder if this has been explored and rejected as not being true.
I bet it would be faster. Compare
(time (apply + (filter even? (map inc (vec (range 1e6))))))
with the same but without converting to a vector to get the chunks
(time (apply + (filter even? (map inc (range 1e6)))))
just a note that there were many dragons behind this change
you can reason from the large number of patch attempts :)
balancing the perf concerns of reducible, sequence, and chunked sequence traversal (all of which are possible and may even interleave) while also avoiding potential overflow/underflow cases was a surprisingly narrow path
But that was the pattern with reducible sequence generators. You do the hard work so others can port it. 🙂
I did not expect to spend several months exploring ways to count