freenode/#sicl - IRC Chatlog
Search
11:38:02
beach
Yet another one: Apparently, the copying GC that SBCL uses must have been inconvenient for certain function object, so SBCL now has a special space for objects that don't move, presumably used for code. That space has a fixed size apparently, and this fact almost because a showstopper for SICL bootstrapping.
11:38:04
beach
SICL bootstrapping used lots and lots of FUNCALLABLE-STANDARD-OBJECTs and at some point, I ran out of space for those. stassats helped me out of my difficulty by having SBCL only allocate generic functions, and not all funcallable standard objects in that space, so I am saved. But the space is still there and it is still fixed size as far as I can tell.
11:41:45
beach
Let me get this straight, though. I am a very happy SBCL user. The maintainers are doing a fantastic job of keeping it correct, fast, and very useful. But I think the age is showing, which is why I am working on SICL. I may never finish without more help, but at least I have understood some aspects of what is needed.
11:46:24
beach
Things are a bit stalled right now for me, because I am working on this year's ELS submissions.
11:48:56
beach
I don't think the bootstrapping paper can be improved a lot more, so I am working on this one instead right now (warning VERY PRELIMINARY VERSION): http://metamodular.com/make-method-lambda.pdf
14:02:49
pfdietz
Stack maps could have all sort of uses beyond GC. Debugging, for example. Record not only what's a root, but where each program variable is at each time.
16:42:02
jcowan
beach: I'm surprised that the symbol-package is still hard-coded in the symbol rather than indirecting through the package name and the global environment. That seems inflexible.
16:54:10
beach
You might think so, but I don't want the symbol-package to depend on the environment.
16:55:59
beach
I don't have a pre-packaged explanation for why I want that. I would have to get back to you on that after I contemplate the consequences of the opposite decision.