libera/#clasp - IRC Chatlog
Search
13:03:27
Colleen
Bike: drmeister said 7 hours, 34 minutes ago: There is something deeply wrong. When I evaluate (fib 31) the evaluation goes off the rails at some point. So I'm trying to compile the following but the compiler isn't ready for it yet. I want to ID where it goes off the rails and then get udb in there to figure it out.
13:22:21
Bike
(lambda (x) (setq x 3) x) puts x in a cell, and does ref 0 const 0 cell-set, with the old order
13:29:04
drmeister
I wonder if your musing about problems is relevant to the (fib 31) blowing up but (fib 30) working
13:39:28
drmeister
The stack pointer just takes off at some point until it points into what I presume is boehm memory and pushes values into it and only then does it crash.
14:20:37
drmeister
I could buffer this and search for that different sequence and then get to where it goes bad.
14:21:06
drmeister
I'm worried the code may be getting modified, or a key datastructure is getting modified and then it breaks.
14:36:51
drmeister
I put in a single statement to print the stack height prior to evaluating each instruction. I expect to see that the stack height blows up at some point.
14:43:44
drmeister
Do you see what I'm talking about? Billions of steps where everything is fine and then something changes and hundreds of thousands of steps where the stack slowly blows up.
15:03:25
drmeister
I tried it again (setting the start of each (fib 30) y value to 99999). This time it failed on the second evaluation.
15:12:24
drmeister
I could catch the problem a lot earlier if I abort when the stack gets above a certain threshold.
15:21:22
drmeister
I'm adding functions to set the stack height trigger and I'll have it exit gracefully so I can do it over and over.
15:37:33
karlosz
Bike: ugh, apparently i had killed the hunk using emit-lexical-set but it was still at least in my undo buffer
16:22:33
drmeister
Playback: Every cycle it will read a PC and stack pointer and compare it to the current PC and stack pointer.
16:51:22
drmeister
I think I should throw an exception and unwind the stack when there is a mismatch rather than just return.
16:52:58
Bike
what's the ninja target to build cboehm (i.e. not precise)? is it just "cboehm", like i'd do ninja -C build cboehm?
17:38:33
drmeister
I can record (fib 20) and when I play it back like a dozen times - no difference.
18:00:52
drmeister
I'll turn off optimization for bytecode_vm and then I'll be able to see more values.
19:00:33
drmeister
It will record that into the vm log and when you play it back it better match or it throws an exception.
19:05:08
drmeister
It means that when the VM ran the first time it recorded that 0x70 was returned by a function call and this time around 0xfffffffffffffffc was returned.
19:10:24
drmeister
I think the first time it returned the correct value and I think the second time it got the wrong arguments.
19:16:59
drmeister
You can keep adding VM_RECORD_PLAYBACK(value,name) macros and record more and more of the evaluation that gets matched to current values when you play it back.
19:30:23
drmeister
../src/core/bytecode.cc:235:vm_record_playback Mismatch between recorded vm_call_receive_one_arg0 0x74 and current 0x8
19:35:36
Bike
oh, i put that into the function descriptions because i thought without a function name printing bytecode functions would crash
19:37:20
drmeister
It's getting the argument 0x8 now but when it was recorded it got the function argument 0x74
19:57:10
Bike
i think the static analyzer is running serially. it used to work in parallel, didn't it?
19:58:16
yitzi
We started on parallel, but I don't think we finished. The building of [abc]clasp is parallel, but the analyzer is series
20:04:22
yitzi
You can set the default target to boehm by adding `:default-target "cclasp-boehm"` to your config.sexp if you want.
20:05:50
Bike
i thought i remembered this taking "only" a few hours before, and the scroll going by faster
20:12:20
yitzi
Bike: Apparently, I put a note in koga https://github.com/clasp-developers/clasp/blob/ecb185da2507fd01ceeddaecc861a0eb2c253c45/src/koga/scripts.lisp#L115-L126
20:24:09
Bike
vm.reg returns the address of the nth local. then * dereferences it. then the value gets pushed to the stack.
20:26:51
drmeister
It should be a CONS cell - correct? This is does not have cell ellision incorporated yet.
20:31:40
drmeister
Yes, you put all the lexical values in cons cell don't you? Do you follow a ref by some other instruction to get the lexical value?
21:07:39
Bike
i'm getting an error that there is no method for cscrape::tag% for a cscrape::exposed-internal-class for a class i just wrote
22:22:30
Bike
drmeister: actually not sure why i even wrote that since we could pass nil directly...
22:23:05
Bike
bytecode compiler envs are now set up enough that the compiler works with them and macroexpand works with them
22:34:41
drmeister
(setf (fdefinition 'fib) (compile-to-vm::bcompile '(lambda (n) (if (eql n 1) (progn (gctools:garbage-collect) 0) (if (eql n 2) 1 (+ (fib (- n 1)) (fib (- n 2))))))))
23:38:29
drmeister
It looks like putting the side stack at the top of the main stack is a better idea.
23:41:20
drmeister
I'm going to clean up the VM logging machinery and merge these changes into the VM branch later this evening.
23:50:55
Bike
i didn't change anything in the actual bytecode interpreter besides interchanging the arguments to cell-set
0:12:20
karlosz
i wonder what a good name is for the operation X <n> that just wraps the value at frame slot n and puts it in a cell
0:45:12
karlosz
also i seem to need to kill the whole clasp directory every time i want to update it. i got an issue with no applicable error on (#<CSCRAPE::EXPOSED-INTERNAL-CLASS core::BytecodeCmpVarInfo_O>).