With Guile 2.0.11:
scheme@(guile-user)> (define cc #f)
scheme@(guile-user)> (map (lambda (v) (if (= v 0) (call/cc (lambda (c) (set! cc
c) 0)) (+ v 1))) '(10 20 30 0 40 50 60))
$1 = (11 21 31 0 41 51 61)
scheme@(guile-user)> (cc 5)
$2 = (61 51 41 0 31 5 41 51 61)
It worked correctly in Guile 1.8.
With Guile 2.0.11:
scheme@(guile-user)> (ash 123 (ash -1 63))
$1 = 123
Correct result would of course be zero. Problem only occurs for
exactly this shift distance: one bit less produces the right answer.
Problem also occurs on Guile 1.8.8. Looking at the implementation,
the problem is attributa
The manual says, in the section "SRFI-19 Introduction",
#Also, for those not familiar with the terminology, a "Julian Day" is
# a real number which is a count of days and fraction of a day, in UTC,
# starting from -4713-01-01T12:00:00Z, ie. midday Monday 1 Jan 4713 B.C.
There are two errors i
The date->string function from (srfi srfi-19), used on ISO 8601 formats
"~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:
scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (date->string (julian-day->date 0 0) "~4")
$1 = "-4714-11-24T12:00:00Z"
The date i
The date->string function from (srfi srfi-19), used on ISO 8601 formats
"~1", "~4", and "~5", gets the formatting of year numbers wrong when the
year number doesn't have exactly four digits. There are multiple cases:
scheme@(guile-user)> (date->string (julian-day->date 150 0) "~1")
$1 = "-607
scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (julian-day->date 0 0)
$1 = #
scheme@(guile-user)> (julian-day->date -1 0)
$2 = #
scheme@(guile-user)> (julian-day->date -10 0)
$3 = #
scheme@(guile-user)> (julian-day->date -1000 0)
$4 = #
Observe the various erroneous
scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (date->string (julian-day->date 245 3600) "~4")
$1 = "1995-10-09T13:00:00+0100"
scheme@(guile-user)> (date->string (julian-day->date 245 3630) "~4")
$2 = "1995-10-09T13:00:30+0100"
There are two problems here with date-
Probing the TAI-to-UTC conversion offered by srfi-19's time-tai->date,
in the minutes around the leap second in 2012:
scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (for-each (lambda (d) (write (list d (date->string
(time-tai->date (add-duration (julian-day->time-tai 24561
Probing the existence of leap seconds on particular days, via srfi-19's
TAI-to-UTC conversion. The methodology here is to take noon UT on the
day of interest, convert to TAI, add 86400 seconds, then convert to UTC
and display. The resulting time of day is 11:59:59 if there is a leap
second that d
The write function is inconsistent about whether it distinguishes between
#nil and ():
scheme@(guile-user)> '(#nil . a)
$1 = (#nil . a)
scheme@(guile-user)> '(a . #nil)
$2 = (a)
Thee latter behaviour, emitting #nil as if it were (), breaks the usual
write/read round-tripping, and the traditional
Here's a fix to this bug. Tests pass, and performance appears to be
back here.
I've assigned copyright to the FSF for Guile so it should be fine to
commit!
>From 79e3b5286a2699f9b302bd3abf8a6b884b13a4f4 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber
Date: Fri, 13 Nov 2015 20:42:31 -060
11 matches
Mail list logo
