freenode/#clasp - IRC Chatlog
Search
12:51:31
scymtym
::notify charles323 that is/will be possible with https://github.com/scymtym/language.c
15:42:43
Bike
well, the only place swank actually uses locks directly outside of implementation code is gray streams
16:18:36
Bike
drmeister: so i can get lisp frames in lldb, right? i don't think i'm getting any right now?
17:26:59
Bike
and i think i have... a little insight into the recursive lock thing? i don't really get it though, it has call-with-lock-held calling call-with-lock-held, which is not reflected in the source
18:02:18
drmeister
No - calling clasp functions from lldb is screwed up - it's a constant source of frustration.
18:13:52
drmeister
clasp/src/profiler/symbolicate.lisp is an sbcl script that you can run a backtrace from 'bt' through and provide the /tmp/perf-<pid>.map file and it SHOULD generate symbol names.
18:14:56
drmeister
It worked when we used dynamic libraries. Object files and faso-files don't work with the operating system backtrace_strings(...) facility.
18:16:06
drmeister
Getting access to function arguments is trickier. They are spilled into the stack frame - we have to find them using stackmap information that we need to write out to /tmp/perf-<pid>.map and then use the new Python object introspection tool I developed to get arguments.
18:16:29
drmeister
Once we get all this working we will have a way to generate backtraces from lldb that are absolutely independent of clasp code working.
18:16:49
drmeister
I have a plan - I just need time to implement it or to show you how to implement it.
18:22:51
Bike
putting the lambda lists in for anonymous functions works but it keeps stuff like default values for &optional that we don't really care about
18:36:31
drmeister
But I won't get very far because I need the value slot - and the thread-local symbol value stuff. Ugh.
19:31:09
drmeister
It's a problem when calling into the clasp code if there is a bug that breaks the clasp code.
19:33:06
Bike
this problem looks like a recursive deadlock, but i can't actually get a backtrace at crunch time
19:39:25
Bike
and then they renamed it call-with-lock-held despite that it didn't stop needing to be recursive!
19:42:28
Bike
alright. alright. then either we fix slime or just go with the flow and make it be a recursive lock
19:44:11
Bike
drmeister: while we're at it - mp:make-lock and mp:make-recursive-mutex take an optional and key parameter respectively - but if they're not provided there's an error saying you can't have a lock named nil
19:48:52
Bike
it's not a big deal, it's just kind of weird to have an &optional parameter, and then if you don't actually pass anything you get an error
19:55:12
Bike
whatever. drmeister, minor slime fix - on L715 of clasp.lisp, change (mp:make-lock :name name) to (mp:make-recursive-mutex name)
20:06:24
Bike
ok. so yeah. and i did the lambda backtrace thing no problem except we might want to store two kinds of lambda lists - one with default values like for slime display, and one without
20:06:38
Bike
either that or get the latter from t he former, but that's work, and difficult work to do in C++
20:11:11
Bike
like (ext:function-lambda-list (lambda (&optional (x nil x-p)) ...)) => (&OPTIONAL (X NIL X-P)) but the X-P isn't really needed
20:24:56
kpoeck
drmeister regarding the defcallback fix, you fixed that for the parallel compiler, correct?
20:24:57
Colleen
kpoeck: drmeister said 18 hours, 31 minutes ago: I think I have defcallback working again.
20:27:15
kpoeck
I get errors like "Constructing call to intrinsic to_object_unsigned_long - mismatch of arg#0 value[#<ARGUMENT@0x7feb094e80b0 i64 %A>], expected type #<INTEGER-TYPE i64> - received type #<TYPE i64>"