Helmut Eller eller.helmut@gmail.com writes:

On Fri, Sep 05 2014, João Távora wrote:

...

I believe I have done everything right fork-wise,

The most important thing for a proper fork is to use a different name. Please use something different than Slime and Swank.

The project is called SLY. Sorry the subject is completely botched it should read "SLY, a fork of SLIME."

There is a file swank.lisp in the SLY project and it starts up a server that SLY connects to (SLIME can also connect to it, to a smaller degree). There is also a swank and package many many symbols are named exactly like in SLIME. I hope you don't expect me to rename all these.

...

maintaining the licensing notice, crediting the original authors prominently in the README and in any commits cherry-picked from this project.

sly-mrepl.el looks like a fork of slime-mrepl.el; but the original had a license.

Indeed, it is a fork. I removed the license but will put it back in place, thanks for noting.

J

Zach,

OK, thanks for the heads up

I will try to make SLY installable via Emac's built-in mechanism basically "M-x package-install RET sly RET"

João

On Fri, Sep 5, 2014 at 6:26 PM, Zach Beane xach@xach.com wrote:

joaotavora@gmail.com writes:

...

Helmut Eller eller.helmut@gmail.com writes:

...

On Fri, Sep 05 2014, João Távora wrote:

...

I believe I have done everything right fork-wise,

The most important thing for a proper fork is to use a different name. Please use something different than Slime and Swank.

The project is called SLY. Sorry the subject is completely botched it should read "SLY, a fork of SLIME."

There is a file swank.lisp in the SLY project and it starts up a server that SLY connects to (SLIME can also connect to it, to a smaller degree). There is also a swank and package many many symbols are named exactly like in SLIME. I hope you don't expect me to rename all these.

If at some point you'd like SLY to be available via Quicklisp, swank.asd at least would need a new name, to avoid conflicts with slime's swank.asd.

Zach

---

Slime-devel mailing list Slime-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/slime-devel

On Fri, Sep 05 2014, joaotavora@gmail.com wrote:

[...]

...

The most important thing for a proper fork is to use a different name. Please use something different than Slime and Swank.

[]

There is a file swank.lisp in the SLY project and it starts up a server that SLY connects to (SLIME can also connect to it, to a smaller degree). There is also a swank and package many many symbols are named exactly like in SLIME. I hope you don't expect me to rename all these.

Yes, I do: please use something different than Slime and Swank as part of symbol names, package names, or file names.

Helmut

joaotavora@gmail.com (João Távora) writes:

Helmut Eller eller.helmut@gmail.com writes:

...

Yes, I do: please use something different than Slime and Swank as part of symbol names, package names, or file names.

Sorry, no, unless you provide an argument.

I'd like to be able to load both of them at the same time without conflicts.

Zach

joaotavora@gmail.com writes:

Zach Beane xach@xach.com writes:

...

joaotavora@gmail.com (João Távora) writes:

...

Helmut Eller eller.helmut@gmail.com writes:

...

Yes, I do: please use something different than Slime and Swank as part of symbol names, package names, or file names.

Sorry, no, unless you provide an argument.

I'd like to be able to load both of them at the same time without conflicts.

OK, that is an argument.

I see SLIME as an application/tool, not as a library, so it doens't make any sense to me. But perhaps a SWANK server running standalone in an application can be viewed as a library. Then again, it's tricky, why would developers need to place two similar separate debugging tools in their applications?

Do you really see this as an impediment to trying out SLY? SLY is alpha right now (as noted before) and I mostly need feedback. When I get some feedback I will consider the ability to load both SLY and SWANK servers in the same Lisp. I probably won't release sly until the time Emacs 24.4 officially comes out (it's in pretest right now)

I'd like to try out sly. I'd like sly not to make it impossible to load swank and slime afterwards. A conflicting system file and conflicting emacs symbol names are an impediment to that.

I think slynk is a fine name for the CL-side of sly.

Zach

On 09/05/2014 12:30 PM, João Távora wrote:

Zach Beane xach@xach.com writes:

...

I'd like to try out sly. I'd like sly not to make it impossible to load swank and slime afterwards. A conflicting system file and conflicting emacs symbol names are an impediment to that.

I think slynk is a fine name for the CL-side of sly.

Hmmm I was thinking of zwank, but your suggestion perhaps rings better. What is a slynk?

It's a zwank that can see in the dark.

Zach Beane xach@xach.com writes:

I'd like to try out sly. I'd like sly not to make it impossible to load swank and slime afterwards. A conflicting system file and conflicting emacs symbol names are an impediment to that.

I think slynk is a fine name for the CL-side of sly.

Zach,

OK, so in SLY's "renames-v2" branch available at

https://github.com/capitaomorte/sly/tree/renames-v2

there is support for loading both SLYNK and SWANK at the same time in the same Lisp image and loading both SLIME and SLY in the same Emacs.

This is the test I used, for reference

$ emacs -Q

(setq inferior-lisp-program "sbcl")

(add-to-list 'load-path "~/Source/Emacs/sly") (require 'sly-autoloads) (delete 'sly-retro sly-contribs)

(add-to-list 'load-path "~/Source/Emacs/slime") (require 'slime-autoloads) (setq slime-contribs '(slime-fancy))

Then you can "M-x sly". In the ensuing repl, you should be able to

(ql:quickload :swank) (swank:create-server :port 4010)

And then you can `M-x slime-connect RET 4010 RET`.

You should getboth the SLIME and SLY's REPLs to the same Lisp image.

I tried this particular combination (1 Emacs to 1 Lisp) but other "n-to-n" combinations should work as well.

Users wanting to do these kinds of stunts have to explicitly disable `sly-retro` in their emacs configurations, otherwise they will get an error when loading whichever is the second server.

Zach, if you wish to distribute SLY with quicklisp you can probably add

(setq sly-contribs (delete 'sly-retro sly-contribs))

to the elisp blessing that quicklisp installs.

If I get positive feedback I will merge "renames-v2" to the mainline.

João

PS: Helmut: I still use SLYNK-RPC::SIMPLE-READ for the bootstrapping, so thanks again for that trick. By the way, a comment nearby states that "no one ever tested this and will probably not work". Which is correct, but is easy to fix: when a symbol is found, INTERN needs to parse the package first or be replaced by READ-FROM-STRING entirely.

PS2: Here is more information about the implementation that I will describe in SLY's CONTRIBUTING.md file.

I went ahead with the package nickname technique for the reasons I gave to Helmut (safer interworking, early abort if error) and because I also want to provide interoperability for other Lisp-side extensions looking for the :SWANK package.

Nicknames are setup if `sly-retro` is in `sly-contribs`. Either via ASDF or the old loader (still supported), `slynk-retro.lisp` is eventually loaded into the Lisp on demand. It will set up the nicknames.

The user might also decide to ASDF-load `slynk-retro` or `slynk-retro.lisp` directly from Lisp.

If sly-retro and slynk-retro are never loaded, SLY operates in a completely isolated namespace AFAIK, both in Emacs and Lisp. Messages in the RPC protocol are prefixed "slynk:"

The `sly-retro` contrib is in `sly-contribs` by default, meaning the nicknames *are* setup by default and exchanged messages have "swank:"" as a prefix.

Attila Lendvai attila.lendvai@gmail.com writes:

...

...

I'd like to be able to load both of them at the same time without conflicts.

OK, that is an argument.

i have a counter argument for too much renaming: the closer the two codebases are to each other, the easier to pull over patches, or ultimately to merge the two projects.

This is an important factor, but it's not my main worry right now. Git is very good at figuring out renames changes and small changes and the volume of contributions to SLIME is not expected to be very high.

My reticence to this particular renaming stems from the fact that the RPC protocol between Emacs and the Lisp process is itself based on the identifier "swank" *and* on its package-designating quality. This is an example of what goes on the > wire

(:emacs-rex (swank:connection-info) nil t 1)

If I blindly rename "swank-">"slynk" in all symbols, packages and parts of symbols, as is being requested, SLY will be immediately locked out of the existing communication protocol.

In practice, this means losing the ability to connect to third party extensions such as SWANKR [1]. It will also, conversely, lose the ability to have an extension like swank-client [2] connect to it.

There are other examples, and even SLIME itself carries swank back-ends for other languages.

In my understanding, asking to rename an external interface resembles asking an HTTP server implementation to rename GET and POST to something else, or asking a Unix implementation to provide grep or sed under different names.

I also don't think arguments of ownership find any kind of provision in SLIME's licensing, but I'm waiting on answers to inquiries that I made to people more knowledgeable in the matter than me. Arguments of authority are also of little or no value to me.

That said, there is the argument of convenience/coexistence that Zach made. I find this argument persuasive, and the "slynk" name particularly elegant.

There is a way to rename "swank" to "slynk" in most places, but implement an indirection that still allows SLY to issue requests in the form "swank:<interface>". Over at the proposed SLYNK side, packages would be nicknamed "SWANK-*" to accept these messages.

These two "tricks" can be packaged in an optional contrib. The contrib would be enabled by default. Users like Zach would need to take care not to ASDF-load "slynk-retro.asd" into an image where "swank.asd" is loaded. Also, before connecting a SLY client to a Lisp where SWANK is laoded (or where it is expected to exist in the future), the `sly-retro' contrib would first need to be deactivated in Emacs with something like

(setq sly-contribs (delete 'sly-retro sly-contribs))

Because SLY will only load contribs' Lisp code on demand (either via ASDF or its own loader) this should be enough to avoid a conflict.

These changes don't seem hard but they don't seem trivial either. Help is welcome.

João Távora

[1]: https://github.com/gigamonkey/swankr [2]: https://github.com/brown/swank-client

Helmut Eller eller.helmut@gmail.com writes:

On Sun, Sep 07 2014, João Távora wrote:

[..,]

...

My reticence to this particular renaming stems from the fact that the RPC protocol between Emacs and the Lisp process is itself based on the identifier "swank" *and* on its package-designating quality. This is an example of what goes on the > wire

(:emacs-rex (swank:connection-info) nil t 1)

If I blindly rename "swank-">"slynk" in all symbols, packages and parts of symbols, as is being requested, SLY will be immediately locked out of the existing communication protocol.

In swank-rpc.lisp is a function SIMPLE-READ that can be used to parse the string that comes from the wire. You could replace the call to INTERN there with something that splits the string at the #: and then map "SWANK" or other package qualifiers to your own packages.

It is an interesting hack indeed. Thanks.

Doesn't sound so hard and it would not need any conflicting package nicknames.

Well, I would still need to rename the rex requests themselves as in

(sly-eval `(swank:list-all-package-names t)))

So as to comply with your "part of symbols names" demand and, more importantly, to keep `sly-edit-definition' capabilities.

This last bit is, incidently, one of the drawbacks of your previous solution compared to nicknaming packages, since for anyone looking at the wire (e.g. *events* buffer) strings would SIMPLE-READ to completely disparate symbols. Now, imagine there is indeed a SWANK server running int the Lisp image and the confusion this could cause. Would this be easier to debug than an early abortive "Can't create package because there is a conflict" error?

After having done that, I would need the reverse indirection in `sly-net-send`, and would have to walk the sexp there, since some extensions "abuse" it and send nested sexps.

As I said, not hard, but also not trivial to consider the consequences.

João

Helmut Eller eller.helmut@gmail.com writes:

On Sun, Sep 07 2014, João Távora wrote:

[...]

...

...

Doesn't sound so hard and it would not need any conflicting package nicknames.

Well, I would still need to rename the rex requests themselves as in

(sly-eval `(swank:list-all-package-names t)))

So as to comply with your "part of symbols names" demand and,

With "part of symbols names" I mean those symbols in ELisp that use "slime" or "sldb" as prefix when one would use packages in Common Lisp to make them unique. Apparently you have already renamed most (all?) of those.

I'm still missing the "sldb-" symbols but I have already tried and this presents no big problem. But again, not super-clean either, because there are symbols in the CL namespace that contain "SLDB", and some are user-customizable. I either leave those be or have to implement abstractions.

...

importantly, to keep `sly-edit-definition' capabilities.

This last bit is, incidently, one of the drawbacks of your previous solution compared to nicknaming packages, since for anyone looking at the wire (e.g. *events* buffer) strings would SIMPLE-READ to completely disparate symbols. Now, imagine there is indeed a SWANK server running int the Lisp image and the confusion this could cause. Would this be easier to debug than an early abortive "Can't create package because there is a conflict" error?

People who are debugging some wire format issues probably wouldn't load Swank and slynk (or whatever name you choose) at the same time. At least I wouldn't load any unnecessary components when debugging.

I don't know about that: when an unexpected error happens, the first thing I do is not teardown my environment and start without unnecessary compoenents, because I don't know who those are in the first place.

My view is that people who for some (slightly questionable) reason, do want to have both Swank and the proposed Slynk in the Lisp, can very well add an extra line to their configuration and see

(:emacs-rex (slynk:connection-info) nil t 1)

in the events buffer.

...

After having done that, I would need the reverse indirection in `sly-net-send`, and would have to walk the sexp there, since some extensions "abuse" it and send nested sexps.

That problem is the same for SWANKR or similar servers. The right place to fix such issues is the extension.

Not really, and the problem is not only sexp nesting. sly.el calls interfaces where a second "slimefun" is mentioned like in slime-repl.el's own

(slime-eval-async `(swank:listener-save-value ',slimefun ,@args) ...)

Which is something that I added precisely for compatibility with SWANKR (See the discussion with Christopher Rhodes in https://github.com/slime/slime/issues/140).

Perhaps you consider it abuse -- I don't, hence the quotes earlier -- but it's also very convenient. It allow the proposed Slynk to serve inspection requests for both SLIME and SLY clients. For example, SLY implements multiple inspectors streams with a call like

(sly-eval-async `(swank:eval-for-inspector ,inspector-name ',slimefun ,args))

, which applies SLIMEFUN to ARGS in INSPECTOR-NAME's context. But the SLIME client, who doesn't support multiple inspectors, will still see its SLIMEFUN request honoured as always. And so Slynk remains backward compatible to SLIME clients.

But anyway, changing `sly-net-send' to walk the sexp just before sending doens't seem hard to do, and though I haven't measured, doesn't sound computationally expensive in the RPC context.

João

Helmut Eller eller.helmut@gmail.com writes:

On Fri, Sep 05 2014, João Távora wrote:

...

Helmut Eller eller.helmut@gmail.com writes:

...

Yes, I do: please use something different than Slime and Swank as part of symbol names, package names, or file names.

Sorry, no, unless you provide an argument.

As you very well know, the Emacs side is called SLIME and the Lisp server is called Swank. I also noticed that sldb is used as prefix in sly.el. Please use something different than Slime, Swank, or sldb as part of names.

Those are still not arguments. Xach has provided an argument of convenience which I will consider.

I will also rename "sldb" to "sly-db", the argument (that I'm making on your behalf) being that it pollutes and takes more than the needed share of symbol namespace.

But SLIME does too, so you ought to change it as well. I will also rename prefixless definitions, something that again SLIME is guilty of. slime.el's when-let, for example is in direct conflict with a proposed addition to emacs.

So to summarize your requests are:

* Add license to sly-mrepl.el * sldb -> sly-db * Maybe rename swank to zwank or slynk.

If I missed something please let me know. João

On Fri, Sep 5, 2014 at 9:10 PM, mikel evins mevins@me.com wrote:

On Sep 5, 2014, at 2:41 PM, João Távora joaotavora@gmail.com wrote:

...

...

As you very well know, the Emacs side is called SLIME and the Lisp server is called Swank. I also noticed that sldb is used as prefix in sly.el. Please use something different than Slime, Swank, or sldb as part of names.

Those are still not arguments.

There is the argument that a current maintainer of the project you're forking has asked you to use different names.

Sorry, stack overflow

[I'm sorry I sent the previous reply from my work email]

Cyrus Harmon ch-slime@bobobeach.com writes:

I watched the video. It’s not immediately obvious what’s new here. Nor is it obvious why any nifty features (inspector, trace statistics, etc…) couldn’t be added to slime-contrib without a fork.

Well the video is less than 4 minutes long and a only brief tour. I have been working on this 6+ months and hundreds of commits.

While I personally disagree with you, the goal *is* to make SLY feel familiar to SLIME users, which I think is a fantastic program.

Finally, perhaps you'll change your mind if you try it or I'll make a better description of the features.

Some comments on the motivation for the fork would be helpful.

OK, by popular request :-) here is _a_ comment.

Of course all of this could be possibly be added to SLIME, but not with the freedom that I believe was required for this work.

As a sincere personal side note, I don't think forking a project detracts from the original at all. As a matter of fact the SLIME Hacker's Guide says

Remember that to rewrite a program better is the sincerest form of code appreciation. When you can see a way to rewrite a part of SLIME better, please do so!

João

Cyrus Harmon ch-slime@bobobeach.com writes:

...

Well the video is less than 4 minutes long and a only brief tour. I have been working on this 6+ months and hundreds of commits.

That’s not too surprising.

Precisely, it's not suprising that I can't sum up 6 months of work in a 4 minute demo.

...

While I personally disagree with you, the goal *is* to make SLY feel familiar to SLIME users, which I think is a fantastic program.

I’m not sure how you can disagree that the changes between SLY and slime are not readily apparent from watching the video. You may be intimately familiar with the differences, but your enumerating some of them would certainly be helpful to folks like me.

This is futile and of course it's obvious I can't disagree with your personal perception. I disagree that SLY doens't bring anything new.

If that’s an either/or, I’ll take the better description of the features before I try it. Thanks.

Have you seed the NEWS.md file? It's a bit sketchy as was the screencast, but it might be what you want. Otherwise, suit yourelf.

...

Remember that to rewrite a program better is the sincerest form of code appreciation. When you can see a way to rewrite a part of SLIME better, please do so!

I don’t disagree with the idea of forking, but there needs to be some rationale for the fork. So far I’ve seen defense of the act of forking but neither a description of the motivation for the fork nor a summary of the benefits to the user for using the forked version.

I've given you an answer: I would not find the freedom to make these changes to SLIME. What is hard to understand there? Mind you, if maintained a 10+ old program, I would not give such vast freedom away. But fortunately, free software does give me that freedom.

João