From: William H. N. <wil...@ai...> - 2004-10-20 16:37:34
|
If we don't discover too much exciting emergent behavior in the next few days, I'll probably release sbcl-0.8.16 next Sunday or Monday. In the meantime, as usual, please avoid excessively exciting innovations in the codebase. -- William Harold Newman <wil...@ai...> They're winning on the basis of execution: The site is always up and it's always fast and you don't get bit by bugs. That's easy to state but it's incredibly hard to do and it requires engineering virtuosity that I just haven't seen equaled by anyone else. -- http://www.tbray.org/ongoing/When/200x/2004/09/28/GoogleYes |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2004-10-20 17:13:46
Attachments:
ppc-darwin-dlshim.h
|
William Harold Newman writes: > If we don't discover too much exciting emergent behavior in the next > few days, I'll probably release sbcl-0.8.16 next Sunday or Monday. In > the meantime, as usual, please avoid excessively exciting innovations > in the codebase. Oops, here's an updated patch to fix building on OS X 10.2 that I've been meaning to send in: |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2004-11-02 01:37:27
|
Thomas F. Burdick writes: > William Harold Newman writes: > > If we don't discover too much exciting emergent behavior in the next > > few days, I'll probably release sbcl-0.8.16 next Sunday or Monday. In > > the meantime, as usual, please avoid excessively exciting innovations > > in the codebase. > > Oops, here's an updated patch to fix building on OS X 10.2 that I've > been meaning to send in: Did anyone have any objections to this patch? If not, uhm, it'd be nice if 0.8.17 built on 10.2 out of the box. |
From: Rick T. <ta...@ui...> - 2004-10-20 18:44:34
|
>> If we don't discover too much exciting emergent behavior in the next >> few days, I'll probably release sbcl-0.8.16 next Sunday or Monday. In >> are callbacks going to be integrated into sbcl in this next release? If not, is there some sort of schedule for this to happen? A few days ago I got an essentially complete gtk2 interface working in sbcl/cmucl/openmcl and it would be nice if I didnt have to include extra callback code for sbcl. Im sure there are lots of other people that would like to see callbacks become part of sbcl's library distribution, if not its core. btw i will make my source-portable gtk2 interface available as soon as i re-integrate some changes due to the linux port back into the openmcl/darwin port. Rick Taube Associate Professor, Composition/Theory School of Music University of Illinois Urbana, IL 61821 USA net: ta...@ui... fax: 217 244 8319 vox: 217 244 2684 |
From: Christophe R. <cs...@ca...> - 2004-10-20 21:20:08
|
Rick Taube <ta...@ui...> writes: >>> If we don't discover too much exciting emergent behavior in the next >>> few days, I'll probably release sbcl-0.8.16 next Sunday or Monday. In > > are callbacks going to be integrated into sbcl in this next release? No. > If not, is there some sort of schedule for this to happen? Not at present. That's not to say that we're not interested in having workable callbacks (just as we're certainly interested in having Unicode support, a working amd64 port, and so on), just that there is at present no schedule. I don't see why we couldn't merge something in the next month, but that rather depends on people with positive opinions about how things /should/ be done convincing other people on this list that their ideas are reasonable -- it's unlikely that a patch coming with lukewarm enthusiasm will make it, but if one comes with a strong endorsement, then it will naturally command more attention. > A few days ago I got an essentially complete gtk2 interface working > in sbcl/cmucl/openmcl and it would be nice if I didnt have to > include extra callback code for sbcl. Having a client for such callback code is a definite help in working out what people actually need. My advice would be not to stress overly about supporting SBCL from the get-go -- unless you have improved on Thomas' work, it won't work in SBCL on many of its platforms anyway -- and there will be another sbcl release along in a month. The important thing is that if you have working code for SBCL, you can give feedback on how good a match it was to your needs, whether anything else in the interface would make your life easier; getting feedback is the best way of hastening a patch's inclusion. > Im sure there are lots of other people that would like to see > callbacks become part of sbcl's library distribution, if not its > core. I'm sure there are too. But from our point of view, while features like this are very welcome, and the more users the better, it's important not to place too high a maintenance load on the SBCL developers -- we do this in our spare time, after all. This affects not just the immediacy with which we can work on any given feature, but also at least my willingness to commit, implicitly or explicitly, to supporting interfaces which I'm not happy with, or which I don't understand, or which I think I'll forget about in a week's time. > btw i will make my source-portable gtk2 interface available as soon > as i re-integrate some changes due to the linux port back into the > openmcl/darwin port. This is very good news, in any case. Do you have any plans to liaise with the gtk+ people on this? I believe they have some sort of framework for evaluating and testing gtk+ bindings. Cheers, Christophe |