[33162] in Perl-Users-Digest
Perl-Users Digest, Issue: 4441 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat May 30 09:09:20 2015
Date: Sat, 30 May 2015 06:09:02 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 30 May 2015 Volume: 11 Number: 4441
Today's topics:
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Why proxy the YouTube data in the following code. <cdalten@gmail.com>
Xsub style <kw@codebykevin.com>
Re: Xsub style <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 29 May 2015 13:50:16 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87fv6f8s53.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
> On 5/28/2015 2:10 PM, C.DeRykus wrote:
>
>> say "same" if join("\0",@list1) eq join("\0",@list2);
>
> Hmmm. Yes, that might work.
>
> Or even...
>
> elsif
> (
> substr($buffer, 0, 16) eq
> join '', map {chr}
> 48,38,178,117,142,102,207,17,166,217,0,170,0,98,206,108
> )
> {
> $new_suffix = '.wma';
> }
>
> $buffer is the first 50 bytes of a file. What I'm doing here is
> looking at the first 50 bytes of each file in a set of files of
> unknown type, and using that info to decide what types of files
> I'm dealing with, then set the extensions accordingly.
Perl handles arbitrary binary data in strings just fine. Including that
it supports building binary strings from numerically represented input
bytes, ie your
join '', map {chr} 48,38,178,117,142,102,207,17,166,217,0,170,0,98,206,108
can also be expressed as
pack('C*', 48,38,178,117,142,102,207,17,166,217,0,170,0,98,206,108)
'C' here referring to the C type 'unsigned char'.
[...]
> Of course I could skip the "join '', map {chr}" and just make strings
> out of the byte patterns like so:
>
> "\x3b\x25\xd2\x1e\x6b\xc2\x97\x8e\xa7"
>
> BUT, that would require converting all the numbers form decimal to hex,
> and involves lots of ugly \x\x\x\x\x\x\x\.
One of the nice things about perl is that it can run arbitrary Perl code while compiling so the pack('C*', ...) can also be used like this
use constant SIGNATURE => pack('C*', ....);
------------------------------
Date: Fri, 29 May 2015 13:50:41 -0700 (PDT)
From: Chad <cdalten@gmail.com>
Subject: Re: Why proxy the YouTube data in the following code.
Message-Id: <19ab0bd4-f5e6-473c-9ac4-fb4d67db5754@googlegroups.com>
Nope. That answers everything. Thanks.
------------------------------
Date: Thu, 28 May 2015 21:11:28 -0400
From: Kevin Walzer <kw@codebykevin.com>
Subject: Xsub style
Message-Id: <mk8e9p$3dg$1@dont-email.me>
I'm working on a Perl extension written in C and have been reading the
Perl man pages on xsubs (perlxs and perlxstut). I've found the
documentation very hard to follow, to be honest. The style outlined for
creating Perl xsubs is different from C coding in other languages, cf:
void
alpha()
PPCODE:
ST(0) = newSVpv("Hello World",0);
sv_2mortal(ST(0));
XSRETURN(1);
SV *
beta()
CODE:
RETVAL = newSVpv("Hello World",0);
OUTPUT:
RETVAL
In looking for various examples of Perl extensions using the xsub API, I
ran across a very different style that seems much easier to understand,
as referenced here:
http://www.slideshare.net/typester/hacking-mac-osx-cocoa-api-from-perl
Here's a small example:
XS(hello) {
dXSARGS;
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSLog(@"Hello!");
[pool drain];
XSRETURN(0);
}
This example creates a Perl subroutine called "hello," calls into C code
(Objective-C, in this case), and then returns.
The second example is much easier for me to model in my head. I want a
C-based subroutine in Perl called "hello," and so I wrap the command in
an XS { } call, and then call it from Perl; it offers a very clean
mapping from Perl to C.
Is there any reason this style of extending Perl in C is not outlined in
any of the official docs, as far as I can find? Have I missed something?
The canonical example above is opaque, at least to my eye, while the
latter example is much easier to grok.
If anyone knows of some additional referneces that highlight the latter
style of xsub programming, I'd love to see them.
Thanks,
Kevin
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
------------------------------
Date: Fri, 29 May 2015 15:45:13 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Xsub style
Message-Id: <87wpzr8mti.fsf@doppelsaurus.mobileactivedefense.com>
Kevin Walzer <kw@codebykevin.com> writes:
> I'm working on a Perl extension written in C and have been reading the
> Perl man pages on xsubs (perlxs and perlxstut). I've found the
> documentation very hard to follow, to be honest. The style outlined
> for creating Perl xsubs is different from C coding in other languages,
> cf:
>
> void
> alpha()
> PPCODE:
> ST(0) = newSVpv("Hello World",0);
> sv_2mortal(ST(0));
> XSRETURN(1);
> SV *
> beta()
> CODE:
> RETVAL = newSVpv("Hello World",0);
> OUTPUT:
> RETVAL
>
>
> In looking for various examples of Perl extensions using the xsub API,
> I ran across a very different style that seems much easier to
> understand, as referenced here:
>
> http://www.slideshare.net/typester/hacking-mac-osx-cocoa-api-from-perl
>
> Here's a small example:
>
> XS(hello) {
> dXSARGS;
> NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
> NSLog(@"Hello!");
> [pool drain];
> XSRETURN(0);
> }
>
> This example creates a Perl subroutine called "hello," calls into C
> code (Objective-C, in this case), and then returns.
This examples ignores most of the XS macros in favour of writing
corresponding C code by hand. That's surely a point in favour of "real
men dig tunnels with tea spoons and clean the floor with a tooth brush[*]"
(and suggesting that they don't know how to use any other tools would be
disingenious) but I can see little else in it.
> The second example is much easier for me to model in my head. I want a
> C-based subroutine in Perl called "hello," and so I wrap the command
> in an XS { } call, and then call it from Perl; it offers a very clean
> mapping from Perl to C.
>
> Is there any reason this style of extending Perl in C is not outlined
> in any of the official docs, as far as I can find?
For the sake of example, let's assume the POSIX fsync call is to be made
available to perl (not as useless as it may sound because POSIX::fsync
doesn't call fsync). As XS routine, this looks like this:
----
int
fsync(fd)
int fd
----
This even won't be over unfamiliar to someone knowing C as the 'put the
return value on a lines of its own' is not that uncommon as convention
and the other parts is just a K&R-style function preamble. The
corresponding C code is (for perl 5.10.1 and 5.14.2)
----
XS(XS__fsync); /* prototype to pass -Wmissing-prototypes */
XS(XS__fsync)
{
#ifdef dVAR
dVAR; dXSARGS;
#else
dXSARGS;
#endif
if (items != 1)
croak_xs_usage(cv, "fd");
{
int fd = (int)SvIV(ST(0));
int RETVAL;
dXSTARG;
RETVAL = fsync(fd);
XSprePUSH; PUSHi((IV)RETVAL);
}
XSRETURN(1);
}
----
In case writing all of this suits you better, no one's going to stop you
from it, you're just working more than necessary in order to perform
worse ...
[*] ... and put their underpants in the diswasher ...
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4441
***************************************
