This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-20
Channels
- # admin-announcements (1)
- # announcements (9)
- # aws (11)
- # babashka (33)
- # beginners (125)
- # calva (20)
- # cider (18)
- # clj-kondo (7)
- # cljs-dev (73)
- # clojure (72)
- # clojure-europe (18)
- # clojure-italy (13)
- # clojure-nl (13)
- # clojure-uk (9)
- # clojurescript (22)
- # core-async (7)
- # cursive (1)
- # data-science (25)
- # datomic (22)
- # duct (32)
- # emacs (13)
- # graalvm (5)
- # hoplon (16)
- # juxt (6)
- # kaocha (8)
- # leiningen (3)
- # malli (11)
- # meander (12)
- # off-topic (18)
- # pathom (109)
- # pedestal (5)
- # rdf (10)
- # reagent (1)
- # reitit (12)
- # shadow-cljs (27)
- # spacemacs (5)
- # sql (9)
- # tools-deps (7)
@mfikes I'm weighing just nixing the Rhino REPL as well as Nashorn in the next release
the issue is that Closure Library has started including more and more ES6 based versions of Closure Library namespaces
and getting Rhino to work is turning out to be a huge pain, and yes Nashorn is on the way out
I wonder if we use Nashorn itself anywhere in the testing suite (hopefully only to actually just test it, not to run any tests)
I think we've shown that we can support many different environments but as Closure changes - keeping everything up to date is becoming a bear
if folks really want Rhino or Nashorn support they can recreate these easily as libraries
@mfikes I'm not sure what you want to do about Graaljs - I believe it needs to be updated
I'm ok with going with that one because it seems like Graaljs is likely to become the thing - the performance is really good
I can take a look at Graaljs. (You're planning on cutting a release, I assume and update for Graaljs would be needed for that right?)
Is part of what you are doing is getting up to the latest Google Closure library and / or compiler?
@mfikes the other option is that we could just remove Graal too and you could resurrect as lib
I think time has shown that the only two REPLs that really matter are Node.js and the Browser
if any or all of those things happen it will definitely generate a lot of work around REPLs
but it means we would probably use their bundler and need to just roll our own code loading
The only reason I may have set it up to use Nashorn is that odd issue with respect to waiting for termination under Node.js
It could involve hopefully minor things like https://github.com/clojure/clojurescript/commit/b31a9a9baec5401813e0f994c78a6f1c6db67a3c#diff-b70a89257109f2544a6abd4bdaf2b3c8
but my sense is that lot of users outside of Google probably depend on the debug loader - so we'll see - they might move it off to a contrib thing or something
I have a feeling other REPLs may need to be updated like Figwheel not sure about that yet
might be a good time to check that nothing regressed w/ browser REPL / Node REPL - I didn't try a large number of things
I'm probably not understanding. I thought closure targeted es3? Doesn't es6 compile too es3 via gcc? Or not in development?
Oh, so it's specifically a section of cljs that is sent raw in some way? Okay, interesting. Thanks!
Oh. I understand now. So it's the closure library that has es6, and it's all gcc compatible es6. But we don't happen to run that through gcc. Got it.
I suspect there's a lot of folks using ES6 or TypeScript where that approach is already the norm