wip-elisp update
Updated wip-elisp branch onto master. https://github.com/lyrra/guile/tree/wip-elisp-2019
[PATCH] doc: Clarify documentation of 'bytevector-copy!'.
--
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
From b294afd366b8ce979ed5f549002057240a6ff478 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A1bor=20Boskovits?=
Date: Wed, 7 Aug 2019 14:34:05 +0200
Subject: [PATCH] doc: Clarify documentation of 'bytevector-copy!'.
* doc/ref/api-data.text (Bytevectors): Reword documentation
to use 'nonnegative' instead of 'positive' for 0-based index.
---
THANKS | 1 +
doc/THANKS | 1 +
doc/ref/api-data.texi | 2 +-
libguile/bytevectors.c | 2 +-
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/THANKS b/THANKS
index a4fad6e08..fe208a720 100644
--- a/THANKS
+++ b/THANKS
@@ -1,6 +1,7 @@
Contributors since the last release:
Christopher Baines
+ Gábor Boskovits
Greg Benison
Tristan Colgate-McFarlane
Aleix Conchillo Flaqué
diff --git a/doc/THANKS b/doc/THANKS
index 53cff29f4..030b44f74 100644
--- a/doc/THANKS
+++ b/doc/THANKS
@@ -3,6 +3,7 @@ manuals!
Proofreading, bug reports and patches from:
Chris Bitmead
+ Gábor Boskovits
Christopher Cramer
Marcus Daniels
Dirk Herrmann
diff --git a/doc/ref/api-data.texi b/doc/ref/api-data.texi
index 5b9c5654e..e7cb85881 100644
--- a/doc/ref/api-data.texi
+++ b/doc/ref/api-data.texi
@@ -6819,7 +6819,7 @@ Fill bytevector @var{bv} with @var{fill}, a byte.
@deffn {Scheme Procedure} bytevector-copy! source source-start target target-start len
@deffnx {C Function} scm_bytevector_copy_x (source, source_start, target, target_start, len)
Copy @var{len} bytes from @var{source} into @var{target}, starting
-reading from @var{source-start} (a positive index within @var{source})
+reading from @var{source-start} (a nonnegative index within @var{source})
and start writing at @var{target-start}. It is permitted for the
@var{source} and @var{target} regions to overlap.
@end deffn
diff --git a/libguile/bytevectors.c b/libguile/bytevectors.c
index 7dfdab499..dfb4733c0 100644
--- a/libguile/bytevectors.c
+++ b/libguile/bytevectors.c
@@ -589,7 +589,7 @@ SCM_DEFINE (scm_bytevector_copy_x, "bytevector-copy!", 5, 0, 0,
(SCM source, SCM source_start, SCM target, SCM target_start,
SCM len),
"Copy @var{len} bytes from @var{source} into @var{target}, "
- "starting reading from @var{source_start} (a positive index "
+ "starting reading from @var{source_start} (a nonnegative index "
"within @var{source}) and start writing at "
"@var{target_start}.")
#define FUNC_NAME s_scm_bytevector_copy_x
--
2.20.1
Re: Support Websocket status code
hi Mark! Yes you're right, the status code should be encoded in close-frame, not HTTP response. Sorry for the wrong patch. ;-) Best regards. On Wed, Aug 7, 2019 at 2:52 PM Mark H Weaver wrote: > Hi, > > Nala Ginrut writes: > > > Hi folks! > > The current response builder will reject status code less than 600: > > ---code- > > ((not (and (non-negative-integer? code) (< code 600))) > > (bad-response "Bad code: ~a" code)) > > --- > > > > However, Websocket specific status code is larger than 1000. > > Section 4.2.2 paragraph 5 of RFC 6455 (the WebSocket RFC) makes it clear > that the HTTP response should conform to RFC 2616, which specifies that > the status code is a 3-digit integer less than 600. > > If I understand correctly, the larger status codes defined in section > 7.4.1 of RFC 6455 are never used in HTTP response headers. Rather, they > are optionally used in WebSocket Close control frames to indicate the > reason for closure. See section 7.1.6 for more on that. > > The WebSocket protocol is quite distinct from the HTTP protocol. > Although HTTP is used initially, after the server returns the HTTP > response with status "101 Switching Protocols", a completely different > protocol is used henceforth. > > So, I don't see anything in the RFCs to justify using the larger status > codes in HTTP response status line. Am I misunderstanding something? > >Mark >
Re: Support Websocket status code
Hi, Nala Ginrut writes: > Hi folks! > The current response builder will reject status code less than 600: > ---code- > ((not (and (non-negative-integer? code) (< code 600))) > (bad-response "Bad code: ~a" code)) > --- > > However, Websocket specific status code is larger than 1000. Section 4.2.2 paragraph 5 of RFC 6455 (the WebSocket RFC) makes it clear that the HTTP response should conform to RFC 2616, which specifies that the status code is a 3-digit integer less than 600. If I understand correctly, the larger status codes defined in section 7.4.1 of RFC 6455 are never used in HTTP response headers. Rather, they are optionally used in WebSocket Close control frames to indicate the reason for closure. See section 7.1.6 for more on that. The WebSocket protocol is quite distinct from the HTTP protocol. Although HTTP is used initially, after the server returns the HTTP response with status "101 Switching Protocols", a completely different protocol is used henceforth. So, I don't see anything in the RFCs to justify using the larger status codes in HTTP response status line. Am I misunderstanding something? Mark
