Diab, I think another "bitrot fix" release of the legacy PDL is a good idea. Thanks for volunteering to be release manager. I'm happy to transfer the various PDL maintainerships I have accumulated over time. Then you can distribute any co-maintainerships and handle any other module rights stuff that might come up.
Ed, Thanks for picking up the PDL/PDLA threads again! In the next few weeks I have some time to contribute to a new PDL point release and to assist with the transition of module ownerships. V/r, Chris On Thu, May 23, 2019 at 1:28 PM Diab Jerius <djer...@cfa.harvard.edu> wrote: > ---------- Forwarded message --------- > From: Diab Jerius <djer...@cfa.harvard.edu> > Date: Thu, May 23, 2019 at 12:40 PM > Subject: Re: [Pdl-devel] PDL release; I'm volunteering. > To: Ed . <ej...@hotmail.com> > > > Ed, > > Thanks for your reply > > > > On Thu, May 23, 2019 at 11:37 AM Ed . <ej...@hotmail.com> wrote: > > > > 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 ;-) > > Sorry about the lack of reply to your proposal; I need to review my > ability to review email! > > I (perhaps mistakenly) saw your proposal as whether or not to continue > with PDLA rather than PDL, and picked up on a thread in the > conversation which followed where Chris indicated he no longer had > time. > > > > > 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. > > I very much prefer bazaar. I've wandered around the PDL code for far > too many years, and keep pulling on what I think are isolated issues > I'd like to fix, only to find they're not isolated at all. I need to > bring my ideas into a coherent state for presentation, as at the > moment they touch upon almost all of the PDL code, and are not > completely separable. > > > > > > 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. > > I value the work you've done on PDLA and actually wish to integrate it > into PDL. I believe there's a way to go forwards while maintaining > reasonable amounts of backwards compatibility. It's one of the things > I've been thinking about a lot. > > > > > > 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. > > By roles, I'm presuming you mean the run time loading of methods into > the PDL class? If so, that's essentially what many PDL modules do now > (by importing everything into the PDL namespace), and I find it leads > to significant namespace problems. (Please note, I'm actually overly > fond of roles, say in the Moo/Moose role sense). > > Let's say that two roles create a similarly named method, 'histo'. > The one which gets added to the PDL class is the first that get's > used, but if a module requires RoleA::histo, but RoleB::histo is > loaded first, then when the module calls $pdl->histo, it gets > RoleB::histo, not the one it wants. There's no way to fix this, other > than exposing histo as a function, and allowing each module to choose > which histo it wants to use. > > My philosophy is that the only things that should be methods are those > that require knowledge of the private innards of a piddle, or that are > required for implementing overloaded operators (useful for subclassing > PDL. I had to write overload::reify to deal with some of the PDL > overloads). Keep the core tight, and everything else becomes a > function, which users have much more control over. > > > > > > > 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 >
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
