freenode/#clasp - IRC Chatlog
Search
13:44:52
beach
Sure. I am convinced that I can use it in Second Climacs from that documentation. Right now I am working more on SICL, though.
13:45:23
drmeister
I need to push out some changes and git doesn't work through the terminal for some bizarre reason
15:39:27
karlosz
is there anything explaining what all the differen boehm version are or what they do?
15:41:03
karlosz
so cclasp is the cleavir clasp, bclasp is the old compiler, and aclasp is a c++ interpreter?
15:55:56
drmeister
What this all means is it’s too complicated and too implementation dependent detail and needs to be swept away by image save/load
16:07:59
Bike
"I'm going to try removing the -flto-thin argument and try linking again" "Warning: execute-link-fasl worked after removing -flto from the argument list --- FIGURE OUT WHAT IS GOING WRONG WITH THAT ARGUMENT!!!"
16:11:57
drmeister
No worry unless things crash later. This is the linked crashing and then recovering.
17:53:15
karlosz
assert waf_node != None, "Could not find waf node for lisp file %s - did you run './waf update_dependencies'?" % file_name
18:01:45
Bike
drmeister: i made some changes, and now building asdf and serve event seems to hang, but if i do it through the workbench there's no problem. do you know what the difference could be?
19:43:20
Bike
i can load cleavir in bclasp, and functions compiled with it seem to work, even if they do weird things like have &optional and &key that i didn't think about before
19:53:17
karlosz
interesting, the commit that upgrades to llvm6 builds successfully and gets past linking on arch
20:35:13
karlosz
Bike: do you have a more full backtrace for the unitialized data problem you ran into with the closure conversion fix? i couldnt succeed getting the latest clasp to build
20:36:02
Bike
no. i can get you one if you want it. a backtrace might nto be sufficient since it's (probably) a miscompile, though.
20:42:55
karlosz
okay, sounds good. i also have partial inlining and closure conversion as the first two steps in my passes, so it should help narrow down where the possible problems could be from, considering it builds for me
20:50:48
karlosz
im looking through the clasp source a bit; its something that check-for-uninitialized-inputs-dumb doesnt catch?
20:52:37
karlosz
thats interesting, because i didnt tthink those could be iintroduced given that inlining is the only thing that happens beforehand
20:53:17
karlosz
if thats the case it shouldnt be too hard to fix, but i want a test case where the graph shows it
20:53:43
karlosz
sadly, that would also mean fixing closure conversion by adding ast nodes wont work
21:14:32
karlosz
oh hey. a little unrelated but partial inlining does something wonky and wrong with this (lambda (n)
21:20:43
karlosz
yeah. i dont think it should be too hard to fix. we just have to check the place we are unwinding to from the funcall is still inside the catch arm and redirect it to a call to error or something
21:22:54
karlosz
the flow structure in HIR doesnt actually match the flow graph of execution for non local exits
21:44:06
Bike
my reasoning was that the flow graph for nonlocal exits can't actually be statically determined- you can have unwind-protects intervening.
22:04:38
karlosz
hm. it seems like its really the funcalls in the catch arm that have two different continuations, rather than cthe catch instruction