freenode/#clasp - IRC Chatlog
Search
3:15:16
Bike
CLOS is going to be annoying though, i can understand a little more now why you go through like four environments
3:18:42
beach
Yeah, CLOS is complicated that way. Recently, I have considered converting some of the generic functions to ordinary functions to avoid some of the problems with simultaneous but different mappings from names to objects.
3:19:42
beach
I have nothing concrete yet, but when I start contemplating SICL bootstrapping again, I will keep that option in mind if I get into trouble.
3:24:36
beach
Yeah, that's not the problem I had in mind. It is possible that, in the same bootstrapping phase, I need two different definitions of some function, called by two different generic functions. I might be able to fix that problem by inlining two different versions of the function and converting at least one of the generic functions to an ordinary function.
3:31:24
beach
The problem is that, in each bootstrapping phase, I use some classes created by the previous phase, and those are often "the same" classes, i.e. the MOP hierarchy of classes, but represented differently in each phase. In phase 1, they are ordinary host classes. In phase 2, they are host non-class instances. In phase 3, they are host header/rack combinations. I often need to call different versions of things like allocate-instance or
12:59:29
Shinmera
I've hard reports about Portacle breaking on it (again) but I haven't tested it myself
13:00:20
Shinmera
Makes you really appreciate the "never break userland" attitude Linus has for the kernel.
14:44:35
Bike
Ok. So, say you have a class that defines a slot and a subclass of that class. The effective slots end up having different locations, but the same reader method can read both, since it's specialized on the superclass.
14:45:10
Bike
So for fastgf to do an optimized read outcome that doesn't look up the location at all, it has to have a different outcome depending on the actual class of the reader argument, not just the list of applicable methods.
14:45:52
beach
Yes, and it already does, because the call history contains actual stamps of instances.
14:46:33
Bike
Right. But, so the method outcome computer can't use compute-effective-method or something too similar to it, since it's not that particular and only gets the effective methods. Right?
14:47:36
beach
Right. When an accessor method is returned, the location has to be computed using the class of the argument.
14:48:08
beach
Hence the CLASS-SLOTS, find the right slot definition, find the location in that slot definition.
14:49:05
Bike
Okay. I see. We weren't doing that so we hit this problem. Just wanted to confirm that you had more specificity in mind.
14:50:15
Bike
we have call histories and stuff worked out this way, but the otucomes were being computed by basically compute-effective-method
14:51:29
beach
<beach> I think you can use CLASS-SLOTS to find all the effective slot-definitions of a class.
14:54:02
Bike
Dunno. I'm only peripherally involved in fastgf, though I'm going to look at effective methods closer later
15:07:23
Bike
We ran into it with unbound-slot for whatever reason, to add another layer of confusion
15:08:48
beach
By the way, I had an idea for avoiding the test for unbound slots in most cases (at least I think so).
15:10:10
beach
It relies on the fact that instance of many (most?) classes never have unbound slots, because the class has initforms or default initargs, or simply because all initargs are always supplied.
15:12:16
beach
So the idea is to check that all slots are bound after :INITIALIZE-INSTANCE, and if so, generate discriminating functions that don't check. Whenever there is a violation of this condition, perhaps because someone called slot-makunbound, then the class is marked, and subsequent slot readers check whether the slot is bound.
15:14:18
beach
Unfortunately, once there has been a violation of this condition, then slots must be checked in all future accesses.