This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (2)
- # arachne (1)
- # beginners (5)
- # boot (33)
- # cider (12)
- # cljs-dev (6)
- # cljsrn (26)
- # clojure (33)
- # clojure-austin (7)
- # clojure-belgium (6)
- # clojure-chicago (1)
- # clojure-dusseldorf (1)
- # clojure-fr (1)
- # clojure-hamburg (1)
- # clojure-nl (11)
- # clojure-portugal (3)
- # clojure-russia (14)
- # clojure-spec (35)
- # clojure-uk (28)
- # clojurescript (49)
- # component (7)
- # core-async (75)
- # cursive (13)
- # datomic (15)
- # dirac (57)
- # emacs (5)
- # events (1)
- # hoplon (34)
- # jobs (2)
- # jobs-discuss (8)
- # lambdaisland (1)
- # lein-figwheel (7)
- # leiningen (3)
- # om (5)
- # onyx (8)
- # re-frame (56)
- # reagent (13)
- # testing (7)
- # untangled (30)
- # vim (51)
- # yada (17)
@markwoodhall I don't understand the question too well. I've not used devcards though. Could you share what you have/what you do? I might know a few things to help.
Sure, so at the moment, I have a
:Figwheel function that will eval
(do (use 'figwheel-sidecar.repl-api) (start-figwheel!)). As far as I understand this will start the first cljsbuild where
nil. If I’m working on something with devcards, I’d also like to start the devcards build too so I have
:FigwheelStartBuild devcards that will eval
(do (require '[figwheel-sidecar.repl-api]) (figwheel-sidecar.repl-api/start-autobuild “devcards”)).
And what are you trying to achieve exactly? To me - that looks pretty good. You've automated what would normally be manual.
@dominicm well, that was the goal, to save that manual step. I was just interested if that was a common way of doing it really, or if there was an alternative, better way.
@markwoodhall The only other thing I could really think of is if there was some way to enumerate possible builds which would be candidates for dev and auto-run those?
:Figwheel could take optional parameters of builds to start
Yeah, that might be better actually. I guess it’s also worth double checking that there is no option to configure the builds to start in
@ingvij A small caution about https://github.com/cemerick/nrepl-python-client is https://github.com/cemerick/nrepl-python-client/pull/11 https://github.com/clojure-vim/nrepl-python-client The clojure-vim team have a fork here which contains the fix.
I'm going to make some improvements/changes to the watchable at some point too I think. It'll be more specific to nrepl bencode protocol, but will handle network failures better. Treating a network socket as a file seems to be a slightly optimistic abstraction in terms of errors.
Yes, now I remember. There's an edge case in my asyncwatchable branch (which isn't a blocker to merge, because it's minor and the rest of the improvements are so significant). If you kill the repl and then launch a new one on the same port, then the read should fail. Due to asyncwatchable, it just sits there forever. It doesn't crash and completions just stop iirc. When you kill neovim, it will sit there forever because it's waiting for the thread to die.
My plan is to update the watcher to use proper polling instead of a loop of reading over the port.
@ingvij I'm happy to support acid in clj-async-omni. That would hugely reduce maintenance burden for you I hope. 🙂
Looking at your tweaks, there might actually be a bug in your implementation. It's totally possible with async runners with nrepl for responses to come out of order. To avoid this, all messages should have a unique message id to which you subscribe so you can await the response. It looks (at first glance) that your system uses a filtering queing mechanism of some kind - but the filtering is done on op, it should probably be done on message id instead.
Not sure if deoplete will get confused if you return
["xyz", "xBC"] as a completion for
"xB" because of incorrect ordering.
I've learned a lot about nrepl clients since I wrote async-clj-omni. I should totally do something with that.
That's it https://github.com/clojure-vim/async-clj-omni has it's latest major release!
The whole thing uses crazy async voodoo to maintain only one connection to the nrepl. It's not perfect, there is an edge case in there to do with connections dying beneath it. I'll fix those upstream someday (tm). I've been using this as my daily driver for 2 months without any hiccups.
@juhoteperi I'm going to delete the asyncwatchable branch at some point, so if you update and find nothing is working. Master now has the new nrepl client in.
@juhoteperi https://github.com/clojure-vim/async-clj-omni/tree/master/rplugin/python3/deoplete/sources might be more to do with how the sync happens.
Hey all, sorry for taking long to answer.. It's been a while since I don't log in here.
I still have to take care of some issues. I'll fix that bug you mentioned earlier and then I imagine it'd be stable enough
Sorry for copying your code that way, btw.. I just needed something to prove the concept of acid.nvim and completion was pretty simple to implement
It'd be great if you could help me with acid, since I'm just scratching the surface of how nrepl works
Seems to be alternative to async-clj-omni currently as both provide depoplete source
async-clj-omni is very much specialized, so probably I'll drop support to deoplete as soon as acid is more stable and leave code completion to async-clj-omni