[Pdl-porters] Case for the ExtUtils::Depends change

Zakariyya Mughal

2014-09-08 22:05:22 UTC

Post by Ed .
Dear PDL porters,
Please see below the case for this change, which Chris has asked me on
#pdl to make yet again. This is cut+pasted from
https://sourceforge.net/p/pdl/feature-requests/81/.
In answer to Chris’s point about backwards compatibility on all main
platforms, this is something that ExtUtils::MakeMaker also needs, to a
rather greater extent, and to which I have contributed quite a bit
recently. What you've done so far has been amazing - making, for free,
a competitor for best-in-class mathematical processing software. But
what you have now is a log-jam. No-one will bother to do the work to
(eg) break PDL2 down into smaller parts (which previously I was
interested in doing), as we did recently for Inline, if they can see
changes are ignored. The usual open source mantra is “patches
welcome”. That is self-evidently not the case here.
What will benefit here is not necessarily to do things at 100mph, but
to be responsive: if someone is offering to do some work on this
volunteer project, talk to them about the what/how of it, telling them
about how to do a sourceforge fork and merge request. Then they can
concurrently go off and prepare their work, and when they MR it,
whoever has taken "ownership" of working with them will aim to be
responsive in a reasonable time. If people are ignored, you lose them.
This point extends beyond new people: there are people developing
stuff on branches in the repo. Which branches? Who "owns" each one?
What are they doing? Are they talking to each other? If so, it's not
on pdl-porters. It seems like there is an opportunity to improve here.

Yes, I too was a bit confused when I was looking at the PDL git
repository. I'm new to PDL development, so I don't know the entire
history of each branch. I would like to have more discussion about this
on the list or a document which explains some of the activity going on
in the repository. I have subscribed to everything that Sourceforge lets
me subscribe to, but that took me a while to find on my own.

I get that there might not be enough people to warrant that level of
discussion, but it is a bit of a chicken-and-egg problem where new
developers aren't being drawn in. I really do love using PDL and wish to
see it grow, if only to make my research easier. It's much more fun to
use than the MATLAB I write everyday — even if MATLAB has more
functions[*]. If you've seen some of the recent Perl news, there was
discussion about the roadmap for Perl5 Porters. I know it might be
controversial to speak of such things, but is there such a roadmap for
PDL? I see the TODO file in the PDL,
<http://sourceforge.net/p/pdl/wiki/PDL_TODO_List/>, and
<http://sourceforge.net/p/pdl/wiki/GSoC_2012_Ideas/>,
<http://sourceforge.net/p/pdl/wiki/PDL_way_forward_draft/>. Should there
be an effort to consolidate that?

To add to Ed's point about ExtUtils::Depends, apart from my work on
refactoring the tests for PDL, I have been experimenting with R
internals to make a PDL-compatible API for R. Having ExtUtils::Depends
support would make the code I'm writing a little bit cleaner. Instead of
what I have at
<https://github.com/zmughal/embedding-r-in-perl-experiment/blob/master/R-array.pl#L10>,
all I would have to do is

use Inline with => [ qw( Rinline PDL ) ];

and my build would just work (as long as R is installed). I hope to have
other modules such as my Image::Leptonica image processing bindings work
with PDL the same way.

Cheers,
- Zaki Mughal

[*]: MATLAB also has quite a lot of bugs / incompatibilities across
versions. Never change your MATLAB version in the middle of a
project. I learned that the hard way.

Post by Ed .
Best regards,
Ed
--------------------------------------------------------------------------------
This is worth emphasising right at the top: the changes I propose do not affect any existing functionality, so there should be no risk of breaking anything already there.
I am responding to chm's implied request today to make the case for my changes.
- # the reason for this config call is explained below
- use Inline C => Config =>
- INC => &PDL_INCLUDE, # make sure we find pdlcore.h etc
- TYPEMAPS => &PDL_TYPEMAP, # use the PDL typemap
- AUTO_INCLUDE => &PDL_AUTO_INCLUDE, # global declarations and includes
- BOOT => &PDL_BOOT; # boot code to load the Core struct
-
+ use Inline with => 'PDL';
Simplicity, expressiveness.
Module Comment
PDL-Parallel-threads (by run4flat, of this parish) - uses Module::Build, EU::D doesn't yet support
Gimp-Perl (would benefit from simplification of this change)
Meschach (ditto)
PDL-Parallel-MPI (ditto)
Inline-SLang (looks like it could be radically simpler)
NCAR (ditto)
There is probably a case to be made for a doc with an example of a module that uses Inline to make a make a trivial-ish "XS" module that does something with a C-level piddle. I predict the Makefile.PL, and the *.pm file, would be only a few lines thanks to these changes.
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters