20:22:54Bikeit's probably going to be more involved
20:23:02kpoeckat the end of the ansi-tests t prints as #:t, weird
20:23:35kpoeckI thought i is by a direct unintern, but no, must be something more complex
20:25:22Bikesbcl has a whole manual chapter http://sbcl.org/manual/index.html#Package-Locks
20:26:09drmeisterkpoeck: Oh - sorry (unintern t) - got it.
20:26:49drmeisterBike: It doesn't know it is invalid - I think it fails while loading the bitcode. I've never been able to do anything with a bitcode file that includes bad bitcode.
20:28:42drmeisterI don't know if it's the validator or the linker that is having a problem and if it's the linker I don't know if the linker is crashing. All I know is that I see that error message when I try to load bitcode files that have bad llvm-ir into any tool.
20:35:10ShinmeraColleen: tell drmeister look up staple
20:35:10Colleendrmeister: About staple https://shinmera.github.io/staple#about_staple
20:46:51karloszshould i be defining primops for new ast nodes i introduce? i see that clasp doesn't really do that
20:50:07karloszso i was thinking over the approach you suggested yesterday
20:50:23karloszwhich was to return the ast in function=info
20:50:48karloszis there a disadvantage to just writing compiler macros instead and returning the right source form instead?
20:51:09karloszthat way i won't have to make the ast's myself, and i can do the &rest inlining
20:51:22karloszare compiler macros guaranteed to expand?
20:51:43Shinmeracompiler macros are prohibited from expanding if the function is declarednotinline
20:53:04karloszhm... do you think it would be reasonable to punt to the default, slower bytecode sequence if a user explicitly declares something like print notinline?
20:54:00karloszim not quite sure when someone would explicitly declare a standard CL function notinline
20:54:14karloszor what an implementation is expected to do with it generally