In the Property Primitives node of the manual (in the cvs), there
seems to be no mention of what parameters are passed to the
not_found_proc taken by primitive-make-property.
Experimenting shows it's the property and the object, but it'd be good
to say that, since I think one needs to know to
In the Array Mapping section of the 1.6.1 manual, I think it'd be a
lot clearer if ra in the prototypes was the same as ARRAY in the
text. It's quite obscure until you twig to that, especially with
lra and ARRAY1 ... (there not being anything to do with a 1 in
the prototype).
For array-map!,
It'd be nice if tm:sec and friends in the Time node of the manual
could appear in the Procedure Index. Currently in emacs for
instance i tm or i tm: doesn't go to those functions. Having the
full set would be best, since C-h C-i for instance will complete on
them.
Similarly tms:clock and
In guile 1.6.1 or the cvs on a recent i386 debian, I noticed that
doing a display of a weak key hash table can seemingly prevent a key
from being garbage collected. For instance
(define h (make-weak-key-hash-table 7))
(define k mykey)
(hash-set! h (string-copy k) 12345)
In the Time node of the guile reference manual, the cross reference
to libc strftime looks like it should be Formatting Calendar Time
these days (eg. Debian packaged glibc 2.3.1), rather than Formatting
Date and Time.
In the Macros guile-snarf recognizes node of the reference manual,
the cross
Mikael Djurfeldt [EMAIL PROTECTED] writes:
We should probably replace this vector with a weak vector, or (perhaps
more efficient) clear the references from the vector.
Sounds wise, to avoid any chance of a program being badly bloated by
big structure kept around just because it was printed.
I noticed guile mktime includes errno in its error report, but I don't
think the C mktime sets errno.
For instance in guile 1.6.3 built on a recent i386 debian with glibc
2.3.1, a little foo.scm
(readdir (opendir .))
(define tm (gmtime (current-time)))
(set-tm:year tm
Andrew Pimlott [EMAIL PROTECTED] writes:
I think there needs to be some way to _exit. primitive-exit seems
like the natural way to me, but if not there, perhaps in a new
function.
Just to chuck in my two cents worth, I too think it'd be good to have
a _exit available. This would help
In guile 1.6.3 built on a recent i386 debian, running interactively
and trying to find a non-existant host with
(gethost x)
produces
standard input:1:1: In procedure gethost in expression (gethost x):
standard input:1:1: Unknown host
Exception during displaying of error:
In guile 1.6.3 on a recent i386 debian, I thought to make myself a
define if not already defined using
(use-modules (ice-9 syncase))
(define-syntax define-maybe
(syntax-rules ()
((define-maybe name value)
(if (not (defined? 'name))
(define name
In guile 1.6.3 built on a recent i386 debian, I struck a couple of
cases where memoized macros seem to induce segmentation violations
during a backtrace print.
The files foo.scm and bar.scm are two examples, each independent, to
be run as
guile --debug -s foo.scm
guile --debug -s
In guile 1.6.3 on a recent i386 debian, I was foolish enough to make a
define of app, promptly breaking use-modules. For example,
(define app my application name)
(use-modules (ice-9 rdelim))
gives
standard input:2:1: In expression (eval-case (# #) (else #)):
Jose Roberto B. de A. Monteiro [EMAIL PROTECTED] writes:
- (request (format #f ~A ~A ~A method path http:version))
+ (request (format #f ~A ~A ~A\r\nHost: ~A method path http:version
(url:host url)))
Perhaps the url:port should be included there too, at least if it's
not 80.
In the guile 1.6.3 reference manual, the node Fold, Unfold Map for
SRFI-1 says
`reduce' is a variant of `reduce'.
I wonder if that's a typo and it should be ... variant of `fold'.
___
Bug-guile mailing list
[EMAIL PROTECTED]
In guile 1.6.3 built on a recent i386 debian, it seems
source-properties and set-source-properties! don't really cooperate.
For instance a file foo.scm,
(define x '(1 2 3))
(define y '(4 5 6))
(set-source-properties! y (source-properties x))
(display
In the guile 1.6.3 on a recent i386 debian, I noticed unread-string
pushes back characters so the first of the string will be the next
returned by read-char.
I guess this is intentional, but it seems like the reverse of what I
might have expected. I think a note on this in the manual to clarify
In guile 1.6.3 on a recent i386 debian I was nosing around ice-9
lineio and struck an apparent problem with read-char used after an
unread-string. For instance a program foo.scm
(use-modules (ice-9 lineio))
(let ((port (make-line-buffering-input-port
In guile 1.6.3, while nosing around display-usage-report I noticed a
call to keyword-symbol, but there doesn't seem to any such function as
far as I can tell.
I haven't actually run display-usage-report, so very possibly I'm
horribly mistaken, but I wonder if it's meant to be keyword-symbol.
Rob Browning [EMAIL PROTECTED] writes:
Fixed in CVS. Thanks.
Actually, I think I might have merely managed to confuse myself.
Still, never hurts to say exactly how things work.
___
Bug-guile mailing list
[EMAIL PROTECTED]
Stephen Compall [EMAIL PROTECTED] writes:
I was planning on saving this until I could get all the way through
the file, but it's getting a little unwieldy, so please have a look.
ChangeLog at the bottom of this email.
It'll be easier to review if you post independent changes separately,
Stephen Compall [EMAIL PROTECTED] writes:
I don't know about that, but the named let section and do section were
suddenly much clearer after I converted them.
Those bits aren't too terrible but could probably stand a bit of
polish. Something in point form might clarify what happens in `do'.
John David Anglin [EMAIL PROTECTED] writes:
On hpux, libcrypt is only available as an archive library. Thus, it's
not particularly a great idea to linked it into a shared library.
Do you mean it can't be used at all from a shared library? Might have
to exclude support for it in that case.
Stephen Compall [EMAIL PROTECTED] writes:
However, var is intended for *metasyntactic* variables, not code
variables, for which I believe you should use @code.
Thanks, I fixed it.
___
Bug-guile mailing list
[EMAIL PROTECTED]
Richard Todd [EMAIL PROTECTED] writes:
+#ifdef __APPLE__
+#define SCM_MUTEX_MAXSIZE (12 * sizeof (long))
Hmm, I guess if that's what it takes.
For reference, how many bytes is the underlying actual mutex?
+#else
#define SCM_MUTEX_MAXSIZE (9 * sizeof (long))
+#endif
No, I think it should
Richard Todd [EMAIL PROTECTED] writes:
It appears to be a lisp-ism, where (not '()) was expected to return
#t, and of course in scheme it does not.
Thanks, I applied your fix.
___
Bug-guile mailing list
[EMAIL PROTECTED]
Richard Todd [EMAIL PROTECTED] writes:
Both normal and recursive mutexes are showing up as 44 bytes.
Thanks, I increased it.
I thought you might prefer that, but I was trying to make the smallest changes
to other architectures as possible, and let you make that call.
Yes, ... and no :-).
Richard Todd [EMAIL PROTECTED] writes:
+#if defined(__APPLE__) defined(__DYNAMIC__)
+#includecrt_externs.h
+static char ** environ;
+#else
extern char ** environ;
+#endif
#ifdef HAVE_GRP_H
#include grp.h
@@ -1735,6 +1740,10 @@
void
scm_init_posix ()
{
+#if
Richard Todd [EMAIL PROTECTED] writes:
Here's a KDE project that tried to be cleaner by defining:
#define environ (*_NSGetEnviron())
http://cvs.sourceforge.net/viewcvs.py/kcvdphoto/kimg2mpg/aclocal.m4?rev=1.4
(still have to #ifdef out the extern declaration, though...)
That sounds cleanest.
Richard Todd [EMAIL PROTECTED] writes:
Would you like another patch for the environ stuff, or would you
rather commit something with the information you have and let me test it?
If you have copyright papers on file we can accept a patch, otherwise
I'll look into it at some stage.
I'm
Rouben Rostamian [EMAIL PROTECTED] writes:
Guile segfaults when given the following code:
(define a (make-uniform-array 1/3 3 3))
(uniform-array-set1! a 5.0 (cons 0 0))
Thanks, a dodgy argument check.
--- unif.c.~1.137.~ 2003-09-13 09:34:18.0 +1000
+++ unif.c
Rouben Rostamian [EMAIL PROTECTED] writes:
- Scheme Procedure: bit-set*! v kv obj
- C Function: scm_bit_set_star_x (v, kv, obj)
This description is garbled. The procedure arguments are listed
as v kv obj while the description refers to uve, BV, BOOL, etc.
Yep. It's not really as clear
Rouben Rostamian [EMAIL PROTECTED] writes:
Essentially all items listed in this section need a good overhaul.
Yep. Bit of polish below. The hairy functions like enclose-array are
still not super clear.
Conventional Arrays
---
Conventional arrays are a collection of cells
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Report bugs to mailing-address.
Thanks, I added that.
I see we also print to stderr instead of stdout. I think I'll change
to use stderr when scm_shell_usage is called for a fatal exit, or
stdout for the plain usage message.
This mail is an automated notification from the bugs tracker
of the project: Guile.
/**/
[bugs #6] Latest Modifications:
Changes by:
Kevin Ryde [EMAIL PROTECTED]
'Date:
Sat 04/17/04 at 00
This mail is an automated notification from the bugs tracker
of the project: Guile.
/**/
[bugs #869] Latest Modifications:
Changes by:
Kevin Ryde [EMAIL PROTECTED]
'Date:
Sat 04/17/04 at 00
This mail is an automated notification from the bugs tracker
of the project: Guile.
/**/
[bugs #872] Latest Modifications:
Changes by:
Kevin Ryde [EMAIL PROTECTED]
'Date:
Sat 04/17/04 at 00
This mail is an automated notification from the bugs tracker
of the project: Guile.
/**/
[bugs #1882] Latest Modifications:
Changes by:
Kevin Ryde [EMAIL PROTECTED]
'Date:
Sat 04/17/04
Bernard Urban [EMAIL PROTECTED] writes:
Is (/ 1 x) always equal to (/ x) in 1.7 ?
This is actually my problem. It originates in the fact that hobbit
converts (/ x) to (/ 1 x), and for x = 0, it fails for 1.6.
You need to be clearer about what you're trying to report.
If you're saying (/ 0)
[EMAIL PROTECTED] (Jan Konecny) writes:
guile (logbit? 32 1)
#t
i think, it should be #f.
Thanks, that's a bug.
The 1L iindex shift wraps around (on many systems).
___
Bug-guile mailing list
[EMAIL PROTECTED]
Andreas Vögele [EMAIL PROTECTED] writes:
I suggest to remove the MIN macro from numbers.c. Instead, the lower
case macro min, which is definded in _scm.h anyway, can be used.
Sounds fair.
I'm wondering why the MIN macro was introduced at all.
I think I missed seeing that min() existed
Andreas Vögele [EMAIL PROTECTED] writes:
I can now link Guile but I get the following runtime error message:
Internal error: Need to upgrade mutex size
Thanks. There's a hard coded maximum size expected of a mutex in the
pluggable threads support stuff. On a hpux11 in 32-bit mode I see
Andreas Vögele [EMAIL PROTECTED] writes:
I think that the following warnings are caused by a bug in GCC
3.3.2.
No it arises from ctype.h supplied by your good friends at hp.
According to my copy of Programming in C it should be okay to
pass a char instead of an int to iscntrl() etc.
I
Andreas Vögele [EMAIL PROTECTED] writes:
It seems that alloca.h must be included on HP-UX even when Guile is
built with GCC.
eval.c: In function `deval':
eval.c:2910: warning: implicit declaration of function `alloca'
That's odd, it's meant to be a builtin outside of strict c89 or c99
mode.
Andreas Vögele [EMAIL PROTECTED] writes:
but building Guile CVS on HP-UX und Mac OS X is a nightmare.
On darwin5.5 for me it compiles, but doesn't run
ERROR: In procedure list:
ERROR: #unknown port:1:6: end of file
test-system-cmds: system exit status was 2 rather than
Andreas Vögele [EMAIL PROTECTED] writes:
I think that the wrong call has to be replaced with one of the
following calls.
Ah yes.
But which one?
Dunno. Do we have an expert here who can say?
t-base is the low address for an upward growing stack is it?, which
would mean it's just the cast
Andreas Vögele [EMAIL PROTECTED] writes:
_POSIX_C_SOURCE is also required in libguile/filesys.c for
readdir_r().
Beaut.
Wouldn't it be better to change configure.in instead of
the source files?
glibc advises putting it in the source file, so they're
self-contained. I think that's the way
Crane, Keith A [ITS] [EMAIL PROTECTED] writes:
Variable $^ was not recognized by AIX Make utility. Had to replace $^
with actual file name version.h.in in libguile/Makefile.
Thanks, I made that change.
Needed to change libguile/list.c to use header file stdarg.h. For some
reason the
Andreas Vögele [EMAIL PROTECTED] writes:
If Guile CVS is built with --disable-deprecated GCC 3.4 fails to build
eval.c. The problem is that the function scm_macroexp(), which is
used in line 1941 of eval.c, is not declared. The prototype is not
declared in eval.h if deprecated functions are
Ah, no, I see this is still not right. scm_m_generalized_set_x is
using scm_macroexp, but it's not defined at all under
--disable-deprecated.
Looks like this was a change by Marius not so long ago. Dunno if it
should be using scm_macroexp, or something else now.
Andreas Vögele [EMAIL PROTECTED] writes:
I thought about this problem. It's probably better to fix the test
instead of scm_strftime().
Yep, it looks pretty dodgy. I wonder what it was trying to exercise.
Or do you think that scm_strftime() should silently fix
mismatches between the time
Andreas Vögele [EMAIL PROTECTED] writes:
Here's the patch that I use.
Hmm. I don't really want to make that change. What's there now is
what autoconf recommends, and I'd rather see it changed in autoconf
first. That's if a change is needed, since what you report
contradicts what the gcc
Andreas Vögele [EMAIL PROTECTED] writes:
A patch for srfi-19.test that uses EST5EDT instead of CET is attached.
Thanks, I made that change.
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
I wrote:
scm_mark_locations (t-base, stack_len);
I made this change (in the head) because it looks right. I tried to
test it on a hppa debian, but it hung at startup in
scm_lt_dlpreload_default :(.
___
Bug-guile mailing list
[EMAIL PROTECTED]
Andreas Vögele [EMAIL PROTECTED] writes:
isinf is a macro on HP-UX. Currently, configure.in uses
AC_CHECK_FUNCS, which checks for functions only, to check for
isinf.
It's tempting to look only for an isinf macro in the C file. I wonder
if any systems have only a function version.
I've
Robert Marlow [EMAIL PROTECTED] writes:
I happened accross a bug in the HTTP module of guile-www which seemed to
trigger when I visited a page which gave no headers and just whitespace
in the body.
Thanks. But I'm guessing it's actually an empty reason phrase in the
status line which
Thien-Thi Nguyen [EMAIL PROTECTED] writes:
in the status line (which has the form: VERSION CODE TEXT), i believe
TEXT is optional,
Yep, in rfc1945 at least. (My reading would be that the second space
is mandatory, though the code strips all trailing whitespace so loses
that).
Andreas Vögele [EMAIL PROTECTED] writes:
According to SRFI-13 the procedure string-every returns #t if it is applied
to an empty sequence (see
http://srfi.schemers.org/srfi-13/srfi-13.html#Predicates). But Guile's
implementation returns #f. Is this a bug in SRFI-13 or in srfi/srfi-13.c?
Maciej W. Rozycki [EMAIL PROTECTED] writes:
As of autoconf 2.59 due to the way AC_LIBOBJ gets expanded, the resulting
configure script contains ; fi alone in a line, which is not accepted at
least by bash 2.05b.
Thanks, that's been fixed in the cvs I think.
Maciej W. Rozycki [EMAIL PROTECTED] writes:
Since automake 1.8 aclocal requires macro names being defined by AC_DEFUN
to be quoted. Here is a patch that adds missing quotations.
Thanks, I made that change.
(Not sure what automake version will actually be used for the next
release though.)
Bill Schottstaedt [EMAIL PROTECTED] writes:
(begin
(display 1)
#!
(display 2)
!#
)
gets:
ERROR: In procedure scm_lreadr:
ERROR: tmp34.scm:6:2: unexpected )
Looks like #! !# doesn't work as the last thing in a list. Maybe that
comment should be detected and discarded in
Mike Small [EMAIL PROTECTED] writes:
The description of string-tokenize in 1.6.4
(doc/ref/srfi-modules.texi) does not seem to be quite accurate. The
part under the Scheme Procedure heading looks like it was fixed in
head in cvs,
Thanks, I brought that across.
first last [EMAIL PROTECTED] writes:
I propose that the following section replace the
current documentation for the DO function. It
essentially replaces test with terminate and
expr with result.
I revised `do' per below in the cvs head, perhaps it's clearer.
-- syntax: do ((variable
Bill Schottstaedt [EMAIL PROTECTED] writes:
(expt 2 (log 0))
gets into an infinite loop.
No, not infinite, it's calculating 2^(2^1024), you just have to be
patient, and have a lot of ram :-).
Thanks. I fixed integer-expt to reject an exponent +/-inf. It got
there because (integer?
Marius Vollmer [EMAIL PROTECTED] writes:
(exact? (integer-expt 2 2.0))
= #t
which seems wrong.
Yep, though it's been that way for a while.
Making the infinities integers was done on purpose, to follow the lead
of PLT Scheme.
Ahh, I backed out that part of my change.
Andreas Vögele [EMAIL PROTECTED] writes:
Here's a patch that replaces the test for the pthread library with the
macro from
http://www.gnu.org/software/ac-archive/htmldoc/acx_pthread.html.
Copyright paperwork will be needed before that can be used.
Without this patch Guile CVS cannot be
Andreas Vögele [EMAIL PROTECTED] writes:
gen-scmconfig.$(OBJEXT): gen-scmconfig.c
$(CC_FOR_BUILD) $(DEFS) $(INCLUDES) -c -o $@ $;
Yep, I'd been meaning to do that. But probably omitting $INCLUDES,
since they're likely to be host-system things, not build-system.
$DEFS probably only has
Rob Browning [EMAIL PROTECTED] writes:
Is CC_FOR_BUILD for executables that will be run on the host system?
No, for the build system.
If not, then we shouldn't be using it at all.
gen-scmconfig has to be run at build time by the host to generate the
header, so it needs to be built by the
Marius Vollmer [EMAIL PROTECTED] writes:
I say we don't need the papers for this. The code is not part of
Guile, we only use it.
Make sure the right copyright notice gets into configure, since that
file will be a joint work.
___
Bug-guile mailing
This mail is an automated notification from the bugs tracker
of the project: Guile.
/**/
[bugs #11197] Latest Modifications:
Changes by:
Kevin Ryde [EMAIL PROTECTED]
'Date:
Sat 12/04/04
This mail is an automated notification from the bugs tracker
of the project: Guile.
/**/
[bugs #1877] Latest Modifications:
Changes by:
Kevin Ryde [EMAIL PROTECTED]
'Date:
Sun 12/05/04
This mail is an automated notification from the bugs tracker
of the project: Guile.
/**/
[bugs #2110] Latest Modifications:
Changes by:
Kevin Ryde [EMAIL PROTECTED]
'Date:
Sun 12/05/04
Pierre [EMAIL PROTECTED] writes:
fail: scm_from_double (nan) == +nan.0
FAIL: test-conversion
See if you can trace through with gdb to see where it fails, ie. if
one of the operands is not a nan, or if the comparison has gone wrong.
A build with CFLAGS=-g will make source lines work properly,
Alan Grover [EMAIL PROTECTED] writes:
+ :re-export (setter))
I think that has to be an export at the end, since it's a redefinition
of a core procedure.
+(export
+ ;; redefined standard procedures
+ car cdr caar cadr cdar cddr caaar caadr cadar caddr cdaar
+
Jean Crepeau [EMAIL PROTECTED] writes:
There appears to be a bug in the 1.6.x releases of guile which wasn't
there in the 1.4.1 (and probably other versions before).
Yep, but those versions are prone to overflow when re or im is above
sqrt(DBL_MAX).
Simply doing
(/ 0-1i)
will result
Neil Jerram [EMAIL PROTECTED] writes:
FAIL: unif.test: make-shared-array: shared of shared
Any ideas?
There's something wrong with making a shared array from another shared
array. The base is or isn't offset or something.
I don't normally add tests that will immediately fail, but this one
Andreas Rottmann [EMAIL PROTECTED] writes:
Segfaults in the G-Wrap testsuite[0] seem to indicate that this might
be a problem on alpha,
Your one-liner seems ok for me on alpha. Propose something for the
test suite in any case.
___
Bug-guile
hyperdivision [EMAIL PROTECTED] writes:
various typos from chapter 4 that i've unveiled so far...
directory guile/guile-core/ of the current CVS.
Thanks, I made those changes, except for the autoconf/aclocal which I
changed to a pxref.
___
Alan Grover [EMAIL PROTECTED] writes:
It isn't clear from the documentation how to use the User Level Options
Interfaces (chapter Configuration, Features and Runtime Options).
Alas, yes.
Apparently, all of the group-set! are macros, and interpret the first
argument as a symbol. Perhaps this
Alan Grover [EMAIL PROTECTED] writes:
The (srfi srfi-17) module uses 'export' instead of 're-export', and thus
generates warnings.
You (I think it was you) already reported that, fixed in the cvs.
+ :re-export (
I'm pretty sure that makes you export the core versions instead of the
new
Gene Pavlovsky [EMAIL PROTECTED] writes:
guile (readline-set! bounce-parens 50)
unnamed port: In expression (readline-options-interface (append # #)):
unnamed port: Unbound variable: readline-options-interface
ABORT: (unbound-variable)
Fixed in the cvs, only waiting for the 1.6.8 release.
Alan Grover [EMAIL PROTECTED] writes:
* The guile.init file (provided in SLIB) has a bug:
Please report slib bugs to slib (Aubrey Jaffer).
ERROR: Unbound variable: with-load-pathname
I think I struck that once when I had the debian packaged slib
installed as well as another newer copy. You
Alan Grover [EMAIL PROTECTED] writes:
There does not appear to be any link from the
http://www.gnu.org/software/guile site to the bug-list.
I don't think there actually is an actively maintained bug list.
* There appears to be a bug-list feature in Savannah for the project,
but which isn't
josh kurlander [EMAIL PROTECTED] writes:
guile.c: In function main:
guile.c:91: error: array type has incomplete element type
guile.c:91: warning: unused variable lt_preloaded_symbols
gcc 4 has become stricter about structs not yet defined. I think you
can comment out the two lines
Neil Jerram [EMAIL PROTECTED] writes:
- Can you be more precise about how __libc_stack_end is non-portable?
(Is it just a matter of having a recent enough glibc?)
My guess would be __libc_stack_end is portable enough, in the sense of
being upward compatible between glibc versions. Maybe the
Peter Nobis [EMAIL PROTECTED] writes:
./configure --host=i586-mingw32msvc
checking for restartable system calls... configure: error: cannot run test
program while cross compiling
Are you actually cross compiling, or just trying to force the CPU-OS
tuple?
Update of bug #15747 (project guile):
Status:None = In Progress
Open/Closed:Open = Closed
___
Follow-up Comment #1:
There's no
Update of bug #14925 (project guile):
Status:None = Need Info
Open/Closed:Open = Closed
___
Follow-up Comment #1:
We think
[EMAIL PROTECTED] writes:
guile (string? s ß)
#f
guile (char? #\s #\ß)
#t
Ah dear. Thanks. The string funcs are signed, the char funcs are
unsigned. I think they used to be both unsigned.
___
Bug-guile mailing list
Bug-guile@gnu.org
Steve Juranich [EMAIL PROTECTED] writes:
Are there any workarounds for this?
There's something evil happening, I can't tell what it is. Marius was
the last to give the array bits a prod, he might be able to say.
___
Bug-guile mailing list
Mike Gran [EMAIL PROTECTED] writes:
There are some C++-style comments in 1.8.0.
Thanks, I applied that fix.
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Charles Ballard [EMAIL PROTECTED] writes:
I downloaded 5.1 from
the gnu site, which resolved all bar one of the issues.
_rl_init_argument seems to have been replaced by _rl_reset_argument.
Looks like the code in question in guile is designed as a fallback for
ancient realine 2.1 and 2.2, and
Aubrey Jaffer [EMAIL PROTECTED] writes:
Because (= 0.0 -0.0) is #t, (eqv? 0.0 -0.0) must be #t.
Ah dear, thanks. Bit too much creativity with the nans and infs.
___
Bug-guile mailing list
Bug-guile@gnu.org
Charles Ballard [EMAIL PROTECTED] writes:
(any chance of an AC_ARG_WITH readline prefix in the configure)
Probably not.
But ripping out the old rl_cleanup_after_signal compatibility bit
would be a possibility. If that would either then work straight away
with editline, or would fail in some
Aubrey Jaffer [EMAIL PROTECTED] writes:
SRFI-77 is the most preliminary of proposals, and guaranteed to be
withdrawn.
Yep. Seems to me the idea of base r5rs is reasonably clear (not
crystal clear, but near enough) that eqv? is the same as = on numbers.
Keeps the heirarchy of comparisons clean
Marius Vollmer [EMAIL PROTECTED] writes:
This behavior might or might not be a feature, but if you really want
it, it is probably better to use array-contents explicitely.
Yep, that should be an error.
___
Bug-guile mailing list
Bug-guile@gnu.org
Frithjof [EMAIL PROTECTED] writes:
Is my system just not set up correctly or is this a bug in Guile or one in
the example?
A bug in the example. If you don't have a HOSTNAME variable then
getenv returns NULL, and scm_str2string can't cope with NULL. I'll
change the manual. Thanks.
The Senator [EMAIL PROTECTED] writes:
checking for restartable system calls... configure: error: cannot run
test program while cross compiling
You should be able to force it with
./configure ac_cv_sys_restartable_syscalls=yes
or no if that's the right answer, I don't know how system
Hector Herrera [EMAIL PROTECTED] writes:
Running numbers.test
FAIL: numbers.test: number-string: (or (string=? (number-string
11.3 12) B.4) (string=? (number-string 11.3
12) B.409))
Thanks, I saw that too and was about to disable it. The conversions
are
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Often, `configure' scripts provide a `--with-PACKAGE-prefix' option (or
`--with-PACKAGE-includes', or `--with-PACKAGE-libs') so that one can
specify where to look fo a particular package.
Though that's contrary to the gnu standards. Getting a path
Ryan VanderBijl [EMAIL PROTECTED] writes:
1. configure couldn't find ltdl library, nor header file.
You need to install libtool (or the ltdl part of it). Guile no longer
comes with an out-of-date version :).
2. read.c:332 s_vector declared but not used warning,
when configured with
1 - 100 of 171 matches
Mail list logo
