Re: [MacPerl] Mac::WASTE

[Arved_37@chebucto.ns.ca]

Quoting Brian McNett <brianmc@telebyte.net>:

> Arved Sandstrom, <Arved_37@chebucto.ns.ca>, wrote:
> 
> > If I may offer a few words of advice. Copy and paste the WASTE public API
> > into a fresh file, and lay the functions out K&R C style, that is:
> >
> > return_value
> > WASTE_func(a, b, c)
> >     datatype_a a;
> >     datatype_b b;
> >     datatype_c c;
> 
> Something like this? (pulled out of WASTE.h and massaged):
> 
> OSErr 
> WENew(*destRect, *viewRect, flags, *we)
>     const LongRect *destRect;
>     const LongRect *viewRect;
>     UInt32 flags;
>     WEReference *we;
> 
> This is doable.
> 

You could do worse than to tackle WENew as your first sub-project. I don't
know for sure, but it may well be that you never need to access the fields
of a WEReference, in which case you can sling it around as an opaque
pointer. That being said, with this call you are nevertheless faced with
two outputs - the OSErr and the *we reference. Do you return a 2-item
list? Do you set it up so you can do

$err = WENew($destRect, $viewRect, $flags, \$we);

and have the value of the $we variable altered? These are the kinds of
things that come up. If you can tackle this then 50% of the work is done.

> > From a cursory looksee I'd say you're probably going to want to do XS,
> > particularly as the WASTE headers use Points, Rects, AE things and so
> > forth, that have already been XS'ed. But don't rule out SWIG until you
> > develop your skeleton interface (that is, the product of the above).
> 
> I figured I was in for some XS code from the outset without having looked 
> at the API, and I KNEW there was a reason for keeping a copy of SWIG 
> handy (which I didn't :-( ).  I'll have to grab another copy at some 
> point.
> 

To the best of my knowledge a bug in MacSWIG (based on the SWIG 1.1p2
patchlevel) prevents it from using the -shadow option for -perl5. I have
a MacPerl + SWIG tutorial coming out shortly which includes a console app
and an MPW tool, both based on the 1.1p5 patchlevel, and which fix this
bug. So you might want to wait on that.

On the same subject, although I'd like to produce CFM68K versions of the
same, a single linker error seems to indicate that the humongous size of
the parser code (a single file) may make this unfeasible. A future SWIG
is supposed to have a much smaller yacc grammar, and CFM68K may have to
wait for that.

> My own first glance reveals the only items NOT already XS'd to be Drag 
> Manager support 
> <Drag.h>, and WASTE's own <LongCoords.h> (needed to support selections 
> larger than 32K).
>

I assume that you're referring to externals. WASTE.h, of course, is not
XS'ed. Unless it's staring me in the face. :-)
 
> I'm beginning to doubt my sanity for taking this up!  I'm going over the 
> documentation with a fine comb, and will probably also post questions to 
> the WASTE mailing list.
> 
Well, it's a big project. It's non-trivial, for sure. There's a lot less
work than a cursory glance at the headers would suggest, as most of the
stuff is of no interest to Perl, but what remains is still more than a
few hours work. :-)

I would also seriously suggest maybe writing up a little C library of your
own, with a non-twinkie struct or two, and 3 or 4 functions that use those
structs in a variety of ways, and return more than one value that needs
to be available in Perl, and just do XS on that until you're comfortable
with the concepts.

Matthias' Toolbox XS files are obvious references. You should also be
aware that the STRUCT keyword (very useful BTW) is something peculiar to
MacPerl XS, so you won't find it in any XS-related POD's.

Arved



---------------------------------------------------------------
 This mail was sent through the Nova Scotia Provincial Server.
 http://nsaccess.ns.ca/mail/ (in development)

===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org