[32742] in Perl-Users-Digest
Perl-Users Digest, Issue: 4006 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 2 21:09:37 2013
Date: Fri, 2 Aug 2013 18:09:06 -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 Fri, 2 Aug 2013 Volume: 11 Number: 4006
Today's topics:
autodie <oneingray@gmail.com>
Re: autodie <ben@morrow.me.uk>
Re: autodie <oneingray@gmail.com>
Re: autodie <ben@morrow.me.uk>
But this is NOT my opinion on that! <rweikusat@mssgmbh.com>
Re: But this is NOT my opinion on that! <gravitalsun@hotmail.foo>
fast scan <gravitalsun@hotmail.foo>
Re: Regex basic question <vedpsingh@gmail.com>
XS: sysread () look-alike? <oneingray@gmail.com>
Re: XS: sysread () look-alike? <ben@morrow.me.uk>
Re: XS: sysread () look-alike? <rweikusat@mssgmbh.com>
Re: XS: sysread () look-alike? <oneingray@gmail.com>
Re: XS: sysread () look-alike? <ben@morrow.me.uk>
Re: XS: sysread () look-alike? <oneingray@gmail.com>
Re: XS: sysread () look-alike? <rweikusat@mssgmbh.com>
Re: XS: sysread () look-alike? <oneingray@gmail.com>
Re: XS: sysread () look-alike? <rweikusat@mssgmbh.com>
Re: XS: sysread () look-alike? <oneingray@gmail.com>
Re: XS: sysread () look-alike? <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 01 Aug 2013 15:37:22 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: autodie
Message-Id: <874nb9pglp.fsf_-_@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
[...]
>> I've thus decided that I'd closely follow the library's own
>> interface of returning a non-zero status code upon failure, and also
>> provide convenience Perl wrappers, which raise an exception if the
>> status returned is non-zero. Consider, e. g.:
> It might be more convenient to do this via autodie. See
> autodie::hints.
How do I get the library's function called (so to convert the
error code returned into a meaningful message) when using
autodie?
>> Naturally, the XXX::Exception object has ->xxx_err_no () and
>> ->xxx_err_string () methods (providing access to the library's own
>> "errno" and "strerror" facilities), as well as the conventional
>> ->error () method, which is also the object's "stringification"
>> routine.
--
FSF associate member #7257
------------------------------
Date: Thu, 1 Aug 2013 18:13:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: autodie
Message-Id: <iihqca-7t11.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >> I've thus decided that I'd closely follow the library's own
> >> interface of returning a non-zero status code upon failure, and also
> >> provide convenience Perl wrappers, which raise an exception if the
> >> status returned is non-zero. Consider, e. g.:
>
> > It might be more convenient to do this via autodie. See
> > autodie::hints.
>
> How do I get the library's function called (so to convert the
> error code returned into a meaningful message) when using
> autodie?
>
> >> Naturally, the XXX::Exception object has ->xxx_err_no () and
> >> ->xxx_err_string () methods (providing access to the library's own
> >> "errno" and "strerror" facilities), as well as the conventional
> >> ->error () method, which is also the object's "stringification"
> >> routine.
That's a good question, actually. The simple answer, if all you're
concerned about is the message, is that you use
autodie::exception->register to register a custom stringification.
However, there is a problem with that, which is that the stringification
will happen late (after the exception has been caught), and the result
of xxx_err_no may no longer apply.
Ideally, you would want to be able to subclass autodie::exception and
arrange to pick up the xxx-specific error information at creation time.
I'm not sure if it's possible to make autodie use your subclass
automatically, though. You might want to talk to Paul; when I had
suggestions in the past for improving the interface, he was very willing
to listen.
Alternatively, you could just forget the idea of providing a return-
value interface, and just always throw your own exceptions. If you do
that, I would recommend making them objects rather than strings, because
it makes it possible to reliably distinguish them from other exceptions
when they're caught; if your exception class doesn't inherit from
something like Exception::Class, it needs to provide overloaded
stringify, and it needs to record at least file and line from caller at
the point where it's thrown.
Ben
------------------------------
Date: Thu, 01 Aug 2013 17:51:55 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: autodie
Message-Id: <87zjt1nvt0.fsf@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>> I've thus decided that I'd closely follow the library's own
>>>> interface of returning a non-zero status code upon failure, and also
>>>> provide convenience Perl wrappers, which raise an exception if the
>>>> status returned is non-zero. Consider, e. g.:
>>> It might be more convenient to do this via autodie. See
>>> autodie::hints.
>> How do I get the library's function called (so to convert the error
>> code returned into a meaningful message) when using autodie?
[...]
> Ideally, you would want to be able to subclass autodie::exception and
> arrange to pick up the xxx-specific error information at creation
> time. I'm not sure if it's possible to make autodie use your
> subclass automatically, though. You might want to talk to Paul; when
> I had suggestions in the past for improving the interface, he was
> very willing to listen.
ACK, thanks.
> Alternatively, you could just forget the idea of providing a
> return-value interface, and just always throw your own exceptions.
> If you do that, I would recommend making them objects rather than
> strings, because it makes it possible to reliably distinguish them
> from other exceptions when they're caught;
Unless I'm missing something, this is exactly what I do. The
point is that I'm hesitant to either generate exception objects
/or/ call Perl code from XS, so my XS ("low-level") interface
returns error codes, which the Perl wrapper methods then turn
into proper exceptions (which are indeed objects.)
> if your exception class doesn't inherit from something like
> Exception::Class, it needs to provide overloaded stringify,
The latter is also done.
> and it needs to record at least file and line from caller at the
> point where it's thrown.
I don't seem to understand this one. Any specific examples,
please?
--
FSF associate member #7257
------------------------------
Date: Thu, 1 Aug 2013 20:16:40 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: autodie
Message-Id: <opoqca-aka1.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >>>> I've thus decided that I'd closely follow the library's own
> >>>> interface of returning a non-zero status code upon failure, and also
> >>>> provide convenience Perl wrappers, which raise an exception if the
> >>>> status returned is non-zero. Consider, e. g.:
[...]
>
> > Alternatively, you could just forget the idea of providing a
> > return-value interface, and just always throw your own exceptions.
> > If you do that, I would recommend making them objects rather than
> > strings, because it makes it possible to reliably distinguish them
> > from other exceptions when they're caught;
>
> Unless I'm missing something, this is exactly what I do. The
> point is that I'm hesitant to either generate exception objects
> /or/ call Perl code from XS, so my XS ("low-level") interface
> returns error codes, which the Perl wrapper methods then turn
> into proper exceptions (which are indeed objects.)
Ah, OK. I though you were trying to provide both return-value and
exception interfaces so users could choose which they wanted.
Throwing exceptions from XS is fairly straightforward; you build your
object (however you like) and call Perl_croak_sv. However it would
probably be easier to have a My::Exception->throw method, which builds
and throws an exception; this means you just need to make a method call,
which goes like this:
PUSHMARK(SP);
mXPUSHs(newSVpvs("My::Exception"));
mXPUSHs(/* more arguments to ->throw */);
PUTBACK;
call_method("throw", G_DISCARD);
(Normally this would be followed with SPAGAIN, but since this will throw
an exception we won't get there). See perlcall.
> > if your exception class doesn't inherit from something like
> > Exception::Class, it needs to provide overloaded stringify,
>
> The latter is also done.
>
> > and it needs to record at least file and line from caller at the
> > point where it's thrown.
>
> I don't seem to understand this one. Any specific examples,
> please?
If you have an exception class like this:
package My::Exception;
use overload
q/""/ => "stringify",
fallback => 1;
sub new {
my ($class, $msg) = @_;
bless {msg => $msg}, $class;
}
sub throw {
my ($self, @args) = @_;
ref $self or $self = $self->new(@args);
die $self;
}
sub stringify { $_[0]{msg} }
and an exception of this class reaches the top-level 'print a message
and kill the program' exception handler, that message will not include
the 'at file ... line ...' information. Adding that information is
something die does if you pass it a string; if you pass it an object, it
has nowhere to put the information.
This means that your 'new' method needs to record that information,
somehow, so it can include it in the stringification. You can pull it
out of 'caller', though that means working out how many stack frames to
go back to get to the 'real' location of the error. You can also use
Carp::shortmess, which gives you the message 'croak' would have given
you.
Ben
------------------------------
Date: Fri, 02 Aug 2013 21:55:35 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: But this is NOT my opinion on that!
Message-Id: <87ioznyfqw.fsf@sapphire.mobileactivedefense.com>
I'm in the process of setting up OTRS for my employer (presumably,
that should crumble to dust because "Nobody uses CGI.pm !!1) and just
got bitten by the following two lines of code (from Defaults.pm):
print STDERR "ERROR: Can't read $Self->{Home}/RELEASE: $! This file is needed by central system parts of OTRS, the system will not work without this file.\n";
die;
This is an incredibly helpful way to report errors because the message
which will land in the Apache error log is
-e: Died at /usr/local/otrs//Kernel/Config/Defaults.pm line 2188.\n
Stuff like this may be a good way to sell 'professional help'
but it should IMNSHO be avoided in code supposed to be used by anyone
except the guy who committed the offence.
------------------------------
Date: Sat, 03 Aug 2013 03:35:12 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: But this is NOT my opinion on that!
Message-Id: <kthj8e$173j$1@news.ntua.gr>
Στις 2/8/2013 23:55, ο/η Rainer Weikusat έγραψε:
> I'm in the process of setting up OTRS for my employer (presumably,
> that should crumble to dust because "Nobody uses CGI.pm !!1) and just
> got bitten by the following two lines of code (from Defaults.pm):
>
> print STDERR "ERROR: Can't read $Self->{Home}/RELEASE: $! This file is needed by central system parts of OTRS, the system will not work without this file.\n";
> die;
>
> This is an incredibly helpful way to report errors because the message
> which will land in the Apache error log is
>
> -e: Died at /usr/local/otrs//Kernel/Config/Defaults.pm line 2188.\n
>
> Stuff like this may be a good way to sell 'professional help'
> but it should IMNSHO be avoided in code supposed to be used by anyone
> except the guy who committed the offence.
>
Some weeks before I wrote for a customer a bridging software between
some linux clusters and his windows java custom application all in
CGI.pm sending XML messages over https using Apache. There were custom
and Apache logs. Customer and his developers really love it.
GI::Carp was very helpful. I barely mention the word Perl.
------------------------------
Date: Sat, 03 Aug 2013 03:39:22 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: fast scan
Message-Id: <kthjg8$1md$1@news.ntua.gr>
# scan a network in 2 seconds using fork. Very simplistic but with
potential !
#!/usr/bin/perl
use strict;
use warnings;
use feature qw/say/;
use Net::Ping;
use Net::IP;
my $threads = 255;
my $duration = 2;
my @ip_team = ();
$|= 1;
my $ip = new Net::IP ('192.168.0.1 - 192.168.0.254') or die "Could not
initiate object because ". Net::IP::Error() ."\n";
while ($ip) {
push @ip_team, $ip++ ->ip();
if ( $threads == @ip_team ) { Scan(@ip_team); @ip_team = () }
}
Scan(@ip_team);
sub Scan
{
my @Pids;
foreach my $ip (@_)
{
my $pid = fork();
die "Could not fork because $!\n" unless defined $pid;
if (0 == $pid)
{
my $ping = Net::Ping->new('icmp');
say "host $ip is up" if $ping->ping($ip, $duration);
$ping->close();
exit
}
else
{
push @Pids, $pid
}
}
foreach my $pid (@Pids) { waitpid($pid, 0) }
}
------------------------------
Date: Wed, 31 Jul 2013 22:10:06 -0700 (PDT)
From: Ved <vedpsingh@gmail.com>
Subject: Re: Regex basic question
Message-Id: <400cb841-46ab-4b95-bf07-ca9290750104@googlegroups.com>
Thanks Guys. That helped
------------------------------
Date: Thu, 01 Aug 2013 09:04:54 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: XS: sysread () look-alike?
Message-Id: <87d2pxpyrt.fsf@violet.siamics.net>
I'm implementing a sysread () look-alike in XS:
my $result;
my $status
= $myio->myread ($start, $count, RESULT);
I wonder whether it's sensible to pass a scalar for RESULT (IOW,
$result), or should I use a reference instead (\$result)?
The issue with passing a scalar is that it won't (AIUI) be all
that easy to allow for "filter" or "guard" functions at the Perl
side, e. g.:
our $myio;
sub read_from_0 {
my $r
= $myio->myread (0, @_);
die (error_message ($r))
unless ($r == 0);
}
my $result;
read_from_0 ($count, $result);
Somehow, it seems that @_[1] in read_from_0 () won't be the same
scalar as the caller's $result. (While for \$result, it would
still be a /reference/ to the same scalar.)
Anything else I should consider?
TIA.
--
FSF associate member #7257
------------------------------
Date: Thu, 1 Aug 2013 12:14:20 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: XS: sysread () look-alike?
Message-Id: <chspca-ki7.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> I'm implementing a sysread () look-alike in XS:
>
> my $result;
> my $status
> = $myio->myread ($start, $count, RESULT);
>
> I wonder whether it's sensible to pass a scalar for RESULT (IOW,
> $result), or should I use a reference instead (\$result)?
I would pass a reference, because it makes it clearer that the function
modifies its argument.
> The issue with passing a scalar is that it won't (AIUI) be all
> that easy to allow for "filter" or "guard" functions at the Perl
> side, e. g.:
>
> our $myio;
> sub read_from_0 {
> my $r
> = $myio->myread (0, @_);
> die (error_message ($r))
> unless ($r == 0);
> }
>
> my $result;
> read_from_0 ($count, $result);
>
> Somehow, it seems that @_[1] in read_from_0 () won't be the same
> scalar as the caller's $result.
It will be. Both $_[1] in read_from_0 and the-equivalent-of-$_[2] in
myread will be aliases to $result.
> (While for \$result, it would
> still be a /reference/ to the same scalar.)
>
> Anything else I should consider?
I would put the buffer argument first, to match IO::Handle->sysread.
Ben
------------------------------
Date: Thu, 01 Aug 2013 12:33:20 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <8738qt63y7.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
> I'm implementing a sysread () look-alike in XS:
>
> my $result;
> my $status
> = $myio->myread ($start, $count, RESULT);
>
> I wonder whether it's sensible to pass a scalar for RESULT (IOW,
> $result), or should I use a reference instead (\$result)?
I think you should work with the language you are using and not
against it: Perl is the opposite of C in this respect and passes
everything 'by reference'. Consequently, using scalars in the way
sysread does is totally fine. A better idea might be to return a
scalar with the contents or undef on error, possibly using an
optionally passed scalar for a more detailed status code. Or setting
$! to a sensible value. Or using the perlapi croak-routine for error
reporting.
------------------------------
Date: Thu, 01 Aug 2013 13:52:09 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <878v0lplh2.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> A better idea might be to return a scalar with the contents or undef
> on error, possibly using an optionally passed scalar for a more
> detailed status code. Or setting $! to a sensible value. Or using
> the perlapi croak-routine for error reporting.
In this case, the library I'm writing interface for has a host
of possible error codes, which do not map to errno.h codes, but
which I nevertheless wish to preserve.
I've thus decided that I'd closely follow the library's own
interface of returning a non-zero status code upon failure, and
also provide convenience Perl wrappers, which raise an exception
if the status returned is non-zero. Consider, e. g.:
package XXX::Qux 0.1;
sub check_rv {
my ($name, $code, $args) = @_;
my $r
= $code->(@$args);
die (XXX::Exception->new ($r, $name))
unless ($r == 0);
## .
return;
}
## assuming XS wrappers inhabit this very same namespace, which they
## probably shouldn't
sub foo {
## .
check_rv_ref (q"xxx_foo",
\&xxx_foo, \@_);
}
Naturally, the XXX::Exception object has ->xxx_err_no () and
->xxx_err_string () methods (providing access to the library's
own "errno" and "strerror" facilities), as well as the
conventional ->error () method, which is also the object's
"stringification" routine.
The only case I deviate from this convention is the one when the
function returns an (array) reference from the XS wrapper in the
case of success, like:
sub check_rv_ref {
my ($name, $code, $args) = @_;
my $r
= $code->(@$args);
die (XXX::Exception->new ($r, $name))
unless (ref ($r));
## .
$r;
}
sub bar_baz {
## .
check_rv_ref (q"xxx_bar_baz",
\&xxx_bar_baz, \@_);
}
This is the case when the xxx_bar () C function is to return
several values, typically via the storage pointed by its
arguments; as in:
xxx_error xxx_bar_baz (xxx_obj, int foo, int *bar, int *baz);
This corresponds to the following XS wrapper usage:
my $r
= $xxx_obj->xxx_bar_baz (42);
die ()
unless (ref ($r));
my ($bar, $baz)
= @$r;
--
FSF associate member #7257
------------------------------
Date: Thu, 1 Aug 2013 15:34:21 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: XS: sysread () look-alike?
Message-Id: <d88qca-mtm.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> > A better idea might be to return a scalar with the contents or undef
> > on error, possibly using an optionally passed scalar for a more
> > detailed status code. Or setting $! to a sensible value. Or using
> > the perlapi croak-routine for error reporting.
>
> In this case, the library I'm writing interface for has a host
> of possible error codes, which do not map to errno.h codes, but
> which I nevertheless wish to preserve.
>
> I've thus decided that I'd closely follow the library's own
> interface of returning a non-zero status code upon failure, and
> also provide convenience Perl wrappers, which raise an exception
> if the status returned is non-zero. Consider, e. g.:
It might be more convenient to do this via autodie. See autodie::hints.
Ben
------------------------------
Date: Fri, 02 Aug 2013 11:58:51 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <87iozonw1w.fsf@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> I'm implementing a sysread () look-alike in XS:
>> my $result; my $status = $myio->myread ($start, $count, RESULT);
>> I wonder whether it's sensible to pass a scalar for RESULT (IOW,
>> $result), or should I use a reference instead (\$result)?
> I would pass a reference, because it makes it clearer that the
> function modifies its argument.
Yes.
Yet, this seem to go against the convention already set by the
Perl core...
[...]
>> read_from_0 ($count, $result);
>> Somehow, it seems that @_[1] in read_from_0 () won't be the same
>> scalar as the caller's $result.
> It will be. Both $_[1] in read_from_0 and the-equivalent-of-$_[2] in
> myread will be aliases to $result.
ACK, thanks. Indeed, my case was more like:
sub myread {
## .
check_rv (q"lowlevel_myread",
\&lowlevel_myread, \@_);
}
with check_rv () later doing $_[1]->(@{$_[2]}).
Alas, in this latter case, it doesn't seem to work anymore.
So, the question is: is there any way to allow for such a use,
apart from resorting to use a reference (\$result)?
>> (While for \$result, it would still be a /reference/ to the same
>> scalar.)
>> Anything else I should consider?
> I would put the buffer argument first, to match IO::Handle->sysread.
It makes sense, indeed, though in this case I'd rather duplicate
the signature of the library's function I'm writing the
interface for, so not to confuse those already familiar with the
C one.
--
FSF associate member #7257
------------------------------
Date: Fri, 02 Aug 2013 14:42:45 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <87wqo4yzsa.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >> I'm implementing a sysread () look-alike in XS:
>
> >> my $result; my $status = $myio->myread ($start, $count, RESULT);
>
> >> I wonder whether it's sensible to pass a scalar for RESULT (IOW,
> >> $result), or should I use a reference instead (\$result)?
>
> > I would pass a reference, because it makes it clearer that the
> > function modifies its argument.
>
> Yes.
>
> Yet, this seem to go against the convention already set by the
> Perl core...
The reason for this is that the people who wrote 'the Perl core'
created a language which doesn't support passs-by-value. Because of
this, it is not necessary to pass a special 'derived value' in order
to have 'output arguments' and dealing with output arguments requires
no 'special indirection syntax'.
[...]
> sub myread {
> ## .
> check_rv (q"lowlevel_myread",
> \&lowlevel_myread, \@_);
> }
>
> with check_rv () later doing $_[1]->(@{$_[2]}).
>
> Alas, in this latter case, it doesn't seem to work anymore.
perl -e 'sub nice { $_[0] = 1723; }; sub try { nice(@{$_[0]}); } sub watson { try(\@_); }; watson($r); print $r'
Given the way argument passing works in Perl (by putting pointers to
SVs on the stack), it is - unfortunately - not possible to weasel
around pass-by-reference with Perl code in this way: At some point,
you have to make a copy of the argument in question in order to create
a different scalar/ SV.
[...]
> > I would put the buffer argument first, to match IO::Handle->sysread.
>
> It makes sense, indeed, though in this case I'd rather duplicate
> the signature of the library's function I'm writing the
> interface for, so not to confuse those already familiar with the
> C one.
Chances are that your Perl code is encountered by Perl programmers ...
------------------------------
Date: Fri, 02 Aug 2013 13:46:44 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <87ehacnr23.fsf@violet.siamics.net>
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
[...]
>>> read_from_0 ($count, $result);
>>> Somehow, it seems that @_[1] in read_from_0 () won't be the same
>>> scalar as the caller's $result.
>> It will be. Both $_[1] in read_from_0 and the-equivalent-of-$_[2]
>> in myread will be aliases to $result.
> ACK, thanks. Indeed, my case was more like:
> sub myread {
> ## .
> check_rv (q"lowlevel_myread",
> \&lowlevel_myread, \@_);
> }
> with check_rv () later doing $_[1]->(@{$_[2]}).
> Alas, in this latter case, it doesn't seem to work anymore.
... Apparently, I've essentially confused \@_ with [ @_ ], and
the first one indeed works as expected.
Sorry for the noise.
[...]
--
FSF associate member #7257
------------------------------
Date: Fri, 02 Aug 2013 14:52:06 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <87ob9gyzcp.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> [...]
>
> >>> read_from_0 ($count, $result);
>
> >>> Somehow, it seems that @_[1] in read_from_0 () won't be the same
> >>> scalar as the caller's $result.
>
> >> It will be. Both $_[1] in read_from_0 and the-equivalent-of-$_[2]
> >> in myread will be aliases to $result.
>
> > ACK, thanks. Indeed, my case was more like:
>
> > sub myread {
> > ## .
> > check_rv (q"lowlevel_myread",
> > \&lowlevel_myread, \@_);
> > }
>
> > with check_rv () later doing $_[1]->(@{$_[2]}).
>
> > Alas, in this latter case, it doesn't seem to work anymore.
>
> ... Apparently, I've essentially confused \@_ with [ @_ ], and
> the first one indeed works as expected.
The second one also works as expected: You are copying the contents of
@_, hence, you get a different set of scalars.
------------------------------
Date: Fri, 02 Aug 2013 13:57:16 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <87a9l0nqkj.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
> dealing with output arguments requires no 'special indirection
> syntax'.
Which is what I consider a serious drawback of the language.
(The same applies to Fortran and C++, though.)
[...]
>>> I would put the buffer argument first, to match
>>> IO::Handle->sysread.
>> It makes sense, indeed, though in this case I'd rather duplicate the
>> signature of the library's function I'm writing the interface for,
>> so not to confuse those already familiar with the C one.
> Chances are that your Perl code is encountered by Perl programmers
> ...
Given the (planned) incompleteness of the interface (at least
for the first N releases), I'd expect for its users to check
with the interfaced library's own documentation from time to
time. And having two different interfaces to stumble upon
doesn't seem like some clever time-saving feature.
That doesn't mean that there can't be a more "Perl-friendly"
interface on top of it, though.
--
FSF associate member #7257
------------------------------
Date: Fri, 02 Aug 2013 17:49:26 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: XS: sysread () look-alike?
Message-Id: <87zjt0xckp.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>
> [...]
>
> > dealing with output arguments requires no 'special indirection
> > syntax'.
>
> Which is what I consider a serious drawback of the language.
> (The same applies to Fortran and C++, though.)
I agree with that although I'm unsure to which degree this is rather
based on 'cultural prejudices' than on actual reasons.
------------------------------
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 4006
***************************************
