This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-24
Channels
- # arachne (3)
- # beginners (39)
- # boot (3)
- # cider (91)
- # cljs-dev (56)
- # cljsrn (4)
- # clojure (267)
- # clojure-dusseldorf (1)
- # clojure-estonia (1)
- # clojure-greece (2)
- # clojure-italy (6)
- # clojure-nl (2)
- # clojure-russia (18)
- # clojure-spec (27)
- # clojure-uk (136)
- # clojurescript (19)
- # core-async (2)
- # cursive (6)
- # datomic (17)
- # emacs (2)
- # fulcro (86)
- # graphql (4)
- # hoplon (13)
- # jobs-discuss (7)
- # jobs-rus (1)
- # keechma (34)
- # keyboards (7)
- # leiningen (5)
- # luminus (4)
- # lumo (8)
- # off-topic (13)
- # om (6)
- # onyx (26)
- # re-frame (22)
- # reagent (1)
- # reitit (2)
- # remote-jobs (8)
- # ring (3)
- # ring-swagger (5)
- # rum (8)
- # shadow-cljs (45)
- # specter (6)
- # unrepl (16)
- # yada (15)
@bozhidar I’m going to split orchard.complete/complete
into two fns, one for and the other for
. For one thing, they take different parameters.
Orchard also doesn’t know if the completion environment is or
; it relies on the client to tell it (by passing in
cljs-env
parameter).
So TBH I’m not sure what value orchard.complete
provides. The client might as well use compliment
and cljs-tools
directly.
I think the latter is better. In particular for completions the REPL itself could provide specific implementations. Lumo, Planck or closh all provide their own completions.
I think that orchard
is really just a container of small utils and therefore I would do the split there and let client code decide how to hook it up.
i think he meant the latter of the two choices to let orchard.complete handle completitions or just let the client code directly ask compliment or cljs-tools. ie, just let cider ask compliment or cljs-tools rather than go through orchard
Yes I meant let the tool call the right thing. This actually is valid not only for cider but for inf-clojure
😄 as well.
There was a mini-debate to define whether the "platform" dispatch should be inside orchard
or not. My 2c opinion is no ...but it is 2c of course.
I don’t think wrapping compliment in orchard
adds a lot of value as well, but in general I do believe that cljs-tooling
should simple be merged with it. Even at this point you can say that cider-nrepl
doesn’t really have completion code in itself.
@U0C8489U6 I disagree with the “small utilities” part, though. The goal at the end of the day is to provide an API to provide CIDER-like functionality for any client, regardless of how they decide to wrap orchard
. E.g. if this was on the classpath for inf-clojure
it could just eval a ton of functions optimized for dev tools directly and provide many extra features easily. Right now this would be just a matter of injecting it transparently when inf-clojure
is invoked inside of a project (and the REPL is a Clojure one). I do want to provide more cross-platform functionality in it, though.
Agree with you, small utilities was wrongly worded 😉
@qqq I'm guessing your're using flycheck? If so then it'll be clojure-mode/cider's integration with that. If so, you could look at the variable flycheck-enabled-checkers
to see what it's currently set to
Apparently, if I execute via C-x C-e, and the repl has a warning, then the expr gets the yellow squiggly line.
FYI - the relevant code is here https://github.com/clojure-emacs/cider/blob/be2341d93870a1f95321aa72b25516b71bb04fe5/cider-interaction.el#L1087
Generally highlighting errors and warnings seemed desirable for everyone, therefore the lack of configuration options for this.
i am getting this error when trying to run cider-nrepl
tests (clj) locally
Picked up _JAVA_OPTIONS: -Xmx2048m -Xms512m
Exception in thread "main" java.io.FileNotFoundException: Could not locate orchard/apropos__init.class or orchard/apropos.clj on classpath., compiling:(cider/nrepl/middleware/apropos_test.clj:1:1)
at clojure.lang.Compiler.load(Compiler.java:7239)
at clojure.lang.RT.loadResourceScript(RT.java:371)
nope, not that. cider-nrepl
tests are referring to orchard namespaces. don’t think that will work when you are running lein with-profile +1.8,+plugin.mranderson/config,+test-clj test
or similar as orchard stuff is inlined
the good news that after commenting out all orchard related tests and playing with mranderson a bit to inline a not “resolved” dep graph (so transient deps are duplicated all over the graph) the tests are passing
i have not checked how much bigger the uberjar gets or how slower cider-nrepl gets either
The bad news is that even if I remove the explicit ns in this test you mentioned it still fails, which puzzles me.
I keep referring to all sorts of libraries in test bodies - not sure how I’m supposed to avoid it if I need those functions in the tests.
modified: test/clj/cider/nrepl/middleware/apropos_test.clj
modified: test/clj/cider/nrepl/middleware/classpath_test.clj
modified: test/clj/cider/nrepl/middleware/info_test.clj
modified: test/clj/cider/nrepl/middleware/inspect_test.clj
modified: test/clj/cider/nrepl/middleware/refresh_test.clj
modified: test/clj/cider/nrepl/middleware/track_state_test.clj
modified: test/clj/cider/nrepl/middleware/util/instrument_test.clj
tbh you can argue that your tests should not know about your library’s dependencies and should only use the API of your lib
yeah, true. can’t you kinda move those tests or the gist of them to orhcard itself. have not really tried to understand them to be fair
Seems to me that CIDER should only test the transport. Functionality should be tested in Orchard.
It will require some work. It’s completely doable, but I just won’t have time for this soon.
fair. i managed what i wanted: have a running test set which i can use to prove that mranderson changes are good
and i will also have refactor-nrepl
tests for the same thing. so i am good. no pressure
no reason to shield from other people's code if they aren't ever going to touch other people's code?
ah, we should have a dir locals file that cranks CIDER up with the right profiles for testing when developing so the CIDER test runner can run them
then we wouldn't have to worry about all of the people wondering why there don't seem to be any tests run with lein test
I’ve fixed 3/8 of the failing tests, but I have to wrap it for today and I’d love to solicit some help from all of you https://github.com/clojure-emacs/cider-nrepl/issues/489 Fixing those shouldn’t be hard/take long. Thanks in advance!
just for the curios. here is cider-nrepl
’s not resolved deps graph (without org.clojure/java.classpath
as a first level dependency)
{[cider/orchard
"0.1.0-20180123.122522-8"
:exclusions
[[org.clojure/clojure]]]
{[org.clojure/java.classpath
"0.2.3"
:exclusions
[[org.clojure/clojure]]]
nil,
[org.clojure/tools.namespace
"0.3.0-alpha4"
:exclusions
[[org.clojure/clojure]]]
{[org.clojure/java.classpath "0.2.3"] nil,
[org.clojure/tools.reader "0.10.0"] nil},
[org.tcrawley/dynapath "1.0.0" :exclusions [[org.clojure/clojure]]]
nil},
[cljfmt
"0.5.7"
:exclusions
[[org.clojure/clojure] [org.clojure/clojurescript]]]
{[org.clojure/tools.reader "1.0.0-alpha4"] nil,
[rewrite-clj "0.5.2"] nil,
[rewrite-cljs "0.4.3"] nil},
[cljs-tooling "0.2.0" :exclusions [[org.clojure/clojure]]] nil,
[compliment "0.3.5" :exclusions [[org.clojure/clojure]]] nil,
[fipp "0.6.12" :exclusions [[org.clojure/clojure]]]
{[org.clojure/core.rrb-vector "0.0.11"] nil},
[mvxcvi/puget "1.0.2" :exclusions [[org.clojure/clojure]]]
{[fipp "0.6.10"] {[org.clojure/core.rrb-vector "0.0.11"] nil},
[mvxcvi/arrangement "1.1.1"] nil},
[org.clojure/tools.namespace
"0.3.0-alpha4"
:exclusions
[[org.clojure/clojure]]]
{[org.clojure/java.classpath "0.2.3"] nil,
[org.clojure/tools.reader "0.10.0"] nil},
[org.clojure/tools.reader "1.1.1" :exclusions [[org.clojure/clojure]]]
nil,
[org.clojure/tools.trace "0.7.9" :exclusions [[org.clojure/clojure]]]
nil}
@bozhidar @benedek I’m not sure why we can’t use Orchard in the tests. Why not run tests w/out the mranderson
profile?
But I do think that, as a long-term goal, CIDER should only test client functionality: https://clojurians.slack.com/archives/C0617A8PQ/p1516828054000552?thread_ts=1516815558.000036&cid=C0617A8PQ
u can run them w/o mranderson ofc. but running them w/ it makes sure that it will work as it is distributed to its users
We’ve a sort of 🐔-and-🥚 problem here: many namespaces, e.g. info
, have not been ported to Orchard. Their tests, therefore, include tests for things that should be moved into Orchard. We can’t very well remove Orchard dependency when some of the functionality is in Orchard and some in cider-nrepl
.
My vote is for running tests w/out mranderson
, at least until the Orchard port is complete. I can’t think of any reason why this’d be a problem. @benedek What is a scenario in which not testing w/ mranderson
could lead to tests passing on CI but the artifact not working for the user?
Philosophically, there should be nothing we cannot use in the tests that we use in the src. mranderson
’s impact should purely be on the distribution of the artifact--we apply it to prevent tooling deps from affecting user’s project deps. For mranderson
to impact the way we develop and test the project is an anti-pattern.
what you really test if you test w/ mranderson is that everything works fine with inlined deps. there are corner cases mranderson does not handle (well). re. antipattern: I hear you, you have a point there, on the other hand this forces you to only refer to your lib's API in your tests, makes stubbing more difficult these are essentially good things ;)
I don't get the "making stubbing more difficult is good" part. Yes, cider-nrepl
tests should only test cider-nrepl
API--that doesn't mean the tests shouldn't be able to make use of functions in a dep.
The other option would be to have mranderson
rewrite the namespaces in test files. In any case, src and test should have access to the same deps.
I’ve created https://github.com/clojure-emacs/cider-nrepl/pull/493 to remove mranderson
from test profiles.
fair. but extra care is needed at release time so no broken inlined version of the artifact gets shipped
what workarounds do people have for cider/emacs freezing when printing long-sequences of data?
disabling font-lock-mode only goes so far for me. it takes ~20 very-long-feeling seconds to print 2 megabytes of data to the terminal.
cider-interrupt
doesn't seem to work for printing long strings.
things like this? https://github.com/clojure-emacs/cider/issues/1934