freenode/#sbcl - IRC Chatlog
Search
9:03:41
scymtym
f55c8ae436a47c5a1e7e5914890808675d9ef822 (x86-64: Eliminate some redundant moves) seems to cause this: https://jenkins-cse.bob.ci.cit-ec.net/job/build-generator-master-ci-docker-build-generator-nightly/1437/console
9:05:23
pfdietz22
That should be easy enough to track down. Random testing is not showing that bug, but it doesn't generate full CL.
9:09:13
scymtym
anyway, the bug is probably reproducible by compiling ironclad or https://github.com/sharplispers/ironclad/blob/3f7da517e5efdd617ed179d1ef6c9048c91dc863/src/ciphers/aria.lisp#L397 in particular
9:15:32
flip214
I was really bothered when I was in France, and mutt told me "unexpected error" from the imap server -- something in the middle changed the "starttls" to "startxxx"...
11:24:53
phoe
regarding my recent launchpad bug about FORMAT ~E, one of the smallest test cases I've found is (format t "~E" 1.365753E-29) ;=> 1.3657531e-29
12:14:45
flip214
phoe: a single-float only has 5 decimal digits in the mantissa, IIRC... should ~E output that many?
12:18:22
flip214
well, a single-float is 32bit, of which 1+7+1 are used for exponent and sign - so 23bits are left. that's 7 digits at most, including the ones before the comma
12:22:31
phoe
well anyway - there is a disparity between PRIN1 and FORMAT ~E in how they print that particular float
13:25:59
phoe
and I think that the issue is on the FORMAT ~E side because 1.3657531 has an unnecessary decimal digit, since 1.365753 is the same float
14:21:11
phoe
found a curious thing - #'format-exp-aux calls sb-impl::scale-exponent that transforms the number
14:27:15
phoe
is this result expected? it seems that this is where the error appears and then gets forwarded all into the flonum-to-string and printing machine
14:53:31
phoe
print-float calls %flonum-to-digits on the original value, but format-exp-aux calls %flonum-to-string on the modified value