freenode/#clim - IRC Chatlog
Search
0:05:00
wmannis
It looks like the right answer to that is a new directory-pathname presentation type. Or so it seems, I’m new to CLIM.
0:05:52
nyef``
That... at least sounds plausible? I have no idea if there might not be another solution.
0:07:28
wmannis
I mean, there’s an easy first fix, to prevent users from doing something impossible, by using CL-FAD to make sure you’re dealing with a directory. But that doesn’t fix the presentation issue.
4:11:55
nyef``
More progress: I now have enough of a working TeX environment that I can build the SICL Specification document.
4:15:13
nyef``
On another front, I'm considering the possibility of a system in which all boxed values are pointers. That is, there ARE no immediate boxed values.
4:16:13
beach
That would certainly simplify the system, but also have an impact on performance, I would think.
4:18:32
nyef``
I don't know if the overall result would be a win, but it's a section of the design space that might be interesting to explore.
4:37:24
beach
Speaking of GC, did I tell you about my latest thinking with respect to the memory management of SICL?
4:38:44
beach
Do you remember this paper, for the per-thread GC? http://metamodular.com/sliding-gc.pdf
4:39:49
beach
I am thinking of a single common GC with a mark-and-sweep for CONS cells and headers of general instances.
4:42:00
beach
So, if I allocate things like functions there, I don't have to worry about code moving around.
4:46:07
beach
And it can be simplified for Common Lisp. His allocator assumes that it is common that a malloc is followed by a free and vice versa. That is not going to be the case here. There will be lots of mallocs followed by lots of frees.
4:47:37
beach
I think this can work, because the per-thread GC will catch a lot of transient objects, thereby cutting down on the load on the global GC.
4:50:16
beach
But I have a feeling this is right for SICL, given the simple structure of heap-allocated objects.