On Sep 1, 2009, at 02:23, Ken Raeburn wrote:
I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as
needed, change == to scm_is_eq. The initializers make it slightly
less trivial, and I can imagine different courses of action.
Okay, not quite so trivial as I blithely asserted.
It
[[ Resending from an account I'm actually subscribed with. ]]
Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h
causes SCM to be defined as a union type (though the comments say a
struct type), which enhances the type checking by making random
conversions and casts to and
On Mon, 2009-08-31 at 18:40 -0700, Mike Gran wrote:
> Note that the German letter Sharp S
> (Eszett) is not uppercased before the comparison since its plural has
> two characters instead of one."
I meant to say 'its _uppercase form_ has two characters instead of one'.
On Mon, 2009-08-31 at 11:21 +0100, Neil Jerram wrote:
> I think there's a case here for making the docstring not identical to
> the corresponding manual text. In the manual context, the section
> begins with talking about Unicode, so "Unicode" can be assumed for
> everything that follows. But in
On Tue, 2009-09-01 at 02:14 +0200, Ludovic Courtès wrote:
> Hello!
>
> Stringbufs and bytevectors are now always "inlined" in the BDW-GC
> branch [0, 1], which means that there's no cell->buffer indirection,
> which greatly simplifies code (it also takes less room and may slightly
> improve perfor
Hello!
Stringbufs and bytevectors are now always "inlined" in the BDW-GC
branch [0, 1], which means that there's no cell->buffer indirection,
which greatly simplifies code (it also takes less room and may slightly
improve performance).
The `scm_take_' functions for strings/symbols/bytevectors are
On Aug 31, 2009, at 17:59, Ludovic Courtès wrote:
I think I'm mildly in favor of keeping all-bits-zero as an invalid
representation. But, if it's a huge win for BDW-GC, maybe it's worth
it.
As discussed in my other message, it would actually be harmful.
Then I'm definitely in favor of keepin
Hi,
Ken Raeburn writes:
> I kind of assumed that making all-bits-zero an invalid value was a
> conscious choice by the Guile (or SCM?) designers which wasn't likely
> to be revisited. It is, after all, a fairly easy way of highlighting
> a certain class of uninitialized-value problems -- choosi
Hello!
Neil Jerram writes:
> Just checking this because Ludovic said recently that (SCM_BOOL_F ==
> 0) would have nice properties for BDW-GC.
Actually he wasn't quite right when he said that. :-)
The issue with BDW-GC is that "disappearing links" (weak pointers in
libgc parlance) replace poin
The end of my build, from a few hours ago:
/bin/ksh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
-DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/pkg/include
-I/usr/y0/include -I/usr/pkg/include -I/usr/y0/include -pthread -Wall
-Wmissing-prototypes -Werror -fvisibility=h
First of all, thanks for making these docs (specifically, commit
3f12aed) so clear. They seem so much clearer and simpler to me than
the months of back-and-forth discussion on r6rs-discuss. I know those
things are not really comparable, but I hope you can see what I mean.
Then, a couple of queri
Hi,
Andy Wingo writes:
> Now, does this indicate a bug in Guile, or at least an undesirable
> behavior?
Yes, I think so.
Programs that want to rely on bare R5RS (e.g., SILex) have nothing else
but `load' to have code in separate files. So I think the compiler
should special-case top-level `lo
Hi!
Andy Wingo writes:
[...]
>> scm_tcs_closures Interpreted procedures
>
> I am hoping to devise a way never to see these in the VM, on the
> eval-cleanup branch.
Cool!
>> scm_tc7_subr_2oSCM (*) () -- 0 arguments.
>> scm_tc7_subr_1 SCM (*) (SCM) -- 1 argu
Mike Gran writes:
> On Fri, 2009-08-21 at 14:27 -0400, Greg Troxel wrote:
>> I ran 'gmake -k' to get all the warnings at once. I think there are
>> just two groups:
>
>> deprecated.c:1092: warning: dereferencing type-punned pointer will break
>> strict-aliasing rules
>
>> vm-i-scheme.c:437: war
14 matches
Mail list logo
