Hi David, As of the next version, an undef won’t warn, but it’s semantically already the same as an empty string. Up to you!
Passing a null as an input would not achieve what you want, and is an error as of PDL 2.073 (if nothing else, it hasn’t got any data at all). But passing a Perl scalar as input if you want to pass a single value works great as PDL will promote it as appropriate, as you say. Best regards, Ed From: David Mertens<mailto:dcmertens.p...@gmail.com> Sent: 11 February 2022 12:00 To: Ed .<mailto:ej...@hotmail.com> Cc: pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net> Subject: Re: [Pdl-devel] Issue when setting PMFunc to undef Hello Ed, Thanks for clearing that up. What you describe is exactly what I meant to achieve. The PDL::PP version of the function is not meant to be called directly. It is meant to be called by the Perl-side wrapper. I suppose I could set it to an empty string instead of undef. For details: the PDL::PP code needs to be written so it can broadcast over all optional values, but that means you have to call the function with a piddle for all optional values. The wrapper actually provides a Perl scalar, 0, which PDL kindly converts to a piddle in the function call. Actually, I wonder if it would be faster if I provided null piddles instead, but that's probably a premature optimization. David On Thu, Feb 10, 2022 at 5:10 PM Ed . <ej...@hotmail.com<mailto:ej...@hotmail.com>> wrote: Hi David, Welcome back, and glad to hear the Prima modules are getting some attention! I recently added “use strict; use warnings” to everything in the PDL distro, and have squashed (or in some cases actually fixed) most of the warnings resulting. Evidently this is one I missed. I have just added a commit to not use the PMFunc if it is set to undef. For clarity: PMCode is pure-Perl wrapper code (which also makes the XS not have varargs handling, which always struck me as pointless); PMFunc overrides the default of making the “PDL::whatever” also be in the current package and therefore exportable, so setting it to undef or empty-string would prevent that behaviour. Once you’re happy with updated Prima modules, please let us know so we can make sure the PDL::Graphics::Simple driver for it also is up to date (or of course you can check that yourself and PR the results!). Best regards, Ed From: David Mertens<mailto:dcmertens.p...@gmail.com> Sent: 09 February 2022 04:47 To: pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net> Subject: [Pdl-devel] Issue when setting PMFunc to undef Hello everyone, After years, I am finally dusting off PDL::Graphics::Prima. I'm compiling PDL::Drawing::Prima and getting a lot of warnings of this sort: Use of uninitialized value $obj{"PMFunc"} in concatenation (.) or string at /home/dcmertens/perl5/lib/perl5/x86_64-linux-thread-multi/PDL/PP.pm line 1060. Interestingly, in my pp_def calls, I consistently set PMFunc => undef and PMCode to something interesting. My memory is too hazy for me to remember the distinction between these two, but presumably I had a reason for doing this back in 2011. Note: everything compiles and works fine. Is this a bug in how pp_def handles PMFunc, or is there something in my code that I should change to suppress these warnings? Thanks! David -- "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
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
