libera/#clasp - IRC Chatlog

15:57:47 yitzi I've just update the repo for trivial-features so be sure to do rm -rf src/lisp/kernel/contrib/trivial-features/ and rerun koga if you build off of main.

18:40:47 bike it's crashing in eclector.cst:read. how the hell.

19:40:41 yitzi I got a type error

19:41:33 yitzi bike: https://plaster.tymoon.eu/view/3831#3831

19:50:47 bike i thinkt he problem is that if eclector.cst:read is bytecompiled, it blows the stack on big conses

19:50:55 bike just reproduced that in main, trying to read a 4000-long list

19:53:21 yitzi ok

19:54:07 yitzi But it works when it is byte compiled later. ANSI tests pass the bytecompiled build

19:55:38 bike Right, but in the bytecompiled build, we don't actually read CSTs (except now in my source info branch)

19:56:04 yitzi ah

19:59:01 yitzi So is your branch not using the C bytecode compiler?

20:01:07 bike It is. It reads the CST first then passes the raw to the bytecode compiler

20:09:29 yitzi For me it appears that it is failing when it attempts to compile MAKE-RANDOM-BACKQUOTED-STRING

20:10:22 yitzi Err....maybe not

20:12:18 bike you can try e.g. (with-open-file (s "whatever.lisp" :direction :output) (write `(defvar *test* ',(make-list 4000)) :stream s)), then (with-open-file (s "whatever.lisp") (eclector.concrete-syntax-tree:read s)) to get the same crash

20:12:47 bike with the ansi tests, it fails when compiling printer/format/roman-numerals.lisp, which has a big ol list in it

20:12:54 bike .lsp rather

20:13:38 yitzi Same here

20:14:23 bike so... this is pretty annoying to deal with. i guess i'll try upping the stack again, why not

20:24:43 bike ok. if i double the stack it can read that much, at least

22:42:45 scymtym bike: do you know where the stack gets blown?

22:46:11 scymtym in SBCL, a much longer list blows the stack in RECONSTRUCT

23:05:19 bike i did not look in detail, but i could. i am not calling reconstruct, so that's not it (unless read calls it?)

23:05:41 bike we have pretty bad recovery from stack overflow - hard to get a sane backtrace. i spent like several hours isolating it to read

23:15:20 scymtym CST read calls RECONSTRUCT for "unaligned" expressions and parse results

23:16:22 scymtym your example is "unaligned" because MATERIAL in 'MATERIAL has corresponding CSTs, but the (quote ...) part does not

23:16:53 scymtym implementing the recursive traversals in RECONSTRUCT would fix the overflow but it would still be slow

23:17:48 scymtym s/implementing/replacing with a worklist/

23:19:12 bike oh, i see.

23:32:05 bike the bytecode probably has a lower max recursion depth than sbcl. it's already less than our own native compiler, apparently

23:32:49 bike i will see if i can find more specifically where it crashes

23:41:28 bike scymtym: looks like it is during reconstruct indeed

23:41:44 bike i wouldn't worry much about changing the implementation unless it's a really fundamental improvement. i can just make the stack bigger

23:43:35 scymtym it would be best to somehow extend the optimization for the aligned case and avoid RECONSTRUCT altogether. i will think about it sometime later