From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: Re: development goals Date: Mon, 08 Sep 2008 01:28:28 -0300 Message-ID: References: <87hc90u9lb.fsf@gnu.org> <49dd78620809061545h1a1aa8e4t8e4c10772ab5b137@mail.gmail.com> <49dd78620809071303r148f2aedq6f5b9f3cd4bef3d2@mail.gmail.com> Reply-To: hanwen@xs4all.nl NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220848228 20474 80.91.229.12 (8 Sep 2008 04:30:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Sep 2008 04:30:28 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Sep 08 06:31:23 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KcYPJ-00040q-Pk for guile-devel@m.gmane.org; Mon, 08 Sep 2008 06:31:22 +0200 Original-Received: from localhost ([127.0.0.1]:36460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcYOJ-0004Ae-QC for guile-devel@m.gmane.org; Mon, 08 Sep 2008 00:30:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcYOD-00048q-MR for guile-devel@gnu.org; Mon, 08 Sep 2008 00:30:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcYOD-00048e-50 for guile-devel@gnu.org; Mon, 08 Sep 2008 00:30:13 -0400 Original-Received: from [199.232.76.173] (port=47044 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcYOC-00048b-VN for guile-devel@gnu.org; Mon, 08 Sep 2008 00:30:12 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:50260 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KcYOC-00020e-Cf for guile-devel@gnu.org; Mon, 08 Sep 2008 00:30:12 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KcYO9-0001eG-Mi for guile-devel@gnu.org; Mon, 08 Sep 2008 04:30:09 +0000 Original-Received: from 201.80.3.52 ([201.80.3.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Sep 2008 04:30:09 +0000 Original-Received: from hanwen by 201.80.3.52 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Sep 2008 04:30:09 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 165 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 201.80.3.52 User-Agent: Thunderbird 2.0.0.16 (X11/20080723) In-Reply-To: <49dd78620809071303r148f2aedq6f5b9f3cd4bef3d2@mail.gmail.com> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7619 Archived-At: Neil Jerram escreveu: > 2008/9/7 Han-Wen Nienhuys : >> OK - I will admit that interpreter/GC hacking is cool, but on the >> downside, when I try to do anything, the intertia/resistance I feel in >> the community here is a big turnoff for me. > > Do you mean regarding releases (as you say more on below)? Or/also > the mailing list dynamic/responsiveness? Anything else? For a large patch (like the disputed GC patch), I got criticism of the process I used to push it and complaints that it had multiple fixes collated together. I was expecting criticism about what it changed, i.e. I was hoping for more insightful comments. It's hard to take criticism seriously if it is only about cosmetics. Also, the general idea that patches can only be committed if they are 'perfect' is not conducive to more rapid development. I was rather shocked that the idea of rolling back the change was considered a better option than adding further fixes on top of it. For example, there was the issue of x86_64 being broken by the asserts. I read complaints on the list, I got scolded at by Ludovic, and a week later the code was still there. I posted a proposed patch (a single #ifdef!), to which I didn't receive a single comment. When I finally committed, I got a complaint that the commit message did not have the right formatting. Apparently: - Rolling back a patch is preferred over fixing actual problems. - Nobody has enough initiative to put a single strategic #ifdef in the code. - If someone finally does take initiative, it's only ok if it is perfect. I try not to goof up when pushing lilypond patches, but I do, up to committing code that does not compile (yes, sue me). When that happens, generally people push simple fixes - there are 24 people with push access, of whom 16 or so are active. The people that push generally ask for review if they are unsure of what they are doing, but when they feel certain, they do without asking; I like that, because I don't have enough time to police the master branch. At ~15 commits per day I don't have time for that. At times, I have to request some corrections (missing regression tests, style issues), but that is rare, and when I do I get prompt responses, with the perpetrators pushing fixes on their own initiative. There also are people that I know and trust to have full competence. For example, Joe Neeman has rewritten all of the vertical spacing code in Lily, and I don't pretend to judge or really understand his code when he pushes. You might construe that I would like to turn Guile development into LilyPond development. That is not necessarily the case, but I keep misunderstanding what people expect in this community. I am assuming that developers in general are interested in a more lively and more rapid evolution of Guile, but everytime I see habits and policies that seem contrary to that goal. >>> FWIW, I would like to run my code on other schemes -- not the same goal >>> as this one, but it overlaps considerably. For me, I think that the path >>> will be implementation of some scheme standard that supports modules, >>> then migrating code over to that standard. I'm not sure about R6 though. >> Is there a Rx/SRFI standard for modules? I always thought that module >> system(s) was one of the unspecified areas. > > R6RS specifies libraries, which are similar to modules. (But probably > much cleverer for separate compilation, and vastly more complicated in > their semantics.) Hmm .. curious, I thought one of the objectives of Scheme was simplicity. >> When working with the devs here I continue to be puzzled by what the >> objectives are. For instance, we had 5 major (stable) releases in 11 >> years. I have always wanted this rate to go up, and have tried argue >> for that, but with 1.10 (or 2.0, whatever it is called) being in >> preparation for 2.5 years at this moment, I don't see this changing. > > For me, almost all of my time since becoming a maintainer has been > absorbed by working on bug fixes, largely to do with slightly odd > platforms (e.g. Mac) or architectures (e.g. ia64). IMO it was > worthwhile to focus on such bug reports soon after they were reported, > because (i) the reporters are still around and interested enough to be > able to provide more info and test fixes, (ii) I believe that running > on more platforms will be good for the Guile community, and for Guile > applications. FWIW, I am shipping lilypond cross compiled on linux (ppc, x86_64, x86) darwin (ppc, x86), mingw and freebsd (x86, x86_64). The stable release is mostly working for that. > Basically, my feeling is that Guile users have been badly burned by > major release incompatibilities in the past, and I really don't want > that to happen again. Therefore my "straw man" plan is that If anything, you should listen to your current users. If you don't listen to your current users, they will leave, and you won't be left with any. I'm one of the current users, and compatibility is the least of my concerns. But don't take my word. You should go out and ask other users too. I remember talking to Joris vd Hoeven (texmacs) several years ago, and his complaint was that GUILE was very slow. I didn't hear him mention compatibility issues once > - we stay on 1.8.x for a while > [..] >> At such a glacial pace of development, you would imagine that backward >> compatibility would not be a concern > > Huh? That makes no sense to me. Small projects don't live long enough to span 2 incompatible GUILE releases. The projects that do live long enough are few. (LilyPond & gnucash come to mind). >> - after all, who plans for >> compatibility over a five year span, > > I believe that programmers' natural tendency is to plan for infinite > compatibility. > >> yet Guile continues to support >> (by default!) the GH interface which was deprecated in 2002 (or was it >> with version 1.4 in 2000?). > > There you're right. We can and should rip GH out now. Actually that > might make an excellent first example for documenting incompatibility. > (Anyone who really still needs it can take on the burden of > maintaining the GH layer themselves.) I probably wouldn't bother too much with documenting incompatibility; bumping the version number to 2.0 is an easier way to deal with that. Then again, as noted before, I am confrontational. >> For LilyPond (and any other package that uses Guile, eg. texmacs, >> snd), this is a problem, since we can not realistically ship anything >> that requires the latest Git/CVS version to work. Hence, my >> improvements in LilyPond are held back by Guile's release scheme. For >> example, I wanted to use SCM rationals for various purposes in Lily >> for a long time, but had to wait for the 1.8 release before I could do >> this. > > Are there items in master now that you are particularly wanting / > waiting for? I guess the GC is one, any others? At the moment the GC fixes are one thing. Maybe I should look into backporting them, but the changes will be somewhat large. There is nothing really significant in the tree that I need desparately, but I did contribute some features (a hook for memoize symbol) that I believe did not make 1.8. I used those for measuring coverage of the lilypond test suite. Then again, with all the back & forth porting of changes between 1.8 and head, it's difficult to tell what is in 1.8 and what is not. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen