Karl Glazebrook wrote: > Hi everyone, > > I've come to this thread pretty late, let me interject some comments. > > It seems to me there are several classes of users > > 1) People who want to use PDL as a dependency on CPAN, for some > lightweight efficient array ops. These people would want it to just > build and install automatically without any hassle which means plain > perl/C and also without any external dependencies. Right now this means > they might lose some basic things such as matrix ops and FFTs, but maybe > we could peel some of those back out of external libs.
I think f2c on the slatec code and the internal FFT algorithm should cover the bases for now. > 2) People who just want PDL to install and then to be used as a system > with Matlab/IDL type IO and Graphics. This is what we have but the > install part bites. Now we have to be careful about the meaning of > 'install'. I would assert that these people really want a binary > one-click install which has to be maintained by someone specifically. One key here is that the PDL installed be usable (easy to start, easy to get help, ...). As is, you have to know too much about perl, cpan, modules, command names,... to even start playing with PDL. The second is the one-click install capability. If we have a usable PDL as described in the previous paragraph, then providing some sort of package installer would address this point. Candidates at the moment are: Mac OS X: SciKarl (once we have someone to build/maintain it) Windows: Strawberry Perl Professional UnixOSen: Various package managers, once PDL is packagable > This means WIndows and Mac - Linux users are probably mature enough to > look after themselves and there is just too many damn distros anyway. > But this is good as Windows and Mac usually have the most curly > dependencies. I tried to achieve this with SciKarl (well I did achieve > it) but my time constraints have not permitted me to keep it up to date. > It's not a big job though for someone keen. [BTW creating SciKarl was > illuminating in just seeing how many CPAN and external dependencies > there really are... I am proud that it installs on a Mac without even a > C compiler which is often handy) > > I agree with Judd that we do not want 'dependency hell'. Seems to me the > way forward is to (a) keep the current PDL mostly as is (b) strip away > some of the more curly modules (PDL::CallExt anyone?) (c) create a > separate PDL::Core [for (1) above] which PDL will depend on and be the > perl/CC bit. We may need to move some stuff in to the core though. So > this is at worst a split in two. We can argue whether graphics/io etc > should be in the core. I am guessing graphics is too curly unless > someone has a brilliant driver idea. Graphics should definitely be in a base, usable PDL install but only in a base PDL::Core install if it will not prevent installation. For example: if the user already has OpenGL installed then the Graphics can be built/used but if not, no attempt will be made to "add on" OpenGL support. > Also someone suggested moving away from MakeMaker - sounds like a good > idea to me! Definitely! A huge piece of non-portability is the shell/cmd and the make/dmake/nmake versions which produces a configuration and special case nightmare. --Chris > > Karl > > > p.s. I suppose I better fill in the survey... > > On 04/11/2009, at 1:07 PM, Chris Marshall wrote: > >> David Mertens wrote: >>> >>> I think we would do well to have all the PDL packages maintained with >>> the save revision-tracking software, and for reasons not entirely clear >>> to me we recently moved to git. >> >> I concur. We moved to git because CVS was outdated and difficult >> to use (as in no one with expertise in configuration and branches >> was in the core developers). The original thought was Subversion >> but by the time we got around to it, git had gone from a linux tree >> only type tool to a nice distributed version control system. >> >>> This may have been discussed on the list before I joined. It would >>> appear that Git's biggest drawback is that the client doesn't really >>> work well on Windows except through cygwin (any comments here, Chris?). >> >> I use the cygwin client on windows. When I'm working with ASperl, I >> just have a cygwin window open for the git stuff. Everything else can >> be done from windows. There may be line ending issues but I have not >> experienced them with cygwin. >> >>> However, Git uses Perl, so I'm guessing there's at least a little bit >>> of sentimental attachment. :) >> >> It is the other way around---if anything. Perl recently changed to >> using git. However, that was not related other than being yet >> another software project switching to git. >> >> --Chris >> >> _______________________________________________ >> Perldl mailing list >> [email protected] >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.425 / Virus Database: 270.14.60/2495 - Release Date: 11/10/09 > 19:56:00 > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
