Hi Diab, It seems you got the same level of response I got a month or two ago, having made the same offer, including from you ;-)
The elephant in the room, as I may have said several dozen times over the last number of years, is that CHM is very busy. Until he wants to release stuff, or actually hand over the reins, no change is possible. Of course, his recent expression of willingness to hand over is a start. I have thoughts on the very preliminary outlines of your thinking that you shared: Cathedral vs bazaar It seems like your approach to this is quite cathedral-y (creating an entire proposal in splendid isolation, taking a very long time); you might achieve more if you went more bazaar-y, and started sharing your ideas in smaller chunks, and earlier. I have never experienced my ideas being worse as the result of others' inputs, and they've pretty much always been better. PDLA, etc It would be useful for you to clarify whether you intend to ignore the stuff I have done with PDLA and continue with PDL, or to instead be part of the PDLA "thing". I made the deliberate choice to avoid namespace clashes by making the new namespace, in order to avoid creating any problems for those using legacy PDL. It would be useful if you include how you would deal with the entirely plausible scenario of another year or two of PDL paralysis. Spell out stuff If you've identified how PDLA needs to go further than splitting into chunks, I hope you will share with us how. I assume it will include the obvious steps of shifting towards the inclusion of extra PDL functionality with something like roles, rather than the manual namespace stuff which makes PDL's namespace vast and confusing to program. Best regards, Ed -----Original Message----- From: Diab Jerius Sent: Thursday, May 23, 2019 3:11 PM To: pdl-devel@lists.sourceforge.net Subject: Re: [Pdl-devel] PDL release; I'm volunteering. 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 _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
