Fork me on GitHub

@thheller Yeah, that’s a good idea as well. Regarding different ops vs same ops + some type param - it seems like more or less the same thing in the end of the day. I guess the different ops would have the slight advantage of making it easier to tell if some ops is supported on cljs, but at the cost of doubling the ops for each middleware.


Unfortunately it doesn’t quit work quite write - the server starts but it seems it’s not an nREPL server. I can’t connect with cider-connect as well.


I’m reasonable certain that’s just a matter of invoking the right command, so I’ve pushed this for everyone’s consideration.


I’ll add the cljs repl code when we get this running. On a related note - it’d be nice if someone can provide me with a “real” project I can play with. I just created a blank project with lein and used shadow-cljs init on it, as I wasn’t quite sure what to do, and don’t have time to peruse the nice manual.


@bozhidar What's the state of play with CIDER and deps.edn these days? I'm just coming back to Emacs/CIDER after a couple of years away ... I set up Prelude again today and did cider-jack-in somewhere that didn't have a project.clj or build.boot and saw it trying to use clj -Sdeps ... I think?


Support is available, at least in 0.17.


Last I checked it was a little incomplete


(I was a bit surprised it didn't walk up the file system tree to a parent folder that did contain build.boot)


@bozhidar do you talk to the server process via stdin/stdout? server is just a standalone process you can't interact it besides CTRL+C o D. it starts a nREPL server and writes its port to .shadow-cljs/nrepl.port (similar to .nrepl-port). its a random port similar to lein .nrepl-port.


I made this example for a user yesterday README contains the usual commands


still a basic project with just one build but something that actually has some code


> (I was a bit surprised it didn’t walk up the file system tree to a parent folder that did contain build.boot)


@seancorfield Outside of a project CIDER now defaults to using tools.deps instead of lein, as it did in the past. But the algorithm for resolving projects hasn’t changed and CIDER will start looking from the current folder up until it finds some project marker file.


Perhaps you had some deps.edn file floating around?


Ah, of course, we maintain all our dependencies in external EDN files called -- you guessed -- deps.edn that predates the new tooling.

😆 4

@thheller No, I can’t connect to the server for some reason, that’s why I started wondering whether this is an nREPL server or a socket server.


depends on what port you connect to. both exist.


Ah, and I assume the port you write to stdout is the socket server port, right?


by default it only prints the http address


printing the random nrepl and socket-repl ports just seemed confusing


I can add a CLI flag to print something useful for cider if that makes sense


I assumed you always look at the .nrepl-port file


Not as a human. 😄


hehe yeah I meant from cider 😉


And I had not gotten to changing the code that looks for the port file, as normally it’s in another place.


Might be nice to still print the nrepl port in the boot message, as I’d assume some people would not know 2 servers are starting and they have to check for the other port in a file.


well it currently only prints the http port because that will some day contain a UI of sorts


currently its pretty useless so there really isn't any reason to print that at all


I'll just switch it to print all the ports always


That sounds like a good plan to me! :thumbsup:


but how do you pick the correct one? where is the detection code for this? should it be printed in a specific format?


(when (string-match "nREPL server started on port \\([0-9]+\\)" output)
        (let ((port (string-to-number (match-string 1 output))))
          (message "nREPL server started on %s" port)
          (with-current-buffer server-buffer
            (let* ((client-proc (nrepl-start-client-process nil port process))
                   (client-buffer (process-buffer client-proc)))
              (setq nrepl-client-buffers
                    (cons client-buffer
                          (delete client-buffer nrepl-client-buffers)))

              (when (functionp nrepl-post-client-callback)
                (funcall nrepl-post-client-callback client-buffer))))))


That’s a bit of legacy, but right now we basically grep for this string.


ah. ok I can emit it like that.


In the past lein wasn’t writing anything to a file and this seemed like a good way to figure out server has finished it’s initialization. That’s basically the big problem - how do you know you can finally connect to the server.


We also use the port files, but only to provide connection candidates for cider-connect.


ok, changed it to print shadow-cljs - nREPL server started on port 8202 on startup


@bozhidar I'm using your init.el. how do I directly use a git checkout of cider? its currently using elpa/cider-20180318.833 I think


Just do M-x package-list-packages and upgrade the package from the UI there.


MELPA packages are build for the git master of their respective repositories.


If you really want to use a local git checkout you’ll need to remove the installed package and add to init.el something like the following code:


; load CIDER from its source code
(add-to-list 'load-path "~/projects/cider")
(require 'cider)


Ah, of course, we maintain all our dependencies in external EDN files called -- you guessed -- deps.edn that predates the new tooling.

😆 4

anyone having trouble with company + cider recently? autocomplete is broken for me with snapshot CIDER and stable CIDER, and I’m inclined to blame one of the many recent commits to company-mode itself


File an issue against CIDER. Be sure to fill in the details:


@bozhidar Should this say "clause" instead of "cause"? > The only thing worse than a rebel without a cause is a REPL without a cause.