[Pdl-porters] PDL::Graphics::Gnuplot v2.000 and Alien::Gnuplot v1.010 released

[Craig DeForest]

PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.

AG v1.010 works in both POSIX and Microsoft Windows environments.

Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.

Happy hacking,
Craig

[Ingo Schmid]

Hi Craig,

I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.

$ni is an object from a class declared as
use base PDL:
to make of the {PDL} key magic. Apparently, this breaks P::G::G.

pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB

pdl> gplot $ni->(,,0,0,0,0,0) # gives this error:

Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.

PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5

printing works:

pdl> p $ni->(,,0,0,0,0,0)

[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]


Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Chris Marshall]

I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.

--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.
PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Chris Marshall]

I've opened a ticket on Craig's github. Thanks for reporting the problem.

[Craig DeForest]

Ingo, immediate cause of the issue you're having is an oversight in PDL::Graphics::Gnuplot, but it has deeper problems that extend right to the heart of the Perl object system. PDL::Graphics::Gnuplot uses 'UNIVERSAL::isa($thing, 'PDL')' to detect PDL arguments in PDL::Graphics::Gnuplot, which has known issues. In fact, your problem is a classic example of why one does *not* use UNIVERSAL::isa -- some types of object require more logic than UNIVERSAL::isa provides. I've seen people advocate, instead, variants of

(eval {$thing->isa('PDL')})

which works for subclasses of PDL (that may overload isa). But even that is broken for your case -- because PDL permits you to use an unblessed hash as a PDL in certain circumstances, so long as the hash contains a 'PDL' key.

So for PDL the proper logic is something like:

( (eval {$thing->isa('PDL')}) or ( (ref $thing) =~ m/HASH/ and exists($thing->{PDL}) ) ) )

or, better,

( (eval {$thing->isa('PDL')}) or PDL::isa($thing,'PDL') )

where PDL::isa is still to be written. But that is cumbersome, slow, and ugly as sin. It would be nice if there were a PDL::isa so that you could write

( PDL::isa($thing,'PDL') )

or even

( PDL::isa($thing) )

but that has the same sort of philosophical problem as using UNIVERSAL::isa -- one day David Mertens, or someone almost as clever as him, is going to write a PDL::Nifty that includes a PDL::Nifty::isa.

Does anyone have thoughts on how to fix this properly?

Post by Chris Marshall
I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.
--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.
PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Craig DeForest]

Argh, I'm sorry if this wasn't clear. To be more succinct:

Using "eval {$thing->isa('PDL')}" solves Ingo's problem, and I'm happy to do that -- the real question is how to avoid this problem with *unblessed* hashes with PDL keys in them, and whether treating unblessed hashes with PDL keys as PDLs is even a behavior worth supporting.

Post by Craig DeForest
Ingo, immediate cause of the issue you're having is an oversight in PDL::Graphics::Gnuplot, but it has deeper problems that extend right to the heart of the Perl object system. PDL::Graphics::Gnuplot uses 'UNIVERSAL::isa($thing, 'PDL')' to detect PDL arguments in PDL::Graphics::Gnuplot, which has known issues. In fact, your problem is a classic example of why one does *not* use UNIVERSAL::isa -- some types of object require more logic than UNIVERSAL::isa provides. I've seen people advocate, instead, variants of
(eval {$thing->isa('PDL')})
which works for subclasses of PDL (that may overload isa). But even that is broken for your case -- because PDL permits you to use an unblessed hash as a PDL in certain circumstances, so long as the hash contains a 'PDL' key.
( (eval {$thing->isa('PDL')}) or ( (ref $thing) =~ m/HASH/ and exists($thing->{PDL}) ) ) )
or, better,
( (eval {$thing->isa('PDL')}) or PDL::isa($thing,'PDL') )
where PDL::isa is still to be written. But that is cumbersome, slow, and ugly as sin. It would be nice if there were a PDL::isa so that you could write
( PDL::isa($thing,'PDL') )
or even
( PDL::isa($thing) )
but that has the same sort of philosophical problem as using UNIVERSAL::isa -- one day David Mertens, or someone almost as clever as him, is going to write a PDL::Nifty that includes a PDL::Nifty::isa.
Does anyone have thoughts on how to fix this properly?

Post by Chris Marshall
I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.
--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.
PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Chris Marshall]

Given that the special handling of PDL attributes is to
enable inheritance and extensions based on PDL, I
think that we may not need to support an unblessed
hash with a PDL key as a PDL. The whole point is
that you have an object that wants to be a PDL too...

For that, you could use Scalar::Util blessed().

--Chris


On Wed, Oct 30, 2013 at 12:33 PM, Craig DeForest

Post by Craig DeForest
Using "eval {$thing->isa('PDL')}" solves Ingo's problem, and I'm happy to do that -- the real question is how to avoid this problem with *unblessed* hashes with PDL keys in them, and whether treating unblessed hashes with PDL keys as PDLs is even a behavior worth supporting.

Post by Craig DeForest
Ingo, immediate cause of the issue you're having is an oversight in PDL::Graphics::Gnuplot, but it has deeper problems that extend right to the heart of the Perl object system. PDL::Graphics::Gnuplot uses 'UNIVERSAL::isa($thing, 'PDL')' to detect PDL arguments in PDL::Graphics::Gnuplot, which has known issues. In fact, your problem is a classic example of why one does *not* use UNIVERSAL::isa -- some types of object require more logic than UNIVERSAL::isa provides. I've seen people advocate, instead, variants of
(eval {$thing->isa('PDL')})
which works for subclasses of PDL (that may overload isa). But even that is broken for your case -- because PDL permits you to use an unblessed hash as a PDL in certain circumstances, so long as the hash contains a 'PDL' key.
( (eval {$thing->isa('PDL')}) or ( (ref $thing) =~ m/HASH/ and exists($thing->{PDL}) ) ) )
or, better,
( (eval {$thing->isa('PDL')}) or PDL::isa($thing,'PDL') )
where PDL::isa is still to be written. But that is cumbersome, slow, and ugly as sin. It would be nice if there were a PDL::isa so that you could write
( PDL::isa($thing,'PDL') )
or even
( PDL::isa($thing) )
but that has the same sort of philosophical problem as using UNIVERSAL::isa -- one day David Mertens, or someone almost as clever as him, is going to write a PDL::Nifty that includes a PDL::Nifty::isa.
Does anyone have thoughts on how to fix this properly?

Post by Chris Marshall
I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.
--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.
PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[David Mertens]

We had some discussion on derived classes on IRC back in June. The part
where the conversation gets interesting is here:
http://irclog.perlgeek.de/pdl/2013-06-11#i_7183688

Unfortunately, it looks like shadowcat cleared their paste cache, so those
links don't work anymore. My copy of those scripts (which I played with on
my own machine) are on a laptop that is now out of commission. *Joel*, do
you happen to have those pastes lying around?

As for Craig's idea of implementing PDL::isa, I appreciate the flattery,
but somebody far more clever than me (Matt Trout) has already written
Safe::Isa <p3rl.org/Safe::Isa>. We could simply use that module, or we
could cook up our own variant to handle the unblessed hash case.

David

Post by Chris Marshall
Given that the special handling of PDL attributes is to
enable inheritance and extensions based on PDL, I
think that we may not need to support an unblessed
hash with a PDL key as a PDL. The whole point is
that you have an object that wants to be a PDL too...
For that, you could use Scalar::Util blessed().
--Chris
On Wed, Oct 30, 2013 at 12:33 PM, Craig DeForest

Post by Craig DeForest
Using "eval {$thing->isa('PDL')}" solves Ingo's problem, and I'm happy

to do that -- the real question is how to avoid this problem with
*unblessed* hashes with PDL keys in them, and whether treating unblessed
hashes with PDL keys as PDLs is even a behavior worth supporting.

Post by Craig DeForest

Post by Craig DeForest
Ingo, immediate cause of the issue you're having is an oversight in

PDL::Graphics::Gnuplot, but it has deeper problems that extend right to the
heart of the Perl object system. PDL::Graphics::Gnuplot uses
'UNIVERSAL::isa($thing, 'PDL')' to detect PDL arguments in
PDL::Graphics::Gnuplot, which has known issues. In fact, your problem is
a classic example of why one does *not* use UNIVERSAL::isa -- some types of
object require more logic than UNIVERSAL::isa provides. I've seen people
advocate, instead, variants of

Post by Craig DeForest

Post by Craig DeForest
(eval {$thing->isa('PDL')})
which works for subclasses of PDL (that may overload isa). But even

that is broken for your case -- because PDL permits you to use an
unblessed hash as a PDL in certain circumstances, so long as the hash
contains a 'PDL' key.

Post by Craig DeForest

Post by Craig DeForest
( (eval {$thing->isa('PDL')}) or ( (ref $thing) =~ m/HASH/ and

exists($thing->{PDL}) ) ) )

Post by Craig DeForest

Post by Craig DeForest
or, better,
( (eval {$thing->isa('PDL')}) or PDL::isa($thing,'PDL') )
where PDL::isa is still to be written. But that is cumbersome, slow,

and ugly as sin. It would be nice if there were a PDL::isa so that you
could write

Post by Craig DeForest

Post by Craig DeForest
( PDL::isa($thing,'PDL') )
or even
( PDL::isa($thing) )
but that has the same sort of philosophical problem as using

UNIVERSAL::isa -- one day David Mertens, or someone almost as clever as
him, is going to write a PDL::Nifty that includes a PDL::Nifty::isa.

Post by Craig DeForest

Post by Craig DeForest
Does anyone have thoughts on how to fix this properly?

Post by Chris Marshall
I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.
--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought

I

Post by Craig DeForest

Post by Craig DeForest

Post by Chris Marshall

Post by Ingo Schmid
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.

PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',

Post by Craig DeForest

Post by Craig DeForest

Post by Chris Marshall

Post by Ingo Schmid
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and

includes many small bug fixes.

Post by Craig DeForest

Post by Craig DeForest

Post by Chris Marshall

Post by Ingo Schmid

Post by Craig DeForest
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive

rounds of testing, trying to get Microsoft Windows' limited IPC to work
properly.

Post by Craig DeForest

Post by Craig DeForest

Post by Chris Marshall

Post by Ingo Schmid

Post by Craig DeForest
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Ingo Schmid]

Craig,
I don't quite understand. When I take the example below and use
UNIVERSAL::isa, I get this.

pdl> p $ni->UNIVERSAL::isa('PDL')
1

pdl> p $ni->(,,0,0,0,0,0,0)->UNIVERSAL::isa('PDL')
1

pdl> p $ni->isa('PDL')
1

So it's recognized as piddle alright, whatever I use.

Would you say that the usage of
use base PDL;
my %data (
... something else,
PDL=>...
);
deprecated?

What are correct/nice/beautiful/clean alternatives to link PDL and other
stuff directly related?

Ingo

Post by Craig DeForest
Ingo, immediate cause of the issue you're having is an oversight in PDL::Graphics::Gnuplot, but it has deeper problems that extend right to the heart of the Perl object system. PDL::Graphics::Gnuplot uses 'UNIVERSAL::isa($thing, 'PDL')' to detect PDL arguments in PDL::Graphics::Gnuplot, which has known issues. In fact, your problem is a classic example of why one does *not* use UNIVERSAL::isa -- some types of object require more logic than UNIVERSAL::isa provides. I've seen people advocate, instead, variants of
(eval {$thing->isa('PDL')})
which works for subclasses of PDL (that may overload isa). But even that is broken for your case -- because PDL permits you to use an unblessed hash as a PDL in certain circumstances, so long as the hash contains a 'PDL' key.
( (eval {$thing->isa('PDL')}) or ( (ref $thing) =~ m/HASH/ and exists($thing->{PDL}) ) ) )
or, better,
( (eval {$thing->isa('PDL')}) or PDL::isa($thing,'PDL') )
where PDL::isa is still to be written. But that is cumbersome, slow, and ugly as sin. It would be nice if there were a PDL::isa so that you could write
( PDL::isa($thing,'PDL') )
or even
( PDL::isa($thing) )
but that has the same sort of philosophical problem as using UNIVERSAL::isa -- one day David Mertens, or someone almost as clever as him, is going to write a PDL::Nifty that includes a PDL::Nifty::isa.
Does anyone have thoughts on how to fix this properly?

Post by Chris Marshall
I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.
--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.
PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Craig DeForest]

Looks like I completely missed your point then. I'll mock up a PDL subclass and have a look at it.

Post by Ingo Schmid
Craig,
I don't quite understand. When I take the example below and use
UNIVERSAL::isa, I get this.
pdl> p $ni->UNIVERSAL::isa('PDL')
1
pdl> p $ni->(,,0,0,0,0,0,0)->UNIVERSAL::isa('PDL')
1
pdl> p $ni->isa('PDL')
1
So it's recognized as piddle alright, whatever I use.
Would you say that the usage of
use base PDL;
my %data (
... something else,
PDL=>...
);
deprecated?
What are correct/nice/beautiful/clean alternatives to link PDL and other
stuff directly related?
Ingo

Post by Craig DeForest
Ingo, immediate cause of the issue you're having is an oversight in PDL::Graphics::Gnuplot, but it has deeper problems that extend right to the heart of the Perl object system. PDL::Graphics::Gnuplot uses 'UNIVERSAL::isa($thing, 'PDL')' to detect PDL arguments in PDL::Graphics::Gnuplot, which has known issues. In fact, your problem is a classic example of why one does *not* use UNIVERSAL::isa -- some types of object require more logic than UNIVERSAL::isa provides. I've seen people advocate, instead, variants of
(eval {$thing->isa('PDL')})
which works for subclasses of PDL (that may overload isa). But even that is broken for your case -- because PDL permits you to use an unblessed hash as a PDL in certain circumstances, so long as the hash contains a 'PDL' key.
( (eval {$thing->isa('PDL')}) or ( (ref $thing) =~ m/HASH/ and exists($thing->{PDL}) ) ) )
or, better,
( (eval {$thing->isa('PDL')}) or PDL::isa($thing,'PDL') )
where PDL::isa is still to be written. But that is cumbersome, slow, and ugly as sin. It would be nice if there were a PDL::isa so that you could write
( PDL::isa($thing,'PDL') )
or even
( PDL::isa($thing) )
but that has the same sort of philosophical problem as using UNIVERSAL::isa -- one day David Mertens, or someone almost as clever as him, is going to write a PDL::Nifty that includes a PDL::Nifty::isa.
Does anyone have thoughts on how to fix this properly?

Post by Chris Marshall
I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.
--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.
PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Craig DeForest]

OK, Ingo, I've pushed up a fix that should work. There were a couple of cases where "ref $thing eq 'PDL'" was being used as a PDL-ness check; that is clearly bad. Throughout the code, I now use

( eval { $thing->isa('PDL') } || undef $@ )

as a PDL-ness check. That should work for anything you throw at it, except an unblessed hash. So pull down the latest git from http://github.com/drzowie/PDL-Graphics-Gnuplot and let me know if that fixed your issue.

All the best,
Craig

Post by Craig DeForest
Looks like I completely missed your point then. I'll mock up a PDL subclass and have a look at it.

Post by Ingo Schmid
Craig,
I don't quite understand. When I take the example below and use
UNIVERSAL::isa, I get this.
pdl> p $ni->UNIVERSAL::isa('PDL')
1
pdl> p $ni->(,,0,0,0,0,0,0)->UNIVERSAL::isa('PDL')
1
pdl> p $ni->isa('PDL')
1
So it's recognized as piddle alright, whatever I use.
Would you say that the usage of
use base PDL;
my %data (
... something else,
PDL=>...
);
deprecated?
What are correct/nice/beautiful/clean alternatives to link PDL and other
stuff directly related?
Ingo

Post by Craig DeForest
Ingo, immediate cause of the issue you're having is an oversight in PDL::Graphics::Gnuplot, but it has deeper problems that extend right to the heart of the Perl object system. PDL::Graphics::Gnuplot uses 'UNIVERSAL::isa($thing, 'PDL')' to detect PDL arguments in PDL::Graphics::Gnuplot, which has known issues. In fact, your problem is a classic example of why one does *not* use UNIVERSAL::isa -- some types of object require more logic than UNIVERSAL::isa provides. I've seen people advocate, instead, variants of
(eval {$thing->isa('PDL')})
which works for subclasses of PDL (that may overload isa). But even that is broken for your case -- because PDL permits you to use an unblessed hash as a PDL in certain circumstances, so long as the hash contains a 'PDL' key.
( (eval {$thing->isa('PDL')}) or ( (ref $thing) =~ m/HASH/ and exists($thing->{PDL}) ) ) )
or, better,
( (eval {$thing->isa('PDL')}) or PDL::isa($thing,'PDL') )
where PDL::isa is still to be written. But that is cumbersome, slow, and ugly as sin. It would be nice if there were a PDL::isa so that you could write
( PDL::isa($thing,'PDL') )
or even
( PDL::isa($thing) )
but that has the same sort of philosophical problem as using UNIVERSAL::isa -- one day David Mertens, or someone almost as clever as him, is going to write a PDL::Nifty that includes a PDL::Nifty::isa.
Does anyone have thoughts on how to fix this properly?

Post by Chris Marshall
I would categorize it as a bug, somewhere. Clean-up of the
PDL object/classes/method stuff is on the list for PDL
development leading to PDL3.
--Chris

Post by Ingo Schmid
Hi Craig,
I may have found a bug, or rather lack of feature, I guess. I thought I
better let you know.
$ni is an object from a class declared as
to make of the {PDL} key magic. Apparently, this breaks P::G::G.
pdl> gplot $$ni{PDL}->(,,0,0,0,0,0) # works!
pdl> help $ni(,,0,0,0,0,0)
This variable is Double D [16,16,1,1,1,1,1] -C 0.00KB
Runtime error: Found 0 PDLs for 2D plot type 'with lines', which needs
one of [1,2].
at /usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line
3348, <FOO> line 173.
PDL::Graphics::Gnuplot::parseArgs('PDL::Graphics::Gnuplot=HASH(0x4bb70a8)',
'PDL::IO::Nifti=SCALAR(0x4bcc568)') called at
/usr/lib64/perl5/vendor_perl/5.16.3/PDL/Graphics/Gnuplot.pm line 2501
PDL::Graphics::Gnuplot::plot('PDL::IO::Nifti=SCALAR(0x4bcc568)')
called at (eval 484) line 5
pdl> p $ni->(,,0,0,0,0,0)
[
[
[
[
[
[
[ 0 43 75 63 102 57 42 58 64 76 68 31 51 89 91 101]
[ 0 66 32 40 75 100 90 86 52 88 67 60 79 90 56 76]
[ 0 56 71 95 82 77 98 66 83 43 70 128 86 90 82 84]
[ 0 58 55 48 25 43 42 35 33 40 63 53 39 36 46 47]
[ 0 92 83 103 60 74 34 48 87 66 101 49 136 84 41 56]
[ 0 36 42 81 33 78 60 41 38 64 41 61 51 79 74 38]
[ 0 68 74 79 42 82 65 54 49 33 71 65 43 57 51 59]
[ 0 72 77 70 57 79 40 66 49 78 21 36 56 84 50 89]
[ 0 60 50 35 62 60 55 75 51 89 57 69 107 94 43 76]
[ 0 36 43 102 113 65 38 59 63 81 65 49 79 70 73 45]
[ 0 82 78 86 88 87 48 50 58 39 71 69 85 54 69 83]
[ 0 71 91 52 85 64 88 60 71 79 82 82 58 50 54 96]
[ 0 76 83 70 103 95 47 40 77 52 53 53 52 72 27 48]
[ 0 74 63 69 48 67 29 79 57 30 124 63 41 45 83 88]
[ 0 62 74 69 33 35 74 64 82 65 52 53 82 67 40 84]
[ 0 58 52 68 69 65 108 54 113 45 78 66 71 86 40 64]
]
]
]
]
]
]
Ingo

Post by Craig DeForest
PGG v2.000 uses Alien::Gnuplot for configuration management and includes many small bug fixes.
AG v1.010 works in both POSIX and Microsoft Windows environments.
Thanks very much to Chris and to Jurgen for the usual extensive rounds of testing, trying to get Microsoft Windows' limited IPC to work properly.
Happy hacking,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters