Guile 1.7.91 has been released.

Guile 1.7.91 has been released.

[Marius Vollmer]

We are pleased to announce the release of Guile 1.7.91.  This is a
release candidate for Guile 1.8.  It can be found here:

    ftp://alpha.gnu.org/gnu/guile/guile-1.7.91.tar.gz

Its MD5 checksum is

    b2106c1b574e22ec67c4c2178074b5ec  guile-1.7.91.tar.gz

The plan is to release version 1.8.0 next weekend, 2006-01-19, if all
goes well.


The NEWS file is quite long.  Here are the most interesting entries:

  Changes since 1.6:

  * Guile is now licensed with the GNU Lesser General Public License.

  * The manual is now licensed with the GNU Free Documentation License.

  * We now use GNU MP for bignums.

  * We now have exact rationals, such as 1/3.

  * We now use native POSIX threads for real concurrent threads.

  * There is a new way to initalize Guile that allows one to use Guile
    from threads that have not been created by Guile.

  * Mutexes and condition variables are now always fair.  A recursive
    mutex must be requested explicitely.

  * The low-level thread API has been removed.

  * There is now support for copy-on-write substrings and
    mutation-sharing substrings.

  * A new family of functions for converting between C values and
    Scheme values has been added that is future-proof and thread-safe.

  * The INUM macros like SCM_MAKINUM have been deprecated.

  * The macros SCM_STRINGP, SCM_STRING_CHARS, SCM_STRING_LENGTH,
    SCM_SYMBOL_CHARS, and SCM_SYMBOL_LENGTH have been deprecated.

  * There is a new way to deal with non-local exits and re-entries in
    C code, which is nicer than scm_internal_dynamic_wind.

  * There are new malloc-like functions that work better than
    scm_must_malloc, etc.

  * There is a new way to access all kinds of vectors and arrays from
    C that is efficient and thread-safe.

  * The concept of dynamic roots has been factored into continuation
    barriers and dynamic states.

See NEWS and the manual for more details.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.7.91 has been released.

[Michael Tuexen]

Hi Marius,

the check for socklen_t fails incorrectly because socklen_t is
defined in /sys/socket.h on Mac OS X, and on BSD systems in general.

What about using

AC_MSG_CHECKING(for socklen_t)
AC_TRY_COMPILE([#ifdef HAVE_SYS_TYPES_H
                 #include <sys/types.h>
                 #endif
                 #include <sys/socket.h>],
                [socklen_t x = 1; return 0;],
                [AC_MSG_RESULT(yes)],
                [AC_MSG_RESULT(int)
                 AC_DEFINE(socklen_t, int, [Define a type for  
socklen_t.])])

instead of

AC_CHECK_TYPE(socklen_t, int)


Best regards
Michael

On Feb 13, 2006, at 12:15 AM, Marius Vollmer wrote:

> We are pleased to announce the release of Guile 1.7.91.  This is a
> release candidate for Guile 1.8.  It can be found here:
>
>     ftp://alpha.gnu.org/gnu/guile/guile-1.7.91.tar.gz
>
> Its MD5 checksum is
>
>     b2106c1b574e22ec67c4c2178074b5ec  guile-1.7.91.tar.gz
>
> The plan is to release version 1.8.0 next weekend, 2006-01-19, if all
> goes well.
>
>
> The NEWS file is quite long.  Here are the most interesting entries:
>
>   Changes since 1.6:
>
>   * Guile is now licensed with the GNU Lesser General Public License.
>
>   * The manual is now licensed with the GNU Free Documentation  
> License.
>
>   * We now use GNU MP for bignums.
>
>   * We now have exact rationals, such as 1/3.
>
>   * We now use native POSIX threads for real concurrent threads.
>
>   * There is a new way to initalize Guile that allows one to use Guile
>     from threads that have not been created by Guile.
>
>   * Mutexes and condition variables are now always fair.  A recursive
>     mutex must be requested explicitely.
>
>   * The low-level thread API has been removed.
>
>   * There is now support for copy-on-write substrings and
>     mutation-sharing substrings.
>
>   * A new family of functions for converting between C values and
>     Scheme values has been added that is future-proof and thread-safe.
>
>   * The INUM macros like SCM_MAKINUM have been deprecated.
>
>   * The macros SCM_STRINGP, SCM_STRING_CHARS, SCM_STRING_LENGTH,
>     SCM_SYMBOL_CHARS, and SCM_SYMBOL_LENGTH have been deprecated.
>
>   * There is a new way to deal with non-local exits and re-entries in
>     C code, which is nicer than scm_internal_dynamic_wind.
>
>   * There are new malloc-like functions that work better than
>     scm_must_malloc, etc.
>
>   * There is a new way to access all kinds of vectors and arrays from
>     C that is efficient and thread-safe.
>
>   * The concept of dynamic roots has been factored into continuation
>     barriers and dynamic states.
>
> See NEWS and the manual for more details.
>
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
>
>
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-devel
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> the check for socklen_t fails incorrectly because socklen_t is
> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.

What happens after the check fails?  Will Guile compile correctly
anyway?

(I tried 1.7.90 on a friends Powerbook.  It compiled, but the
testsuite didn't run.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Han-Wen Nienhuys]

In article <878xsdzk1z.fsf@zagadka.de>, Marius Vollmer  <mvo@zagadka.de> wrote:
>Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> the check for socklen_t fails incorrectly because socklen_t is
>> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.
>
>What happens after the check fails?  Will Guile compile correctly
>anyway?
>
>(I tried 1.7.90 on a friends Powerbook.  It compiled, but the
>testsuite didn't run.)


I get an error,


 i686-freebsd4-gcc -DHAVE_CONFIG_H -I. -I/home/hanwen/vc/gub/target/freebsd/src/guile-1.7.91/libguile -I.. -I.. -I/home/hanwen/vc/gub/target/freebsd/src/guile-1.7.91 -g -O2 -Wall -Wmissing-prototypes -MT posix.lo -MD -MP -MF .deps/posix.Tpo -c /home/hanwen/vc/gub/target/freebsd/src/guile-1.7.91/libguile/posix.c  -fPIC -DPIC -o .libs/posix.o
In file included from /home/hanwen/vc/gub/target/freebsd/src/guile-1.7.91/libguile/posix.c:122:
/home/hanwen/vc/gub/target/freebsd/system//usr/include/netdb.h:204: error: two or more data types in declaration specifiers


(crosscompile on linux/x86 to to freebsd 4.10/x86.)




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> the check for socklen_t fails incorrectly because socklen_t is
> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.

Let's figure this out in HEAD first and then put it into 1.8.1.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Han-Wen Nienhuys]

In article <87y80gyxrq.fsf@zagadka.de>, Marius Vollmer  <mvo@zagadka.de> wrote:
>We are pleased to announce the release of Guile 1.7.91.  This is a
>release candidate for Guile 1.8.  It can be found here:

cross-compiling from Linux/x86 to Mingw/x86:

Making all in libguile
make[2]: Entering directory `/home/hanwen/vc/gub/target/mingw/build/guile-1.7.91/libguile'
make[2]: *** Geen regel voor aanmaken doel `fileblocks.x', nodig voor `all'.  Stop.
make[2]: Leaving directory `/home/hanwen/vc/gub/target/mingw/build/guile-1.7.91/libguile'
make[1]: *** [all-recursive] Fout 1
make[1]: Leaving directory `/home/hanwen/vc/gub/target/mingw/build/guile-1.7.91'm


there is no fileblocks.* anywhere.  Configure mentions

## Remove fileblocks.o from the object list.  This file gets added by
## the Autoconf macro AC_STRUCT_ST_BLOCKS.  But there is no need.
#LIBOBJS="`echo ${LIBOBJS} | sed 's/fileblocks\.o//g'`"



I got this when configuring with 


/home/hanwen/vc/gub/target/mingw/src/guile-1.7.91/configure
--config-cache --enable-shared --disable-static
--build=i386-redhat-linux --host=i686-mingw32 --target=i686-mingw32
--prefix=/usr --sysconfdir=/usr/etc --includedir=/usr/include
--libdir=/usr/lib --without-threads --with-gnu-ld --enable-deprecated
--enable-discouraged --disable-error-on-warning --enable-relocation
--disable-rpath PATH_SEPARATOR=;
LDFLAGS=-L/home/hanwen/vc/gub/target/mingw/system/usr/lib
CC_FOR_BUILD= C_INCLUDE_PATH= CPPFLAGS= LIBRARY_PATH= LDFLAGS= cc
-I/home/hanwen/vc/gub/target/mingw/build/guile-1.7.91
-I/home/hanwen/vc/gub/target/mingw/src/guile-1.7.91
-I/home/hanwen/vc/gub/target/mingw/build/guile-1.7.91/libguile
-I. -I/home/hanwen/vc/gub/target/mingw/src/guile-1.7.91/libguile



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.7.91 has been released.

[Ludovic Courtès]

Hi,

Marius Vollmer <mvo@zagadka.de> writes:

> We are pleased to announce the release of Guile 1.7.91.  This is a
> release candidate for Guile 1.8.  It can be found here:
>
>     ftp://alpha.gnu.org/gnu/guile/guile-1.7.91.tar.gz

FYI, on `powerpc-unknown-linux-gnu', everything seems to work fine: all
standalone C tests pass, and all Scheme tests do as well.

  Totals for this test run:
  passes:                 11538
  failures:               0
  unexpected passes:      0
  expected failures:      25
  unresolved test cases:  9
  untested test cases:    0
  unsupported test cases: 9
  errors:                 0

  PASS: check-guile

BTW, I'd strongly recommend using SHA1 sums (e.g., via `sha1sum', part
of GNU Coreutils) rather than MD5.  See the example at
http://www.cits.rub.de/MD5Collisions/ if in doubt.  ;-)

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Marius Vollmer]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> BTW, I'd strongly recommend using SHA1 sums (e.g., via `sha1sum', part
> of GNU Coreutils) rather than MD5.

Yeah, that's probably best.

> See the example at http://www.cits.rub.de/MD5Collisions/ if in
> doubt.  ;-)

Well, they get to choose both texts that have a MD5 collision.
Looking at the PostScript source reveals that the texts have been
rigged, which should be enough if this goes to court.  In our case, an
attacker would need to find a second meaningful text that collides
with the text that we provide.  I guess that is much harder to do.

And the tarball is signed with a SHA1 hash anyway.  Maybe I should
include the signature in the announcement and not a checksum...

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Ludovic Courtès]

Hi,

Marius Vollmer <mvo@zagadka.de> writes:

> Well, they get to choose both texts that have a MD5 collision.
> Looking at the PostScript source reveals that the texts have been
> rigged, which should be enough if this goes to court.  In our case, an
> attacker would need to find a second meaningful text that collides
> with the text that we provide.  I guess that is much harder to do.

Well, since *you* are malicious, you could very well have prepared a
second tarball whose MD5 is the same and which you will propagate
during the days following the announcement.  ;-)

Seriously, this kind of attack is really about the level of trust one
can have in the *emitter* of the tarball and checksum.

> And the tarball is signed with a SHA1 hash anyway.  Maybe I should
> include the signature in the announcement and not a checksum...

Right.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Marius Vollmer]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

>> Well, they get to choose both texts that have a MD5 collision.
>> Looking at the PostScript source reveals that the texts have been
>> rigged, which should be enough if this goes to court.  In our case, an
>> attacker would need to find a second meaningful text that collides
>> with the text that we provide.  I guess that is much harder to do.
>
> Well, since *you* are malicious, you could very well have prepared a
> second tarball whose MD5 is the same and which you will propagate
> during the days following the announcement.  ;-)

Ahh, that never occured to me... I don't tend to think of _me_ as the
bad guy.. :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Bill Schottstaedt]

In solaris 10, I think the readdir_r usage is incorrect.

 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall -Wmissing-prototypes -MT filesys.lo -MD -
MP -MF .deps/filesy
s.Tpo -c filesys.c  -fPIC -DPIC -o .libs/filesys.o
filesys.c: In function `scm_readdir':
filesys.c:860: error: `NAME_MAX' undeclared (first use in this function)
filesys.c:860: error: (Each undeclared identifier is reported only once
filesys.c:860: error: for each function it appears in.)
filesys.c:863: error: too many arguments to function `readdir_r'

readdir_r is now:

     struct dirent *readdir_r(DIR *dirp, struct dirent *entry);

I changed filesys.c line 860 (or thereabouts) from:

    union {
      struct dirent ent;
      char pad1 [sizeof(struct dirent) + NAME_MAX];
      char pad2 [offsetof (struct dirent, d_name) + NAME_MAX + 1];
    } u;
    SCM_SYSCALL (readdir_r ((DIR *) SCM_CELL_WORD_1 (port), &u.ent, &rdent));

to:

    struct dirent ent;
    SCM_SYSCALL (readdir_r ((DIR *) SCM_CELL_WORD_1 (port), &ent));

and the rest went smoothly, although I had to remove -Werror from libguile/Makefile
because:

In file included from eval.c:5969:
eval.c: In function `deval':
eval.c:3248: warning: implicit declaration of function `alloca'
make[2]: *** [libguile_la-eval.lo] Error 1
make[2]: Leaving directory `/home/bil/test/guile-1.7.91/libguile'
make[1]: *** [all-recursive] Error 1



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Kevin Ryde]

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:
>
> filesys.c:860: error: `NAME_MAX' undeclared (first use in this function)
>
>     union {
>       struct dirent ent;
>       char pad1 [sizeof(struct dirent) + NAME_MAX];
>       char pad2 [offsetof (struct dirent, d_name) + NAME_MAX + 1];

This is recommended for portability by the glibc manual.

You've probably got NAME_MAX, is it hiding in some strange header?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Bill Schottstaedt]

I don't think NAME_MAX is defined anywhere -- the documentation says
you should use pathconf instead.  Here's the portion of limits.h where
they commented out NAME_MAX:

/*
 * POSIX 1003.1a, section 2.9.5, table 2-5 contains [NAME_MAX] and the
 * related text states:
 *
 * A definition of one of the values from Table 2-5 shall be omitted from the
 * <limits.h> on specific implementations where the corresponding value is
 * equal to or greater than the stated minimum, but where the value can vary
 * depending on the file to which it is applied. The actual value supported for
 * a specific pathname shall be provided by the pathconf() (5.7.1) function.
 *
 * This is clear that any machine supporting multiple file system types
 * and/or a network can not include this define, regardless of protection
 * by the _POSIX_SOURCE and _POSIX_C_SOURCE flags.
 *
 * #define      NAME_MAX        14
 */


I'd be happy to test anything, of course.  (The d_name field is still defined
to be 1 char long, so I think the glibc comment still pertains to Solaris,
but I'm really no expert about this system!).





_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Kevin Ryde]

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:
>
> (The d_name field is still defined to be 1 char long, so I think the
> glibc comment still pertains to Solaris,

I guess that means you can't just define a struct.  What does the
readdir_r man page say you should do?  pathconf like you said?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Bill Schottstaedt]

Yes, here's the relevent portion of man readdir_r:


The caller must allocate storage pointed to by entry  to  be
     large  enough  for  a dirent structure with an array of char
     d_name  member  containing  at  least  NAME_MAX  (that   is,
     pathconf(directory,   _PC_NAME_MAX))   plus   one  elements.
     (_PC_NAME_MAX is defined in  <unistd.h>.)


I found some examples by Googling for readdir_r and _PC_NAME_MAX.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Kevin Ryde]

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:
>
> I found some examples by Googling for readdir_r and _PC_NAME_MAX.

Incomplete bit of code below, it's not pretty but I guess it's what
has to be done.


#if HAVE_READDIR_R
    /* On Solaris 2.7, struct dirent only contains "char d_name[1]" and the
       application is expected to provide a buffer of "sizeof(struct dirent)
       + NAME_MAX" bytes.

       The glibc 2.3.2 manual notes this sort of thing too, and advises
       "offsetof(struct dirent,d_name) + NAME_MAX + 1".

       On Solaris 2.10, there's no NAME_MAX because it varies according to
       the filesystem, one is expected to use pathconf().

       So the code below tries a plain struct dirent, plus all three of the
       above possibly bigger sizes, to establish the buffer.  If we're not
       using pathconf then the size is a constant and we don't need to
       malloc/free, but let's assume for modern systems pathconf is usual so
       most of the time we'll be wanting a dynamic size.  */

    size_t  bufsize = sizeof (struct dirent);
    char    *buf;
    int     old_errno;
#ifdef NAME_MAX
    bufsize = SCM_MAX (bufsize, sizeof(struct dirent) + NAME_MAX);
    bufsize = SCM_MAX (bufsize, offsetof (struct dirent, d_name) + NAME_MAX + 1\);
#endif
#ifdef _PC_NAME_MAX
    {
      char *c_dirname = scm_to_locale_string (SCM_FILENAME (port));
      long name_max = pathconf (c_dirname, _PC_NAME_MAX);
      old_errno = errno;
      free (c_dirname);
      errno = old_errno;
      if (name_max == -1)
        SCM_SYSERROR;
      bufsize = SCM_MAX (bufsize, name_max);
    }
#endif
    buf = scm_malloc (bufsize);
    SCM_SYSCALL (readdir_r ((DIR *) SCM_CELL_WORD_1 (port),
                            (struct dirent *) buf,
                            &rdent));
    ...


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Kevin Ryde]

Oops, I see opendir doesn't record the opened directoryname.  Hmm.  It
might be easiest for now to just stick a mutex around plain readdir()
and worry later about readdir_r and its buffer size.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Bill Schottstaedt]

Andy Wingo says:
> I once did some painful CVS bisection, which for the compiler flags I was
> using brought it back to the introduction of the inline keyword in 2002
> or something.

Perhaps you're on to something -- the "inline" business reminded me of
the old pstate bug where a variable was being optimized off the stack
causing premature gc, or something like that.  So, I rebuilt guile using
-g3 and not -O2, and the build ran to completion!  Unfortunately, it's still
not right; guile doesn't segfault but I get:

/home/bil/test/ bin/guile
Backtrace:
In unknown file:
   ?: 130* [syntmp-gen-syntax-1074 #(syntax-object # #) #(syntax-object # #) ...]
   ?: 131  (if (syntmp-id?-115 syntmp-e-1110) (let* (#) (let* # #)) ...)
     ...
   ?: 132  [call-with-values #<procedure #f ()> #<procedure #f #>]
   ?: 133  (@call-with-values (producer consumer))
   ?: 134* [#<procedure #f ()>]
   ?: 135* [syntmp-gen-syntax-1074 #(syntax-object # #) #(syntax-object begin #) ...]
   ?: 136  (if (syntmp-id?-115 syntmp-e-1110) (let* (#) (let* # #)) ...)
     ...
   ?: 137  (if # # #)
   ?: 138* [syntmp-ellipsis?-160 #(syntax-object begin (# # # #))]
   ?: 139  (and # #)
     ...
   ?: 140  [syntmp-free-id=?-138 #(syntax-object begin #) #(syntax-object ... #)]
   ?: 141  (and (eq? # #) (eq? # #))
   ?: 142* [eq? ...
   ?: 143*  (let* ((syntmp-x-885 syntmp-i-883)) (let* (#) (if # # syntmp-e-886)))
   ?: 144   (let* (#) (if # # syntmp-e-886))
   ?: 145*  (if # # syntmp-x-885)
   ?: 146*  [syntmp-syntax-object?-101 #(syntax-object begin (# # # #))]
   ?: 147   (and (vector? syntmp-x-1008) (= (vector-length syntmp-x-1008) 3) ...)
   ?: 148*  [= ...
   ?: 149*   (vector-length syntmp-x-1008)

<unnamed port>: In expression (vector-length syntmp-x-1008):
<unnamed port>: Stack overflow



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Kevin Ryde]

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:
>
> So, I rebuilt guile using -g3
> ...
> <unnamed port>: Stack overflow

If that's gcc 4 then it might be the same thing afflicting i386 under
-O3, that ceval/deval end up using a lot of stack.  Try increasing the
stack limit, ie. the guile one, wherever the default for that hides in
the sources ...


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> If that's gcc 4 then it might be the same thing afflicting i386 under
> -O3, that ceval/deval end up using a lot of stack.  Try increasing the
> stack limit, ie. the guile one, wherever the default for that hides in
> the sources ...

Also, on PPC, I can hardly get Guile running when compiled with `-O0': I
get "stack overflow" errors early during the startup phase when I do so.
If that is what you tried, I'd suggest compiling with at least `-O1'.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released (x86-64 segfault)

[Bill Schottstaedt]

I may be chasing pure randomness, but I find that the only file that cannot
be compiled -O2 is read.c -- I can switch back and forth between the segfault
and the stack overflow just by changing the optimization switch on that
file (optimizing all the rest).  



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Ludovic Courtès]

Hi,

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:

> filesys.c:860: error: `NAME_MAX' undeclared (first use in this function)

GNU (aka. GNU/Hurd) may very well have the same problem. (arbitrary
limitations like this or `PATH_MAX' are not supported[0])  Can somebody
check this?

Thanks,
Ludovic.

[0] http://www.debian.org/ports/hurd/hurd-devel-debian


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Bill Schottstaedt]

In Linux FC4 dual x86-64, trying to build Guile 1.7.91 I get:

creating guile
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc 
debug.doc deprecation.doc deprecated.doc discouraged.doc dynl.doc dynwind.doc environments
.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc 
futures.doc gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.d
oc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc 
lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objpro
p.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc 
rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.
doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc srfi-14.doc 
strorder.doc strports.doc struct.doc symbols.doc threads.doc throw.doc values.doc va
riable.doc vectors.doc version.doc vports.doc weaks.doc ramap.doc unif.doc dynl.doc filesys.doc 
posix.doc net_db.doc socket.doc regex-posix.doc | GUILE="/home/bil/test/guile-1.7.91/
pre-inst-guile" ../scripts/snarf-check-and-output-texi --manual > guile.texi || { rm guile.texi; 
false; }
ERROR: In procedure memoization:
ERROR: Bad binding (e) in expression (letrec ((genmatch (lambda (x clauses match-expr) (let* 
((length>= #) #<freed cell 0x2aaaaaf3f2a0; GC missed a reference> (blist #) (plist #) (c
ode #)) (unreachable plist match-expr) (inline-let (quasiquote #))))) (genletrec (lambda (pat exp body 
match-expr) (let* ((length>= #) (eb-errf #) (x #) (p #) (bv #) (bindings #) (c
ode #) (plist #) (x #) (m #) ...) (unreachable plist match-expr) (quasiquote (letrec # #))))) (gendefine 
(lambda (pat exp match-expr) (let* ((length>= #) (eb-errf #) (x #) (p #) (bv
 #) (bindings #) (code #) (plist #) (x #) (m #) ...) (unreachable plist match-expr) (quasiquote (begin # 
#))))) (pattern-var? (lambda (x) (and (symbol? x) (not (dot-dot-k? x)) (not 
(memq x #))))) (dot-dot-k? (lambda (s) (and (symbol? s) (if (memq s #) 0 (let* # #))))) (error-maker 
(lambda (match-expr) (cond ((eq? match:error-control #) (cons # #)) ((memq match
:error-control #) (cons # #)) ((eq? match:error-control #) (let # #)) (else (match:syntax-err # "invalid 
value for match:error-control, legal values are"))))) (unreachable (lambda (
plist match-expr) (for-each (lambda (x) (if # #)) plist))) (validate-pattern (lambda (pattern) (letrec 
((simple? #) (ordinary #) (quasi #) (ordlist #)) (ordinary pattern)))) (e) (in
line-let (lambda (let-exp) (letrec ((occ #) (subst #) (const? #) (isval? #) (small? #)) (let loop (# # #) 
(cond # # #))))) ...) (list genmatch genletrec gendefine pattern-var?)).
make[2]: *** [guile.texi] Error 1

I did:

touch guile.texi
touch guile-procedures.texi

and went on, but then after installation when trying to run it:

/home/bil/cl/ ../test/bin/guile
ERROR: In procedure memoization:
ERROR: Bad define placement (define (warn module name int1 val1 int2 val2 var val) (format #t 
"WARNING: ~A: `~A' imported from both ~A and ~A
" (module-name module) name (module-name int1) (module-name int2)) #f).


Not immediately sure what to look for here.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Andy Wingo]

Hi,

On Mon, 2006-02-13 at 07:31 -0800, Bill Schottstaedt wrote:
> In Linux FC4 dual x86-64, trying to build Guile 1.7.91 I get:

This is
http://lists.gnu.org/archive/html/guile-devel/2005-12/msg00048.html. I
once did some painful CVS bisection, which for the compiler flags I was
using brought it back to the introduction of the inline keyword in 2002
or something.

I suspect something regarding GC and the stack, and a stack that grows
twice as fast as the normal one. But although I've spent a bit of time
trying to get this, I haven't figured it out yet.

Regards,
-- 
Andy Wingo
http://wingolog.org/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Neil Jerram]

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:

> ERROR: In procedure memoization:
> ERROR: Bad binding (e) in expression (letrec ((genmatch (lambda (x clauses match-expr) (let* 
> ((length>= #) #<freed cell 0x2aaaaaf3f2a0; GC missed a reference> (blist #) (plist #) (c

I wonder if this might be related to a change I made recently in the
area of letrec initializers.  Would you mind reproing this under GDB,
with a breakpoint on the 

      ASSERT_SYNTAX_2 (scm_ilength (binding) == 2,
                       s_bad_binding, binding, expr);

line in check_bindings() in eval.c, and let me know what callstack you
have at that point?

Thanks,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Bill Schottstaedt]

Here it is -- I noticed while poking around earlier that the thing it
doesn't like is <#winder...> -- it was apparently expecting to call
cadr on it or something like that -- been kinda busy at work, so I
haven't had time to look into it.  (I had to insert an abort after expanding
the ASSERT_SYNTAX_2 macro -- it wasn't clear how to get into gdb
in .libs/lt-guile from the makefile otherwise, and .libs/lt-guile by
itself hits a different error).  Let me know if I can help in any way.

(gdb) where
#0  0x00000034f552f3b0 in raise () from /lib64/libc.so.6
#1  0x00000034f5530860 in abort () from /lib64/libc.so.6
#2  0x00002aaaaaaf67ad in check_bindings (bindings=0x2aaaaae864e0, expr=0x2aaaaaf3f420) at 
eval.c:1553
#3  0x00002aaaaaaf6cee in scm_m_letrec (expr=0x2aaaaaf3f420, env=0x2aaaaae6dde0) at eval.c:
1732
#4  0x00002aaaaaafc061 in ceval (x=0x2aaaaae6dde0, env=0x2aaaaae6dde0) at eval.c:4052
#5  0x00002aaaaaaffdf4 in scm_m_define (expr=Variable "expr" is not available.
) at eval.c:1230
#6  0x00002aaaaaafc061 in ceval (x=0x2aaaaae4baa0, env=0x2aaaaae6dde0) at eval.c:4052
#7  0x00002aaaaab14aec in scm_primitive_load (filename=0x2aaaaae4baa0) at load.c:109
#8  0x00002aaaaaafcf27 in ceval (x=Variable "x" is not available.
) at eval.c:4225
#9  0x00002aaaaaaee5f2 in scm_dynamic_wind (in_guard=0x2aaaaae8d4c0, 
thunk=0x2aaaaae8d550, out_guard=0x2aaaaae8d490) at dynwind.c:107
#10 0x00002aaaaaafd30c in ceval (x=0x2aaaaae99ba0, env=0x2aaaaae8d4e0) at eval.c:4562
#11 0x00002aaaaaafd534 in ceval (x=0x2aaaaae4baa0, env=0x2aaaaae8d570) at eval.c:3390
#12 0x00002aaaaab01291 in scm_c_with_fluid (fluid=0x2aaaaae29be0, value=0x4, 
cproc=0x2aaaaab01200 <apply_thunk>, cdata=0x2aaaaae8d620)
    at fluids.c:453
#13 0x00002aaaaaafd30c in ceval (x=0x2aaaaaf661c0, env=0x2aaaaae8d640) at eval.c:4562
#14 0x00002aaaaaaee5f2 in scm_dynamic_wind (in_guard=0x2aaaaae8d8f0, 
thunk=0x2aaaaae8d8d0, out_guard=0x2aaaaae8d8b0) at dynwind.c:107
#15 0x00002aaaaaafd30c in ceval (x=0x2aaaaae87cd0, env=0x2aaaaae8d950) at eval.c:4562
#16 0x00002aaaaaafd534 in ceval (x=0x2aaaaae423c0, env=0x2aaaaae8d950) at eval.c:3390
#17 0x00002aaaaaafdb78 in ceval (x=0x2aaaaaf700c0, env=0x2aaaaae8fe20) at eval.c:3656
#18 0x00002aaaaaafd534 in ceval (x=0x2aaaaae52a00, env=0x2aaaaae8fe50) at eval.c:3390
#19 0x00002aaaaaafda99 in ceval (x=0x2aaaaae8eed0, env=0x2aaaaae91580) at eval.c:3641
#20 0x00002aaaaaafda99 in ceval (x=0x2aaaaae8c740, env=0x2aaaaae91810) at eval.c:3641
#21 0x00002aaaaaafd534 in ceval (x=0x2aaaaae28ae0, env=0x2aaaaaf6c5d0) at eval.c:3390
#22 0x00002aaaaaafda99 in ceval (x=0x2aaaaaf6fd40, env=0x2aaaaaf710a0) at eval.c:3641
#23 0x00002aaaaab14aec in scm_primitive_load (filename=0x2aaaaaef9140) at load.c:109
#24 0x00002aaaaaafcf27 in ceval (x=Variable "x" is not available.
) at eval.c:4225
#25 0x00002aaaaaaeb50b in scm_start_stack (id=0x2aaaaae3c9e0, exp=0x2aaaaadf7920, 
env=0x2aaaaaf71410) at debug.c:454
#26 0x00002aaaaaafc061 in ceval (x=0x4, env=0x2aaaaaf71410) at eval.c:4052
#27 0x00002aaaaab01291 in scm_c_with_fluid (fluid=0x2aaaaae29be0, value=0x4, 
cproc=0x2aaaaab01200 <apply_thunk>, cdata=0x2aaaaaf71480)
    at fluids.c:453
#28 0x00002aaaaaafd30c in ceval (x=0x2aaaaadf78e0, env=0x2aaaaaf71500) at eval.c:4562
#29 0x00002aaaaaaee5f2 in scm_dynamic_wind (in_guard=0x2aaaaaf71760, 
thunk=0x2aaaaaf718f0, out_guard=0x2aaaaaf71720) at dynwind.c:107
#30 0x00002aaaaaafd30c in ceval (x=0x2aaaaae99ba0, env=0x2aaaaaf717d0) at eval.c:4562
#31 0x00002aaaaaafdff3 in ceval (x=0x2aaaaaf71a00, env=0x2aaaaaf719a0) at eval.c:3361
#32 0x00002aaaaaaff2ca in scm_eval_x (exp=0x2aaaaaf71a00, module_or_state=0x2aaaaaef96e0) 
at eval.c:5938
#33 0x00002aaaaab2f5a2 in scm_shell (argc=6, argv=0x7fffff871258) at script.c:737
#34 0x00002aaaaab1237f in invoke_main_func (body_data=0x7fffff871130) at init.c:367
#35 0x00002aaaaaaea3aa in c_body (d=0x7fffff8710d0) at continuations.c:362
#36 0x00002aaaaab4da1a in scm_c_catch (tag=0x104, body=0x2aaaaaaea3a0 <c_body>, 
body_data=0x7fffff8710d0, handler=0x2aaaaaaea3c0 <c_handler>, 
    handler_data=0x7fffff8710d0, pre_unwind_handler=0x2aaaaab4e060 
<scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at throw.c:204
#37 0x00002aaaaaaea361 in scm_i_with_continuation_barrier (body=0x2aaaaaaea3a0 <c_body>, 
body_data=0x7fffff8710d0, 
    handler=0x2aaaaaaea3c0 <c_handler>, handler_data=0x7fffff8710d0, 
pre_unwind_handler=0x2aaaaab4e060 <scm_handle_by_message_noexit>, 
    pre_unwind_handler_data=0x0) at continuations.c:338
#38 0x00002aaaaaaea400 in scm_c_with_continuation_barrier (func=Variable "func" is not available.
) at continuations.c:380
#39 0x00002aaaaab4be03 in scm_i_with_guile_and_parent (func=0x2aaaaab12360 
<invoke_main_func>, data=0x7fffff871130, parent=Variable "parent" is n
ot available.
) at threads.c:645
#40 0x00002aaaaab12345 in scm_boot_guile (argc=Variable "argc" is not available.
) at init.c:350
#41 0x0000000000400ba0 in main (argc=6, argv=0x7fffff871258) at guile.c:74




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Bill Schottstaedt]

I was trying to build the new guile on a MacIntel box, got this error in gmp:

 tmp-dive_1.s:98:invalid character '@' in first operand 
 make[2]: *** [dive_1.lo] Error 1 

I sent a bug report to the gmp bug list and got this reply:

--------

Date: 13 Feb 2006 17:26:45 +0100   
From: Torbjorn Granlund <tege@swox.com>         
To: "Bill Schottstaedt" <bil@ccrma.Stanford.EDU>
CC: gmp-bugs@swox.com
Subject: Re: gmp 4.1.4 on x86 Mac       All headers
 
"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes: 

 During make in MacIntel (OS X 10.4.4, i686-apple-darwin8-gcc-4.0.1), 
 I get this error: 
  
[snip] 

 tmp-dive_1.s:98:invalid character '@' in first operand 
 make[2]: *** [dive_1.lo] Error 1 
  
MacIntel is not a platform we support in GMP 4.1. 

(For most new platforms, things would just work.  But Darwin, 
both for POWER and x86, uses its private assembly syntax and 
object file relocations.) 

--------

which I guess means the new Guile won't work on either kind of Mac?



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Han-Wen Nienhuys]

In article <87y80gyxrq.fsf@zagadka.de>, Marius Vollmer  <mvo@zagadka.de> wrote:
>We are pleased to announce the release of Guile 1.7.91.  This is a
>release candidate for Guile 1.8.  It can be found here:
>
>    ftp://alpha.gnu.org/gnu/guile/guile-1.7.91.tar.gz
>
>Its MD5 checksum is
>
>    b2106c1b574e22ec67c4c2178074b5ec  guile-1.7.91.tar.gz

Hi Marius,

what is your plan for maintaining the branches?  I've just put Ludovic's
scm_t_sweep_statistics patch in HEAD, can I also put it 1.8? 






_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.7.91 has been released.

[Marius Vollmer]

hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) writes:

> what is your plan for maintaining the branches?

The release-1-6 branch remains stable of course, and the release-1-8
branch will be stable after 1.8.0 has been released, and is now in
feature freeze.  "Stable" should mean "we try very hard to not
regress and to remain binary compatible".

> I've just put Ludovic's scm_t_sweep_statistics patch in HEAD, can I
> also put it 1.8?

No. :-) I will look at it more closely, tho.  Maybe it makes sense to
put it into 1.8.1.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.7.91 has been released.

[Ludovic Courtès]

Marius Vollmer <mvo@zagadka.de> writes:

> We are pleased to announce the release of Guile 1.7.91.  This is a
> release candidate for Guile 1.8.  It can be found here:

BTW, maybe you should also announce it on `info-gnu@gnu.org' (which is
relayed as the `gnu.announce' newsgroup).

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel