freenode/#sbcl - IRC Chatlog
Search
14:49:10
dougk_
Xof: would be opposed to my pushing an improved fix for https://bugs.launchpad.net/sbcl/+bug/1366263 without which it's not possible to even reliably run cheneygc? I think it's gotten worse somehow
14:55:45
Xof
the analysis in that bug is plausible, but it would be nice to know why it's suddenly worse
14:55:48
dougk_
dont know the timeframe, but i have near identical places at which failure occurs on both emulators and physical hardware
14:56:42
Xof
If it's not new, I'd rather see the patch at the start of 1.4.7.x, unless it only touches cheneygc-only source
14:57:27
Xof
(and even then, I'd like to think twice about committing during the freeze; the thought of possibly invalidating all the testing done so far is a bit miserable)
14:58:13
Xof
I was singing the praises of this attitude to Ludovic Cortes at ELS; I'd quite like to act as if it is true :)
15:01:00
dougk_
so out of curiosity, why can an octet buffer straddle the unprotected/protected boundary? i thought that the lowest protected page strictly bounds the range below which is in-use and above which is not-in-use ?
17:18:20
dougk_
stassats: i bisected the Alpha failure to "Fix stack exhaustion in with-alien on non-x86oids."
20:38:18
phoe
the code walker in SBCL is very aggressive when macroexpanding. when I try to slime-macrostep the external DEFUN in the form (defun foo () (when nil (defun bar 2))) then I get thrown into the debugger.
20:39:08
phoe
I'd find it more convenient to be thrown into the debugger when the actually wrong form is attempted to be macrostepped - if I try to step into a complicated macro, I instantly get an error, instead of being able to expand the outer macro and try expanding inner ones to check for the exact location of the error.