Re: [PATCH] Add backlog option to http-open

On 6 April 2013 12:14, Nala Ginrut wrote: > Resend patch, added the example for #:backlog. > Since there's no docs for all run-server open-params, but examples. > So I just added the example. I think it's enough to explain the usage. You missed to add it to the preceding ‘@deffn’. I don't think

[PATCHES] Keyword args for file openers; coding scan off by default

Hello all, Here's the last major patch set that I very much hope to get into 2.0.8. The first patch disables the coding declaration scan in 'open-file' by default. I feel quite strongly that this is important for robustness and security reasons, and I'm pleased to report that Ludovic recently gav

Re: [PATCH] Implement 'scm_c_bind_kwargs' to handle keyword arguments from C

Hi Andy, Andy Wingo writes: > I'm OK with this in principle, but we shouldagree on names before this > goes in. Indeed, I often have trouble coming up with good names. We talked about it on IRC, and agreed on 'scm_c_bind_keyword_arguments', 'SCM_ALLOW_OTHER_KEYS' and 'SCM_ALLOW_NON_KEYWORD_ARG

Re: [PATCH] Implement efficient 'scm_unget_bytes' and 'unget-bytevector'

Mark H Weaver skribis: > Mark H Weaver writes: > >> I discovered that 'scm_unget_byte' is kind of dumb. It puts the bytes >> at the beginning of the pushback buffer instead of the end. This means >> that every time you unget a byte, it has to shift up the existing >> contents of the buffer, so

Fwd: array-copy! is slow & array-map.c

This patch replaces the scm_generalized_vector_get_handle() in the rank-1 functions by scm_array_get_handle(). These calls came from the GVSET/GVREF code that I spliced in there, but the arguments are known to be rank-1, so there's no reason not to use the simpler call. Regards Danie

Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.7-291-g4a1cdc9

Mark H Weaver skribis: > I'd like to hear opinions on how to print promises. Here are mine: > > * I don't like # and #>. > > * Both forms should start with #, because from a user's > point of view that is the type. +1 > * We should avoid printing "# location tag would be useful, but let's

Re: Outdated section of manual 6.19.10 (Included Guile Modules)

On Thu 04 Apr 2013 09:38, Mark H Weaver writes: > I just noticed that section 6.19.10 is horribly out of date. It's also > out of place, in a section of the manual that talks about the module > mechanism. > > Frankly, I think it should simply be removed. It is mostly redundant > with Chapter 7

Re: [PATCH] Implement 'scm_c_bind_kwargs' to handle keyword arguments from C

Hi Mark, I'm OK with this in principle, but we shouldagree on names before this goes in. On Sat 06 Apr 2013 21:31, Mark H Weaver writes: > * libguile/keywords.c (scm_keyword_argument_error): New variable. > (scm_c_bind_kwargs): New API function. I think I prefer scm_c_bind_keyword_arguments,

[PATCH] Implement 'scm_c_bind_kwargs' to handle keyword arguments from C

This patch speaks for itself. Comments and suggestions solicited. Mark >From a53f6505de29c8408a09127b96c8be6ad3d712a6 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sat, 6 Apr 2013 13:36:24 -0400 Subject: [PATCH] Implement 'scm_c_bind_kwargs' to handle keyword arguments from C. * lib

Re: [PATCH] Implement efficient 'scm_unget_bytes' and 'unget-bytevector'

Mike Gran writes: > It is true that none of Guile's clients ever look at putback_buf? I'm assuming the worst: that Guile's clients might look at, and manipulate the 'putback_buf' directly. The way I'm filling 'putback_buf' can *already* happen today. Here's how it can happen today: unget enoug

Re: [PATCH] Move let/ec to top-level

Ian Price skribis: > From ffbe4cf3c151d5d5affd5baecf7b4cf65b22ce50 Mon Sep 17 00:00:00 2001 > From: Ian Price > Date: Sat, 6 Apr 2013 03:06:25 +0100 > Subject: [PATCH] Remove duplicate definitions of `call/ec' and `let/ec'. > > * module/language/tree-il/peval.scm (let/ec): Remove. Import > (ic

Re: [PATCH] Move let/ec to top-level

Ian Price skribis: > Okay, apparently Ludovic already mailed the list about this, but I > didn't see it due to a stale gnus. Yes. :-/ I think all your suggestions are incorporated in 55e26a4, but let me know if something’s missing. Ludo’.

Re: [PATCH] Implement efficient 'scm_unget_bytes' and 'unget-bytevector'

>> I discovered that 'scm_unget_byte' is kind of dumb.  It puts the > bytes >> at the beginning of the pushback buffer instead of the end.  This means >> that every time you unget a byte, it has to shift up the existing >> contents of the buffer, so ungetting N bytes takes O(N^2) time. >> >>

[PATCH] Implement efficient 'scm_unget_bytes' and 'unget-bytevector'

Mark H Weaver writes: > I discovered that 'scm_unget_byte' is kind of dumb. It puts the bytes > at the beginning of the pushback buffer instead of the end. This means > that every time you unget a byte, it has to shift up the existing > contents of the buffer, so ungetting N bytes takes O(N^2)

Re: [PATCH] Implement efficient 'scm_unget_bytes' and use it

On Sat, Apr 06, 2013 at 02:28:14AM -0400, Mark H Weaver wrote: > This patch implements a function 'scm_unget_bytes' that enables large > buffers to be unread efficiently. It keeps the bytes at the end of the > buffer instead of the beginning, but it can cope if some external code > manipulates the