freenode/#clasp - IRC Chatlog
Search
4:38:54
drmeister
::notify Bike Looks good - Under Entry Point - call-with-stack or call-with-backtrace?
10:26:47
selwyn
i am getting a segfault upon building aclasp and i would like to use gdb on a finished iclasp to figure out what's going on
12:02:41
kpoeck
at least i can do /Users/karstenpoeck/lisp/compiler/clasp-karsten/build/boehm/iclasp-boehm --image /Users/karstenpoeck/lisp/compiler/clasp-karsten/build/boehm/fasl/aclasp-boehm-image.fasp
12:02:57
Colleen
Bike: drmeister said 7 hours, 24 minutes ago: Looks good - Under Entry Point - call-with-stack or call-with-backtrace?
12:06:15
selwyn
i get the error while building aclasp so i don't have an image unfortunately. will try the -l
13:05:58
Bike
i'm hoping we could rewrite it to have only one kind of "frame" object by having the "frames" be some C++ object that's also accessible in lisp, and having them form a (doubly) linked list instead of using std::vector
13:06:18
Bike
some things are confusing. there "size_t nptrs = backtrace.size()-2; nptrs -= 2; // drop the last two frames"
13:06:31
Bike
i assume that's to avoid capturing the backtrace machinery itself, but that's like... four.
13:18:57
Bike
alright, next redundancy: We have an InvocationHistoryFrame thing that probably dates from ECL. this is like, a separate stack of interpreter frame markers, I think?
13:19:10
Bike
we shouldn't need that. we should be able to recognize interpreter frames on the actual call stack
14:14:27
drmeister
FORWARD(xxx) is a better name for SMART(xxx) - they are equivalent and what you are really doing is creating a forward definition.
14:28:53
Bike
well, that, but i also meant BacktraceEntry versus the vectors that are actually passed to lisp.
14:30:22
drmeister
Oh - so get rid of BacktraceEntry - that's going to take a bit more work. You want to just have the CL exposed backtrace frame?
14:31:33
Bike
using the pseudo defstruct :type vector makes no sense when we're working in C++ anyway, right? We can just have a C++ class