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: 17 Oct 2002 02:10:48 +0200 Sender: guile-devel-admin@gnu.org Message-ID: References: <87u1jub4lh.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034991739 10171 80.91.224.249 (19 Oct 2002 01:42:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 19 Oct 2002 01:42:19 +0000 (UTC) Cc: Neil Jerram , guile-devel@gnu.org, Lynn Winebarger 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 182id7-0002ds-00 for ; Sat, 19 Oct 2002 03:42:17 +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 182ibK-0006j6-00; Fri, 18 Oct 2002 21:40:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 182iao-0006ai-00 for guile-devel@gnu.org; Fri, 18 Oct 2002 21:39:54 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 182ial-0006aH-00 for guile-devel@gnu.org; Fri, 18 Oct 2002 21:39:53 -0400 Original-Received: from gnudist.gnu.org ([199.232.41.7]) by monty-python.gnu.org with esmtp (Exim 4.10) id 182bkI-000879-01 for guile-devel@gnu.org; Fri, 18 Oct 2002 14:21:14 -0400 Original-Received: from stateless3.tiscali.cz ([213.235.135.72] helo=mail.tiscali.cz) by gnudist.gnu.org with esmtp (Exim 4.10) id 1820oY-0000Cp-00 for guile-devel@gnu.org; Wed, 16 Oct 2002 22:55:10 -0400 Original-Received: from hobitin.ucw.cz (212.11.106.92) by mail.tiscali.cz (6.0.044) id 3D76F544002DBBF0; Thu, 17 Oct 2002 04:46:07 +0200 Original-Received: from 0rfelyus by hobitin.ucw.cz with local (Exim 3.36 #1 (Debian)) id 181yFU-0000MM-00; Thu, 17 Oct 2002 02:10:48 +0200 Original-To: Rob Browning In-Reply-To: <87u1jub4lh.fsf@raven.i.defaultvalue.org> Original-Lines: 127 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:1564 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1564 > Two parties I'd like to keep in mind when making these decisions: > > - the packagers - we should consider what happens if I want to > package guile for debian and we've stuck guile-gtk, qt, kde, > gnome, etc. all in the main tree. If I build and install with > everything, I can assure you there will be a *lot* of users who > will (legitimately) complain that I'm forcing them to install, say > X, gtk, qt, and gnome on their *non-X* system. There are a > variety of ways we could handle this, but I think it's important > to keep in mind. > > (This has actually been a fairly major hassle to fix in the > current emacs21 wrt x and no-x, and I'm still not finished.) In my opinion, Guile _development_ should not copy the way how various distributions split Guile into packages. Last time I compiled Emacs myself, it was one big executable - either with or without X support (no modules possible). Guile has big advantage over Emacs that it can be split into modules and these modules can be distributed independently (with different dependencies). > - the special cases -- we should consider what effect any > arrangement we discuss might have on the difficulty of using guile > in small environments. i.e. the user (or distribution) who wants > to put guile on a firewall, ipaq, or mini-board. If we only > support a make install of 20MB+, then we're not considering this > case, and IMO it's not very workable to just say "these people > need to pick out the bits they need themselves" -- if we don't > have some policies wrt to our "core", then we'll eventually end up > with all kinds of cross-dependencies between different modules. "What if". Your are afraid that if Guile was bloated, Guile would lose users who want to use Guile in small environments. Notice that are not such users - otherwise there would be demand for small guile or there would be such guile distribution already. How can Guile lose users that it does not have? I am afraid that Guile has not many users. I am trying to find better development model and how to attract more users. I am thinking: better development -> more users (-> more developers ...). Also when more users are familiar with Guile and use it for their daily work, it is more likely that somebody choose Guile for his ipaq application... I think that there are many ways how to strip down Guile and decide what should or should not be included. Until there is somebody who really needs such Guile, we are not able to guess which way is right. It seems to me that you want to invent a hammer, but you do not know yet what it will be good for. > As an example of a policy question -- if we added a perlre module, > would it be OK for the core code to use it? How about srfi-1?, > etc. Lynn Winebarger writes: > Keeping the trees separate is a proactive measure for preventing code incest. (I had to read this sentence few times before I fully understood it :-) srfi-1 is very good example - it is really large module and it sometimes makes me thinking: "I want to use only function `every' (or fold-left) - why I have to include so BIG list library?" Pros/cons: + srfi-1 is standard - it is so BIG + If I implement fold (every, any) every time I need it, again and again, - I waste my time - it negates any benefits that come from standard libraries - I bloat code of my programs anyway (various `fold' implementation - here and there...) - when I copy buggy implementation of `fold', I also copy a bug. When I fix the bug, I also have to fix all copies of `fold'.... If I do not bloat my program by using BIG srfi-1, I end up with zillions of fold (every,and*..) implementations bloating every library. So, (use-module (srfi srfi-1)) or not to (use-module (srfi srfi-1))? That's question. What does it mean "keeping the trees separate is a proactive measure for preventing code incest"? If it means that every guile developer has to reinvent the wheel again and again (because of holy grail of small set of dependencies), than it is bad measure. We should distinguish three different problems: Development process - I think that we should integrate here as much as possible. When I say "integrate", I do not mean "put everything in one big libguile.so or boot-9.scm", rather I mean "one development pot". Even though Neil announced his guile-debugger many times, it passed unnoticed by many developers (though many of them wrote in their TODO list - "I really have to look into guile-debugger..." :-) I bet that if somebody had merged guile-debugger sooner, it would have been already in wide use and possibly it would already have been enhanced with many new features. Release - when "one big pot" is not feasible, it seems that Guile has to be split into packages (just for release). I think that it is not wise to use "smallest dependencies" criteria, instead I would split packages "logically" - I would look for the ways people often use them. Guile-Gdk would depend on less packages than Guile-Gtk, but almost all people use them together. If somebody really, really wants to extract Gdk bindings out of Guile-gtk, he should invest some work. If we want to think of all ways in which people may use Guile and a priori satisfy all possible demands on Guile, we are going to fail. Nothing is perfect from the beginning. We should be careful to not to close some doors (many interdependencies now -> hard to make stripped down version later), but such care should not paralyse and slow down development. Policies - As you already warned, we should consider what policies we keep so we do not close any door and make some further development impossible. Please, separate these three issues in your mind. Policies should only affect the source code, they should not slow down development or make it harder. Guile is divided into packages according to distribution policies. Using distribution (foreign) policies during Guile development sounds unnatural to me. To divide Guile to several packages is the task of package maintainer. 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel