no-auto-compile t2
5
$ 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: unr
to-compilation is enabled, set 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
ed in the guile documentation are actually 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
;)' >t13
$ echo '(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
an incarnation of this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734128
-zefram
:
?: 3 [primitive-load "/home/zefram/usr/guile/t6"]
In ice-9/eval.scm:
387: 2 ^Z
zsh: suspended guile-2.0 --no-auto-compile t6
$ jobs -l
[1] + 32574 suspended guile-2.0 --no-auto-compile t6
$ ps vw 32574
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
32574 pts/5T
N doesn't fit. Scheme's "complex" is
similarly extended relative to the mathematical complex numbers, but
the mathematical term "hypercomplex" unfortunately refers to something
quite different (quaternions and the like).
-zefram
:
788: 1 [call-with-input-file #f ...]
In unknown file:
?: 0 [open-file #f "r" #:encoding #f #:guess-encoding #f]
ERROR: In procedure open-file:
ERROR: Wrong type (expecting string): #f
$
This is guile-2.0.9 on Debian. Debian incarnation of this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734314
-zefram
ich is what the flonum indefinite `infinity'
really represents.)
-zefram
to disable.
;;; compiling /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 ru
h between actual literal pairs (that can be
merged) and non-literals whose 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
way from
script execution. 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
ments.
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
xpt 2.0 -53) 1.0)
$10 = 1.0002
fl+'s behaviour is not a bug. The R6RS ideal is clearly not mandatory,
and the Guile documentation makes no stronger claim than that its fl+
conforms to R6RS. As it is consistent between compiler and interpreter,
it is not subject to the concern that I'm raising in this ticket about
the generic +.
-zefram
e then a
"newer than" banner is emitted. 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
at on the cached file. Although not quite as
effective as a hash comparison, it would be a huge practical improvement
over the current filename-and-inexact-mtime comparison.
-zefram
nsible to offer
some explicit control over the encoding to be used with the environment,
just as I/O ports have a concept of per-port selected encoding.
The same issue applies to other environment access functions too.
For setenv the corresponding problem is the inability to *write* an
arbitrary octet string to an environment variable. Obviously all the
functions should have mutually consistent behaviour.
-zefram
ed by locale"
mostly apply here too, with a slight change: it seems necessary to store
the original octet strings and decode at the time program-arguments is
called. With that change, the decoding can be responsive to setlocale
(and in particular can reliably use ISO-8859-1 in the absence of
setlocale).
-zefram
(- (integer-length v))) (if (< v 0) -1 0))
(else (ash v s
-zefram
ation's extent, even if the continuation's extent is
still in progress in its original thread and the continuation has
never been invoked.
-zefram
is false in this case. I think a continuation barrier should block the
use of the call/ec continuation.
-zefram
It also only happens when compiling, not when interpreting:
scheme@(guile-user)> ,o interp #t
scheme@(guile-user)> (list 'a (let/ec ae (list 'b (let/ec be (be 2)
$7 = (a (b 2))
scheme@(guile-user)> (list 'a (let/ec ae (list 'b (let/ec be (ae 2)
$8 = (a 2)
scheme@(guile-user)> (list 'a (let/ec ae (list 'b (ae 2
$9 = (a 2)
-zefram
y in Guile 1.8.
-zefram
lem with a 2^63 bit shift. My bug
does occur with the rnrs bitwise-arithmetic-shift-right, which was used
in #14864, as well as with ash.
-zefram
es to UTC should instead be to "UT", the wider class
of closely-matching time scales of which UTC is one representative.
Also, in the first sentence of this doc section, the phrase "universal
time (UTC)" should be either "universal time (UT)" or (more likely)
"coordinated universal time (UTC)".
-zefram
"~4")
$1 = "-4714-11-24T12:00:00Z"
The date in question, the JD epoch, is 24 November 4714 BC (in the
proleptic Gregorian calendar). In ISO 8601 format, that year is properly
represented as "-4713", not "-4714", because ISO 8601 uses the AD era
exclusively. 4714 BC = AD -4713.
-zefram
->string (julian-day->date 1 0) "~1")
$8 = "269078-08-07"
For year numbers 1 and above, it is necessary to use more than four
digits for the year, and that's permitted, but ISO 8601 requires that
more than four digits are preceded by a sign. For positive year numbers
the sign must be "+". So one should write "+22666" rather than "22666",
for example.
The formatting of year numbers for ISO 8601 purposes is currently only
correct for numbers -1000 and lower (though the choice of number is off
by one) and for year numbers 1000 to inclusive.
-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
rror
when trying to represent a zone offset that's not an integral minute.
Incidentally, for offsets of -1 to -59 inclusive, the truncation isn't
clearing the negative sign, so is producing the invalid output "-".
The zero offset is required to be represented with a "+" sign. If you
take the rounding option described above, anything that rounds to a
zero-minutes offset must yield "+00:00" in the output.
-zefram
ent of the leap being misinterpreted as a time-tai seconds value.
The UTC-to-TAI conversion is in better shape. As a result,
time-tai->time-utc and time-utc->time-tai are not inverses during the
35 second erroneous period. Round-tripping through the two conversions
produces an output not matching the input.
-zefram
ere will be no leaps at all beyond the
historically-scheduled ones that it knows about.
Guile ought to be aware of how far its leap table extends, and signal
an error when asked to perform a TAI<->UTC conversion that falls outside
its scope.
-zefram
ever is done, even if it's to endorse the inconsistency, the behaviour
should be documented, with rationale.
-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
The faulty output is always 23:59:60 in the output zone.
Matching up with this, the actual leap second is never correctly described
with a non-zero zone offset. It should be, for example, 00:59:60+01:00.
However, probing for this side of the problem also runs into the
round-tripping failure that I described in bug#22033.
-zefram
on the other hand, it is decided to endorse the current non-decoding
behaviour, then the break of abstraction needs to be documented.
-zefram
am not attempting to use it myself, despite the
scenario implied by the above test cases. I think it's a bloody 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
ning.
However, if it is deemed to be essential that Guile 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
ding.
Non-primordial ports opened before or after the setlocale call are
not affected.
-zefram
that it does so, this really amounts to setting the
encoding before every I/O operation.
-zefram
to determine encoding for all environment access.
The latter would match the encoding model used by ports.
-zefram
l of encoding will be necessary.
-zefram
file that exists]
Obviously, even if a program could turn off the locale mangling in
general, this instance 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
r to get access.
Lazy loading sounds like a bad idea. Error handling is a bad place to
attempt something that complex and failure-prone.
-zefram
l. The case I originally raised, (* 0 +inf.0), is one
for which R6RS offers the choice.
-zefram
ecoding via
the selected locale does not suffice, because there's no guarantee that
there'll be a locale with a cooperative encoding.
-zefram
really easy to trigger within 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
Andy Wingo wrote:
>Would you like to propose a specific patch to the documentation?
Sure. Patch attached.
-zefram
--- a/doc/ref/srfi-modules.texi 2014-03-20 20:21:21.0 +
+++ b/doc/ref/srfi-modules.texi 2016-06-24 18:57:59.088243245 +0100
@@ -2461,8 +2461,8 @@
@cindex UTC
@cin
specifies its own encoding.) The program 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
n decide to abort rather than continue with faulty output,
would be another middle way.
-zefram
ey expected
to manually save and restore port encodings 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
portable back to Guile versions lacking
the new function, by using cond-expand, false-if-exception, or other
metaprogramming facilities.
-zefram
orts
that are automatically opened at program initialisation can be set to
#:locale-at-io, and setlocale now doesn't directly set the encoding of
any port. If the user calls setlocale without otherwise controlling port
encoding then the locale controls the encoding of the primordial ports.
I expect that's the effect that the setlocale code was aiming for,
given that when setlocale is called it's too late to affect the opening
of the primordial ports.
-zefram
e it under 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
LOCALE=0\n!#\n" immediately following the program's
initial #!...!# block. This is ignored as a comment by older Guile
versions. The semantic on newer versions would be that the setting given
there (which may be 0 or 1) determines conclusively whether the implicit
setlocale happens. The environment variable would take effect as it
currently does only for programs not containing this kind of setting.
-zefram
ategy. These 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
or the foreseeable future, and it needs to be shorn
of its unwanted side effects.
-zefram
hould be
credited to SRFI-19 (the standard), not to the code.
-zefram
7;s (lack of) text on this matter? You should
consider the possibility of changing your implementation to use the
conventional astronomical year numbering in this slot.
-zefram
for the 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
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
seconds. It is not somehow squeezed into two UTC seconds.
-zefram
ons for some earlier
years once the above is fixed.
-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
. Since the documentation's list is otherwise
complete, presumably it is intended to be a complete list, and the
omission of this feature from the list is a mistake. In any case,
it would be helpful to list it.
-zefram
g this requires not using any formatting mechanism that would ever
resort to exponent notation for values in the relevant range.
-zefram
ation of ~f, but with that
example it does at least seem clear that there should be no padding there.
-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
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
Andy Wingo wrote:
>This makes sense to me, FWIW.
Patch attached.
-zefram
>From 444703940983d559935c4dd2a2c89d7888c67119 Mon Sep 17 00:00:00 2001
From: Zefram
Date: Wed, 19 Apr 2017 17:08:30 +0100
Subject: [PATCH] correct note about Gregorian reform in SRFI-19
SRFI-19 specifies proleptic
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
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-difference to time struc
t 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
Date: We
#x27;guile' 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
support 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 43dfb5fabc9debb80f87b17d82a1
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
numbering is really only about this bug.
-zefram
>From 3d39f1dfa0e210282db48a9af828646d7e9acef3 Mon Sep 17 00:00:00 2001
From: Zefram
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-19's date->
nds it would
still be wrong. In the 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
he best
way forward. What do you think? If you like it, I could work up a patch.
-zefram
s (roughly 86399.90003 s). This runs
into trouble with SRFI-19's insistence that the nanosecond field of a
time object only contain an integer.
-zefram
rary,
having attempted conversions 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
82 matches
Mail list logo
