This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-02
Channels
- # beginners (72)
- # boot (68)
- # cider (51)
- # clara (20)
- # cljs-dev (44)
- # cljsrn (7)
- # clojure (168)
- # clojure-brasil (1)
- # clojure-dev (48)
- # clojure-greece (2)
- # clojure-nl (29)
- # clojure-russia (4)
- # clojure-spec (19)
- # clojure-uk (28)
- # clojurescript (2)
- # cursive (9)
- # datascript (1)
- # datomic (105)
- # dirac (1)
- # docker (2)
- # duct (11)
- # emacs (19)
- # events (1)
- # figwheel (1)
- # fulcro (23)
- # garden (4)
- # graphql (5)
- # hoplon (46)
- # jobs (5)
- # juxt (13)
- # leiningen (6)
- # lumo (12)
- # off-topic (29)
- # parinfer (5)
- # re-frame (7)
- # reagent (6)
- # ring (2)
- # sql (5)
- # yada (6)
added Nashorn bootstrap script to Nashorn REPL, that brings standard JS event loop stuff, setTimeout etc. to Nashorn REPL
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?
>The following code duplicates the functionality of the each of the setInterval family of functions, when used in a JavaFX application.
I’m switching gears investigate allowed all the REPL -mains
to just become runners by emulating the bits from clojure.main
that make sene
@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.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.)
Perhaps https://dev.clojure.org/jira/browse/CLJS-2095 will be solved via this work.
yeah I was working on that, then I realized we should just generalize - which isn’t difficult
one nice thing is that the REPL environments initialize the target JS environment, so we can reuse most of that machinery
foo.core/-main
and pass command line args through splicing into the evaluate-form
form for that call
I think *main-cli-fn*
was kind of a workaround since we couldn’t control running ourselves (about to be false)
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.
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
.
for running, you almost always want to set :output-dir
so that would be different from Clojure running
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
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
Another thing limitation that applies which I think I’m fine with is that this means running isn’t really for advanced builds
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”
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.)
well in theory we could also do everything in memory but the reality is for many projects that’s pretty unrealistic now
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)
I know it might have been bundled in
no actually it is bundled in, because lumo
itself is using it, but it is bundled as clojure.data