x-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Please let me know if I can provide further information.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
ls = {
0,
--- a/libguile/vm-engine.h
+++ b/libguile/vm-engine.h
@@ -74,7 +74,7 @@
#define FP_REG asm("%r16")
#endif
#ifdef __mc68000__
-#define IP_REG asm("a5")
+#define IP_REG asm("a3")
#define SP_REG asm("a4")
#define FP_REG
#endif
--
Rob Browning
rlb
an/patches/series
> --- guile-2.0-2.0.11+1/debian/patches/series 2014-04-23 19:11:29.0
> +0200
> +++ guile-2.0-2.0.11+1/debian/patches/series 2014-09-13 15:33:45.0
> +0200
> @@ -1,2 +1,3 @@
> 0001-Change-guile-to-guile-X.Y-for-info-pages.patch
> 0002-Mark-mutex-with-owner-not-retained-threads-test-as-u.patch
> +libtoolize-check.patch
--
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
o
>
> # ^^ Note that the byte-compiled file is world-readable
>
> $ strings ~rwp/.cache/guile/ccache/2.0-LE-4-2.0/home/rwp/myscript.go
> [...]
> DEADBEEFDEADBEEF
> secret-password
> [...]
--
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
x-case to use "body ..." instead of ". body" appears
to fix the problem.
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:
> With 2.0.11(-deb+1-9):
>
> scheme@(guile-user)> (use-modules (srfi srfi-64))
> scheme@(guile-user)> (test-group "foo" 13)
> :2:0: In procedure #:2:0
> ()>:
> :2:0: In procedure struct_vtable: Wrong type argument in
> pos
Rob Browning writes:
> Rob Browning writes:
>
>> With 2.0.11(-deb+1-9):
>>
>> scheme@(guile-user)> (use-modules (srfi srfi-64))
>> scheme@(guile-user)> (test-group "foo" 13)
>> :2:0: In procedure #> input>:2:0 ()>:
>> :2
Rob Browning writes:
> To follow up, it does look like it might be broken, but you can ignore
> my suggested fix.
I'm not that familiar with srfi-64, but it looks like the problem (if
it's not expected) is that test-group doesn't handle the case where it's
creatin
libc6 and
> libguile-ltdl-1 seems to work fine, and interrupts the read(2) call with
> the signal handler.
This appears to still be the case with at least Debian's 2.0.11+1-10
package, and setting the handler to something that doesn't perform IO
has the same effect (i.e. no alarm until
uld have been 765497, and so the Debian forwarded address would be
765497-forwar...@bugs.debian.org, as in the headers above.
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 5
detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
$
--
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
[If possible, please preserve the 816123-forwarded CC in any replies.]
Since the content of guile-procedures.txt can vary, perhaps it shouldn't
be in schemelib_DATA.
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816123
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
G
or Debian's guile-2.0, if it's not to complicated, I should
see if I can move it to libdir. Otherwise as described, /usr/share is
isn't.
--
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 14
Rob Browning writes:
> Andy Wingo writes:
>
>> Confirmed. I guess we could put this in libdir somehow. I wonder if we
>> shouldn't take advantage of the opportunity to do something more
>> sensible and extensible... the easy thing to do would be to just keep
&
Rob Browning writes:
> Perhaps I could move it to the %guile-build-info libdir, i.e. here
> /usr/lib/x86_64-linux-gnu/guile/2.0/guile-procedures.txt and make sure
> documentation-files includes that in its search list.
If there are no substantial objections, I'll consider tha
;s causing the trouble yet, but I augmented
read-until-prompt to print every line it reads to stderr, and nothing
appeared amiss there, at least.
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
merge 24819 24769
thanks
Rob Browning writes:
> I noticed that 00-repl-server.test had failed on some of the debian
> buildds like this:
>
> Running 00-initial-env.test
> Running 00-repl-server.test
> FAIL: 00-repl-server.test: repl-server: simple expression - argum
mpt to manually
reproduce the failure on a Debian porterbox.
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:
> We're seeing the same thing on a Debian powerpc buildd
> https://buildd.debian.org/status/fetch.php?pkg=guile-2.0&arch=powerpc&ver=2.0.11%2B1-9%2Bdeb8u1&stamp=1485708200&raw=0
>
> FAIL: fractions.test: fractions: (eqv? (expt 2 1/2) (
Rob Browning writes:
> OK, I can reproduce this on partch.debian.org now
> (https://db.debian.org/machines.cgi?host=partch):
>
> (jessie_powerpc-dchroot)rlb@partch:~/guile-2.0-2.0.11+1$ ./check-guile
> fractions.test
> Testing /home/rlb/guile-2.0-2.0.11+1/meta/guile
Rob Browning writes:
> Rob Browning writes:
>
>> OK, I can reproduce this on partch.debian.org now
>> (https://db.debian.org/machines.cgi?host=partch):
>>
>> (jessie_powerpc-dchroot)rlb@partch:~/guile-2.0-2.0.11+1$ ./check-guile
>> fractions.test
>&
ack-protector-strong' ./configure
make check
If that flag is the problem, I'm wondering whether for now I'd be better
off quashing it, or temporarily disabling the test. i.e. is the test
detecting that something's actually wrong, or does the flag just break
one of the test
details: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=+29464#11
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:
> While updating Debian to 2.2.3 (and trying to get 2.2 building on all
> the release architectures) I hit the previously reported
> test-out-of-memory failure, or something similar.
>
> I spent a while poking at it, and it looks like -fstack-protector-strong
d with -fno-stack-protector just
finished successfully, so for the moment, I think I may proceed with
that and get the builds started on the other architectures. Then I can
try removing -O0 again.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2
Rob Browning writes:
> I'm fairly sure it did, and a build with -fno-stack-protector just
> finished successfully, so for the moment, I think I may proceed with
> that and get the builds started on the other architectures. Then I can
> try removing -O0 again.
OK, without -O0 a
Rob Browning writes:
> OK, without -O0 and with -no-stack-protector, my local amd64 build was
> fine, but ppc64el still crashes in test-out-of-memory:
>
> https://buildd.debian.org/status/package.php?p=guile-2.2&suite=sid
Oh, and for those not familiar with the buildd, the l
d prebuilt -name "*.go" | wc -l
279
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
==
> 1 of 1 test failed
>
>
> Full log at https://buildd.debian.org/status/package.php?p=guile-2.2
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
ux-libc-dev
> powerpc: ftcbfs, ftcbfs
> ppc64el: successful
> s390x: ftcbfs
>
> I ran each ftcbfs build twice to rule out the possibility of a random
> ftcbfs. So we have a non-random ftcbfs for some architectures. I'm a bit
> surprised about s390x here as it is the only fai
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 if would be plausible to mark the test as
> un
Mark H Weaver writes:
> Would you like to try cherry-picking these commits and see if they fix
> the problem for you?
Uploaded as 2.2.3+1-5. Thanks 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 59
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
cm_to_double (12) = -3.58805e+199
> FAIL: test-conversion
> [...]
> ==
> 1 of 39 tests failed
> Please report to bug-guile@gnu.org
> ==
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C
t 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
need to define a base specialization using the original
equal? or do something equivalent.
I also noticed goops itself does this:
https://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/oop/goops.scm;h=837a667e602\
5b6f8ed7818e5a8efe064cca7843d;hb=791cae940afcb2b2eb2c167fe438be1dc1008a73
Rob Browning writes:
> You can work around the problem by stashing equal? somewhere else, and
> then define-generic will work after a (define equal? #f). Presumably
> you'd then need to define a base specialization using the original
> equal? or do something equivalent.
It
retitle 37461 Methods added to primitive generics don't always work
thanks
Rob Browning writes:
> A re-export doesn't affect the module using the re-exporter, and export
> and replace both fail with "Unbound variable: equal?", even though
> there's a (defin
Rob Browning writes:
> A re-export doesn't affect the module using the re-exporter, and export
> and replace both fail with "Unbound variable: equal?", even though
> there's a (define equal? ...) in the module.
Perhaps there was something else going on, but now
function, is discarded and replaced
by a new, empty generic function.
and might also mention the issue in the define-method docs.
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
For example, in 2.2.6:
scheme@(guile-user)> (define x (make-thread-local-fluid 'default))
scheme@(guile-user)> (fluid-ref x)
$1 = #f
Here's a possible fix and some (trivial) tests:
>From 31fa1050340271ca2f68ac5a6c66322912f915e0 Mon Sep 17 00:00:00 2001
From: Rob Bro
Even setting aside any security concerns, this caused tests to fail if
you ran them as a given user and then ran them again as another user.
---
It didn't look like we have anything like mkdtemp or I'd have used it
instead. And it looks like this might apply to, and it would be nice
to have s
It's
also easy to work around -- just change the first define to a
define-method.
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:
> And then I found that the the manual says this:
>
> If symbol was previously bound to a Scheme procedure (or
> procedure-with-setter), the old procedure (and setter) is incorporated
> into the new generic function as its default procedure (and se
cords/procedural.scm:130:2: ERROR:
1. &assertion-failure
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
(hash #:x most-postive-fixnum) hashes to the same value for all keyowrds
in at least 2.2 and 3.0. Here's one potential fix for 3.0, and I'd be
happy to adjust it for 2.2 if needed.
>From b380102564aad053f22586eb404e99c82635a3b0 Mon Sep 17 00:00:00 2001
From: Rob Browning
Date: Sun
> 10/7)
> FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0
> -10/7)
> FAIL: numbers.test: Number-theoretic division: truncate/: mixed types:
> (-130.0 10/7)
> FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (-130.0
> -10/7)
Thank
empted a seek on the fd that should
still be open.
For now, I've just commented out the test in the Debian packages, and
unless some other arrangements can be made, suspect we might want to do
the same thing in Guile itself.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG a
Rob Browning writes:
> I believe the problem is that if the gc doesn't collect the port when
> the test calls (gc), then the test (which recognizes that possibility)
> calls close-fdes on the underlying fd. However, the port still exists,
> and it may be garbage collected lat
Rob Browning writes:
> ...and I'd have to think about it more carefully, but if dropping
> the close-fdes call would completely prevent any subsequent test from
> re-using the fd unsafely before the lingering port is collected, then
> perhaps that's one potential fix.
I e
It looks like this has been resolved, but please feel free to re-open
the bug report if you think I've closed it in error.
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
bly fail with the same error after a handful of
attempts.
--
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 fix.
(I originally noticed because it breaks lokke, which like the elisp
dialect, depends more heavily on #nil.)
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
se-exception:
Unbound variable: make-struct/no-tail
Please let me know if I can help with further diagnosis.
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
Taylan Kammer writes:
> Closing this report but feel free to ask further questions.
Looks like the first attempt didn't take. Trying 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
s-an-expected-failure-for-n.patch
--
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
fi-60.html
--
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
al
> case '$(host_os)' in \
> darwin[56]*) \
> need_charset_alias=true ;; \
> - darwin* | cygwin* | mingw* | pw32* | cegcc*) \
> + darwin* | cygwin* | mingw* | pw32* | cegcc* | linux-musl*) \
> need_charset_alias=fa
. need_charset_alias is no longer mentioned anywhere in the tree).
I wonder if that means we need a different patch, or perhaps the problem
has been resolved.
--
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
Noticed while investigating a migration to utf-8 strings. After making
changes that routed non-ascii symbol hashing through this function,
encoding-iso88597.test began intermittently failing because it would
traverse trailing garbage when u8_strnlen reported 8 chars instead of 4.
Change the scm_i
Rob Browning writes:
> Noticed while investigating a migration to utf-8 strings. After making
> changes that routed non-ascii symbol hashing through this function,
> encoding-iso88597.test began intermittently failing because it would
> traverse trailing garbage when u8_strnlen repo
a bit so it's not
top of mind, though I hope to soon.)
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:
> Jenkins?
Oh, right (after looking back at the code).
I'll get back to you regarding this and the other questions after I
finish reviewing/remembering.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D
Ludovic Courtès writes:
> Rob Browning skribis:
>> + // Make sure a utf-8 symbol has the expected hash. In addition to
>> + // catching algorithmic regressions, this would have caught a
>> + // long-standing buffer overflow.
>> +
>> + // περί
>>
Rob Browning writes:
> OK, so unfortunately I don't actually recall how I came up with that
> number, but I can start over with some canonical approach to compute the
> value if we like.
I hacked up hash.c to let me call wide_string_hash() directly and
printed the hash for wchar_t
Noticed while investigating a migration to utf-8 strings. After making
changes that routed non-ascii symbol hashing through this function,
encoding-iso88597.test began intermittently failing because it would
traverse trailing garbage when u8_strnlen reported 8 chars instead of 4.
Change the scm_i
Noticed while investigating a migration to utf-8 strings. After making
changes that routed non-ascii symbol hashing through this function,
encoding-iso88597.test began intermittently failing because it would
traverse trailing garbage when u8_strnlen reported 8 chars instead of 4.
Change the scm_i
bit set, which trips
up further unboxed uses which error if the operand to `scm->u64` is
negative.
* module/language/cps/type-fold.scm (rem): Emit logand/immediate.
I also found some other issues I have patches for that I'll propose
separately, e.g. test-hashing needs a 32-bit &
Changing GUILE-VERSION doesn't update these deriviative files. This
patch may fix that:
>From 485b9c282e0b4e6c6317666129e433e90acf4dea Mon Sep 17 00:00:00 2001
From: Rob Browning
Date: Sun, 30 Jun 2024 12:27:38 -0500
Subject: [PATCH 1/1] Ensure GUILE-VERSION changes propagate to .ver
Some of the tests in the test-suite depend on guile-procedures.txt, but
nothing currently indicates that, and so a build in a clean tree may
fail.
This patch tries to fix that:
>From 2e391649fc17c1ecaa297e5ce4bf2bfae0963eaf Mon Sep 17 00:00:00 2001
From: Rob Browning
Date: Sun, 30 Jun 2024
The first patch attempts to fix that, and the second is an optimization
when then input is ASCII (since we already have the information we need
to detect that):
>From 619e3d3afec2c116007d9cb2ad32a500fb32a7dd Mon Sep 17 00:00:00 2001
From: Rob Browning
Date: Sun, 30 Jun 2024 22:41:40 -0
I'm closing this, suspecting that the issue has been resolved in newer
versions of Guile or the platform, or... But please feel free to
re-open it if that's mistaken.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0
Sweden
Linus Björnstam
Rob Browning (25 mins. ago) (inbox unread)
Subject: Re: bug#40809: Apology: documentation for srfi-modules broken?
To: Linus Björnstam
Cc: 40...@-donedebbugs.gnu.org
Date: Fri, 12 Jul 2024 20:07:48 -0500
Linus Björnstam writes:
> The warning I got was on Line
Sweden
Linus Björnstam
Rob Browning (25 mins. ago) (inbox unread)
Subject: Re: bug#40809: Apology: documentation for srfi-modules broken?
To: Linus Björnstam
Cc: 40...@-donedebbugs.gnu.org
Date: Fri, 12 Jul 2024 20:07:48 -0500
Linus Björnstam writes:
> The warning I got was on Line
Rob Browning writes:
> Changing GUILE-VERSION doesn't update these deriviative files. This
> patch may fix that:
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 14D
e-output}.
Hmm, it looks like this was fixed in
f27e8b855f45bff1fde82d4d0f155a72feebab3f
Thanks for the report.
--
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
[r...@defaultvalue.org: adjust commit message]
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
67e783d21a326eaf2
basename: check suffix against basename, not full argument
* libguile/filesys: check suffix against basename, not full argument.
Thanks for the report
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B
THORS
Robert Merkel <[EMAIL PROTECTED]> wrote this manpage.
.B guile
is GNU software. Guile is originally based on Aubrey Jaffer's
SCM interpreter, and is the work of many individuals.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Here's an updated guile.1 manpage. I just added a section documenting
GUILE_LOAD_PATH. I'd like to do the same for the guile info pages.
Should I just send those fixes here too?
Thanks
.\" Written by Robert Merkel ([EMAIL PROTECTED])
.\" augmented by Rob Browni
guile> (define xxx (make-vector 100))
guile> (vector-length xxx)
100
guile> (define xxx (make-vector 1))
guile> (vector-length xxx)
16113920
guile> (version)
"1.4"
--
Rob Brownin
TODO that mentions
that there's a known performance issue there (mention the
file/function(s)) so someone may see it and decide to work on it.
Also, at some point, it might be worth looking at
RScheme/Stalin/etc. to see if they have any good ideas on this issue
that we could use.
--
Rob Bro
bdir approach
doesn't involve too many changes, other than the move itself and a
little bit of automakery, I'm even OK with that approach if it's the
right solution.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E
gh change to be worried about, so I'd
be happy to if whoever performs the fix determines that it's not
"sweeping" :>
I think we need to sort out the goops method export issue before we
can release anyhow.
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com,
Neil Jerram <[EMAIL PROTECTED]> writes:
> This is now done. All works OK as far as I can tell, but I hope
> others will test this as well...
I'll release a 1.5.2 test tarfile soon and get it up on alpha.gnu.org.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com
the GC and can be freed when the
> above code sequence is aborted due to non-local exit.
So guile can exit a chunk of C code, "non-locally"? Is there any good
documentation about path of control issues in guile? i.e. I somewhat
presumed that C functions were "atomic", or ar
oblems (in SunOS 5.7, Solaris 2.7)
> I had to configure it --disable-shared.
Hmm. Could this one be a libtool version issue? What version of
libtool do you have available?
(Note that the upcoming 1.5.3 won't address your bugs, but if we can
get them worked out, 1.5.4 will.)
Thanks
--
Ro
ld (Jul 95) that it
> doesn't accept this switch and causes the entire build
> to halt. I deleted --force.
Hmm. Well I'm not sure what to do about this. Either you need a
newer makeinfo, or we'll need an autoconf test for the version of
makeinfo and choose to use -
be that the installed ltdl isn't as smart as the .la
files that our build tree copy of libtool is producing.
In the end, I still think we need to be using the system libtool
whenever it's a suitable version, but I'm wondering if maybe the
problem is that we need a better check to see i
his (though he may have just sent it
to me), and unless someone else gets to it sooner, I'll try and
integrate it soon.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
___
more, and you
don't mind, the easiest thing would be for you to get paperwork on
record for your guile related work at the FSF. Then you can just send
patches whenever you feel like it. If you're interested, just mail
[EMAIL PROTECTED] and they can set you up.
Thanks a lot for
Thomas Wawrzinek <[EMAIL PROTECTED]> writes:
> Hi!
>
> I had to make the following small change to Makefile.in in the
> libguile subdirectory to get 1.5.6 compiled on a Cygwin system.
Thanks.
Fixed in my trees, I'll commit when I finish some other bits.
--
Rob Brownin
de to branch_release-1-6 that are
> long-term applicable would be also made in HEAD roughly concurrently,
> but i guess this is saved for later?
I've been trying to make sure to migrate all my 1.6 patches to HEAD,
but there are still some outstanding. Of course some of the lag is
because I&#
ate" header arrangement.)
However, a function like
void scm_num2mpz(mpz_t dest, SCM src);
(or similar) might not be a bad idea. We could continue to provide it
in libguile or in a helper lib indefinitely, no matter what our
internal representation is.
--
Rob Browning
rlb @defaultvalue.org, @l
I'll add these to the list as I look back over numbers.c -- I've been
integrating GMP support, starting with our bignums, and I've already
fixed some similar issues (maybe these as well?).
I've filed your message as workbook/bugs/numbers-gmp-conversion. I'll
add other bits
ate the changes
into HEAD right now.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
f not, then I make a note of
the pending to-do item for 1.8. In some cases, coming up with a fix
for HEAD as well right now would likely be a waste of time.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F
ing: implicit declaration of function `sin'
Hmm. numbers.c has a #include at the top. Are fabs, sin,
cos, etc. in some other header on AIX5?
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG s
but we *are* planning to change it in libguile-ltdl.
This change may or may not ever make it into the guile 1.6 tree,
though. If not, it's definitely planned for 1.8.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03
seem to work nicely. Patch attached.
Thanks -- committed to the unstable tree.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
__
1 - 100 of 148 matches
Mail list logo
