[Openmcl-devel] CCL::%GET-PTR --- When to use?

[David Steuber]

On Jan 7, 2005, at 2:51 AM, Gary Byers wrote:

>
>
> On Fri, 7 Jan 2005, David Steuber wrote:
>
>> I seem to be having endless confusion on when I need to use
>> CCL::%GET-PTR when using the Carbon API for OS X.  I think the problem
>> lies in me not always being able to tell when a MACPTR is like a
>> pointer or a pointer to a pointer.  Has anyone come up with a good
>> heuristic so as not to have to guess so often?
>>
>
>
> It general helps a lot to use things like RLET and PREF; they're
> generally just syntactic sugar for lower-level constructs (including
> %GET-PTR and friends), but they often make otherwise confusing
> distinctions clearer.  (If it's any consolation, I think that C
> programmers - even experienced ones - often find some of the
> same things to be confusing ...)
>
> One thing to bear in mind is that the values of variables bound
> by RLET are always of type "pointer to ...", and it sometimes
> makes things clearer to name the variables with that in mind:

[snip examples]

Thanks.  That's a help.  I still have some confusion left though.  I'm 
not sure about my use of CCL::%GET-PTR here:

(defun show-moon-facts-window (windowref)
   (rlet ((&text :<cfs>tring<r>ef (#_CFBundleCopyLocalizedString 
(#_CFBundleGetMainBundle)
                                                                 
(const-cfstring +moon-facts-text-key+)
                                                                 
(const-cfstring +moon-facts-text-key+)
                                                                 
(ccl::%null-ptr)))
          (moon-facts-box :<c>ontrol<r>ef)
          (moon-facts-control-id :<c>ontrol<id>
                                 :signature +application-signature+
                                 :id +moon-facts-field-id+))
     (#_GetControlByID windowref moon-facts-control-id moon-facts-box)
     (#_ShowWindow windowref)
     (#_SelectWindow windowref)
     (#_SetControlData (ccl::%get-ptr moon-facts-box) 
#$kControlEntireControl #$kControlEditTextCFStringTag
                       (ccl::%foreign-type-or-record-size 
:<cfs>tring<r>ef :bytes) &text)
     (#_CFRelease (ccl::%get-ptr &text))
     (#_Draw1Control (ccl::%get-ptr moon-facts-box))))

In the call to #_CFRelease, I can just pass &text or I can do what I'm 
doing and pass (ccl::%get-ptr &text) with no visible difference.  I 
don't know how clever #_CFRelease is and I don't want to have some 
small memory leak that potentially fragments my address space.  I'm not 
at all sure on how to run the application in a debugger to verify 
anything.

Right now, I use CCL::SAVE-APPLICATION to create an image and then copy 
the lisp kernel and image into an application bundle that can be 
launched from Finder:

(ccl::save-application image-name :toplevel-function #'main)

This makes my current development cycle a rather C like compile and 
run.  Unfortunately, I don't have the benefit of being able to setup 
break points and step through the code in a debugger.  Is this 
something I can do in OpenMCL 0.14.2-p1?  I have been able to include 
SLIME in the image so that I can connect to it from Emacs.  I haven't 
figured out how to trace the code that way though.  I also seem to 
loose the FFI database files needed for #_ and #$ to work properly.

I also have an annoying issue with #_CFBundleCopyLocalizedString 
returning a string that matches +moon-facts-text-key+ instead of the 
one in Localizable.strings.  I don't know what I'm doing wrong there.