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> 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> 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> > *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 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", 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 /\_/\__/ > GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB > > > _______________________________________________ > 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
