Opened 15 months ago

Closed 15 months ago

Last modified 15 months ago

#13698 closed enhancement (fixed)


Reported by: Bruce Dubbs Owned by: Douglas R. Reno
Priority: normal Milestone: 10.0
Component: BOOK Version: SVN
Severity: normal Keywords:


New point version.

Change History (5)

comment:1 by Douglas R. Reno, 15 months ago

Owner: changed from blfs-book to Douglas R. Reno
Status: newassigned

comment:2 by Douglas R. Reno, 15 months ago

Changes in 3.0.3 (since 3.0.2)

* New interfaces and functionality

** New baseline compiler

Guile's CPS-based compiler generates good code, but it takes time and
memory to do so.  For users that prioritize speed of compilation over
speed of generated code, Guile now has a new baseline compiler that goes
directly from the high-level Tree-IL to bytecode, skipping CPS and all
of its optimizations.  This compiler is used for `guild compile -O0',
and generally runs around ten times as fast as the CPS compiler.

*** New VM intrinsics to support baseline compiler

See "Intrinsic Call Instructions" in the manual.

*** Compiler support for warning and lowering passes
*** Compiler support for choosing different compilation orders

See "Compiler Tower" in the manual.  The new per-language "compiler
chooser" facility can choose different compilers based on optimization

*** Better support for specifying optimization and warning levels

The procedural compilation interfaces (`compile', `compile-file', and so
on) now have #:optimization-level and #:warning-level keyword arguments,
which default to corresponding `default-optimization-level' and
`default-warning-level' parameters.  You can still specify warning and
optimization passes manually, but we think most users will find the
higher-level interfaces more robust to use.

** Faster Guile build from source

Guile now uses the baseline compiler for its bootstrap, when building
the first Scheme compiler.  Because the baseline compiler runs faster
and includes less code than the CPS compiler, Guile takes less time to

** New 'pipeline' procedure in (ice-9 popen)

The 'pipeline' procedure provides a simple way to spawn command pipeline
as one would do in a shell.

** Refreshed bitvector facility

See "Bit Vectors" in the manual, for more on all of these.

*** New bitvector-count, bitvector-count-bits, bitvector-position

These replace the wonky "bit-count", "bit-count*", and "bit-position"

*** New bitvector-bit-set?, bitvector-bit-clear? procedures

These replace bitvector-ref.  The reason to migrate is that it's an
opportunity be more efficient in 3.0 (because the new procedures only
work on true bitvectors, and not generic bit arrays), easier to read (no
need for 'not' when checking for false bits), and more consistent with
other bitvector procedures.

*** New bitvector-set-bit!, bitvector-clear-bit! procedures

These replace bitvector-set!, for similar reasons as the bitvector-ref
replacement above.

*** New bitvector-set-all-bits!, bitvector-clear-all-bits! procedures

These replace bitvector-fill!.

*** New bitvector-flip-all-bits! procedure

This replaces bit-invert!.

*** New bitvector-set-bits!, bitvector-clear-bits! procedures

These replace the wonky "bit-set*!" procedure.

* Bug fixes

** statprof reports the names of primitives

Previously statprof would show strings like "anon #x1234" for primitives
written in C.

** Compiler reduces 'equal?' when passed a character literal

The compiler now properly reduces expressions such as (equal? c #\x) to
(eq? c #\x).  This was not the case in 3.0.2, which could lead to slower
code, especially in 'match' expressions with many clauses with with
character literals.

** JIT bugs on ARMv7 have been fixed

** 'http-get', 'http-post', etc. now honor #:verify-certificates?

** web: Accept URI host names consisting only of hex digits

** (web http) parser recognizes the CONNECT and PATCH methods

** Initial revealed count of file ports is now zero

* New deprecations

** Old bitvector interfaces deprecated

See "Bit Vectors" in the manual, for details on all of these

*** bit-count, bit-position

Use bitvector-count or bitvector-position instead.  

*** bitvector-ref

Use 'bitvector-bit-set?' or 'bitvector-bit-clear?' instead.

*** bitvector-set!

Use 'bitvector-set-bit!' or 'bitvector-clear-bit!' instead.

*** bitvector-fill!

Use 'bitvector-set-all-bits!' or 'bitvector-clear-all-bits!' instead.

*** bit-invert!

Use 'bitvector-flip-all-bits! instead.

*** bit-set*!

Use 'bitvector-set-bits!' or 'bitvector-clear-bits!' instead.

*** bit-count*

Use 'bitvector-count-bits' instead, subtracting from 'bitvector-count'
on the mask bitvector if you are counting unset bits.

*** Accessing generic arrays using the bitvector procedures

For the same efficiency reasons that use of 'vector-ref' on generic
arrays was deprecated in Guile 2.0.10, using 'bitvector->list' and
similar procedures on 1-dimensional boolean-typed arrays is now
deprecated.  Use 'array-ref' and similar procedures on arrays.

*** scm_istr2bve

This C-only procedure to parse a bitvector from a string should be
replaced by calling `read' on a string port instead, if needed.

comment:3 by Douglas R. Reno, 15 months ago

Resolution: fixed
Status: assignedclosed

Fixed at r23313

comment:4 by Bruce Dubbs, 15 months ago

Milestone: 9.210,0

Milestone renamed

comment:5 by Bruce Dubbs, 15 months ago

Milestone: 10,010.0

Milestone renamed

Note: See TracTickets for help on using tickets.