Ed .
2014-08-31 23:06:18 UTC
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.
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.
To expand on the case for the improvement this change makes, to include the parallel support for use Inline with => 'PDL'; (which depends on the EU::D change), I cite this change in Basic/Pod/API.pod:
- # 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.
Likewise, the actual support for ExtUtils::Depends creates similar levels of simplification in XS modules that use PDL. This is a bit of a case of supply creating its own demand. A CPAN search (http://grep.cpan.me/?q=CoreSV.*PDL%3A%3ASHARE) shows at least 6 modules use PDL in XS:
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.
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.
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.
To expand on the case for the improvement this change makes, to include the parallel support for use Inline with => 'PDL'; (which depends on the EU::D change), I cite this change in Basic/Pod/API.pod:
- # 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.
Likewise, the actual support for ExtUtils::Depends creates similar levels of simplification in XS modules that use PDL. This is a bit of a case of supply creating its own demand. A CPAN search (http://grep.cpan.me/?q=CoreSV.*PDL%3A%3ASHARE) shows at least 6 modules use PDL in XS:
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.