libera/#clasp - IRC Chatlog
Search
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
3:20:31
drmeister
This is the backtrace for the TagbodyEnv destination - the same function (of course)
3:22:23
drmeister
This is on the stack when the UnwindProtect that it unwinds to is put on the stack