[Openmcl-devel] Errors Creating NSTimer

[Phil]

I just did a quick Google search to see what the news was as I  
apparently slept through the reports of MCL going open source.  I was  
an MCL customer years ago (back when it was an Apple product) and  
remember what a nicely integrated Mac OS app/environment it was at  
the time and am curious what Gary or anyone else thought as to what  
this will likely to mean to both MCL and CCL users going forward?   
Specifically, I'm thinking that there probably isn't much in terms of  
capability, setting aside code compatibility needs of MCL users for a  
moment, where CCL doesn't probably lead significantly but I recall  
there was lots of GUI/integration/add-ons in and for MCL that hasn't  
made it into CCL yet.  The discussion over on gmane is fascinating  
I'm just curious, at a high level, what the current plan/thinking is  
and I don't want to get too many happy thoughts into my head about  
what this could mean as I'm guessing that some sort of continuity  
plan for MCL users is a pretty high priority right now.

Thanks,
Phil

On Oct 24, 2007, at 1:34 AM, Brent Fulgham wrote:

> Doh!  Of course...
>
> I guess I'm still reeling from the recent Clozure Common Lisp
> announcement!  Why wasn't that shown on this list (did I miss it?)
>
> -Brent
>
> On Oct 23, 2007, at 10:20 PM, Gary Byers wrote:
>
>> The first argument to any ObjC method should be the "receiver" (the
>> object - instance (usually) or class (sometimes) - that might
>> implement
>> a method on the message.  If this were CLOS, we might call the
>> receiver
>> the first and only specialized parameter.)
>>
>> In the case of
>> #/scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:,
>> the receiver is the class "NSTimer" (which happens to be the value
>> of the variable NS:NS-TIMER.)  The bridge is complaining because
>> the first argument in your calls below either isn't a pointer at
>> all or isn't a pointer to an ObjC class or instance; getting a lisp-
>> level
>> error like that is probably better than trying to send a message to
>> 0.01d0 ...
>>
>>
>> On Tue, 23 Oct 2007, Brent Fulgham wrote:
>>
>>> I'm trying to get the right Cocoa bridge syntax for calling:
>>>
>>> scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:
>>> Returns a new NSTimer object and adds it to the current NSRunLoop
>>> object in the default mode.
>>>
>>> + (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds
>>> target:(id)target selector:(SEL)aSelectoruserInfo:(id)userInfo
>>> repeats:(BOOL)repeats
>>>
>>> NSTimeInterval is just a typedef to double, so I thought that I
>>> could just pass the double value to the function, since this is how
>>> many of the example Objective C programs are written, but this does
>>> not work for a variety of reasons:
>>>
>>> 1.  If I attempt to simply use a bare double, it's not happy:
>>>
>>> (let* ((TimerInterval (ccl::%double-float 0.01)))
>>>           (Timer (#/
>>> scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:
>>> TimeInterval (cocoa-view self) (objc:@selector #/animate) (ccl::
>>> %null-ptr) #$YES)))
>>>
>>>> Error: value 0.009999999776482582D0 is not of the expected type
>>>> MACPTR.
>>>> While executing: CCL::SEND-UNAMBIGUOUS-MESSAGE, in process
>>>> listener(1).
>>>
>>> 2.  If I attempt to use an RLET to allocate the C Type, it's still
>>> not happy:
>>>
>>> (rlet ((TimeInterval :<NST>ime<I>nterval (ccl::%double-float 0.01)))
>>>  (let* (
>>>         (Timer (#/
>>> scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:
>>> TimeInterval (cocoa-view self) (objc:@selector #/animate) (ccl::
>>> %null-ptr) #$YES))))
>>>    ;; add myself to list
>>>    (pushnew Self (animated-views Self))))
>>>
>>>> Error: value #<A Foreign Pointer [stack-allocated] (:* DOUBLE-
>>>> FLOAT) #xB029BE70> is not of the expected type OBJC:OBJC-OBJECT.
>>>> While executing: CCL::SEND-UNAMBIGUOUS-MESSAGE, in process
>>>> listener(1).
>>>
>>> I vaguely remember a mechanism to convert native C types to Cocoa
>>> analogs, but I cannot find documentation of this, and may be mixing
>>> Objective C up with something up.
>>>
>>> What's the correct way to deal with this particular API call?
>>>
>>> Thanks,
>>>
>>> -Brent
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel