From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()' Date: Sun, 7 Sep 2008 13:30:38 -0400 Message-ID: <85B98DCA-3A6C-451E-AF79-3E72998F5E87@raeburn.org> References: <87hc90u9lb.fsf@gnu.org> <87ljybmwvx.fsf@gnu.org> <14AB3911-5838-4DDE-B57F-C6A73F627EC1@raeburn.org> <49dd78620809070824s41c1d69dyb26fd8f8d2f13866@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v928.1) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220808665 26331 80.91.229.12 (7 Sep 2008 17:31:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Sep 2008 17:31:05 +0000 (UTC) Cc: guile-devel@gnu.org To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Sep 07 19:32:00 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 1KcO7D-00036z-2Q for guile-devel@m.gmane.org; Sun, 07 Sep 2008 19:31:59 +0200 Original-Received: from localhost ([127.0.0.1]:43562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcO6D-0001zL-AW for guile-devel@m.gmane.org; Sun, 07 Sep 2008 13:30:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcO68-0001zG-2u for guile-devel@gnu.org; Sun, 07 Sep 2008 13:30:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcO66-0001z3-LG for guile-devel@gnu.org; Sun, 07 Sep 2008 13:30:51 -0400 Original-Received: from [199.232.76.173] (port=38349 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcO66-0001z0-Ii for guile-devel@gnu.org; Sun, 07 Sep 2008 13:30:50 -0400 Original-Received: from raeburn.org ([69.25.196.97]:20044) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KcO5v-0001uf-KR for guile-devel@gnu.org; Sun, 07 Sep 2008 13:30:50 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [69.25.196.102]) by raeburn.org (8.14.1/8.14.1) with ESMTP id m87HUc4N005652; Sun, 7 Sep 2008 13:30:38 -0400 (EDT) In-Reply-To: <49dd78620809070824s41c1d69dyb26fd8f8d2f13866@mail.gmail.com> X-Mailer: Apple Mail (2.928.1) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) 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:7613 Archived-At: On Sep 7, 2008, at 11:24, Neil Jerram wrote: >> I'm using a Mac as my main machine these days. The Emacs unexec >> mechanism >> interacts badly with the Mac version of malloc, so Emacs uses its own >> version specially tailored to use Mac system allocation routines in >> a way >> that works with unexec. Guile doesn't have any hooks for doing >> that sort of >> thing. Of course you can configure with -Dmalloc=unexec_malloc and >> so on, >> but then you're guaranteed not to be able to build an actual guile >> interpreter executable without the extra Emacs code. > > Not sure I understand. Surely you would always know if you're > building with or without the Emacs code, and so could define malloc or > not accordingly? Not if you want to build and install the full guile package and then link emacs against libguile, which is how I've generally done it. Or if you want to build both emacs and guile executables at once so you can test libguile without the rest of emacs. Of course, I could just drop a copy of guile into the source tree and tweak the build process to skip the 'guile' binary, or add wrapper functions that only link into that executable and cause the redirected calls to invoke malloc and friends after all. I could also create function-pointer variables that could be changed before guile initialization, and I may do it that way for my own use, but it's not clear to me that there'd be any value in feeding that back upstream. Ken