freenode/#clasp - IRC Chatlog
Search
15:48:06
Bike
(let ((*readtable* (copy-readtable nil))) (set-syntax-from-char #\0 #\`) (values (get-macro-character #\0) (get-macro-character #\`))) => CORE:READER-BACKQUOTED-EXPRESSION, ECLECTOR.READER::BACKQUOTE
15:53:22
Bike
if i do set-macro-character instead it works. okay, so set-syntax-from-char is being stupid i guess
18:58:04
drmeister
I'm going to have to set up three tmux connections. I have (1) for emacs/source-code editing/compilation (2) for running clasp (3) for running udb
20:08:41
kpoeck
If you do (core::set-eclector-reader-readmacros core:+standard-readtable+) it should work fine afterwards
20:11:47
Bike
no i mean i checked clhs, it really is supposed to be the standard readtable, like we do
20:29:56
kpoeck
The compiler complains about (core::set-eclector-reader-readmacros core:+standard-readtable+)
20:34:58
kpoeck
better than (eval '(core::set-eclector-reader-readmacros core:+standard-readtable+)) what I have now :-)
20:37:59
drmeister
This is waaaaay better than staring at hex dumps and calculating offsets with the MacOS Calculator app.
20:40:01
drmeister
I don't know how much work you do with lldb - but I wrote a python extension that works with gdb and lldb that makes it easier to debug clasp code at a low level.
20:41:13
kpoeck
Although I am sure if stassats would be interested, he could fix most of the sbcl bugs
20:41:14
drmeister
Ok, well if you want to examine clasp objects in memory - this will show you the structure of objects.
20:43:23
drmeister
Ok, I can see bad entry point function pointers now after image load. Digging deeper.
20:44:13
drmeister
I find that Cleavir is performing faster than ever - it's really a pleasure to work with when I'm not mucking around with low level runtime issues.
20:45:55
drmeister
jackdaniel: There is a new garbage collector on the horizon - https://mmtk.io - forgive me if I'm repeating myself.
20:46:58
Bike
kpoeck: _no_ bugs? because we definitely have some outstanding bugs in the type system
20:58:11
karlosz
i still had a bunch of stuff on the todo list (both optimizations and bugs) for the compiler i haven't gotten around to yet cuz this semesters been pretty chaotic but if things are pretty stable as is that's good too
21:02:30
karlosz
also - this issue can finally be closed. i added the general flow graph simplification mechanism for this a while ago in Cleavir: https://github.com/clasp-developers/clasp/issues/252
21:09:52
kpoeck
mcclim compiles with the fix for https://github.com/clasp-developers/clasp/issues/1127
21:11:03
Bike
a better fix in cleavir might be having some kind of actual lambda list structure rather than re-parsing everything constantly which is stupid
21:37:58
drmeister
I'm connecting five terminals into hermes (linux box) and running image save in one and then image load in the other while connecting a time traveling debugger into each.
21:38:30
drmeister
Then I can compare what's going on with function pointers in image save vs image load.
21:54:51
drmeister
Oh for crying out loud! I've been chasing my tail for the past 24 hours. I've been loading an old image because the new one was being generated in a different directory. Argh!
21:56:00
drmeister
I need to calculate some kind of hash of the executable and libraries so I catch when I'm loading old images.
21:58:58
drmeister
Well, at least I'm back on track debugging the real problems. I have llvm objects to initialize at image load time.
22:02:14
drmeister
Hmm, this suggests something interesting. If I encounter an object that isn't initialized properly at load time. I can time-travel back to the moment it was created at in the save session, look at the backtrace and then replicate that at load-time.
23:55:42
drmeister
Truth dies in image save/load. The "T" value in clasp doesn't survive image save/load for some reason.
2:26:20
drmeister
Ah - the problem is I unwind the stack too far when I throw the SaveLispAndDie exception and among other things the _lisp->_Roots._TrueValue gets reset to null.