freenode/#clasp - IRC Chatlog
Search
15:53:24
Bike
so although it seems like backtraces are going to be a mess for the forseeable future, we ought to come up with a stable interface for accessing the information.
15:55:15
Bike
so that we don't have to push a new commit to slime every week when some llvm change renders our previous approach futile, that sort of thing
16:24:11
Bike
for each frame we should at least have readers for let's seee... the function, the arguments, local variables, source location
16:24:45
drmeister
And you'd like them to be copied and prepared so that users can access these things without touching pointers.
16:25:29
Bike
yeah. like right now the frame-source-location in slime is basically ext:code-source-position of core:backtrace-frame-return-address. not too hard to pack into a function, so that we only mess with pointers interanlly
16:26:04
Bike
what i'm not sure about is whether to represent frames as actual objects (though we do need objects) or as indices into the stack, but that's what you've been changing with ihs-top and such
16:28:25
drmeister
How about you design a good API and we can create the CLASP-DEBUG package to put the functions within.
16:29:45
Bike
including foreign frames seems fine, though we should maybe retain some options to skip them
20:14:01
Bike
drmeister: https://gist.github.com/Bike/596457ed1105a25754c1d275b7cf5b82 start of a debugger interface. See anything obviously stupid?
20:17:10
Shinmera
Bike: the one thing missing from this is also what's missing from Dissect, namely eval-in-frame
20:17:33
Bike
yeah, i mentioned at the end i don't think we can actually unwind to the frame correctly
20:18:17
Bike
i was also wondering if dissect shouldn't have access to local variables in addition to arguments, but i figured i should fix the beam in my own eye first
20:18:59
Bike
sldb has a restartable-frame-p thing, which is fine, but i'm not sure we can do it with any frame at all
20:28:01
kpoeck
regarding the debugger interface, what about `(ext:btcl)`? I also use `(ext:ihs-argument ...)`a lot
20:28:46
Bike
honestly i was mostly thinking about the low level interface, and reading on the debugger in top.lsp
20:31:40
Bike
well, that's the low level for it yeah. you're right that there should be something for it in the actual debugger.
20:36:37
kpoeck
I played a bit with portable aserve (in the version from https://github.com/gendl/aserve)
20:45:13
Shinmera
I can't even test my stuff on LispWorks cause even the latest free copy of it just crashes on start on my machines :shrug:
20:47:00
kpoeck
Martin from lispworks said at last els ("We should publish a new personal version"), but wasn't a real promise
21:54:07
Bike
to actually implement this, i could put it on top of the existing structures, but that's yet more redundancy and also doing CLOS things would be hard for debugging build problems
21:54:37
Bike
should be able to just have the fields of the vector frames like now, though maybe we should lose one of the name fields
21:56:26
Shinmera
If you want to be forwards compatible I suppose you could just say that FRAME is a type, rather than a class, and give no further promise about what you can do with it aside from handing it to the protocol functions.
21:57:33
Bike
well, i think we should make it a class but not necessarily allow subclassing or anything like that
21:57:46
Bike
what we have for frames now are basically a defstruct :type vector, which isn't even a type
21:59:26
Bike
i suppose i can't think of many applications where you'd want to specialize on a frame class