freenode/#lisp - IRC Chatlog
Search
2:01:56
pjb
White_Flame: (loop for test in '( nil (f o o) ) collect (format nil "(~{~A~^ ~})" test)) #| --> ("()" "(f o o)") |#
6:25:11
flip214
jdz: thanks, sent an email yesterday, too.... in the meantime I opened https://github.com/quicklisp/quicklisp-projects/issues/1825 to use your repo instead ;)
7:02:53
jdz
flip214: Cool. I have not run into the OOM issue, so I'm glad I've fixed it unknowingly.
7:04:13
jdz
The main issue I was fixing was out-of-bounds array access, which was not very nice since there were (safety 0) declarations.
7:12:27
flip214
didn't spend any time looking for the reason.... allocating 2GB for a NIL sounds interesting
7:16:16
flip214
hmmm, replicating the (declare (string input) (optimize ... (safety 0))) isn't enough, I get a type error
7:21:08
flip214
aeth: that's why https://github.com/jdz/cl-base64/commit/f495809807a9311747c84fcb9520105ed663a971
7:31:32
aeth
to be fair, (safety 0) wouldn't be less safe than C if SBCL didn't also stop doing most static checking when (safety 0) not just runtime checking
7:33:01
aeth
Compare (safety 0) to (safety 1) here: (with-compilation-unit () (defun hi () "hi") (defun foo () (declare (optimize (safety 0))) (+ 0 (hi))))
7:35:05
aeth
beach: The C compiler will tell you it's bad, as will SBCL with (safety 1). Compiler, not runtime. Of course, this is not quite a good example because GENERIC-+ will still typecheck so it won't mess up at runtime. This is UB because it's a non-generic +: (with-compilation-unit () (defun hi () "hi") (defun foo () (declare (optimize (safety 0))) (+ 0 (the fixnum (hi)))))
7:35:39
aeth
THE, of course, is portably speaking dangerous, but only because it permits behavior like what's happening here with SBCL, but only when SBCL has (safety 0)
7:36:18
adlai
beach: thanks; so it's probably for a specific project? since specbot is in #sbcl too, there's even a usual suspect :)
7:37:11
aeth
My example is also bad in one other way... (+ 0 ...) won't mess things up, but any other number probably will
7:38:12
aeth
to be fair, (safety 0) does have its use in removing bounds checks in arrays in a LOCALLY if you really know what you're doing...
7:38:42
aeth
Just never do it at the function level because then it won't check the inputs, e.g. you could pass in too many or too few arguments
7:38:56
jdz
aeth: One does not need (safety 0) if the compiler can figure out the bounds checks don't have to be checked on every iteration.
7:39:24
aeth
There definitely are cases where you know it can't go out of bounds but SBCL does not (yet) know this
7:41:41
aeth
I generally use fixed-size arrays when I want performance, though. Then there's no need to play any games around bounds checking.
7:44:40
aeth
Anyway for anyone following along later, my final, corrected version of messing up your SBCL with (safety 0) that will otherwise be caught at compile time is: (with-compilation-unit () (defun hi () "hi") (defun foo () (declare (optimize (safety 0))) (+ 2 (the fixnum (hi)))))
12:10:54
flip214
when I try stepping via swank, the next output is a (continue) call in SWANK:SLDB-NEXT. I'd have expected to get the next form after the (BREAK)
12:16:13
flip214
but the command going across the wire is "000038(:emacs-rex (swank:sldb-next 0) "COMMON-LISP-USER" 3 69)", and frame 0 is the function frame that I'm trying to step through?!
12:39:02
beach
flip214: I have never managed to get stepping to work to my satisfaction. It is of course possible that I am doing something wrong.
12:40:17
jcowan
"Removing run-time checks in production is like having life jackets in port but removing them before going to sea in order to carry more cargo."
13:51:20
jasom
jcowan: coincidentally, I just had a project that saved a large amount of money *because* assertions were disabled in production.
13:54:49
jasom
hardware docs said that both the "success" and "error" indicator bits wouldn't be set at the same time. error-injection testing caught this happening in aging parts after about a year and a half of testing due to the assertion. Analysis of behavior without the assert is that the driver will eventually reset the hardware and continue. No patch needed specifically for this problem.