bug#13416: closed (Re: bug#13416: guile e0c211b segfaults when linked against libgc 7.1)

On Thu, Mar 7, 2013 at 11:13 PM, GNU bug Tracking System wrote: >> gc.c:212:1: warning: 'GC_get_free_space_divisor' defined but not used > > This comes (I think) from configuring Guile against one version of > libgc, then upgrading or downgrading libgc, and then running "make" > without reconfigur

bug#13903: Compile error

When compile guile 2.0.7, I got such error: make[3]: Entering directory `/home/wangwangwar/desktop/guile-2.0.7/libguile' CC libguile_2.0_la-fports.lo fports.c: In function 'fport_input_waiting': fports.c:613:10: error: variable 'pollfd' has initializer but incomplete type fports.c:613:10

bug#13905: (max inexact exact) => always inexact?

Not necessarily a bug, but I'd like to hear some thoughts on this. In current Guile (max -inf.0 9) => 9.0 The manual says > R5RS requires that, with few exceptions, a calculation involving inexact > numbers always produces an inexact result [...] The only exception to the > above requirement

bug#13905: (max inexact exact) => always inexact?

tags 13905 notabug close 13905 thanks Daniel Llorens writes: > Not necessarily a bug, but I'd like to hear some thoughts on this. > > In current Guile > > (max -inf.0 9) => 9.0 Yes, and this is correct. In general, the error of an inexact number is unbounded. Consider the inexact infinities (

bug#13905: (max inexact exact) => always inexact?

Daniel Llorens writes: > My interest in this is that I don't want > > (fold max -inf.0 exact-number-list) > > to return an inexact number. By the way, there's an easy way to accomplish what you want. Simply use 'reduce' (from SRFI-1) instead of 'fold': (reduce max -inf.0 exact-number-list)

bug#13905: (max inexact exact) => always inexact?

On Mar 8, 2013, at 19:59, Mark H Weaver wrote: > By the way, there's an easy way to accomplish what you want. Simply use > 'reduce' (from SRFI-1) instead of 'fold': > > (reduce max -inf.0 exact-number-list) I was about to roll my own, but this is exactly the case where fold doesn't work and r

bug#13904: A bug in guile's newest documentation.

Hello On 8 March 2013 16:39, Patrick Pan wrote: > 6.9.8 Procedures with Setters > > A procedure with setter is a special kind of procedure which normally > behaves like any > accessor procedure, that is a procedure which accesses a data > structure. The difference is > that this kind of procedure

bug#13857: Unhandled case in module/web/response.scm

On 3 March 2013 12:55, Jason Earl wrote: > On Sat, Mar 02 2013, Daniel Hartwig wrote: > >> Hello >> >> Which version of guile are you using? Is it from recent git? There >> are perhaps related fixes to the web modules made since January. > > Dang it. I knew that there was stuff that I had forgo

bug#13544: (web http) fails to parse numeric timezones in Date header

On 8 March 2013 06:28, Andy Wingo wrote: > On Thu 24 Jan 2013 23:13, l...@gnu.org (Ludovic Courtès) writes: > >> scheme@(guile-user)> (use-modules(web client)(web uri)) >> scheme@(guile-user)> (http-get (string->uri "http://www.sqlite.org/";)) >> web/http.scm:768:6: In procedure parse-asctime-date

bug#10522: Patch: Improve optional variable and keyword notation in manual

On 3 March 2013 17:45, Andy Wingo wrote: > On Sun 03 Mar 2013 02:07, Daniel Hartwig writes: > >> Can I ask whether it is preferred to use, e.g. @code{#f}, for the >> default values, as some places seem to and others don't. This patch >> is not using @code, but then, neither does it touch any doc

bug#10522: Patch: Improve optional variable and keyword notation in manual

On 9 March 2013 09:58, Daniel Hartwig wrote: > On 3 March 2013 17:45, Andy Wingo wrote: >> On Sun 03 Mar 2013 02:07, Daniel Hartwig writes: >> >>> Can I ask whether it is preferred to use, e.g. @code{#f}, for the >>> default values, as some places seem to and others don't. This patch >>> is not

bug#13544: (web http) fails to parse numeric timezones in Date header

On 9 March 2013 09:41, Daniel Hartwig wrote: > A survey of HTTP sites I performed > last year as research for another header issue in Guile showed > something like 1% of those sites using the numeric timezone format, > contrary to the specification. Reference:

bug#12216: peek-char incorrectly *CONSUMES* eof

On 8 March 2013 05:32, Andy Wingo wrote: > On Tue 05 Mar 2013 20:17, "David A. Wheeler" writes: > >> I reported: >>> > Guile's peek-char has a bug; it incorrectly *consumes* eof instead of >>> > just reporting it. >> >> Andy Wingo replied: >>> I have the feeling that for interactive use, if you e