[Openmcl-devel] Missing header(s) for OpenGL FFI?
Phil
pbpublist at comcast.net
Sat Aug 12 11:16:52 PDT 2006
Below is the backtrace but please keep in mind, this and the previous
error I reported *only* occur with the new interfaces. When I switch
back to the older interfaces, the exact same code compiles without
error. Re: redefining something that the runtime needs... all of my
code is in CL-USER (the only exception being a modification to
ccl::sletify to add rect-to-nsrect) and I have not received any
messages indicating that I'm redefining anything. If this
information isn't helpful, let me know and I will work on isolating
the code which results in the error so that you can attempt to
reproduce on your end.
> Error in process listener(1): Error reporting error
> While executing: CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION
> Type :GO to continue, :POP to abort.
> If continued: Skip loading init file.
Type :? for other options.
1 > (:b t)
(F0134130) : 0 (FUNCALL-WITH-ERROR-REENTRY-DETECTION #<COMPILED-
LEXICAL-CLOSURE #x294146>) 112
0 CCL::THUNK: #<COMPILED-LEXICAL-CLOSURE #x294146> ("required")
1 : #<Recursive printing error #x2941EE> ("saved SAVE0")
2 CCL::*ERROR-REENTRY-COUNT*: 1 (:SAVED-SPECIAL)
(F0134150) : 2 (FUNCALL #'#<Anonymous Function #x810655E> [...]) 208
0 CCL::XP: (:INHERITED)
1 CCL::FN: #<Compiled-function CCL::POINTER-IN-CFSTRING-SECTION-P
(Non-Global) #x83BAFBE> (:INHERITED)
2 CCL::PC-OR-INDEX: #<A Mac Pointer #x28> (:INHERITED)
3 CCL::FN-REG: 16 (:INHERITED)
4 CCL::THE-TRAP: 2092832776 (:INHERITED)
5 CCL::FRAME-PTR: #<CCL::FAKE-STACK-FRAME #x29417E> ("optional")
6 #:G27089: #<COMPILED-LEXICAL-CLOSURE #x294146>
> Error in process listener(1): Array index 54 out of bounds for
#<SIMPLE-VECTOR 54> .
> While executing: CCL::POINTER-IN-CFSTRING-SECTION-P
> Type :POP to abort.
Type :? for other options.
2 >
On Aug 12, 2006, at 1:09 PM, Gary Byers wrote:
> 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