This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-10
Channels
- # beginners (97)
- # boot (77)
- # cider (7)
- # cljs-dev (47)
- # cljsrn (3)
- # clojure (125)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-italy (4)
- # clojure-russia (91)
- # clojure-spec (80)
- # clojure-uk (54)
- # clojurescript (92)
- # core-async (6)
- # cursive (17)
- # datomic (56)
- # hoplon (7)
- # immutant (3)
- # liberator (3)
- # luminus (4)
- # off-topic (26)
- # om (41)
- # om-next (11)
- # pedestal (3)
- # perun (3)
- # protorepl (25)
- # re-frame (32)
- # reagent (33)
- # ring (46)
- # rum (3)
- # spacemacs (5)
- # specter (82)
- # test-check (16)
- # untangled (8)
- # yada (26)
What do parse-require-spec
and parse-import-spec
do with deps
?
They use (swap! deps conj ...)
so with the change it is possible that they add duplicates to deps vector
Ah, but the patch takes care of that by using distinct
clojurescript iterators do not behave the same when there is no element left, some return nil, others throw an exception. Is it intended ? should they all throw an exception like clojure's ?
I notice PersistentVector and Subvec implement IAssociative
but don't have a -contains-key?
method. Is this intentional?
I think the way print-namespace-maps is set when starting the REPL is wrong. We are setting print-namespace-maps as a side effect of binding the init option. The "evaluate-form" call should be wrapped in a function instead: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl.cljc#L826. Patch needed ?
@tmulvaney probably not
@dnolen It matters because the evaluation of the javascript code is done outside the read-eval-print loop! Thus exceptions won't be catched
I can’t say whether it does or doesn’t work since I didn’t try it myself yet - but I’m assuming the patch author tested it as they wanted the feature
@dnolen all exceptions that can be sent by evaluate-form https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl.cljc#L493
there is a typo in the code I linked, its written (let [init (evaluate-form ...)]) instead of (let [init #(evaluate-form)])
@ewen to clarify, I’m not suggesting the code couldn’t be cleaner - but if it works it’s really not a priority
the reason this code causes me troubles is that i am developing a clj/cljs repl: https://github.com/EwenG/replique
When evaluating a form in a replique repl, if the javascript environment is not connected, instead of blocking the thread, the replique repl displays a message to the user, telling him that the javascript environment is not connected.
It is not possible anymore with the way the repl binds print-namespace-maps. They are two reasons to this:
- the code that binds print-namespace-maps is called outside the read-eval-print loop, so instead of returning a :js-eval-error or :js-eval-exception and continuing the loop, it throws an exception and breaks out of the repl function
@ewen your issue seem to be concerned about a much wider scope than the original problem
in anycase all of the REPL code assumes you can eval immediately - there’s no real consideration for other cases
@ewen the REPL namespace is meant to be reusable if for some reason you can’t use the main REPL entry point
making it easier for a few REPL developers just less important goal than not affecting tooling for thousands of users
@dnolen yes i fully agree, and the behaviour of the repl did change with this commit: the repl now blocks the thread even when passed an empty :init param. The change I was suggesting would result in having a behaviour that better match to the previous one, which would decrease the possibility to break existing tooling