[32962] in Perl-Users-Digest
Perl-Users Digest, Issue: 4238 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 19 09:09:18 2014
Date: Thu, 19 Jun 2014 06:09:03 -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 Thu, 19 Jun 2014 Volume: 11 Number: 4238
Today's topics:
Re: Can be this be optimized? <rm-dash-bau-haus@dash.futureapps.de>
Re: Can be this be optimized? <rweikusat@mobileactivedefense.com>
Re: Can be this be optimized? <rweikusat@mobileactivedefense.com>
Re: Can be this be optimized? <derykus@gmail.com>
Re: Can be this be optimized? <rweikusat@mobileactivedefense.com>
Re: Can be this be optimized? <derykus@gmail.com>
Re: Can be this be optimized? <rweikusat@mobileactivedefense.com>
Re: Can be this be optimized? <rweikusat@mobileactivedefense.com>
Re: Can be this be optimized? <derykus@gmail.com>
Re: Can be this be optimized? <rweikusat@mobileactivedefense.com>
Need feedback on XS file <kw@codebykevin.com>
Re: Need feedback on XS file <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 16 Jun 2014 18:06:27 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Can be this be optimized?
Message-Id: <539f1601$0$6616$9b4e6d93@newsspool4.arcor-online.net>
On 15.06.14 19:20, gamo wrote:
> El 15/06/14 17:13, Peter J. Holzer escribió:
>>> Is there any chance that a solution with substr could be
>>> >efficient?
>> Why don't you try it? I doubt it, but then I was surprised that your
>> explicit loop was faster than using scalar to count the matches.
>>
>> Using index() is about as fast as your original version.
>>
>>
>
> Tried with substr, it's a lot slower.
index(); maybe a little boring, but flexible, and a little
faster than your original,
sub count4 { # string, string -> int
my ($c, $p) = (0, 0);
while (($p = index($_[1], $_[0], $p)) > -1) {
++$c, ++$p;
}
return $c;
}
------------------------------
Date: Mon, 16 Jun 2014 17:52:29 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can be this be optimized?
Message-Id: <87y4ww4x0y.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 15.06.14 19:20, gamo wrote:
>> El 15/06/14 17:13, Peter J. Holzer escribió:
>>>> Is there any chance that a solution with substr could be
>>>> >efficient?
>>> Why don't you try it? I doubt it, but then I was surprised that your
>>> explicit loop was faster than using scalar to count the matches.
>>>
>>> Using index() is about as fast as your original version.
>>>
>>>
>>
>> Tried with substr, it's a lot slower.
>
> index(); maybe a little boring, but flexible, and a little
> faster than your original,
>
> sub count4 { # string, string -> int
> my ($c, $p) = (0, 0);
> while (($p = index($_[1], $_[0], $p)) > -1) {
> ++$c, ++$p;
> }
> return $c;
> }
Here's another mid-field method:
sub count5
{
my $s = $_[1];
return $s =~ s/$_[0]/x/g;
}
------------------------------
Date: Mon, 16 Jun 2014 18:55:27 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can be this be optimized?
Message-Id: <87tx7k4u40.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
[count characters in a string]
>> sub count4 { # string, string -> int
>> my ($c, $p) = (0, 0);
>> while (($p = index($_[1], $_[0], $p)) > -1) {
>> ++$c, ++$p;
>> }
>> return $c;
>> }
>
> Here's another mid-field method:
>
> sub count5
> {
> my $s = $_[1];
> return $s =~ s/$_[0]/x/g;
> }
Here's another which is bad for short strings but does (for me) amazingly
good for long ones:
sub count6
{
my $c = 0;
my $first;
for ($_[1]) {
/\G[^$_[0]]+/gc and $first = pos(), redo;
/\G$_[0]+/gc and $c += pos() - $first, redo;
}
return $c;
}
------------------------------
Date: Tue, 17 Jun 2014 13:09:45 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Can be this be optimized?
Message-Id: <lnq7b3$3ll$1@speranza.aioe.org>
On 6/15/2014 11:41 AM, Rainer Weikusat wrote:
> gamo <gamo@telecable.es> writes:
>> El 15/06/14 15:47, Rainer Weikusat escribió:
>>> gamo <gamo@telecable.es> writes:
>>>> sub count{
>>>> my ($char, $string) = @_;
>>>> my $c = 0;
>>>> ++$c while ($string =~ /$char/g);
>>>> return $c;
>>>> }
>
> [...]
>
>>> my @counters = map { eval("sub { \$_[0] =~ tr/$_// }") } 'A' .. 'Z';
>>> sub count3 {
>>> &{$counters[ord(shift) - 65]};
>>> }
>>>
>>>
>>> print STDERR (count3($char, $string), "\n");
>>>
>>>
>>> timethese(-4,
>>> {
>>> count => sub { count($char, $string) },
>>> count2 => sub { count2($char, $string)},
>>> count3 => sub { count3($char, $string)}
>>> });
>>>
>>
>> Thank you. 'count3' is faster but do the counting before,
>> I think. It's confuse for me.
>
> Some explanations: For the purpose of this example, 'characters' are
> restricted to the uppercase letters A - Z. Further, ASCII enconding is
> assumed.
>
> my @counters = map { eval("sub { \$_[0] =~ tr/$_// }") } 'A' .. 'Z';
>
> This builds an array of 26 subroutines each counting occurrence of one of
> the possible input characters in its first argument. In order to avoid
> copying this argument (and because the subroutine code is really
> simple), it accesses that via @_ as $_[0].
>
> sub count3 {
> &{$counters[ord(shift) - 65]};
> }
>
> This is a subroutine which expects the character supposed to be counted
> as first argument and the string as second. It shifts the first argument
> of its @_ and converts that into an ASCII codepoint via ord. Subtracting
> 65 (the ASCII code of A) from this numbers results in the array index
> for the counting subroutine counting the correct character. The result
> of the expression
>
> $counters[ord(shift) - 65]
>
> is a reference to this subroutine. It is then invoked via & without
> arguments which means the invoked subroutine uses the @_ of the invoking
> subroutine. Since the original first argument was shifted away, the
> string to be searched is now the new $_[0] which was what the called
> subroutine expects.
> ...
>
I'm inspired to engage in bit of dark humor.
Performance not too shabby either:
sub CountDarkula {
my ($char, $string) = @_;
goto('A'..'Z')[ord($char)-65];
A: return $string =~ tr/A//;
B: return $string =~ tr/B//;
C: return $string =~ tr/C//;
...
Z: return $string =~ tr/Z//;
}
--
Charles DeRykus
------------------------------
Date: Tue, 17 Jun 2014 21:40:46 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can be this be optimized?
Message-Id: <878uov5kxd.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 6/15/2014 11:41 AM, Rainer Weikusat wrote:
>> gamo <gamo@telecable.es> writes:
>>> El 15/06/14 15:47, Rainer Weikusat escribió:
>>>> gamo <gamo@telecable.es> writes:
>>>>> sub count{
>>>>> my ($char, $string) = @_;
>>>>> my $c = 0;
>>>>> ++$c while ($string =~ /$char/g);
>>>>> return $c;
[...]
>> my @counters = map { eval("sub { \$_[0] =~ tr/$_// }") } 'A' .. 'Z';
[...]
>> sub count3 {
>> &{$counters[ord(shift) - 65]};
>> }
[...]
> I'm inspired to engage in bit of dark humor.
> Performance not too shabby either:
>
>
> sub CountDarkula {
> my ($char, $string) = @_;
> goto('A'..'Z')[ord($char)-65];
> A: return $string =~ tr/A//;
> B: return $string =~ tr/B//;
> C: return $string =~ tr/C//;
> ...
> Z: return $string =~ tr/Z//;
> }
I fail to understand the punchline: Ultimatively, anything which can be
done with any 'structured programming' construct can also be implemented
with conditional gotos. That's not exactly an exciting, new
discovery. Further (that's a daring generalization from a few personal
experiences) any use of any 'structured programming construct' will
appear to be nothing but 'something which somehows gotos' to someone
unfamiliar with it who is also old enough to remember goto as facility
instead of just as traditional taboo.
Technically, you've replaced two lines of code with 27, 26 of which are
almost identical (that's a maintenance disaster waiting to happen) and
the operations runs somewhat slower now since 'goto' is not cheap in
Perl.
Conclusion: Anything can be reimplemented such that more code results in
a slower program ....
------------------------------
Date: Tue, 17 Jun 2014 15:56:33 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Can be this be optimized?
Message-Id: <lnqh3u$rnn$1@speranza.aioe.org>
On 6/17/2014 1:40 PM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 6/15/2014 11:41 AM, Rainer Weikusat wrote:
>> ...
>>
>>
>> sub CountDarkula {
>> my ($char, $string) = @_;
>> goto('A'..'Z')[ord($char)-65];
>> A: return $string =~ tr/A//;
>> B: return $string =~ tr/B//;
>> C: return $string =~ tr/C//;
>> ...
>> Z: return $string =~ tr/Z//;
>> }
>
> I fail to understand the punchline: Ultimatively, anything which can be
> done with any 'structured programming' construct can also be implemented
> with conditional gotos. That's not exactly an exciting, new
> discovery. Further (that's a daring generalization from a few personal
> experiences) any use of any 'structured programming construct' will
> appear to be nothing but 'something which somehows gotos' to someone
> unfamiliar with it who is also old enough to remember goto as facility
> instead of just as traditional taboo.
>
> Technically, you've replaced two lines of code with 27, 26 of which are
> almost identical (that's a maintenance disaster waiting to happen) and
> the operations runs somewhat slower now since 'goto' is not cheap in
> Perl.
>
> Conclusion: Anything can be reimplemented such that more code results in
> a slower program ....
>
Gosh, I'd think "dark humor" would suffice to drive a stake through
its heart without additional help. Yes, the program sucks "blood"
with lots of added code and no one in his right mind would use it.
But something like ...[ord($char)-65] might be viewed as a bit dark
and byzantine too. Somewhat rickety and special purpose too.
IMO speed issues start to get dracula-like quickly. They suck alot
out of you for very dubious gain. The original solutions looked
clear enough. Of course, it's interesting and useful to learn how
to speed it up as well.
--
Charles DeRykus
--
Charles DeRykus
------------------------------
Date: Wed, 18 Jun 2014 14:43:27 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can be this be optimized?
Message-Id: <87tx7ifi4g.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 6/17/2014 1:40 PM, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:
>>> On 6/15/2014 11:41 AM, Rainer Weikusat wrote:
>>>
>>> sub CountDarkula {
>>> my ($char, $string) = @_;
>>> goto('A'..'Z')[ord($char)-65];
>>> A: return $string =~ tr/A//;
>>> B: return $string =~ tr/B//;
>>> C: return $string =~ tr/C//;
>>> ...
>>> Z: return $string =~ tr/Z//;
>>> }
>>
>> I fail to understand the punchline: Ultimatively, anything which can be
>> done with any 'structured programming' construct can also be implemented
>> with conditional gotos. That's not exactly an exciting, new
>> discovery.
[...]
> Gosh, I'd think "dark humor" would suffice to drive a stake through
> its heart without additional help. Yes, the program sucks "blood"
> with lots of added code and no one in his right mind would use it.
Ah. Which part of it was supposed to be funny? I just see a bad use of a
computed goto here (implement a 'static' multiway conditional) and even
the static multiway conditional alone would be a bad solution to the
original problem. I can only guess why you consider computed gotos to
implement 'static' multiway conditionals to be 'closely similar' to
higher-order code (code which generates other code) designed to avoid
them.
> But something like ...[ord($char)-65] might be viewed as a bit dark
> and byzantine too. Somewhat rickety and special purpose too.
[rw@sable]~#perldoc -f ord
ord EXPR
ord Returns the numeric (the native 8-bit encoding, like
ASCII or EBCDIC, or Unicode) value of the first character of
EXPR. If EXPR is omitted, uses $_.
Since perl doesn't support using anything other than 'integral numbers'
for arrays and also tries to hide the fact that characters are
represented as numbers, there's no other way to index an array 'by
character'. The alphabet is a pretty well known sequence and that some
duckheads from IBM felt compelled to reinvent that half a century ago is
not a problem to be dealt with without reason.
------------------------------
Date: Wed, 18 Jun 2014 14:48:21 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can be this be optimized?
Message-Id: <87ppi6fhwa.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Charles DeRykus <derykus@gmail.com> writes:
[...]
>> But something like ...[ord($char)-65] might be viewed as a bit dark
>> and byzantine too. Somewhat rickety and special purpose too.
>
> [rw@sable]~#perldoc -f ord
> ord EXPR
> ord Returns the numeric (the native 8-bit encoding, like
> ASCII or EBCDIC, or Unicode) value of the first character of
> EXPR. If EXPR is omitted, uses $_.
>
> Since perl doesn't support using anything other than 'integral numbers'
> for arrays and also tries to hide the fact that characters are
> represented as numbers, there's no other way to index an array 'by
> character'. The alphabet is a pretty well known sequence and that some
> duckheads from IBM felt compelled to reinvent that half a century ago is
> not a problem to be dealt with without reason.
In case this is unclear without it: I completely agree. But I didn't
design any part of this mess, I just have to live with it.
------------------------------
Date: Wed, 18 Jun 2014 12:58:24 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Can be this be optimized?
Message-Id: <lnsr1r$ug$1@speranza.aioe.org>
On 6/18/2014 6:43 AM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 6/17/2014 1:40 PM, Rainer Weikusat wrote:
>>> Charles DeRykus <derykus@gmail.com> writes:
>>>> On 6/15/2014 11:41 AM, Rainer Weikusat wrote:
>>>>
>>>> sub CountDarkula {
>>>> my ($char, $string) = @_;
>>>> goto('A'..'Z')[ord($char)-65];
>>>> A: return $string =~ tr/A//;
>>>> B: return $string =~ tr/B//;
>>>> C: return $string =~ tr/C//;
>>>> ...
>>>> Z: return $string =~ tr/Z//;
>>>> }
>>>
>>> I fail to understand the punchline: Ultimatively, anything which can be
>>> done with any 'structured programming' construct can also be implemented
>>> with conditional gotos. That's not exactly an exciting, new
>>> discovery.
>
> [...]
>
>> Gosh, I'd think "dark humor" would suffice to drive a stake through
>> its heart without additional help. Yes, the program sucks "blood"
>> with lots of added code and no one in his right mind would use it.
>
> Ah. Which part of it was supposed to be funny? I just see a bad use of a
> computed goto here (implement a 'static' multiway conditional) and even
> the static multiway conditional alone would be a bad solution to the
> original problem. I can only guess why you consider computed gotos to
> implement 'static' multiway conditionals to be 'closely similar' to
> higher-order code (code which generates other code) designed to avoid
> them.
>
>> But something like ...[ord($char)-65] might be viewed as a bit dark
>...nt
The humor was a bit understated. My point was the inordinate amount of
effort spent to micro-optimize for a bit more speed. The computed goto
was a "funny" example of what might happen if carried to extremes. The
victim starts to look pale and keep late hours in his craving for speed.
Swap "speed" for "blood" and it's kinda like Dracula. (See "Nachts, wenn
Dracula erwacht": https://www.youtube.com/watch?v=3PGq8tXbgcg)
Some of the techniques are quite ingenious however.
--
Charles DeRykus
------------------------------
Date: Wed, 18 Jun 2014 21:37:06 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can be this be optimized?
Message-Id: <8738f2eyz1.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 6/18/2014 6:43 AM, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:
>>> On 6/17/2014 1:40 PM, Rainer Weikusat wrote:
>>>> Charles DeRykus <derykus@gmail.com> writes:
>>>>> On 6/15/2014 11:41 AM, Rainer Weikusat wrote:
>>>>>
>>>>> sub CountDarkula {
>>>>> my ($char, $string) = @_;
>>>>> goto('A'..'Z')[ord($char)-65];
>>>>> A: return $string =~ tr/A//;
>>>>> B: return $string =~ tr/B//;
>>>>> C: return $string =~ tr/C//;
>>>>> ...
>>>>> Z: return $string =~ tr/Z//;
>>>>> }
>>>>
>>>> I fail to understand the punchline: Ultimatively, anything which can be
>>>> done with any 'structured programming' construct can also be implemented
>>>> with conditional gotos. That's not exactly an exciting, new
>>>> discovery.
>>
>> [...]
>>
>>> Gosh, I'd think "dark humor" would suffice to drive a stake through
>>> its heart without additional help. Yes, the program sucks "blood"
>>> with lots of added code and no one in his right mind would use it.
>>
>> Ah. Which part of it was supposed to be funny? I just see a bad use of a
>> computed goto here (implement a 'static' multiway conditional) and even
>> the static multiway conditional alone would be a bad solution to the
>> original problem. I can only guess why you consider computed gotos to
>> implement 'static' multiway conditionals to be 'closely similar' to
>> higher-order code (code which generates other code) designed to avoid
>> them.
>>
>>> But something like ...[ord($char)-65] might be viewed as a bit dark
>>...nt
>
> The humor was a bit understated. My point was the inordinate amount of
> effort spent to micro-optimize for a bit more speed. The computed
> goto was a "funny" example of what might happen if carried to
> extremes. The victim starts to look pale and keep late hours in his
> craving for speed.
That's an assortment of very traditional prejudices about people
programming computers which would be much more suited to some
'mainstream' newspaper or magazine ...
------------------------------
Date: Mon, 16 Jun 2014 23:30:47 -0400
From: Kevin Walzer <kw@codebykevin.com>
Subject: Need feedback on XS file
Message-Id: <lnocph$d7o$1@dont-email.me>
I'm trying to develop a Perl extension using the XS API and I would like
to get some feedback to see if I am on the right track. XS is rather
complex and I am not sure I am doing things correctly.
The code below provides a basic Perl interface to the Mac Apple Event
Manager API. Apple Events are a form of IPC that allow apps to drive
other apps and exchange data with them. Essentially, an app will
register an event class with the system corresponding to that app and
also register individual event ID's with that event class, corresponding
to specific app commands or functions.
The code below does the following:
1. The first function, InstallAEEvents, registers an event class, event
ID, and Perl subroutine with the OS and stores this data in a
CFDictionary (Mac-native array-like datatype). It also registers a
second function, AEScriptsAEHandler, to parse the Apple Events and
dispatch them to specific Perl subroutine.
2. AEScriptsAEHandler parses an Apple Event, retrieves the associated
Perl subroutine from the dictionary, runs the subroutine in the Perl
interpreter via call_argv, and passes the output of the subroutine back
to the Apple Event API; it is then dispatched to the original requesting
app.
Any feedback on the code below is appreciated; I would like to make sure
I am not missing any necessary macro's, etc. I have read both the Perl
XS and the Perlcall tutorials.
Thanks, Kevin
------
#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include <CoreFoundation/CoreFoundation.h>
#include <Carbon/Carbon.h>
#include <Cocoa/Cocoa.h>
#include <CoreServices/CoreServices.h>
#include "ppport.h"
MODULE = Mac::AEM PACKAGE = Mac::AEM
//Register Apple Events with OS X and associate them with a Perl
subroutine via CFDictionary.
void InstallAEEvents (SV *myeventclass, SV *myeventid, SV *perleventsub) {
OSErr err;
OSType eventClass;
OSType eventID;
CFStringRef stringeventClass;
CFStringRef stringeventID;
CFStringRef eventFunction;
CFMutableDictionaryRef aeDict;
//create the CFDictionary that will hold the Apple Event ID's and
associated Perl subroutines
aeDict = CFDictionaryCreateMutable(NULL, 0,
&kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
//convert char args to CFStringRef, insert into dictionary
stringeventClass = CFStringCreateWithCString(kCFAllocatorDefault,
myeventclass, kCFStringEncodingUTF8);
stringeventID = CFStringCreateWithCString(kCFAllocatorDefault,
myeventid, kCFStringEncodingUTF8);
eventFunction = CFStringCreateWithCString(kCFAllocatorDefault,
perleventsub, kCFStringEncodingUTF8);
CFDictionarySetValue(aeDict, stringeventID, eventFunction);
//convert these strings to OSTypes for registration with Apple Event
server
eventClass = UTGetOSTypeFromString(stringeventClass);
eventID = UTGetOSTypeFromString(stringeventID);
err = AEInstallEventHandler(eventClass, eventID,
NewAEEventHandlerUPP(AEScriptsAEHandler), 0, false);
if (err != noErr) {
croak("Unable to install custom Apple Events handlers.");
}
CFRelease(stringeventID);
CFRelease(stringeventClass);
CFRelease(eventFunction);
}
//Upon receiving an Apple Event, retrieve the associated Perl subroutine
from CFDictionary and any parameter from Apple Event itself.
static OSErr AEScriptsAEHandler(const AppleEvent *theAppleEvent,
AppleEvent *reply, long refCon) {
OSErr err = noErr;
AEDesc returnData;
AEEventID eventID;
OSType typeCode;
AEDesc directParameter;
CFStringRef stringeventID;
//Read the AppleEvent
err = AEGetParamDesc(theAppleEvent, keyDirectObject, typeUnicodeText,
&returnData);
//get event ID to look up in CFDictionary
err = AEGetAttributePtr(theAppleEvent, keyEventIDAttr, typeType,
NULL, &eventID, sizeof(eventID), NULL );
//get direct parameter
err = AEGetKeyDesc(theAppleEvent, keyDirectObject, typeType,
&directParameter);
SV *parameter = &directParameter;
CFTypeRef perlsub;
stringeventID = UTCreateStringForOSType(eventID);
perlsub = CFDictionaryGetValue(aeDict, stringeventID);
//call perl function from CFDictionary, in scalar context
SV *output = call_argv(perlsub, G_SCALAR, parameter);
if (err == noErr) {
AEPutParamPtr(reply, keyDirectObject, typeUTF8Text, output,
strlen(output)+1);
} else {
croak("Unable to return AppleScript data.");
}
return err;
}
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
------------------------------
Date: Tue, 17 Jun 2014 16:59:53 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Need feedback on XS file
Message-Id: <87zjhb5xxi.fsf@sable.mobileactivedefense.com>
Kevin Walzer <kw@codebykevin.com> writes:
> I'm trying to develop a Perl extension using the XS API and I would
> like to get some feedback to see if I am on the right track. XS is
> rather complex and I am not sure I am doing things correctly.
[...]
> #define PERL_NO_GET_CONTEXT
> #include "EXTERN.h"
> #include "perl.h"
> #include "XSUB.h"
> #include <CoreFoundation/CoreFoundation.h>
> #include <Carbon/Carbon.h>
> #include <Cocoa/Cocoa.h>
> #include <CoreServices/CoreServices.h>
>
> #include "ppport.h"
>
>
> MODULE = Mac::AEM PACKAGE = Mac::AEM
>
>
> //Register Apple Events with OS X and associate them with a Perl
> subroutine via CFDictionary.
> void InstallAEEvents (SV *myeventclass, SV *myeventid, SV *perleventsub) {
>
> OSErr err;
> OSType eventClass;
> OSType eventID;
> CFStringRef stringeventClass;
> CFStringRef stringeventID;
> CFStringRef eventFunction;
> CFMutableDictionaryRef aeDict;
>
> //create the CFDictionary that will hold the Apple Event ID's and
> associated Perl subroutines
> aeDict = CFDictionaryCreateMutable(NULL, 0,
> &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
>
>
> //convert char args to CFStringRef, insert into dictionary
> stringeventClass = CFStringCreateWithCString(kCFAllocatorDefault,
> myeventclass, kCFStringEncodingUTF8);
I don't see any XS-code in here and you surely can't use an SV * (C
pointer to the datastructure representing a Perl scalar) in this
way. Assuming that you're trying to pass string arguments,
SvPV_nolen(myeventclass)
would provide access to 'the Perl string' stored in the SV (possibly
after stringification). The 'Perl string' isn't necessarily a valid C
string: It will have a trailing 0 (automatically managed by perl) but
may contain embedded null bytes, too.
Suggestion: Write your interface routines in C and use h2xs to generate
the infrastructure for a proper extension module. This will include XS
stubs for enabling perl to call the C subroutines which will 'usually
just work' (and if they don't, fixing them up is easier than writing
them from scratch).
Simple example of an actual XS routine (enabling Perl code to use the
OpenSSL AES encryption routine for 'single-shot encryptions'):
void
enc_block(data, key)
SV *data
SV *key
PREINIT:
AES_KEY aes_key;
CODE:
AES_set_encrypt_key(SvPVX(key), KEY_BITS, &aes_key);
AES_encrypt(SvPVX(data), SvPVX(data), &aes_key);
------------------------------
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 4238
***************************************
