GNU Guile 1.9.2 released (alpha)

GNU Guile 1.9.2 released (alpha)

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 7153 bytes --]

We are pleased to announce GNU Guile release 1.9.2.  This is the next
pre-release of what will eventually become the 2.0 release series.  It
provides many new noteworthy features, most notably the addition of a
compiler and virtual machine.  We encourage you to test them and provide
feedback to `guile-devel@gnu.org'.

The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a link to the Guile FAQ and pointers to
the mailing lists.

Guile is an implementation of the Scheme programming language, with
support for many SRFIs, packaged for use in a wide variety of
environments.  In addition to implementing the R5RS Scheme standard,
Guile includes a module system, full access to POSIX system calls,
networking support, multiple threads, dynamic linking, a foreign
function call interface, and powerful string processing.

Guile can run interactively, as a script interpreter, and as a Scheme
compiler to VM bytecode.  It is also packaged as a library so that
applications can easily incorporate a complete Scheme interpreter/VM.
An application can use Guile as an extension language, a clean and
powerful configuration language, or as multi-purpose "glue" to connect
primitives provided by the application.  It is easy to call Scheme code
From C code and vice versa.  Applications can add new functions, data
types, control structures, and even syntax to Guile, to create a
domain-specific language tailored to the task at hand.


Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/guile/guile-1.9.2.tar.gz   (4.6MB)

Here are the GPG detached signatures[*]:
  ftp://alpha.gnu.org/gnu/guile/guile-1.9.2.tar.gz.sig

Here are the MD5 and SHA1 checksums:

b89cfdef4c6e851923a18ef03933f672  guile-1.9.2.tar.gz
5bf59d9d17841d8d87e1744c9d35b276b5c67133  guile-1.9.2.tar.gz

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify guile-1.9.2.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.64
  Automake 1.11
  Libtool 2.2.6


This is a new release series with many new features and differences
compared to 1.8.  The complete list of changes compared to the 1.8.x
series is available in the `NEWS' file.

Changes since the 1.9.1 pre-release:

  ** VM speed improvements

  Closures now copy the free variables that they need into a flat vector
  instead of capturing all heap-allocated variables. This speeds up access
  to free variables, avoids unnecessary garbage retention, and allows all
  variables to be allocated on the stack.

  Variables which are `set!' are now allocated on the stack, but in
  "boxes". This allows a more uniform local variable allocation
  discipline, and allows faster access to these variables.

  The VM has new special-case operations, `add1' and `sub1'.

  ** VM robustness improvements

  The maximum number of live local variables has been increased from 256
  to 65535.

  The default VM stack size is 64 kilo-words, up from 16 kilo-words. This
  allows more programs to execute in the default stack space. In the
  future we will probably implement extensible stacks via overflow
  handlers.

  Some lingering cases in which the VM could perform unaligned accesses
  have been fixed.

  The address range for relative jumps has been expanded from 16-bit
  addresses to 19-bit addresses via 8-byte alignment of jump targets. This
  will probably change to a 24-bit byte-addressable strategy before Guile
  2.0.

  ** Compiler optimizations

  Procedures bound by `letrec' are no longer allocated on the heap,
  subject to a few constraints. In many cases, procedures bound by
  `letrec' and `let' can be rendered inline to their parent function, with
  loop detection for mutually tail-recursive procedures.

  Unreferenced variables are now optimized away.

  ** Compiler robustness

  Guile may now warn about unused lexically-bound variables. Pass
  `-Wunused-variable' to `guile-tools compile', or `#:warnings
  (unused-variable)' within the #:opts argument to the `compile' procedure
  from `(system base compile)'.

  ** Incomplete support for Unicode characters and strings

  Preliminary support for Unicode has landed. Characters may be entered in
  octal format via e.g. `#\454', or created via (integer->char 300). A hex
  external representation will probably be introduced at some point.

  Internally, strings are now represented either in the `latin-1'
  encoding, one byte per character, or in UTF-32, with four bytes per
  character. Strings manage their own allocation, switching if needed.

  Currently no locale conversion is performed. Extended characters may be
  written in a string using the hexadecimal escapes `\xXX', `\uXXXX', or
  `\UXXXXXX', for 8-bit, 16-bit, or 24-bit codepoints, respectively.

  This support is obviously incomplete. Many C functions have not yet been
  updated to deal with the new representations. Users are advised to wait
  for the next release for more serious use of Unicode strings.

  ** `defined?' may accept a module as its second argument

  Previously it only accepted internal structures from the evaluator.

  ** `let-values' is now implemented with a hygienic macro

  This could have implications discussed below in the NEWS entry titled,
  "Lexical bindings introduced by hygienic macros may not be referenced by
  nonhygienic macros".

  ** Global variables `scm_charnames' and `scm_charnums' are removed

  These variables contained the names of control characters and were
  used when writing characters.  While these were global, they were
  never intended to be public API.  They have been replaced with private
  functions.

  ** EBCDIC support is removed

  There was an EBCDIC compile flag that altered some of the character
  processing.  It appeared that full EBCDIC support was never completed
  and was unmaintained.

  ** Packaging changes

  Guile now provides `guile-2.0.pc' (used by pkg-config) instead of
  `guile-1.8.pc'.

  ** And of course, the usual collection of bugfixes

  Interested users should see the ChangeLog for more information.


You can follow Guile development in the Git repository and on the Guile
mailing lists.  Guile builds from the `master' branch of Git have
version number 1.9.x.

Guile versions with an odd middle number, e.g., 1.9.*, are unstable
development versions.  Even middle numbers indicate stable versions.
This has been the case since the 1.3.* series.

Please report bugs to `bug-guile@gnu.org'.  We also welcome reports of
successful builds, which can be sent to the same email address.


Ludovic Courtès, on behalf of the Guile team.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Building Guile 1.9.2 on i686-pc-linux-gnu

[Mike Gran]

On Sat, 2009-08-15 at 15:06 +0200, Ludovic Courtès wrote:
> We are pleased to announce GNU Guile release 1.9.2.  

Sweet.

Result from a machine. i686-pc-linux-gnu running Redhat 10 and gcc
4.3.2.  As was to be expected, it all turned out OK.


Scheme compilation had two sets of warnings

----------------------------
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
"srfi/srfi-35.go" "srfi/srfi-35.scm"
wrote `srfi/srfi-35.go'

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
----------------------------

and

----------------------------
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
"language/ecmascript/parse.go" "language/ecmascript/parse.scm"
%% Reduce/Reduce conflict (reduce 9, reduce 6) on lparen in state 395
...
----------------------------

Make check completes with "some deprecated features have been used"
after socket.test

Make install completes okay.  Note the double-slashes in the "touch"
lines during installation.  For example.

----------------------------
 touch -r 'ice-9/emacs.scm'
'/usr/local/share/guile/1.9//ice-9/emacs.scm'
 touch -r 'ice-9/expect.scm'
'/usr/local/share/guile/1.9//ice-9/expect.scm'
--------------------------

Also, Guile-1.9.2 causes no regressions in the test suite for my library
gucu-0.3, which is to be expected because gucu is simple.  It was a bit
of a shock to see all the information about turning autocompilation off
repeated once for each of the ~50 scheme scripts that make up its test
suite, though.

-Mike

Re: Building Guile 1.9.2 on i686-pc-linux-gnu

[Neil Jerram]

Mike Gran <spk121@yahoo.com> writes:

> Scheme compilation had two sets of warnings
>
> ----------------------------
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
> "srfi/srfi-35.go" "srfi/srfi-35.scm"
> wrote `srfi/srfi-35.go'
>
> Some deprecated features have been used.  Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.  Set it to "no" to suppress
> this message.
> ----------------------------

These and other deprecation warnings are fixed by
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=f564f4784f856d0b38008327bc877905e36fc56a

> It was a bit
> of a shock to see all the information about turning autocompilation off
> repeated once for each of the ~50 scheme scripts that make up its test
> suite, though.

Yes.  It would be better if the information was only issued once per
Guile run.  Andy, any objection if I work on that?

        Neil

Re: Building Guile 1.9.2 on i686-pc-linux-gnu

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

>> It was a bit
>> of a shock to see all the information about turning autocompilation off
>> repeated once for each of the ~50 scheme scripts that make up its test
>> suite, though.
>
> Yes.  It would be better if the information was only issued once per
> Guile run.  Andy, any objection if I work on that?

Actually I think I misunderstood what you meant, Mike.  It looks like
the autocompilation warning is already issued only once per Guile run.

        Neil

Re: GNU Guile 1.9.2 released (alpha)

[Linas Vepstas]

2009/8/15 Ludovic Courtès <ludo@gnu.org>:

>  ** Incomplete support for Unicode characters and strings
>
>  Internally, strings are now represented either in the `latin-1'
>  encoding, one byte per character, or in UTF-32, with four bytes per
>  character.

Will this eventually move to UTF8? European languages typically
use only a small handful of non-latin symbols, typically just misc
punctuation.  I recent dump of voice-of-america  radio broadcasts
I ran through guile used misc UTF8 punctuation ... backwards-facing
double-quotes, ellipsis, etc.  I'd hate to see this common case
blow up to 32-bits per char just to accommodate stray punctuation.

--linas

Re: GNU Guile 1.9.2 released (alpha)

[Mike Gran]

> From: Linas Vepstas <linasvepstas@gmail.com>
> 
> 2009/8/15 Ludovic Courtès :
> 
> >  ** Incomplete support for Unicode characters and strings
> >
> >  Internally, strings are now represented either in the `latin-1'
> >  encoding, one byte per character, or in UTF-32, with four bytes per
> >  character.
> 
> Will this eventually move to UTF8? European languages typically
> use only a small handful of non-latin symbols, typically just misc
> punctuation.  I recent dump of voice-of-america  radio broadcasts
> I ran through guile used misc UTF8 punctuation ... backwards-facing
> double-quotes, ellipsis, etc.  I'd hate to see this common case
> blow up to 32-bits per char just to accommodate stray punctuation.
> 

We've gone back and forth on this.  I think, for the near term, in
terms of my personal involvement with Guile, the answer is 'no'.  

The problem lies in in the R6Rs requirement that functions like 
string-ref run in 'constant time'.  To implement that with UTF-8
requires that internally a string be both character storage and
an indexing scheme to point to the start of the characters in 
that storage.

If it weren't for the 'constant time' requirement, UTF-8 would
have been the winner hands down.

It is likely true that a UTF-8 character store and indexing scheme 
could be created that would be less memory-intensive that UTF-32
alone and still allow for constant time accesses.  But, in my 
uniformed opinion (since I haven't tried to implement such a 
thing myself), I don't think the memory savings would be 
so much less than UTF-32 to justify the complexity.

However, in terms of 2.0, the Unicode patches that I'll be asking
Ludo, Andy, and Neil to review will leave Guile in better 
position to swap out internal string representations, so 
a future switch to UTF8 wouldn't be as painful as this switch has
been so far.

> --linas

-Mike