Fork me on GitHub
#cljs-dev
<
2020-03-20
>
dnolen00:03:01

@mfikes I'm weighing just nixing the Rhino REPL as well as Nashorn in the next release

dnolen00:03:40

the issue is that Closure Library has started including more and more ES6 based versions of Closure Library namespaces

dnolen00:03:00

(the issue with Rhino specifically)

mfikes00:03:05

Both of those engines are on the way out anyway

dnolen00:03:37

and getting Rhino to work is turning out to be a huge pain, and yes Nashorn is on the way out

mfikes00:03:01

I wonder if we use Nashorn itself anywhere in the testing suite (hopefully only to actually just test it, not to run any tests)

dnolen00:03:20

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

dnolen00:03:48

if folks really want Rhino or Nashorn support they can recreate these easily as libraries

dnolen00:03:22

@mfikes I'm not sure what you want to do about Graaljs - I believe it needs to be updated

mfikes00:03:29

That's a good point... no need for them to ship with the compiler indefinitely

dnolen00:03:51

I'm ok with going with that one because it seems like Graaljs is likely to become the thing - the performance is really good

dnolen00:03:05

and their ES6 support seems pretty top notch

mfikes00:03:45

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?)

dnolen00:03:07

yeah I believe it should be minor

dnolen00:03:17

Node.js & Browser worked because they already have good ES6 support

dnolen00:03:22

no problem loading those libs

mfikes00:03:37

Is part of what you are doing is getting up to the latest Google Closure library and / or compiler?

dnolen00:03:56

the compiler side of things is already done, been done for over a month

dnolen00:03:05

but the REPL stuff has made the effort go way longer

dnolen00:03:24

@mfikes the other option is that we could just remove Graal too and you could resurrect as lib

dnolen00:03:41

I think time has shown that the only two REPLs that really matter are Node.js and the Browser

dnolen00:03:57

and it took a long time for Node.js to really be meaningful but it certainly is now

mfikes00:03:58

Yeah, that's not a bad idea

dnolen00:03:24

ok I think that simplifies maintenance a great deal

mfikes00:03:41

Yeah, shed non-critical REPL environments ๐Ÿ™‚

dnolen00:03:59

Closure Library is also potentially on the verge of churning

dnolen00:03:09

I got an email from Steve Hicks where they are weighing

dnolen00:03:21

converting everything to ES6 / TypeScript and removing the debug loader

dnolen00:03:34

if any or all of those things happen it will definitely generate a lot of work around REPLs

dnolen00:03:55

it's not the end of the world

dnolen00:03:21

but it means we would probably use their bundler and need to just roll our own code loading

dnolen00:03:47

(none the above matters diddly for compilation of course)

dnolen00:03:53

@mfikes ah your REPL tests may depend on Nashorn?

dnolen00:03:06

perhaps we should just switch that to Node.js

mfikes00:03:12

Yeah.. I think some of that stuff is actually driven by Nashorn.

dnolen00:03:14

probably not a big deal for CI?

mfikes00:03:26

Just dumping all of our energy into a quality Node.js REPL, testing, etc, makes sense

dnolen00:03:40

but you're just using shell to test nashorn it seems

dnolen00:03:47

looks like trivial to flip the repl-env over

mfikes00:03:17

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

dnolen00:03:52

hrm I don't remember what that was about?

mfikes00:03:07

I'm searching for its JIRA to be sure...

dpsutton00:03:01

will self-hosted remain a supported target?

mfikes00:03:27

^ Closed, so my memory was fuzzy in the right direction ๐Ÿ˜‰

mfikes00:03:22

self-hosted could conceivably need work with revisions to Closure... hrm

dnolen00:03:22

hrm, why do you think so?

mfikes00:03:37

(Stuff surrounding how Closure code loading works.)

dnolen00:03:05

yeah I think it would only affect the tests

dnolen00:03:43

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

mfikes00:03:53

Cool... yeah. That kind of stuff is hard to predict without just trying ๐Ÿ™‚

dnolen01:03:52

welp it's done

dnolen01:03:08

only browser and Node.js REPL now and we're on the latest versions

dnolen01:03:25

I have a feeling other REPLs may need to be updated like Figwheel not sure about that yet

dnolen01:03:54

might be a good time to check that nothing regressed w/ browser REPL / Node REPL - I didn't try a large number of things

๐Ÿ‘ 4
dominicm07:03:49

I'm probably not understanding. I thought closure targeted es3? Doesn't es6 compile too es3 via gcc? Or not in development?

lilactown09:03:15

the repl doesnโ€™t use gcc iirc

dominicm12:03:59

Oh, so it's specifically a section of cljs that is sent raw in some way? Okay, interesting. Thanks!

dnolen12:03:50

historically we never compiled JS for the REPL, only CLJS

dominicm12:03:02

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.

dnolen17:03:36

right that may change in the future, they do have a bundler thing we could use

dnolen17:03:59

I suspect there's a lot of folks using ES6 or TypeScript where that approach is already the norm

dnolen17:03:06

which why they are considering the changes

dnolen17:03:24

@mfikes reviewing the cli test, it seems we already test node - so I'm just going through and removing the remaining references

dnolen17:03:34

to graal/rhino/nashorn

dnolen17:03:48

@mfikes k pushed that, what's CI look like?

dnolen18:03:46

Figwheel seems fine w/ these changes