libera/#clasp - IRC Chatlog
Search
13:11:51
yitzi
Bike: Do you know how STREAM-LINE-COLUMN, etc are getting exported from GRAY? I found an export statement for the classes in kernel/lsp/packages (its missing the base classes like FUNDAMENTAL-STREAM) byte I can't seem to find the export for the generics.
13:12:53
yitzi
Additionally, why is this needed? https://github.com/clasp-developers/clasp/blob/6397b56a8e27c38b0eac87cf986b7924e05f7168/src/lisp/kernel/clos/streams.lisp#L743-L747
13:17:25
yitzi
Ok...so the export is happening in C code... the second question still stands though.
13:48:39
Bike
https://gitlab.com/embeddable-common-lisp/ecl/-/commit/82aef0f69ed5489f081d533cf93d58b0564588e0 yeah, this doesn't seem like a good idea to me
14:06:12
Bike
in order to get good backtraces with source info for bytecode, i think we need to be able to pick out bytecode_vm frame and find their C++ arguments
14:06:21
Bike
not sure if that's possible without stackmaps, and not sure how we would get stackmaps
14:09:18
yitzi
Yeah, I removed the re-export of the CL symbols. Everything seems fine. I can't imagine anybody using it that way since everybody imports COMMON-LISP themselves.
14:20:52
Bike
alternately, we could rely on bytecode_vm itself not signaling errors, and just look through the VM call stack, maybe. but i'm not sure how it would be combined with the machine call stack.
14:24:10
Bike
because i have a scheme in mind for how to record source info for bytecode, so sldb v would work, but it's useless if we can't get it in the debugger.
19:00:57
Bike
tried a flame graph for the bytecode swank load - works fine. i don't understand the results, though. says it's spending a lot of time in dispatch miss, but i don't know why it would be taking the slow path. kinda worrying!
23:04:35
Bike
think i managed to shave about a second off the bytecode slime startup with a small rearrangement of the fasl format. so i'm feeling optimistic about further optimizations.
23:46:26
cracauer
Wait, the right dir already is in llvm-config14 --ldflags but the build seems to ignore it.
0:08:15
Bike
but there's also an underlying issue of everything dispatch missing for some reason, so i'll probably have to dust off the fastgf log
0:08:39
Bike
and maybe come up with something more focused. it would probably be helpful to tell _some particular gf_ to log dispatch miss stuff. i'll probably try writing that
0:09:15
Bike
debug-fastgf was basically written for debugging fastgf as a whole, so it's probably not good for performance telemetry