Common Lisp/ros/swank not behaving as expected about conjure HOT 15 CLOSED

So are we happy with this now? I'm going to merge anyway and get it in more hands, I think it's solid theoretically from what I understand of CL now. Thanks for doing research, sharing it and testing this @russtoku ❤️

from conjure.

Closing this issue because I think we did it! Please re-open if you run into issues!

from conjure.

Hey sorry about the bug, it's because Conjure is swapping the package to "common-lisp-user" on each eval because it's looking for a defpackage form and not finding it. It's related to #557

I'm just trying to add a fix now that is a best effort contextual eval that should support multiple defpackage / in-package forms in a file. Conjure's context system was designed with Clojure in mind with one ns form at the top and you generally keep the link of file-namespace name. It looks like in CL people swap the package a lot in some files, so I haven't accounted for that yet.

I'm not a CL user so it's a bit unfamiliar to me, but I'll add a best effort fix for this to develop now.

from conjure.

Great, thanks! I'm also brand new to the whole world of CL, so it's all a bit confusing :-)

from conjure.

Pushed a change to develop that I think addresses this? We now search up through the lines from your cursor position for the nearest in-package or defpackage then try to assume that package name with the eval you're doing. So it should support multiple regions in your files where you swap between packages for different calls.

I think that's useful for CL? But I'm really not sure! Let me know if that works for you. I can call the functions you listed in your example now but I do run into some other kind of errors, I think because I don't have whatever dependencies it needs installed.

from conjure.

Wow, that seems to work! Thanks a lot.

A couple of initial tests:

(in-package :sc-user)
(named-readtables:in-readtable :sc)

(setf *s* (make-external-server "localhost" :port 48800))
(server-boot *s*)

(defvar *synth*)

(setf *synth* (play(sin-osc.ar [320 321] 0 0.2))) ;; evaluating root form here...
(free *synth*) ;; ... also evaluates this.

(server-quit *s*) ;; evaluating root form on this also evaluates the previous two forms.

Not sure if this is expected behavior....

from conjure.

from conjure.

Yup, using treesitter. I did notice, however, that the highlighting is off in a way that suggests something is not quite right here...:

from conjure.

Good spot! That's 100% related, the highlighting and Conjure's view of your code tree are interlinked in tree sitter. So if what you're seeing is wrong, Conjure is seeing the same when it queries the tree. You might have to update your tree sitter parsers, I've had to do that between Neovim versions before otherwise I saw similar problems.

from conjure.

OK, so treesitter is to blame here, I think :-) Tried updating it, but seems it hasn't seen an update for 4 months, so there may be some breaking changes in the treesitter since then. When I disable treesitter for commonlisp the evaluation works as expected. If I have a bit more time I'll open an issue over at cl-treesitter!

from conjure.

Ah, figured out where treesitter stumbles: it doesn't like the square brackets in this expression:

(setf *synth* (play(sin-osc.ar [320 321] 0 0.2))) ;; evaluating root form here...

When I change those to regular parentheses it all works fine.

from conjure.

@Olical commented:

I'm just trying to add a fix now that is a best effort contextual eval that should support multiple defpackage / in-package forms in a file. Conjure's context system was designed with Clojure in mind with one ns form at the top and you generally keep the link of file-namespace name. It looks like in CL people swap the package a lot in some files, so I haven't accounted for that yet.

I think that it should be the nearest preceeding in-package form from the form or item being evaluated. I've put a comment regarding this on the discussion #557.

But I will try the fix added to the develop branch to see how things works so far.

from conjure.

I tried the fix added to the develop branch (20df0e0) and it seems to work.

from conjure.

from conjure.

No, just in-package should be OK.

from conjure.