Re: Issues on WindowMaker
Germán Arias wrote: Sometimes (only in WindowMaker) isn't possible miniaturize a window, (the window becomes miniaturized, but is deminiaturized immediately). Also MiniWindows don't get the appropriate icon (for example in Gemas, all miniwindows have the AppIcon, instead the corresponding icon for the file). This bug was introduced with r33045 | ericwa | 2011-05-15 10:37:44 +0200 (Sun, 15 May 2011) | 14 lines Implement the _NET_WM_SYNC_REQUEST protocol described here: http://standards.freedesktop.org/wm-spec/1.3/ar01s06.html Eric was writing an additional value to the protocols array of a _gswindow_device_t struct but didn't care to increase the size of that array :-(. Fixed in svn. I've also added some code to make it easier to track down such errors in the future. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
GSIMap
Hi, I'm trying to make NSHashTable / NSMapTable use the correct read / write barrier functions in GC mode, but I don't really understand the GSIMap code. Does it define macros for reading / writing pointers anywhere? In GC mode, we need to call the relevant read and write barrier functions for assigning pointer values, depending in the pointer functions: For storing strong pointers, we should call objc_assign_strongCast(value, address), and read directly. For storing weak pointers, we should call objc_assign_weak(value, address) and read using objc_read_weak(address). This is the main thing required still for full Apple-compatible GC support. There also seem to be a few places (I've not identified them yet) where GNUstep code is storing strong pointers in globals that are not marked as strong. The compiler will only generate a write barrier if the pointer is either id, or has the __strong qualifier. Without these, we need to mark the entire data segment as potentially containing pointers, which adds some overhead (I'm currently doing this, but I'd like to turn it off). David -- Sent from my brain ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSIMap
On 1 Jun 2011, at 19:30, David Chisnall wrote: Hi, I'm trying to make NSHashTable / NSMapTable use the correct read / write barrier functions in GC mode, but I don't really understand the GSIMap code. Does it define macros for reading / writing pointers anywhere? In GC mode, we need to call the relevant read and write barrier functions for assigning pointer values, depending in the pointer functions: NSHashTable and NSMapTable use both NSPointerFunctions and the old callbacks (Apple added new classes for these objects, while retaining backward compatibility with the old API)... see NSConcretePointerFunctions.[hm] for the new functions and the CallBacks files for the old ones. If you look at the actual hash/map table code (eg NSConcreteHashTable.m) you will see the defines which tell GSIMAP which versions to use. eg. #define GSI_MAP_RETAIN_KEY(M, X)\ (M-legacy ? M-cb.old.retain(M, X.ptr) \ : pointerFunctionsAcquire(M-cb.pf, X.ptr, X.ptr)) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSIMap
On 1 Jun 2011, at 23:20, Richard Frith-Macdonald wrote: On 1 Jun 2011, at 19:30, David Chisnall wrote: Hi, I'm trying to make NSHashTable / NSMapTable use the correct read / write barrier functions in GC mode, but I don't really understand the GSIMap code. Does it define macros for reading / writing pointers anywhere? In GC mode, we need to call the relevant read and write barrier functions for assigning pointer values, depending in the pointer functions: NSHashTable and NSMapTable use both NSPointerFunctions and the old callbacks (Apple added new classes for these objects, while retaining backward compatibility with the old API)... see NSConcretePointerFunctions.[hm] for the new functions and the CallBacks files for the old ones. If you look at the actual hash/map table code (eg NSConcreteHashTable.m) you will see the defines which tell GSIMAP which versions to use. eg. #define GSI_MAP_RETAIN_KEY(M, X)\ (M-legacy ? M-cb.old.retain(M, X.ptr) \ : pointerFunctionsAcquire(M-cb.pf, X.ptr, X.ptr)) I am not sure this helps. The GSIMap code seems to do things like: GSI_MAP_RETAIN_KEY(map, node-key) node-key = key; This is actually wrong in retain / release mode (-retain is not guaranteed to return self), but in GC mode, these two lines need to somehow become: objc_assign_strongCast(key, (node-key)); there also doesn't seem to be any macro for reading the keys. For example, when ever you read node-key or node-value as a weak pointer, lines like: GSI_MAP_EQUAL(map, node-key, key) Need to be expanded to something like: [objc_read_weak((node-key) isEqual: key] David -- Sent from my STANTEC-ZEBRA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSIMap
On 1 Jun 2011, at 23:48, David Chisnall wrote: On 1 Jun 2011, at 23:20, Richard Frith-Macdonald wrote: On 1 Jun 2011, at 19:30, David Chisnall wrote: Hi, I'm trying to make NSHashTable / NSMapTable use the correct read / write barrier functions in GC mode, but I don't really understand the GSIMap code. Does it define macros for reading / writing pointers anywhere? In GC mode, we need to call the relevant read and write barrier functions for assigning pointer values, depending in the pointer functions: NSHashTable and NSMapTable use both NSPointerFunctions and the old callbacks (Apple added new classes for these objects, while retaining backward compatibility with the old API)... see NSConcretePointerFunctions.[hm] for the new functions and the CallBacks files for the old ones. If you look at the actual hash/map table code (eg NSConcreteHashTable.m) you will see the defines which tell GSIMAP which versions to use. eg. #define GSI_MAP_RETAIN_KEY(M, X)\ (M-legacy ? M-cb.old.retain(M, X.ptr) \ : pointerFunctionsAcquire(M-cb.pf, X.ptr, X.ptr)) I am not sure this helps. The GSIMap code seems to do things like: GSI_MAP_RETAIN_KEY(map, node-key) node-key = key; This is actually wrong in retain / release mode (-retain is not guaranteed to return self), The guarantee is that it's specifically documented to do so in the protocol see http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html So any implementation of -retain which doesn't return self is faulty, and the programmer really deserves any error they have introduced by overriding/replacing the default one. but in GC mode, these two lines need to somehow become: objc_assign_strongCast(key, (node-key));\ there also doesn't seem to be any macro for reading the keys. For example, when ever you read node-key or node-value as a weak pointer, lines like: GSI_MAP_EQUAL(map, node-key, key) Need to be expanded to something like: [objc_read_weak((node-key) isEqual: key] Then we need some modification for if/when we support non-boehm GC. The current sequence: node-key = key; GSI_MAP_RETAIN_KEY(map, node-key); could become: GSI_MAP_ACQUIRE_KEY(map, key_in_node, key); and we could trivially add a macro to reference the map content. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
