Clojurians Log v2

Happy New year to you all on that side then! Here I still need to wait a bit 🙂

Happy New Year, everyone! :partywombat:

It’s almost 8 am at home and I’m just wrapping up the NY party here. 😄

Happy New Year to you all!

Happy New Year and happy new spiral Issue @volrath

🎉

haha, looking at it

holy moly, spiral's git repo is 102M big

the gifs...

ahh lol!

they're about 50mb, plus the git ref objects, twice that size

@volrath can't figure out to install spiral from master

followed the instructions in the readme but

Debugger entered--Lisp error: (file-error "Cannot open load file" "No such file or directory" "a")
  require(a)
  eval-buffer(#<buffer  *load*-613561> nil "/Users/pe/prg/spiral/parseclj/parseclj-parser.el" nil t)  ; Reading at buffer position 1146
  load-with-code-conversion("/Users/pe/prg/spiral/parseclj/parseclj-parser.el" "/Users/pe/prg/spiral/parseclj/parseclj-parser.el" nil t)
  require(parseclj-parser)
  eval-buffer(#<buffer  *load*-630384> nil "/Users/pe/prg/spiral/parseclj/parseclj.el" nil t)  ; Reading at buffer position 1113
  load-with-code-conversion("/Users/pe/prg/spiral/parseclj/parseclj.el" "/Users/pe/prg/spiral/parseclj/parseclj.el" nil t)
  require(parseclj)
  eval-buffer(#<buffer  *load*-294663> nil "/Users/pe/prg/spiral/spiral-loop.el" nil t)  ; Reading at buffer position 1277
  load-with-code-conversion("/Users/pe/prg/spiral/spiral-loop.el" "/Users/pe/prg/spiral/spiral-loop.el" nil t)
  require(spiral-loop)
  eval-buffer(#<buffer  *load*> nil "/Users/pe/prg/spiral/spiral.el" nil t)  ; Reading at buffer position 1491
  load-with-code-conversion("/Users/pe/prg/spiral/spiral.el" "/Users/pe/prg/spiral/spiral.el" nil t)
  require(spiral)
  (let ((spiral-dir "/Users/pe/prg/spiral")) (add-to-list (quote load-path) spiral-dir) (add-to-list (quote load-path) (expand-file-name "parseclj" spiral-dir)) (require (quote spiral)))
  eval((let ((spiral-dir "/Users/pe/prg/spiral")) (add-to-list (quote load-path) spiral-dir) (add-to-list (quote load-path) (expand-file-name "parseclj" spiral-dir)) (require (quote spiral))) nil)
  elisp--eval-last-sexp(nil)
  #[257 "\204\303
!\207	\303
!\n)B\211A	=\204\211A\211@\207" [eval-expression-debug-on-error elisp--eval-last-sexp-fake-value debug-on-error elisp--eval-last-sexp] 4 2269455 "P"](nil)
  ad-Advice-eval-last-sexp(#[257 "\204\303
!\207	\303
!\n)B\211A	=\204\211A\211@\207" [eval-expression-debug-on-error elisp--eval-last-sexp-fake-value debug-on-error elisp--eval-last-sexp] 4 2269455 "P"] nil)
  apply(ad-Advice-eval-last-sexp #[257 "\204\303
!\207	\303
!\n)B\211A	=\204\211A\211@\207" [eval-expression-debug-on-error elisp--eval-last-sexp-fake-value debug-on-error elisp--eval-last-sexp] 4 2269455 "P"] nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

did you package-install a?

(by the way why are emacs stacktraces so ugly??)

they are the worst!

there's a package called a???

yep, is Arne's

whoever came up with that should be ... oops 🙂

it's a dependency of parseclj

haha

very hard to figure that out from the stacktrace

a as in Associative data structures for elisp

you need a, clojure-mode (which you have already) and treepy

looks like I didn't actually read the readme

serves me right 🙂

usually I try to follow a readme roughly and then let myself be guided by the errors

spiral master installation is not so straight forward because of the parseclj submodule/dependency

yeah I totally get that

but cool that you got it to work, melpa is updating really slow lately, the fix will be there sometime today, I guess

the instructions are great

btw, I've been thinking into implementing more tooling, particularly getting information about symbols, for documentation or any other purposes. This type of tooling is not only relevant to spiral, but to any unrepl client, so I was thinking we should start considering creating a repo for it

things that can be reused between unravel and spiral, that may not fit in unrepl itself

another way to go would be to look into cider-nrepl and try to split that into library / nrepl stuff, and make it generic enough so that it's useful for unrepl clients

@volrath you mean clojure code like https://github.com/unrepl/unravel/blob/throwable/src/unravel/loop.cljs#L120 ?

as a simple example

that could be a library actually that we include in the unrepl blob (or add as a second blob)

correct

or as a sideloded jar 🙂

@volrath do you have a pointer to the corresponding code in CIDER?

yes, sec

@pesterhazy for example, this function will give you information about any symbol, if it's a special form, a function, macro, or java class/member, its arglist if any, docstring, etc.. https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/info.clj#L87

ah right so in CIDER it's part of the nrepl middleware

I think spinning that off as a (reusable?) library would be great

another example on cider-nrepl is this: https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/complete.clj which I basically copied the only interesting part that I needed here: https://github.com/Unrepl/spiral/blob/master/tools/src/spiral/tools/completion.clj

ideally 0 calories (no deps)

yeah exactly

so cider-nrepl has the two things coupled, and even though we could use it and only refer to the functions that we need, it's far from 0 calories

but what I think we should start thinking is have a unified place where to create these helpers that all clients might benefit from... I was going to start building my own version of info in spiral, but then I thought maybe we share them and reuse them

definitely, unravel needs those just as much

same with all future clients

right

I'm getting a bit worried that we're spawning too many repos

it makes integration more complicated because you need submodules or some other means of coordination

otoh I don't know what alternative is better (monorepo for all things unrepl?)

I know that React uses a monorepo for all their projects, even if they're disparate as modules (react, react-dom, react-server, ...)

what do you think?

for this, I'm thinking maybe just a separate repo, and clients would include a jar file... submodules would still be an option for client authors that might wanna hack on the tooling library and release their own versions of it

the jar file can be sideloaded the same way as a submodule folder

right

tbh, I'm not sure how to make mono repo work, I'm not being able to picture it

the missing piece is "shading' (to echo @dominicm) the namespaces

yes....

that's a big deal

I don't want to leave too much perf on the table by unpacking a jar, regex the hell out of the ns declarations, than re-assembling it, all at runtime

cider-nrepl uses mranderson and it works fine

is that done at runtime?

No

they do it at build time, I think....

https://github.com/clojure-emacs/cider-nrepl/blob/master/build.sh#L12

I guess you might as well reuse the NS if it's the same exact version

yes

so we'd just bundle a shaded "clojure-tooling.jar"

sounds good to me

cool, I'm going to create an issue in unrepl, as I'm sure @cgrand will have interesting thoughts on this

@volrath Does spiral already support the classic apropos, doc, ... I would start from those as they are a must in any lisp (see geiser) the build up. Also wanted to ask what you guys think about REPL types (cljs, lumo, Planck..). I am asking not to port things right now but to take into consideration while hooking up things, like in inf-clojure, a simple defcustom might be the solution.

@richiardiandrea I don't understand. Cider, spiral and inf-clojure use vastly different methods if interacting with the repl. How could that be just a matter of a defcustom?

@pesterhazy are they? In any case not maybe a matter of just a defcustom, just asking if you folks considered the multiple REPL type thing or it is out of scope for now

I'd say they're pretty different. Sure there could be a layer of abstraction, but that would be a lot of effort — essentially merging multiple project. Or am I misunderstanding?

@pesterhazy maybe I am oversimplifying 😄

@pesterhazy @volrath thinking a bit more about this, in inf-clojure each operation is dispatched based on the REPL type: https://github.com/clojure-emacs/inf-clojure/blob/master/inf-clojure.el#L808

Then each op is defined by a defcustom: https://github.com/clojure-emacs/inf-clojure/blob/master/inf-clojure.el#L837

This can be expanded by adding the connection type

So that the dispatch now is on [conn-type op]

@volrath as requested, in master you can now run arbitrary unravel sessions in "dual pane debug" view, e.g.

scripts/dual bin/unravel --debug --method clojure

@richiardiandrea > Does spiral already support the classic apropos, doc, ... I would start from those as they are a must in any lisp (see geiser) the build up. My initial intention is to start with eldoc, then I was going to decide between apropos or just something that would resolve symbols to its fully qualified name so that we could integrate tools like grimoire

about dispatching on the type of repl, I think we'll need to do something similar... the idea is that unrepl as a protocol would be a common ground to communicate to any type of repl, but definitely tooling would vary depending on the underlying actual repl. For that, I think there might be 2 options: 1. use the custom session actions that @cgrand added to unrepl, so that client authors could specify actions for completing on the jvm or on lumo or whatever, for example, 2. let the tooling library decide how to do it, which i think it would be best

so that client authors only have one way to call for completion, and the tooling library decides how to do it.. the only thing is that I'm not sure if this approach is generic enough to cover things beside completion

@volrath Some actions (ok I found the common term now) cannot be shared for, say, text repls and I think this is partly why there is a "manifest" in the unrepl initial :hello to advertise capabilities. Having said that I was more thinking in terms of UI. I would really like to see your UI applied to inf-clojure simple and not bloated REPL.

The dispatch on connection type + repl type + op is a simple layer on top I could take care of (already done that in inf-clojure)

The only thing I am asking is if there is interest in this now, never or later. I see value, but maybe I am the only one 😃

Maybe I can propose it in the next hack day 😺

I think I'm a bit lost 😳 do you mean if there's a need of dispatching depending on connection type (clj, cljs, self-hosted cljs) in spiral? or in any unrepl client?

I am talking about spiral only yes. Do you mean you would like to push the dispatching at the tooling library level?

hopefully yes. the thing is that unrepl only works in clojure so far, so there's no way to connect to cljs, or lumo/plank/... as in inf-clojure

that's why i only did completion for the jvm only

but once there's support for (self hosted)cljs, we definitely will want to port all the tooling

All the other repls have socket, I am not even thinking stdin/out

the thing I'm wondering is if we could push all of this to the tooling library, as you say, so that clients can just dispatch the same session actions

there are some initial efforts to bring support for unrepl in lumo, check this out

https://github.com/cgrand/lumo/tree/suspension

that branch let's you have a suspension in lumo's socket repl, so that you can upgrade it to unrepl

Uhm, I feel that would bring us to the brittleness of the current cider-nrepl. I liked the idea of clients deciding that actually

Yep I am very aware of that

alright, so you think it'd be better to have different session actions for, say, completing, depending on the host? that could also be an option

I'll be back, breakfast time with family

either way, I think this is something that not only concerns spiral but all the family of unrepl clients, because we definitely should want to have a standarized way to handle this. Maybe we could also discuss this in unrepl#30. If we go with having host-dependent actions, then spiral would certainly need something similar to what inf-clojure does 🙂 but instead of defcustoms, it would be session actions that are declared in :hello

On the other end it would be pretty trivial for inf-clojure to support the basics of the unrepl protocol. Ok ok going 🛩️

> Uhm, I feel that would bring us to the brittleness of the current cider-nrepl. I liked the idea of clients deciding that actually

What brittleness?

> so cider-nrepl has the two things coupled, and even though we could use it and only refer to the functions that we need, it’s far from 0 calories

I’m not sure if you understand what this middleware does - it simple calls two completion functions from two different libraries.

Obviously there’s no way to use the libraries without depending on them. 🙂

All of the middleware is really easy to reorganize into something generic - the nREPL handlers call just a single function generating the desired result and that’s it. Nothing’s really coupled between nREPL and utility logic. There was just no real need to have different namespaces when there was just a single user of this code.

It’s similar for info - there’s one implementation for Clojure that’s in cider-nrepl itself and another for cljs in cljs-tooling.

> they do it at build time, I think....

Yeah, that’s true.

We just deploy artefacts that have been processed with mranderson.

I'm getting close to a point where I might take a shot at doing the cider-nrepl port work.

I've just got a full build system shoe-horned into clj command line tool, and I'm aware of a frustration (with myself) with having to provide support for tooling baked-in. So I'm keen to reach a point where I can tell people to sideload their own damn dev tools and leave me alone 😄. Once I add support for unrepl to replant (unreplant?) I'll probably say that it's time for people to move over 😄

(of course, I can say that to my team, as long as emacs has a good story)

🙂

> I’m getting close to a point where I might take a shot at doing the cider-nrepl port work. I’ll also try to do something on the subject in the next couple of weeks.

Might be fun to write a bit of pure Clojure for a change. 😄

nice!

Maybe brittleness in not the right word here, but the reason I switched to inf-Clojure was to avoid errors due to the middleware libraries and have shorter stack traces.