[Slime-devel] SLY, a fork of SLY
Hi list, For some time now, I've been working on SLY, a fork of SLIME. I believe it is ready to go live now. There's a screencast at https://www.youtube.com/watch?v=xqWkVvubnSI and the project page lives at github http://github.com/capitaomorte/sly.git SLY forked around SLIME 2.4 and is currently on-par with bugfixes in SLIME 2.9. It will continue to track SLIME's bugfixes. A list of changes SLY is available in its NEWS.md file. SLY is still alpha for now. I believe I have done everything right fork-wise, maintaining the licensing notice, crediting the original authors prominently in the README and in any commits cherry-picked from this project. Nevertheless, I invite the current SLIME maintainers to double check-check and notify me so that I can correct any mistakes. Thanks João
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.
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. Helmut
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
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
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
-- João Távora
João Távora <joaotavora@gmail.com> writes:
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"
That's good, but I think Quicklisp availability has some advantages, too. Quicklisp supports going back to previous versions, for example; you can say "Give me the library state-of-the-world from June, 2013" and match it up to a project's API requirements. I'm not that familiar with the Emacs package system, so maybe it provides something like that, too. Zach
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
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. João PS: Your request is satisfied, to the best of my knowledge, for "SLIME", the project, but for for "swank".
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
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) João
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
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?
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.
On Fri, 5 Sep 2014, 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?
A cross between a lynx and a slinky? Regards, Faheem
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.
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. people should rarely want to load two versions of the same project/functionality into the same image, and IMO the benefits of being able to cherry-pick patches both direction is bigger than the loss of the ability to load both projects into the same image/emacs. please note that i don't argue against renaming the .asd file (small change), but i do argue against renamings that touche on every second line of the code. but it won't be my headache, just throwing around my two cents. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Here's a way to tell scientific intelligence from legal intelligence. Both may start from the idea that something cannot be done and think up arguments to explain why. However, it is possible that the scientist may discover a flaw in the argument that leads him to change his mind and discover a way to do it. He will be pleased. The legal thinker will merely try to patch the flaw in the argument, because once he has chosen a side, all his intelligence is devoted to finding arguments for that side.” — John McCarthy
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
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. Doesn't sound so hard and it would not need any conflicting package nicknames. Helmut
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
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.
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.
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. Helmut
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
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.
João
PS: Your request is satisfied, to the best of my knowledge, for "SLIME", the project, but for for "swank".
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. Helmut
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 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.
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 -- João Távora
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. Some comments on the motivation for the fork would be helpful. thanks, Cyrus On Sep 5, 2014, at 9:37 AM, João Távora <joaotavora@gmail.com> wrote:
Hi list,
For some time now, I've been working on SLY, a fork of SLIME. I believe it is ready to go live now. There's a screencast at
https://www.youtube.com/watch?v=xqWkVvubnSI
and the project page lives at github
http://github.com/capitaomorte/sly.git
SLY forked around SLIME 2.4 and is currently on-par with bugfixes in SLIME 2.9. It will continue to track SLIME's bugfixes.
A list of changes SLY is available in its NEWS.md file. SLY is still alpha for now.
I believe I have done everything right fork-wise, maintaining the licensing notice, crediting the original authors prominently in the README and in any commits cherry-picked from this project.
Nevertheless, I invite the current SLIME maintainers to double check-check and notify me so that I can correct any mistakes.
Thanks João
_______________________________________________ Slime-devel mailing list Slime-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/slime-devel
[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
On Sep 5, 2014, at 10:43 AM, João Távora <joaotavora@gmail.com> wrote:
[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.
That’s not too surprising.
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. (Hopefully there’s not too much room for disagreement with this assertion, except possibly the fact that there might not be many folks like me).
Finally, perhaps you'll change your mind if you try it or I'll make a better description of the features.
If that’s an either/or, I’ll take the better description of the features before I try it. Thanks.
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.
To each their own.
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!
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. thanks, Cyrus
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
participants (9)
-
Attila Lendvai -
Cyrus Harmon -
Faheem Mitha -
Helmut Eller -
Jeff Cunningham -
joaotavora＠gmail.com -
João Távora
-
mikel evins -
Zach Beane