On Thu, May 23, 2019 at 1:24 PM Ed . <ej...@hotmail.com> wrote: > > Hi Diab, > > Thanks for a very quick reply. I would note that you sent this to me, and at > least I think your thoughts deserve a wider audience so you might also > forward to pdl-devel :-) If so, I'll be pleased to reply there as I believe > this discussion being in the open would be very valuable.
I just noticed that myself, and forwarded my response there. > > No need to be sorry. I was only amused by the situational irony! > > You say you prefer bazaar, I do too. I think well-expressed problems (even > without a fully-offered, or any, solution) are a very valuable thing. Please > start sharing your observations. They might prompt someone to have an > epiphany. > > There is a fundamental problem with "integrating the PDLA stuff" into PDL - > backwards compatibility. PDLA has a sort of licence, by loudly saying so, to > break that. It represents an opportunity to build on PDL, while being a bit > free and easy with the things that don't make sense. Understood. There may be things which cannot be immediately shared across the codebases, but I would like to minimize that to as great an extent as possible. I'm very concerned with not splitting the community between old and new PDL. It may be possible to provide backwards compatibility layers in PDL to handle old behavior; if not, then a cycle of deprecation, just as is done with Perl, would be in order. Even with PDLA, a procedure must be developed to ensure that the code base can evolve. > > Roles: yes, I was absolutely referring to Moo/Moose/Role::Tiny things. > Honestly, on further reflection I think that the vast bloat of methods is a > fundamental error. It's a lot of code to work out whether my new "thing" is > being called as a method, or just as a function. Instead, have subclasses > (if you must, I'm an OO skeptic), or just recommend everything be a > function, and violently deprecate @EXPORT - everything would be called as a > function, except the irreducible minimum of PDL[A] methods. I think you and > I are in agreement on this, which reassures me. Yes, I think we are. I should note that I'm fairly OO in my approach but have dabbled in enough other strategies that I think there's an appropriate mix of approaches that can work (this is Perl after all). Particularly when we're dealing with a group of users that might not eat objects for breakfast. > What would your list of PDL* methods be? I'll have to think about that a bit. > > -----Original Message----- > From: Diab Jerius > Sent: Thursday, May 23, 2019 5:40 PM > To: Ed . > Subject: Re: [Pdl-devel] PDL release; I'm volunteering. > > 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
