[25104] in Perl-Users-Digest
Perl-Users Digest, Issue: 7354 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 3 06:10:40 2004
Date: Wed, 3 Nov 2004 03:10:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 3 Nov 2004 Volume: 10 Number: 7354
Today's topics:
Re: Q: re Inline and Benchmark <kalinaubears@iinet.net.au>
Re: Q: re Inline and Benchmark <kalinaubears@iinet.net.au>
Re: Q: re Inline and Benchmark <tassilo.von.parseval@rwth-aachen.de>
Re: Q: re Inline and Benchmark <kalinaubears@iinet.net.au>
Re: Q: re Inline and Benchmark <kalinaubears@iinet.net.au>
Re: Q: re Inline and Benchmark <tassilo.von.parseval@rwth-aachen.de>
Re: Q: re Inline and Benchmark <kalinaubears@iinet.net.au>
Re: using different copies of same module <tassilo.von.parseval@rwth-aachen.de>
We have Juvio: Computer Glitches? Rent your own tech. 2 <sales@asan.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 03 Nov 2004 06:17:50 +0000
From: Sisyphus <kalinaubears@iinet.net.au>
Subject: Re: Q: re Inline and Benchmark
Message-Id: <4188795c$0$30713$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
Abigail wrote:
> use Inline C => <<'--';
> char * r_string () {
> char * str;
> int i;
> int l;
>
> l = 20000;
> srand (time ((time_t) NULL));
> if ((str = (char *) malloc (l * sizeof (char))) == (char *) NULL) {
> perror (malloc);
> exit (-1);
> }
> for (i = 0; i < l; i ++) {
> str [i] = rand () % 255;
> }
> return (str);
> }
> --
>
The above will leak memory because 'str' never gets freed.
One alternative (that doesn't leak) is to have 'r_string' return a 'SV
*' rather than a 'char *'. (I would also use 'New' and 'Safefree' in
place of 'malloc' and 'free'. Not sure about 'perror' either, so I'll
opt for 'croak' - with which I *am* familiar :-)
Something like (untested):
SV * r_string () {
char * str;
SV * outsv;
int i;
int l;
l = 20000;
srand (time ((time_t) NULL));
New(1, str, l * sizeof(char), char);
if(str == NULL)
croak("Failed to allocate memory in r_string()");
for (i = 0; i < l; i ++) {
str [i] = rand () % 255;
}
outsv = newSVpv(outstr, l)
Safefree(str);
return outsv;
}
'str' now gets freed inside the subroutine, and perl takes care of the
SV* that has been returned.
Cheers,
Rob
--
To reply by email u have to take out the u in kalinaubears.
------------------------------
Date: Wed, 03 Nov 2004 06:21:14 +0000
From: Sisyphus <kalinaubears@iinet.net.au>
Subject: Re: Q: re Inline and Benchmark
Message-Id: <41887a28$0$30904$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
Michele Dondi wrote:
> Also, the previous question was not terribly specific of Benchmark.pm
> (but only of the kind of parameters one of its functions wants), so
> more on-topic: is there any caveat with benchmarks carried on
> Inline::C subs? I don't think so, but just to be sure...
>
I've benchmarked hundreds of Inline::C subs and never struck any.
Cheers,
Rob
--
To reply by email u have to take out the u in kalinaubears.
------------------------------
Date: Wed, 3 Nov 2004 08:10:19 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Q: re Inline and Benchmark
Message-Id: <slrncoh12r.qs.tassilo.von.parseval@localhost.localdomain>
Also sprach Sisyphus:
> Abigail wrote:
>
>> use Inline C => <<'--';
>> char * r_string () {
>> char * str;
>> int i;
>> int l;
>>
>> l = 20000;
>> srand (time ((time_t) NULL));
>> if ((str = (char *) malloc (l * sizeof (char))) == (char *) NULL) {
>> perror (malloc);
>> exit (-1);
>> }
>> for (i = 0; i < l; i ++) {
>> str [i] = rand () % 255;
>> }
>> return (str);
>> }
>> --
>>
>
> The above will leak memory because 'str' never gets freed.
> One alternative (that doesn't leak) is to have 'r_string' return a 'SV
> *' rather than a 'char *'. (I would also use 'New' and 'Safefree' in
> place of 'malloc' and 'free'. Not sure about 'perror' either, so I'll
> opt for 'croak' - with which I *am* familiar :-)
>
> Something like (untested):
>
> SV * r_string () {
> char * str;
> SV * outsv;
> int i;
> int l;
>
> l = 20000;
> srand (time ((time_t) NULL));
> New(1, str, l * sizeof(char), char);
No need for the sizeof. New's fourth paramater takes care of that:
New(1, str, l, char);
> if(str == NULL)
> croak("Failed to allocate memory in r_string()");
> for (i = 0; i < l; i ++) {
> str [i] = rand () % 255;
> }
> outsv = newSVpv(outstr, l)
> Safefree(str);
> return outsv;
That will leak, too. 'outsv' must be made mortal in order to get freed on
block boundaries:
return sv_2mortal(outsv);
> }
>
>
> 'str' now gets freed inside the subroutine, and perl takes care of the
> SV* that has been returned.
Not quite.
Allocating a string, then copy it into an SV after which the string is
freed is also a bit wasteful. A better solution:
New(1, str, l, char);
...
outsv = sv_newmortal();
sv_usepvn(outsv, str, l);
return outsv;
Perl will now use the memory of 'str' for 'outsv' and no double
allocation is done.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 03 Nov 2004 07:35:17 +0000
From: Sisyphus <kalinaubears@iinet.net.au>
To: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Q: re Inline and Benchmark
Message-Id: <41888A35.4010706@iinet.net.au>
Tassilo v. Parseval wrote:
> Also sprach Sisyphus:
>
>
>>Abigail wrote:
>>
>>
>>> use Inline C => <<'--';
>>> char * r_string () {
>>> char * str;
>>> int i;
>>> int l;
>>>
>>> l = 20000;
>>> srand (time ((time_t) NULL));
>>> if ((str = (char *) malloc (l * sizeof (char))) == (char *) NULL) {
>>> perror (malloc);
>>> exit (-1);
>>> }
>>> for (i = 0; i < l; i ++) {
>>> str [i] = rand () % 255;
>>> }
>>> return (str);
>>> }
>>> --
>>>
>>
>>The above will leak memory because 'str' never gets freed.
>>One alternative (that doesn't leak) is to have 'r_string' return a 'SV
>>*' rather than a 'char *'. (I would also use 'New' and 'Safefree' in
>>place of 'malloc' and 'free'. Not sure about 'perror' either, so I'll
>>opt for 'croak' - with which I *am* familiar :-)
>>
>>Something like (untested):
>>
>> SV * r_string () {
>> char * str;
>> SV * outsv;
>> int i;
>> int l;
>>
>> l = 20000;
>> srand (time ((time_t) NULL));
>> New(1, str, l * sizeof(char), char);
>
>
> No need for the sizeof. New's fourth paramater takes care of that:
>
> New(1, str, l, char);
>
>
>> if(str == NULL)
>> croak("Failed to allocate memory in r_string()");
>> for (i = 0; i < l; i ++) {
>> str [i] = rand () % 255;
>> }
>> outsv = newSVpv(outstr, l)
>> Safefree(str);
>> return outsv;
>
>
> That will leak, too. 'outsv' must be made mortal in order to get freed on
> block boundaries:
>
> return sv_2mortal(outsv);
>
I don't think so - and messrs Jenness and Cozens agree with me (page 241
of Extending and Embedding Perl). I think we touched on this in an XS
list discussion some time back and decided that mortalisation was not
necessary in an Inline C environment .... should I check on that? .... I
seem to recall that Nick stated that the C code revealed that the return
value *was* mortalised. Certainly it won't hurt to mortalise that code
as you have done - but I'm fairly sure it's not necessary .... I've got
some code to rewrite if I'm wrong:-)
>
>> }
>>
>>
>>'str' now gets freed inside the subroutine, and perl takes care of the
>>SV* that has been returned.
>
>
> Not quite
>
> Allocating a string, then copy it into an SV after which the string is
> freed is also a bit wasteful. A better solution:
>
> New(1, str, l, char);
> ...
> outsv = sv_newmortal();
> sv_usepvn(outsv, str, l);
> return outsv;
>
Yes - I was going to take that approach but didn't want to get into
presenting code that was going to set each character within the SV
individually (for simplicity). Much easier (for me, anyway) to simply
leave the for() loop as is, and copy the result into an SV.
Cheers,
Rob
--
To reply by email u have to take out the u in kalinaubears.
------------------------------
Date: Wed, 03 Nov 2004 08:18:25 +0000
From: Sisyphus <kalinaubears@iinet.net.au>
Subject: Re: Q: re Inline and Benchmark
Message-Id: <4188959f$0$564$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
Sisyphus wrote:
>
> I don't think so - and messrs Jenness and Cozens agree with me (page 241
> of Extending and Embedding Perl). I think we touched on this in an XS
> list discussion some time back and decided that mortalisation was not
> necessary in an Inline C environment .... should I check on that? .... I
> seem to recall that Nick stated that the C code revealed that the return
> value *was* mortalised. Certainly it won't hurt to mortalise that code
> as you have done - but I'm fairly sure it's not necessary .... I've got
> some code to rewrite if I'm wrong:-)
>
I don't have to worry - it's as I thought. The C code reveals that
returning an SV as I did (in Inline C) pushes the SV onto the stack,
where it is made mortal and then returned to perl. My code does *not*
leak memory and returning an 'sv_2mortal' in this case is simply redundant.
Cheers,
Rob
--
To reply by email u have to take out the u in kalinaubears.
------------------------------
Date: Wed, 3 Nov 2004 09:43:17 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Q: re Inline and Benchmark
Message-Id: <slrncoh6h5.13t.tassilo.von.parseval@localhost.localdomain>
Also sprach Sisyphus:
> Tassilo v. Parseval wrote:
>> That will leak, too. 'outsv' must be made mortal in order to get freed on
>> block boundaries:
>>
>> return sv_2mortal(outsv);
>>
>
> I don't think so - and messrs Jenness and Cozens agree with me (page 241
> of Extending and Embedding Perl). I think we touched on this in an XS
> list discussion some time back and decided that mortalisation was not
> necessary in an Inline C environment .... should I check on that? .... I
> seem to recall that Nick stated that the C code revealed that the return
> value *was* mortalised. Certainly it won't hurt to mortalise that code
> as you have done - but I'm fairly sure it's not necessary .... I've got
> some code to rewrite if I'm wrong:-)
You seem to be right. According to Devel::Peek, it is mortalized even
when it's not. As it looks this is not Inline::C specific but applies to
XS as well. The xsubpp utitily adds 'sv_2mortal(ST($num))' before it's
XSRETURNing. I find this a little bit annoying because that is usually
the thing typemaps are for. I hate such (possibly undocumented)
smartery. :-)
As for not hurting: Actually it does hurt when you mortalize here. You
get an "Attempt to free unreferenced scalar" warning if you do.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 03 Nov 2004 09:03:34 +0000
From: Sisyphus <kalinaubears@iinet.net.au>
Subject: Re: Q: re Inline and Benchmark
Message-Id: <4188a035$0$1375$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
Tassilo v. Parseval wrote:
> Also sprach Sisyphus:
>
>
>>Tassilo v. Parseval wrote:
>
>
>>>That will leak, too. 'outsv' must be made mortal in order to get freed on
>>>block boundaries:
>>>
>>> return sv_2mortal(outsv);
>>>
>>
>>I don't think so - and messrs Jenness and Cozens agree with me (page 241
>>of Extending and Embedding Perl). I think we touched on this in an XS
>>list discussion some time back and decided that mortalisation was not
>>necessary in an Inline C environment .... should I check on that? .... I
>>seem to recall that Nick stated that the C code revealed that the return
>>value *was* mortalised. Certainly it won't hurt to mortalise that code
>>as you have done - but I'm fairly sure it's not necessary .... I've got
>>some code to rewrite if I'm wrong:-)
>
>
> You seem to be right. According to Devel::Peek, it is mortalized even
> when it's not. As it looks this is not Inline::C specific but applies to
> XS as well. The xsubpp utitily adds 'sv_2mortal(ST($num))' before it's
> XSRETURNing. I find this a little bit annoying because that is usually
> the thing typemaps are for. I hate such (possibly undocumented)
> smartery. :-)
Oh ... I assumed it was an Inline::C thing. I guess that if you don't
want to mortalise it then, instead of 'return'ing it, you would push it
onto the stack as a non-mortal. That way it won't get to be mortalised.
At least that's what you'd do in Inline::C:
Inline_Stack_Vars;
.
.
Inline_Stack_Push(outsv);
Inline_Stack_Done;
Inline_Stack_Return(1);
Now 'outsv' has been returned to perl without mortalising it. (I don't
know the XS equivalent to that.)
>
> As for not hurting: Actually it does hurt when you mortalize here. You
> get an "Attempt to free unreferenced scalar" warning if you do.
>
Yes - I just found that myself a few minutes ago. It's not so "simply
redundant" (as I subsequently posted) after all :-)
Cheers,
Rob
--
To reply by email u have to take out the u in kalinaubears.
------------------------------
Date: Wed, 3 Nov 2004 07:53:42 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: using different copies of same module
Message-Id: <slrncoh03m.qs.tassilo.von.parseval@localhost.localdomain>
Also sprach wana:
> Suppose you have a module installed and you want to test an updated version
> but you need to be certain of which copy on your system you are using.
Use only: <http://search.cpan.org/~ingy/only-0.26/>.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 03 Nov 2004 04:55:07 GMT
From: <sales@asan.com>
Subject: We have Juvio: Computer Glitches? Rent your own tech. 24 hours a day, 7 days a week
Message-Id: <LwZhd.39951$Jb.1197945@twister.southeast.rr.com>
http://tinyurl.com/3rcs4
We have Juvio: Computer Glitches? Rent your own tech. The Juvio Single Service Plan
is perfect for the user looking to get their computer related problems solved at anytime,
24 hours a day, 7 days a week.Computers are here to help make your life easier and
more efficient. Wasting valuable time on a computer system that is down is very frustrating.
If you’re in need of computer assistance, don’t waste any more time rummaging through
manuals or waiting on hold for someone whose focus is to get you off the phone quickly.
Call in the professionals from Juvio!
http://tinyurl.com/3rcs4
www.gamerschoice.biz
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 7354
***************************************
