Re: scm_i_print_symbol_name() in libguile/print.c ...

2011-04-11 Thread Andy Wingo 
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 specially, nor _usually_ needs escaping. (*)

Fixed now, I think.

Thanks for the report,

Andy
-- 
http://wingolog.org/

Re: scm_i_print_symbol_name() in libguile/print.c ...

2011-04-11 Thread Andy Wingo 
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 backslashes specially, nor _usually_ needs escaping. (*)
>
> I notice that the bug is already present in GUILE V1.8 .

Indeed, good catch.  I had seen this before but didn't fully understand
it.

> (*) 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 hex escapes in symbols, and escape '}', along with anything that's
not a printable character.

Andy
-- 
http://wingolog.org/

Re: Problem with netcat

2011-04-11 Thread Andy Wingo 
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
(system repl repl), which should fix the issue.  Thanks for the
debugging, and thanks for the report, John!

Andy
-- 
http://wingolog.org/

Re: scm_i_print_symbol_name() in libguile/print.c ...

2011-04-11 Thread Wolfgang J Moeller 
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 the documentation)
> > doesn't treat backslashes specially, nor _usually_ needs escaping. (*)
>
> Fixed now, I think.
>
> Thanks for the report,

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" GUILE. Hope it doesn't hurt ...

Thanks,

Wolfgang J. Moeller, Tel. +49 551 47361, wjmheenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+ http://www.heenes.com/

Re: scm_i_print_symbol_name() in libguile/print.c ...

2011-04-11 Thread Wolfgang J Moeller 
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 hex escapes in symbols, and escape '}', along with anything that's
> not a printable character.

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 read symbols
containing "}#" so far, just keep the "transparent" treatment of those
guile-private brackets on input.

Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjmheenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+ http://www.heenes.com/

Re: Problem with netcat

2011-04-11 Thread Detlev Zundel 
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 SIGPIPE SIG_IGN) to
> (system repl repl), which should fix the issue.  Thanks for the
> debugging, and thanks for the report, John!

Thanks for the fix - I can confirm that this works (guile survives) for
the cases where I saw the sigpipe before.

Cheers
  Detlev

-- 
I had nothing to do with implementing Gosmacs.  It was inspired
by the original Emacs, but that's all.  I would never have agreed
to use a language like Mocklisp.
 -- Richard Stallman in

Re: scm_i_print_symbol_name() in libguile/print.c ...

2011-04-11 Thread Andy Wingo 
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" GUILE. Hope it doesn't hurt ...

No, it doesn't.  The backslash was an accident, and anyway after fixing
the reader too #{foo\ bar}# reads the same as #{foo bar}#.  Those
symbols need to be unique lexically, but not globally, so it's not a big
deal.  At some point we will need globally unique gensyms but this
change does not adversely impact the current state of things.

Cheers,

Andy
-- 
http://wingolog.org/

Re: scm_i_print_symbol_name() in libguile/print.c ...

2011-04-11 Thread Andy Wingo 
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 read symbols
> containing "}#" so far, just keep the "transparent" treatment of those
> guile-private brackets on input.

We have a choice of ensuring that:

  (equal? (with-input-from-string (object->string sym) read) sym)

or preserving the old behavior that introduced spurious backslashes in
the symbol names.  Incidentally it does appear that }# could be read, in
theory, given the fact that }# in a name would be written out as }\#.
Strange stuff.  I think interpreting \ as a general escape is compatible
with the intentions of that code, and \x...; is generally compatible as
well, if we assume that nobody was escaping x in their own code, because
Guile sure wasn't.

Anyway, I do think that providing an option to just use r6rs syntax for
serialization is a good idea.  Unfortunately you can't do it in general,
because there is the #{}# case to deal with, but oh well.

Cheers,

Andy
-- 
http://wingolog.org/

Re: (@ (rnrs base) log) optional second argument

2011-04-11 Thread Andy Wingo 
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 to the
FSF.  Are you OK with that?  Please let me know and I'll kick off the
process.

Thanks,

Andy
-- 
http://wingolog.org/

Re: ASSERT should return a value

2011-04-11 Thread Andy Wingo 
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/

Re: (@ (rnrs base) log) optional second argument

2011-04-11 Thread Ian Price 
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

Re: guile-2.0.0 fails to build without threads

2011-04-11 Thread Andy Wingo 
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 guile configure warns about:
> configure: WARNING: unrecognized options: --disable-debug-freelist
> which I don't think it should do.

I think this is a newer autoconf feature to warn about unknown options.
I think this option was removed since 1.8.

Andy
-- 
http://wingolog.org/

Re: [r6rs] frontier port position rejected with bytevector ports

2011-04-11 Thread Andy Wingo 
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, and thanks for the
test.

Andy
-- 
http://wingolog.org/

Re: Problem with netcat

2011-04-11 Thread Mark H Weaver 
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 get around a memory access
to an unmapped area that would be inconvenient to prevent.

Furthermore, what happens if a REPL is started within a Guile process
that wants to install its own handler for SIGPIPE?

Why is a pipe being created here, anyway?  Why not just a socket?

 Best,
  Mark

Re: Problem with netcat

2011-04-11 Thread Andy Wingo 
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 unnoticed.  To me,
> this seems kind of like ignoring SIGSEGV to get around a memory access
> to an unmapped area that would be inconvenient to prevent.
>
> Furthermore, what happens if a REPL is started within a Guile process
> that wants to install its own handler for SIGPIPE?
>
> Why is a pipe being created here, anyway?  Why not just a socket?

Sorry, this isn't in (system repl repl), it's in (system repl server) --
so it's a socket.  If the socket is closed without cleanup, you might
get a SIGPIPE.  It's necessary in net-facing servers.  You don't get
this behavior if you don't --listen.

Regards,

Andy
-- 
http://wingolog.org/

Re: Problem with netcat

2011-04-11 Thread John Proctor 
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 signal which
> >> guile is not prepared for.
> >
> > Excellent debugging, Detlev!  I pushed a (sigaction SIGPIPE SIG_IGN) to
> > (system repl repl), which should fix the issue.  Thanks for the
> > debugging, and thanks for the report, John!
>
> Thanks for the fix - I can confirm that this works (guile survives) for
> the cases where I saw the sigpipe before.
>
> Cheers
>  Detlev
>
> --
> I had nothing to do with implementing Gosmacs.  It was inspired
> by the original Emacs, but that's all.  I would never have agreed
> to use a language like Mocklisp.
> -- Richard Stallman in 
>

Re: guile-2.0.0 fails to build without threads

2011-04-11 Thread Marco Maggi 
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 same
point when  building branch stable-2.0; I  have just fetched
from the repository, so I have the commit c89b452993...

  On  a i686-pc-linux-gnu, I  still have  installed Autoconf
2.65, while  I see that  the last is  2.68; I run  gcc (GCC)
4.6.0, and:

$ ldd /usr/local/lib/libgc.so.1.0.3
linux-gate.so.1 =3D>  (0xe000)
libpthread.so.0 =3D> /lib/libpthread.so.0 (0xb76e8000)
libdl.so.2 =3D> /lib/libdl.so.2 (0xb76e4000)
libgcc_s.so.1 =3D> /usr/local/lib/libgcc_s.so.1 (0xb76c7000)
libc.so.6 =3D> /lib/libc.so.6 (0xb7564000)
/lib/ld-linux.so.2 (0xb7762000)

  In the stable-2.0 branch I do:

$ git clean -dxf
$ ./autogen.sh
$ ./configure \
--prefix=3D/usr/local \
--enable-shared --disable-static \
CFLAGS=3D'-O3 -march=3Di686 -mtune=3Di686'

everything looks fine; then I do:

$ make

while it goes I see:

  CC libguile_2.0_la-rw.lo
  CC libguile_2.0_la-scmsigs.lo
scmsigs.c: In function 'signal_delivery_thread':
scmsigs.c:159:3: warning: implicit declaration of function 'GC_pthread_sigm=
ask' [-Wimplicit-function-declaration]
  CC libguile_2.0_la-script.lo
  CC libguile_2.0_la-simpos.lo

then:

  CC libguile_2.0_la-symbols.lo
  CC libguile_2.0_la-threads.lo
threads.c: In function 'launch_thread':
threads.c:962:3: warning: implicit declaration of function 'GC_pthread_deta=
ch' [-Wimplicit-function-declaration]
threads.c: In function 'scm_call_with_new_thread':
threads.c:997:3: warning: implicit declaration of function 'GC_pthread_crea=
te' [-Wimplicit-function-declaration]
  CC libguile_2.0_la-throw.lo
  CC libguile_2.0_la-trees.lo

then:

  SNARF  mallocs.doc
  SNARF  memoize.doc
memoize.c:478:***Mismatching FUNC_NAME.  Should be: `#define FUNC_NAME s_"@=
prompt"'
  SNARF  modules.doc
  SNARF  numbers.doc

then:

  SNARF  options.doc
  SNARF  pairs.doc
pairs.c:147:***Missing or erroneous `#define FUNC_NAME s_scm_cdr'
pairs.c:150:***Missing or erroneous #undef for scm_car:
pairs.c:155:***Missing or erroneous `#define FUNC_NAME s_scm_cddr'
pairs.c:158:***Missing or erroneous #undef for scm_cdar:
pairs.c:163:***Missing or erroneous `#define FUNC_NAME s_scm_cadr'
pairs.c:166:***Missing or erroneous #undef for scm_caar:
pairs.c:171:***Missing or erroneous `#define FUNC_NAME s_scm_cdddr'
pairs.c:174:***Missing or erroneous #undef for scm_cddar:
pairs.c:179:***Missing or erroneous `#define FUNC_NAME s_scm_cdadr'
pairs.c:182:***Missing or erroneous #undef for scm_cdaar:
pairs.c:187:***Missing or erroneous `#define FUNC_NAME s_scm_caddr'
pairs.c:190:***Missing or erroneous #undef for scm_cadar:
pairs.c:195:***Missing or erroneous `#define FUNC_NAME s_scm_caadr'
pairs.c:198:***Missing or erroneous #undef for scm_caaar:
pairs.c:203:***Missing or erroneous `#define FUNC_NAME s_scm_cr'
pairs.c:206:***Missing or erroneous #undef for scm_cdddar:
pairs.c:211:***Missing or erroneous `#define FUNC_NAME s_scm_cddadr'
pairs.c:214:***Missing or erroneous #undef for scm_cddaar:
pairs.c:219:***Missing or erroneous `#define FUNC_NAME s_scm_cdaddr'
pairs.c:222:***Missing or erroneous #undef for scm_cdadar:
pairs.c:227:***Missing or erroneous `#define FUNC_NAME s_scm_cdaadr'
pairs.c:230:***Missing or erroneous #undef for scm_cdaaar:
pairs.c:235:***Missing or erroneous `#define FUNC_NAME s_scm_cadddr'
pairs.c:238:***Missing or erroneous #undef for scm_caddar:
pairs.c:243:***Missing or erroneous `#define FUNC_NAME s_scm_cadadr'
pairs.c:246:***Missing or erroneous #undef for scm_cadaar:
pairs.c:251:***Missing or erroneous `#define FUNC_NAME s_scm_caaddr'
pairs.c:254:***Missing or erroneous #undef for scm_caadar:
pairs.c:259:***Missing or erroneous `#define FUNC_NAME s_scm_caaadr'
pairs.c:262:***Missing or erroneous #undef for scm_cr:
  SNARF  ports.doc
  SNARF  print.doc

and finally:

  SNARF  regex-posix.doc
  GENguile-procedures.texi
Throw without catch before boot:
Throw to key stack-overflow with args (#f "Stack overflow" #f #f)Aborting.
cat: write error: Broken pipe
/bin/sh: line 1: 14549 Done(1) cat alist.doc arbiters.doc a=
rray-handle.doc array-map.doc arrays.doc async.doc backtrace.doc boolean.do=
c bitvectors.doc bytevectors.doc chars.doc control.doc continuations.doc de=
bug.doc deprecated.doc deprecation.doc dynl.doc dynwind.doc eq.doc error.do=
c eval.doc evalext.doc expand.doc extensions.doc feature.doc fluids.doc for=
eign.doc fports.doc gc-malloc.doc gc.doc gettext.doc generalized-arrays.doc=
 generalized-vectors.doc goops.doc gsubr.doc guardians.doc hash.doc hashtab=
.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc list.doc load.doc m=
acros.doc mallocs.doc memoize.doc modules.doc numbers.doc objprop.doc