From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Daniel Skarda <0rfelyus@ucw.cz> Newsgroups: gmane.lisp.guile.devel Subject: Re: Adding stuff to the core distro (was Re: Infix syntax) Date: 10 Oct 2002 18:06:17 +0200 Sender: guile-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034268013 2676 127.0.0.1 (10 Oct 2002 16:40:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 10 Oct 2002 16:40:13 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17zgM3-0000gI-00 for ; Thu, 10 Oct 2002 18:40:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17zgJG-0001e2-00; Thu, 10 Oct 2002 12:37:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17zgIw-0000y9-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 12:36:54 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17zgIu-0000wZ-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 12:36:54 -0400 Original-Received: from stateless1.tiscali.cz ([213.235.135.70] helo=mail.tiscali.cz) by monty-python.gnu.org with esmtp (Exim 4.10) id 17zgIu-0000ve-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 12:36:52 -0400 Original-Received: from hobitin.ucw.cz (212.11.106.11) by mail.tiscali.cz (6.0.044) id 3DA29C7F0007C003; Thu, 10 Oct 2002 18:35:24 +0200 Original-Received: from 0rfelyus by hobitin.ucw.cz with local (Exim 3.36 #1 (Debian)) id 17zfpJ-0000Cw-00; Thu, 10 Oct 2002 18:06:17 +0200 Original-To: Neil Jerram Original-Lines: 87 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1519 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1519 > On the other hand... Rob has raised the question of whether we should > be adding things to the core distro that don't strictly need to be > there, so perhaps we should stop for a moment to consider our > principles on this point. > > I'm not sure what to suggest, myself. Seems to me that one extreme is > the Emacs approach - basically bundle everything. The convenience of > the opposite extreme depends on what kind of package repository system > (aka GUMM) we can create. I vote for Emacs approach - bundle everything that is mature, documented and stable. Before you reply that my message was driven by megalomania, I try to explain my view: Scheme is very pretty language, but I think that these days "pretty language" does not imply success. Also libraries that come with language are important as well. So we should not see Guile as a single package but rather as a development platform. The development platform that is not as popular as other (python, perl) ... I my opinion, breaking guile into small (orthogonal) packages is nice from "pure" developer's view, but it fails in "real world" and builds unnecessary walls between Guile and Joe Average Programmer, who wants to evaluate Guile: "Install guile-x.y, guile-foo-y.z, guile-bar-a.b. Joe, do you want to use feature XYZ? than you have to checkout, compile, install guile-CVS, checkout guile-foo-CVS, because guile-foo-y.z does not work with guile-CVS... Also users of your program must do the same because there are no Debian/RedHat/... packages for development versions." Do you think that Mr Joe A. Programmer will choose Guile because Scheme is superior language and "Official GNU blah blah blah"? I think programmers want to start coding, not to spend their time collecting/ maintaining/upgrading various tiny packages. Also Guile development would be easier with "one big development pot": * Read "guile-debugger" thread on guile-devel. Even developers have not known that there is guile-debugger package. "One big pot" means less probability you miss some important package, because have not noticed its announcement or reference deep inside the Guile documentation. * When somebody changes (read: improves :-) some interface, it is easier to spot and fix all places, where the change breaks actual code. Even thought a developer, who was responsible for some feature, retires, code from big pot will not become orphan (there is always somebody who fixes it). * It saves us a lot of time. cvs update -dP, autogen, configure, make, make install, cvs update, autoget, configure, make install, .... * "One big pot" also simplifies dependecies (see Joe's example). And there is no need for a lot of #ifdef GUILE_HAS_FOO_FEATURE, #ifdef GUILE_1_x_y,.. which are hell to maintain. So these were my arguments I could think of. Please try to write down your oppinions. I would also like to hear arguments from "the other side" (break Guile into small and orthogonal packages), but I can not think of any benefit that would come from scattered development (except specific "beauty"). IMHO it is easier to write script, that extracts small subset from guile-core, than to maintain zillions of small packages (think: guile-core, guile-infix, guile-srfi-1, guile-srfi-*, guile-readline, guile-.....) 0. ps: It would be also nice to "release Guile regularly, release Guile often". I would like to propose to release Guile development branch monthly (or every fortnight). At least for some time, so we can find if this approach is an advantage or not. Also detailed development roadmap (timeline, schedule) would be very helpful. ps: Another successful example of "big development pot" is Linux kernel (or XFree project). ps: Example of tools/utils/code I would merge into Guile immediately or ASAP: g-wrap, build-guile-gtk script or any other tool for making language bindings. There are plenty of them and it is strange that there is no standard one. Also sgtk_flags2scm family of C utils would be helpful. (When I say "merge" here, I do not mean to merge directly into libguile, but merge into guile-core as libguiletools or something like that). ps: Maybe "hybrid" approach would be the best way. Bundle everything possible, but also provide an easy way for creating/distributing/maintaining Guile packages (and a repository to archive them). _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel