<Shinmera>
scymtym's is a lot more advanced, but I don't know if it's public anywhere or if you even need everything it aims to provide.
<Shinmera>
Having swank depend on more standardised libraries to avoid code duplication would be really nice if it weren't for the version conflicts that arise from it.
<luis>
Shinmera: that /is/ the conundrum.
<Shinmera>
I do have some of the stuff that Swank does in separate libraries alread (dissect, definitions, trivial-arguments) but I reall don't know if using them would be the right thing to do.
<jackdaniel>
I want to note, that having swank depend on more standarised libraries is fine, but that will probably induce dependency on ASDF and/or QL ecosystem (maybe not unreasonable, but not very nice either)
<Shinmera>
Yes.
<luis>
Shinmera: do you know Conium?
<Shinmera>
Haven't heard of it, no
<Shinmera>
Ah, I see.
<luis>
Shinmera: it's swank but using libraries like that.
<jackdaniel>
swank is already organized in a fashion where interfaces and implementations are defined separately. some work could make it possible to be able to load different implementation at runtime
<jackdaniel>
i.e default implementation on ecl is :ecl, but you could suck from ql implementation :octopus
<jackdaniel>
at your own risk of course
<Shinmera>
That wouldn't really alleviate the maintainer's burden though
<jackdaniel>
ah, that was a goal. I thought we talk about some fancy extensions taken from remote libraries
<Shinmera>
Well, having both would be great :)
<jackdaniel>
yet another perspective: being forced to chase many (potentially abandoned) libraries to improve swank coverage for your implementation will be a pita
<jackdaniel>
it is easier to work on swank locally (and I'm saying it as an implementer)
<Shinmera>
Oh definitely.
<jackdaniel>
and make a single PR which is either accepted or not by slime team (not some 3rd party)
<jackdaniel>
I have nothing witty to add beyond this so I'll get back to unicode line breaks in McCLIM ;)
<Shinmera>
Good luck
<luis>
jackdaniel: you make good points and I agree with all of them. At this stage, I'm just wondering if I can avoid manually copying Eclector into SWANK and renaming it.
<Shinmera>
Using the backend idea would at least provide a way to get things done in the interim
<luis>
Indeed.
<Shinmera>
Having swank-ng as a ql system
<luis>
Although then you have more code to maintain, not less. Heh.
<Shinmera>
Right. Though with Swank being pretty mature I'd hope there's not that much to work on the old stuff while the new is coming along.
<Shinmera>
Of course I'm ready to get my hopes crushed :)
<luis>
Oh, exactly. There's so many cool features to implement in SLIME and SWANK!
<micro>
luis: Cheers
scymtym has joined #slime
<scymtym>
hi
<scymtym>
with respect to reading security: eclector can be configured to not intern, to evaluate #. in a client-defined way and to execute reader macros under the client's control. the last part doesn't help too much, of course, unless a secure interpreter or similar is available
<scymtym>
regarding code walking CSTs: i'm working on a system for s-expression syntax based on pattern matching that can handle ordinary s-expressions as well as CSTs with non-native symbols: https://techfak.de/~jmoringe/s-expressino-syntax.ogv . but i don't think it will be ready in time for slime. the dependency footprint also makes it inappropriate
<luis>
scymtym: Hi there. o/
<luis>
scymtym: Eclector does seem quite interesting. I'm going to try and integrate it with the standard readtable. I think that, in some sense, I'll be doing something for reader macros that is similar to what you guys do for regular macros in cst:reconstruct.
<luis>
So, micro asks: "make compile fails on slime-macrostep.el due to ../lib/macrostep not existing."
<luis>
micro: I think it's a bug that the melpa package includes a Makefile at all.
<luis>
micro: so, if you want to do things like that, you should grab the source tarball or, even better, git clone the repo.
<micro>
luis: Cheers
<scymtym>
luis: interesting idea. maybe you could use an adjusted standard readtable instance and a custom stream that, together, tell you approximately which input ranges were read with CL:READ, read the same ranges with eclector, then reconstruct
<luis>
scymtym: right. I have such a stream + readable already!
<luis>
*readtable
<scymtym>
luis: great. let us know how it goes
pesite` has joined #slime
pesite has quit [Ping timeout: 250 seconds]
pesite` has left #slime ["ERC (IRC client for Emacs 26.1)"]
pesite` has joined #slime
pesite` has left #slime ["ERC (IRC client for Emacs 26.1)"]
<fiddlerwoaroof>
luis: random question, I've occassionally wanted a stream that works like the repl io streams, but has its own dedicated buffer
<fiddlerwoaroof>
i.e. so that (princ foo *s*) goes to a dedicated buffer
<fiddlerwoaroof>
Is there anything generic like that in SWANK?
<fiddlerwoaroof>
I've looked around a bit, but I didn't see anything obvious
<fiddlerwoaroof>
luis: as far as the dependency issue goes, I wonder how far you could get by keeping a list of packages before loading dependencies and then renaming all the new packages
<fiddlerwoaroof>
You might have to patch some dependencies that do things like (intern "FOO" "BAR"), but I think it would work pretty well for 80%
<fiddlerwoaroof>
... of the dependencies you want to include
scymtym has quit [Ping timeout: 260 seconds]
scymtym has joined #slime
<luis>
micro: good news!
<luis>
fiddlerwoaroof: slime-redirect-trace-output is probably the closest thing we have, and... it doesn't seem to work.
<luis>
fiddlerwoaroof: it seems like (swank-repl::make-output-stream-for-target swank::*emacs-connection* "buffer-name") or something along those lines should do what you want, but it doesn't.
<luis>
fiddlerwoaroof: (swank/backend:make-output-stream (lambda (string) (swank:eval-in-emacs `(with-current-buffer "buffer-name" (goto-char (point-max)) (insert ,string))))) sort of works, but you have to call finish-output.
<luis>
Using a proper swank message instead of eval-in-emacs would be a better way to do it, of course.