Howdidlydoo,
I'm feeling impulsive lately. How about shooting for a 1.0 release?
I know some people are already in favour (hi Brian :-), so I'm particularly probing for the opinion of the other side (hi Helmut :-)
From my end there are a lot of good omens for an August 27 release:
It will be the one-year anniversary of the first public mention [1] of SLIME. (Time really flies!)
It will be my birthday. (*)
I'll be starting a new job, and be really busy for a while.
How do the tea leaves look for you guys?
Cheers, Luke
[1]: The fateful posting of a tweak to Eric Marsden's SLIM on a list that Helmut reads: http://thread.gmane.org/gmane.lisp.cmucl.devel/3850
(*): How sad is it that I apparently spent my 25th birthday hacking Emacs? :-)
Luke Gorrie luke@bluetail.com writes:
Howdidlydoo,
I'm feeling impulsive lately. How about shooting for a 1.0 release?
I know some people are already in favour (hi Brian :-), so I'm particularly probing for the opinion of the other side (hi Helmut :-)
Yes, would be good to make the 1.0 release before SLIME begins to suffer to much from creeping featurism. It would also be nice to have a completed project (my list of unfinished stuff is depressingly long).
I think Martin Simmons enhancements for LispWorks are ready, and he will commit them in the next few days; perhaps we could make a feature freeze afterwards.
Where should install we SLIME by default? A writable directory would be the easiest for us; not sure if distributors like that.
I don't plan to add much new stuff in the future; the current state seems to satisfy my needs.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Where should install we SLIME by default? A writable directory would be the easiest for us; not sure if distributors like that.
I think Emacs has a canonical place for site local .el and .elc files.
As for the swank end, if it was just a tad more ASDF friendly (no compiling at all when you start SLIME), then writable directory wouldn't be an issue. It could perhaps be made to work with Debian's Common Lisp Controler and with the Lisps that support ASDF-INSTALL.
On Wed, 09 Jun 2004 08:47:34 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at said:
Helmut> Luke Gorrie luke@bluetail.com writes:
Howdidlydoo,
I'm feeling impulsive lately. How about shooting for a 1.0 release?
I know some people are already in favour (hi Brian :-), so I'm particularly probing for the opinion of the other side (hi Helmut :-)
Helmut> Yes, would be good to make the 1.0 release before SLIME begins to Helmut> suffer to much from creeping featurism. It would also be nice to have Helmut> a completed project (my list of unfinished stuff is depressingly Helmut> long).
Helmut> I think Martin Simmons enhancements for LispWorks are ready, and he Helmut> will commit them in the next few days; perhaps we could make a feature Helmut> freeze afterwards.
Done now.
__Martin
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Where should install we SLIME by default? A writable directory would be the easiest for us; not sure if distributors like that.
I hacked swank-loader.lisp to put the fasl files in ~/.slime/fasl/ (on Win32 it's _slime instead). This way we can install in a read-only directory. Sound okay?
I gather that pathname'ery is notoriously non-portable. I've tested this in CMUCL, SBCL, LispWorks, ACL50.
I don't plan to add much new stuff in the future; the current state seems to satisfy my needs.
Likewise. Now I'm more comfortable hacking CL than Elisp and that's my major milestone. I would still like an answer to edebug in Emacs21, but we gotta save something for version 2 :-)
So it seems to be worth interrupting normal hacking for a little while to get a 1.0 release out the door. I propose this release plan:
"alpha" release towards the end of this month: Release a tarball of something FAIRLY-STABLE and encourage as many people as possible to install and bash on it. Major bug-hunting spree, last chance for people to suggest small changes.
"beta" release towards the end of July: Take what we have after alpha and release that. Final round of bug-hunting. Try really hard not to add features.
"1.0" release towards the end of August: If we're satisfied at this point we make a slime-1.0.tar.gz and put it on the 'net. We also try to get it bundled in packaging systems (debian, gentoo, xemacs, etc).
Thoughts?
-Luke
Luke Gorrie luke@bluetail.com writes:
I hacked swank-loader.lisp to put the fasl files in ~/.slime/fasl/ (on Win32 it's _slime instead). This way we can install in a read-only directory. Sound okay?
Yes, I like it.
So it seems to be worth interrupting normal hacking for a little while to get a 1.0 release out the door. I propose this release plan:
"alpha" release towards the end of this month: Release a tarball of something FAIRLY-STABLE and encourage as many people as possible to install and bash on it. Major bug-hunting spree, last chance for people to suggest small changes.
"beta" release towards the end of July: Take what we have after alpha and release that. Final round of bug-hunting. Try really hard not to add features.
"1.0" release towards the end of August: If we're satisfied at this point we make a slime-1.0.tar.gz and put it on the 'net. We also try to get it bundled in packaging systems (debian, gentoo, xemacs, etc).
Thoughts?
Sounds good.
Which versions of the various Lisp to we want to support? The latest released version in June?
Tests for the "essential" features we be nice. It would also be nice if we could write tests for a specific Lisp.
Are there any features we can remove? I was going to suggest removing the REPL (because the code is messy and a REPL is not the Emacs way to interact with anything), but I guess people wouldn't like that :-)
Any outstanding keybinding wars? A while ago we talked about grouping documentation commands under C-c C-d; I like that idea.
Should we make a (final?) try to simplify the connection handling code in swank.lisp? It is not very readable, but I haven't any good ideas to improve it.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Which versions of the various Lisp to we want to support? The latest released version in June?
That would be nice, but I think we should keep the backwards compatibility that we have if people are need it. We're testing with ACL5.0 so we should stay compatible with that if possible, and I think people are using older LispWorksen out of necessity (please confirm!).
Raymond Toy also suggested we shouldn't be too quick to drop CMU18e support, since 19a will want some field testing before it's considered "the right stuff". But 19a won't be out by end of June anyway, but probably will by August. I would love to delete the 18e-compat code but I think we should wait until (immediately) after 1.0.
For SBCL, OpenMCL, CLISP I don't know of any reason to aim for compatibility with older versions.
We should also try to make sure that we'll be forwards-compatible for a while by minimizing our uses of internal functions and hassling implementors not to delete the ones that we still use too quickly :-)
The SBCL backend definitely needs an audit since those guys are so good about making supported interfaces for us.
Tests for the "essential" features we be nice. It would also be nice if we could write tests for a specific Lisp.
Yes. In addition to the fully automated tests it might be good to write an interactive tester that sets up certain situations (file with compiler notes, sldb, etc) and asks you to check certain things manually. I'm not sure. It was helpful in Distel, but then I didn't have any fully-automated tests there.
Are there any features we can remove? I was going to suggest removing the REPL (because the code is messy and a REPL is not the Emacs way to interact with anything), but I guess people wouldn't like that :-)
Amazingly I find myself using the REPL all the time, even though I never use IELM for Emacs Lisp. I'm not sure why.
Any outstanding keybinding wars? A while ago we talked about grouping documentation commands under C-c C-d; I like that idea.
Agree. We should also move hyperspec-lookup so that `C-c C-h' does the default action of listing all bindings starting with C-c, and move the funky-indentation C-M-q command because it's different to the standard indentation command on that binding (does a whole defun, not sexp at point).
Should we make a (final?) try to simplify the connection handling code in swank.lisp? It is not very readable, but I haven't any good ideas to improve it.
Lots of code-cleanups would be good.
I'm still tempted to delete all of the multiple-connections code. It seems to me like the only thing we use multiple-connections-to-one-lisp for is attaching a new connection to a thread, but that seems multiplexable in principle at least. I'll reread what we said about this last time.
-Luke
Luke Gorrie luke@bluetail.com writes:
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Which versions of the various Lisp to we want to support? The latest released version in June?
That would be nice, but I think we should keep the backwards compatibility that we have if people are need it. We're testing with ACL5.0 so we should stay compatible with that if possible, and I think people are using older LispWorksen out of necessity (please confirm!).
I assume you mean that's the oldest ACL you're testing with, not the only one? I'll almost certainly be using (and shipping trial versions of) some fairly recent version of Allegro with my book. Also, are there any issues with Allegro that might benefit from some contact with folks at Franz--I'm not saying I have a lot of pull over there but they are helping me with the book so if there's anything they could do to make SLIME work better on Allegro I might be able to talk to someone.
-Peter
On Thu, 17 Jun 2004 12:16:17 -0700, Peter Seibel peter@javamonkey.com wrote:
Also, are there any issues with Allegro that might benefit from some contact with folks at Franz
I've recently started to use AllegroCL with SLIME and I've seen a couple of issues, yes. (I mainly used CMUCL before but I have to use AllegroCL for this project.)
Unfortunately, most of them aren't easy to reproduce but I'll try to summarize some if I find the time. (I posted one to this list two or three days ago.) I'm using the 7.0 beta - this might also be a reason.
Generally, SLIME seemed much more mature to me when used with CMUCL.
Cheers, Edi.
[Edi, apologies: you've already received a similar reply via email.]
Edi Weitz edi@agharta.de writes:
On Thu, 17 Jun 2004 12:16:17 -0700, Peter Seibel peter@javamonkey.com wrote:
Also, are there any issues with Allegro that might benefit from some contact with folks at Franz
I've recently started to use AllegroCL with SLIME and I've seen a couple of issues, yes. (I mainly used CMUCL before but I have to use AllegroCL for this project.)
Unfortunately, most of them aren't easy to reproduce but I'll try to summarize some if I find the time. (I posted one to this list two or three days ago.) I'm using the 7.0 beta - this might also be a reason.
Generally, SLIME seemed much more mature to me when used with CMUCL.
Yeah. To the extent anyone else kicks the tires with Allegro 7.0 that'd be great--I'm pretty sure the 7.0 final will be the version I'll be shipping with the book so bug reports now to Franz or here will help me out a lot as I don't have much time to program at the moment and thus don't even know how well the SLIME/Allegro implementation works. Though that should change in a couple weeks once I start working on example chapters at which point I'll probably start noticing any gaps in the Allegro implementation.
And if anyone is using Allegro with SLIME, you might consider dropping a note to support@franz.com to let them know that you'll be a happier customer if they do what they can to make it work really well. They tend to be very oriented to keeping their customers happy so if you are actually using Allegro other than to test out SLIME they'll probably be interested to hear about it.
-Peter
Peter Seibel peter@javamonkey.com writes:
And if anyone is using Allegro with SLIME, you might consider dropping a note to support@franz.com to let them know that you'll be a happier customer if they do what they can to make it work really well.
We mailed them yesterday and they've offered licenses to Helmut and I for SLIME development, and that should make things a bit easier. Still, I don't think either of us will be using ACL for our daily hacking so it's not the same as e.g. having Alanr and Gary on OpenMCL and Martin Simmons on LispWorks.
They tend to be very oriented to keeping their customers happy so if you are actually using Allegro other than to test out SLIME they'll probably be interested to hear about it.
*nod*. It would be great if Franz decided SLIME was important for their customers and had a hacker look over our backend and participate in this mailing list.
-Luke
Peter Seibel peter@javamonkey.com writes:
[ACL 5.0]
I assume you mean that's the oldest ACL you're testing with, not the only one?
Yesterday I fired up our ACL backend for the first time ever, I think. I haven't been testing it at all.
Each backend really needs some people to use it and care for it in order for it to work well. A lot of problems will only show up during real usage, and I doubt most people can do serious programming with more than 1-2 backends at a time. I only ever use the CMUCL and SBCL backends except when trying to reproduce a reported bug.
That said, the most important part is finding the bugs. Once they're found it's not so hard to fire up the right Lisp and work on a fix. (But currently 5.0 is the only version of ACL that I'm able to run on my computer - 6.2 doesn't link - so we'll have to wait for a copy of 7.0beta to look at Edi's bug reports.)
Also now that we're headed towards a release we should do some more systematic testing of the various backends. But I think heavy-duty real usage is the most important thing, so I'm really glad that you and Edi will be hammering away on ACL :-)
Caveat: It almost looks like Helmut is actually using every Lisp :-)
-Luke
On Thu, 17 Jun 2004, Luke Gorrie wrote:
Are there any features we can remove? I was going to suggest removing the REPL (because the code is messy and a REPL is not the Emacs way to interact with anything), but I guess people wouldn't like that :-)
Amazingly I find myself using the REPL all the time, even though I never use IELM for Emacs Lisp. I'm not sure why.
This one is easy, I think :-) How often are you curious about the return value of an emacs lisp function given some arguments? If you used emacs lisp for writing (non-editing-related) applications, you'd probably spend a lot more time in ielm buffers.
Andras
Andras Simon andras@renyi.hu writes:
On Thu, 17 Jun 2004, Luke Gorrie wrote:
Amazingly I find myself using the REPL all the time, even though I never use IELM for Emacs Lisp. I'm not sure why.
This one is easy, I think :-) How often are you curious about the return value of an emacs lisp function given some arguments? If you used emacs lisp for writing (non-editing-related) applications, you'd probably spend a lot more time in ielm buffers.
Yeah, that'd explain it. My Elisp evals typically operate on the current buffer/point so I wouldn't run them from IELM.
-Luke
Luke Gorrie wrote:
Raymond Toy also suggested we shouldn't be too quick to drop CMU18e support, since 19a will want some field testing before it's considered "the right stuff". But 19a won't be out by end of June anyway, but probably will by August. I would love to delete the 18e-compat code but I think we should wait until (immediately) after 1.0.
I know this is a little early to start worrying about post 1.0 stuff, but please don't be too eager to dump 18e support. I'm just starting tot propagate SLIME around here and since we use our own version of 18e it'll take a while for us to upgrade. I'm sure there are other shops with similar problems.
Dan Pierson, ITA Software
Dan Pierson dlp@itasoftware.com writes:
I know this is a little early to start worrying about post 1.0 stuff, but please don't be too eager to dump 18e support. I'm just starting tot propagate SLIME around here and since we use our own version of 18e it'll take a while for us to upgrade. I'm sure there are other shops with similar problems.
If you contribute your nice improvements to the main CMUCL tree we'll help you get them working with the latest version in no time :-)
But I don't think there's much to worry about. 19A looks to be very similar to 18E from SLIME's point of view.
Cheers, Luke
On Thu, 17 Jun 2004, Helmut Eller wrote:
Any outstanding keybinding wars? A while ago we talked about grouping documentation commands under C-c C-d; I like that idea.
I don't know if it has come up before, but having conflicting keybindings in Lisp and REPL buffers is quite dangerous. I've been bitten by hitting C-c C-t in the REPL a few times.
Andras
On Wed, 09 Jun 2004 02:43:25 +0200, Luke Gorrie luke@bluetail.com wrote:
I'm feeling impulsive lately. How about shooting for a 1.0 release?
Given the enduring non-availabilty of anonymous CVS[1] the fact that SLIME is only available via CVS makes it kind of difficult for us mere mortals which aren't registered SLIME developers.
I'd be happy if there were at least a nightly snapshot (although cvs update is of course more convenient).
Cheers, Edi.
[1] See recent c.l.l posting and http://security.e-matters.de/advisories/092004.html
On Wed, 9 Jun 2004, Edi Weitz wrote:
Given the enduring non-availabilty of anonymous CVS[1] the fact that SLIME is only available via CVS makes it kind of difficult for us mere mortals which aren't registered SLIME developers.
A bandaid:
As a temprorary workaround for those who have been tracking various projects via CVS we've put up tarballs of the indidual project CVSROOTs at:
http://www.common-lisp.net/cvs_tarballs/
These tarballs are updated every 15 minutes.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time."
On Wed, 9 Jun 2004 22:00:14 +0300 (EEST), Nikodemus Siivola tsiivola@cc.hut.fi wrote:
These tarballs are updated every 15 minutes.
Well, that's certainly good enough for the moment.
Thanks, Edi.
Luke Gorrie luke@bluetail.com writes:
Howdidlydoo,
I'm feeling impulsive lately. How about shooting for a 1.0 release?
I know some people are already in favour (hi Brian :-), so I'm particularly probing for the opinion of the other side (hi Helmut :-)
Well, I'm on the "yea" side but here's my reason: I'm planning to use SLIME in some form in my book. I've been talking with the Lisp In A Box guys about maybe using that and it uses SLIME. So it would be nice if there was a 1.0 SLIME to include on the CD to give my readers the warm fuzzies that come from that magic number. Also, having a stable release that is recognized by other SLIME developers would make my testing, etc. easier since presumably there would be some interest in patching show-stopper bugs in the 1.0 release without requiring me to move forward to the head of the development branch in CVS.
-Peter
-
Andras Simon -
Dan Pierson -
David Steuber -
Edi Weitz -
Helmut Eller -
Luke Gorrie -
Martin Simmons -
Nikodemus Siivola -
Peter Seibel