From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2
Date: Tue, 01 Sep 2009 21:47:52 +0200 [thread overview]
Message-ID: <87bplu4fbr.fsf@gnu.org> (raw)
In-Reply-To: AEB8F600-F8F9-474E-84B4-A9B1B978FF02@raeburn.org
Hi Ken,
Ken Raeburn <raeburn@raeburn.org> writes:
> Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h
Another compilation flag that must be rarely used. :-)
Do you find it useful?
> It also means constant values for static initializers ("{ { BITS } }")
> have a different form from run-time expressions generating certain
> values ("scm_pack (BITS)" calls an inline function), and comparisons
> can't be done with "==" and "!=". (In fact, tags.h already says "SCM
> values can not be compared by using the operator ==", right above the
> definition of scm_is_eq.)
>
> Guess what we're also doing? :-)
> And I haven't even tried compiling Ludovic's bdw-gc-static-alloc
> branch yet, just master.
Indeed, we're in trouble.
> #1: We continue to not support static initialization.
[...]
> #1a: Extend #1 later with whatever internal macros are needed to
> provide the right initialization syntax for constructs used in bdw-gc-
> static-alloc based on the STRICTNESS setting.
>
> #1b: Try to supplement #1 with changes to SCM_PACK or SCM_MAKIFLAG to
> make it not considered a compile-time constant even with STRICTNESS<2
> and thus SCM_UNSPECIFIED, SCM_BOOL_F, etc are never suitable for
> static initialization, catching this problem earlier in the future.
[...]
> #1c: Try to supplement #1 by defaulting to STRICTNESS=2 on platforms
> where the union is passed and returned the same way as the pointer or
> integer in function calls
[...]
> #2: Drop STRICTNESS=2 support and really support static initialization
> with the current macros.
>
> #3: Keep STRICTNESS=2 support, and support static initialization, even
> for application code, with a bunch of new macros.
My preference is for #2 because: (1) I've never used it ;-), and
(2) we're moving away from C anyway. Hmm, weak arguments maybe.
Anyway, in the meantime, we can conditionalize static initialization
stuff from bdw-gc-static-alloc on STRICTNESS == 0 and keep everyone
happy.
Does that sound reasonable?
> It looks like the eval code is going to be annoying too
I wouldn't worry much about this one either as its probably doomed, once
Andy's eval cleanup work is mature.
Things have been moving too fast lately!
Thanks,
Ludo'.
next prev parent reply other threads:[~2009-09-01 19:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 6:23 more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2 Ken Raeburn
2009-09-01 6:26 ` Ken Raeburn
2009-09-16 19:20 ` Andy Wingo
2009-11-18 5:52 ` Ken Raeburn
2009-11-18 9:37 ` Ludovic Courtès
2009-11-18 20:40 ` Ken Raeburn
2009-11-18 21:18 ` Andy Wingo
2009-11-18 23:09 ` Ludovic Courtès
2009-09-01 19:47 ` Ludovic Courtès [this message]
2009-09-01 22:29 ` Ken Raeburn
2009-09-02 8:08 ` Ludovic Courtès
2009-09-02 18:17 ` Ken Raeburn
2009-09-03 11:48 ` Ludovic Courtès
2009-09-08 23:37 ` Neil Jerram
2009-09-09 1:41 ` Ken Raeburn
-- strict thread matches above, loose matches on Subject: below --
2009-09-01 4:52 Ken Raeburn
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=87bplu4fbr.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/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).