mid-term plan for slynk

[PuercoPop]

Most of the development of sly these days happens in the emacs front. I'm thinking that because Sly used asdf to load slynk we could start breaking up slynk in multiple systems. Making slynk more approachable by new developers. In addition, Because slime is from a pre-quicklisp era it avoids dependencies. We could start moving stuff out tree when applicable, like using closer-mop instead of slynk-mop. I'm curious if this approach would be welcomed?

I'm thinking for something

• utils (maybe make it one file per util?)
• definterface
• slynk-mop
• tcp-server
• connections
• listeners
• sentinel
• package-interface
• compilation-interface
• pathname-interface
• (etc for interfaces)

Also are there any plans to attempt to merge sly and slime, now that slime is under new management?

[joaotavora]

Sly used asdf to load slynk

That's the default. It can use slynk-loader too, so you can still load sly in an asdf-less lisp

Because slime is from a pre-quicklisp era it avoids dependencies.

If it didn't, it would be impossible to bootstrap a fresh lisp without having to install quicklisp on it first. Also you would have to be connected, no bootstrapping a new lisp in the desert. We could bundle some of those libraries though and use plain asdf.

I'm curious if this approach would be welcomed?

Possibly. But your premise, the "new developers"... Except for you, I haven't many of those. I'd rather not go to heroic measures in refactoring to meet a target that isn't there.

Also are there any plans to attempt to merge sly and slime, now that slime is under new management?

I don't know. The "new management" sits right in front of me. We've talked about it, but then we talk a lot :-)

[PuercoPop]

Also you would have to be connected,

Not connected, it only needs to fetch the dependencies once. But if support asdf-less lisps is important then yeah, it is a no go.

Possibly. But your premise, the "new developers"... Except for you, I haven't many of those. I'd rather not go to heroic measures in refactoring to meet a target that isn't there.

If you build it, they will come :smile_cat: It seems like a good idea for Sly as a project to facilitate on boarding new developers. But then again code talks, not feature requests.

More than something you'd work on, Reorganizing the code and breaking it up in smaller packages is something I will do (occasionally, over the lapse of months) to understand better the code base. Only that if merging upstream is not a possibility I'll be more sloppy with the commit messages.

I don't know. The "new management" sits right in front of me. We've talked about it, but then we talk a lot :-)

Just as point of reference, I don't think that a merge would be the best option. There is room for sly and slime in the CL community. Sly could be an IDE less concerned w/ working in old or exotic implementations. Breaking backwards compatibility when there is something to be gained.

[jcguu95]

By tcp-server did you mean to let slynk to communicate to its clients by UNIX tcp-sockets, rather than by local network? I'm pondering on making a contrib on this, but want to know how much people have given thoughts on it.

After some inspection, I suspect it would not be terribly hard. For sbcl at least, it seems to be enough to hack this part by using a local-socket instead of an inet(6)-socket. Related work has been done for slime/swank, but it has been in PR for almost 5 years.