Version 2.2.3 tests fail on Debian i386 and ppc64el hosts

[1] The release architectures are the unshaded ones on the buildd page. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Version 2.2.3 tests fail on Debian i386 and ppc64el hosts

Rob Browning writes: > I've been trying to get Guile 2.2 to build and pass the tests on all of > the Debian architectures again, and at this point, the release[1] > architectures are OK except i386 and ppc64el (and armel, which is still > building...). > > Initially amd64

Re: bug#31776: guile-2.2: FTBFS on armhf: FAIL: gc.test: gc: after-gc-hook gets called

Rob Browning writes: > Rob Browning writes: > >> It looks like gc.test may be failing intermittently in Debian (see below). >> Searching around I saw at least one other report of this in the #guile >> logs from last year. >> >> For now, I'm wondering if

Unexpectedly low read/write performance of open-pipe

stdin=subprocess.PIPE, stdout=subprocess.PIPE, close_fds = True, bufsize = 4096) n_kb = 100 start = os.times()[4] written = 0 for i in range(n_kb): assert(len(proc.stdout.read(1024)) == 1024) written += 1024 end = os.times()[4] proc.termina

Re: Unexpectedly low read/write performance of open-pipe

Rob Browning writes: > While evaluating guile as a possibility to replace some python code, > assuming I'm not just doing something wrong, I noticed that open-pipe > appears to transfer data *much* more slowly than python when OPEN_BOTH is > specified as opposed to OPEN_READ

Re: Unexpectedly low read/write performance of open-pipe

Rob Browning writes: > For what it's worth, in an earlier round of testing I also hacked up > open-pipe to let me access the underlying ports and set their buffers to > 65k. That doubled the transfer rate, but of course, it's still fairly > slow. I also ran statprof on

Re: Unexpectedly low read/write performance of open-pipe

Rob Browning writes: > I haven't tried to track it down yet, but if the only underlying way to > get a fixed block of data out of an OPEN_BOTH port is read-char, then > that might explain much of the difference. And this, in popen.scm was why I started wondering about that: (ca

Re: Unexpectedly low read/write performance of open-pipe

t, measured by pv. (If the patch holds up, it'd be nice to have in 2.2, but I suppose that might not be appropriate.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Unexpectedly low read/write performance of open-pipe

roposal: 1453.49 mb/s >300% CPU in top this series: 3937.01 mb/s <80% CPU in top (and most importantly for this series, a much quieter fan...) And yes, I'd love to see something like this in 2.2 too if it turns out to be feasible to include it there. Nice -- Rob Browning

Should an enclosing let keep the compiler from handling define-module?

#`(eval-when (expand load eval) (let ((orig (current-language))) (current-language 'scheme) (define-module name #:use-module (has-foo)) ... (current-language orig))) Thanks -- Rob Browning rlb @default

Re: Distributed verification of release tarballs using Guix? (was Re: Releasing 2.2.5?)

a lot of relevant heavy-lifting over the past few years (working on the relevant tools, generating patches or workarounds, etc.). Their diffoscope tool might also be of interest: https://reproducible-builds.org/tools/ -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A

Re: Distributed verification of release tarballs using Guix? (was Re: Releasing 2.2.5?)

Ricardo Wurmus writes: > Ludovic and other folks in the Guile and Guix communities are > participating in the reproducible builds effort since the first summit. Oh, excellent. (Now that you mention it, I think I remember seeing Guix mentioned, and had just forgotten.) Thanks -- Rob Br

Should letrec via syntax work within eval-when (expand load eval)?

fine without the eval-when, and I wondered if that was expected. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Should letrec via syntax work within eval-when (expand load eval)?

Rob Browning writes: > I narrowed down an issue I'd hit to this: > > ;; somefile.scm > (define-syntax foo > (syntax-rules () > ((_ any ...) (letrec ((x y) (y 'foo)) x > > (eval-when (expand load eval) (foo 1)) Wait, maybe that's just i

Re: Should an enclosing let keep the compiler from handling define-module?

e the current language, i.e. to rely on compile #:from #:to and load-compiled-file, etc. So if this doesn't seem like any real issue as far as Guile is concerned right now, feel free to disregard. And thanks for the response. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-0

Re: Should letrec via syntax work within eval-when (expand load eval)?

rror in > this case. Indeed, not strictly necessary, but would have been nice, so I'd have realized more quicly that I was doing it wrong. Thanks again for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: [PATCH] doc: Clarify documentation of 'bytevector-copy!'.

ATCH] doc: Clarify documentation of 'bytevector-copy!'. > > * doc/ref/api-data.text (Bytevectors): Reword documentation > to use 'nonnegative' instead of 'positive' for 0-based index. Reviewed-by: Rob Browning Looks good to me, excepting maybe the tab in the

Modules that work with 2.2 and 3.0 with re-export-and-replace

e of requiring a 2.2 update, which decreases it's appeal. In any case, if I'm not misunderstanding, I'm happy to help work on whatever improvement we prefer. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B

Should guile-3.0 cond-expand guile-2 and guile-2.2?

$ guile-3.0 -c '(display (cond-expand (guile-2.2 "?\n"))) ? Is that intentional? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Should guile-3.0 cond-expand guile-2 and guile-2.2?

Ludovic Courtès writes: > Rob Browning skribis: > >> $ guile-3.0 -c '(display (cond-expand (guile-2.2 "?\n"))) >> ? >> >> Is that intentional? > > I think so, though I don’t think this was discussed here. > > The way I see it, it

[PATCH 1/1] fports: handle revealed as unsigned everywhere and check range

The type is currently unsigned int, so respect that everywhere, and range check the adjustments. Note that this changes the ABI of scm_revealed_count(). --- If we don't want to change the ABI, then I imagine we could leave both scm_revealed_count and the data structure the same, and add some

[PATCH 1/1] (scheme base) member: return #f, not (), for no match

* module/scheme/base.scm (member): Match the r7rs requirement, as assoc already does. Thanks to Erik Dominikus for reporting the problem. Closes: 43304 --- Proposed for 3.0 module/scheme/base.scm | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/module/scheme/base.s

Re: [PATCH 1/1] (scheme base) member: return #f, not (), for no match

Rob Browning writes: > * module/scheme/base.scm (member): Match the r7rs requirement, as assoc > already does. > > Thanks to Erik Dominikus for reporting the problem. > > Closes: 43304 > --- > > Proposed for 3.0 Hmm, this causes a failure in r7rs.test. Not sure

Re: [PATCH 1/1] (scheme base) member: return #f, not (), for no match

Rob Browning writes: > Hmm, this causes a failure in r7rs.test. Not sure if I made a mistake, > or if other code depends on the incorrect behavior. Looking in to it. Ahh, it just revealed a bug in r7rs.test, i.e.: diff --git a/test-suite/tests/r7rs.test b/test-suite/tests/r7rs.test

[PATCH 1/1] scm_i_make_transcoded_port: fix mode for input/output ports

* libguile/r6rs-ports.c (scm_i_make_transcoded_ports): make sure to include SCM_RDNG for input/output ports. Thanks to Göran Weinholt for reporting the problem. Closes: 41045 --- Proposed for 3.0. libguile/r6rs-ports.c| 4 ++-- test-suite/tests/r6rs-ports.test | 26

[PATCH 1/1] Support mkdtemp via mkdtemp! and scm_mkdtemp

* doc/ref/posix.texi: Document mkdtemp! and scm_mkdtemp. * libguile/filesys.c: (mkdtemp!, scm_mkdtemp): New functions. Signed-off-by: Rob Browning --- Proposed for 3.0 and/or 2.2 (current patch is against 3.0). doc/ref/posix.texi | 14 ++ libguile/filesys.c | 48

Re: [PATCH 1/1] Support mkdtemp via mkdtemp! and scm_mkdtemp

up.org/onlinepubs/9699919799/functions/mkdtemp.html Not sure what our current bar is for checks. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: [PATCH 1/1] Support mkdtemp via mkdtemp! and scm_mkdtemp

Rob Browning writes: > Mike Gran writes: > >> Since mkdtemp already returns a string of the new directory name, >> it might be more scheme-like to not modify the input string, and instead >> just return the new directory name. > > Perhaps, though I was just matc

Re: [PATCH 1/1] Support mkdtemp via mkdtemp! and scm_mkdtemp

internal client of scm_i_mkdtemp. Oh, offhand, that seems fine to me -- I don't know that I had any reason for that other than that I just copied and adapted what had been done for mkstemp. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C6

[PATCH 1/1] scm_set_source_properties_x: optimize if only name, line, and/or col

* libguile/srcprop.c (scm_set_source_properties_x): When only a subset of file, line, and column fields are specified, store the data as a srcprops object (tc16_srcprops) rather than an alist. --- Proposed for at least 3.x. If we want some additional tests, then one option might be a public

Re: Clojure support

ed it to have a standard regex syntax/behavior across platforms. I've also thought I might like to see that as a (presumably optional) guile feature, though it'll make more sense if I ever finish the work I've started to migrate guile to utf-8 (or if someone else beats me to it) because pcr

Re: Clojure support

gt; (("subtrie-vector vector") > "subtrie-vector trie" > > (which has been merged upstream.) > (Or perhaps you encountered some other bug.) > > Possibly your version of pfds is simply out-of-date. Oh thanks, though lokke

[PATCH 1/1] Export (ice-9 ports) from (guile)

Without this, bindings like current-output-port won't be available after selectively importing (guile), e.g. (define-module (sandbox) #:pure #:use-module ((guile) #:hide (...)) * ice-9/boot-9.scm: export (ice-9 ports) exports from (guile). Thanks to Andy Wingo for helping track down th

[PATCH 3/8] pyutil: add INTEGER_TO_PY as BUP_LONGISH_TO_PY

Change to longish to hint that it only handles up to long (long)s. Signed-off-by: Rob Browning Tested-by: Rob Browning --- lib/bup/_helpers.c | 47 ++ src/bup/pyutil.h | 7 +++ 2 files changed, 29 insertions(+), 25 deletions(-) diff --git a

[PATCH 0/8] Move py C utility code to pyutil; guard overflow

Proposed for main. This starts moving some of the utility functions to src/bup/pyutil.*, so that we can use them everywhere, e.g. hashsplit, bupsplit... Rob Browning (8): bup_shared_cflags: add -Winline Create src/pyutil.c for utility functions pyutil: add INTEGER_TO_PY as

[PATCH 1/8] bup_shared_cflags: add -Winline

Signed-off-by: Rob Browning Tested-by: Rob Browning --- GNUmakefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GNUmakefile b/GNUmakefile index 6300acf6c..d762f32b7 100644 --- a/GNUmakefile +++ b/GNUmakefile @@ -43,7 +43,7 @@ os := $(call shout,$(os),Unable to determine

[PATCH 2/8] Create src/pyutil.c for utility functions

Signed-off-by: Rob Browning --- GNUmakefile| 2 +- lib/bup/_helpers.c | 29 ++--- src/bup/pyutil.c | 37 + src/bup/pyutil.h | 4 4 files changed, 44 insertions(+), 28 deletions(-) create mode 100644 src/bup/pyutil.c

[PATCH 6/8] _helpers: remove vestigial py2 utimes related code

Signed-off-by: Rob Browning Tested-by: Rob Browning --- lib/bup/_helpers.c | 180 - 1 file changed, 180 deletions(-) diff --git a/lib/bup/_helpers.c b/lib/bup/_helpers.c index 2ca4ef839..9bfb5e35a 100644 --- a/lib/bup/_helpers.c +++ b/lib/bup

[PATCH 8/8] Reject bup_getpwuid bup_getgrgid argument overflow

Replace PyArg_ParseTuple "K" checks (which ignore overflow) with BUP_ASSIGN_PYLONG_TO_INTEGRAL. Signed-off-by: Rob Browning Tested-by: Rob Browning --- lib/bup/_helpers.c | 25 - src/bup/pyutil.h | 4 ++-- 2 files changed, 18 insertions(+), 11 deletion

[PATCH 5/8] pyutil: add BUP_ASSIGN_PYLONG_TO_INTEGRAL; use EXPR_SIGNED

Check EXPR_SIGNED to simplify the handling, i.e. we know which path we're on up front. Signed-off-by: Rob Browning Tested-by: Rob Browning --- lib/bup/_helpers.c | 43 --- src/bup/pyutil.h | 39 +++ 2 files ch

[PATCH 4/8] pyutil: add bup_uint_from_py bup_ulong_from_py bup_ullong_from_py

Signed-off-by: Rob Browning Tested-by: Rob Browning --- lib/bup/_helpers.c | 58 -- src/bup/pyutil.c | 56 src/bup/pyutil.h | 4 3 files changed, 60 insertions(+), 58 deletions(-) diff --git a

[PATCH 7/8] HashSplitter_init: guard against bits/fanbits overflow

Replace PyArg_ParseTuple "I" conversion (which ignores overflow) with bup_uint_from_py. Signed-off-by: Rob Browning Tested-by: Rob Browning --- lib/bup/_hashsplit.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/lib/bup/_hashsplit.c b/lib/bup/_h

Re: [PATCH 0/8] Move py C utility code to pyutil; guard overflow

Rob Browning writes: > Proposed for main. > > This starts moving some of the utility functions to src/bup/pyutil.*, > so that we can use them everywhere, e.g. hashsplit, bupsplit... Apologies. Clearly the wrong git send-email address. -- Rob Browning rlb @defaultvalue.org and @de

[PATCH 1/7] srfi-10.test: add missing (test-suite lib) dependency

--- test-suite/tests/srfi-10.test | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/test-suite/tests/srfi-10.test b/test-suite/tests/srfi-10.test index c379d0bac..bc7a79157 100644 --- a/test-suite/tests/srfi-10.test +++ b/test-suite/tests/srfi-10.test @@ -17,7 +17,9 @@ L

[PATCH 7/7] Switch to the preferred parallel automake test harness

Here, this allows make -j4 check to run in about half the time that it does with the deprecated serial harness. --- Makefile.am| 3 --- check-guile.in | 5 +--- configure.ac | 5 +--- test-suite/Makefile.am | 18 - test-suite/driver | 60 ++

[PATCH 3/7] guile-test: set declarative #f to eliminate warning

--- test-suite/guile-test | 1 + 1 file changed, 1 insertion(+) diff --git a/test-suite/guile-test b/test-suite/guile-test index 2d4e94171..e0c4333f7 100755 --- a/test-suite/guile-test +++ b/test-suite/guile-test @@ -81,6 +81,7 @@ (apply (module-ref module 'main) args))) (define-module (t

[PATCH 2/7] interp.test: add missing (test-suite lib) dependency

--- test-suite/tests/interp.test | 3 +++ 1 file changed, 3 insertions(+) diff --git a/test-suite/tests/interp.test b/test-suite/tests/interp.test index 5f3e2aaf7..7497094a8 100644 --- a/test-suite/tests/interp.test +++ b/test-suite/tests/interp.test @@ -16,6 +16,9 @@ License along with thi

[PATCH 0/7] Allow tests to run in parallel

this might be interesting. If so, I can make whatever adjustments are desired (guessing perhaps changelog entries, etc.). I suspect eventually we might also want further adjustments to the output, but that might or might not be important in the first pass. Rob Browning (7): srfi-10.test: a

[PATCH 6/7] check-guile.in: exit 2 on errors and direct output to stderr

Return 2 rather than 1 for errors so that 1 will be available for any future boolean tests (as with say grep). Direct error message to stderr rather than stdout. --- check-guile.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/check-guile.in b/check-guile.in index 09d95a

[PATCH 4/7] guile-test: support automake parallel test harness via --trs-file

Support an optional --trs-file PATH argument that causes guile-test to write the status information expected by the automake parallel test harness to PATH. In addition, when --trs-file is specified, suppress the final test summary (via print-counts) since it would be repeated per-test-file when ru

[PATCH 5/7] check-guile.in: improve quoting (e.g. paths with spaces)

--- check-guile.in | 23 +-- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/check-guile.in b/check-guile.in index 214deec16..09d95a03c 100644 --- a/check-guile.in +++ b/check-guile.in @@ -14,25 +14,22 @@ set -e top_builddir=@top_builddir_absolute@ top_srcdir=@

Re: Close 10519, and, how to close bug on debbugs?

particular https://www.debian.org/Bugs/Developer discusses the NUMBER-done addresses. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Close 10519, and, how to close bug on debbugs?

Debian page does. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: [PATCH 0/7] Allow tests to run in parallel

Rob Browning writes: > This series switches Guile to the Automake parallel test harness so > that commands like "make -j4 check" can run tests concurrently: > https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html. > > Here it cuts the check ti

Re: [PATCH v1] SRFI-19: Add support for ISO 8601 zones with a colon.

(time-error 'string->date 'bad-date-template-string (list "Invalid time zone number" ch))) (set! ...)) (...and (not related), I also wondered about making some of the error messsages more specific, i.e. "Inval

Re: [PATCH v1] SRFI-19: Add support for ISO 8601 zones with a colon.

Oh, and for anyone else reviewing this, some specification-related info: https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F

Re: [PATCH v1] SRFI-19: Add support for ISO 8601 zones with a colon.

ate 'bad-date-template-string (list "Invalid time zone number" ch))) (set! ...)) -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: [PATCH v1] SRFI-19: Add support for ISO 8601 zones with a colon.

Rob Browning writes: > Apologies for the delay, and good point. I should have used eqv? rather > than char=?, i.e. > > (let ((ch (read-char port))) >(if (eqv? ch #\:) >(set! ch (read-char port)) >

Re: [PATCH] eval-string: Fix setting port column

(if (or compile? (not (language-evaluator lang))) >((load-thunk-from-memory Thanks - added a test and pushed to main. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: [PATCH v1] SRFI-19: Add support for ISO 8601 zones with a colon.

Denis 'GNUtoo' Carikli writes: > Yes, that makes the code much better and since when ch is eof, '(eqv? ch > #\:)' returns #f, so it should work. OK, pushed your commit to main. Thanks for the help -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011

[PATCH 5/6] scm_i_utf8_string_hash: don't overrun when len is zero

ges), and don't bother mutating length for the trailing bytes, since we don't need to. Signed-off-by: Rob Browning --- libguile/hash.c | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/libguile/hash.c b/libguile/hash.c index a038a11b

[PATCH 3/6] Add guile-procedures.txt to BUILT_SOURCES

Add guile-procedures.txt to BUILT_SOURCES to ensure it's available to tests. Without this, a "make check" from a clean checkout the "bit-extract documented?" test in bit-operations.test will fail. * Makefile.am (BUILT_SOURCES): add guile-procedures.txt Si

[PATCH 4/6] test-hashing: support 32-bit

Signed-off-by: Rob Browning --- test-suite/standalone/test-hashing.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/test-suite/standalone/test-hashing.c b/test-suite/standalone/test-hashing.c index 5982a0fdb..50e132989 100644 --- a/test-suite/standalone/test

[PATCH 1/6] define-meta-command: mention effects of a missing category

module/system/repl/command.scm: add comment. Signed-off-by: Rob Browning --- module/system/repl/command.scm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/module/system/repl/command.scm b/module/system/repl/command.scm index ca7450610..8b0422dbd 100644 --- a/module/system/repl

[PATCH 2/6] Ensure GUILE-VERSION changes propagate to .version and Makefiles

akefile.am (CONFIG_STATUS_DEPENDENCIES): drop. ($(top_srcdir/.version)): depend on Makefile. * configure: add GUILE-VERSION to CONFIG_STATUS_DEPENDENCIES via AC_SUBST. Signed-off-by: Rob Browning --- Makefile.am | 4 +--- configure.ac | 1 + 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/Mak

[PATCH 6/6] scm_i_utf8_string_hash: optimize ASCII

Since we already compute the char length, use that to detect all ASCII strings and handle those the same way we handle latin-1. Signed-off-by: Rob Browning --- libguile/hash.c | 28 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/libguile/hash.c b

[PATCH 0/6] A handful of post 3.0.10 fixups

I generated this set of patches while trying to track down the Debian buildd failures. Four of them are bug fixes, the other two are an optimization and a doc fix. Proposed for main, and if they're deemed plausible, I'll add relevant changelog entries and NEWS updates. Thanks Rob B

Re: [PATCH 3/6] Add guile-procedures.txt to BUILT_SOURCES

Rob Browning writes: > Add guile-procedures.txt to BUILT_SOURCES to ensure it's available to > tests. Without this, a "make check" from a clean checkout the > "bit-extract documented?" test in bit-operations.test will fail. > > * Makefile.am (BUILT_SO

[PATCH v2 4/6] scm_i_utf8_string_hash: don't overrun when len is zero

When the length is zero, the previous code would include the byte after the end of the string in the hash. Fix that (the wide an narrow hashers also guard against it via "case 0"), and while we're there, switch to u8_mbtouc since the unsafe variant is now the same (see the info pages), and don't b

[PATCH v2 6/6] define-meta-command: mention effects of a missing category

module/system/repl/command.scm: add comment. --- module/system/repl/command.scm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/module/system/repl/command.scm b/module/system/repl/command.scm index ca7450610..8b0422dbd 100644 --- a/module/system/repl/command.scm +++ b/module/system/repl/comm

[PATCH v2 3/6] test-hashing: support 32-bit

* test-suite/standalone/test-hashing.c (test_hashing): add expected value for 32-bit architectures. --- test-suite/standalone/test-hashing.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/test-suite/standalone/test-hashing.c b/test-suite/standalone/test-hashing.c index

[PATCH v2 0/6] A handful of post 3.0.10 fixups

d to v2 is to the patch, now "Ensure tests have guile-procedures.txt" that previously proposed adding it to BUILT_SOURCES. That wasn't quite right. Thanks Rob Browning (6): Ensure GUILE-VERSION changes propagate to .version and Makefiles Ensure tests have guile-procedures.txt

[PATCH v2 5/6] scm_i_utf8_string_hash: optimize ASCII

Since we already compute the char length, use that to detect all ASCII strings and handle those the same way we handle latin-1. libguile/hash.c (scm_i_utf8_string_hash): when byte_len == char_len, (i.e. fixed-width ASCII) optimize hashing via existing narrow path. --- libguile/hash.c | 28 +++

[PATCH v2 1/6] Ensure GUILE-VERSION changes propagate to .version and Makefiles

Have .version depend on the Makefile, and move our CONFIG_STATUS_DEPENDENCIES setting to an AC_SUBST, as recommended by the automake info pages "Rebuilding Makefiles" section, so that changes to GUILE-VERSION will update the VERSION, etc. in the generated Makefiles. * Makefile.am (CONFIG_STATUS_DE

[PATCH v2 2/6] Ensure tests have guile-procedures.txt

The tests depend on libguile/guile-procedures.txt, for example via documented? in bit-operations.test. Previously "make check -j..." in a clean tree would fail because libguile/guile-procedures.txt is built by ./Makefile.am (rather than libguile/Makefile.am) so that it will have a built module/ av

Re: [BUG] Eval sets incorrect runtime metainformation

t; (in a generalized way), and resolving Clojure's namespaced symbols to Guile module refs. For anyone interested in the current arrangement (the README also covers a bunch of limitations, differences, etc.): https://codeberg.org/lokke/lokke/src/branch/main/DESIGN.md -- Rob Browning rlb @defaultvalue.

Improving the handling of system data (env, users, paths, ...)

trade-offs/(security)-concerns, as mentioned in the PEP. [1] https://en.wikipedia.org/wiki/UTF-8#Encoding [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/uselocale.html [3] https://en.wikipedia.org/wiki/ISO/IEC_8859-1 [4] https://codeberg.org/rlb/guile/src/branch/utf8 [5] htt

Re: Improving the handling of system data (env, users, paths, ...)

ly that what's potentially in scope for now is "incremental". I'll also say that the broader discussion is interesting, and I do like to better understand how other systems work. > Le samedi 06 juillet 2024 à 15:32 -0500, Rob Browning a écrit : > >> The mos

RE: Improving the handling of system data (env, users, paths, ...)

rrent plan is to switch Guile to UTF-8 internally, which is why I've been including that in considerations. > Here is an alternative solution: Right, there are a lot of options if we're in the market for a "broader" solution, but my impression was that we aren't right n

Re: [PATCH v2 3/6] test-hashing: support 32-bit

Rob Browning writes: > * test-suite/standalone/test-hashing.c (test_hashing): add expected > value for 32-bit architectures. Pushed this one to main. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2

Re: [PATCH v2 6/6] define-meta-command: mention effects of a missing category

Rob Browning writes: > module/system/repl/command.scm: add comment. Pushed this one to main. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Debian package build problems with 2.0.9 (from git)

est might need another exception here: (and (or (= errcode EAI_NONAME) (and (defined? 'EAI_NODATA) ; GNU extension (= errcode EAI_NODATA)) (= errcode EAI_AGAIN) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011

Re: Debian package build problems with 2.0.9 (from git)

00 27725 write(1, " err: -11\n", 11) = 11 27725 write(1, "errno: 2\n", 9) = 9 27725 exit_group(0) = ? Hope this helps, and thanks. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Debian package build problems with 2.0.9 (from git)

a new release. It's quite handy to be able to use normal git commands with respect to upstream development. (And for anyone remotely interested -- I use git-dpm -- many thanks to Bernhard.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8

Preferences regarding Debian's Guile version string

1 So I wanted to check to see what your preferences might be, if any. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Preferences regarding Debian's Guile version string

" #define PACKAGE_PACKAGER_VERSION "2.0.9-deb+1-1" #define PACKAGE_PACKAGER_BUG_REPORTS "http://www.debian.org/Bugs/Reporting"; -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002

Re: Preferences regarding Debian's Guile version string

it doesn't show up in --help yet: $ meta/guile --help | grep Debian $ meta/guile -c \ '(use-modules (ice-9 pretty-print)) (pretty-print %guile-build-info)' \ | grep packager ((packager-bug-reports (packager-version . "2.0.9-deb+1-2~1.gbpedcc92") (packa

Guile 2.0.9 won't build on ia64 (segfault)

_syserror (subr=0x2033bec0 "mkdir") at error.c:167 #18 0x20104050 in scm_mkdir (path=0x60000021d300, mode=) at filesys.c:1282 ] -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Guile 2.0.9 won't build on ia64 (segfault)

e if that's possible -- in the meantime, if there are any tests you'd like me to run, just shout. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Guile 2.0.9 won't build on ia64 (segfault)

Rob Browning writes: > I'll see if that's possible -- in the meantime, if there are any tests > you'd like me to run, just shout. So while it might have been feasible, it turns out the relevant box has just gone down for the time being. But it also turns out that ia64

Placement of libguile-2.0.so.22.7.2-gdb.scm

start. Which made me wonder why a scm file ended up in /usr/lib (assuming I didn't cause that via packaging somehow). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592

Re: Placement of libguile-2.0.so.22.7.2-gdb.scm

ht place for it in Debian is /usr/share/gdb/auto-load. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Possibility of patching 2.0.5 for armhf support

assuming it doesn't require major changes. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Bug#758463: guile-2.0: Unable to cross-build to arm or arm64 (runtime endianness detection failure)

clause. In any case, I wanted to see how we'd like to handle this upstream so we can do something similar in Debian. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[PATCH 1/1] Add "&" asm constraint modifier to ASM_MUL outputs

Without this change, building for arm{hf,el} with gcc-4.9 (Debian 4.9.1-14) fails as follows: /tmp/ccdZTkXQ.s:14591: rdhi, rdlo and rm must all be different Thanks to Mark H Weaver for the suggestion. --- This should apply against 2.0.11. libguile/vm-i-scheme.c | 2 +- 1 file changed, 1 i

[PATCH 1/1] Recognize m68k, s390x, and sh4 as compilation targets

--- Though note that this is necessary, but not sufficient for sh4: http://buildd.debian-ports.org/status/package.php?p=guile-2.0&suite=sid Thanks module/system/base/target.scm | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/module/system/base/target.scm b/modul

Unintentional conflict in define-immutable-type?

xfoo) fixes the conflict, even though "define-immutable-type foo" actually creates a binding for , not foo. I thought there was a chance this might be unintentional. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 5

Re: Unintentional conflict in define-immutable-type?

but I was interested in immutability, and at the moment they don't appear to support it. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Unintentional conflict in define-immutable-type?

Ludovic Courtès writes: > The convention is indeed to use for the RTD. ...and so (just to clarify) the goops class for a record is supposed to be <> by default, and you'd need to (define <>) yourself afterward, if you wanted the goops class to appear more conventio

Re: Unintentional conflict in define-immutable-type?

(make-foo x) foo? (x x)) (display foo) (newline) (display ) (newline) Whether or not that's a good idea is of course a different question... Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG

  1   2   3   >