t-suite/driver via
test-suite/Makefile.am. And of course there are other approaches we can
take, if/when 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 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0
en dealing with
"unencodable" system data (paths, environment variables, etc.). For
example, #u8"\b5;m-calibration.log" (Latin 1) when the system encoding
is UTF-8.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39
-explanatory and
> need not be manually annotated in Guile, e.g.:
I went ahead and moved SRFI-197 to the newer commit so we have the new
SPDX headers, but I also kept the license text in each file for now
under the assumption that I should stick to the current convention
until/unless Guile itself
Rob Browning writes:
> So for now I've attempted to just allow us to mix and match SRFI-64 and
> (test-suite lib) based tests by integrating SRFI-64 into the existing
> automake/check-guile arrangement via a suitable test driver.
I've pushed this preliminary support to main
Rob Browning writes:
> I was considering adding SRFI 197
> https://srfi.schemers.org/srfi-197/srfi-197.html,
> i.e. "pipeline/threading operators". I've incorporated the reference
> implementation, integrated the tests, and converted the documentation to
> texi
Maxim Cournoyer writes:
>> Rob Browning writes:
>> This does introduce some "noise" to the tests because it uses srfi-64
>> which writes to standard output by default. I imagine we might want to
>> add a test-suite/lib specific srfi-64 reporter at some point
-runner-group*, test-runner-test-name, etc.
That's why I was thinking about it, but then it also seems like the
other "extended" features of the current test suite (throwing fail,
unresolved, etc.) are the more notable concern anyway.
--
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
e your job slightly easier here, by not
> having to hunt and place the license text yourself in the source files:
> <https://github.com/scheme-requests-for-implementation/srfi-197/pull/5>.
Thanks much, for that, and the review.
I suppose the main question is still whether we want srfi-197 i
ting srfi 64 tests in the Guile test suite is
> done ad-hoc as I had done in the (unreviewed/unmerged) series here for
> example: https://lists.gnu.org/r/guile-devel/2023-12/msg00062.html
>
> See the file test-suite/tests/srfi-209.test.
Oh, thanks.
--
Rob Browning
rlb @defaultvalue.org and
t certain about was the handling of the per-file
copyrights. (Oh, and I'm planning to move the NEWS down into the "New
interfaces section".)
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
Rob Browning writes:
> I've incorporated the reference
> implementation, integrated the tests, and converted the documentation to
> texinfo.
This does introduce some "noise" to the tests because it uses srfi-64
which writes to standard output by default. I imagine we
non-integral type if it were easy enough to be sure. May not be a
problem at all.
> If I'm honest, it would help more to get reviews from people actually
> looking at the code...
Well, for what it's worth, I was hesitant too, but people asked me to
post my (as I told them) cursory co
iss
something important, I wondered if there would be any point, if it's
feasible, to define it as a non-integral type, even if just
temporarily, to force the compiler to expose any such situations.
And note that I didn't look carefully at what the main code was actually
*doing*
Maxime Devos writes:
> Otherwise (with the errno=… change mentioned in your other e-mail), it seems
> good to me.
Thanks again for the review. Broke it up into two commits, fixed a
couple of minor issues, and pushed it to main.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG
Rob Browning writes:
> SCM_LOCKED_SYSCALL(&scm_i_misc_mutex, global_name = ttyname (fd));
Forgot to put the strcpy inside the SCM_LOCKED_SYSCALL...
--
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
Rob Browning writes:
> if (err___ != EINTR) \
> break; \
Rather:
if (err___ !=
Rob Browning writes:
> If I get time, I might poke around a bit and see if the thing we've
> attempted to fix here might be more widespread.
I suppose something like this might serve as a generalization:
#define SCM_LOCKED_SYSCALL(lock, body) \
a bit and see if the thing we've
attempted to fix here might be more widespread.
Thanks again
--
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
Rob Browning writes:
> while(1)
> {
> // ttyname() may use a shared global buffer
> scm_i_pthread_mutex_lock (&scm_i_misc_mutex);
> global_name = ttyname (fd);
> err = errno;
> scm_i_pthread_mutex_unlock (&sc
)
break;
scm_async_tick ();
}
strcpy(name, global_name);
#endif // HAVE_TTYNAME
if (err)
return scm_from_int(err);
else
return scm_from_locale_string (name);
}
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1F
; while(error == EINTR) }.)
I don't understand -- Guile clearly intends to do a specific thing right
now for EINTR (described by SCM_SYSCALL and scm_syserror). Why should
ttyname() be treated specially?
And I feel like whether or not that specific approach should be
reconsidered is outside th
Rob Browning writes:
> I'll look a bit more closely at your locking concern. Unless there's
> something else going on, I completely agree that we don't want to exit
> without releasing the lock.
Assuming you don't see anything amiss, perhaps I'll include this
serve the existing scm_ttyname() behavior
for now.
I'll look a bit more closely at your locking concern. Unless there's
something else going on, I completely agree that we don't want to exit
without releasing the lock.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
G
t sure at first either, but then I saw that POSIX says "The value
of namesize is smaller than the length of the string to be returned
including the terminating null character" for the ERANGE case, so I
assumed it was included:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/ttyna
Rob Browning writes:
> + // Not necessary if ttyname() must also respect TTY_NAME_MAX.
> + // POSIX ttyname description isn't completely clear.
> + if (strlen (global_name) > TTY_NAME_MAX - 1)
> +errno = ERANGE;
Oops:
err = ERANGE
...and perhaps
Rob Browning writes:
> Oh, and in addition to wondering about using ttyname_r when it's
> available, if we did that, or even if we didn't, I could also see moving
> the shared code to a shared helper, but I was just starting with a
> "simpler" proposal (to
Rob Browning writes:
> Hmm, just to clarify. *I* didn't write any of that code, and hadn't
> considered it carefully yet -- I just replicated the existing
> scm_ttyname() code from posix.c, i.e. this just does what we already do
> there.
Oh, and in addition to wondering
ode from posix.c, i.e. this just does what we already do
there.
But of course, that may also warrant improvement.
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
Rob Browning writes:
> Call ttyname() rather than scm_ttyname() to avoid some
> extra work and having to catch the ENODEV.
I also wondered about using ttyname_r() when it's available, to avoid
locking, perhaps in a function shared by this and scm_ttyname(), but if
that's ev
In some situations, ttyname may return ENODEV even though isatty is
true. From ttyname(3):
A process that keeps a file descriptor that refers to a pts(4) device
open when switching to another mount namespace that uses a different
/dev/ptmx instance may still accidentally find that a device
John Paul Adrian Glaubitz writes:
> Is there a chance this particular Debian patch that fixes the segfault on
> 32-bit big-endian targets could be upstreamed?
It's at been filed upsteam, at least https://debbugs.gnu.org/45214
--
Rob Browning
rlb @defaultvalue.org and @debian.or
Rob Browning writes:
> r4rs.test crashes with a ttyname ENODEV while apparently trying to print
> a backtrace, so I don't know exactly what's wrong "underneath" yet.
> (Offhand, I wondered if the ENODEV might be (s)chroot-related somehow.)
...or how about tmux? Sud
Rob Browning writes:
> Offhand, the failure doesn't look quite the same, but think it's worth
> checking.
I tried it on perotto with most of the debian/patches, and it passes all
the tests except for one odd failure in r4rs.test, which I think is new?
i.e. the original 32-bit
but think it's worth
checking.
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
John Paul Adrian Glaubitz writes:
> Yes, freshly checkout out from Git and built with autogen.sh && configure &&
> make.
>
> You can try it yourself on the Debian porterbox perotto.
Just to verify, that was a "powerpc" (s)chroot there, so 32-bit,
bi
John Paul Adrian Glaubitz writes:
> Guile from git segfaults for me on 32-bit PowerPC:
And that was from a completely clean main tree (i.e. full bootstrap)?
Thanks for testing
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 3
root, which
now passes make check (excepting the tests debian already disables
there).
(I'll probably wait at least a bit for a 3.0.11 release before switching
debian unstable back to the newer version.)
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3
broken on 32-bit architectures:
https://buildd.debian.org/guile-3.0
So if that's what you have, you may need to stick with 3.0.9 for now. I
plan to downgrade debian/unstable to 3.0.9 this weekend.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1F
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
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
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
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
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
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.
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
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
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 +++
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
* 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
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
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
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
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
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
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
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
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
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
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
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
(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
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))
>
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
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
(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
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
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
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
---
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=@
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
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
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
---
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
---
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
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 ++
---
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
* 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
* 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
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
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
* 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
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
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
1 - 100 of 271 matches
Mail list logo
