pnf
commented
8 years ago That's definitely something I've thought about. Of course this won't stop corruption within the linting VM, as you're still using Eastwood in this nonstandard persistent fashion, and it might actually be harder to debug, so you'll be tempted to add restart logic, the ultimate manifestation of which would be to run a new VM for every lint cycle. At some point, it will seem easiest just to repeatedly invoke the lein command, thereby achieving maximum isolation, using Eastwood in the way that's actually supported, and reducing the flycheck plugin to the standard variety that just knows how to parse stdout.
On Jun 23, 2016, at 12:57 AM, Eric Gebhart notifications@github.com wrote:
I was thinking that my problem #40 could possibly not be as much of a problem if flycheck clojure used a second jvm just for it's purposes. Things seem to work reasonably well in #40 if it weren't for the fact that eastwood corrupts my JVM. And it makes no promises that it won't. So who knows what else could happen that might not result in such an obvious failure. As obvious as it is now, it took me a few days to understand that it wasn't my code or something else.
Cider has had nice connection management working for a while. So I'm wondering how hard would it be to create a second JVM and use that for all of the code checking. It should probably be optional since some people might not want to be running two JVMs.
Obviously the load would have to happen twice. But otherwise, using cider's connections should be fairly straight forward. It seems like this could be an easy win given eastwood's experimental status for repl calls and it would also be faster since the working jvm wouldn't be waiting on the code checks.
If I can help in any way, I'm willing. I might be able to make a pull request, but I can't promise that. I've got other things breathing down my neck.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
EricGebhart
MalloZup
I was thinking that my problem #40 could possibly not be as much of a problem if flycheck clojure used a second jvm just for it's purposes. Things seem to work reasonably well in #40 if it weren't for the fact that eastwood corrupts my JVM. And it makes no promises that it won't. So who knows what else could happen that might not result in such an obvious failure. As obvious as it is now, it took me a few days to understand that it wasn't my code or something else.
Cider has had nice connection management working for a while. So I'm wondering how hard would it be to create a second JVM and use that for all of the code checking. It should probably be optional since some people might not want to be running two JVMs.
Obviously the load would have to happen twice. But otherwise, using cider's connections should be fairly straight forward. It seems like this could be an easy win given eastwood's experimental status for repl calls and it would also be faster since the working jvm wouldn't be waiting on the code checks.
If I can help in any way, I'm willing. I might be able to make a pull request, but I can't promise that. I've got other things breathing down my neck.