Whenever I post to the perldl list, I assume that everyone knows that I know close to nothing about PDL or programming (in spite of banging away at it for a decade or so). Most of the stuff that I create amazes me that it works at all. So, I am in constant awe of stuff like PDL. But, that also means that when I say something like, "It would be nice for PDL to be able to read ERDAS files" or "It would be nice if PDL were available as a macport," I am really saying, "It would be nice if someone else would make the above happen."
No, seriously, it is not for a lack of time or motivation, but that I really have no clue how to go about it. Nevertheless, since I was able to get PDL 2.4.6 to install on my iMac via macports, I will study the portfile (essentially, a set of instructions written in Tcl) to see if I could upgrade that to 2.4.9. Unfortunately, as much as I desire it, I am unable to do anything with the problem of reading ERDAS and other rasters (for example, incorporating GDAL and OGR or Bio-Formats into the PDL build). I do think that it would be nice to have better support for different data formats in PDL. My unscientific sense is that SciPy does have a much better support in this department than PDL does. More below... On Nov 21, 2011, at 1:41 PM, David Mertens wrote: > Puneet > > I think this is a great idea, though it's not a top priority of mine right > now. As one of the Porters, I wanted to be able to twiddle with and compile > PDL from source, so finding a way to install everything so that I could > compile from source was important. I ran into a snag with GSL, but Joel's > suggestion of Homebrew solved that issue for me. Which brings me to this > question: > > If I were to install GSL or one of the other optional packages (like FFTW) > using MacPorts, how easily does that play with compiling PDL from source? Probably not easily, but since macports sandboxes everything under the /opt/local space, you could perhaps point full paths to specific macport installed libraries when configuring PDL from source. But, the other direction would be more problematic as your hand-rolled software will go into /usr/local, and would not be picked up by anything that might be compiled by macports subsequently. > I > would expect it works just fine, but I was surprised that the GSL installer > did not work. That's not to say that you shouldn't move forward: please do. > Just be aware that this might be an issue. > > As one who recently acquired a mac, I have this question: now that I have > my PDL install working, how might I try installing PDL using a different > approach without trashing my current install? Just install it under a new prefix, perhaps. One thing that macports allows you to do is to have multiple versions of anything, and you can activate-deactivate anything on demand, kinda like perlbrew. > If it were Linux I'd just > create a virtualbox, but I don't have any install media for the Mac OS, so > I can't do that. That makes it much more difficult for me to help diagnose > and debug any of your work. If you have VMWare Fusion (or Virtual Box), you can install other operating systems, including Lion and Leopard, etc. You could potentially download the "recovery partition" maker from Apple's web site, and use that to create a recovery partition on a USB drive, use that to boot a bare OS image on a VMWare instance, and then re-download and install your copy of the operating system from the app store. Sounds convoluted, but might work. > > Thoughts? > David > > On Sun, Nov 20, 2011 at 10:41 AM, Mr. Puneet Kishor > <[email protected]>wrote: > >> The latest version of PDL available on Macports is 2.4.6, and it installed >> very easily. Actually, the first time I tried to install it, there was a >> problem with pdlcore.h. I filed a ticket. Am not sure if the ticket was >> addressed or not, but I tried it again a few days later, and it installed >> easily and cleanly. I also wanted PDL::NetCDF, but it was not available on >> Macports; the other netcdf module was available. In any case, PDL::NetCDF >> installed really easily even though I had to download the code and compile >> it. >> >> Macports has now a new capability added to it... the ability to add pre >> made binaries. If macports determines that the client computer is >> compatible with an existing binary, just the binary is downloaded an >> activated without need to download the source code and compile it. Saves a >> lot of time. >> >> My suggestion -- move the Mac PDL effort from SciPDL to macports, which >> would download and activate the pre-built binary where appropriate, or >> build PDL from scratch for other instances. >> >> I discovered Macports a few months ago, and have really enjoyed my >> experience. Until then, I insisted on compiling all my software, but it >> really was a needless exercise in pain. I also realize there are >> alternatives to Macports (Homebrew, Fink, etc.), however, my experience is >> limited to Macports, and from just reading about, I find their approach >> better. For example, they don't use anything from the system installed >> software. Either an existing Perl is used, or, if a particular port is >> really finicky about perl versions, a perl specific to the port can also be >> used. >> >> In short, being able to install PDL via macports helped me get on with the >> science problems instead of spending too much time on the installing >> problems. >> >> -- >> Puneet Kishor >> >> >> >> _______________________________________________ >> Perldl mailing list >> [email protected] >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >> > > > > -- > Sent via my carrier pigeon. _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
