Hi Chris,

I just tried rebuilding PDL with TriD, and I am happy to report that
PDL::Graphics::TriD builds on my Mac without any problem (I am using
Mac OS X 10.6.4).

I got the following report (relevant to TriD) when making the Makefile

--------------------------
   USE_POGL is set, will build TriD using OpenGL.

Graphics/TriD/Makefile.PL: using POGL for OpenGL bindings and compile options
Writing Makefile for PDL::Graphics::TriD::Rout
Writing Makefile for PDL::Graphics::VRML
Checking if your kit is complete...
Warning: the following files are missing in your kit:
        Changes
Please inform the author.
--------------------------

I have no idea what "Chages" is... if I try to install a module called
"Changes," I get something called Alien::BWIPP

--------------------------
punk...@lucknow ~$sudo cpanm Changes
Password:
! Finding Changes on cpanmetadb failed.
Fetching 
http://search.cpan.org/CPAN/authors/id/D/DA/DAXIM/Alien-BWIPP-0.006.tar.gz
... OK
Configuring Alien-BWIPP-0.006 ... OK
Building and testing Alien-BWIPP-0.006 for Changes ... OK
Successfully installed Alien-BWIPP-0.006
--------------------------

Nevertheless, PDL builds without any issues, as long as I make the
corrections to the Graphics/PLplot/Makefile as document earlier.

Another issue... I ran a few demos for TriD (just to make sure things
were working). I get the rendered images (charts) to show up in a
separate window, but then the program hangs. When I try to close the
window, (there is no obvious way to close the window and terminate the
program), I get the following error

-----------------------------
PDL> use PDL::Graphics::TriD
PDL> $a=sqrt(rvals(zeroes(50,50))/2)
PDL> imagrgb [0.5*sin(8*$a)+0.5,0.5*cos(8*$a)+0.5,0.5*cos(4*$a)+0.5]

(this is where I try to close the window that popped up with imagrgb chart)

Runtime error: Unable to locate glut handler at
/usr/local/lib/perl5/site_perl/5.12.1/darwin-2level/PDL/Graphics/OpenGL/Perl/OpenGL.pm
line 328, <DATA> line 387.
PDL>



On Sun, Jul 4, 2010 at 10:22 PM, Chris Marshall <[email protected]> wrote:
> On 7/4/2010 9:38 PM, P Kishor wrote:
>>
>> On Sun, Jul 4, 2010 at 8:23 PM, Chris Marshall<[email protected]>  wrote:
>>>
>>> On 7/4/2010 8:48 PM, P Kishor wrote:
>>>>
>>>> This is likely to be a common reality. For many Mac users, they go to
>>>> 64-bit via 32-bit (upgrade Mac OS X 10.5.x to 10.6.x). This leaves a
>>>> lot of custom stuff in the 32-bit world still hanging around. Very
>>>> unlikely that a user will have a clean machine. For those that do,
>>>> installs will be a lot easier.
>>>
>>> True but PDL cannot fix problems with user systems
>>> and their private configuration problems.  However,
>>> a clean run through the entire PDL build is necessary
>>> to diagnose what needs fixing in PDL to support the
>>> Mac platform.
>>>
>> ..
>>
>>
>> Chris, you have used the term "a clean run" or a "clean build" a
>> couple of times, so I am curious what you exactly mean by that. Do you
>> mean the target computer should be clean, without any previous
>> installation of PDL? If so, only someone who has never installed PDL,
>> has not upgraded from 32-bit to 64-bit, not installed any software
>> libraries... basically, someone with a brand new computer, updated
>> with only Apple's updates, decides to install PDL. That kind of a
>> person would be hard to find. Maybe I will be that, when sometime in
>> the future I buy a new computer... not for another couple of years.
>
> That is one of the reasons it is difficult to debug
> installation.  If I want to check out the latest PDL
> I would need to completely wipe my existing installation
> of PDL.
>
> The good news is that by using the PREFIX and LIB
> arguments it is possible to have PDL installed and
> usable but non visible for a "clean install test".
>
> The bad news, it that is does take at least once
> through the exercise and you have noted many of
> the difficulties in setting up for that.  I found
> a very large number of little gotcha's when I
> started porting PDL to cygwin since I was doing
> it from scratch and not from a pre-existing setup...
>
>> On the other hand, if you mean that the new installation of PDL should
>> be from a clean source, well, that is what I do. I downloaded PDL
>> 2.4.6, installed it. A few days/weeks later, I downloaded PDL 2.4.6_11
>> in a completely different directory, and tried to build it there. Of
>> course, I can build it a million times, but until I do a 'make
>> install' it stays inside its src directory, leaving the current,
>> working version of PDL 2.4.6 alone.
>
> Even this much is useful information.  For example, I
> don't know if you ever got TriD working.  As far as I
> know it should build out of the box for PDL on the Mac.
> Since I don't have a Mac I cannot verify that myself.
> If no one reports problems and success, we don't even
> know what or if things need fixing.
>
>> For now, the one that does need fixing is that Makefile for
>> PDL::Graphics::PLplot. Most users will likely stay away from esoteric
>> Fortran stuff, but most will want to install some kind of graphics
>> capability. PLplot seems to be the most mature option (I could be
>> wrong in that assessment). Fixing that Makefile will really make
>> things a lot easier. Both the error and the fix are well documented.
>> They just need to be baked in.
>
> We're trying to reduce the cross platform issues for
> PDL.  Reducing the number of different language compilers
> needed will help with that.  Using fortran is definitely
> a complexity inducer.  :-(
>
> Thanks always for the thoughts.
>
> --Chris
>
>



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

Reply via email to