[Openmcl-devel] slet/rlet with C functions?

Phil pbpublist at comcast.net
Thu Aug 17 19:48:23 PDT 2006


And here I was thinking that this mechanism was for Obj-C sends  
only... thanks, that worked and was what I needed to know.

A couple of followup questions (one OpenMCL specific and the other,  
more general Lisp):

1) Would it be possible/feasible to modify sletify as the last test  
before failure to do a (inverse?) lookup, if it is an external call,  
on the function in question via the interfaces to determine if the  
function returns a structure and if so, what kind of structure?

2) I tried to track down the answer the first question myself but  
didn't get very far as I lacked the knowledge to effectively get to  
find the appropriate entry points in the source code.  I'm familiar  
with static analysis tools like XREF and am looking for pointer on  
good tools or techniques to perform dynamic analysis of code?  For  
example,  given an arbitrary lisp expression, is it possible to see  
step-by-step how the expression is being processed by the reader from  
a reader macro and/or macroexpansion standpoint?  I know I can pass  
it through macroexpand or macroexpand-1 for full or single-step  
macroexpansion, respectively.  But that doesn't help with reader  
macros and seems rather tedious when dealing with an expression which  
has many levels of macroexpansion (i.e. it seems most important to  
see the progression of ns-make-rect...->:<NSR>ect...->%stack-block...  
rather than the minutia in the end result)  Maybe the way I'm going  
about things is wrong... if so please let me know as I'm looking for  
pointers on the most effective way to get to the bottom of questions  
like this when one doesn't have detailed knowledge of the code behind  
an expression.

On Aug 17, 2006, at 6:35 PM, Gary Byers wrote:

> A C (or ObjC) function that returns a structure does so by
>  a( accepting a pointer to an instance of such a structure as a hidden
>     first argument
>  b) filling in the values of that first argument's fields
>  c) returning no meaningful conventional value, i.e., behaving like
>     something declared to return "void".
>
> If there were a function that "created" a CGRect from 4 floats, it  
> might
> be prototyped something like:
>
> CGRect MakeCGRect(float x, float y, float width, float height);
>
> but it's actually implemted as if it were:
>
> void MakeCGRect(CGRect *result, float x, float y, float width,  
> float height)
> {
>   result.origin.x = x;
>   result.origin.y = y;
>   result.size.width = width;
>   result.size.height = height;
>   return;
> }
>
> I'm pretty sure that the interface translator recognizes struture- 
> returning
> functions and adds the invisible argument (the "return" pointer) to  
> the
> foreign function's argument list, so that your example could be:
>
>
> (ccl::slet ((r (ccl::ns-make-rect 0.0 0.0 100.0 100.0)))
>   (rlet ((r2 :<NSRect))
>     (#_CGRectIntegral r2 r)))  ; r2/result passed as 1st arg
>
>
> (SLET ((var form)) ...)
>
> does this for you and hides some of that ugliness, but it only works
> when it can tell that each "form" is a foreign function call that
> nominally returns a structure.  It can tell that for ObjC message  
> sends
> and for a few built-in magic constructors; I'm not sure how easy/hard
> it would be to generalize.
>
>
>
> On Thu, 17 Aug 2006, Phil wrote:
>
>> I'm trying to figure out how to use slet/rlet with a C function call
>> such as:
>>
>> (ccl::slet* ((r (ccl::ns-make-rect 0.0 0.0 100.0 100.0))
>> 		   (r2 (#_CGRectIntegral r))))
>>
>> but of course slet doesn't know how to deal with #_CGRectIntegral and
>> I haven't had any better luck with rlet, so... is there currently a
>> comparable way of dealing with structures defined via the interface
>> files and C functions?
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>




More information about the Openmcl-devel mailing list