On Sun, Jul 25, 2010 at 3:07 PM, Daniel Carrera <[email protected]> wrote: > Hi Matt, > > On Sun, Jul 25, 2010 at 9:04 PM, Matthew Kenworthy > <[email protected]> wrote: >> 1) With the combination of OSes and processors, we would end up >> supporting approximately a dozen or so static builds, each probably 1 >> Gb in size, as we have to build a perl from scratch for each >> combination. I know this because I did this for Mac OSX as an >> experiment prior to building SciKarl in January 2010. > > Wow. How come this isn't a problem for Padre? They have only one > static download for Windows, one for Linux, one for Mac. For other > OS's or other CPUs you use CPAN.
Mac itself actually has two builds for its current processor, and more if you include previous but still viable processors: 32-bit/64-bit for 10.6 on Intel, 32-bit for 10.5 on Intel and PPC, and 32-bit for 10.4 on Intel and PPC. In any case, someone would have to do this. Why that is a problem is explained by Matt in the following para... > > >> 2) More fundamentally, PDL is built on Perl, and people expect PDL to >> work with Perl modules they've installed themselves. WIth a static >> build, there would be two perls on a given system, leading to lots of >> Module confusion (I've tied myself in knots with this problem....) > Padre is an IDE. It works and can work on its own. Its job is to create programs, not run them. Personally, I don't use Padre. I don't (yet) like it. So, I can live without it, and still have PDL. PDL, for me, is part of a bigger plan, a larger work flow and project. It would be very difficult, confusing, perhaps insanely difficult to use one installation of Perl for part of the work and another installation of Perl for PDL related work. In fact, Perl is such an integral part of the system that I want to leave the system Perl alone. That is why, I have my own custom Perl where I personally install everything I want to, and that includes PDL. Matlab is a standalone program. Perhaps PDL could also be considered a standalone program. However, PDL's strength is that it is *not* a standalone program. Instead, it is built using Perl, so you can do everything with Perl, and do PDL things with PDL. > I'm not thinking of current Perl users, I'm thinking of Matlab users > who are not Perl users. Ultimately I want to be able to tell a > colleague that there is a free Matlab alternative that they can try > out. But I will only do that if that alternative is reliable, easy to > install (for a non-Perl user), and properly documented. A PDL that > only serves existing Perl users is not a PDL I would recommend to > colleagues. > > >> We also have PDL dependent on libraries that are beyond our control, >> such as fortran for PGPLOT, and I've always hit stumbling blocks with >> PLplot not correctly building, and then people (incorrectly) blame PDL >> for these problems. > > This is a slight tangent, but I actually side with those people. If > you choose to base your software on an unreliable platform, you are > responsible for that choice. > Not really. PDL is not based on PGPLOT or PLplot. PDL will work just fine without them. You need those modules *only* if you want to use them. > > Daniel. > -- > Intolerant people should be shot. > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ======================================================================= _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
