We are pleased to announce GNU Guile release 2.1.1. This is the first pre-release of what will eventually become the 2.2 release series. It provides many improvements, most notably in speed: it starts up faster than Guile 2.0, runs your programs faster, and uses less memory; see below for full details. We encourage you to test this release 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 copy of the Guile manual and pointers to more resources. Special thanks to Luis Felipe López Acevedo for the new site design, also released today; we hope you enjoy it. 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. Guile 2.1.1 can be installed in parallel with Guile 2.0.x; see http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html. A more detailed NEWS summary follows these details on how to get the Guile sources. Note that compiling Guile takes about an hour if you compile with -j4 or so, as the compilation has to bootstrap itself from a small interpreter written in C. It's worth it, though! Here are the compressed sources: http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.gz (7.4MB) http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.xz (4.6MB) Here are the GPG detached signatures[*]: http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.gz.sig http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.xz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html Here are the MD5 and SHA1 checksums: 784d512ab62e885af1708242f06cda18 guile-2.1.1.tar.gz ded0680f4c2caf49315efda80fb9e292 guile-2.1.1.tar.xz bcb2ea6ab606b52ac469d79ec17c6a2652cdd66f guile-2.1.1.tar.gz 6781aa27db3d16eb8972842d24dbfd69f3256f77 guile-2.1.1.tar.xz [*] Use a .sig file 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-2.1.1.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 8812F8F2 and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.15 Libtool 2.4.6 Gnulib v0.1-92-g546ff82 Makeinfo 6.0 Changes in 2.1.1 (changes since the 2.0.x series): * Notable changes ** Speed The biggest change in Guile 2.2 is a complete rewrite of its virtual machine and compiler internals. The result is faster startup time, better memory usage, and faster execution of user code. See the "Performance improvements" section below for more details. ** Better thread-safety This new release series takes the ABI-break opportunity to fix some interfaces that were difficult to use correctly from multiple threads. Notably, weak hash tables are now transparently thread-safe. Ports are also thread-safe; see "New interfaces" below for details on the changes to the C interface. ** Better space-safety It used to be the case that, when calling a Scheme procedure, the procedure and arguments were always preserved against garbage collection. This is no longer the case; Guile is free to collect the procedure and arguments if they become unreachable, or to re-use their slots for other local variables. Guile still offers good-quality backtraces by determining the procedure being called from the instruction pointer instead of from the value in slot 0 of an application frame, and by using a live variable map that allows the debugger to know which locals are live at all points in a frame. ** Off-main-thread finalization Following Guile 2.0.6's change to invoke finalizers via asyncs, Guile 2.2 takes the additional step of invoking finalizers from a dedicated finalizer thread, if threads are enabled. This avoids concurrency issues between finalizers and application code, and also speeds up finalization. If your application's finalizers are not robust to the presence of threads, see "Foreign Objects" in the manual for information on how to disable automatic finalization and instead run finalizers manually. ** Better locale support in Guile scripts When Guile is invoked directly, either from the command line or via a hash-bang line (e.g. "#!/usr/bin/guile"), it now installs the current locale via a call to `(setlocale LC_ALL "")'. For users with a unicode locale, this makes all ports unicode-capable by default, without the need to call `setlocale' in your program. This behavior may be controlled via the GUILE_INSTALL_LOCALE environment variable; see the manual for more. ** Complete Emacs-compatible Elisp implementation Thanks to the work of BT Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love. ** Dynamically expandable stacks Instead of allocating fixed stack sizes for running Scheme code, Guile now starts off each thread with only one page of stack, and expands and shrinks it dynamically as needed. Guile will throw an exception for stack overflows if growing the stack fails. It is also possible to impose a stack limit during the extent of a function call. See "Stack Overflow" in the manual, for more. This change allows users to write programs that use the stack as a data structure for pending computations, as it was meant to be, without reifying that data out to the heap. Where you would previously make a loop that collect its results in reverse order only to re-reverse them at the end, now you can just recurse without worrying about stack overflows. Using the stack also allows more code to be continuation-safe. For example, returning multiple times from a `map' procedure in Guile 2.0 would change the value of previously returned result lists, because `map' built its result list in reverse order then used `reverse!' to return the proper result. Now in Guile 2.2, `map' is implemented using straightforward recursion, which eliminates this bug while maintaining good performance as well as good space complexity. ** Out-of-memory improvements Instead of aborting, failures to allocate memory will now raise an unwind-only `out-of-memory' exception, and cause the corresponding `catch' expression to run garbage collection in order to free up memory. ** GOOPS core reimplemented in Scheme Guile's object orientation system, GOOPS, has been mostly reimplemented in Scheme. This decreases its maintenance burden on the rest of Guile, while also makes it possible to implement new features in the future, such as method combinations or `eqv?' specializers. * Performance improvements ** Faster programs via new virtual machine Guile now compiles programs to instructions for a new virtual machine. The new virtual machine's instructions can address their source and destination operands by "name" (slot). This makes access to named temporary values much faster than in Guile 2.0, and removes a lot of value-shuffling that the old virtual machine had to do. The end result is that loop-heavy code can be two or three times as fast with Guile 2.2 as in 2.0. Your mileage may vary, of course; see "A Virtual Machine for Guile" in the manual for the nitties and the gritties. ** Better startup time, memory usage with ELF object file format Guile now uses the standard ELF format for its compiled code. (Guile has its own loader and linker, so this does not imply a dependency on any particular platform's ELF toolchain.) The benefit is that Guile is now able to statically allocate more data in the object files. ELF also enables more sharing of data between processes, and decreases startup time (about 40% faster than the already fast startup of the Guile 2.0 series). Guile also uses DWARF for some of its debugging information. Much of the debugging information can be stripped from the object files as well. See "Object File Format" in the manual, for full details. ** Better optimizations via compiler rewrite Guile's compiler now uses a Continuation-Passing Style (CPS) intermediate language, allowing it to reason easily about temporary values and control flow. Examples of optimizations that this permits are optimal contification, optimal common subexpression elimination, dead code elimination, loop-invariant code motion, loop peeling, loop inversion, parallel moves with at most one temporary, allocation of stack slots using precise liveness information, and closure optimization. For more, see "Continuation-Passing Style" in the manual. ** Faster interpreter Combined with a number of optimizations to the interpreter itself, simply compiling `eval.scm' with the new compiler yields an interpreter that is consistently two or three times faster than the one in Guile 2.0. ** Allocation-free dynamic stack Guile now implements the dynamic stack with an actual stack instead of a list of heap objects, avoiding most allocation. This speeds up prompts, the `scm_dynwind_*' family of functions, fluids, and `dynamic-wind'. ** Optimized UTF-8 and Latin-1 ports, symbols, and strings Guile 2.2 is faster at reading and writing UTF-8 and Latin-1 strings From ports, and at converting symbols and strings to and from these encodings. ** Optimized hash functions Guile 2.2 now uses Bob Jenkins' `hashword2' (from his `lookup3.c') for its string hash, and Thomas Wang's integer hash function for `hashq' and `hashv'. These functions produce much better hash values across all available fixnum bits. ** Optimized generic array facility Thanks to work by Daniel Llorens, the generic array facility is much faster now, as it is internally better able to dispatch on the type of the underlying backing store. * New interfaces ** New `cond-expand' feature: `guile-2.2' Use this feature if you need to check for Guile 2.2 from Scheme code. ** New predicate: `nil?' See "Nil" in the manual. ** New compiler modules Since the compiler was rewritten, there are new modules for the back-end of the compiler and the low-level loader and introspection interfaces. See the "Guile Implementation" chapter in the manual for all details. ** New functions: `scm_to_intptr_t', `scm_from_intptr_t' ** New functions: `scm_to_uintptr_t', `scm_from_uintptr_t' See "Integers" in the manual, for more. ** New thread-safe port API For details on `scm_c_make_port', `scm_c_make_port_with_encoding', `scm_c_lock_port', `scm_c_try_lock_port', `scm_c_unlock_port', `scm_c_port_type_ref', `scm_c_port_type_add_x', `SCM_PORT_DESCRIPTOR', and `scm_dynwind_lock_port', see XXX. There is now a routine to atomically adjust port "revealed counts". See XXX for more on `scm_adjust_port_revealed_x' and `adjust-port-revealed!', All other port API now takes the lock on the port if needed. There are some C interfaces if you know that you don't need to take a lock; see XXX for details on `scm_get_byte_or_eof_unlocked', `scm_peek_byte_or_eof_unlocked' `scm_c_read_unlocked', `scm_getc_unlocked' `scm_unget_byte_unlocked', `scm_ungetc_unlocked', `scm_ungets_unlocked', `scm_fill_input_unlocked' `scm_putc_unlocked', `scm_puts_unlocked', and `scm_lfwrite_unlocked'. ** New inline functions: `scm_new_smob', `scm_new_double_smob' These can replace many uses of SCM_NEWSMOB, SCM_RETURN_NEWSMOB2, and the like. See XXX in the manual, for more. ** New low-level type accessors For more on `SCM_HAS_TYP7', `SCM_HAS_TYP7S', `SCM_HAS_TYP16', see XXX. `SCM_HEAP_OBJECT_P' is now an alias for the inscrutable `SCM_NIMP'. `SCM_UNPACK_POINTER' and `SCM_PACK_POINTER' are better-named versions of the old `SCM2PTR' and `PTR2SCM'. Also, `SCM_UNPACK_POINTER' yields a void*. ** <standard-vtable>, standard-vtable-fields See "Structures" in the manual for more on these ** Convenience utilities for ports and strings. See XXX for more on `scm_from_port_string', `scm_from_port_stringn', `scm_to_port_string', and `scm_to_port_stringn'. ** New expressive PEG parser See "PEG Parsing" in the manual for more. Thanks to Michael Lucy for originally writing these, and to Noah Lavine for integration work. ** `make-stack' now also works on delimited continuations ** Better URI-reference support The `(web uri)' module now has interfaces for handling URI references, which might not have a scheme. The Location header of a web request or response is now a URI reference instead of a URI. Also, `request-absolute-uri' now has an optional default scheme argument. See "Web" in the manual for full details. ** formal-name->char, char->formal-name See "Characters", in the manual. * Incompatible changes ** ASCII is not ISO-8859-1 In Guile 2.0, if a user set "ASCII" or "ANSI_X3.4-1968" as the encoding of a port, Guile would treat it as ISO-8859-1. While these encodings are the same for codepoints 0 to 127, ASCII does not extend past that range, whereas ISO-8859-1 goes up to 255. Guile 2.2 no longer treats ASCII as ISO-8859-1. This is likely to be a problem only if the user's locale is set to ASCII, and the user or a program writes non-ASCII codepoints to a port. ** String ports default to UTF-8 Guile 2.0 would use the `%default-port-encoding' when creating string ports. This resulted in ports that could only accept a subset of valid characters, which was surprising to users. Now string ports default to the UTF-8 encoding. Sneaky users can still play encoding conversion games with string ports by explicitly setting the encoding of a port after it is open. See "Ports" in the manual for more. ** `scm_from_stringn' and `scm_to_stringn' encoding arguments are never NULL These functions now require a valid `encoding' argument, and will abort if given `NULL'. ** All r6rs ports are both textual and binary Because R6RS ports are a thin layer on top of Guile's ports, and Guile's ports are both textual and binary, Guile's R6RS ports are also both textual and binary, and thus both kinds have port transcoders. This is an incompatibility with respect to R6RS. ** Vtable hierarchy changes In an attempt to make Guile's structure and record types integrate better with GOOPS by unifying the vtable hierarchy, `make-vtable-vtable' is now deprecated. Instead, users should just use `make-vtable' with appropriate arguments. See "Structures" in the manual for all of the details. As such, `record-type-vtable' and `%condition-type-vtable' now have a parent vtable and are no longer roots of the vtable hierarchy. ** Syntax parameters are a distinct type Guile 2.0's transitional implementation of `syntax-parameterize' was based on the `fluid-let-syntax' interface inherited from the psyntax expander. This interface allowed any binding to be dynamically rebound -- even bindings like `lambda'. This is no longer the case in Guile 2.2. Syntax parameters must be defined via `define-syntax-parameter', and only such bindings may be parameterized. See "Syntax Parameters" in the manual for more. ** Defined identifiers scoped in the current module Sometimes Guile's expander would attach incorrect module scoping information for top-level bindings made by an expansion. For example, given the following R6RS library: (library (defconst) (export defconst) (import (guile)) (define-syntax-rule (defconst name val) (begin (define t val) (define-syntax-rule (name) t)))) Attempting to use it would produce an error: (import (defconst)) (defconst foo 42) (foo) =| Unbound variable: t It wasn't clear that we could fix this in Guile 2.0 without breaking someone's delicate macros, so the fix is only coming out now. ** Pseudo-hygienically rename macro-introduced bindings Bindings introduced by macros, like `t' in the `defconst' example above, are now given pseudo-fresh names. This allows (defconst foo 42) (defconst bar 37) to introduce different bindings for `t'. These pseudo-fresh names are made in such a way that if the macro is expanded again, for example as part of a simple recompilation, the introduced identifiers get the same pseudo-fresh names. See "Hygiene and the Top-Level" in the manual, for details. ** Fix literal matching for module-bound literals `syntax-rules' and `syntax-case' macros can take a set of "literals": bound or unbound keywords that the syntax matcher treats specially. Before, literals were always matched symbolically (by name). Now they are matched by binding. This allows literals to be reliably bound to values, renamed by imports or exports, et cetera. See "Syntax-rules Macros" in the manual for more on literals. ** `dynamic-wind' doesn't check that guards are thunks Checking that the dynamic-wind out-guard procedure was actually a thunk before doing the wind was slow, unreliable, and not strictly needed. ** All deprecated code removed All code deprecated in Guile 2.0 has been removed. See older NEWS, and check that your programs can compile without linker warnings and run without runtime warnings. See "Deprecation" in the manual. ** Remove miscellaneous unused interfaces We have removed accidentally public, undocumented interfaces that we think are not used, and not useful. This includes `scm_markstream', `SCM_FLUSH_REGISTER_WINDOWS', `SCM_THREAD_SWITCHING_CODE', `SCM_FENCE', `scm_call_generic_0', `scm_call_generic_1', `scm_call_generic_2' `scm_call_generic_3', `scm_apply_generic', and `scm_program_source'. `scm_async_click' was renamed to `scm_async_tick', and `SCM_ASYNC_TICK' was made private (use `SCM_TICK' instead). ** Many internal compiler / VM changes As the compiler and virtual machine were re-written, there are many changes in the back-end of Guile to interfaces that were introduced in Guile 2.0. These changes are only only of interest if you wrote a language on Guile 2.0 or a tool using Guile 2.0 internals. If this is the case, drop by the IRC channel to discuss the changes. ** Defining a SMOB or port type no longer mucks exports of `(oop goops)' It used to be that defining a SMOB or port type added an export to GOOPS, for the wrapper class of the smob type. This violated modularity, though, so we have removed this behavior. ** Bytecode replaces objcode as a target language One way in which people may have used details of Guile's runtime in Guile 2.0 is in compiling code to thunks for later invocation. Instead of compiling to objcode and then calling `make-program', now the way to do it is to compile to `bytecode' and then call `load-thunk-from-memory' From `(system vm loader)'. ** Weak pairs removed Weak pairs were not safe to access with `car' and `cdr', and so were removed. ** Weak alist vectors removed Use weak hash tables instead. ** Weak vectors may no longer be accessed via `vector-ref' et al Weak vectors may no longer be accessed with the vector interface. This was a source of bugs in the 2.0 Guile implementation, and a limitation on using vectors as building blocks for other abstractions. Vectors in Guile are now a concrete type; for an abstract interface, use the generic array facility (`array-ref' et al). ** scm_t_array_implementation removed This interface was introduced in 2.0 but never documented. It was a failed attempt to layer the array implementation that actually introduced too many layers, as it prevented the "vref" and "vset" members of scm_t_array_handle (called "ref" and "set" in 1.8, not present in 2.0) from specializing on array backing stores. Notably, the definition of scm_t_array_handle has now changed, to not include the (undocumented) "impl" member. We are sorry for any inconvenience this may cause. ** `scm_make' is now equivalent to Scheme `make' It used to be that `scm_make' only implemented a hard-wired object allocation and initialization protocol. This was because `scm_make' was used while GOOPS booted its own, more complete `make' implementation in Scheme. Now that we've re-implemented everything in Scheme, the C `scm_make' now dispatches directly to Scheme `make', which implements the full protocol. This change is incompatible in some ways, but on the whole is good news for GOOPS users. ** GOOPS slot definitions are now objects Slot definitions are now instances of a <slot> class, instead of being specially formatted lists. To most user code, this is transparent, as the slot definition accessors like `slot-definition-name' continue to work. However, code that for example uses `car' to get the name of a slot definition will need to be updated to use the accessors. ** Class slot changes Class objects no longer have a `default-slot-definition-class' slot, which was never used. They also no longer have slots for hashsets (`h0', `h1', and so on up to `h7'), which have been unused since Guile 2.0 and were not a great idea. There is a new class option, `#:static-slot-allocation?'. See the manual for details. ** Removal of internal, unintentionally exposed GOOPS C interfaces These include: `scm_sys_fast_slot_ref', `scm_sys_fast_slot_set_x' `scm_basic_basic_make_class', `scm_sys_compute_slots', `scm_sys_prep_layout_x' `scm_t_method', `SCM_METHOD', `scm_s_slot_set_x', `SCM_CLASS_CLASS_LAYOUT', `scm_si_slotdef_class', `scm_si_generic_function', `scm_si_specializers', `scm_si_procedure', `scm_si_formals', `scm_si_body', `scm_si_make_procedure', `SCM_CLASS_CLASS_LAYOUT', `SCM_INSTANCE_HASH', `SCM_SET_HASHSET', `union scm_t_debug_info', `scm_pure_generic_p', `SCM_PUREGENERICP', `SCM_VALIDATE_PUREGENERIC', `SCM_VTABLE_FLAG_GOOPS_PURE_GENERIC', `SCM_CLASSF_PURE_GENERIC', `scm_c_extend_primitive_generic', `scm_sys_initialize_object', `SCM_CLASS_CLASS_LAYOUT', `scm_si_redefined', `scm_si_direct_supers', `scm_si_direct_slots', `scm_si_direct_subclasses', `scm_si_direct_methods', `scm_si_cpl' `scm_si_slots', `scm_si_getters_n_setters', `SCM_N_CLASS_SLOTS', `SCM_OBJ_CLASS_REDEF', `SCM_INST', `SCM_ACCESSORS_OF', `scm_sys_allocate_instance', and `scm_sys_invalidate_class_x'. * New deprecations ** SCM_WTA_DISPATCH_0, SCM_WTA_DISPATCH_1, SCM_WTA_DISPATCH_2, SCM_WTA_DISPATCH_N ** SCM_GASSERT0, SCM_GASSERT1, SCM_GASSERT2, SCM_GASSERTn ** SCM_WTA_DISPATCH_1_SUBR These macros were used in dispatching primitive generics. They can be replaced by using C functions (the same name but in lower case), if needed, but this is a hairy part of Guile that perhaps you shouldn't be using. ** scm_compute_applicable_methods and scm_find_method Use `compute-applicable-methods' from Scheme instead. ** scm_no_applicable_method Fetch no-applicable-method from the GOOPS exports if you need it. ** scm_class_boolean, scm_class_char, scm_class_pair ** scm_class_procedure, scm_class_string, scm_class_symbol ** scm_class_primitive_generic, scm_class_vector, scm_class_null ** scm_class_real, scm_class_complex, scm_class_integer ** scm_class_fraction, scm_class_unknown, scm_class_top ** scm_class_object, scm_class_class, scm_class_applicable ** scm_class_applicable_struct, scm_class_applicable_struct_with_setter ** scm_class_generic, scm_class_generic_with_setter, scm_class_accessor ** scm_class_extended_generic, scm_class_extended_generic_with_setter ** scm_class_extended_accessor, scm_class_method ** scm_class_accessor_method, scm_class_procedure_class ** scm_class_applicable_struct_class, scm_class_number, scm_class_list ** scm_class_keyword, scm_class_port, scm_class_input_output_port ** scm_class_input_port, scm_class_output_port, scm_class_foreign_slot ** scm_class_self, scm_class_protected, scm_class_hidden ** scm_class_opaque, scm_class_read_only, scm_class_protected_hidden ** scm_class_protected_opaque, scm_class_protected_read_only ** scm_class_scm, scm_class_int, scm_class_float, scm_class_double ** scm_port_class, scm_smob_class These class exports are now deprecated. Instead, look up the ones you need from the GOOPS module, or use `scm_class_of' on particular values. ** scm_get_keyword Instead from Scheme use kw-arg-ref or real keyword arguments, and from C use `scm_c_bind_keyword_arguments'. ** scm_slot_ref_using_class, scm_slot_set_using_class_x ** scm_slot_bound_using_class_p, scm_slot_exists_using_class_p Instead use the normal `scm_slot_ref' and similar procedures. * Changes to the distribution ** New minor version The "effective version" of Guile is now 2.2, which allows parallel installation with other effective versions (for example, the older Guile 2.0). See "Parallel Installations" in the manual for full details. Notably, the `pkg-config' file is now `guile-2.2'. ** Bump required libgc version to 7.2, released March 2012. ** The readline extension is now installed in the extensionsdir The shared library that implements Guile's readline extension is no longer installed to the libdir. This change should be transparent to users, but packagers may be interested.
signature.asc
Description: PGP signature
