Fork me on GitHub
#cursive
<
2019-05-15
>
ikitommi05:05:55

Hmm.. for some reason, when loading reitit.core ns into Cursive, it shows a weird dependency error. I don’t see any error and it compiles ok.

ikitommi05:05:30

oh, there is a checkouts in one of the example projects which seems to be found in the classpath. hmm.

ikitommi04:05:30

@cfleming it seems than all checkouts are handled as part of a classpath even if they are not. in reitit, there are /examples, which have checkouts for the main modules, which causes the weird dependency error. Something has changed? Using the latests version of both idea & cursive.

cfleming04:05:31

@U055NJ5CC I don’t think anything has changed with that, but I’ll check it out. Should I be able to repro this just checking out reitit, starting a REPL and loading the reitit.core ns into it?

ikitommi04:05:16

I believe so. Removing all the checkouts removes the problem.

ikitommi04:05:06

and thanks for checking!

cfleming00:05:01

@U055NJ5CC I just tried to reproduce this, and I couldn’t. I tried running a REPL from the parent project, and also from some of the example projects with checkouts (e.g. frontend). Is that in a CLJ or CLJS REPL?

cfleming00:05:15

Can you give me some more specific repro instructions?

cfleming00:05:07

In both REPLs, I could load impl.cljc and reitit.core with no problem.

ikitommi07:05:48

thanks for investigating. Could you test adding one of the examples into source? e.g. https://github.com/metosin/reitit/tree/master/examples/frontend-auth. I have done that for all examples, but after change of dependencies, they drop out of source path, but could be that the checkouts still remain.

cfleming09:05:37

Do you mean adding that leiningen project? Yes, I did that, and ran the REPL both from the frontend project and the root project, and it all worked fine.

cfleming09:05:19

I didn’t go as far as getting a CLJS REPL going though, are you receiving this error in CLJ or CLJS?

ikitommi10:05:51

in clj. I’ll reinstall the project to see if that goes away.

cfleming10:05:28

Ok, if not I’ve also put some debug log in that we can enable to get a better idea of what’s going on (shows the full paths, not just the filename).

Rachel Westmacott15:05:47

I've done an 'invalidate caches & restart' and now none of my (or clojure core's) symbols can be resolved!

Rachel Westmacott08:05:52

I had shut all the other projects, and restarted with a single project.

Rachel Westmacott08:05:27

but it seems to have resolved itself with a restart, so not a huge issue for me right now

Rachel Westmacott15:05:05

I'm sure I've forgotten something silly. I just have no idea what.

Rachel Westmacott15:05:08

oh, another (manual) restart seems to have cleared it

p-himik15:05:10

What symbol should I use this this context? this doesn't work.

cfleming21:05:22

@p-himik Yes, Clojure doesn’t define a this keyword. You could switch the expression from Clojure to Java which would allow that. Otherwise, what’s the actual expression you’d like to use?

p-himik21:05:23

For example, (str "<" (:tag this) ">"). If a user can't refer to the object being rendered, is there even any point in having Clojure in the selector near the input field?

cfleming21:05:05

I see what you mean in the case of things like records - perhaps Cursive should wrap the renderer expression in something defining a local variable this that can be used in those expressions.

cfleming21:05:43

Unfortunately, thinking about it, those expressions are fundamentally designed to be used in an OO way, i.e. to have an implicit receiver. They’re not very useful for Clojure as they stand, I’ve filed https://github.com/cursive-ide/cursive/issues/2175

p-himik06:05:23

Thanks! Just to add a bit - it's not only about records, the Element on the image is deftype. Also the Clojure selector is missing entirely for java.lang.*, clojure.lang.*, primitives, Clojure functions. Could you extend a bit on "fundamentally designed to be used in an OO way"? Is this a limitation of IDEA? If so, maybe a feature request should be filed to JetBrains?

cfleming08:05:50

It’s more that that expression is designed to be called on an explicit receiver (OO style) rather than be a function receiving a this object or something similar.

cfleming08:05:12

Which makes sense since these are usually used in the context of printing a particular object.

ikitommi04:05:30

@cfleming it seems than all checkouts are handled as part of a classpath even if they are not. in reitit, there are /examples, which have checkouts for the main modules, which causes the weird dependency error. Something has changed? Using the latests version of both idea & cursive.