Clojurians
#cljs-dev
<
2018-02-02
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

dnolen11:02:02

added Nashorn bootstrap script to Nashorn REPL, that brings standard JS event loop stuff, setTimeout etc. to Nashorn REPL

thheller12:02:26

the article you linked in the bootstrap file suggests that this is the preferred method in JFX applications. might be better to use something none JFX related?

thheller12:02:32

>The following code duplicates the functionality of the each of the setInterval family of functions, when used in a JavaFX application.

thheller12:02:45

also from 2013 might not be totally current

thheller12:02:43

should be fine but maybe starting the entire JavaFX machinery is overkill?

dnolen12:02:31

it doesn’t seem to take that long and my laptop is very slow

dnolen12:02:18

but happy to see an better thing - implementation details

dnolen12:02:28

I’m switching gears investigate allowed all the REPL -mains to just become runners by emulating the bits from clojure.mainthat make sene

mfikes12:02:47

@dnolen That's awesome. Then you could write ClojureScript scripts that are easily executed:

clj -m cljs.repl.node foo.cljs
(especially if -main is supported somehow) or kick off unit tests in Node, etc.

mfikes13:02:10

Additionally if it is feasible to honor *main-cli-fn* this is useful. (https://dev.clojure.org/jira/browse/CLJ-2316 is a similar relevant issue for Clojure.)

dnolen13:02:40

@mfikes yeah I’m making this generic for all the current REPLs, not just nashorn

mfikes13:02:57

Cool. Exciting consequences. :slightly_smiling_face:

dnolen13:02:09

yeah I was working on that, then I realized we should just generalize - which isn’t difficult

dnolen14:02:02

one nice thing is that the REPL environments initialize the target JS environment, so we can reuse most of that machinery

dnolen14:02:36

runners are just a degenerate case of REPLs I guess

dnolen14:02:36

@mfikes I suppose for -m we could just followed the convention

dnolen14:02:33

foo.core/-main and pass command line args through splicing into the evaluate-form form for that call

mfikes14:02:00

Yeah. Checking to see if Planck does anything of interest for -m...

dnolen14:02:32

I think *main-cli-fn* was kind of a workaround since we couldn’t control running ourselves (about to be false)

dnolen14:02:52

is there something you have in mind here with regards to support?

mfikes14:02:40

Perhaps *main-cli-fn* is of limited value. I found it useful on Linux for shebang scripts because you can't put extra arguments on the shebang line. FWIW, I think *main-cli-fn* support could be deferred to later if decided it was really needed.

dnolen14:02:26

java -jar cljs.jar -m cljs.repl.nashorn -e "(+ 1 2) (+ 3 4)" works now on master

mfikes14:02:25

For -m Planck first dynamically evaluates a require on the namespace symbol, and then does a (var -main) to get that var, and then does an apply on that var to the command line args. Without thinking about it deeply, I wonder if there are challenges in the non-self hosted implementation of this. Perhaps you've fought with it already @dnolen and have solved how to do -m.

dnolen14:02:55

@mfikes well in the non-bootstrapped context it’s a bit simpler

dnolen14:02:03

we have the args, and we can evaluate whatever expression we want

mfikes14:02:22

Ahh right, you have Clojure available

dnolen14:02:34

yes, I do have some questions that require feedback, back shortly

dnolen14:02:51

ok I have a bit more time

dnolen14:02:31

one issue is that ClojureScript is “compile-centric”

dnolen14:02:15

for running, you almost always want to set :output-dir so that would be different from Clojure running

dnolen14:02:23

-o & --output-dir ?

dnolen14:02:11

my assumption is that for most cases of running you either don’t care what the output-dir is and are fine the REPL one or you want to set it to an existing one

mfikes14:02:22

Yeah, for coal-mine I ran into exactly that problem and ended up using .coal_mine_out just to satisfy the need for an out dir

dnolen14:02:40

Another thing limitation that applies which I think I’m fine with is that this means running isn’t really for advanced builds

mfikes15:02:41

For Planck and Lumo, I think the analogous idea is the cache directory. They both don’t require one since everything can be done in RAM, but if you want to cache output, they let you specify it via some non-standard options, or default to .planck_cache and .lumo_cache respectively if you pass -K. Which is another way of saying, “I don’t care, just make a hidden directory for me”

mfikes15:02:56

Yeah, I think :none is probably fine for running scripts. (If you try to do :advanced or some such, you lose the “low-latency” benefit associated with scripting pretty quickly, unless you have things cached.)

dnolen15:02:05

well in theory we could also do everything in memory but the reality is for many projects that’s pretty unrealistic now

mfikes15:02:46

I wonder if using the existing things like .cljs_node_repl could cause any problems

dnolen15:02:45

that’s already the case now, we just use the REPL defaults for the runners

dnolen15:02:55

but we definitely need a knob

richiardiandrea20:02:25

sorry to ask here, I will investigate more for sure, but is there any obvious reason by I get this in lumo?:

No such macros namespace: cljs.data, could not locate cljs/data.clj or cljs/data.cljc in file pjstadig/macro.cljc
	 (new)
	 Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2024:72)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2660:92)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (NO_SOURCE_FILE <embedded>:2659:92)
	 (NO_SOURCE_FILE <embedded>:5662:162)
	 Object.lumo.repl.load_other (NO_SOURCE_FILE <embedded>:6471:378)
	 lumo.repl.load (NO_SOURCE_FILE <embedded>:6475:96)
	 Function.cljs.js.require.cljs$core$IFn$_invoke$arity$5 (NO_SOURCE_FILE <embedded>:5664:77)
	 (NO_SOURCE_FILE <embedded>:5699:463)
	 (NO_SOURCE_FILE <embedded>:5663:394)

richiardiandrea20:02:40

I know it might have been bundled in

richiardiandrea20:02:02

no actually it is bundled in, because lumo itself is using it, but it is bundled as clojure.data