freenode/#clasp - IRC Chatlog
Search
15:15:19
Bike
well, it'e easy enough to define af unction that catches out of extent returns, but i don't think i have any way for the slime repl to use it
15:20:12
Bike
er, (call-without-escape (lambda () (funcall (block nil (lambda () (return)))))) that is
15:28:15
drmeister
frgo: A new Keychron update came out yesterday - keyboards with blue switches are going to ship. Yippee-kay-yay!
15:29:35
frgo
... I am eager to get to use that ... my stock Apple external keyboard is, well, far from optimal.
15:30:01
drmeister
Soon my fingertips will be dancing on the bouncy playground of a Keychron C2 keyboard.
15:31:58
drmeister
Shift is unreliable, control is unreliable - 1/4 of all chorded keys in emacs fail and I have to backup and retype. Grrrrr
15:33:32
frgo
... yep! And I'm missing the sound of production. The clicks of that C2 keybaord is to coders what a good drilling machine is to a steel worker.
15:33:59
Bike
I think the right way to do this would be to define our own unwinder (in terms of libunwind), which does basically the same thing as the C++ one except if it doesn't find a handler it signals an error instead of terminating, and then we use that instead of "throw" for return-from
18:07:29
Bike
drmeister: was there a reason not to use llvm.frameaddress? i think i'm going to try it for dynamic block keys (instead of consing like we do now)
19:11:42
Bike
well, it works perfectly, but i guess there's no guarantee an out of extent return might accidentally hit a frame, so we'd also want a counter of some kind
22:54:17
Bike
so about unwinding: right now what we do is when we hit a catch-instruction, we make a cons to distinguish the frame
22:54:48
Bike
i tried having it use llvm.frameaddress aka __builtin_frame_address aka RBP instead, and that works, but for out of extent returns it might be ambiguous so we'd need a counter or something in there too
22:55:41
Bike
if we do that, we can use libunwind to interrogate the RBP of each frame, and so i put something together that can note out of extent returns and do something nicer than crashing
22:55:57
Bike
this makes unwinding slower, because we then interrogate the stack three times, instead of just twice
0:55:25
Bike
the itanium abi is reasonable but the C++ one is... way more complex than we need for lisp
0:58:48
Bike
because you could hypothetically have a new, unrelated stack frame that happens to have the same frame pointer
1:00:43
Bike
then two separately established frames would be distinguished by having different integers
1:01:34
Bike
anywho, i think we could set up a personality routine that uses our rules to determine whether a frame is where we're exiting to, instead of C++'s like we do now
1:01:52
Bike
so it would just check that it's one of our exceptions and not C++'s, and if so, compare the frame pointer and this counter, and that's it
1:06:48
Bike
In C++ you can have like, "} catch (foo x) { ... throw x; ... }" so the exception has to stick around, and the unwind machinery has to be prepared for that
1:07:26
Bike
we have it NOW, but only because if we have a dynamic block it does a C++ catch for EVERY unwind, even if it's just passing through
1:18:54
Bike
anyway first i'll merge what i have (with fpe disabled), it handles a few more signals more nicely