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
17:35:42
specbot
Introduction to Classes: http://www.lispworks.com/reference/HyperSpec/Body/04_ca.htm
17:35:51
Shinmera
"A class can have a name. The function class-name takes a class object and returns its name. The name of an anonymous class is nil."
17:39:33
Shinmera
Well, not necessarily. You could constrain classes and require them to have a unique name.
17:42:34
drmeister
Ok, so the instance is being changed from a ASDF/COMPONENT:COMPONENT to an ASDF/SYSTEM:SYSTEM and for some reason the change isn't being done properly
17:43:42
drmeister
Hmmm, the stamp of the instance is still 876 - but the class of the instance does not match that.
17:44:02
drmeister
Ok - well the problem is changing the class of an instance - it's broken somehow.
18:19:56
beach
Also notice that the name given to find-class can be distinct from the one you get by calling CLASS-NAME.
18:33:25
kpoeck
Surprisingly i get an error compiling [ 6/368] Compiling src/clbind/link_compatibility.cc
18:33:58
kpoeck
Saying /usr/local/include/boost/config/detail/posix_features.hpp:18:15: fatal error: 'unistd.h' file not found
18:34:41
kpoeck
I have unistd.h in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/
18:35:50
kpoeck
In /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 there is no unistd.h
18:42:03
drmeister
kpoeck: No - I keep my OS X updated and I have no interest in going backwards in OS X version or Xcode version.
18:42:36
kpoeck
include_dirs.append("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/")
18:45:38
drmeister
Are you using the stock Xcode? I haven't tried that yet. I build clang/llvm from the tip-of-trunk
18:46:52
kpoeck
No until upgrading to highSierra it worked perfectly with external-clasp and this is what I am using
18:47:36
kpoeck
I wonder whether I need to tell external clasp about /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/
18:48:00
drmeister
Ok - I'm a bit rushed today doing something else so I can't help you at the moment - check back tomorrow - I'll have more time.
18:48:55
drmeister
Yeah - missing header files happen to me every time I upgrade Xcode - that's why I automatically assumed you were using an old version.
18:57:49
Bicyclidine
so this error says it's for cell-error-name, not any of the accessors you define
18:59:18
Bicyclidine
if you do like (ignore-errors (bara *foo*)) so that it doesn't trigger the debugger does it still happen?