---------- Forwarded message --------- From: Diab Jerius <djer...@cfa.harvard.edu> Date: Tue, Jun 11, 2019 at 9:51 AM Subject: Re: [Pdl-devel] Fwd: PDL release; I'm volunteering. To: Chris Marshall <devel.chm...@gmail.com>
Sorry for the radio silence! We've had a wet spring in the Boston area and suddenly got nice weekend weather, which meant dealing with lots of postponed yard work, and not much free time. The first thing I've started to work on is to bring the changelog up-to-date for the release, at the same time converting it to something that's compatible with CPAN::Changes::Spec. I should be able to finish that this week. I've also been looking into how we well we support the CPAN::Meta::Spec. On Fri, May 24, 2019 at 10:03 AM Chris Marshall <devel.chm...@gmail.com> wrote: > > 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
