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.