I have looked at PP myself in the past, and quailed a bit. It’s on my list of things to do some work on, starting with making the output nicely readable, and having it include comments that show which bit of the PP module makes each part.
However, that is not an immediate element of the PDLA plan. One step at a time! From: Terry Gaetz<mailto:tga...@cfa.harvard.edu> Sent: Saturday, April 13, 2019 5:45 AM To: Karl Glazebrook<mailto:karlglazebr...@mac.com> Cc: Ed .<mailto:ej...@hotmail.com> ; pdl-devel<mailto:pdl-devel@lists.sourceforge.net> ; Terry Gaetz<mailto:tga...@cfa.harvard.edu> Subject: Re: [Pdl-devel] Whither PDL? I have been using PDL for more than a decade (or is it two?). Generally, mere users don't pipe up on pdl-devel... I make extensive use of the PDL affine transformations and PDL threading. I'd like to work with PP, but it has been too intimidating so far, so if PDLA provides a gentler entry, that would be welcome. So, yes, there are users out there. PDLA sounds intriguing. There is an awful lot of the current PDL I depend on, so there will be a threshold for my transitioning to a PDLA system. That said, I could try smaller projects as a test bed for eventual transitioning. Terry On Fri, Apr 12, 2019 at 10:16 PM Karl Glazebrook via pdl-devel <pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>> wrote: Thanks Ed for restarting this conversation. Your fix-lite patch seems good to me. > Do people still use PDL? - Yes I do, I have a number of scripts and stuff for my research. These days I do also use python (about half my coding probably) as my collaborators and students all mostly use it (it has captured the astronomy mindshare). > Is PDLA a good idea - Yes, heaviness is a major barrier to adoption. Getting a full PDL installed can be really difficult (esp. on Mac unless you use my kitchen sink which brings its own problems) because there are so many packages with complex non-perl dependencies and so many ways to go wrong. Breaking it up in to a set of light weight packages that can be installed by convenient package managers that people use would give it a future. I think we should seriously discuss the proposition: that the current PDL should be put in to maintenance mode, (critical bug fixes) and that development should be moved in to something like PDLA. Karl On 13 Apr 2019, at 3:40 am, Ed . <ej...@hotmail.com<mailto:ej...@hotmail.com>> wrote: Hi Luis, I’m really glad this subject came up. A lot of this discussion is the first time I’ve articulated some of these things (as opposed to just being ideas), and it’s increasingly clear that it will be highly useful to include an “explanation” as well as the tips in the PDLA top-level docs. Yes, your scripts would need to say “PDLA” everywhere, not PDL. This is to avoid clashes. As far as I know, I’ve also changed all the installed scripts to have different filenames. If I haven’t, that’s a bug, please open an issue! The plans to update PDLA to 2.019 are in place, as mentioned earlier, and not a great deal of labour. It would be really useful to get a quick bit of “on the ground”, real scientist input on using PDLA in a small thing, just to confirm it actually works. Please let me (and us) know the results of your experiments! As you say, using a local lib, within a perlbrew, really does act as two levels of isolation to avoid risk. Best regards, Ed Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ________________________________ From: Luis Mochan <moc...@icf.unam.mx<mailto:moc...@icf.unam.mx>> Sent: Friday, April 12, 2019 6:25:36 PM To: Ed . Subject: Re: [Pdl-devel] Whither PDL? On Fri, Apr 12, 2019 at 02:45:34PM +0000, Ed . wrote: > Hi Luis, > > Good to hear there's at least one list participant, and at least one user > :-) Hope more appear... > > PDLA - the "A" stands for "Agile". The concept was to unwedge the > development of PDL, by moving it to a place where the core was separated > from the many, many awesome extras that have become part of the distro. The > problem with the large distro was that any part of it not working was a > blocker to further release. PDLA is a fork of PDL (approximately) 2.013 > currently, with PDLA::Core as a separate distro, on which PDLA depends. Then > further parts of PDLA can be split into separate CPAN distros, all depending > on PDLA::Core (and anything else they need to). Thanks for the explanation. > > The updating process won't be hard, since I mostly automated the bringing > across of each patch from PDL. I'll do one release for each PDL main-release > (which is only 6), then make further "sub" releases with further splits. The > benefit is a quicker release process, quicker installation, and less risk > for each release. I don't mean to put words in CHM's mouth, but the last > thing I recall him saying on this list, on this subject, was a hope that I > would continue this process. I hope I got that right (and he can speak up!), > and I hope that's still true. > > If you don't mind using the equivalent of 2.013, rather than 2.019, you can > install full PDLA with just "cpanm PDLA", or just the core with "cpanm > PDLA::Core". Then change any of your code to use "PDLA" instead of "PDL", > and it should "just work". I guess I should change all PDL's to PDLA's. Are there equivalents to all PDL's modules? There have been some problems with previous PDL's that have been solved in 2.019, so I'm not sure I can use 2.013. Are there plans to update PDLA upto 2.019 (and beyond). > My version-numbering scheme deliberately adds a further 3 digits to the 3 > used by PDL, allowing me to iterate very rapidly, while still being visible > what we're tracking. The intent further will be to increase, not decrease, > the reproducibility of PDL* scientific results, because it will be > super-easy (and I will document all these points) to get people to use known > versions of things. Your scientific paper could have a little "PDLA > installation" paragraph which might say: > > perlbrew install perl-5.26.1 > perlbrew use perl-5.26.1 > perlbrew lib create experiment-6 # you can make other local-libs, with > different versions of eg PDL > perlbrew use perl-5.26.1@experiment-6 > cpanm PDLA::Core@2.013000 PDLA::Some::Other@1.002 # very specific version of > PDLA, to *guarantee* reproducibility > wget > https://raw.githubusercontent.com/myusername/experiment-6/master/processing.pl > # made-up but correct URL format > wget > https://raw.githubusercontent.com/myusername/experiment-6/master/dataset # > made-up but correct URL format > ./processing.pl<http://processing.pl> dataset > # etc Thanks for these useful/detailed suffestion. > > You will see that almost all of this is also applicable to PDL. People have > made these fantastic tools, which genuinely solve the previously terrible > problems of reproducibility. There is of course the remaining problem of PDL > config such as BADVALUE. > > On that point, someone (probably me) needs to change PDLA to have things > like BADVALUE etc from an install-time choice, to a runtime choice. That way > the same "processing.pl<http://processing.pl>", which specified BADVALUE > itself, would run the > same on the same data and same version of PDLA. That would be a change from > PDL, though the defaults would be the same as out-of-the-box PDL, so a > better description might be just "added feature". > > This really won't take much work to do, and I would love to see this bit of > unfinished business get tidied up. I just want to be sure people will > actually use it :-) I guess there could be a problem installing both PDL and PDLA simultaneously. According to what I just read, the scripts installed by PDLA have the same names as those of PDL (for example, pdl2). So care should be taken to use one or the other instead of replacing one with the other, maybe using the perlbrew lib trick you mentioned above. Anyway, I'll start experimenting with it. Best regards, Luis -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Apdo. Postal 48-3, 62251 | (*)/\/ \ Cuernavaca, Morelos, México | moc...@fis.unam.mx<mailto:moc...@fis.unam.mx> /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/pdl-devel _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net<mailto: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
