property primitives doco
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 write such a procedure. Also, the text for primitive-property-set! says CODE, but the prototype says val. Perhaps that's a bit of a typo, unless I misunderstand it badly. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
array mapping doco
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!, perhaps ARRAY0 could be written DST-ARRAY or similar to avoid any confusion with the sources. The text could also probably have the sentence PROC is applied ... first, to get the primary action stated nice and prominently. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
tm:sec etc doco indexing
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 friends. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
weak key hash versus display
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) (display (hash-ref h k)) (newline) (display h) (newline) (gc) (display (hash-ref h k)) (newline) run with guile -s foo.scm produces 12345 #wh(() () () () () ((mykey . 12345)) ()) 12345 whereas I might have expected the gc to have collected the entry just set, making the second hash-ref give #f rather than 12345. This is what happens if the (display h) is not present. I don't really know if this is a bug, or ignorance on my part, but it seemed more than a little strange. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
doco cross references
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 reference for goops is (goops)GOOPS, but there seems to be
no such node. Maybe it should be something like
@pxref{Creating Generic Functions,,, goops, GOOPS}
In the What is libguile node of the guile tutorial, the cross
reference to the reference manual comes out as *Note Guile Reference
Manual: (Guile Reference Manual)Scheme data representation. which
clearly isn't a correct filename, and the node name seems to be out of
date too. Perhaps,
@ref{Data representation,, Data Representation in Guile,
guile, The Guile Reference Manual}
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: weak key hash versus display
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
mktime error reporting
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 -123) (mktime tm GMT) run with guile -s foo.scm gives the rather curious ERROR: In procedure mktime: ERROR: Success Who'd have thought success was an error :-). Of course readdir has set errno to 0 as part of its normal operation, and mktime has returned -1 for a bogus tm_year, but not set errno. I'm not actually sure what the standards say about mktime and errno, but a draft of C99 I've seen doesn't mention it setting errno, and certainly in glibc 2.3.1 it doesn't seem to get set. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: primitive-exit doesn't _exit
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 guile-gtk, since gtk recommends that _exit be used in a child process after forking. But I don't know if it should be primitive-exit doing this or a new function. I guess it depends whether there's a case for wanting C level atexit cleanups but not scheme level unwinds. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
gethost error display
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: misc-error ABORT: (host-not-found) I take it Exception during displaying of error means what it says. Nosing around the source it seems the error is thrown with string Host name lookup failure but with an extra argument (the bad host name), and simple-format objects to that extra. I don't know if the gethost error should be changed, it might break existing code to do so. But it might be nice if the default error handler was more forgiving of exception arguments. If the arguments are pretty much arbitrary then perhaps some sort of heuristic like using simple-format only if there's the right number of ~A or ~S in the string. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
syntax-rules and conditional define
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 value) (define-maybe x 123) but run with guile -s foo.scm gives /down/guile/usr/share/guile/1.6/ice-9/syncase.scm:130:16: In procedure scm-error in expression (scm-error (quote misc-error) who ...): /down/guile/usr/share/guile/1.6/ice-9/syncase.scm:130:16: invalid context for definition of x I guess I'm not sure if this is a bug, but (if (not (defined? 'x)) (define x 123)) worked at the top-level, so I thought perhaps it could be expected to in a macro too. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
segvs on memoized macro backtraces
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 bar.scm Each results in a partial backtrace printout then a segmentation violation, whereas naturally I hoped for a full printout. foo.scm has an obviously incorrect let, as revealled by running without --debug. Still, it'd be nice to get a backtrace to locate the problem. For what it's worth, gdb suggests perhaps unmemocopy has gone into an infinite or very long recursion (the call under the loop label), apparently overflowing the stack (the faulting insn being a pushl). bar.scm produces a correct macro expansion, I believe. (Uncommenting the pretty-print in the file shows what's being executed, or is supposed to be executed.) But the record-accessor call is requesting an incorrect field. Running without --debug shows that error. For what it's worth, gdb suggests scm_unmemocar has been reached with an env list of just one element, whereas SCM_IFRAME is 1, for which an env of two or more elements is apparently expected. (But all this is a mystery to me, so I wouldn't necessarily trust that analysis). foo.scm Description: Binary data bar.scm Description: Binary data ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
defining `app' breaks modules
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 #)): standard input:2:1: not-a-record my application name ABORT: (misc-error) It'd be nice if the module system implementation could protect itself against such stray defines. I guess there's a lot of things in boot-9.scm that could be upset, but app seems a particularly unfortunate one, since it's short and rather natural for some sort of application thing. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: virtual host support
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
srfi-1 reduce docs typo
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] http://mail.gnu.org/mailman/listinfo/bug-guile
source-properties versus set-source-properties!
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 (source-properties x)) (newline) (display (source-properties y)) (newline) run with guile --debug -s foo.scm prints ((breakpoint . #f) (line . 0) (column . 11) (filename . foo.scm)) () whereas I hoped it would print two lines the same, having copied the properties from x onto y. Nosing around srcprops.c, I guess set-source-properties! will put an alist in the hash table, but source-properties won't return that, instead always returning '() for anything except an srcprops object. If source-property and set-source-property! are to be believed then I guess either an srcprops or an alist is allowed in the hash, perhaps on that basis source-properties should simply return verbatim what it finds in the hash if it's not an srcprops. Ie. return SCM_EOL would become return p. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
unread-string character order
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 would be good. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
ice-9 lineio read-char versus unread-string
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 (open-input-string hello (unread-string world port) (display (read-char port)) (newline)) run guile -s foo.scm produces ERROR: Wrong number of arguments to #primitive-procedure string-ref whereas I hoped it would print a character. I guess this is just a missing index for the string-ref call in the getc handler of make-line-buffering-input-port. Judging by the substring taken I guess it should be 0. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
display-usage-report and keyword-symbol
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: unread-string character order
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] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [DOCPATCH]Revamp of doc/ref/scheme-control.texi
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, showing the new text. * scheme-control.texi (while do): Continue converting to active voice. I wouldn't worry about that sort of thing, not unless it's really unclear. * scheme-control.texi (begin): Added note about begin's uselessness. Well, it's only sometimes not required. If you want to add something, then perhaps a typical use in an `if'. Untabified. Fixed result indication in call-with-values example. Thanks, I applied these bits. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [DOCPATCH]Revamp of doc/ref/scheme-control.texi
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'. I assume you want me to repropose the remainder of the changes on guile-devel, as suggested earlier? Typos can go in immediately, the rest will need copyright paperwork. Yes, guile-devel is the best place to get feedback. Make sure your diffs are against the current cvs, for easy of applying. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Support for shared libraries is broken under hpux
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: doco scheme-data.texi: use of var for Scheme variable
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] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: patch to build guile CVS on Mac OS X
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 be increased for all systems. I think it'll be too hard to keep the conditionals right going forward otherwise. (The same size needs to be maintained for binary compatibility.) PS. Matters like this relating only to the development code can be raised on the guile-devel list. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: ice-9/q.scm bug fix
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] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: patch to build guile CVS on Mac OS X
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 :-). Conditionals like __APPLE__ are usually bad, since people end up unable to remember exactly why it was like that, and apple might make a new system, or make their existing system normal, or whatever. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: patch to build guile CVS on Mac OS X
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 defined(__APPLE__) defined(__DYNAMIC__)
+ environ = *_NSGetEnviron();
+#endif
+
That's really weird. I'd rather not do that if it can be avoided.
Surely they can't expect every library that accesses environ to get a
system-specific change?
Does it work to take the declaration of environ from stdlib.h
instead of giving an explicit extern? The autoconf way is normally
to let the headers do the job where possible.
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: patch to build guile CVS on Mac OS X
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. Does apple hide some advice on this somewhere in the man pages? (To put a reference to.) You may prefer the #define approach...I avoided it because I thought the init_xxx() stuff in guile was a clean enough place for it, and though I'm sure it's not an issue it would technically be more efficient not to do the function call on each access. Yep. But I'm guessing you need to hold the return from _NSGetEnviron, ie. the address of the environ variable, not its contents a given time. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: patch to build guile CVS on Mac OS X
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 thinking of just the #define, for simplicity. Though establishing some sort of scm_i_environ_location in init.c, and using it only under #ifdef PIC, would be optimal. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile segfaults
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 2004-01-06 15:34:23.0 +1000
@@ -473,7 +473,7 @@
scm_error_num_args_subr (what);
return pos + (SCM_INUM (args) - s-lbnd) * (s-inc);
}
- while (k !SCM_NULLP (args))
+ while (k SCM_CONSP (args))
{
ind = SCM_CAR (args);
args = SCM_CDR (args);
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: garbled documentation
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 as it could be either. In fact, most descriptions under the section Bit Vectors suffer from the same problem. I made a bit of a revision: Bit Vectors --- Bit vectors are a specific type of uniform array: an array of booleans with a single zero-based index. They are displayed as a sequence of `0's and `1's prefixed by `#*', e.g., (make-uniform-vector 8 #t #f) = #* - Scheme Procedure: bit-count bool bitvector - C Function: scm_bit_count (bool, bitvector) Return a count of entries in BITVECTOR equal to BOOL. For example, (bit-count #f #*000111000) = 6 - Scheme Procedure: bit-position bool bitvector start - C Function: scm_bit_position (bool, bitvector, start) Return the index of the first occurrance of BOOL in BITVECTOR, starting from START. If there is no BOOL entry between START and the end of BITVECTOR, then return `#f'. For example, (bit-position #t #*000101 0) = 3 (bit-position #f #*000 3) = #f - Scheme Procedure: bit-invert! bitvector - C Function: scm_bit_invert_x (bitvector) Modify BITVECTOR by replacing each element with its negation. - Scheme Procedure: bit-set*! bitvector uvec bool - C Function: scm_bit_set_star_x (bitvector, uvec, bool) Set entries of BITVECTOR to BOOL, with UVEC selecting the entries to change. If UVEC is a bit vector, then those entries where it has `#t' are the ones in BITVECTOR which are set to BOOL. When BOOL is `#t' it's like UVEC is OR'ed into BITVECTOR. Or when BOOL is `#f' it can be seen as an ANDNOT. (define bv #*0110) (bit-set*! bv #*10010001 #t) bv = #*11010011 If UVEC is a uniform vector of unsigned long integers, then they're indexes into BITVECTOR which are set to BOOL. (define bv #*0110) (bit-set*! bv #u(5 2 7) #t) bv = #*01100111 - Scheme Procedure: bit-count* bitvector uvec bool - C Function: scm_bit_count_star (bitvector, uvec, bool) Return a count of entries in BITVECTOR which are equal to BOOL, with UVEC selecting the entries to consider. UVEC is interpreted in the same way as `bit-set*!' above. Namely, if UVEC is a bit vector then entries which have `#t' there are considered in BITVECTOR. Or if UVEC is a uniform vector of unsigned long integers then it's the indexes in BITVECTOR to consider. For example, (bit-count* #*01110111 #*11001101 #t) = 3 (bit-count* #*01110111 #u(7 0 4) #f) = 2 ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: more garbled documentation in uniform arrays
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 organized into an arbitrary number of dimensions. Each cell can hold any kind of Scheme value and can be accessed in constant time by supplying an index for each dimension. This contrasts with uniform arrays, which use memory more efficiently but can hold data of only a single type. It contrasts also with lists where inserting and deleting cells is more efficient, but more time is usually required to access a particular cell. A conventional array is displayed as `#' followed by the rank (number of dimensions) followed by the cells, organized into dimensions using parentheses. The nesting depth of the parentheses is equal to the rank. When an array is created, the number of dimensions and range of each dimension must be specified, e.g., to create a 2x3 array with a zero-based index: (make-array 'ho 2 3) = #2((ho ho ho) (ho ho ho)) The range of each dimension can also be given explicitly, e.g., another way to create the same array: (make-array 'ho '(0 1) '(0 2)) = #2((ho ho ho) (ho ho ho)) A conventional array with one dimension based at zero is identical to a vector: (make-array 'ho 3) = #(ho ho ho) The following procedures can be used with conventional arrays (or vectors). An argument shown as IDX... means one parameter for each dimension in the array. Or a IDXLIST is a list of such values, one for each dimension. - Scheme Procedure: array? obj [prot] - C Function: scm_array_p (obj, prot) Return `#t' if the OBJ is an array, and `#f' if not. The PROT argument is used with uniform arrays (*note Uniform Arrays::). If given then the return is `#t' if OBJ is an array and of that prototype. - Scheme Procedure: make-array initial-value bound ... Create and return an array that has as many dimensions as there are BOUNDs and fill it with INITIAL-VALUE. Each BOUND may be a positive non-zero integer N, in which case the index for that dimension can range from 0 through N-1; or an explicit index range specifier in the form `(LOWER UPPER)', where both LOWER and UPPER are integers, possibly less than zero, and possibly the same number (however, LOWER cannot be greater than UPPER). - Scheme Procedure: array-ref array idx ... - Scheme Procedure: uniform-vector-ref array idx ... - C Function: scm_uniform_vector_ref (array, idxlist) Return the element at `(idx ...)' in ARRAY. (define a (make-array 999 '(1 2) '(3 4))) (array-ref a 2 4) = 999 - Scheme Procedure: array-in-bounds? array idx ... - C Function: scm_array_in_bounds_p (array, idxlist) Return `#t' if the given index would be acceptable to `array-ref'. (define a (make-array #f '(1 2) '(3 4))) (array-in-bounds? a 2 3) = #f (array-in-bounds? a 0 0) = #f - Scheme Procedure: array-set! array obj idx ... - Scheme Procedure: uniform-array-set1! array obj idxlist - C Function: scm_array_set_x (array, obj, idxlist) Set the element at `(idx ...)' in ARRAY to OBJ. The return value is unspecified. (define a (make-array #f '(0 1) '(0 1))) (array-set! a #t 1 1) a = #2((#f #f) (#f #t)) - Scheme Procedure: make-shared-array oldarray mapfunc bound ... - C Function: scm_make_shared_array (oldarray, mapfunc, boundlist) `make-shared-array' can be used to create shared subarrays of other arrays. The MAPPER is a function that translates coordinates in the new array into coordinates in the old array. A MAPPER must be linear, and its range must stay within the bounds of the old array, but it can be otherwise arbitrary. A simple example: (define fred (make-array #f 8 8)) (define freds-diagonal (make-shared-array fred (lambda (i) (list i i)) 8)) (array-set! freds-diagonal 'foo 3) (array-ref fred 3 3) = foo (define freds-center (make-shared-array fred (lambda (i j) (list (+ 3 i) (+ 3 j))) 2 2)) (array-ref freds-center 0 0) = foo - Scheme Procedure: shared-array-increments array - C Function: scm_shared_array_increments (array) For each dimension, return the distance between elements in the root vector. - Scheme Procedure: shared-array-offset array - C Function: scm_shared_array_offset (array) Return the root vector index of the first element in the array. - Scheme Procedure: shared-array-root array - C Function: scm_shared_array_root (array) Return the root vector of a shared array. - Scheme Procedure: transpose-array array dim1 ... - C Function: scm_transpose_array (array, dimlist) Return an array sharing
Re: --help
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
[bugs #6] non-valid prototype for inet_aton
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:11 (Australia/Queensland) What | Removed | Added --- Resolution | None | Fixed Status | Open | Closed -- Additional Follow-up Comments Thanks, I believe this has been addressed in 1.6. (The prototype is now only given when using the replacement inet_aton code.) /**/ [bugs #6] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=6 Project: Guile Submitted by: Clax On: Sun 05/06/01 at 13:56 Category: None Severity: 5 - Average Item Group: None Resolution: Fixed Assigned to: None Status: Closed Summary: non-valid prototype for inet_aton Original Submission: Ellu, I#039;ve downloaded and compiled Guile 1.4 under Linux Redhat 7.0, and found the following tiny bug: In the file libguile/net_db.c on row 85 there is a prototype for inet_aton with no arguments. This prototype conflicts with the real prototype for inet_aton in /usr/include/arpa/inet.h, at least under linux. thanks, Claes Follow-up Comments -- --- Date: Sat 04/17/04 at 00:11 By: kryde Thanks, I believe this has been addressed in 1.6. (The prototype is now only given when using the replacement inet_aton code.) For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=6 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
[bugs #869] README.autogen/README.newbie
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:36 (Australia/Queensland) What | Removed | Added --- Resolution | None | Works for me Status | Open | Closed -- Additional Follow-up Comments Alas, I believe the foibles of automake and libtool are too numerous to be described. Strictly speaking these are matters for those packages rather than guile. There's a HACKING file in the workbook (and the dist) with some notes concerning guile. /**/ [bugs #869] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=869 Project: Guile Submitted by: Tony Sidaway On: Wed 07/17/02 at 21:35 Category: None Severity: 5 - Average Item Group: None Resolution: Works for me Assigned to: None Status: Closed Summary: README.autogen/README.newbie Original Submission: A relatively old version of automake (1.4) and/or old libtool 1.3.3) caused autogen.sh to barf with a cryptic message about macro 'AM_PROG_LIBTOOL' not found in the library. Perhaps a README.autogen (or README.newbie) is called for. Points to watch out for: automake 1.6.2 is okay. libtool 1.4.2 is okay. After building libtool, be sure to perform a hash -r (if in bash) or rehash (in csh) if you have a /usr/local install coexisting with an older /usr install. Follow-up Comments -- --- Date: Sat 04/17/04 at 00:36 By: kryde Alas, I believe the foibles of automake and libtool are too numerous to be described. Strictly speaking these are matters for those packages rather than guile. There's a HACKING file in the workbook (and the dist) with some notes concerning guile. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=869 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
[bugs #872] README.autogen/README.newbie
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:40 (Australia/Queensland) What | Removed | Added --- Resolution | None | Duplicate Status | Open | Closed -- Additional Follow-up Comments Duplicate of bug #869. /**/ [bugs #872] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=872 Project: Guile Submitted by: Tony Sidaway On: Wed 07/17/02 at 23:00 Category: None Severity: 5 - Average Item Group: None Resolution: Duplicate Assigned to: None Status: Closed Summary: README.autogen/README.newbie Original Submission: A relatively old version of automake (1.4) and/or old libtool 1.3.3) caused autogen.sh to barf with a cryptic message about macro 'AM_PROG_LIBTOOL' not found in the library. Perhaps a README.autogen (or README.newbie) is called for. Points to watch out for: automake 1.6.2 is okay. libtool 1.4.2 is okay. After building libtool, be sure to perform a hash -r (if in bash) or rehash (in csh) if you have a /usr/local install coexisting with an older /usr install. Follow-up Comments -- --- Date: Sat 04/17/04 at 00:40 By: kryde Duplicate of bug #869. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
[bugs #1882] Doc bug: further reading link needs updating
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 at 00:24 (Australia/Queensland) What | Removed | Added --- Resolution | None | Fixed Status | Open | Closed -- Additional Follow-up Comments Thanks, I believe this is fixed in 1.6. /**/ [bugs #1882] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=1882 Project: Guile Submitted by: Judy Hawkins On: Wed 12/04/02 at 11:21 Category: None Severity: 5 - Average Item Group: None Resolution: Fixed Assigned to: None Status: Closed Summary: Doc bug: further reading link needs updating Original Submission: guile.info-4 Further Reading node bad link: http://www.cs.rice.edu/~dorai/t-y-scheme/t-y-scheme.html. That document is now at: http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html Follow-up Comments -- --- Date: Sat 04/17/04 at 00:24 By: kryde Thanks, I believe this is fixed in 1.6. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=1882 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: division by 0
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) is not the same as (/ 1 0), then I see that's the case. My guess would be that's wrong, probably both ought to give errors (on the basis there's no multiplicative inverse of an exact zero). This is the case in the cvs head, perhaps it should be made so in the 1.6 series too. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: logbit?
[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] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: MIN macro in numbers.c causes build problems on HP-UX
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 already. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: More problems on HP-UX ... 7
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 pthread_mutex_t is 88 bytes. Is that what you get? ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: More problems on HP-UX ... 6
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 think it was meant to be an int. But if you're in 7-bit ascii then it doesn't make a difference. backtrace.c: In function `display_frame_expr': backtrace.c:403: warning: subscript has type `char' numbers.c: In function `mem2uinteger': numbers.c:2337: warning: subscript has type `char' ... Thanks, I'll add some casts to int. They definitely want casts through unsigned char, to protect against 8-bit values. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: More problems on HP-UX ... 4
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. A #define to __builtin_alloca might be better than alloca.h. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: More problems on HP-UX ... macos
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 42 FAIL: test-system-cmds cannot determine stack base! FAIL: test-num2integral ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: More problems on HP-UX ... 2
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 which is wrong perhaps? scm_mark_locations (t-base, stack_len); ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: More problems on HP-UX ... 3
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 these defines are meant to be used. It might be different if every single file needed something. Currently, I can't build Guile CVS since autogen.sh fails on HP-UX as well as on Debian Woody (with autoconf and automake from backports.org). It get the error message possible undefined macro: AM_INIT_AUTOMAKE. Usually that's from not re-running aclocal. autoreconf in autogen.sh might be meant to do that, but I always do it manually. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Installation on AIX 5.1
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 preprocessor statement '#ifdef __STDC__' fails and varargs.h is included instead of stdarg.h. This causes the compile to fail with the following message: list.c, line 118.3: 1506-045 (S) Undeclared identifier va_alist. Thanks. Yes, rumour has it all AIX compilers are ansi but don't always define __STDC__. I see there's no actual support for varargs.h style in the way the va stuff is used. I'll change it to stdarg.h unconditionally. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used
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 disabled and the function definition starts further below in line 2131. I solved this problem locally by adding a forward declaration to eval.c. Thanks, I added that. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Patch for scm_strftime() in stime.c
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 zone name and dst? I think it should print what's in the tm record it's given. If the user has butchered the info then that's their problem. A patch for time.test is attached. Thanks, I made that change, but using set-tm:isdst. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: More problems on HP-UX ... 4
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 manual says about alloca being a builtin. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Small patch for srfi-19.test on HP-UX
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
Re: More problems on HP-UX ... 2
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] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: isinf is a macro on HP-UX
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 attached a patch that replaces the current test with a test that includes math.h. I guess the alternative is to leave configure alone and supplement the result of the test with #ifdef isinf in the C file. Though I suppose it's a bit disconcerting to see no in configure when one's libc docs say isinf exists. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Bug in http module of guile-www
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 provokes this. 139,140c139,144 parse-status-line I take it. (if second (make-shared-substring statline (1+ first) second) #f) No, that would be to end of string to get the status code. (if second (make-shared-substring statline (1+ second)) #f And I think that would be better as for an empty reason phrase. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug in http module of guile-www
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). ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: string-every returns #f when applied to an empty sequence
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? Thanks. If it's contrary to the spec then it's a bug in guile. Looks like guile also doesn't make the final predicate application a tail call the way the spec describes. Not sure how to fix that. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [patch] 1.6.4: configure syntax error with autoconf 2.59
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [patch] 1.6.4: aclocal 1.8 compatibility
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.) ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: another #! !# problem
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 scm_flush_ws, so the readrecparen funcs can see the close paren. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Documentation error: srfi-13, string-tokenize
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: minor proposed changed to guile doc
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 init [step]) ...) (test [expr ...]) body ... Bind VARIABLEs and evaluate BODY until TEST is true. The return value is the last EXPR after TEST, if given. A simple example will illustrate the basic form, (do ((i 1 (1+ i))) (( i 4)) (display i)) -| 1234 Or with two variables and a final return value, (do ((i 1 (1+ i)) (p 3 (* 3 p))) (( i 4) p) (format #t 3**~s is ~s\n i p)) -| 3**1 is 3 3**2 is 9 3**3 is 27 3**4 is 81 = 789 The VARIABLE bindings are established like a `let', in that the expressions are all evaluated and then all bindings made. When iterating, the optional STEP expressions are evaluated with the previous bindings in scope, then new bindings all made. The TEST expression is a termination condition. Looping stops when the TEST is true. It's evaluated before running the BODY each time, so if it's true the first time then BODY is not run at all. The optional EXPRs after the TEST are evaluated at the end of looping, with the final VARIABLE bindings available. The last EXPR gives the return value, or if there are no EXPRs the return value is unspecified. Each iteration establishes bindings to fresh locations for the VARIABLEs, like a new `let' for each iteration. This is done for VARIABLEs without STEP expressions too. The following illustrates this, showing how a new `i' is captured by the `lambda' in each iteration (*note The Concept of Closure: About Closure.). (define lst '()) (do ((i 1 (1+ i))) (( i 4)) (set! lst (cons (lambda () i) lst))) (map (lambda (proc) (proc)) lst) = (4 3 2 1) ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: (expt 2 (log 0)) hangs
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? -inf.0) = #t, which seems pretty wrong to me, so I changed that to #f. That expt now goes to pow(), giving 0. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: (expt 2 (log 0)) hangs
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. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: portable pthreads test
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 built on FreeBSD. Yep, I struck that too. Using gcc -pthread is probably enough, but what guile-config compile spits out needs to be considered. Giving -pthread might make that compiler-dependent (which is not really a problem in practice on a free system). ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: building gen-scmconfig.c on FreeBSD
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 -DHAVE_CONFIG_H, and may be unnecessary too. One thing for a proper cross-compile is to figure out $OBJEXT_FOR_BUILD, which may be different from the host system. I'd planned to go straight to an executable rather than through an obj. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: building gen-scmconfig.c on FreeBSD
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 host's compiler. You mean the build compiler I think. gen-scmconfig.c doesn't (and must not) depend on any target specific computations like sizeof(foo), etc. It is solely used as a portable way to generate scmconfig.h, taking into account the contents of config.h. Yep, which is why using $(INCLUDES), which is for the host compiler, seems doubtful. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: portable pthreads test
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 list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
[bugs #11197] Error in string-number
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 at 22:02 (Australia/NSW) -- Additional Follow-up Comments In fact only bases 2, 10 and 16 look right. Others have a bad bignum size calculation and overflow in various cases. Only bases 2, 8, 10 and 16 are documented as supported, though others (below 16) are not explicitly rejected. Maybe that should change too. /**/ [bugs #11197] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=11197 Project: Guile Submitted by: 0 On: Fri 12/03/04 at 08:10 Category: None Severity: 5 - Average Item Group: None Resolution: None Privacy: Public Assigned to: None Status: Open Summary: Error in string-number Original Submission: guile (string-number 11 7) 19608 guile (string-number 11 8) 37449 guile (string-number 11 9) unnamed port:4:1: In procedure bignum in expression (string-number 11 9): unnamed port:4:1: Numerical overflow ABORT: (numerical-overflow) Type (backtrace) to get more information or (debug) to enter the debugger. guile (string-number 11 10) 11 guile (string-number 11 11) 177156 Follow-up Comments -- --- Date: Sat 12/04/04 at 22:02 By: Kevin Ryde kryde In fact only bases 2, 10 and 16 look right. Others have a bad bignum size calculation and overflow in various cases. Only bases 2, 8, 10 and 16 are documented as supported, though others (below 16) are not explicitly rejected. Maybe that should change too. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=11197 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
[bugs #1877] cannot load srfi-13
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 at 23:02 (Australia/NSW) What | Removed | Added --- Resolution | None | Invalid Status | Open | Closed -- Additional Follow-up Comments Maybe guile should force its configured lib directory into the ltdl path. Leave it for now though. /**/ [bugs #1877] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=1877 Project: Guile Submitted by: Eric Hanchrow On: Tue 12/03/02 at 23:14 Category: None Severity: 5 - Average Item Group: None Resolution: Invalid Privacy: Public Assigned to: None Status: Closed Summary: cannot load srfi-13 Original Submission: GNU Guile, version 1.6.0 guile (use-modules (srfi srfi-1)) guile (use-modules (srfi srfi-13)) /usr/local/share/guile/1.6.0/srfi/srfi-13.scm:159:1: In procedure dynamic-link in expression (load-extension libguile-srfi-srfi-13-14-v-1 scm_init_srfi_13): /usr/local/share/guile/1.6.0/srfi/srfi-13.scm:159:1: file: libguile-srfi-srfi-13-14-v-1, message: file not found ABORT: (misc-error) Type (backtrace) to get more information or (debug) to enter the debugger. guile Follow-up Comments -- --- Date: Sun 12/05/04 at 23:02 By: Kevin Ryde kryde Maybe guile should force its configured lib directory into the ltdl path. Leave it for now though. --- Date: Tue 12/03/02 at 23:21 By: Eric Hanchrow offby1 Two minutes *after* submitting the above, it ocurred to me to run guile with LD_LIBRARY_PATH set to /usr/local/lib, and of course that fixed the problem. So consider this pilot error. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=1877 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
[bugs #2110] bug in threading implementation using guile-1.6.1
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 at 23:09 (Australia/NSW)
-- Additional Follow-up Comments
I'm pretty sure you're only meant to run one gtk-main (at any one time). It'd
be nice if guile or guile-gtk could protect against any ill effects of running
two, but I'm not sure where the actual problem lies.
/**/
[bugs #2110] Full Item Snapshot:
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=2110
Project: Guile
Submitted by: Stan Pinte
On: Thu 01/02/03 at 13:12
Category: None
Severity: 5 - Average
Item Group: None
Resolution: None
Privacy: Public
Assigned to: None
Status: Open
Summary: bug in threading implementation using guile-1.6.1
Original Submission: hello,
I am using multiple threads within a guile-gtk application.
a call to (gtk-threads-ensure-handler) ensures that a first thread gets
started, and
allows the rest of my program to execute. At the end of that program, I call
(gtk-main), to
wait in the Gtk event thread.
If I run my program without starting a second thread, it is ok, but as soon as
I invoke
(gtk-threads-ensure-handler), my CPU is used at 100%
NOTES:
1: I configured guile-1.6.1 using the --with-threads flag.
2: if I strace my process, I see this:
ioctl(7, FIONREAD, [0]) = 0
select(32, [6 7], [], [], {0, 0}) = 1 (in [6], left {0, 0})
gettimeofday({1041338430, 454970}, NULL) = 0
gettimeofday({1041338430, 455055}, NULL) = 0
ioctl(7, FIONREAD, [0]) = 0
select(32, [6 7], [], [], {0, 0}) = 1 (in [6], left {0, 0})
gettimeofday({1041338430, 455767}, NULL) = 0
gettimeofday({1041338430, 455852}, NULL) = 0
ioctl(7, FIONREAD, [0]) = 0
select(32, [6 7], [], [], {0, 0}) = 1 (in [6], left {0, 0})
gettimeofday({1041338430, 456429}, NULL) = 0
gettimeofday({1041338430, 456511}, NULL) = 0
ioctl(7, FIONREAD, [0]) = 0
select(32, [6 7], [], [], {0, 0}) = 1 (in [6], left {0, 0})
gettimeofday({1041338430, 457084}, NULL) = 0
gettimeofday({1041338430, 457166}, NULL) = 0
ioctl(7, FIONREAD, [0]) = 0
select(32, [6 7], [], [], {0, 0}) = 1 (in [6], left {0, 0})
gettimeofday({1041338430, 459008}, NULL) = 0
gettimeofday({1041338430, 459097}, NULL) = 0
ioctl(7, FIONREAD, [0]) = 0
select(32, [6 7], [], [], {0, 0}) = 1 (in [6], left {0, 0})
gettimeofday({1041338430, 459688}, NULL) = 0
gettimeofday({1041338430, 459771}, NULL) = 0
ioctl(7, FIONREAD, [0]) = 0
select(32, [6 7], [], [], {0, 0}) = 1 (in [6], left {0, 0})
and so on
-- I suspect a bug in the implementation of
coop_wait_for_runnable_thread () in libguile/isselect.c
if (QFIRST (coop_global_sleepq)-timeoutp)
gettimeofday (now, NULL);
return coop_wait_for_runnable_thread_now (now);
...
thanks a lot,
Stan
Follow-up Comments
--
---
Date: Sun 12/05/04 at 23:09 By: Kevin Ryde kryde
I'm pretty sure you're only meant to run one gtk-main (at any one time). It'd
be nice if guile or guile-gtk could protect against any ill effects of running
two, but I'm not sure where the actual problem lies.
---
Date: Fri 01/10/03 at 13:38 By: Stan Pinte stan_pinte
This only seems to happen when I make two calls two (gtk-main), indirectly.
- one via the (gtk-ensure-handler) call
- one afterwards, via the (gtk-main) call.
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=2110
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Problem compiling tests for guile 1.7.1
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, but might also make the problem go away. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: srfi-17 generates deprecated warnings
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 + cdadr cddar cdddr cr caaadr caadar caaddr cadaar cadadr + caddar cadddr cdaaar cdaadr cdadar cdaddr cddaar cddadr + cdddar cr string-ref vector-ref) Thanks, I made that change. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Problem diving complex numbers
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 in #.##.#i
Thanks. Looks like nobody ever divided by -i before :). I think it's
meant to be like:
--- numbers.c.~1.135.2.20.~ 2005-02-21 09:50:34.0 +1100
+++ numbers.c 2005-04-29 14:19:10.535828592 +1000
@@ -3738,7 +3738,7 @@
} else if (SCM_COMPLEXP (x)) {
double r = SCM_COMPLEX_REAL (x);
double i = SCM_COMPLEX_IMAG (x);
- if (r = i) {
+ if (fabs(r) = fabs(i)) {
double t = r / i;
double d = i * (1.0 + t * t);
return scm_make_complex (t / d, -1.0 / d);
@@ -3782,7 +3782,7 @@
{
double r = SCM_COMPLEX_REAL (y);
double i = SCM_COMPLEX_IMAG (y);
- if (r = i) {
+if (fabs(r) = fabs(i)) {
double t = r / i;
double d = i * (1.0 + t * t);
return scm_make_complex ((a * t) / d, -a / d);
@@ -3873,7 +3873,7 @@
} else if (SCM_COMPLEXP (y)) {
double ry = SCM_COMPLEX_REAL (y);
double iy = SCM_COMPLEX_IMAG (y);
- if (ry = iy) {
+ if (fabs(ry) = fabs(iy)) {
double t = ry / iy;
double d = iy * (1.0 + t * t);
return scm_make_complex ((rx * t + ix) / d, (ix * t - rx) / d);
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: FAIL: unif.test: make-shared-array: shared of shared
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 is a bit obscure and might otherwise be forgotten. (It's a real bug though, it breaks my charting program.) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Segfault using call/cc on ia64 (and possibly others)
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 mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: typos from guile/guile-core/ref/
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. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Unclear documentation: Options and Config, set! and enable/disable
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 was an attempt to make this interface appear analogous to set!, despite the option-symbols not being defined/bound. An example of a macro only serving to obscure :(. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: SRFI-17 generates re-export warnings
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 definitions, which is not what's wanted. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: using guile's readline module
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. (readline-options-interface needs to be exported from guile-readline/ice-9/readline.scm for use by the macros.) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: SLIB 3a2 does not work with Guile 1.6.4
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 might like to check it's hitting the right files. Incidentally, the (ice-9 slib) module which comes with guile probably doesn't work with the latest slib, running up guile.init as described in the slib docs is the way to go. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug list hard to find
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 used (?). It copies through to bug-guile, for whoever wants to takeup something. A few people have submitted bugs anonymously though, which makes it hard to get feedback, so mailing bug-guile directly is probably best. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.6.7 make problem
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 extern const scm_lt_dlsymlist lt_preloaded_symbols[]; scm_lt_dlpreload_default (lt_preloaded_symbols); I'm pretty sure they don't do anything on a normal gnu/linux system. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [bug #14925] Non-portable binary compilations on linux
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 OP was moving to an older one. - What do you mean statically linking from the share directory? I can't tell what that means either. Moved directories or something. Unlikely to be a good thing. But I don't see any way, either in this mail or in the bug report on savannah, to contact the submitter ... Unless the submitter is lurking here we'll have to close it as unable to be actioned, not aware of such a problem ... ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.6: fails to configure within the MinGW environment
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? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
[bug #15747] guile 1.6.7 is missing hash-for-each function
Update of bug #15747 (project guile): Status:None = In Progress Open/Closed:Open = Closed ___ Follow-up Comment #1: There's no hash-for-each in Guile 1.6, but it's going to be in 1.8. You can use hash-fold in 1.6. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15747 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
[bug #14925] Non-portable binary compilations on linux
Update of bug #14925 (project guile): Status:None = Need Info Open/Closed:Open = Closed ___ Follow-up Comment #1: We think __libc_stack_end is portable enough, we think it's upwardly compatible between glibc versions, which should be enough. Incidentally, it must be very difficult doing binary compilations on linux, I wasn't aware the kernel came with a compiler or shell or tools. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14925 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: string comparison vs. char comparison
[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 http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug in make-shared-array.
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 Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: pedantic stuff: C++ comments in 1.8.0
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
Re: guile and readline-5.1
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 shouldn't be getting used at all with readline 5.1. Please see whether configure has detected rl_cleanup_after_signal(), and put -DHAVE_RL_CLEANUP_AFTER_SIGNAL=1 into DEFS in the generated Makefile. The stuff in config.log should give a hint what went wrong if that function wasn't detected, post the relevant part if so. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: bug in eqv?
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 http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile and readline-5.1
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 cleaner way. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: bug in eqv?
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 too. -- library procedure: equal? obj1 obj2 `Equal?' recursively compares the contents of pairs, vectors, and strings, applying `eqv?' on other objects such as numbers and symbols. A rule of thumb is that objects are generally `equal?' if they print the same. `Equal?' may fail to terminate if its arguments are circular data structures. If -0.0 and 0.0 print differently, then there is no support for (equal? -0.0 0.0) == #t. I would read it that equal? is supposed to be the same as eqv? on numbers, and the bit about printing is only an aid to understanding the recursion (and not a terribly helpful one really). ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug in make-shared-array.
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 http://lists.gnu.org/mailman/listinfo/bug-guile
Re: 'Segmentation fault' in example program
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. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: configure cannot test when cross-compiling should be ok
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 calls and
signals interact on mingw.
--- configure-old-with-errors 2006-05-13 20:19:06.0 +1200
+++ configure 2006-05-15 02:44:35.0 +1200
@@ -37596,7 +37596,7 @@
See \`config.log' for more details. 5
echo $as_me: error: cannot run test program while cross compiling
See \`config.log' for more details. 2;}
- { (exit 1); exit 1; }; }
+ }
That's probably not what you want.
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Guile 1.8.0 make check fails
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 not so exact that the test can be relied on, not in its current form. [some other tests] They're just warnings, or bits still in progress. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Does not find header files or libraries under /usr/local
[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 from somewhere is fine, even good, but --with is not the place for it. http://www.gnu.org/prep/standards/html_node/Configuration.html Do not use a --with option to specify the file name to use to find certain files. That is outside the scope of what --with options are for. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: compile problems
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 --disable-elisp. Thanks. Easily fixed by some ifdefs. Or not forcing -Werror on unsuspecting users :-(. 3. throw.c:495 scm_handle_by_message control reaches end of non-void function. Thanks. Not sure what the correct behavior should be, perhaps it should 'return SCM_BOOL_F;' like the function scm_handle_by_message_noexit? It doesn't return so it doesn't matter. I guess exit or pthread_exit isn't marked as noreturn. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
