[PATCH] Implement efficient 'scm_unget_bytes' and use it

Hello all, 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. This patch

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

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. This patch

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

Ian Price ianpric...@googlemail.com 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] Move let/ec to top-level

Ian Price ianpric...@googlemail.com skribis: From ffbe4cf3c151d5d5affd5baecf7b4cf65b22ce50 Mon Sep 17 00:00:00 2001 From: Ian Price ianpric...@googlemail.com Date: Sat, 6 Apr 2013 03:06:25 +0100 Subject: [PATCH] Remove duplicate definitions of `call/ec' and `let/ec'. *

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

Mike Gran spk...@yahoo.com 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

[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 m...@netris.org Date: Sat, 6 Apr 2013 13:36:24 -0400 Subject: [PATCH] Implement 'scm_c_bind_kwargs' to handle keyword arguments

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 m...@netris.org writes: * libguile/keywords.c (scm_keyword_argument_error): New variable. (scm_c_bind_kwargs): New API function. I think I prefer

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

On Thu 04 Apr 2013 09:38, Mark H Weaver m...@netris.org 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

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

Mark H Weaver m...@netris.org skribis: I'd like to hear opinions on how to print promises. Here are mine: * I don't like #eager ... and #lazy #procedure * Both forms should start with #promise ..., because from a user's point of view that is the type. +1 * We should avoid

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