I founded nothing about slices in perlguts, perlxs*, or perlapi
(where are they documented?), so I wrote this little utility to take
a slice from AV* data using the indices in AV* indices (integers),
and put the result in AV* out (indices and out are guaranteed to have
the same length):
v
On Nov 3, 2005, at 9:05, Reinhard Pagitsch wrote:
Xavier Noria wrote:
I founded nothing about slices in perlguts, perlxs*, or perlapi
(where are they documented?), so I wrote this little utility to
take a slice from AV* data using the indices in AV* indices
(integers), and put the
On Nov 4, 2005, at 8:40, Reinhard Pagitsch wrote:
Hello Xavier,
Did you got my private mal?
Yep!
The text was actually about extending arrays, but it was helpful in
the sense that they applied the concepts to implement by hand array
slicing, so that suggests there's no built-in support.
Say a distribution has a regular Perl module
Foo::Bar::Baz
and another Perl module, used by the former, that is a loader:
Foo::Bar::Baz::XSModule
so we have something like this:
lib/Foo/Bar/Baz.pm
lib/Foo/Bar/Baz/XSModule.pm
lib/Foo/Bar/Baz/XSModule.xs
Makefile.PL
On Nov 12, 2005, at 17:26, Marvin Humphrey wrote:
Try it with the .xs file in the root directory of the distro -- the
same directory as Makefile.PL.
What are MODULE and PACKAGE set to?
For the above config, set...
MODULE = Foo::Bar::Baz::XSModulePACKAGE = Foo::Bar::Baz
Foo::Bar::
On Nov 12, 2005, at 19:12, Marvin Humphrey wrote:
Xavier,
Changing this line in Makefile.PL...
NAME => 'Foo::Bar::Baz',
to this...
NAME => 'Foo::Bar::Baz::XSModule',
... triggers compilation for me.
I'm curious why you're doing things this way.
Because the main module in the dist
The last release of one of my modules works fine except in 5.6.2:
http://cpantesters.perl.org/show/Algorithm-
Combinatorics.html#Algorithm-Combinatorics-0.22
A tester reported the failure and I can reproduce it in my Mac with
5.6.2.
The test suite runs OK but for the last two tests of a
On May 16, 2007, at 7:37 AM, Marvin Humphrey wrote:
On May 15, 2007, at 11:14 AM, Xavier Noria wrote:
A tester reported the failure and I can reproduce it in my Mac
with 5.6.2.
Do you have access to a Linux box with Valgrind on it? I think
your best bet will be to use valgrind to track
On May 16, 2007, at 6:11 PM, Marvin Humphrey wrote:
On May 16, 2007, at 5:58 AM, Xavier Noria wrote:
Fortunately the tester that reported the problem (David Cantrell)
is so kind as to provide a SSH account on his Linux.
He's done that for me, too. Good bloke.
Indeed, if I run the
On May 16, 2007, at 9:39 PM, Xavier Noria wrote:
Errors? I've seen leaks (including one in DynaLoader), but I
don't recall errors under 5.8.8.
This is the first time I use Valgrind. Using 5.8.8 the test suite
passes but there's a report that reads:
ERROR SUMMARY: 18
OK, I've got something. Very misterious!!!
Fortunately the segmentation fault happens in the first call to the
function and some printfs where enough to arrive to what seems the key.
The C subroutine receives an array in its second argument:
int __next_partition_of_size_p(SV* k_avptr, SV*
On May 18, 2007, at 2:58 AM, Xavier Noria wrote:
OK, I've got something. Very misterious!!!
Fortunately the segmentation fault happens in the first call to the
function and some printfs where enough to arrive to what seems the
key.
The C subroutine receives an array in its s
Hi, this C function is leaking memory:
AV* __next_subset(SV* data_avptr, SV* odometer_avptr)
{
AV* data = GETAV(data_avptr);
AV* odometer = GETAV(odometer_avptr);
I32 len_data = av_len(data);
AV* subset = newAV();
IV adjust= 1;
int i;
IV n;
for (i = 0; i
On Fri, Jan 28, 2011 at 11:31 AM, wrote:
> Can't answer your leaking memory/reference count problem,
> but please consider these points:
>
> 1. Generally when you iterate over a length, you want
> for (i = 0; i < len_data; ++i) [not <=]
Yeah, in this case len_data is named after the "len"
14 matches
Mail list logo
