#13698 closed enhancement (fixed)
guile-3.0.3
| Reported by: | Bruce Dubbs | Owned by: | Douglas R. Reno |
|---|---|---|---|
| Priority: | normal | Milestone: | 10.0 |
| Component: | BOOK | Version: | SVN |
| Severity: | medium | Keywords: | |
| Cc: |
Description
New point version.
Change History (5)
comment:1 by , 6 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 6 years ago
Note:
See TracTickets
for help on using tickets.

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 level. *** 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 build. ** 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 procedures These replace the wonky "bit-count", "bit-count*", and "bit-position" procedures. *** 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 (<https://bugs.gnu.org/40737>, <https://gitlab.com/wingo/lightening/-/issues/12>) ** 'http-get', 'http-post', etc. now honor #:verify-certificates? (<https://bugs.gnu.org/40486>) ** web: Accept URI host names consisting only of hex digits (<https://bugs.gnu.org/40582>) ** (web http) parser recognizes the CONNECT and PATCH methods ** Initial revealed count of file ports is now zero (<https://bugs.gnu.org/41204>) * New deprecations ** Old bitvector interfaces deprecated See "Bit Vectors" in the manual, for details on all of these replacements. *** 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.