I'm not sure what that means as far as the PDL version. Someone on this list
will be able to tell you how to get that version information quicker than I
can. I believe the fix went in right before the PDL 2.4.10 release.
The read_png() function is not object oriented, so you don't have to do
->to_pdl(), as it already returns a piddle. So, simply:
use PDL::IO::GD;
my $piddle = read_png("largeimage.png");
-Judd
____________________________
Judd Taylor
Software Engineer
Orbital Systems, Ltd.
3807 Carbon Rd.
Irving, TX 75038-3415
(972) 915-3669 x127
________________________________
From: Grasswistle [[email protected]]
Sent: Thursday, August 02, 2012 10:25 AM
To: Judd Taylor
Cc: David Mertens; Sisyphus; chm; [email protected]
Subject: Re: [Perldl] Memory problems with GD
@Judd
H:\>perl -v
This is perl 5, version 12, subversion 3 (v5.12.3) built for
MSWin32-x86-multi-thread
(with 9 registered patches, see perl -V for more detail)
So, to reiterate "undef $im" doesn't seem to do anything while "$im->Destroy"
does fix the crash. Is my version old enough to explain this? Unfortunately,
I am at work here so I am not at liberty to upgrade...
Are you suggesting that I use the following code instead?
use PDL::IO::GD;
my $im = read_png("largeimage.png");
my $piddle = $im->to_pdl();
Thanks,
Perldough
2012/8/2 Judd Taylor
<[email protected]<mailto:[email protected]>>
What version is the OP using? I fixed a memory leak with a non-working DESTROY
not very long ago, and I suspect the OP is using the older broken version.
Even if the OP can't upgrade to the newer version, then they can use the
read_png() and other non-OO methods, which are well known not to have any
memory issues.
-Judd
____________________________
Judd Taylor
Software Engineer
Orbital Systems, Ltd.
3807 Carbon Rd.
Irving, TX 75038-3415
[email protected]<mailto:[email protected]>
(972) 915-3669 x127<tel:%28972%29%20915-3669%20x127>
________________________________________
From: David Mertens [[email protected]<mailto:[email protected]>]
Sent: Thursday, August 02, 2012 9:02 AM
To: Sisyphus
Cc: chm; [email protected]<mailto:[email protected]>
Subject: Re: [Perldl] Memory problems with GD
Rob - Can you reproduce the memory failure on your machine with the
OP's script (and a suitably created 9134x6059 white png)?
Afsheen - Do you still get a crash if you explicitly call $im->DESTROY
instead of undef $im?
David
On Thu, Aug 2, 2012 at 8:45 AM, Sisyphus
<[email protected]<mailto:[email protected]>> wrote:
>
> ----- Original Message ----- From: "David Mertens"
> <[email protected]<mailto:[email protected]>>
> To: "chm" <[email protected]<mailto:[email protected]>>
> Cc: <[email protected]<mailto:[email protected]>>
> Sent: Thursday, August 02, 2012 11:17 PM
> Subject: Re: [Perldl] Memory problems with GD
>
>
>
>> Hmm, this may be an issue with how PDL::IO::GD is implemented. I don't
>> have GD, but if you could try the following code, which is a minor
>> modification of your script, we might get somewhere:
>>
>> __CODE__
>> use strict;
>> use PDL;
>> use PDL::IO::Pic;
>> use PDL::IO::GD;
>>
>> package My::PDL::IO::GD;
>>
>> our @ISA = qw(PDL::IO::GD);
>>
>> sub DESTROY {
>> my $self = shift;
>> print "Destroying the image\n";
>> $self->SUPER::DESTROY();
>> }
>>
>> package main;
>>
>> $|++;
>>
>>
>> for my $i (0 .. 500)
>> {
>> print "$i\n";
>> test();
>>
>> }
>>
>> sub test
>> {
>> my $path = 'largeimage.png';
>> my $im = My::PDL::IO::GD->new( {filename => $path} );
>> undef $im;
>>
>> }
>> __END__
>>
>> My hunch is that undef'ing $im doesn't actually lead to the
>> destruction. If it *does* work, then you should have output that looks
>> like this:
>> 0
>> Destroying the image
>> 1
>> Destroying the image
>> ...
>>
>> in which case I have *no* *idea* what's going on. However, if you
>> don't get those notifications, we have a circular reference issue
>> somewhere that needs to be fixed, which is a tractable problem. :-)
>
>
> For me, the undef() in your test script *does* call DESTROY. I get
>
>
> 0
> Destroying the image
> 1
> Destroying the image
> ...
>
> Also, in the general case, I'm finding that undef() of an object *does* call
> for its DESTROY().
> Still ... it'll be interesting to see if the op is finding the same.
>
> I suppose it's also possible that we have a bodgey DESTROY() - one that's
> not freeing up memory correctly. (I haven't looked.)
>
> Cheers,
> Rob
--
"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]<mailto:[email protected]>
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
_______________________________________________
Perldl mailing list
[email protected]<mailto:[email protected]>
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
