libera/#clasp - IRC Chatlog
Search
18:25:03
Bike
it still uses lambda list handlers... in a way that can be replaced, but it'll be a little messy
18:41:02
yitzi
Bike: The new list is here https://github.com/clasp-developers/clasp/blob/vm-boehm/src/lisp/cscript.lisp
18:46:55
drmeister
Bike: What direct-calls.lisp did will be replaced with the bytecode wrappers. The BytecodeModule_O will carry the form that generated the bytecode wrapper with them and we will be able to compile them to native code at any time simply using COMPILE.
18:47:28
drmeister
bytecode wrappers will be considered (compiled-function-p #'bytecode-wrapper) -> NIL
21:05:31
drmeister
There is `(defun print-object (object stream) (print-unreadable-object (object stream) ...))` in kernel.lisp
21:07:47
drmeister
Now that I put the question to words I realize I should add a method for what I really want to print, which is wrapped-pointer
22:54:28
drmeister
We got bit by the worst C++ interop problem. A C++ wrapped object went out of scope when it shouldn't have, got finalized and then a use after free.
23:00:26
karlosz
i thought about how to do the local GO/RETURN -FROM thing some more actually and i think its probably going to be better to just focus on making vm_enty and vm_exit faster by reworking the dynenv represntation like we were talking about
23:01:01
karlosz
that has the bonus of improving cclasp performance as well as fundamentally removing ocnsing for a whole bunch of stuff in the bytecode compiled coe
23:01:22
Bike
I did not. I was mostly doing that to try to lose the funwind protect rather than for efficiency, but then i already had it written up, sooo
23:05:22
karlosz
i just figured if its not too difficult we could improve a lot of things more generally by making entry not cons
23:06:57
karlosz
to just do the specila case of no-exit entry elision is just anotherfixp class. i mean its already kinda there with the borken optimization in the reference compilerat the moment
23:07:16
karlosz
(which should probably get reverted since special bindings don't work with itbecuase of a lack of appropriate local unwinding)
23:26:49
drmeister
I think I've got the static analyzer working again. We should look into getting the sanitizers working.
23:29:59
drmeister
(1) Very complicated code (2) segfault deep in clang ASTMatcher code (3) object quietly went out of scope and was garbage collected (4) use after free
0:22:18
drmeister
yitzi: I got this when I tried to run the analyze script - does it tell you anything about what could be wrong? I thought I unwound all of my hacks to debug this problem...
0:27:51
yitzi
I would skip the analyze script for now. I'll run on the vm-boehm-simp branch after you push. I don't think the cando build is working on vm-boehm
0:31:15
yitzi
you don't need the analyze script....that is for automating the analyzer on clasp and then doing the same thing on cando.
0:32:24
yitzi
The idea behind the analyzer script is to avoid dirtying your working tree with a cando build when you are working on clasp. It builds everything in a separate directory, first clasp, then cando.
0:44:36
yitzi
You can run `ninja -C build analyze` in a completely bare clone and it will everything you need. :)
0:48:53
drmeister
I don't know if it's possible with a garbage collector and our own code generating compiler
0:52:29
yitzi
Ok....well I stuck it in koga in any case...so that is a start. https://github.com/clasp-developers/clasp/blob/61d776cf9a753c9c85c7aa34b1cdc02c3299e05b/src/koga/units.lisp#L205-L207
1:26:39
drmeister
We need the sanitizers because nobody is going to have the patience to debug something like this.
1:34:24
drmeister
Bike: There is an issue though - I actually started trying to debug the static analyzer problem just using bytecode. When I `ninja -C build load_cclasp-boehm` it dies trying to unwind from the first error.
1:35:25
Bike
i mentioned it earlier, but i have something that should be cheaper than the unwind protect
1:36:01
Bike
i'm not sure how to do it that way correctly. i think the unwinder needs to know about bytecode frames some way or another.
3:21:30
drmeister
I'm building cclsp-boehmprecise in my local vm branch now that I merged vm-boehm into it and once it's done I'll push.
3:38:36
Bike
nice, and the analyzer works and all? ok. tomorrow i can merge in all the code deleting i've been doing, and the funwind protect replacement
3:46:52
drmeister
Building cclasp-boehmprecise builds like vclasp-boehmprecise did. It loads everything in as bytecode and then compile-files everything.
3:47:42
drmeister
I have turned on the funwind-protect thing in bytecode_call so that I don't have to worry about VM issues.
3:57:38
drmeister
There is still a problem with the bytecode compiled code. It I `ninja -C build load_cclasp-boehmprecise` and then evaluate `(error "foo")` and then use `:r1` restart - it segfaults.
3:58:26
drmeister
This is where it does `sjlj_continue_unwinding` when the dynamic environment that it is unwinding to has already been removed from the dynenv stack.
4:00:26
drmeister
Let's look at it tomorrow. It doesn't break anything other than the idea of doing everything in bytecode.
4:04:24
Bike
yeah i was actually wondering how the funwind protect would have fixed that, since all it does is fix the stack pointer