[Openmcl-devel] Errors Creating NSTimer

[Phil]

Andrew,

Fair enough and thanks for the reply.  You might want to think about  
running a similar survey here to what was posted on gmane (obviously  
tailored for Clozure CL users) and communicating things that are  
being worked on or would be if funding could be obtained (i.e.  
solicit contributions to see if, in aggregate, it can be funded.)   
Maybe it is and I'm just not looking in the right place... in that  
case: where should I be checking?  You might be surprised to find  
some people willing to donate funds and/or time if it would help get  
some things done but may not individually be able to provide  
everything that is needed.  I was banging my head on my desk after  
reading that there apparently is a 32-bit Intel version coming... I  
spent ~6 months rewriting code in Obj-C because largely because it  
was previously stated that this wasn't going to happen.  Don't get me  
wrong: this is great news, but I would have happily donated some  
funds to help make this happen and spent those 6 months getting other  
things done on my end... but that didn't appear to be an option at  
the time so I went with plan B.

Thanks,
Phil

On Oct 24, 2007, at 3:48 PM, Andrew Shalit wrote:

> 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
>