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 <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 > > > > <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 > > <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 > <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 > <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
