Clojurians
#cljs-dev
<
2018-05-29
>

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

bhauman04:05:31

is there a way to indicate a system exit(1) from cljs.main -m example.test-runner ?

dnolen15:05:12

@bhauman hrm don’t we catch exceptions and exit(1)?

dnolen15:05:00

that’s where we call shutdown-agents and do the higher level stuff

bhauman15:05:12

makes sense

dnolen15:05:40

@bhauman hrm thinking about it some more not so obvious

dnolen15:05:55

since we don’t want to just catch any old exception

dnolen15:05:35

how is this handled in Clojure testing libraries?

bhauman15:05:56

ex-info :type :system-exit :value 1

bhauman15:05:13

good question

dnolen15:05:19

fine with using ex-info, but probably at least should see how this handled elsewhere

bhauman15:05:27

I'm thinking it's add hoc, first obtain a failure signal, then do something, checking leiningen

bhauman15:05:52

yeah its add hoc, hook the report function and gather the number of failures to make a decision how to exit

bhauman15:05:23

its just that we don't have the ability to supply an exit value from the javascript env

dnolen15:05:55

hrm maybe it makes sense to just have a special value

dnolen15:05:07

that you can return from the JS environment

dnolen15:05:48

:cljs.test/failure or something like that

bhauman15:05:59

:cljs.main/exit-1 ?

bhauman15:05:14

:cljs.main/exit-0

dnolen15:05:42

do we need different things though?

dnolen15:05:56

I don’t know you should have to signal exit 0

bhauman15:05:57

only the first one is neccesary

dnolen15:05:45

maybe cljs.main/error is enough?

bhauman15:05:04

yeah that would work

bhauman15:05:44

but it would only work in the --main option of course

bhauman15:05:51

which makes perfect sense

dnolen15:05:54

@bhauman then my other question is how can this work with async tests?

bhauman15:05:37

so right it wont

bhauman15:05:20

and this is where you would need a channel back to the java env like tap

bhauman15:05:22

but --main doesn't work with async anyway

bhauman15:05:02

so solving the general testing problem is a different situation

dnolen15:05:54

well not completely true not working with async

dnolen15:05:01

when we can control the process it’s not so hard

bhauman15:05:02

I was going to introduce an exit signal in figwheel and that would solve the general situation

dnolen15:05:08

basically the only case we can’t handle is browser

dnolen15:05:10

Node.js works

dnolen15:05:01

and I think maybe browser could work …

bhauman15:05:02

this was a good exploration, I'm going to add the ability to signal figwheel to system exit

bhauman15:05:15

as that will handle all cases

bhauman15:05:01

oh you could get the browser to work?

bhauman15:05:07

--main-async ?

dnolen15:05:14

stepping back a bit - one thing is we could think about is beforeunload or something like that for browser process termination detection

dnolen15:05:44

the other thing is to make test completion a special kind of browser REPL event

bhauman16:05:37

would it be better to separate the idea of system.exit and test completion?

bhauman16:05:57

or are you thinking its the same thing?

dnolen16:05:32

Well I don’t think System exit is all that useful anyway as a concept

dnolen16:05:43

main will do the right thing if the exception gets to it

dnolen16:05:01

I think we should focus on test completion as the problem worth addressing

bhauman16:05:15

yeah, it would be good to solve this problem, everyone's using node based test runners, mainly to get the right exit signal.

dnolen16:05:42

and actually I don’t think the browser termination is something to bother with - I keep forgetting that refreshing the browser w/o losing REPL is an acceptable tradeoff

bhauman16:05:19

there's running a single run with headless-chrome

dnolen16:05:50

I need to mess around with headless-chrome - that’s probably something we should just supporrt

dnolen16:05:43

(if there’s something that makes it hard to use, but perhaps it’s already fine)

bhauman16:05:27

it works fine, its just finding it and launching of it

bhauman16:05:58

@dnolen does clojure.spec.alpha get autoconverted like clojure.string ?

bhauman16:05:17

to cljs.spec.alpha ?

dnolen16:05:09

@bhauman it should yes

bhauman16:05:38

the more I reflect on the notion of an --main-async, the more it makes sense given the nature of Javascript and the variety of platforms. The env could provide a completion-callback as the first arg to (defn -main-async [callback & args])

dnolen16:05:59

hrm, I don’t like it

dnolen16:05:12

I really don’t understand what this would be useful for

dnolen16:05:26

the reason you want exit(1) is for CI stuff

dnolen16:05:11

generalizing to --main-async would only create more questions from end users

bhauman16:05:34

hmmm the -main function could return :cljs.main/async

dnolen16:05:26

I’m just not seeing the value of signaling async main

dnolen16:05:59

it’s not something that we do in Clojure and I don’t see what we would really get out of it in ClojureScript

bhauman17:05:11

async browser tests, other clojurescript tasks that are async in nature and run in the browser, hitting an api from an actual browser environment, etc

dnolen17:05:15

none of these things are different from stuff you do in Clojure

dnolen17:05:21

you create processes from main etc.

dnolen17:05:19

I can’t think of cases where you want to signal outside of testing

dnolen17:05:26

most stuff happens in REPLs

dnolen17:05:38

well interactive REPL sessions

dnolen17:05:17

to me the problem is one very specific to main usage since JVM process manages the JS process in this case

dnolen17:05:39

i.e. irrelevant for compile + run in target env

dnolen17:05:40

I’m wondering why tap> wouldn’t be sufficient here for the signal?

bhauman17:05:42

yeah that's what I was wondering, its a perfect candidate

dnolen17:05:20

gonna stew on it a bit and will probably tackle it soon - I agree it’s a big missing piece for main usage