Guile 1.5.8 beta available for testing.

Guile 1.5.8 beta available for testing.

[Rob Browning]

We are pleased to annouce the availability of Guile 1.5.8 for testing.
Please report problems to guile-devel@gnu.org or bug-guile@gnu.org.

Note that the 1.5.X series is a BETA series, intended only for
testing, so please don't put it into a distribution or anything
similar.

This release is only a minor update from 1.5.7 -- guile-snarf has
been changed to not require the input file to be the first argument
after the optional -o.  Apparently this was breaking too many other
programs.  Since this update was so minor, Marius and I agreed that
the release date should remain unchanged.  So unless any release
critical bugs bugs are found beforehand, the first 1.6 stable
version, 1.6.1, will be released on or after this weekend.

You can find the beta release here:

  ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/

If you're interested in testing, please try as much of the following
as is convenient:

        - Unset GUILE_LOAD_PATH.

        - Remove automake and autoconf from your path, or turn off
          their execute bits, or something.  (Users must be able to
          build from the tarfile without installing those tools.)  As
          an example, you could disable the tools during the test like
          so:

            mkdir /tmp/stub
            cat > /tmp/stub/do-nothing <<EOF
            #!/bin/sh
            echo warning: $0 called
            sleep 10
            exit 0
            EOF
            chmod +x /tmp/stub/do-nothing
            ln /tmp/stub/do-nothing /tmp/stub/automake
            ln /tmp/stub/do-nothing /tmp/stub/autoconf	# etc
            PATH=/tmp/stub:$PATH

        - Configure, "make", "make check", and "make install".  Make
          sure to remove your previous install tree before the "make
          install".

        - Make sure LD_LIBRARY_PATH doesn't include anything
          unnecessary -- though at the moment it (or
          LTDL_LIBRARY_PATH) will need to include guile's lib
          directory if that directory is not already in the normal
          places libltdl looks.

        - Run the test suite on the installed version.
            ./check-guile -i [INSTALL_PATH]/bin/guile

        - Look at the install tree (with "find | sort" or similar) and
          make sure nothing seems obviously amiss.

        - Make sure readline works.

        - You might try the example code in the doc directory.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Guile 1.5.8 beta available for testing.

[Lars J. Aas]

Rob Browning <rlb@defaultvalue.org> wrote:
: We are pleased to annouce the availability of Guile 1.5.8 for testing.
: Please report problems to guile-devel@gnu.org or bug-guile@gnu.org.
: 
: Note that the 1.5.X series is a BETA series, intended only for
: testing, so please don't put it into a distribution or anything
: similar.
: 
: This release is only a minor update from 1.5.7 -- guile-snarf has
: been changed to not require the input file to be the first argument
: after the optional -o.  Apparently this was breaking too many other
: programs.  Since this update was so minor, Marius and I agreed that
: the release date should remain unchanged.  So unless any release
: critical bugs bugs are found beforehand, the first 1.6 stable
: version, 1.6.1, will be released on or after this weekend.

I'd appreciate it if the SCM_POSFIXABLE() bug, steming from the
fallback SCM_LONG_BIT define in __scm.h, was fixed before 1.6
was released.

  Lars J


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

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

"Lars J. Aas" <larsa@sim.no> writes:

> I'd appreciate it if the SCM_POSFIXABLE() bug, steming from the
> fallback SCM_LONG_BIT define in __scm.h, was fixed before 1.6 was
> released.

I'm not yet satisfied with the analysis.  As far as I can see, the
problem lies not with SCM_LONG_BIT being unsigned incorrectly, but
with SCM_MOST_POSITIVE_FIXNUM being unsigned incorrectly.

We compute SCM_MOST_POSITIVE_FIXNUM like this

  ((((scm_t_signed_bits) 1) << (SCM_I_FIXNUM_BIT - 1)) - 1)

where SCM_I_FIXNUM_BIT is unsigned when SCM_LONG_BIT is.  However, the
type of the result of a bit-shift operator is that of the promoted
left operand (6.5.7;3 in the ANSI C standard).  So
SCM_MOST_POSITIVE_FIXNUM is signed since scm_t_signed_bits is.

Your compiler seems to get this wrong, right?

A fix would be to move the scm_t_signed_bits cast one level up, and
also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
deriding comment about MS on the code.  OK?

Is that the only issue holding off a plain build of 1.5.8 with the
Microsoft compiler?  If there are others, we shouldn't bother to work
around this particular bug in the release.

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


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

Re: Guile 1.5.8 beta available for testing.

[Lars J. Aas]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
: "Lars J. Aas" <larsa@sim.no> writes:
: > I'd appreciate it if the SCM_POSFIXABLE() bug, steming from the
: > fallback SCM_LONG_BIT define in __scm.h, was fixed before 1.6 was
: > released.
: 
: I'm not yet satisfied with the analysis.  As far as I can see, the
: problem lies not with SCM_LONG_BIT being unsigned incorrectly, but
: with SCM_MOST_POSITIVE_FIXNUM being unsigned incorrectly.
: 
: We compute SCM_MOST_POSITIVE_FIXNUM like this
: 
:   ((((scm_t_signed_bits) 1) << (SCM_I_FIXNUM_BIT - 1)) - 1)
: 
: where SCM_I_FIXNUM_BIT is unsigned when SCM_LONG_BIT is.  However, the
: type of the result of a bit-shift operator is that of the promoted
: left operand (6.5.7;3 in the ANSI C standard).  So
: SCM_MOST_POSITIVE_FIXNUM is signed since scm_t_signed_bits is.
: 
: Your compiler seems to get this wrong, right?
: 
: A fix would be to move the scm_t_signed_bits cast one level up, and
: also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
: deriding comment about MS on the code.  OK?

Sounds reasonable.

This works:

#define SCM_MOST_POSITIVE_FIXNUM \
  (((scm_t_signed_bits) (1 << (SCM_I_FIXNUM_BIT - 1))) - 1)

compiler version info for comment:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86

: Is that the only issue holding off a plain build of 1.5.8 with the
: Microsoft compiler?

Nope.  The msvc compiler needs to follow the __MINGW32__ path most of
the time, so I had to update most of those #if conditionals.  There
are some issues with opendir()/readdir()/closedir(), so I had to disable
those bindings.  I also disabled all the compiled srfis (4, 13&14?).

: If there are others, we shouldn't bother to work
: around this particular bug in the release.

OK.

  Lars J


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

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

"Lars J. Aas" <larsa@sim.no> writes:

> : A fix would be to move the scm_t_signed_bits cast one level up, and
> : also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
> : deriding comment about MS on the code.  OK?
> 
> Sounds reasonable.

However, in CVS HEAD, we use these definitions, to make them
computable by the preprocessor:

#define SCM_I_FIXNUM_BIT         (SCM_LONG_BIT - 2)
#define SCM_MOST_POSITIVE_FIXNUM ((SCM_T_SIGNED_BITS_MAX-3)/4)
#define SCM_MOST_NEGATIVE_FIXNUM (-SCM_MOST_POSITIVE_FIXNUM-1)

Does this work as well?

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


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

Re: Guile 1.5.8 beta available for testing.

[Lars J. Aas]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
: "Lars J. Aas" <larsa@sim.no> writes:
: 
: > : A fix would be to move the scm_t_signed_bits cast one level up, and
: > : also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
: > : deriding comment about MS on the code.  OK?
: > 
: > Sounds reasonable.
: 
: However, in CVS HEAD, we use these definitions, to make them
: computable by the preprocessor:
: 
: #define SCM_I_FIXNUM_BIT         (SCM_LONG_BIT - 2)
: #define SCM_MOST_POSITIVE_FIXNUM ((SCM_T_SIGNED_BITS_MAX-3)/4)
: #define SCM_MOST_NEGATIVE_FIXNUM (-SCM_MOST_POSITIVE_FIXNUM-1)
: 
: Does this work as well?

Yes, the following snippet works out of the box with no tweaks
necessary for the defines.

  Lars J

----------------------------------------------------------------------------

#include <stdio.h>
#include <limits.h>

typedef signed long scm_t_signed_bits;

#ifdef LONG_BIT
# define SCM_LONG_BIT LONG_BIT
#else
# define SCM_LONG_BIT (SCM_CHAR_BIT * sizeof (long) / sizeof (char))
#endif

#define SCM_T_SIGNED_BITS_MAX LONG_MAX

#define SCM_I_FIXNUM_BIT         (SCM_LONG_BIT - 2)
#define SCM_MOST_POSITIVE_FIXNUM ((SCM_T_SIGNED_BITS_MAX-3)/4)
#define SCM_MOST_NEGATIVE_FIXNUM (-SCM_MOST_POSITIVE_FIXNUM-1)

#define SCM_POSFIXABLE(n) ((n) <= SCM_MOST_POSITIVE_FIXNUM)

int
main(int argc, char ** argv)
{
  int val;
  fprintf(stderr, "test 1 - ");
  if ( SCM_POSFIXABLE(-1) ) fprintf(stderr, "success\n");
  else                      fprintf(stderr, "failure\n");
  fprintf(stderr, "test 2 - ");
  val = -1;
  if ( SCM_POSFIXABLE(val) ) fprintf(stderr, "success\n");
  else                       fprintf(stderr, "failure\n");
  return 0;
}



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