Fork me on GitHub
#cursive
<
2016-09-08
>
hlship00:09:21

It does a good job for source files from the same project; have you tried using checkouts? That’s a leiningen feature, but I believe (I can’t use this on my project) that it will do the right thing for you in Cursive as well.

hlship00:09:53

The “Load file in REPL” command, BTW.

danielcompton00:09:08

@kenny cursive has a “Load file in REPL” command which will reload dependent namespaces that have changed

danielcompton00:09:26

which will work in conjunction with checkouts as hlship has pointed out

jrheard00:09:47

hi - i can't set a breakpoint in my clojurescript project in cursive, can't figure out what i'm doing wrong. i'm coming back to this project (and cursive / programming in general) after having stepped away for about six months, and am pretty sure that i used to be able to set breakpoints

jrheard00:09:07

when i select the "run" menu up top, most of its items are grayed out, including "toggle line breakpoint"

jrheard00:09:32

i'm sure i'm doing something wrong (and am half-convinced that i've entirely forgotten how to use a computer) - has anyone run into anything like this before?

jrheard00:09:56

not sure what other info i can provide to help diagnose this issue

jrheard00:09:43

per a random google result, i've done a file -> invalidate caches + restart, issue persists

jrheard00:09:10

https://github.com/jrheard/voke/tree/ai is the project, if that's at all helpful

jrheard00:09:00

my repl is configured as specified in https://github.com/bhauman/lein-figwheel/wiki/Running-figwheel-in-a-Cursive-Clojure-REPL , and i'm running it in debug mode

jrheard00:09:55

intellij 15.0.6, cursive 1.3.1-15

jrheard01:09:46

nothing in the intellij event log, just an "all files are up-to-date" message; restarting computer didn't fix problem 😄

lfn301:09:35

@jrheard I’m pretty sure you can’t debug cljs yet.

lfn301:09:42

If you want to debug cljs I’ve heard good things about https://github.com/binaryage/dirac

jrheard01:09:41

oh hm i could've sworn cljs cursive debugging was a thing

jrheard01:09:45

must've just misremembered i guess

jrheard01:09:56

all these months of dark souls 3 and hearthstone turning my brain to mush

lfn301:09:57

Dw, I’ve found part of programming is realising you’re being a bit of idiot every now and again.

jrheard01:09:59

nice, thanks @lfn3 !

jrheard01:09:20

s/every now and again/multiple times daily/ in my case... 😄

sveri07:09:12

@cfleming you mean the "Prettify stacktrace elements using folding"?

sveri07:09:26

If so yes, then it does not work for me. I see the whole stacktrace printed.

cfleming07:09:21

@sveri Can you send me an example of one that fails to fold?

cfleming07:09:29

Either here or by email

cfleming08:09:11

@sveri Interesting, is that the new readable error format?

cfleming08:09:47

It’s not actually a stacktrace, it’s an object - is that the Clojure one or some custom object?

sveri08:09:47

@cfleming Actually I never really thought about it. Its from web dev and I guess its just a stacktrace that is embedded.

sveri08:09:59

I will try to figure out where it comes from exactly

cfleming10:09:07

@pupeno Thanks very much for the cheatology sheet, if those shortcuts are working for you I’ll take those as the new defaults.

cfleming10:09:20

@hlship The built-in “Jump to next error” (F2 by default, I think) should work for test failures.

cfleming10:09:11

@jrheard Right, no CLJS debugging yet sorry, it’s on the roadmap

pupeno10:09:44

@cfleming: i think I already modified them a bit. Give me a couple of weeks of use and I'll polish the selection.

cfleming10:09:07

@pupeno Ok great, let me know when you think they’re good and I’ll make them the defaults.

shooodooken10:09:38

@cfleming Would you have a public facing tracker we could view what's happening in Cursive dev (similar to what Fogbugz on Trello(https://trello.com/b/JZLXnMnN/fogbugz-development)) ?

cfleming10:09:00

@shooodooken I don’t right now, but using Trello for that is something I have thought about

kenny17:09:13

@danielcompton No this does not work for dependent projects. It works for all namespaces in your current project, but not namespaces that have changed in dependent project. For example: I have two projects: project1 and project2. project1 depends on project2. I have an auto building task running in project2 (the auto build task builds a new jar, same version, into your local maven every time a file in project2 changes. for boot users this is just boot watch pom jar install). I have a function in project2 called project2.core/foo. Now I open a REPL in project1 and load the file project1.core, which looks something like this:

(ns project1.core
  (:require [project2.core :as project2]))
and switch namespaces to project1.core. I can now run project2/foo and get my expected output from that function. Now I decide I want to add a new function to project2.core called bar (located at project2.core/bar). So I go ahead and add it, save the file, the auto build task runs, and I switch back to project1. I run the "Load file in REPL" command and try to execute project2/bar. I get
java.lang.RuntimeException: No such var: project2/bar
To get the REPL to recognize the changed dependency, project2, I need to run (require 'project2.core :reload). Now if I run project2/bar, the function exists and I get the expected output. It would be great if Cursive could add a way to do this.

darwin18:09:50

not using it myself, it just sounds like what you just described

kenny18:09:24

Hmm, yeah that looks like what I need. There's nothing like that built in Cursive though, correct?

darwin18:09:16

the problem is much deeper in general, you have to write “reloadable” code in the first place, Cursive could run (refresh) for you, that is easy, but it won’t rewrite your app 😉

dmarjenburgh20:09:03

Hi, if I run a test.check defspec, the repl will log an error. Any ideas?

Error handling response - class java.lang.IllegalArgumentException: Argument for @NotNull parameter 'path' of com/intellij/openapi/vfs/impl/local/LocalFileSystemBase.findFileByPath must not be null
I’m using OSX 10.11.6 and Cursive 1.4.0-eap2-2016.2

danielcompton21:09:55

@kenny I think the use case you’re describing would be (better?) served by checkouts? I don’t think much Clojure tooling expects JARs in a running JVM to be changing

kenny22:09:12

@danielcompton Works great for cljs, not for clj due to caching.

cfleming22:09:13

@dmarjenburgh Could you file an issue for that please, and I’ll try to reproduce it?

danielcompton22:09:08

right, that’s why checkouts may be a better option

cfleming22:09:40

@kenny Hmm, that’s an interesting one. I’ll try to reproduce that case and see if I can fix it. Are you overwriting a snapshot jar here?

kenny22:09:13

Doesn't have to be a snapshot but it could be

cfleming22:09:29

I don’t think that tools.namespace will handle that better, since it assumes (IIRC, don’t have the code here) that the files are on disk and not in a jar.

cfleming22:09:06

So if it’s not a snapshot, a lot of tooling will assume that my-library-x.y.z.jar will not change, since in theory it’s the same version.

cfleming22:09:23

(I doubt that’s the real problem here, but it’s something to bear in mind).

kenny22:09:02

I can test with a snapshot version

cfleming22:09:10

I’m actually surprised that works in a normal REPL too. You’re essentially dynamically updating a classpath element, and often things will cache etc, or maintain a File open on a particular jar - if you swap the jar out from under it you’re probably in undefined territory I suspect.

kenny22:09:14

Same result with a snapshot

kenny22:09:49

It's possible boot's :checkouts is doing some handy work here. I'll try with no :checkouts.

juhoteperi22:09:43

Boot checkouts explodes the JAR to tmp-dir and adds that to the classpath instead of the JAR in maven repo (and looks for changes in the jar file and updates tmp-dir if it changes)

kenny22:09:15

Interesting.. I get a

Could not locate my/ns/core__init.class or my/ns/core.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
when using :reload. Works fine without :reload.

kenny22:09:36

Ah, that would explain how it works

cfleming22:09:25

Right, I think that swapping the jar itself is a recipe for problems. What I suspect you’ll find is that require works without :reload, but it won’t actually reload anything.

kenny22:09:25

So yeah. Looks like it only works with boots :checkouts. Still would be nice to have a way to :reload changed namespaces.

kenny22:09:03

When :checkouts is set?

juhoteperi22:09:19

@kenny What about just using c.t.n.repl/refresh like normally?

cfleming22:09:28

Well, it sounds like boot’s :checkouts does some magic (thanks deraen, I didn’t know that)

kenny22:09:48

Yes, require without :reload works but does not do anything

kenny22:09:55

@juhoteperi I'll look into it. It may cause some code changes that I'm not happy with though.

cfleming22:09:18

@juhoteperi I don’t think c.t.n will work here, I believe it only reloads files from disk, not from jars

cfleming22:09:45

@kenny Are you using the boot script which generates the project.clj?

juhoteperi22:09:24

@cfleming Yes, but as Boot checkouts unpacks the jar to disk, it doesn't see the jar but just files in disk like any source-path

cfleming22:09:24

Perhaps you could modify that to set up lein checkouts when :checkouts is used in boot?

cfleming22:09:11

I see - the problem is that I’m not sure lein gives you a way to add an arbitrary dir to the classpath. Perhaps you could generate resource-paths in lein, or something like that.

kenny22:09:43

Unless checkouts in lein have changed I don't see how that is possible. :checkouts in boot are a vector of deps and I have no way of knowing where that project is located on disk.

kenny22:09:10

Actually you could probably symlink to a file in jar

cfleming22:09:25

Right - I think generating a resource-paths entry for the exploded jar location (if you can access that) might work.

cfleming22:09:48

The problem is you’ll have to remove the original jar from the classpath too.

cfleming22:09:07

Otherwise it’ll depend on lein’s internal classpath generation order.

kenny22:09:19

Possibly using the same functions boot's :checkouts uses?

cfleming22:09:42

Maybe, I don’t know anything about boot so I’d only be guessing 🙂

kenny22:09:41

Hmm.. I think this would need to be separate from the lein-generate task because you wouldn't want to run lein-generate every time you change a dependency.

cfleming22:09:06

You might not have to - it depends whether the unpacked jar location is stable.

kenny22:09:18

stable meaning static?

cfleming22:09:12

Right. If it is generated using a hash of the jar’s location or something then you can just add the resource-path in lein-generate and that will always remain the same.

cfleming22:09:37

So I also think you’ll hit another problem here - Cursive will complain that the source/resource dir is outside the module content root.

cfleming22:09:46

Let me find the issue

cfleming22:09:05

I can fix that if that is a blocker for this problem, I spoke to IntelliJ’s Gradle support guy about it and I know how to fix it.

kenny22:09:48

Well I think the first thing would be to confirm that this would work as we think.

cfleming22:09:20

Sure, I guess first make sure you can actually generate the source-path or similar.

kenny22:09:37

Would doing "Load file in REPL" realize the changed files from dependencies or would you still need to do require with :reload?

cfleming22:09:23

Well, if you add that as a source path, then Cursive will think that the copied source is part of the same project, so that should work.

cfleming22:09:50

Do you have both lein/boot projects added to a single IntelliJ project?

kenny22:09:08

One project per IntelliJ project

kenny22:09:15

I usually have multiple IntelliJ projects open

cfleming22:09:07

Ok, so that will be ok - otherwise you’d get multiple completion entries etc. You will have to be careful not to edit the files in the wrong project. If I do fix that content root issue, I’ll try to add the sources as read-only.

cfleming22:09:18

Not sure if that’s possible though.

cfleming22:09:55

One possibility - if you can control where the checkout exploded dir is put, then you could just put that inside the other project in a src-checkout dir alongside your src

cfleming22:09:04

Then Cursive would not complain about the content root.

kenny22:09:22

That's probably pretty easy

cfleming22:09:40

I think that’s your best solution then.

kenny22:09:27

Is the checkout exploded dir the same dir as where the jar is installed to?

cfleming22:09:47

No, it won’t be, it’s probably a temp dir somewhere.

cfleming22:09:18

I imagine (again, just guessing), that boot writes the jar as normal and then additionally writes the exploded contents somewhere else.

kenny22:09:31

Does the unpacking only occur once?

kenny22:09:38

Maybe a question for #boot

cfleming22:09:54

Yeah, I think so - I’m only making stuff up at this point.

cfleming22:09:14

I mean, it must happen once each time you re-generate the jar.

kenny22:09:22

That's what I thought

kenny22:09:29

I have no idea how it knows when the jar is regenerated

juhoteperi22:09:21

Same as Figwheel etc., using inotify/such or polling for file modification date changes

cfleming22:09:35

Right, looking at file changes I guess

kenny22:09:37

Ah, so there is a watch on the maven dir where the jar is located?

cfleming22:09:26

Or a watch on the source, which regenerates the jar when it changes (which provokes the exploding)

kenny22:09:36

Is there one watch per dep in :checkouts or one watch on the whole maven?

kenny22:09:59

I believe there is a watch on both the source and the jar

juhoteperi22:09:07

watch per dep

kenny22:09:50

Oh cool, so there is a :checkout-paths

juhoteperi22:09:22

oh right, didn't see that, I guess that could be useful here

kenny22:09:42

@juhoteperi Each time a checkout dep changes is the exploded path a new tempdir?

juhoteperi22:09:45

problem is that it changes for each Boot process

juhoteperi22:09:57

temp-dir is per Boot process per dependency

kenny23:09:25

So the checkout path is not static

cfleming23:09:02

Can you run the lein-generate when starting your boot auto-watcher?

cfleming23:09:27

Hang on, if you’re setting your own exploded path there’s no problem, right?

juhoteperi23:09:33

Should be possible to update project.clj the first thing in pipeline

cfleming23:09:35

By definition it’s static.

kenny23:09:28

I thought the exploded path changed each time the dependency updates, no?

kenny23:09:44

boot removes old path from classpath then adds the new one?

juhoteperi23:09:51

No, the contents on temp-dir change

cfleming23:09:55

No, I doubt it

cfleming23:09:02

Right, just the contents.

kenny23:09:22

So then it should work if I just call lein-generate when starting a repl

kenny23:09:02

I suppose that bug you mentioned will need to be fixed first 🙂

cfleming23:09:12

But can’t you set the checkout dir?

cfleming23:09:29

If you do that, and set it within your other project, you’ll be fine.

juhoteperi23:09:51

No. :checkout-paths is read-only property, I guess supposed to be used for debugging and such

cfleming23:09:35

So is that a directory that boot then creates all exploded content inside of?

kenny23:09:43

A vector of paths

cfleming23:09:08

You need a Cursive fix, then. I’ll try to fix that issue in the next EAP.

kenny23:09:59

Cool. Once that's fixed I'll update the lein-generate task to add :checkout-paths to :source-paths.

kenny23:09:28

That'll actually be really helpful

kenny23:09:51

It's pretty time consuming having to type the require out each time 😛

cfleming23:09:20

That, my friend, is a first-world problem 🙂

cfleming23:09:39

(also, you can use your REPL history)