freenode/#clasp - IRC Chatlog
Search
3:50:11
drmeister
Actually, most of them don't need to be redefined - so we could do something more compile-timey
4:21:45
drmeister
Whew - I ran into a subtle problem. When xtracting lambda lists from pointer signatures - variable's named 't' caused problems.
4:36:53
beach
The CST-to-AST system seems to work for computing all the phases of the SICL boot procedure that I have implemented so far.
4:52:31
drmeister
https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/cleavir/translate.lisp#L1155
12:44:24
drmeister
Bike: Is it possible to have call-with-variable-bound lambdas named as such? using (declare (core:lambda-name call-with-variable-bound.lambda))? By changing Clasp code - without adding implementation specific declares?
13:12:23
Bike
on t he other hand, i made it so that the call runs through convert, so there could be a compiler macro on c-w-v-b to annotate it
13:13:19
Bike
on the third hand, it might not be unreasonable for cleavir to have a named-lambda extension, since it's common and useful, and i think it could maybe be done while allowing ignorant code walkers
13:13:30
drmeister
It appears that nothing that I've done over the past several months has moved the build time by even one minute. I am supremely frustrated.
13:16:14
drmeister
Since profiling and backtraces are useless without JITted code symbols - I'm writing a 'symbolicator'.
13:16:51
drmeister
Clasp now writes out JITted symbol info to a file like... /tmp/clasp-symbols-20942-Qix1CS
13:17:44
Bike
also, you said you added direct calls, but did you add LTO earlier in build? if not, it would only affect the final image, right?
13:18:52
drmeister
You are correct - you can't get full benefit of direct-calls without LTO linking all of the C++ bitcode to whatever calls it.
14:00:11
drmeister
(symbolicate-buffer "hello there 0x10DC13211 this is a test" *standard-output* *s*) -->
14:01:32
drmeister
Anything containing multiple 0xYYY strings will have those 0xYYY strings converted to symbol names if they exist in the symbol table.
14:23:24
drmeister
I define these three methods that call each other - and the last signals an error
14:28:08
drmeister
The core::FuncallableInstance_O::entry_point(...) is mine - that's a level of indirection that we can remove.
14:28:56
drmeister
The #<POINTER ...> I'm not sure where those are coming from. They aren't in the symbol table obviously.
14:36:08
drmeister
It should be cc_dispatch_effective_method but I don't understand why it doesn't have a symbol.
15:45:33
drmeister
If I compile-file this... (defmethod foo () (bar)) (defmethod bar () (baz)) (defmethod baz () (error "in baz"))
15:49:44
drmeister
It doesn't look too bad after that. I can single step instructions from the start of FOO to BAR and it's not too bad, if a bit difficult to follow (probably because of optimization).