Return-Path: Delivered-To: apmail-perl-dev-archive@perl.apache.org Received: (qmail 45065 invoked by uid 500); 30 May 2003 13:06:59 -0000 Mailing-List: contact dev-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@perl.apache.org Received: (qmail 45051 invoked from network); 30 May 2003 13:06:58 -0000 Received: from unknown (HELO secure.exclamationlabs.net) (66.77.29.176) by daedalus.apache.org with SMTP; 30 May 2003 13:06:58 -0000 Received: from modperlcookbook.org (ham-nat.covad.net [68.165.151.221]) (authenticated (0 bits)) by secure.exclamationlabs.net (8.11.6/8.11.6) with ESMTP id h4UD6j402095; Fri, 30 May 2003 08:06:45 -0500 Message-ID: <3ED7575A.9060605@modperlcookbook.org> Date: Fri, 30 May 2003 09:06:34 -0400 From: Geoffrey Young User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stas Bekman CC: dev@perl.apache.org Subject: Re: $parms->info(), take 2 References: <3ED61637.2020102@modperlcookbook.org> <3ED690D0.5@stason.org> <3ED69A13.3050707@modperlcookbook.org> <3ED6A151.50208@stason.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >> all those *.h files are full of both mpxs_ functions and static XS >> functions, with functionaity implemented in one or the other seemingly >> at random. I have no idea how you would choose one format over the >> other, but if the mpxs_ implementation makes you more comfortable, >> that's fine - I'll commit that approach tomorrow. > > > Even though they look random, they aren't. I have tried to document some > of these here: > http://perl.apache.org/docs/2.0/devel/core/explained.html#Adding_Wrappers_for_existing_APIs_and_Creating_New_APIs > wow. here I am raking through the code trying to figure it all out and there it is in print. > Admittedly it's incomplete. I wrote that document when I was coping with > this puzzle myself. As you are now coping with it, it'd help if you > could improve that document. > > I believe Doug's idea was to have to write (and maintain) the minimal > amount of code. So if you have a simple function where the args and > return values can be converted from perl to C and back automatically, > you use just that. If you have an optional number of args you use (...) > and manipulate the stack. If you have a variable number/type of return > args you use XS(). If you read the above section, things might get more > clear. yeah, that actually helps lots. now I know what to do with the others that will come :) thanks stas. anyway, I made the change and committed it this morning - all tests pass and I can use it in real life just fine. more stuff to come... :) --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org For additional commands, e-mail: dev-help@perl.apache.org