14:25:11drmeisterI'm still working on the static analyzer
14:25:46drmeisterI'm now hacking the clang ASTMatcher code, putting print statements into it to print addresses of internal data structures to try and figure out what is going on.
14:26:20drmeisterWe set up clang ASTMatchers from Clasp Lisp and they look like they get set up fine but then all of a sudden they are corrupt.
14:26:44drmeisterIt looks like a wild pointer stomping on an clang internal data structure.
14:27:04drmeisterWith udb I should be able to identify what is doing the stomping as soon as I figure out exactly what is being stomped.
14:27:52drmeisterI am hacking my own copy of llvm14 and it is installing itself in /opt/llvm14 - we used to use that before llvm14 was available.
14:28:14drmeisterIf you start seeing weirdness, check that you aren't building with /opt/llvm14/bin/llvm-config
14:29:04drmeisterThis is slow and painful debugging. I'm just so glad that we have udb and that I've learned how to work around it's slow debug registration.
14:30:17drmeisterBike: I really want compile-file semantics working in the bytecode compiler. The less judiciously chosen compiled hot code we have - the faster udb will be able to work with it.
14:30:48drmeisterAt its peak clasp had about 14,000 compiled object files.
14:31:44drmeisterIf we can get that down to a few hundred or thousand and the rest is bytecode (with compile-file'd bytecode) then udb will be able to work with it better.
14:33:33yitziSo shipping bytecode in the image ... or do you just mean during load-cclasp?
14:35:07Bikeshipping bytecode should be fine, but i'm more worried about making the bytecode compiler normally accessible
14:35:11Bikesince it does like zero error handling
14:37:09Bikethat can be fixed, i just mean i wouldn't want to do it right now
14:41:47Bikeunrelated: i'm seeing if i can't figure out bytecode wrappers for methods now but this code is kind of confusing
14:42:00Bikeit kind of looks like we have the exact same class definition repeated twice? in wrappers.h?