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
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
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
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
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
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
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
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
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 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
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 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'.
[[ 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 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
14 matches
Mail list logo
