Hello!
I just updated the `bdw-gc-static-alloc' branch [0]. It statically
allocates stringbufs, strings, and subrs defined using the "snarfing
macros". It links `libguile' with `-z relro' such that constants
needing relocation are placed in a `PT_GNU_RELRO' ELF segment, which is
made read-only b
On Sep 1, 2009, at 15:47, Ludovic Courtès wrote:
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?
Not so far. :-) There seems to be a lot of otherwise correct code
making assumptions about u
Julian Graham writes:
>> This should all be fixed in master now. Can you have a go and let me
>> know if you still see any problems?
>
> Just built from HEAD. The errors I reported earlier are gone, but I'm
> still not getting any trace output from the `rev' example in the
> manual.
I'm sorry,
I'm going to be travelling for a few days and so away from email;
should be looking at the list again in about a week from now.
So, apologies in advance for my non-responsiveness...
Neil
Mark H Weaver writes:
> I agree that the names are uncomfortably long. We could shorten them
> without much loss of clarity by replacing "lisp_nil" with "nil" and
> "and_not" with "not", yielding:
>
> scm_is_false_assume_not_nil scm_is_true_assume_not_nil
> scm_is_false_not_nil scm_
Mark H Weaver writes:
> What about scm_is_bool? I'm tempted to suggest that it should work
> the same way as "boolean?" within scheme, whatever that may be. I
> tend to think they ought to treat %nil as boolean, though I'm less
> sure of this than about scm_is_true/false/null. It's the right t
Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 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 from pointer and integer types not work without going through the
correct conversion
Mark H Weaver writes:
> On Sun, Aug 30, 2009 at 12:13:59PM +0100, Neil Jerram wrote:
>> Mark H Weaver writes:
>>
>> > This numbering has the nice properties that 0 is #f.
>>
>> Just to be clear: will this mean that (SCM_BOOL_F == 0) ? As things
>> stand I don't think it will, because SCM_MAKI
Mike Gran writes:
>> For this context I think it would be clearer to say
>>
>> Return `#t' iff the Unicode code point of `x' is less than the
>> code point of `y', else `#f'.
>
> Sounds good.
[..]
> I see what you mean. The text should have something like...
>
> "In case folding comparison
> > It would be nicer if string ports were actually bytevector ports, and that
> > they were locale-independent? Or that scm_get_output_bytevector returned a
> > locale-independent (ergo 8-bit or 32-bit) vector?
>
> The latter.
The test suite requires an API for testing the correctness of the
Hi Ken,
Ken Raeburn 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 expr
Hi!
Ken Raeburn writes:
> --- a/libguile/gc.h
> +++ b/libguile/gc.h
> @@ -248,7 +248,7 @@ SCM_INTERNAL void scm_i_ensure_marking(void);
> SCM_API int scm_debug_cell_accesses_p;
> SCM_API int scm_expensive_debug_cell_accesses_p;
> SCM_API int scm_debug_cells_gc_interval ;
> -void scm_i_expensi
Hi!
Mike Gran writes:
>> On Tue 01 Sep 2009 10:19, l...@gnu.org (Ludovic Courtès) writes:
>>
>> > Mike Gran writes:
>> >
>> >> The latest commit 'Add full Unicode capability to ports and the default
>> >> reader' 889975e51accb80491af76fc5db980aeb3edd342 adds the majority of
>> >> the functional
- Original Message
> From: Andy Wingo
> To: Ludovic Courtès
> Cc: guile-devel@gnu.org
> Sent: Tuesday, September 1, 2009 11:25:26 AM
> Subject: Re: Unicode ports patch
>
> Hi,
>
> On Tue 01 Sep 2009 10:19, l...@gnu.org (Ludovic Courtès) writes:
>
> > Mike Gran writes:
> >
> >> The lat
Hi,
On Tue 01 Sep 2009 10:19, l...@gnu.org (Ludovic Courtès) writes:
> Mike Gran writes:
>
>> The latest commit 'Add full Unicode capability to ports and the default
>> reader' 889975e51accb80491af76fc5db980aeb3edd342 adds the majority of
>> the functionality for non-ASCII strings.
>
> This pa
Hi,
Mike Gran writes:
> On Tue, 2009-09-01 at 02:14 +0200, Ludovic Courtès wrote:
[...]
>> The `scm_take_' functions for strings/symbols/bytevectors are now
>> essentially aliases to the corresponding `scm_from_' because we cannot
>> advantageously reuse the provided storage.
>>
>> Should the
Hello!
Mike Gran writes:
> The latest commit 'Add full Unicode capability to ports and the default
> reader' 889975e51accb80491af76fc5db980aeb3edd342 adds the majority of
> the functionality for non-ASCII strings.
This patch adds a few functions related to string ports:
* libguile/strports
17 matches
Mail list logo
