On Tue 05 Apr 2011 17:27, Wolfgang J Moeller writes:
> scm_i_print_symbol_name() in libguile/print.c ought not insert backslashes
> into "weird" symbol names that it prints using #{ ... }#,
> because the "extended read syntax" (in agreement with the documentation)
> doesn't treat backslashes spec
Hi Wolfgang,
On Tue 05 Apr 2011 17:27, Wolfgang J Moeller writes:
> scm_i_print_symbol_name() in libguile/print.c ought not insert backslashes
> into "weird" symbol names that it prints using #{ ... }#,
> because the "extended read syntax" (in agreement with the documentation)
> doesn't treat ba
On Thu 07 Apr 2011 18:04, Detlev Zundel writes:
> So it seems like guile wants simply to output a newline but the socket
> is closed already and the process then gets the SIGPIPE signal which
> guile is not prepared for.
Excellent debugging, Detlev! I pushed a (sigaction SIGPIPE SIG_IGN) to
(sy
On Mon, 11 Apr 2011, Andy Wingo wrote:
> On Tue 05 Apr 2011 17:27, Wolfgang J Moeller writes:
>
> > scm_i_print_symbol_name() in libguile/print.c ought not insert backslashes
> > into "weird" symbol names that it prints using #{ ... }#,
> > because the "extended read syntax" (in agreement with th
On Mon, 11 Apr 2011, Andy Wingo wrote:
>[...]
> > (*) Apparently, reading a "weird" symbol whose name contains "}#"
> > isn't provided for.
>
> Also; irritating. Relatedly it does not seem that Guile supports R6RS
> hex escapes in symbols. I guess the right thing to do is to allow for
> R6RS
Hi Andy,
> On Thu 07 Apr 2011 18:04, Detlev Zundel writes:
>
>> So it seems like guile wants simply to output a newline but the socket
>> is closed already and the process then gets the SIGPIPE signal which
>> guile is not prepared for.
>
> Excellent debugging, Detlev! I pushed a (sigaction SIGP
Hi,
On Mon 11 Apr 2011 14:23, Wolfgang J Moeller writes:
> Subsequently I noticed that `psyntax-pp.scm' is full of symbols
> #{name\ number}# which so far, would _not_ be read in
> as the original "gensym"s.
>
> This is going to change if you re-generate `psyntax-pp.scm'
> using the "fixed" GUIL
Hello again :)
On Mon 11 Apr 2011 15:08, Wolfgang J Moeller writes:
> Having any sort of escapes mixed with #{ }# notation would be incompatible -
> maybe you ought no longer generate #{ }# on output, but switch to R6RS escapes
> throughout. Since there has been (in my understanding) no way to r
Hi Ian,
On Wed 06 Apr 2011 03:11, Ian Price writes:
> Guile does not implement the optional second argument for log. I have
> attached a simple patch that implements it using the formula you learn
> in high school.
Thanks, applied.
We're brushing the point at which you should assign copyright
On Wed 06 Apr 2011 16:11, Ian Price writes:
> Over on Racket Users, Marco Maggi points out that ASSERT should return
> the value of the expression if it is true[0][1]. I have attached a
> simple patch to fix this behaviour in guile.
Thanks; applied.
Andy
--
http://wingolog.org/
Andy Wingo writes:
>
> We're brushing the point at which you should assign copyright to the
> FSF. Are you OK with that? Please let me know and I'll kick off the
> process.
Yeah sure. Just tell me what you need.
Regards,
Ian
On Thu 07 Apr 2011 16:47, Marijn writes:
> guile-2.0.0 fails to build without --disable-threads when libgc
> (boehm-gc in gentoo) is built without threads:
Can you try with a snapshot? Should be fixed in stable-2.0, but it
would be nice to get some feedback before releasing 2.0.1.
> Further gu
On Fri 08 Apr 2011 04:06, Ian Price writes:
> I'm not too familiar with guile's codebase, but I think I've found the
> bug. It's a fencepost error in the SEEK_SET case of bip_seek from
> libguile/r6rs-ports.c . I've attached a fix for stable-2.0
Yes, that does sound right. Good catch. Applied,
Andy Wingo wrote:
> I pushed a (sigaction SIGPIPE SIG_IGN) to (system repl repl), which
> should fix the issue.
Isn't this a bad idea? SIGPIPE generally indicates that something went
wrong. If we ignore it, important problems may go unnoticed. To me,
this seems kind of like ignoring SIGSEGV to
On Mon 11 Apr 2011 19:36, Mark H Weaver writes:
> Andy Wingo wrote:
>> I pushed a (sigaction SIGPIPE SIG_IGN) to (system repl repl), which
>> should fix the issue.
>
> Isn't this a bad idea? SIGPIPE generally indicates that something went
> wrong. If we ignore it, important problems may go unn
Thanks for the great response.
On Mon, Apr 11, 2011 at 10:32 AM, Detlev Zundel wrote:
> Hi Andy,
>
> > On Thu 07 Apr 2011 18:04, Detlev Zundel writes:
> >
> >> So it seems like guile wants simply to output a newline but the socket
> >> is closed already and the process then gets the SIGPIPE sig
Marijn wrote:
> guile-2.0.0 fails to build without --disable-threads when
> libgc (boehm-gc in gentoo) is built without threads:
>
> GENguile-procedures.texi
>0x75c140 is not a GC visible pointer location
>GC_is_visible test failed
I am following up here because I have a problem at the sam
17 matches
Mail list logo