. Re: cross-stack globals, also, file inclusion

Dar Scott dsc at swcp.com
Sat Oct 25 18:02:49 EDT 2003


On Saturday, October 25, 2003, at 03:13 PM, Rob Cozens wrote:

>> Transcript already allows a rich representation of values and is 
>> suitable for representing values to be configured as structures or 
>> whatever for system calls.
>
> OK, Dar, show me and I will grovel in mortification...especially if it 
> involves Boxes.rev:

But I cheated!  It could easily involve boxes, but it need not.  ( I 
need to make that available at my web site, if we are going to babble 
about that.)

I said "representing".  That is not exactly the structure, itself, so 
that is a sort of cheating.  However, one can build binary strings that 
look like structures, if those structures do not include pointers.  I 
mean something else.

What I meant was that one can define a 'description' of such values.  
This can apply to even the structure below.

>
> The first argument to the Mac Interapplication Communication Toolbox 
> function, PPCOpen, is a pointer to a PPCOpen parameter block which 
> includes (at specified byte offsets)...
>
> 	The address of a completion routine
> 	A pointer to a PPCPortRec structure
> 	A pointer to a LocationNameRec structure
> 	resFlag, a SignedByte
> 	networkVisible, a boolean [in Mac OS System format]
>
> Other PPC functions need to see pointers to pointers, Str32s, and 
> values in binary & real formats, integer & longInt arrays.

To keep this discussion simple, this can represented in XML format.  
That includes the structure, pointers to other values, typed values and 
the pointer to the completion routine.  The generic completion routine 
would take its description and extract values from parameters and queue 
up a "send" based on the callback value.  The call to PPCOpen proxy 
would be given an XML description of each of the parameters for the 
actual call.
>
> Show me how to define a PPCOpen parameter block in Transcript, and I 
> will be even more impressed with your skills & wisdom than I am 
> already.

Though a generic scheme can be set up as above, it might be easier to 
use an adhoc scheme in which the proxy somehow gets all the needed info 
and then builds the parameters.  Callbacks might set flags or something 
can be polled instead of queuing up a send, which has problems.  This 
might be faster, too.

>
> ...and notice, I didn't even ask you to address the issue of passing a 
> pointer as an argument.   :{`)

That should fall out in the above scheme.



More information about the Use-livecode mailing list