Hello Helmut,
I would like to suggest that the slime-fancy contrib be loaded by default. Some of those features have become rather fundamental to me and, I suspect, to many other SLIME users as well.
IMHO, it would be unfortunate if newcomers didn't get to experience the CLOS inspector, autodoc, presentations, the REPL(!), etc, because of inadequate default settings. I believe said newcomers will quite likely find SLIME somewhat anemic and underwhelming.
I hope you take this suggestion into consideration and I'd be glad to prepare a patch with the necessary trivial changes to slime.el and slime.texi.
Thanks.
Luis Oliveira luismbo@gmail.com writes:
Hello Helmut,
I would like to suggest that the slime-fancy contrib be loaded by default. Some of those features have become rather fundamental to me and, I suspect, to many other SLIME users as well.
The key word for me here is "some". I don't use slime-fancy; I load the contribs I want, and only the contribs I want. I'd prefer it stayed that way.
Zach
Zach Beane xach@xach.com writes:
Luis Oliveira luismbo@gmail.com writes:
Hello Helmut,
I would like to suggest that the slime-fancy contrib be loaded by default. Some of those features have become rather fundamental to me and, I suspect, to many other SLIME users as well.
The key word for me here is "some". I don't use slime-fancy; I load the contribs I want, and only the contribs I want. I'd prefer it stayed that way.
I think Luis was arguing that (slime-setup) should be made equivalent to (slime-setup '(slime-fancy)).
(slime-setup '(slime-foo slime-bar)) should load the contribs `slime-foo' and `slime-bar', and only those.
-T.
"Tobias C. Rittweiler" tcr@freebits.de writes:
Zach Beane xach@xach.com writes:
Luis Oliveira luismbo@gmail.com writes:
Hello Helmut,
I would like to suggest that the slime-fancy contrib be loaded by default. Some of those features have become rather fundamental to me and, I suspect, to many other SLIME users as well.
The key word for me here is "some". I don't use slime-fancy; I load the contribs I want, and only the contribs I want. I'd prefer it stayed that way.
I think Luis was arguing that (slime-setup) should be made equivalent to (slime-setup '(slime-fancy)).
I understand and disagree.
Zach
What about listing the features that currently are/aren't included by default? For example I was surprised to see the REPL moved to contrib. It would be easier to understand/frame the discussion that way (at least for me :-) ).
Thanks,
Glenn
V. Glenn Tarcea gtarcea@umich.edu
On Dec 27, 2008, at 9:20 PM, Zach Beane wrote:
"Tobias C. Rittweiler" tcr@freebits.de writes:
Zach Beane xach@xach.com writes:
Luis Oliveira luismbo@gmail.com writes:
Hello Helmut,
I would like to suggest that the slime-fancy contrib be loaded by default. Some of those features have become rather fundamental to me and, I suspect, to many other SLIME users as well.
The key word for me here is "some". I don't use slime-fancy; I load the contribs I want, and only the contribs I want. I'd prefer it stayed that way.
I think Luis was arguing that (slime-setup) should be made equivalent to (slime-setup '(slime-fancy)).
I understand and disagree.
Zach
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Zach Beane xach@xach.com writes:
The key word for me here is "some". I don't use slime-fancy; I load the contribs I want, and only the contribs I want. I'd prefer it stayed that way.
I guess I wasn't as clear as I could have been. My proposal is basically something like this:
< (defun slime-setup (&optional contribs) ---
(defun* slime-setup (&optional (contribs '(slime-fancy)))
I'm not proposing that slime-fancy should forced on everyone. I'm just suggesting that it (or some subset thereof) should be loaded *by default*. Anemic SLIME would be just one (slime-setup nil) away.
Luis Oliveira luismbo@gmail.com writes:
Zach Beane xach@xach.com writes:
The key word for me here is "some". I don't use slime-fancy; I load the contribs I want, and only the contribs I want. I'd prefer it stayed that way.
I guess I wasn't as clear as I could have been. My proposal is basically something like this:
< (defun slime-setup (&optional contribs)
(defun* slime-setup (&optional (contribs '(slime-fancy)))
I'm not proposing that slime-fancy should forced on everyone. I'm just suggesting that it (or some subset thereof) should be loaded *by default*. Anemic SLIME would be just one (slime-setup nil) away.
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
Zach
Zach Beane wrote, On 28/12/08 3:43 PM:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
I agree with you. I have just set up the default installation of the slime plugin for Aquamacs to load slime-fancy and some other contrib modules. Even though I like slime-fancy enough to do that, I would not want to confuse people by having the loading of some set of modules hidden in a default value of an optional argument. This way, whatever we choose for the default installation on slime on Aquamacs will be explicit in the setup-slime call in the initialization file and easily modified by anyone who has different preferences.
-- sidney
Sidney Markowitz sidney@sidney.com writes:
Zach Beane wrote, On 28/12/08 3:43 PM:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
I agree with you. I have just set up the default installation of the slime plugin for Aquamacs to load slime-fancy and some other contrib modules.
You think slime-fancy shouldn't be loaded by default, yet you make it so in your plugin? That doesn't make a lot of sense to me. clbuild loads slime-fancy by default as well, and I've seen that setup being recommended in #lisp and c.l.l before. Clearly, for a lot of users, that is the de facto default. Why not take it a step further?
Even though I like slime-fancy enough to do that, I would not want to confuse people by having the loading of some set of modules hidden in a default value of an optional argument.
I fail to see how that's confusing, really. Particularly if it's documente. That's how default settings work. That's what 'by default' means, IIUC.
This way, whatever we choose for the default installation on slime on Aquamacs will be explicit in the setup-slime call in the initialization file and easily modified by anyone who has different preferences.
You are free to keep an explicit contrib list in your Aquamacs setup. My proposal doesn't harm that freedom at all.
Luis Oliveira wrote, On 28/12/08 11:53 PM:
You think slime-fancy shouldn't be loaded by default, yet you make it so in your plugin? That doesn't make a lot of sense to me.
I should preface my remarks by saying that I don't think that this is a very important decision. Even though I am stating a preference, I don't think that it would be a bad thing for the Slime maintainers to decide it your way. So please put my arguments in that context.
From the perspective of Slime as a project I don't think that
unsupported contrib modules should be loaded by default. If the maintainers want to structure Slime so that it is in separate modules that are loaded by (slime-setup) then those modules should go into some other directory than contrib and be officially maintained. I take it that REPL was moved into contrib not just because of a refactoring of the code into separate pieces, but also because it is not being maintained as part of SLIME. Putting it into contrib and not loading it with the default call to slime-setup makes it clear what its status is.
That is a separate issue from how the Aquamacs developers choose to configure an optional Slime plugin for Aquamacs.
I fail to see how that's confusing, really. Particularly if it's documente. That's how default settings work. That's what 'by default' means, IIUC.
The confusing part is in loading non-maintained code that potentially could disappear if it gets out of sync with Slime itself. I don't think that loading anything from contrib should be default behaviour.
You are free to keep an explicit contrib list in your Aquamacs setup. My proposal doesn't harm that freedom at all.
Yes, I agree that the choice of defaults for slime-setup would not affect how Aquamacs sets up its Slime optional plugin. That's part of why I say that I don't consider this a crucial decision either way. But that also means, I think, that it makes it more a matter of aesthetics and the personal inclinations of the Slime maintainers.
If most software distributions that include Slime do package it to load the same certain contrib modules by default and there are people maintaining those modules with whom the mainline Slime maintainers are willing to work and to whom they are willing to give commit privileges, then it would make sense to move them from contrib into some other directory and load them with (slime-setup).
-- sidney
Sidney Markowitz sidney@sidney.com writes:
Luis Oliveira wrote, On 28/12/08 11:53 PM:
You think slime-fancy shouldn't be loaded by default, yet you make it so in your plugin? That doesn't make a lot of sense to me.
I should preface my remarks by saying that I don't think that this is a very important decision. Even though I am stating a preference, I don't think that it would be a bad thing for the Slime maintainers to decide it your way. So please put my arguments in that context.
Sorry if my previous email came off a bit rude.
From the perspective of Slime as a project I don't think that unsupported contrib modules should be loaded by default.
Agreed! I guess that my point, then, is that some of those modules should be supported. But, since I have only contributed very minor changes to SLIME, I'm not in a good position to pursue that argument. In any case, I don't have any personal reason to complain, SLIME works wonderfully for me.
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
That works for as long as the contribs are the fancy chrome, not the core essentials. Of course different people are going to have different opinions on what's a core essential feature, but I really fail to see the point of a CL ide without a repl.
The motivation of splitting it out into a contrib was apparently to allow people to replace the whole repl implementation if needed, and that seems fair enough. But it seems incredibly user-hostile to but the burden of figuring out "oh, I need the repl module" on new users, instead of on the one person on the planet who is going to write his own replacement repl. So maybe some subset of contribs should be loaded by default.
And I don't think I'm whining about this just due to the sbcl repl being unusable by itself.
Juho Snellman jsnell@iki.fi writes:
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
That works for as long as the contribs are the fancy chrome, not the core essentials. Of course different people are going to have different opinions on what's a core essential feature, but I really fail to see the point of a CL ide without a repl.
Me neither. I think it's foolish not to have the slime repl in the core of slime. I'd prefer some other way to make it loaded by default than loading slime-fancy by default.
Zach
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
Perhaps we could agree on another set of contribs then?
Luis Oliveira luismbo@gmail.com writes:
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
Perhaps we could agree on another set of contribs then?
Maybe it's the terminology that bugs me. I think of contribs as handy but inessential add-ons to SLIME. I think essentials should be loaded by default, and add-ons, however useful, shouldn't.
I think the REPL is essential.
Zach
Luis Oliveira wrote:
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
Perhaps we could agree on another set of contribs then?
Ok, then please don't load slime-fancy by default, as it does not work with LispWorks, without applying some patches by Johannes Grødem and Peder O. Klingenberg that can be found on this list dated back in 2007. It would be very difficult for newcomers to find out that it is slime-fancy that is the problem.
I don't know why these patches are not approved for inclusion yet.
On Mon, 29 Dec 2008 15:09:56 +0100, knobo said:
Luis Oliveira wrote:
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
Perhaps we could agree on another set of contribs then?
Ok, then please don't load slime-fancy by default, as it does not work with LispWorks, without applying some patches by Johannes Grødem and Peder O. Klingenberg that can be found on this list dated back in 2007. It would be very difficult for newcomers to find out that it is slime-fancy that is the problem.
I don't know why these patches are not approved for inclusion yet.
I tried loading CVS HEAD slime-fancy into LispWorks 5.1.2 and I've not seen any errors yet. The REPL, completion and source location work as expected, but I've not tested everything. Can you post links to the patches please?
* Martin Simmons 200901081912.n08JC9sM006644@higson.cam.lispworks.com : Wrote on Thu, 8 Jan 2009 19:12:09 GMT:
|>>>>> On Mon, 29 Dec 2008 15:09:56 +0100, knobo said: |> |> Luis Oliveira wrote: |> > Zach Beane xach@xach.com writes: |> > |> >> I disagree. I think the default slime setup should have no contribs |> >> loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded. |> > |> > Perhaps we could agree on another set of contribs then? |> > |> Ok, then please don't load slime-fancy by default, as it does not work |> with LispWorks, without applying some patches by Johannes Grødem and |> Peder O. Klingenberg that can be found on this list dated back in 2007. |> It would be very difficult for newcomers to find out that it is |> slime-fancy that is the problem. |> |> I don't know why these patches are not approved for inclusion yet. | | I tried loading CVS HEAD slime-fancy into LispWorks 5.1.2 and I've not seen | any errors yet. The REPL, completion and source location work as expected, | but I've not tested everything. Can you post links to the patches please?
Here is what I load into slime after slime loads (I'm still using older slime and have not updated to CVS HEAD) but the first issue is likely unchanged.
#|| BASED ON SUGGESTIONS: From: Johannes Groedem johs@netfonds.no Newsgroups: gmane.lisp.slime.devel Subject: Re: fancy inspector problems Date: Mon, 17 Sep 2007 15:40:40 +0200 Archived-At: http://permalink.gmane.org/gmane.lisp.slime.devel/6696 ||#
;;; ;;; patch swank-lispworks.lisp ;;; (in-package "SWANK-BACKEND")
;; we have imported '(slot-boundp-using-class slot-value-using-class) ;; from :clos into swank-mop via import-swank-mop-symbols. i.e. ;; (import '(clos::slot-value-using-class) :swank-mop) ;; (import '(clos::slot-boundp-using-class) :swank-mop)
(assert (eq 'clos::slot-value-using-class 'swank-mop::slot-value-using-class)) (assert (eq 'clos::slot-boundp-using-class 'swank-mop::slot-boundp-using-class))
(when (eq 'clos::slot-value-using-class 'swank-mop::slot-value-using-class) (unintern 'swank-mop::slot-value-using-class :swank-mop)) (export 'swank-mop::slot-value-using-class :swank-mop)
(when (eq 'clos::slot-boundp-using-class 'swank-mop::slot-boundp-using-class) (unintern 'swank-mop::slot-boundp-using-class :swank-mop)) (export 'swank-mop::slot-boundp-using-class :swank-mop)
(defun swank-mop:slot-boundp-using-class (class object slotd) (clos::slot-boundp-using-class class object (clos:slot-definition-name slotd)))
(defun swank-mop:slot-value-using-class (class object slotd) (clos::slot-value-using-class class object (clos:slot-definition-name slotd)))
;;; ;;; patch fancy-inspector ;;;
(in-package :swank) (defgeneric inspect-slot-for-emacs (class object slot) (:method (class object slot) (let ((slot-name (swank-mop:slot-definition-name slot)) (boundp (swank-mop:slot-boundp-using-class class object slot))) `(,@(if boundp `((:value ,(swank-mop:slot-value-using-class class object slot))) `("#<unbound>")) " " (:action "[set value]" ,(lambda () (with-simple-restart (abort "Abort setting slot ~S" slot-name) (let ((value-string (eval-in-emacs `(condition-case c (slime-read-object ,(format nil "Set slot ~S to (evaluated) : " slot-name)) (quit nil))))) (when (and value-string (not (string= value-string ""))) (setf (swank-mop:slot-value-using-class class object slot) (eval (read-from-string value-string)))))))) ,@(when boundp `(" " (:action "[make unbound]" ,(lambda () (swank-mop:slot-makunbound-using-class class object slot)))))))))
On Fri, 09 Jan 2009 09:40:31 +0530, Madhu said:
;;; ;;; patch fancy-inspector ;;;
(in-package :swank) (defgeneric inspect-slot-for-emacs (class object slot) (:method (class object slot) (let ((slot-name (swank-mop:slot-definition-name slot)) (boundp (swank-mop:slot-boundp-using-class class object slot))) `(,@(if boundp `((:value ,(swank-mop:slot-value-using-class class object slot))) `("#<unbound>")) " " (:action "[set value]" ,(lambda () (with-simple-restart (abort "Abort setting slot ~S" slot-name) (let ((value-string (eval-in-emacs `(condition-case c (slime-read-object ,(format nil "Set slot ~S to (evaluated) : " slot-name)) (quit nil))))) (when (and value-string (not (string= value-string ""))) (setf (swank-mop:slot-value-using-class class object slot) (eval (read-from-string value-string)))))))) ,@(when boundp `(" " (:action "[make unbound]" ,(lambda () (swank-mop:slot-makunbound-using-class class object slot)))))))))
I didn't use this part of the patch because it looks like it is only needed to fix package issues.
Martin Simmons martin@lispworks.com writes:
On Mon, 29 Dec 2008 15:09:56 +0100, knobo said:
Luis Oliveira wrote:
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
Perhaps we could agree on another set of contribs then?
Ok, then please don't load slime-fancy by default, as it does not work with LispWorks, without applying some patches by Johannes Grødem and Peder O. Klingenberg that can be found on this list dated back in 2007. It would be very difficult for newcomers to find out that it is slime-fancy that is the problem.
I don't know why these patches are not approved for inclusion yet.
I tried loading CVS HEAD slime-fancy into LispWorks 5.1.2 and I've not seen any errors yet. The REPL, completion and source location work as expected, but I've not tested everything. Can you post links to the patches please?
Full thread on gmane is here:
http://thread.gmane.org/gmane.lisp.slime.devel/6653/
Initial patch by Johannes Grødem in that thread:
http://article.gmane.org/gmane.lisp.slime.devel/6696
Later update by me:
http://article.gmane.org/gmane.lisp.slime.devel/7415
...Peder...
Martin Simmons wrote:
On Mon, 29 Dec 2008 15:09:56 +0100, knobo said:
Luis Oliveira wrote:
Zach Beane xach@xach.com writes:
I disagree. I think the default slime setup should have no contribs loaded, not the arbitrary slime-fancy kitchen sink of contribs loaded.
Perhaps we could agree on another set of contribs then?
Ok, then please don't load slime-fancy by default, as it does not work with LispWorks, without applying some patches by Johannes Grødem and Peder O. Klingenberg that can be found on this list dated back in 2007. It would be very difficult for newcomers to find out that it is slime-fancy that is the problem.
I don't know why these patches are not approved for inclusion yet.
I tried loading CVS HEAD slime-fancy into LispWorks 5.1.2 and I've not seen any errors yet. The REPL, completion and source location work as expected, but I've not tested everything. Can you post links to the patches please?
It's been long time since I have tried without the patch, but I think you'll get an error if you try to inspect objects with unbound slots.
Tell me if you need any more information.
* Luis Oliveira [2008-12-28 03:03+0100] writes:
I guess I wasn't as clear as I could have been. My proposal is basically something like this:
< (defun slime-setup (&optional contribs)
(defun* slime-setup (&optional (contribs '(slime-fancy)))
I'm not proposing that slime-fancy should forced on everyone. I'm just suggesting that it (or some subset thereof) should be loaded *by default*. Anemic SLIME would be just one (slime-setup nil) away.
We could change the README file so that it includes (slime-setup '(slime-fancy)) or some other list of contribs.
Helmut.
-
Glenn Tarcea -
Helmut Eller -
Juho Snellman -
Knut Olav Bøhmer -
Luis Oliveira -
Madhu -
Martin Simmons -
peder＠klingenberg.no -
Sidney Markowitz -
Tobias C. Rittweiler -
Zach Beane