>> Hmm, what I'm trying to say here that "lazy" is not some standard,
>> established terminology, and if we come up with something better, we
>> should feel free to change terminology.
>
> Yes, that makes good sense. I can't think of anything better than
> "pre-unwind", so I'll use that in all new
On Jan 24, 2006, at 16:06, Han-Wen Nienhuys wrote:
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
Yes, -- FWIW, I warmly recommend darcs, which is much easier to
use.
I don't think there's such a huge difference, esp
Hi,
guile> (define m43 (1- (expt 2 30402457)))
guile> (integer-length m43)
30402457
guile> (remainder m43 8352716958173659)
2698619340888656
guile> (number->string m43 16)
"f."
guile> m43
Segmentation fault
So we can handle numbers like that, but we can
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> Yes, -- FWIW, I warmly recommend darcs, which is much easier to use.
I don't think there's such a huge difference, especially when looking at
[0]. Additionally, most of the commands shown there now have
"easy-looking" counterparts taken from Bazaa
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
>
>> Yes, -- FWIW, I warmly recommend darcs, which is much easier to use.
>
>I don't think there's such a huge difference, especially when looking at
>[0]. Additionally, most
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> The following patch makes `scm_is_pair ()' an inline --- the macro was
> indeed a bad idea because there are places (e.g., async.c:208) where its
> argument is an assignment.
Which is probably not really in line with gnu coding standards
(standards.i
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>In fact, I think we'd greatly benefit from using a distributed revision
>control system like GNU Arch: it really makes it easier to collaborate,
Yes, -- FWIW, I warmly recommend darcs, which is much easier to use.
>> I
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> In article <[EMAIL PROTECTED]>,
> Ludovic Courtès <[EMAIL PROTECTED]> wrote:
[...]
>>This second modification has a nice effect: it can significantly reduce
>>the number of objects created at load-time. Unfortunately, Guile's
>>built-in reader alwa
Hi,
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> I think it looks OK. If noone steps forward, I will integrate it.
Thanks!
> Have
> you considered asking Marius for CVS write access?
One might arguably consider it inadequate. Beside, as long as patches
are reviewed in a reasonable amount of
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>Hi,
>
>The patch below does two things:
>
>1. It introduces `scm_take_locale_symbol ()'.
>
>2. It modifies `scm_from_locale_symbol ()' so that it doesn't create a
>Scheme string to do the job.
>
>This second modificat
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>> * api-data.texi (Operations Related to Symbols):
>> Documented `scm_take_locale_symbol ()'.
>
>Can someone review this patch?
I think it looks OK. If noone steps forward, I will integrate it. Have
you considere
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Since, I consider compilers that don't support inlining unimportant, I'd
> happily live without the `inline.c' stuff. I.e., I'd put this in
> `pairs.h':
>
> static SCM_C_INLINE int
> scm_is_pair (...)
>
> With compilers not supporting inlinin
Hello,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> libguile:
>
> 2005-12-19 Ludovic Courtès <[EMAIL PROTECTED]>
>
> * strings.c (scm_i_take_stringbufn): New.
> (scm_i_c_take_symbol): New.
> (scm_take_locale_stringn): Use `scm_i_take_stringbufn ()'.
>
> * strings.h (scm
13 matches
Mail list logo
