[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Guilecommits] GNU Guile branch, master, updated. release_1915108g4
From: 
Andy Wingo 
Subject: 
[Guilecommits] GNU Guile branch, master, updated. release_1915108g487bacf 
Date: 
Mon, 14 Feb 2011 21:58:26 +0000 
This is an automated email from the git hooks/postreceive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Guile".
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=487bacf4ff983178adb4c963cbc5d1fe4705e741
The branch, master has been updated
via 487bacf4ff983178adb4c963cbc5d1fe4705e741 (commit)
from 7a5cfd22b55de475eb592dd85391e69dc8980906 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
 Log 
commit 487bacf4ff983178adb4c963cbc5d1fe4705e741
Author: Andy Wingo <address@hidden>
Date: Mon Feb 14 23:03:11 2011 +0100
fold new NEWS items into main text
* NEWS: Fold all items into main text, while keeping a list of things
that are new in 1.9.15.

Summary of changes:
NEWS  536 +++++++++++++++++++++++++++++++
1 files changed, 250 insertions(+), 286 deletions()
diff git a/NEWS b/NEWS
index 6bebbf6..e202a19 100644
 a/NEWS
+++ b/NEWS
@@ 74,281 +74,6 @@ which yields 5.0+0.0i. Previously it did the equivalent of:
which yielded 5.0.
Changes in 1.9.15 (since the 1.9.14 prerelease):

** Formally deprecate omission of port to `format'

It used to be that you could omit passing a port to `format', in some
cases. This still works, but has been formally deprecated.

** ECMAScript fixes

Noah Lavine and KanRu Chen noticed and fixed a number of embarrassing
bugs in object creation, unicode literals in strings, empty function
bodies, nonbreaking whitespace, and numeric literals.

** `(web ...)' changes

*** `parseuri', `unparseuri' now called `string>uri', `uri>string'

*** `uridecode' takes `#:encoding' keyword argument, not `#:charset'

*** HTTP header representation change

Guile properly garbagecollects symbols, so there's no need to read some
headers as symbols and some as strings: all header names are symbols
now. The same goes for many keyvalue constructs in headers. Guile
parses the challenge/authentication headers now, as well. Header decl
objects are no longer exposed to the user.

*** Request and response bodies are always bytevectors

Reading bodies as latin1 strings was a cute hack, but not general, so
Guile's only official fetchmethebody procedures return bytevectors
now.

** New procedures: scm_{to,from}_{utf8,latin1}_symbol{n,}
** New procedures: scm_{to,from}_{utf8,utf32,latin1}_symbol{n,}

These new procedures convert to and from string representations in
particular encodings.

Basically, continue to use locale encoding for user input, user output,
or interacting with the C library. Use latin1 for ASCII, and for
literals in source code. Use utf8 for interaction with modern libraries
which deal in UTF8. Use utf32 for interaction with utf32using
libraries. Otherwise use scm_to_stringn or scm_from_stringn with a
specific encoding.

Also, scm_from_latin1_symbol is quite a bit faster now.

** Documentation updates

The GOOPS manual saw a lot of work, as well as documentation for the
`(web ...)' modules.

** Guile uses iconv directly for reading from and writing to ports.

In addition to providing faster Unicode I/O (e.g., `display',
`readchar'), this change improves error reporting.

For instance, the `encodingerror' exception conveys information about
the port and character that could not be encoded. Likewise, the new
`decodingerror' exception conveys information about the port from which
data failed to be decoded, and leaves the port in a known position.

** Source files default to UTF8.

If source files do not specify their encoding via a `coding:' block,
the default encoding is UTF8, instead of being taken from the current
locale.

** Man page updates

Thanks to Mark Harig for many suggestions regarding the manual page,
which is getting better.

** Interactive Guile installs the current locale.

Instead of leaving the user in the "C" locale, running the Guile REPL
installs the current locale. [FIXME xref?]

** `recv!', `recvfrom!', `send', `sendto' now deal in bytevectors

These socket procedures now take bytevectors as arguments, instead of
strings. There is some deprecated string support, however.

** New foreign API: `definewrappedpointertype', `pointer?'

See "Foreign Types", for more.

** Changes and bugfixes in numerics code

*** Added two new sets of fast quotient and remainder operators

Added two new sets of fast quotient and remainder operator pairs with
different semantics than the R5RS operators. They support not only
integers, but all reals, including exact rationals and inexact
floating point numbers.

These procedures accept two real numbers N and D, where the divisor D
must be nonzero. `euclideanquotient' returns the integer Q and
`euclideanremainder' returns the real R such that N = Q*D + R and
0 <= R < D. `euclidean/' returns both Q and R, and is more
efficient than computing each separately. Note that when D > 0,
`euclideanquotient' returns floor(N/D), and when D < 0 it returns
ceiling(N/D).

`centeredquotient', `centeredremainder', and `centered/' are similar
except that the range of remainders is abs(D/2) <= R < abs(D/2), and
`centeredquotient' rounds N/D to the nearest integer.

Note that these operators are equivalent to the R6RS integer division
operators `div', `mod', `divandmod', `div0', `mod0', and
`div0andmod0'.

*** Complex number changes

Guile is now able to represent nonreal complex numbers whose
imaginary part is an _inexact_ zero (0.0 or 0.0), per R6RS.
Previously, such numbers were immediately changed into inexact reals.

(real? 0.0+0.0i) now returns #f, per R6RS, although (zero? 0.0+0.0i)
still returns #t, per R6RS. (= 0 0.0+0.0i) and (= 0.0 0.0+0.0i) are
#t, but the same comparisons using `eqv?' or `equal?' are #f.

Like other nonreal numbers, these complex numbers with inexact zero
imaginary part will raise exceptions is passed to procedures requiring
reals, such as `<', `>', `<=', `>=', `min', `max', `positive?',
`negative?', `inf?', `nan?', `finite?', etc.

**** `makerectangular' changes

scm_make_rectangular `makerectangular' now returns a real number only
if the imaginary part is an _exact_ 0. Previously, it would return a
real number if the imaginary part was an inexact zero.

scm_c_make_rectangular now always returns a nonreal complex number,
even if the imaginary part is zero. Previously, it would return a
real number if the imaginary part was zero.

**** `makepolar' changes

scm_make_polar `makepolar' now returns a real number only if the
angle or magnitude is an _exact_ 0. If the magnitude is an exact 0,
it now returns an exact 0. Previously, it would return a real
number if the imaginary part was an inexact zero.

scm_c_make_polar now always returns a nonreal complex number, even if
the imaginary part is 0.0. Previously, it would return a real number
if the imaginary part was 0.0.

**** `imagpart' changes

scm_imag_part `imagpart' now returns an exact 0 if applied to an
inexact real number. Previously it returned an inexact zero in this
case.

*** `eqv?' and `equal?' now compare numbers equivalently

scm_equal_p `equal?' now behaves equivalently to scm_eqv_p `eqv?' for
numeric values, per R5RS. Previously, equal? worked differently,
e.g. `(equal? 0.0 0.0)' returned #t but `(eqv? 0.0 0.0)' returned #f,
and `(equal? +nan.0 +nan.0)' returned #f but `(eqv? +nan.0 +nan.0)'
returned #t.

*** `(equal? +nan.0 +nan.0)' now returns #t

Previously, `(equal? +nan.0 +nan.0)' returned #f, although
`(let ((x +nan.0)) (equal? x x))' and `(eqv? +nan.0 +nan.0)'
both returned #t. R5RS requires that `equal?' behave like
`eqv?' when comparing numbers.

*** Change in handling products `*' involving exact 0

scm_product `*' now handles exact 0 differently. A product containing
an exact 0 now returns an exact 0 if and only if the other arguments
are all exact. An inexact zero is returned if and only if the other
arguments are all finite but not all exact. If an infinite or NaN
value is present, a NaN value is returned. Previously, any product
containing an exact 0 yielded an exact 0, regardless of the other
arguments.

*** `expt' and `integerexpt' changes when the base is 0

While `(expt 0 0)' is still 1, and `(expt 0 N)' for N > 0 is still
zero, `(expt 0 N)' for N < 0 is now a NaN value, and likewise for
integerexpt. This is more correct, and conforming to R6RS, but seems
to be incompatible with R5RS, which would return 0 for all nonzero
values of N.

*** `expt' and `integerexpt' are more generic, less strict

When raising to an exact nonnegative integer exponent, `expt' and
`integerexpt' are now able to exponentiate any object that can be
multiplied using `*'. They can also raise an object to an exact
negative integer power if its reciprocal can be taken using `/'.
In order to allow this, the type of the first argument is no longer
checked when raising to an exact integer power. If the exponent is 0
or 1, the first parameter is not manipulated at all, and need not
even support multiplication.

*** Infinities are no longer integers, nor rationals

scm_integer_p `integer?' and scm_rational_p `rational?' now return #f
for infinities, per R6RS. Previously they returned #t for real
infinities. The real infinities and NaNs are still considered real by
scm_real `real?' however, per R6RS.

*** NaNs are no longer rationals

scm_rational_p `rational?' now returns #f for NaN values, per R6RS.
Previously it returned #t for real NaN values. They are still
considered real by scm_real `real?' however, per R6RS.

*** `inf?' and `nan?' now throw exceptions for nonreals

The domain of `inf?' and `nan?' is the real numbers. Guile now signals
an error when a nonreal number or nonnumber is passed to these
procedures. (Note that NaNs _are_ considered numbers by scheme, despite
their name).

*** `rationalize' bugfixes and changes

Fixed bugs in scm_rationalize `rationalize'. Previously, it returned
exact integers unmodified, although that was incorrect if the epsilon
was at least 1 or inexact, e.g. (rationalize 4 1) should return 3 per
R5RS and R6RS, but previously it returned 4. It also now handles
cases involving infinities and NaNs properly, per R6RS.

*** Trigonometric functions now return exact numbers in some cases

scm_sin `sin', scm_cos `cos', scm_tan `tan', scm_asin `asin', scm_acos
`acos', scm_atan `atan', scm_sinh `sinh', scm_cosh `cosh', scm_tanh
`tanh', scm_sys_asinh `asinh', scm_sys_acosh `acosh', and
scm_sys_atanh `atanh' now return exact results in some cases.

*** New procedure: `finite?'

Add scm_finite_p `finite?' from R6RS to guile core, which returns #t
if and only if its argument is neither infinite nor a NaN. Note that
this is not the same as (not (inf? x)) or (not (infinite? x)), since
NaNs are neither finite nor infinite.

*** R6RS base library changes

**** `div', `mod', `divandmod', `div0', `mod0', `div0andmod0'

Efficient versions of these R6RS division operators are now supported.
See the NEWS entry entitled `Added two new sets of fast quotient and
remainder operators' for more information.

**** `infinite?' changes

`infinite?' and `finite?' now throw exceptions for nonnumbers. (Note
that NaNs _are_ considered numbers by scheme, despite their name).

**** `realvalued?', `rationalvalued?' and `integervalued?' changes

These predicates are now implemented in accordance with R6RS.

** R6RS textual I/O procedures raise R6RS error conditions

R6RS procedures `getchar', `putstring', etc. now raise the correct
R6RS error coding, i.e., `&i/odecodingerror' or `&i/oencodingerror'.

** New reader option: `hungryeolescapes'

Guile's string syntax is more compatible with R6RS when the
`hungryeolescapes' option is enabled. See "String Syntax" in the
manual, for more information.

** And of course, the usual collection of bugfixes

Interested users should see the ChangeLog for more information.



Changes in 1.9.x (since the 1.8.x series):
* New modules (see the manual for details)
@@ 447,7 +172,8 @@ The guile binary now supports a new switch "x", which can
be used to
extend the list of filename extensions tried when loading files
(%loadextensions).
** New reader options: `squarebrackets' and `r6rshexescapes'
+** New reader options: `squarebrackets', `r6rshexescapes',
+ `hungryeolescapes'
The reader supports a new option (changeable via `readoptions'),
`squarebrackets', which instructs it to interpret square brackets as
@@ 458,6 +184,11 @@ will recognize string escape sequences as defined in R6RS.
R6RS string
escape sequences are incompatible with Guile's existing escapes, though,
so this option is off by default.
+Additionally, Guile follows the R6RS newline escaping rules when the
+`hungryeolescapes' option is enabled.
+
+See "String Syntax" in the manual, for more information.
+
** Function profiling and tracing at the REPL
The `,profile FORM' REPL metacommand can now be used to statistically
@@ 635,6 +366,11 @@ Support was added for the IP_MULTICAST_TTL and
IP_MULTICAST_IF socket
options. See "Network Sockets and Communication" in the manual, for
more information.
+** `recv!', `recvfrom!', `send', `sendto' now deal in bytevectors
+
+These socket procedures now take bytevectors as arguments, instead of
+strings. There is some deprecated string support, however.
+
** New GNU procedures: `setaffinity' and `getaffinity'.
See "Processes" in the manual, for more information.
@@ 1239,6 +975,11 @@ compatibility purposes. No semantic change has been made
(we hope).
Optional and keyword arguments now dispatch via special VM operations,
without the need to cons rest arguments, making them very fast.
+** New syntax: defineonce
+
+`defineonce' is like Lisp's `defvar': it creates a toplevel binding,
+but only if one does not exist already.
+
** New function, `truncatedprint', with `format' support
`(ice9 prettyprint)' now exports `truncatedprint', a printer that
@@ 1260,6 +1001,9 @@ macros like `quote' are printed better.
The `format' procedure in `(ice9 format)' now emits a deprecation
warning if a number is passed as its first argument.
+Also, it used to be that you could omit passing a port to `format', in
+some cases. This still works, but has been formally deprecated.
+
** SRFI4 vectors reimplemented in terms of R6RS bytevectors
Guile now implements SRFI4 vectors using bytevectors. Often when you
@@ 1314,6 +1058,198 @@ implementation.
`*unspecified*' is no longer a variable, so it is optimized properly by
the compiler, and is not `set!'able.
+** Changes and bugfixes in numerics code
+
+*** Added six new sets of fast quotient and remainder operators
+
+Added six new sets of fast quotient and remainder operator pairs with
+different semantics than the R5RS operators. They support not only
+integers, but all reals, including exact rationals and inexact
+floating point numbers.
+
+These procedures accept two real numbers N and D, where the divisor D
+must be nonzero. Each set of operators computes an integer quotient
+Q and a real remainder R such that N = Q*D + R and R < D. They
+differ only in how N/D is rounded to produce Q.
+
+`euclideanquotient' returns the integer Q and `euclideanremainder'
+returns the real R such that N = Q*D + R and 0 <= R < D. `euclidean/'
+returns both Q and R, and is more efficient than computing each
+separately. Note that when D > 0, `euclideanquotient' returns
+floor(N/D), and when D < 0 it returns ceiling(N/D).
+
+`centeredquotient', `centeredremainder', and `centered/' are similar
+except that the range of remainders is abs(D/2) <= R < abs(D/2), and
+`centeredquotient' rounds N/D to the nearest integer. Note that these
+operators are equivalent to the R6RS integer division operators `div',
+`mod', `divandmod', `div0', `mod0', and `div0andmod0'.
+
+`floorquotient' and `floorremainder' compute Q and R, respectively,
+where Q has been rounded toward negative infinity. `floor/' returns
+both Q and R, and is more efficient than computing each separately.
+Note that when applied to integers, `floorremainder' is equivalent to
+the R5RS integeronly `modulo' operator. `ceilingquotient',
+`ceilingremainder', and `ceiling/' are similar except that Q is
+rounded toward positive infinity.
+
+For `truncatequotient', `truncateremainder', and `truncate/', Q is
+rounded toward zero. Note that when applied to integers,
+`truncatequotient' and `truncateremainder' are equivalent to the
+R5RS integeronly operators `quotient' and `remainder'.
+
+For `roundquotient', `roundremainder', and `round/', Q is rounded to
+the nearest integer, with ties going to the nearest even integer.
+
+*** Complex number changes
+
+Guile is now able to represent nonreal complex numbers whose
+imaginary part is an _inexact_ zero (0.0 or 0.0), per R6RS.
+Previously, such numbers were immediately changed into inexact reals.
+
+(real? 0.0+0.0i) now returns #f, per R6RS, although (zero? 0.0+0.0i)
+still returns #t, per R6RS. (= 0 0.0+0.0i) and (= 0.0 0.0+0.0i) are
+#t, but the same comparisons using `eqv?' or `equal?' are #f.
+
+Like other nonreal numbers, these complex numbers with inexact zero
+imaginary part will raise exceptions is passed to procedures requiring
+reals, such as `<', `>', `<=', `>=', `min', `max', `positive?',
+`negative?', `inf?', `nan?', `finite?', etc.
+
+**** `makerectangular' changes
+
+scm_make_rectangular `makerectangular' now returns a real number only
+if the imaginary part is an _exact_ 0. Previously, it would return a
+real number if the imaginary part was an inexact zero.
+
+scm_c_make_rectangular now always returns a nonreal complex number,
+even if the imaginary part is zero. Previously, it would return a
+real number if the imaginary part was zero.
+
+**** `makepolar' changes
+
+scm_make_polar `makepolar' now returns a real number only if the
+angle or magnitude is an _exact_ 0. If the magnitude is an exact 0,
+it now returns an exact 0. Previously, it would return a real
+number if the imaginary part was an inexact zero.
+
+scm_c_make_polar now always returns a nonreal complex number, even if
+the imaginary part is 0.0. Previously, it would return a real number
+if the imaginary part was 0.0.
+
+**** `imagpart' changes
+
+scm_imag_part `imagpart' now returns an exact 0 if applied to an
+inexact real number. Previously it returned an inexact zero in this
+case.
+
+*** `eqv?' and `equal?' now compare numbers equivalently
+
+scm_equal_p `equal?' now behaves equivalently to scm_eqv_p `eqv?' for
+numeric values, per R5RS. Previously, equal? worked differently,
+e.g. `(equal? 0.0 0.0)' returned #t but `(eqv? 0.0 0.0)' returned #f,
+and `(equal? +nan.0 +nan.0)' returned #f but `(eqv? +nan.0 +nan.0)'
+returned #t.
+
+*** `(equal? +nan.0 +nan.0)' now returns #t
+
+Previously, `(equal? +nan.0 +nan.0)' returned #f, although
+`(let ((x +nan.0)) (equal? x x))' and `(eqv? +nan.0 +nan.0)'
+both returned #t. R5RS requires that `equal?' behave like
+`eqv?' when comparing numbers.
+
+*** Change in handling products `*' involving exact 0
+
+scm_product `*' now handles exact 0 differently. A product containing
+an exact 0 now returns an exact 0 if and only if the other arguments
+are all exact. An inexact zero is returned if and only if the other
+arguments are all finite but not all exact. If an infinite or NaN
+value is present, a NaN value is returned. Previously, any product
+containing an exact 0 yielded an exact 0, regardless of the other
+arguments.
+
+*** `expt' and `integerexpt' changes when the base is 0
+
+While `(expt 0 0)' is still 1, and `(expt 0 N)' for N > 0 is still
+zero, `(expt 0 N)' for N < 0 is now a NaN value, and likewise for
+integerexpt. This is more correct, and conforming to R6RS, but seems
+to be incompatible with R5RS, which would return 0 for all nonzero
+values of N.
+
+*** `expt' and `integerexpt' are more generic, less strict
+
+When raising to an exact nonnegative integer exponent, `expt' and
+`integerexpt' are now able to exponentiate any object that can be
+multiplied using `*'. They can also raise an object to an exact
+negative integer power if its reciprocal can be taken using `/'.
+In order to allow this, the type of the first argument is no longer
+checked when raising to an exact integer power. If the exponent is 0
+or 1, the first parameter is not manipulated at all, and need not
+even support multiplication.
+
+*** Infinities are no longer integers, nor rationals
+
+scm_integer_p `integer?' and scm_rational_p `rational?' now return #f
+for infinities, per R6RS. Previously they returned #t for real
+infinities. The real infinities and NaNs are still considered real by
+scm_real `real?' however, per R6RS.
+
+*** NaNs are no longer rationals
+
+scm_rational_p `rational?' now returns #f for NaN values, per R6RS.
+Previously it returned #t for real NaN values. They are still
+considered real by scm_real `real?' however, per R6RS.
+
+*** `inf?' and `nan?' now throw exceptions for nonreals
+
+The domain of `inf?' and `nan?' is the real numbers. Guile now signals
+an error when a nonreal number or nonnumber is passed to these
+procedures. (Note that NaNs _are_ considered numbers by scheme, despite
+their name).
+
+*** `rationalize' bugfixes and changes
+
+Fixed bugs in scm_rationalize `rationalize'. Previously, it returned
+exact integers unmodified, although that was incorrect if the epsilon
+was at least 1 or inexact, e.g. (rationalize 4 1) should return 3 per
+R5RS and R6RS, but previously it returned 4. It also now handles
+cases involving infinities and NaNs properly, per R6RS.
+
+*** Trigonometric functions now return exact numbers in some cases
+
+scm_sin `sin', scm_cos `cos', scm_tan `tan', scm_asin `asin', scm_acos
+`acos', scm_atan `atan', scm_sinh `sinh', scm_cosh `cosh', scm_tanh
+`tanh', scm_sys_asinh `asinh', scm_sys_acosh `acosh', and
+scm_sys_atanh `atanh' now return exact results in some cases.
+
+*** New procedure: `finite?'
+
+Add scm_finite_p `finite?' from R6RS to guile core, which returns #t
+if and only if its argument is neither infinite nor a NaN. Note that
+this is not the same as (not (inf? x)) or (not (infinite? x)), since
+NaNs are neither finite nor infinite.
+
+*** Improved exactness handling for complex number parsing
+
+When parsing nonreal complex numbers, exactness specifiers are now
+applied to each component, as is done in PLT Scheme. For complex
+numbers written in rectangular form, exactness specifiers are applied
+to the real and imaginary parts before calling scm_make_rectangular.
+For complex numbers written in polar form, exactness specifiers are
+applied to the magnitude and angle before calling scm_make_polar.
+
+Previously, exactness specifiers were applied to the number as a whole
+_after_ calling scm_make_rectangular or scm_make_polar.
+
+For example, (string>number "#i5.0+0i") now does the equivalent of:
+
+ (makerectangular (exact>inexact 5.0) (exact>inexact 0))
+
+which yields 5.0+0.0i. Previously it did the equivalent of:
+
+ (exact>inexact (makerectangular 5.0 0))
+
+which yielded 5.0.
+
** Unicode characters
Unicode characters may be entered in octal format via e.g. `#\454', or
@@ 1348,6 +1284,17 @@ The pre1.9.3 reader handled 8bit clean but otherwise
unspecified source
code. This use is now discouraged. Binary input and output is
currently supported by opening ports in the ISO88591 locale.
+** Source files default to UTF8.
+
+If source files do not specify their encoding via a `coding:' block,
+the default encoding is UTF8, instead of being taken from the current
+locale.
+
+** Interactive Guile installs the current locale.
+
+Instead of leaving the user in the "C" locale, running the Guile REPL
+installs the current locale. [FIXME xref?]
+
** Support for locale transcoding when reading from and writing to ports
Ports now have an associated character encoding, and port read and write
@@ 1673,6 +1620,14 @@ should use Guile with Emacs.
crazy. Please change to use `catch', possibly with a throwhandler, or
`withthrowhandler'.
+** Deprecated: primitive properties
+
+The `primitivemakeproperty', `primitivepropertyset!',
+`primitivepropertyref', and `primitivepropertydel!' procedures were
+crufty and only used to implement object properties, which has a new,
+threadsafe implementation. Use object properties or weak hash tables
+instead.
+
** Deprecated address@hidden' syntax
address@hidden' was part of an older implementation of the Emacs Lisp language,
@@ 1680,13 +1635,14 @@ and is no longer used.
** Miscellaneous other deprecations
`applytoargs', `hassuffix?', `schemefilesuffix'
`getoption', `fornextoption', `displayusagereport',
`transformusagelambda', `collect', `setbatchmode?!',

`cuserid' has been deprecated, as it only returns 8 bytes of a user's
login. Use `(passwd:name (getpwuid (geteuid)))' instead.
+Additionally, the procedures `applytoargs', `hassuffix?',
`schemefilesuffix'
+`getoption', `fornextoption', `displayusagereport',
+`transformusagelambda', `collect', and `setbatchmode?!' have all
+been deprecated.
+
** Add support for unbound fluids
See `makeunboundfluid', `fluidunset!', and `fluidbound?' in the
@@ 1709,15 +1665,23 @@ backwardcompatible way. A new allocation routine,
Libgc is a conservative GC, which we hope will make interaction with C
code easier and less errorprone.
** New procedures: `scm_to_latin1_stringn', `scm_from_latin1_stringn'
+** New procedures: `scm_to_stringn', `scm_from_stringn'
+** New procedures: scm_{to,from}_{utf8,latin1}_symbol{n,}
+** New procedures: scm_{to,from}_{utf8,utf32,latin1}_string{n,}
+
+These new procedures convert to and from string representations in
+particular encodings.
Use these procedures when you know you have latin1encoded or
ASCIIencoded strings.
+Users should continue to use locale encoding for user input, user
+output, or interacting with the C library.
** New procedures: `scm_to_stringn', `scm_from_stringn'
+Use the Latin1 functions for ASCII, and for literals in source code.
Use these procedures if you want to encode or decode from a particular
locale.
+Use UTF8 functions for interaction with modern libraries which deal in
+UTF8, and UTF32 for interaction with utf32using libraries.
+
+Otherwise, use scm_to_stringn or scm_from_stringn with a specific
+encoding.
** New type definitions for `scm_t_intptr' and friends.
hooks/postreceive

GNU Guile
[Prev in Thread] 
Current Thread 
[Next in Thread] 
 [Guilecommits] GNU Guile branch, master, updated. release_1915108g487bacf,
Andy Wingo <=