freenode/#clasp - IRC Chatlog
Search
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
14:35:34
drmeister
There is one issue. If the system is really screwed up - then we won't be able to allocate memory and a C++ class allocated on the heap could give trouble.
14:36:04
drmeister
With the BacktraceEntry we can still squeeze out a backtrace under a wider range of conditions.
14:49:32
Bike
if GC allocation is broken I don't think we can do much more than print something and die.
14:51:51
drmeister
We need to expose the stackmaps info so that the lldb python stuff can find spilled arguments.
14:55:12
Bike
What I want to support here is a normal debugging experience, basically. If we have to assume that nothing is reliable and up is down it will make the code and the debugger worse.
16:04:47
Bike
so cool fact, if an error is signaled in '-I -n' mode clasp dies because backtrace-frame-fix-names doesn't exist
17:14:35
Bike
i'm getting a bunch of errors i don't understand from gc_interface.cc and stuff saying that my new class is an incomplete type. It looks like it only sees the forward declaration.
17:18:23
Bike
i mean, i guess what it's actually going off is a forward declaration the scraper put in, but i don't know why it doesn't have the actual definition
17:37:02
jackdaniel
Bike: what clasp does? https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/194 (also, do you have an opinion about gf congruency with this regard?)
17:40:10
Bike
so what this does is have an &allow-other-keys in a generic function mean that any keys are allowed in the methods?
17:41:28
jackdaniel
that is what standard says, but this commit is about something else (please see the commit message in the first one)
17:42:01
jackdaniel
methods are obliged to have all keyword arguments as defgeneric has (plus possibly some more if &allow-other-keys is specified in either)
17:42:41
jackdaniel
this change makes it so that method doesn't have to have all keys mentioned in defgeneric if said defgeneric has &allow-other-keys
17:48:31
Bike
with changing the behavior. it's a pretty small thing. i suppose that going off the logic in 7.6.4, what i'd actually expect is... if a generic function specifies &allow-other-keys, each method has to have &allow-other-keys or &rest, so it can accept any key
19:17:03
kpoeck
try https://github.com/clasp-developers/clasp/wiki/Road-to-clasp-with-lvm@9, just tried to update them
19:18:23
selwyn
i am trying to implement bignum arithmetic by defining virtual functions in the class Bignum_O derived from Integer_O e.g. Bignum_O::shift_
19:19:59
selwyn
gdb is telling me that an Integer_sp has no vtable, which causes a segfault when i try to call one of these methods, so i am wondering if there is some initializing step i am not doing
19:20:20
selwyn
as far as i can tell allocating using GC_ALLOCATE should be fine? it calls the constructor?
19:22:32
Bike
maybe i'm not understanding something. bignum.cc already has a shift_, right? you're just replacing it.
19:44:19
Bike
and i tracked down the "#<FOO >" thing and it turned out to be sillier than i thought so i think i can just remove that problem
19:53:20
clasper
https://github.com/clasp-developers/clasp/wiki/Road-to-clasp-with-lvm@9, seems to be empty?
20:30:13
Bike
there's no reason we can't get t he lambda list for a function in the backtrace... so we can back construct the actual argument bindings, rather than using cl-user::arg2 and such
20:35:28
Bike
eval-in-frame does funny things for what are probably supposed to be method calls, oh no.