libera/#clasp - IRC Chatlog
Search
15:30:06
drmeister
Running under the debugger is very, very slow for several reasons. Part of why I wanted to debug running with bytecode.
15:36:56
Bike
how about this - i push my code with the conditionalization, which breaks either way, and then i go work on some stuff i have in mind to maybe improve the stack pointer handling
15:37:57
drmeister
I'm trying `ninja -C build load_cclasp-boehm` and then `(cmp::compile-file-serial "SYS:SRC;LISP;KERNEL;LSP;CLTL2.LISP")`
16:05:08
drmeister
Rather fork and the stack guards are not compatible. I'll have to think hard why that is.
16:11:52
drmeister
Bike: So - I pull your changes - then I edit bytecode_call and turn on the funwind_protect?
16:26:36
drmeister
Bike: I pulled your changes, set #if 0 to #if 1 in bytecode_call and I'm building.
16:31:55
Bike
so what i'm doing now should have the same effect as the unwind protect without actually doing one, hopefully
16:34:02
drmeister
yitzi: If I want to run the static analyzer just on clasp - and not pull in cando - is there a way to do that?
16:37:46
yitzi
If cando is included in the koga line it is included with the static analyzer. Otherwise not.
16:50:43
yitzi
If you guys can fix this issue I think we should run the analyzer on clasp and then stop there. The cando build is much better on vm-boehm-simp.
16:57:25
drmeister
It looks like it's working fine `In on-start-of-translation-unit for file 11 of 177`
17:47:47
Bike
with the sp change the vm runs for a while until it dies on some pretty normal looking code. egh...
17:48:23
Bike
are the python scripts to get better udb backtraces of bytecode well enough along to use?
17:48:48
drmeister
If you want to turn the guards on to catch stack overruns - go into the VirtualMachine ctor and dtor and uncomment the code.
17:50:17
drmeister
It will segfault - but in a clean way, right away when it tries to write into the guard.
17:58:42
drmeister
I should give you a primer on the debugger extension - I added a lot of features this weekend.
20:48:21
Bike
it looks like it works if i update the vm sp on normal returns. i do not understand why, though...
20:50:39
Bike
i guess what must be happening is we return from a bytecode function, and then a different bc function is called, but without a call instruction to update the vm sp
20:51:06
Bike
which i guess could happen if we have a native function that calls distinct bc functions.
21:42:57
drmeister
It's currently crashing on the first file and `./analyze` runs koga and rebuilds everything.
22:49:58
drmeister
It's dying deep in the static analyzer - I'm guessing when it's about to call the callback.
23:07:04
drmeister
It's failing in this function: clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchWithFilter(clang::DynTypedNode const&)
0:10:34
an_origamian
*All* C++ code that wants to interact with clasp must use waf? (as described here: https://clasp-developers.github.io/clbind-doc.html)
0:10:42
an_origamian
If that is the case, is that code required to be licensed under LGPL like clasp is?
0:22:13
an_origamian
I am also unsure where that directory structure at the top of the page comes from since I don't see that in the repo or in my filesystem (I installed from AUR).
0:23:45
yitzi
To use clbind you need clone from github and follow the instructions in the wiki to build. We no longer use waf, so the clbind documentation needs to be updated.
0:32:29
yitzi
I don't believe so. Pretty sure we don't currently have the ability to dynamically add extensions, therefore they are linked directly with the clasp binary.
0:33:30
yitzi
You are already using the AUR version which is building from scratch. Building on AUR is easy. That is my base OS and I wrote the AUR and new build system.
0:39:51
an_origamian
So that would imply that any C++ I write that extends clasp must be licensed under LGPL?
0:42:17
drmeister
No, C++ that extends clasp will link with clasp - it doesn't need to be licensed under the LGPL.
1:17:32
Bike
on further reflection i think to avoid the unwind protect we may need to set the stack pointer in the unwinder itself
1:46:09
Bike
that's more closely analogous to the native unwinder... but also there's no real way to inform it... bleh
1:47:09
Bike
i guess i could define a new dynenv class specifically for vm frames, that just records the frame pointer to unwind to
1:47:41
Bike
then the unwinder can do that without going through longjmp. so we'd still be stack consing dynenvs and all, but it would at least be somewhat cheaper than an unwind protect dynenv