[Openmcl-devel] Errors Creating NSTimer

[Andrew Shalit]

Clozure hasn't made an announcement about our plans because we haven't  
made plans yet!  We're still digesting all the input we've gotten from  
MCL people, following up to get more details, and thinking about what  
would make most sense and be most interesting.

There are two things that we have decided: we will be changing the  
name of OpenMCL to Clozure CL, and we are continuing to work on the  
Mac OS-based IDE.  We hope to have a more general release of that  
soon.  (It's currently available as an example project if you update  
from CVS or SVN, rebuild, and then do "(require :cocoa-application)".)

We'll share more news as we have it and ask more questions as we have  
them.

Andrew


On Oct 24, 2007, at 3:34 PM, Phil wrote:

> 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
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel