libera/#clasp - IRC Chatlog
Search
16:15:40
drmeister
Yes, we only need the wrapper if we have a non-trivial lambda list. We can do the trick I did with functions and bypass the wrapper
16:19:13
drmeister
.def(core::names_("LLVM-SYS:TYPE-GET-POINTER-TO","LLVM-SYS:TYPE/TYPE-GET-POINTER-TO"),&Type_O::getPointerTo,R"lambda(((self llvm-sys::type) &optional (addressSpace 0)))lambda",R"decl()decl")
17:21:14
Bike
but barring that, i did at least delete all the baclasp and interpreted closure stuff fine
17:33:24
Bike
there's a few references to it still, but they're never actually used. i could comment them out though
17:35:07
Bike
this is still in the vm-sans-interpreter branch, since i don't want to mess with whatever drmeister is doing
17:37:16
yitzi
Yeah, I was talking about the vm-boehm branch. I'm sure it can wait. I'm working on some stuff there b.c. it is mostly orthogonal to drmeister's debugging. I move to a different branch if needed.
17:39:50
Bike
alright, outright removing the bclasp-compile symbol goes fine, so i'll commit&push this in a minute
17:42:46
Bike
yeah, but when i'm ripping out parts of the runtime and compiler i tend to do clean builds just to make sure things aren't only working by inertia
17:43:53
yitzi
Its more intelligent then the incremental logic on main. For example, if the load order is A -> B -> C and the source file for B changes, then it invalidates the faso of C.
18:08:34
yitzi
Yep, just found that. Seeing if I can use that during stage loading for cando. Thanks.
18:08:50
Bike
we may want to coalesce some of these control variables together... we also have implicit-compile-hook
18:12:29
yitzi
Looks like most of those get set in auto-compile.lisp which is loaded before the end of the stage. I wonder if skipping that file and setting that stuff in the stage terminator file would be better.
18:25:26
Bike
auto-compile is definitely written with the "building means loading these files in this order" ethos in mind
19:39:04
drmeister
I pushed the changes to get bytecode frames with arguments in the python extension.
19:39:52
drmeister
The important thing is: I pushed the changes to get bytecode frames with arguments in the python extension.
19:59:38
Bike
so i can get clos to use cleavir except it keeps recursively compiling for reasons i don't really understand...
19:59:51
Bike
it looks like it builds fine if i put ina kludge to not compile recursively, but that's a kludge
20:04:27
Bike
i sorta wonder if we shouldn't just work out something more sophisticated than COMPILE_TRIGGER anyway... i feel like it'll get a bit weird with concurrency
20:05:17
drmeister
Maybe - the _TheEntryPoint's are atomic - we should be able to CAS them in safely.
20:05:52
drmeister
Bike: I'm trying to get the bytecode system before loading cleavir to be more stable.
20:06:35
drmeister
If it signals an error and goes into the debugger and I use a :R1 restart it segfaults apparently when it's trying to unwind the stack.
20:06:41
Bike
man, i'm so confused here. i don't see how we would possibly ever compile the same discriminator twice... or wait... what happens if there's a miss...
20:26:30
Bike
i think the call counts increase monotonically. that's bad, becuase of the miss thing, but also good for avoiding the ifninite recursion, except that's still somehow happening anyway.
20:35:33
Bike
i think i need to consider this for a while. i kind of figured that would be the case but i was hoping for once it would just work
21:15:36
Bike
ok so on further examination, the problem is _not_ an infinitely recursive compilation loop
21:16:00
Bike
but that means i don't know what it is, and it's still doing the nested error thing, so i think i'm going to wait until i can use the python debugger scripting thing to get a backtrace i can understand
21:19:57
Bike
it might also be possible for us to coordinate things with the compiler to stuff more info into dynamic environments, at least in cclasp. like source locations and block names and stuff.
21:21:03
drmeister
Sounds good. It's easy enough to expose them in the boehm build and they are automatically exposed to the python debugger extension in the boehmprecise build.
21:22:01
drmeister
That's used when we run the boehm build. The boehmprecise build constructs this python code from the static analyzer output.
21:25:59
Bike
do you know why the actual segfault is happening? is it longjmping to an expired buffer?
21:26:27
Bike
the slime thing was weird in that it would segfault, but then i could resume from _that_ and continue using the slime repl normally
21:31:19
drmeister
There are a whole bunch of sjlj_unwind's one after another and then it fails on one.
1:51:56
Bike
i did a quick survey of interpreted gf calls, since i have the compiler totally disabled, and man is the distribution skewed
1:53:34
Bike
if you take only functions that have actually been called, it's 504,926 and 9490 respectively
2:03:25
Bike
man, so if compiling it shaves a millisecond from each all, that's twenty five seconds... which sounds impressive until you remember how slow the compiler is
2:37:51
Bike
this is why i mentioned compiler coordination earlier- as is there's very little, but if you want to keep doing this kind of debugging it'll make things a lot less painful
3:04:58
drmeister
I printed the DynEnv stack on the left at the start of the sjlj_unwind and the DynEnv stack after the first proceed.
3:09:51
Bike
also, i wonder if we should find some way to coalesce bindings, but that's not important