$ guile-2.0 t2
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t2
;;; WARNING: compilation of /home/zefram/usr/guile/t2 failed:
;;; ERROR: build-constant-store: unrecognized object
GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t0
;;; WARNING: compilation of /home/zefram/usr/guile/t0 failed:
;;; ERROR: #. read expansion found and read-eval? is #f.
hello world
$
I can turn off the auto-compilation from within
available,
despite not being listed.
This is guile-2.0.9 on Debian. Debian incarnation of this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734313
-zefram
'(display bbb\n)' t14
$ guile-2.0 t13
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t13
;;; compiled
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t13.go
aaa
$ mv
/bugreport.cgi?bug=734128
-zefram
[#procedure e9bcc0 at ice-9/boot-9.scm:3961:3 ()]
1645: 5 [%start-stack load-stack #procedure e9c980 at ice-9/boot-9.scm:3957:10
()]
1650: 4 [#procedure e9a060 ()]
In unknown file:
?: 3 [primitive-load /home/zefram/usr/guile/t6]
In ice-9/eval.scm:
387: 2 ^Z
zsh: suspended guile-2.0 --no-auto-compile
to the mathematical complex numbers, but
the mathematical term hypercomplex unfortunately refers to something
quite different (quaternions and the like).
-zefram
report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734314
-zefram
the flonum indefinite `infinity'
really represents.)
-zefram
/home/zefram/usr/guile/t9
;;; compiled
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t9.go
(5 . 2)
(5 . 2)
$ guile-2.0 t9
(5 . 2)
(5 . 2)
In the test case, the explicitly-constructed pair aaa is conflated with
the pair literal (1 . 2), and so the runtime modification of aaa
distinct identity needs to be preserved.
This might well be painful to add to your existing code, given the
way you represent pairs. But that's a difficulty with the specific
implementation, not an inherent limitation of compilation.
-zefram
. In that case, either the REPL should perform the same
fallback that script execution does (as I originally suggested on this
ticket), or script execution should not perform the fallback.
-zefram
object and needs its own serialisation arrangements.
Presumably you already have that solved in order to compile code that
contains function definitions. Aside from that it's all ordinary
Lisp objects that look totally serialisable. What do you think is the
difficult part?
-zefram
. With the environment variable set the
cached version will never be updated, nor will it be deleted, so the
banner then appears on every execution.
-zefram
ven if the continuation's extent is
still in progress in its original thread and the continuation has
never been invoked.
-zefram
$4 = #
Observe the various erroneous field values: negative hour, negative
day-of-month, zero month. These occur in general for various negative
JD inputs. Not only should the conversion not produce these kinds of
values, the date structure type probably ought to reject them if they
get that far.
-zefram
t;)
Observe that the second immediately following the leap second, the
first second of the following UTC day, isn't round-tripped correctly.
It comes back as the leap second. These two seconds are perfectly
distinct parts of the UTC time scale, and the time-utc format ought to
preserve their distinction.
-zefram
nally raised, (* 0 +inf.0), is one
for which R6RS offers the choice.
-zefram
ng via
the selected locale does not suffice, because there's no guarantee that
there'll be a locale with a cooperative encoding.
-zefram
thin that:
scheme@(guile-user)> (let ((x (list 'a)) (y (list 'a))) (eq? x y))
$1 = #f
scheme@(guile-user)> (let* ((x (list 'a)) (y (list 'a))) (eq? x y))
$2 = #t
scheme@(guile-user)> (let ((x (list 'a))) (let ((y (list 'a))) (eq? x y)))
$3 = #t
-zefram
One more variant:
scheme@(guile-user)> (let ((x (list 'a))) (eq? x (list 'a)))
$1 = #t
scheme@(guile-user)> ,opt (let ((x (list 'a))) (eq? x (list 'a)))
$2 = (let ((x (list 'a))) (eq? x x))
-zefram
ram could be env(1), not
interpreting the environment but needing to output the octets correctly.
The program could be saving an uninterpreted environment, for a cron
job to later run some other program with equivalent settings.
-zefram
dy stupid
mechanism, imposing on the program something that needs to be under the
program's control, and which previously was. I'm actually investigating
how to make programs cope with the unpredictable situation caused by
this mechanism with the unpredictable environment setting.
-zefram
ng
behaviour, then the break of abstraction needs to be documented.
-zefram
ile attempt the implicit
setlocale and gripe about its failure, then the message should not
precede or otherwise mix with the actual program run. The message should
be emitted *instead of* running the program, declaring the absolute
incompatibility of the Guile framework with this environmental condition.
-zefram
, this really amounts to setting the
encoding before every I/O operation.
-zefram
encoding will be necessary.
-zefram
onment access.
The latter would match the encoding model used by ports.
-zefram
nce of it occurs too early for the program to avoid.
The guile framework itself has acquired the kind of 8-bit-cleanliness
bug that it is imposing on the programs that it interprets.
-zefram
primordial ports opened before or after the setlocale call are
not affected.
-zefram
ese two fluids together would
control the encoding and decoding for all operations that currently
apply the locale encoding to arbitrary data. (Decoding locale-supplied
messages is a different matter.)
-zefram
around setlocale calls?
(This is complicated by set-port-encoding! not accepting #f as an encoding
value, despite it actually being a permitted value for the encoding slot.)
Some example code equivalent to the above call-with-locale would be
useful.
-zefram
the name "libgc". So I've now got 2.1.3 running.
All of the code in my day-of-week-string-for-locale sketch works exactly
the same on 2.1.3 as it did on 2.0.
-zefram
ther than continue with faulty output,
would be another middle way.
-zefram
foreseeable future, and it needs to be shorn
of its unwanted side effects.
-zefram
s requires not using any formatting mechanism that would ever
resort to exponent notation for values in the relevant range.
-zefram
(date->string (make-date 5 34 12 26 3 2017 0)
"~N")
$5 = ""
scheme@(guile-user)> (date->string (make-date 2 5 34 12 26 3 2017 0)
"~N")
$6 = "2"
The padding clearly has to be to the full nine digits.
-zefram
I wrote:
>written to perform divisions with quotient where it obviously needs
>modulo.
Oops, thinko there. It needs floor-quotient, the quotient-like function
that uses floor rounding. modulo is the *remainder*-like function that
uses floor rounding.
-zefram
to SRFI-19 (the standard), not to the code.
-zefram
the possibility of changing your implementation to use the
conventional astronomical year numbering in this slot.
-zefram
or some earlier
years once the above is fixed.
-zefram
he second would be
#
or possibly, at a stretch,
#
(SRFI-19 isn't clear about which way it's meant to be normalised.
Having the nanoseconds field always non-negative is less surprising and
easier to maintain through computation.)
-zefram
It is not somehow squeezed into two UTC seconds.
-zefram
le documentation says the arguments "must be" of the same type.
It would be very easy for time-difference to detect and signal this error.
It's not absolutely a bug that it currently doesn't, but it would be a
useful improvement if it did.
-zefram
r operations:
scheme@(guile-user)> (eqv? time-tai time-monotonic)
$4 = #f
scheme@(guile-user)> (julian-day->time-tai 245)
$5 = #
scheme@(guile-user)> (julian-day->time-monotonic 245)
$6 = #
-zefram
033 and
to the bug regarding pre-1972 UTC. The latter I haven't even reported
yet because it's difficult to formulate in the presence of some of the
other UTC-related bugs such as bug#21911 and bug#21912. So I think this
is one to postpone until some of those are out of the way.
-zefram
Patch attached.
-zefram
>From 6f9d9b355233b578eb3ce13549c8fdc9d7fb8364 Mon Sep 17 00:00:00 2001
From: Zefram <zef...@fysh.org>
Date: Wed, 19 Apr 2017 19:02:13 +0100
Subject: [PATCH] signal error of time-difference on differing types
It is an error to apply SRFI-19's time-differenc
' failed
make[3]: *** [guile] Error 1
At a guess, maybe this is supposed to be supplied by libgc. But I have
the version of libgc that README says is required (7.2), and configure
was happy with it. Maybe a higher version is now required, and README
and configure need updating?
-zefram
numbering is really only about this bug.
-zefram
>From 3d39f1dfa0e210282db48a9af828646d7e9acef3 Mon Sep 17 00:00:00 2001
From: Zefram <zef...@fysh.org>
Date: Thu, 20 Apr 2017 00:53:40 +0100
Subject: [PATCH 2/2] fix SRFI-19's ISO 8601 year numbering
The ISO 8601 date formats offered by SRFI-
Andy Wingo wrote:
>This makes sense to me, FWIW.
Patch attached.
-zefram
>From 444703940983d559935c4dd2a2c89d7888c67119 Mon Sep 17 00:00:00 2001
From: Zefram <zef...@fysh.org>
Date: Wed, 19 Apr 2017 17:08:30 +0100
Subject: [PATCH] correct note about Gregorian reform in SRFI-19
SRFI-
in date->string at all,
but more strongly because it's useful to have access to ISO 8601 year
formatting on its own. There isn't any other format specifier for that
job; it looks like SRFI-19 imagines that ~Y will fill that need.
-zefram
>From 43dfb5fabc9debb80f87b17d82a1adde356e547c Mon Sep
port the ~z problems in a separate ticket if you like.
Beware that the second of these patches has some textual dependence on
the first, so trying to handle them separately might just be confusing.
-zefram
>From e6db0e40e5464591df204f9d07e66b3d7853c0d7 Mon Sep 17 00:00:00 2001
From: Zefram <zef.
I wrote:
>I chose the former strategy, partly because the funny non-linear year
>number doesn't seem a useful thing to support in date->string at all,
Sorry, this comment is misplaced. It relates to bug#21903; the choice
about ~Y applies to both of these bugs.
-zefram
rubber seconds era the number of UTC seconds in
an interval differs from the number of TAI seconds.
-zefram
hmetic
could be performed, because UTC is not defined for any time prior to 1961.
The only sane behaviour is for the conversion to signal an error.
The same goes for time-tai->time-utc, which at present accurately inverts
time-utc->time-tai for the above time.
-zefram
ike it, I could work up a patch.
-zefram
tence that the nanosecond field of a
time object only contain an integer.
-zefram
signal an error. That would have to be
documented, and it seems like it would still amount to a deviation from
the requirements of SRFI-19.
-zefram
58 matches
Mail list logo
