libera/#clasp - IRC Chatlog
Search
13:16:44
Bike
so far today i've just been frustrated trying to sign into kronos, but yeah, hopefully can try putting it in clasp now
13:27:01
Bike
which i thought i was having trouble starting, but i guess you need to do -I -n and not -In
13:36:24
drmeister
You might want to also add -f clasp-min. There is stuff in that code that is available only when loaded the first time.
13:38:26
Bike
stopped almost immediately because it can't find set-documentation, wtf... i'll try clasp-min
13:46:41
Bike
it was trying to bytecode-compile the definition of with-interpreter in cmprepl, i think.
13:48:21
Bike
the cmprepl-bytecode i'm using is pretty much like yours, cept with-interpreter i guess
13:49:36
Bike
pushed to vm. it's bytecode-compile.lisp and cmprepl-bytecode.lisp. but as mentioned this typecase thing will kill them
14:08:25
drmeister
FYI clasp/src/lisp/kernel/init.lisp is also being loaded right at the start - that was turning off *load-print*
14:08:27
Bike
it 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:10:25
drmeister
Ok, 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:11:07
drmeister
I think <Shift>-<Enter> on a form in a buffer will pass that form to the run-lisp *interactive-lisp* buffer
14:11:17
Bike
the backtrace says that (var-info nil [an environment]) somehow immediately calls bytecode-implicit-compile-repl-form, which seems nonsensical
14:12:16
drmeister
Once you install (setq *implicit-compile-hook* 'bytecode-implicit-compile-repl-form)
14:12:53
drmeister
If you leave *implicit-compile-hook* alone - then you can use the clasp interpreter to evaluate things.
14:13:50
Bike
i mean, it's saying that the function var-info somehow calls the implicit compile hook
14:16:58
drmeister
I would turn on *load-print* and load the source code and see what expressions cause it to fail.
14:17:37
drmeister
Then don't load cmprepl-bytecode.lisp and bytecode compile that last expression in a run-lisp session.
14:20:27
Bike
Alright, so with that done i can see it gets all the way to... uh... itself, actually, to bytecode-compile.lisp
14:20:59
drmeister
Edit 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:22:15
Bike
i 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
14:22:57
Bike
well, it's fine, i can translate a clasp macrolet environment into a bytecode compiler one, as long as there are a few basic accessors
14:24:19
Bike
actually i really don't understand what's even making this macrolet environment, so let me find that first
14:26:40
drmeister
~/Development/clasp-vm/build/boehmprecise/iclasp-boehmprecise -I -f clasp-min -l ~/Development/clasp-vm/bloader/loader.lisp
14:26:48
Bike
i see, and eval-with-env-hook goes to t1evaluate, so it will try to do its own thing with toplevel forms before dropping to the implicit compile hook
14:27:45
Bike
so either i translate interpreter environments, or maybe i can just replace eval-with-env-hook? is there a reason i shouldn't?
14:30:39
drmeister
If you want to use udb later I can show you how to set some environment variables and then run emacs so that clasp generates debugging information for udb.
14:30:45
Bike
like what would happen, exactly? it seems like binding implicit-compile-hook means using the bytecode compiler for almost everything to begin with
14:31:32
drmeister
I don't know why load isn't working right now - where is it setting up an environment?
14:33:23
Bike
so t1evaluate sets up a macrolet environment, and then passes it to implicit-compile-hook, and bytecode-compile can't deal with it
14:34:07
Bike
other than turning off the switch in init.lisp and using eval-with-env-hook that's the code i have
14:36:40
Bike
if we replace the interpreter with the C++ bytecode compiler, of course, the macrolet thing won't come up since there won't be macrolet environments any more
14:42:13
Bike
it's in macrolet, where it's recursively compiling itself, so maybe that somehow is a problem
14:58:51
drmeister
To make udb more convenient run iclasp-boehmprecise from the clasp top level directory
14:59:55
drmeister
That will automatically connect udb to clasp and clasp will have generated debugging information for the udb extension I wrote.
15:00:19
drmeister
Also the CLASP_DONT_HANDLE_CRASH_SIGNALS=1 will put you in the debugger immediately when a crash happens rather than in the crash handling code.
15:33:17
Bike
looks like it's in the middle of call-receive-one, doing the funcall, when it segfaults
15:34:24
Bike
i think i'm giving it an untagged function_O pointer? so i guess it would have problems
15:35:51
Bike
if i do `lprint 0x55a520df42b5' that should be a tagged general, right? given that the untagged pointer is that but b4
15:41:51
Bike
if we do want to ue this bytecode compiler more comprehensively we will have to really improve its debug generation
15:49:51
Bike
ok. the problem is not that the function is not tagged. the problem is that the function is somehow the symbol progn
16:06:24
Bike
oh, we're still compiling local jumps as exits. that's gonna be the next efficiency problem after cells
16:28:56
drmeister
Look at register and pointers and get a sense of what are real pointers and what are not.
16:31:29
drmeister
The 0x55...5 has a tag #b101 - that's VASLIST0_TAG - hmmm - ok. What does RSP look like? Does it start with 0x55...?
16:38:04
karlosz
Bike: what is the efficiency problem with local exits? what can be done with less work when its local?
16:46:32
Bike
karlosz: jump instead of exit, so just changing ip instead of longjmping and changing ip
16:46:55
Bike
also it would be good if we could delete unused ENTRYs, because otherwise we're going to cons every time we start a loop
16:58:40
Bike
we don't need to longjmp to change the stack pointer. also, in some common cases (like (go ...) as a top level tagbody statement) the stack ought to be just where it was
17:05:58
Bike
but i think there would be a bit of an issue there in that we wouldn't be eliminating the consing entry needs to do for nonlocal unwinds but not otherwise
17:06:26
Bike
for local unwind... i actually don't think entry should _need_ to do anything, since the amount of stack to drop at any local go should be statically determinable?
17:06:55
Bike
so that if you do (funcall (block nil (lambda () (return)))) you get an out of extent unwind error instead of jumping to an expired stack frame
17:07:34
Bike
the other way to do it would be to invalidate on our way out, yeah, but that would be complicated in its own way
17:09:36
Bike
i think the segfault is being caused because i got the jump wrong by 1 in exit-8. gah.
17:09:59
Bike
it should jump to FDEFINITION 9 FDEFINITION 10 bla bla bla, but instead i see CELL-REF FDEFINITION 10, and CELL-REF is 9
17:45:12
Bike
and everything seems to be optimized out so udb doesn't know shit... i thought it would have recorded this stuff
17:53:33
Bike
drmeister: i need a primer or something on lprint. almost every time i use it i get a python error
18:03:58
drmeister
the python extension loads itself with every command - so if you can get into the code you can fix problems.
18:04:45
drmeister
Regarding udb - variables will become available and be optimized out from machine instruction to machine instruction.
18:05:07
drmeister
If you stepi and reverse-stepi or step/reverse-step you can sometimes see variables.
18:05:51
drmeister
You could also compile the interpreter with __attribute__((optnone)) - then you will have lots of debugging info.
18:06:18
Bike
i'm seeing ENTRY-CLOSE REF 7 ENTRY-CLOSE in the disassembly short before this segfault. that sequence is legal but the ref is discarded, so i'm a little suspicious
18:06:52
drmeister
When inspecting a variable value it uses the pc to crawl into the DWARF to find out where that variable value is at the current pc. When optimization is turned on that coverage becomes very, very spotty.
18:15:35
Bike
okay, i manually went through to try to figure out the stack position after each instruction (which capability i should add to the tracer, by the way) and i think the bytecode as written is trying to draw elements past the bottom of the stack frame for the function