libera/#sicl - IRC Chatlog
Search
3:10:57
beach
jcowan: You don't need to check that a rack is obsolete. This is done automatically by the generic-dispatch mechanism. Every generic function applied to an object with an obsolete rack will fail to find an applicable method. The technique is documented in my paper on generic dispatch from ILC 2014.
3:13:55
beach
moon-child: Yes, structure objects are standard objects. I don't know whether I said anything about allowing change-class on them. I think I haven't said anything because I don't care much about structure objects, but it seems reasonable to allow. However that's not what you said. You said that all classes that are not built-in classes are standard classes, and that's very different.
3:30:10
hayley
I asked the authors if the LXR collector had to handle popular objects specially when compacting. They said that they have to fix fewer pointers, than if they only reclaimed memory by copying, so it's not an issue. Which is a good sign, but I'll have to check, and I'll have to add some sort of pause time prediction when I implement compaction.
3:41:18
hayley
At the moment the serial mark-region collector makes my parallel program "only" 13% slower; I'm not sure what I've missed to make it faster, without using parallelism.
11:09:31
beach
scymtym: I think I managed to fork your repository, add my fork as a remote, make a change, and push that change to my fork.
11:21:41
scymtym
i good thing that got lost in the transition from org-mode to texinfo is handling of listings. org-mode has syntax highlighting for listings and, more importantly, can evaluate the code in the listing and include the output in the document. i'm not sure whether it's worth the effort to try and build similar behavior into the Makefile
11:22:57
scymtym
i also used this functionality to include documentation strings in the dictionary section. that's my main reason for considering it
12:13:44
beach
scymtym: Is it OK if I just start a new chapter named Node kinds and relations, with a section for Node kinds and a section for Relations?
12:14:28
beach
For the node kinds, I would then list each node kind with an itemized list of the relations in which that kind is used, and whether it is on the left or on the right.
12:16:44
beach
I mean, the important part is to get the information in there. The structure can be changed later I guess. I don't know whether you already have some ideas for the documentation structure that is different.