freenode/#clasp - IRC Chatlog
Search
13:14:58
drmeister
It's pretty clear that slot locations are being rewritten occasionally and the optimized slot accessors that I've added aren't getting the memo.
13:15:26
drmeister
With the new slot accessors I can compile bclasp but I can't compile cclasp because inline.lisp fails.
13:15:59
drmeister
I can't compile ASDF within bclasp because that also fails at a completely reproducible spot.
13:16:23
drmeister
I wrote debugging slot accessors that I'm still working on to clarify the problem.
13:19:10
drmeister
Then an accessor is called 'component-operation-times which is supposed to return a hash-table - but instead returns #:UNBOUND
13:23:08
drmeister
That accessor was called previously but this time it's being called from invalidated-dispatch-function and it tries to read the wrong slot.
13:31:12
drmeister
Ok, I set up (and am still working on) debugging optimized slot-accessors code that cross-checks the slot access - it was triggered.
13:36:10
drmeister
It lets me unravel what is going on with fastgf. But i need to log the slot-definition-location's.
13:37:10
drmeister
Then I can cross check them with what the debugging optimized slot-accessors have recorded within them.
13:47:24
beach
The slot location might change whenever there is a change to the class or one of its superclasses. Perhaps even if one of its subclasses changes.
13:47:59
beach
I suggest you look at the code that computes the location. Then you can see what it depends on.
13:49:10
drmeister
Ok - because I thought I had hooks everywhere that kept the call history up to date - but there appears to be something getting by me.
13:50:05
drmeister
I haven't noticed it until now because the slot accessors were all going through an unoptimized slot definition location hash table lookup.
13:51:09
drmeister
So the debugging optimized slot accessors will do the slow hash table lookup and compare the slot index to the results. If they don't match it will signal an error. If they do - it will proceed to carry out the slot access and return.
13:53:01
drmeister
It was looking up the slot index using a hash table - I'm not sure about the details beyond that - yet.
13:54:04
drmeister
I assume it was starting with the slot name and looking up the effective-slot-definition
14:14:01
Bike
there's something called a location-table in some classes (standard classes, i guess) and if there is one it gets the slot location from it directly with gethash.
14:14:47
beach
I would be very surprised if using a hash table were faster than searching the list of slots sequentially.
14:25:33
beach
If there is no slot writer, then I use REINITIALIZE-INSTANCE. That way, only protocol functionality is used.
14:27:00
Bike
it's internal right near where the class is defined, so i figured it wasn't horrible, at least
14:58:20
drmeister
https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/clos/hierarchy.lsp#L86
15:11:24
drmeister
I have two intrinsics for debugging optimized slot access cc_dispatch_slot_reader_index_debug, cc_dispatch_slot_writer_index_debug
15:12:29
drmeister
They take a Common Lisp struct named cmp::optimized-slot-reader and cmp::optimized-slot-writer respectively and an instance or a value and an instance.
15:14:00
drmeister
They call back out to Common Lisp functions dispatch-slot-reader-index-debug and dispatch-slot-writer-index-debug that pulls information out of the optimized structs to lookup the slot index using the slot-name, class, and method and then compare that to the optimized slot index also stored in the struct.
15:16:18
drmeister
It's turned on by uncommenting cfg.define("DEBUG_SLOT_ACCESSORS",1) in the wscript file.
15:42:41
drmeister
Hmmmm, my first test suggested that the precalculated and on-the-fly calculated slot indices are identical - so that may not be the problem.
15:43:14
drmeister
That suggests that it's a problem with changing the class of an instance rather than changing a class.
16:40:24
drmeister
The part I don't know what to make of are the stamps. They are the stamp that the class imposes on instances 876 and the stamp of the object 900.
16:45:19
drmeister
The class of the instance may have been changed - then there will be no relation between the stamp values.
16:45:54
drmeister
So if the class of the instance is being changed but the slots of the instance aren't being rewritten - then there will be a problem...
16:59:13
drmeister
I'm also adding more code to the debugging reader to get more insight into what is going on.
16:59:30
drmeister
I don't have a way to lookup the class given a stamp - that would be useful here.
17:00:28
drmeister
This is an situation where I have an error and I want to figure out which class is associated with stamp 900