freenode/#sicl - IRC Chatlog
Search
14:11:57
Bike
update on change-class atomicity: my code doesn't handle class slots correctly. doing so correctly and thread safely may be kind of involved
14:13:00
Bike
change-class has to handle slots that are class-allocated in the instance but will be instance-allocated with the new class.
14:13:56
Bike
in clasp the storage is that the slot-definition-location is a cons, and the value of the slot is stored in the car
14:14:43
Bike
since the info is in the rack and slot definitions are immutable and so on, there shouldn't be any additional thread safety concerns
14:15:12
Bike
does mean my earlier plan to store only instance-allocated slotds in the rack is a bust, but that's not important
14:15:49
beach
Right. Some code that uses that information to determine instance size, may have to be adapted.
15:10:18
beach
So I think I have the basic structure of TYPEP down. But TYPEP is implemented as three generic functions, and they have EQL specializers. I didn't teach satiation to handle those, because previously I didn't think I would need them during bootstrapping. But having TYPEP available solves a bunch of problems during bootstrapping, so I think I should teach satiation to handle them.
15:11:18
beach
I can still load this new TYPEP after I "tie the knot", but then the old TYPEP is invoked, and I would like to avoid that, so that I can completely replace the old one at some point.
15:14:28
beach
So in summary, I am pretty pleased with this (very long) day of work. Progress is steady. My tools are working better and better. The boot-specific backtrace inspector together with Clouseau are invaluable tools, and they work in more and more situations.
15:14:47
Bike
what do the three generic functions do? also, i thought on sicl eql specializers always put things on the slow path
15:16:00
beach
There is one for choosing between an atomic and a compound type specifier. Exaggerated, perhaps. One handles atomic type specifiers, and one handles compound type specifiers and the last one EQL specializes on the CAR of the type specifier.
15:16:21
beach
And yes, at the moment, just the slow path. So satiation is not going to do anything for it.
15:18:33
beach
And I will remove the version in first-class global environments, because it is not needed.
15:21:06
beach
There are relatively few methods on TYPEP-ATOMIC, because SICL has more classes than what the standard requires, so most cases are handled by checking the class precedence list of the class of the object.
15:22:19
beach
I mainly have to handle non-classes like ATOM, BASE-CHAR, etc. in the specific methods.
15:40:58
beach
As it turns out, during bootstrapping, there are not that many subclasses to take into account. The generic functions are mostly accessors, and those that manipulate metaobjects.
15:53:25
Bike
that'll get weird with the type hierarchy. like, atom has to be a superclass of almost everything.
15:54:51
Bike
the symbol T has to be an instance of either the BOOLEAN class, or a class with no other members
15:59:53
beach
Yes, and I don't think you are allowed to alter the class hierarchy in such radical ways.
16:08:54
beach
I am thinking that, once this bootstrapping thing is working, it might be interesting to replace the HIR interpreter by an AST interpreter. I am betting it will be an order of magnitude faster.
16:09:55
beach
HIR is huge, which is why translating HIR to Common Lisp failed, but the AST is fairly close in size to the original code.
16:11:30
Bike
i've been tuning its performance a bit. there are some problems. it can't interpret things like fixnum-add-ast. if it can't interpret things it just uses the full compiler, but that can cause problems involving closures, so it maps the ast first to see if there's anything uninterpretable. and map-ast is really slow because of the huge hash table.
16:11:50
Bike
though i'm going to try rearranging the AST into being an actual tree, so the hash table won't be necessary
16:12:56
beach
I see. I wonder whether I wold have similar problems in SICL. That's not clear to me.
16:13:19
beach
I mean, I only need the AST interpreter/compiler during bootstrapping, so I can make certain assumptions.
16:14:44
beach
Another advantage of an AST *compiler* would be that it might be possible to understand the resulting Common Lisp code by looking at it. That was totally impossible with HIR-to-CL.
16:16:45
beach
But I would have to make similar transformations to the AST as I now do to HIR, so that I can "tie" the result to a particular first-class global environment.
16:19:01
beach
OK, enough for today. I'm off to fix dinner for my (admittedly small) family, and then spend time with her. I might check in briefly later. Otherwise, I'll be back tomorrow morning.
16:19:26
Bike
with clasp things could be simplified. like if cst->ast could be configured to not inline anything, there probably wouldn't be any fixnum arithmetic primops to worry about