[Openmcl-devel] Missing header(s) for OpenGL FFI?
Gary Byers
gb at clozure.com
Sat Aug 12 10:09:12 PDT 2006
The error message basically means that the last few attempts to signal
an error themselves resulted in errors. There are a number of things
that can cause this (e.g., redefining some class/method/function that's
basic part of the lisp runtime); if there's enough of the error system
there for it to notice that it's not making progress, that -usually-
implies that thing aren't hosed at a deeper level. Without seeing a
backtrace (if things are un-hosed enough to make that possible), I
can't really guess what the original error would have been or why
attempts to signal it generate further errors.
I would be surprised if any of this had anything to do with incompatibities
between the lisp and a set of interfaces. The format of the information
in the .cdb files hasn't changed since before 1.0; the lisp runtime
depend on a fairly small subset of the stuff in the standard C library
(file I/O, exception context information, some math library functions, not
much else) and most of that stuff is pretty stable between OS releases
(since thousands of other programs depend on the same things.) If there
-were- changes in those interfaces, they'd be more likely to cause
problems when the lisp itself was being compiled than at runtime.
I might be mistaken about some or all of this, but I think that the
first thing that needs to be done is to try to either see a backtrace
from the point where you get the "error reporting error" or, if that's
not possible, to see what I'd need to do to reproduce the problem.
On Sat, 12 Aug 2006, Phil wrote:
> Gary,
>
> I attempted to switch back to the new interfaces and now have a new problem
> compiling a new method (Error in process listener(1): Error reporting error.
> While executing: CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION) so I'm thinking
> that the problem might be a version mismatch between the image (1.0) I'm
> using and interfaces downloaded. If this seems the likely source of my
> problems, which versions of the test images and interfaces should I be
> downloading for PPC-32 for Tiger?
>
> Thanks,
> Phil
>
> On Jul 23, 2006, at 4:03 AM, Gary Byers wrote:
>
>> I'll try to take a look at it; I'm skeptical that anything's actually
>> defined differently and there may be some other bug at play here.
>>
>> On Sat, 22 Jul 2006, Phil wrote:
>>
>>> Apologies for muddying the water with the NSString... I was mainly
>>> asking about NSAttributedString which does appear to be an issue
>>> since the Tiger Interfaces:
>>>
>>> ; New interfaces (060620 Darwin interfaces)
>>>
>>> (CCL::SLET ((TEST-SIZE
>>> (CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>>> 'NS-ATTRIBUTED-STRING
>>> :INIT-WITH-STRING
>>> "testing")
>>> 'SIZE))))
>>>
>>> NonSTRET SEND in (CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>>> 'NS-ATTRIBUTED-STRING
>>> :INIT-WITH-STRING
>>> "testing")
>>> 'SIZE)
>>> [Condition of type SIMPLE-ERROR]
>>>
>>> (CCL::OBJC-MESSAGE-INFO-FLAGS
>>> (CCL::GET-OBJC-MESSAGE-INFO
>>> (CCL::PARSE-MESSAGE
>>> (CDDR '(CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>>> 'NS-ATTRIBUTED-STRING
>>> :INIT-WITH-STRING
>>> "testing")
>>> 'SIZE)))))
>>>
>>> (:AMBIGUOUS T)
>>>
>>> ; Old interfaces (Tiger Cocoa interfaces)
>>>
>>> (CCL::SLET ((TEST-SIZE
>>> (CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>>> 'NS-ATTRIBUTED-STRING
>>> :INIT-WITH-STRING
>>> "testing")
>>> 'SIZE))))
>>>
>>> NIL
>>>
>>> (CCL::OBJC-MESSAGE-INFO-FLAGS
>>> (CCL::GET-OBJC-MESSAGE-INFO
>>> (CCL::PARSE-MESSAGE
>>> (CDDR '(CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>>> 'NS-ATTRIBUTED-STRING
>>> :INIT-WITH-STRING
>>> "testing")
>>> 'SIZE)))))
>>>
>>> (:RETURNS-STRUCTURE T)
>>>
>>> On Jul 16, 2006, at 8:49 PM, Gary Byers wrote:
>>>
>>>> AFAIK, NString has never had or inherited a "size" method.
>>>> NSAttributedString defines such a method, as do a few other classes.
>>>> All of the size methods that're defined in the standard Cocoa headers
>>>> have the same type signature; this means that - with only those
>>>> headers
>>>> in effect - a SEND of a "size" message to any object will use that
>>>> common type signature (and arrange to "return" an NSSize.) This
>>>> has to do with what SEND macroexpands into; sending a message to
>>>> an object that doesn't implement it generally results in a runtime
>>>> error.
>>>>
>>>> ? (ccl::lookup-objc-message-info "size") #S(OBJC-MESSAGE-INFO ...)
>>>> with 3 methods (NSImage, INImageRep,
>>>> NSAttributedString). If you look at the methods, you'll see that
>>>> they each return an NSSize.
>>>>
>>>> If you introduce additional interfaces, it's possible that a new
>>>> "size" method with a different type signature will be declared in
>>>> those interfaces. (This doesn't happen too often; when it does
>>>> happen, it tends to involve message with generic names like "size".)
>>>> When it happens, a warning is printed (since we'd been assuming that
>>>> "size" was unambiguous but now have information to the contrary.)
>>>> Note that this (the introduction of a method with a different type
>>>> signature) can only happen if the class on which that method is
>>>> defined is disjoint from all other classes which define the method.
>>>>
>>>>
>>>> If it doesn't have any additional information about the type of
>>>> the "receiver" object, SEND has to treat the message send as a
>>>> sort of TYPECASE. If the class NSToaster defines "size" to
>>>> return an :int and NSAttributedString, NSImage, and NSImage all
>>>> define it to return an :<NSS>ize, then SEND may have to arrange
>>>> to test at runtime to determine which of these classes the instance
>>>> is a receiver of. An NSString might fail all of these tests; even
>>>> if it didn't, the message send should generate a runtime "message not
>>>> understood" NSException.
>>>>
>>>> I don't believe that there's any substantial difference in content
>>>> between what I packaged as the "Tiger Cocoa interfaces" and the
>>>> cocoa stuff in the "060620 Darwin interfaces", and I don't believe
>>>> that NSString has ever defined a "size" method (unless a string has
>>>> some attributes - like font and point size - it'd be a little hard
>>>> to tell how big it'd be when drawn ...)
>>>>
>>>>
>>>> On Sun, 16 Jul 2006, Phil wrote:
>>>>
>>>>> Thanks for clarifying that point. I dropped in the new interfaces
>>>>> (replacing the previous tiger interface update) and it resulted in
>>>>> one bit of breakage: sending an NSString or NSAttributedString a
>>>>> size message no longer works (nonSTRET SEND). I did a little
>>>>> digging and found that in the previous interfaces this bit of code:
>>>>> (CCL::OBJC-MESSAGE-INFO-FLAGS
>>>>> (CCL::GET-OBJC-MESSAGE-INFO
>>>>> (CCL::PARSE-MESSAGE
>>>>> (CDDR '(CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>>>>> 'NS-STRING
>>>>> :INIT-WITH-STRING
>>>>> "testing")
>>>>> 'SIZE)))))
>>>>> which previously resulted in:
>>>>> (:returns-structure t)
>>>>> now returns:
>>>>> (:ambiguous t)
>>>>>
>>>>> On Jul 14, 2006, at 4:08 PM, Gary Byers wrote:
>>>>>
>>>>>> Sorry if I wasn't clear; the "060620" interfaces are all Tiger-based
>>>>>> (except for the CHUD stuff, which has been enough of a moving target
>>>>>> that I wanted to pick an arbitrary release and stick with it as long
>>>>>> as possible.)
>>>>>> On Fri, 14 Jul 2006, Phil wrote:
>>>>>>> Gary,
>>>>>>> Any chance of getting an updated version of the Tiger interfaces
>>>>>>> or it safe to mix and match? (i.e. should I just drop the darwin
>>>>>>> GL interfaces from darwin on top of the tiger version)
>>>>>>> Thanks,
>>>>>>> Phil
>>>>>>> On Jul 14, 2006, at 4:22 AM, Gary Byers wrote:
>>>>>>>> I think that it was probably an oversight.
>>>>>>>> I can't easily check at the moment (the machine that I used is
>>>>>>>> acting
>>>>>>>> up ...), but I think that the interfaces that were generated on
>>>>>>>> 6/20
>>>>>>>> (in <ftp://clozure.com/pub/testing/openmcl-darwin-
>>>>>>>> interfaces-060620.tar.gz>)
>>>>>>>> contain glext.h (by virtue of the fact that AGL/agl.h #includes
>>>>>>>> it.)
>>>>>>>> On Fri, 14 Jul 2006, Phil wrote:
>>>>>>>>> The GL extension constants and functions (i.e. glext.h) don't
>>>>>>>>> appear
>>>>>>>>> to be included and I was wondering if this was by design or
>>>>>>>>> just an
>>>>>>>>> oversight?
>>>>>>>>> Thanks,
>>>>>>>>> Phil
>>>>>>>>> _______________________________________________
>>>>>>>>> Openmcl-devel mailing list
>>>>>>>>> Openmcl-devel at clozure.com
>>>>>>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>>
>
>
More information about the Openmcl-devel
mailing list