unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: Neil Jerram <neiljerram@googlemail.com>
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()'
Date: Sun, 7 Sep 2008 13:30:38 -0400	[thread overview]
Message-ID: <85B98DCA-3A6C-451E-AF79-3E72998F5E87@raeburn.org> (raw)
In-Reply-To: <49dd78620809070824s41c1d69dyb26fd8f8d2f13866@mail.gmail.com>

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




  reply	other threads:[~2008-09-07 17:30 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-31 22:02 [PATCH] Avoid `SCM_VALIDATE_LIST ()' Ludovic Courtès
2008-09-01  0:12 ` Han-Wen Nienhuys
2008-09-01 20:19   ` Neil Jerram
2008-09-01 20:30   ` Ludovic Courtès
2008-09-02  2:40     ` Han-Wen Nienhuys
2008-09-06 22:23       ` Neil Jerram
2008-09-06 21:36     ` Neil Jerram
2008-09-07  4:23     ` Ken Raeburn
2008-09-07 15:24       ` Neil Jerram
2008-09-07 17:30         ` Ken Raeburn [this message]
2008-09-07 19:21           ` Neil Jerram
2008-09-08 23:11         ` Neil Jerram
2008-09-09  8:28           ` Ludovic Courtès
2008-09-10 20:43             ` Neil Jerram
2008-09-04 18:24   ` Andy Wingo
2008-09-05  0:10     ` Han-Wen Nienhuys
2008-09-05  1:06       ` Andy Wingo
2008-09-06 22:45         ` Neil Jerram
2008-09-07  2:33           ` Han-Wen Nienhuys
2008-09-07 13:38             ` Neil Jerram
2008-09-07 15:00               ` Han-Wen Nienhuys
2008-09-07 16:19                 ` Neil Jerram
2008-09-07 19:25                   ` Han-Wen Nienhuys
2008-09-07 14:05             ` Andy Wingo
2008-09-07 15:38               ` development goals (was: [PATCH] Avoid `SCM_VALIDATE_LIST ()') Han-Wen Nienhuys
2008-09-07 20:03                 ` Neil Jerram
2008-09-08  4:28                   ` development goals Han-Wen Nienhuys
2008-09-08 10:16                     ` Ludovic Courtès
2008-09-08 13:57                       ` Han-Wen Nienhuys
2008-09-09  7:08                       ` Andy Wingo
2008-09-08 10:27                   ` Ludovic Courtès
2008-09-06 22:40     ` [PATCH] Avoid `SCM_VALIDATE_LIST ()' Neil Jerram
2008-09-01 21:09 ` Neil Jerram
2008-09-01 21:47   ` Ludovic Courtès
2008-09-06 22:15     ` Neil Jerram
2008-09-08  9:40       ` Ludovic Courtès
2008-09-06 23:11     ` Mikael Djurfeldt
2008-09-07  2:43       ` Han-Wen Nienhuys
2008-09-07 15:04         ` Neil Jerram
2008-09-07 13:32       ` Neil Jerram
2008-09-02  2:44   ` Han-Wen Nienhuys
2008-09-06 22:32     ` Neil Jerram
2008-09-08  3:13       ` Han-Wen Nienhuys
2008-09-08  4:42         ` Clinton Ebadi
2008-09-08  9:47           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85B98DCA-3A6C-451E-AF79-3E72998F5E87@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=guile-devel@gnu.org \
    --cc=neiljerram@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).