From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.devel Subject: Re: Plan for 2.0 Date: Fri, 9 Jan 2009 13:53:50 +0000 Message-ID: <49dd78620901090553q54c30420v6b4ee5edca903de0@mail.gmail.com> References: <49dd78620901031038i6f6c678o5cebc21b217374d2@mail.gmail.com> <49dd78620901071516j4592684du81efaf04cd95742a@mail.gmail.com> <878wpl79ty.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1231510425 28016 80.91.229.12 (9 Jan 2009 14:13:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Jan 2009 14:13:45 +0000 (UTC) Cc: guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 09 15:14:55 2009 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 1LLI8O-0005bm-D2 for guile-devel@m.gmane.org; Fri, 09 Jan 2009 15:14:49 +0100 Original-Received: from localhost ([127.0.0.1]:36939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLI77-0006k9-U1 for guile-devel@m.gmane.org; Fri, 09 Jan 2009 09:13:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLI0t-0005LW-GH for guile-devel@gnu.org; Fri, 09 Jan 2009 09:07:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLI0q-0005Kf-OT for guile-devel@gnu.org; Fri, 09 Jan 2009 09:07:01 -0500 Original-Received: from [199.232.76.173] (port=36248 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLI0o-0005KI-MF for guile-devel@gnu.org; Fri, 09 Jan 2009 09:06:59 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:38265) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LLI0k-00058A-RJ; Fri, 09 Jan 2009 09:06:54 -0500 Original-Received: from fg-out-1718.google.com ([72.14.220.156]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LLHo9-00011a-3z; Fri, 09 Jan 2009 08:53:53 -0500 Original-Received: by fg-out-1718.google.com with SMTP id l26so3654629fgb.30 for ; Fri, 09 Jan 2009 05:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=YO2P0QTWP5wF+GO59hVDwqsUr7Qenm3ztziNTMtmQPU=; b=lcPPqVJszY1NKHp+eeF0CLJkHzAL6/xeC/i5/zHwbBQhs//Bb/hVu6BJFlPWvMixKg CFwlJmRICvYPZWskq0U4wW2sB4gThxGeXkYAe/ezFX+8J85ZyP+CtbNScbu45XUiJ2b6 SxwvNmaajXhVGctXW3oRmKlANkISAtGPIS0ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=I6SAtawanbDdXS+Jsc2wgPKtyABCN9nNRo6oQeTv+y/JsUXuTAYybrJHsuDrXjqf0W 4hO74bD88eVNsyB9H6qGAYjff501180pKoK5xSMzffHRuJqtJQnKZ35toIY7ktOi3qQq nksnra/CMjkaBGX/C388Oi6D9WoyQGyi4JHYQ= Original-Received: by 10.86.4.14 with SMTP id 14mr14874815fgd.76.1231509230243; Fri, 09 Jan 2009 05:53:50 -0800 (PST) Original-Received: by 10.86.74.2 with HTTP; Fri, 9 Jan 2009 05:53:50 -0800 (PST) In-Reply-To: <878wpl79ty.fsf@gnu.org> Content-Disposition: inline X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/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:7976 Archived-At: Hi Ludo! Thanks for your responses... 2009/1/8 Ludovic Court=E8s : > Hi Neil, > > "Neil Jerram" writes: > >> Use of Gnulib >> - linker warning >> - alloca - Have we inadvertently removed requirement for a real alloca? > > No. Gnulib's `alloca' provides a substitute when that's needed and most > importantly provides the right #ifdefs to get a working `alloca ()' (see > `lib/alloca.in.h' and (info "(autoconf) Particular Functions")). That's good, but I think I didn't explain the possible problem fully, i.e. that the substitute won't work. Because of how Guile saves and restores continuations (by copying the stack), and how it uses alloca to create space for debug information on the stack, we must have an alloca() that really does use the stack, and not one that uses the heap. And when I last checked, the common substitute definition of alloca() uses the heap. So, (i) am I still missing something, or (ii) does the substitute definition use the stack now, or (iii) is there a way to tell Gnulib that we really need an on-the-stack alloca (and that the build should fail if there isn't one), or (iv) are we already doing (iii) and I just missed it :-) ? (We originally addressed this, somewhere in 1.6.x or 1.8.x, here: http://git.savannah.gnu.org/gitweb/?p=3Dguile.git;a=3Dcommitdiff;h=3D31e4c6= 9e95bc77b7f701348a32ffc8374ad8a0e5) >> serial number in guile.m4 > > Why is that? Are there differences? master has a line "serial 9", branch_release-1-8 doesn't. I believe it's a standard of some kind to have a "serial" line, so we added it in master, but preferred to avoid perturbing 1.8.x. >> eval.c/eval.i.c >> - still need to compare old eval.c against new eval.i.c >> - why does eval.i.c contain code that is common to both modes and that >> is not compiled twice? > > Like what? The top of the file is in `#ifdef DEVAL'. I would have thought that the point of eval.i.c is to hold the code that gets compiled twice (debug and non-debug). If there is #ifdef DEVAL code in eval.i.c, it seems to be better to move it back to eval.c. >> SCM_INTERNAL (grep diffs for SCM_INTERNAL to get list of affected functi= ons) > > Speaking of which, some functions were left external (e.g., > `scm_i_string_chars ()') under the assumption that if we changed that in > 1.8 (which was my plan back then) it would break apps. We may need to > revise that. I can't immediately remember what the latest consensus on that was... >> Queries >> =3D=3D=3D=3D=3D=3D=3D >> AC_SUBST(GCC_FLAGS) > > This is so that we don't compile Gnulib code with `-Wall -Werror' since > Gnulib doesn't guarantee that this would work. > >> lib-version.texi > > This is for use in `api-i18n.texi', for instance. Thanks for those. >> ChangeLogs still in distribution? > > Yes, same as for `branch_release-1-8'. OK, thanks. >> libguile in subdirs list of pre-inst-guile.in > > Dunno why. The Right Way would be to use `libtool --mode=3Dexecute > -dlopen foo-bar.la' anyway. Thanks, I'll look into that. > Thanks, > Ludo'. Regards, Neil