Thanks David and Craig. That is more than enough to
get started.
John
On 02/09/2013 09:02 PM, David Mertens wrote:
Sorry for all the posts. I felt it important to get that correction up.
As to your questions, there is no notion of provenance in PDL's
conversion of scalars to piddles. It will automatically coerce your
scalar to a piddle, but there is no way to know from within the pp_def
code unless you inspect it by hand in a PMCode section, and pass an
additional boolean flag in your OtherPars indicating whether this was a
Perl scalar or a piddle.
I have been meaning to document all of this stuff about PMCode in the
PDL::PP docs. These and other ideas could serve as useful examples, so
please ask questions to clarify what I did not explain.
David
On Sat, Feb 9, 2013 at 1:35 PM, David Mertens
<[email protected]> wrote:
sorry, that last bit was incomplete. Somehow sit send without meaning
to. Now, continuing...
pp_def('some_func' =>
Pars => 'input_piddle(); [o] output_piddle()',
OtherPars => 'SV * output_scalar',
Code => q{
/* Code goes here; manipulate the output SV with Perl XS functions */
},
PMCode => q{
sub some_func {
my ($input_piddle) = @_;
# You should see if they also passed in a pre-constructed output piddle,
# but I'll ignore that for now
my $output_piddle = $intput_piddle->zeroes;
my $output_scalar;
# Notice the name of the actual XS-defined function is a little
name-mangled
_some_func_int($input_piddle, $output_piddle, $output_scalar);
return $output_piddle, $output_scalar;
}
},
);
Commentary to follow...
On Sat, Feb 9, 2013 at 1:32 PM, David Mertens
<[email protected]> wrote:
John -
There is more than one way to do it. :-)
First, you could simply use the OtherPars section, passing an SV*, and
modify the functions calling convention. For example, you can include a
"my $output" in your function call and get it out on the other side:
pp_def('some_func' =>
Pars => 'input_piddle(); [o] output_piddle()',
OtherPars => 'SV * output_scalar',
Code => q{
/* Code goes here; manipulate the output SV with Perl XS functions */
},
);
You would then call this function as
$output_piddle = $input_piddle->some_func(my $output_scalar);
The next option is to use the PMCode key. Beware, however, this does
not work with Inline::Pdlpp, only with compiled pd files. The PMCode
section specifies perl code that is meant to wrap the function you
define. It looks something like this:
pp_def('some_func' =>
Pars => 'input_piddle(); [o] output_piddle()',
OtherPars => 'SV * output_scalar',
Code => q{
/* Code goes here; manipulate the output SV with Perl XS functions */
},
PMCode => q{
sub some_func {
my ($input_piddle) = @_;
}
},
);
On Sat, Feb 9, 2013 at 11:54 AM, John Lapeyre
<[email protected]> wrote:
Hello,
Does anyone know how to write a call to `pp_def' that somehow returns,
or updates, scalar values ? I know that with `OtherPars' it is easy
to specify that a scalar is to be passed as input. For output, do I
have to somehow use the normal C api to perl to get at the contents of
an SV?
For instance, I might want to take piddles and or scalars as input and
have scalars and possibly piddle as output. A clumsy solution is to
pass a piddle of length 1, where I really want a scalar, in the `Code'
string, and then write a wrapper function in perl to extract the
scalar from the auxiallry piddle.
A related question: With `GenericTypes' and the template mechanism
`$T( ...', I can automatically generate interfaces for several
types of piddles. Is it possible to somehow use this template with
`OtherPars' ? In particular, I want to define a function via
pp_def that takes a piddle and a scalar as arguments. I want the
two arguments to be of the same type. For example, both integers,
both doubles, etc.
Thank you!
John
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
