I think I've officially been Warnocked. I've been working my way through a number of areas (graphics, ppcode, module layout, documentation, etc), but haven't finalized a proposal for what I would hope to accomplish as the next release manager.
If that's what's holding up any response to my offer, or if I've unknowingly tread on some toes, please let me know (or more references are required) please let me know! Thanks, Diab On Thu, May 9, 2019 at 2:38 PM Diab Jerius <djer...@cfa.harvard.edu> wrote: > > Hi, > > I'm willing to marshal the next release of PDL.[0] > > PDL needs to keep going while its future successor is developed and > planned.[1] While PDLA is promising, it's not a simple drop-in > replacement, and perhaps shouldn't be. > > To move PDL into its proper place in the Perl ecosystem[2] requires a > lot of work. Splitting it into chunks as Ed has done with PDLA is a > start, but in my opinion it needs to go further than that. > > PDL library organization isn't obvious, we have internal namespace > collisions (does everything really need to be a method on a PDL > object?), there's no proper C API (e.g. documented, and callable from > non PP-generated C code). We need to make it so easy to interface and > work with PDL that all of the non-PDL numeric code on CPAN becomes > obsolete. While I don't find PP code to be horrible, there's no doubt > that it's not user friendly. We need to change that. > > We also need tighter integration with NumPy, Julia, and R so that we > can leverage those ecosystems without horrendous overhead. > > There's a lot we can do to modernize the existing code base to make a > transition easier. Most of it starts with documenting and adding > tests, so that we can be sure we don't break things as we move along. > The thorniest work will be dealing with Core and PP. There's a lot of > undocumented behavior and a bit of cargo-culting in there which needs > to be teased out. > > CPAN is the wild west, and there are PDL modules there which may > conflict with a consistently designed PDL library ecosystem. We need > to reserve the PDL namespace for the "official" ecosystem and have a > separate namespace for contributions outside of it. Namespace > pollution is a significant problem that we have to deal with. > > I'll take some time this weekend to draft my ideas on modernizing the code. > > > [0] My credentials are that I've been using Perl and PDL for a long > time, I'm happy to dive into C code, and I've made a few contributions > to PDL over the years. My CPAN contributions are here: > https://metacpan.org/author/DJERIUS > > [1] I'm not quite convinced Perl6 is ready for numerics, and Perl5 is > still a viable language. Not to mention lots of code using PDL is out > there! > > [2] It's frustrating to see projects on CPAN which should use PDL but > don't. PDL doesn't have the same visibility as does NumPy in the > Python world, and we need to change that. _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
