14:07:20drmeisterThe *load-print* is being turned off early
14:07:54Bikemade some fixes, now it's complaining about a stack overflow
14:08:25drmeisterFYI clasp/src/lisp/kernel/init.lisp is also being loaded right at the start - that was turning off *load-print*
14:08:27Bikeit doesn't look like an infinite recurison to me, but it's hard to tell because as soon as it tries to print a bytecode compiler environment it crashes, because they're full of circularities
14:08:35Bikedo we have print-circle? i guess we probably do
14:09:26Bikeok yeah that fixed the segfaults, great.
14:10:25drmeisterOk, then if you want to evaluate things a little more slimey you can use M-x run-lisp and give it iclasp-boehmprecise -I -f clasp-min -l loader.lisp
14:19:17drmeisterSo let's comment that out for now - it's unnecessary anyway.
14:19:47drmeisterThen go one failed expression at a time.
14:20:27BikeAlright, so with that done i can see it gets all the way to... uh... itself, actually, to bytecode-compile.lisp
14:20:52BikeBut it can't handle itself since I guess LOAD uses its own macrolet environments?
14:20:59drmeisterEdit cmprepl to set *implicit-compile-hook* to the bytecode compiler/interpreter, hit a problem, unset it, load- that code and then try and bytecode compile and run it.
14:21:04BikeSo I suppose I need to translate that into a bytecode compiler environment
14:21:35drmeisterI guess you need to add bytecode environments to load?
14:21:46drmeisterWe did that with cleavir environments I recall?
14:22:15Bikei already hooked bytecode environments into macro-function and stuff, but in this case it's load _constructing_ an environment and passing that to the bytecode compiler, rather than the other way around