[Openmcl-devel] Hemlock and its documents and windows
cmhanson at eschatologist.net
cmhanson at eschatologist.net
Sat Oct 15 15:17:47 PDT 2016
I think the best thing to do would be to make this functionality work without isa-swizzling. That’s not the way you’d do it in Cocoa with ObjC or Swift, so it’s probably not what you want to do in Cocoa via CCL either.
One thing that might be useful is also abstracting the classes that are used to implement the IDE and editor, such that there’s a “pure CLOS” class that the Cocoa class delegates to, and you can adjust which CLOS class is used easily. That could also make it more feasible to put the IDE atop, say, GTK+ on Linux or the Windows API on Windows as well.
(Maybe that’s already how things are designed, I haven’t looked too closely yet.)
> On Oct 13, 2016, at 12:12 PM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>> On Oct 13, 2016, at 6:07 PM, Chris Hanson <cmhanson at eschatologist.net> wrote:
>> It could be a behavior change in the system frameworks due to the SDK against which 1.11 is compiled against vs 1.10. When you link an executable, the version of the SDK used is encoded in it. That lets newer versions of the OS preserve old behaviors for binary compatibility. If CCL 1.11 was linked against a newer SDK that could this result in behavior changes for otherwise identical code.
>> -- Chris
>> Sent from my iPad
>>> On Oct 13, 2016, at 9:58 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>>> Thank you Chris for the info about NSKVONotifying_…
>>> Now I understand a little more. However it seems to me that searching the CCL
>>> sources ought to show up uses of NS functions containing ‘keyPath’ or ‘key-path’,
>>> and I found a very few but none seemed related to Hemlock. From which I suppose
>>> I must conclude that the notifying change probably occurred when I got beyond
>>> Snow Leopard, and I just never noticed because things were still working.
>>> The code compiled using CCL1.10 works while the same compiled using CCL1.11
>>> doesn’t, despite the machine (& hence OS configuration) being identical. This
>>> suggests to me that it’s a change in CCL rather than anything the OS has started to
>>> do which is the root of my problem, and what I notice is that the CCL1.11 NS objects
>>> have foreign pointers in their ISA slots, the CCL1.10 don’t.
>>> I can’t see a change in the Hemlock code that causes foreign pointers to be used
>>> in place of NS classes (I used the source comparison tool on the ccl1.10 and ccl1.11
>>> to look). Maybe I’m being blind to something obvious to others. It happens.
>>>> On Oct 13, 2016, at 2:58 AM, Chris Hanson <cmhanson at eschatologist.net> wrote:
>>>> On Oct 12, 2016, at 7:43 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>>>>> On my mid-2015 Macbook Pro with OS X.11.5 I have been trying to move my code
>>>>> from DarwinX8664 ccl 1.10 r16196 to ccl 1.11 r16635.
>>>>> I have a problem with some code I contributed a few years back, clickable.lisp.
>>>>> Specifically it uses gui::find-or-make-hemlock-view and then (hold your noses here)
>>>>> changes the ns:isa slot of the window to a subclass of gui::hemlock-frame and
>>>>> changes the ns:isa slot of the document to a subclass of guy::hemlock-editor-document.
>>>>> While the first seems to succeed, the second seems to cause a crash in ccl 1.11.
>>>>> I notice that the original contents of these ns:isa slots are now foreign pointers, whereas previously in ccl 1.10 they were ns class objects. I also notice that sometime between
>>>>> my developing that code and ccl 1.10 coming along, a change was made to the
>>>>> hemlock-frame’s ns:isa to be a #<NS-OBJECT NSKVONotifying_HemlockFrame …>.
>>>>> So I have a few questions, I’d love to hear your helpful answers!
>>>>> Is there a better way to get the effect of change-class on a NS object than to change its NS:ISA slot?
>>>>> If I am to change the slot, what sort of value should be used? If a foreign pointer, then
>>>>> how do I make an appropriate one (I only know of ccl::%int-to-ptr but that probably isn’t
>>>>> appropriate and if it is then I don’t know how to get the appropriate int)
>>>>> Where is that NSKVONotifying_HemlockFrame defined? Where is it used? Searches of the ccl files don’t show me anything relevant.
>>>> When you see an Objective-C class with a name starting with NSKVONotifying_, it’s because Key-Value Observing has swizzled the isa of the class itself to intercept getter/setter calls and post notifications to observers on its behalf. This can happen for any instance of a class that is observed, and of course Cocoa itself can add observers, they don’t just have to be in developer code.
>>>> That would probably also explain why your own isa-swizzling has stopped working, whatever change to the isa you’re making isn’t compatible with KVO’s own changes to the isa.
>>>> -- Chris
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel