If TriD/OpenGL is problematic (i.e. no support and
broken) then a good case could be made for moving
it out of the PDL release tree. My recent progress
to get PDL (including PDL::Graphics::TriD::OpenGL)
working under cygwin leads to some questions and
comments:
1. If OpenGL is removed, what will
is that it seems to work great for symmetric matrices
(not the slatec one).
If I check in my code, all tests will pass, but it's still broken.
-Bill Coffman
On 7/8/06, Chris Marshall wrote:
... the root cause of this problem can not be solved with a
simple fix to eigens
In addition to the major bugs on SourceForge, I would
suggest a look at the bugs reported by the CPAN testers:
12094 Won't compile on 64bit arch
17217 PDL won't build with ExtUtils::MakeMaker 6.30
16467 Bug and solution at PDL/IO/Pic.pm 2.4.2, wpic function
14223 NMAKE : fatal error
Cygwin perl appears to be fully thread-enabled but
the PDL build does not enable threading since there
is no -lpthread on the link line. I tried forcing the
option to true and it worked. Further investigation
confirmed:
- Setting WITH_POSIX_THREADS = 1 seems ok for
the current version of
:
- Original Message -
From: Chris Marshall [EMAIL PROTECTED]
.
.
Some of the reading I did suggested that the
pthreads library must come before the c library or
that it could be loaded dynamically. I assumed it
was being pulled in somehow---because of my initial
success
Congratulations Craig!
I'll volunteer to get the 2.4.3 release out of the door. As
I work through the process I'll try to document the steps in
a checklist for future reference.
Here is the release to-do list I have so far. I'll get
started on a draft of the release notes and known problems
I reran the test code and realized I had misread the
previous results. On the hyperthreaded PC the
performance was 2X *worse* not better. The dual
Opteron still shows only a 15% performance penalty.
These results are more consistent (less puzzling) but
still leave the question of whether/if
Attention PDL developers and interested parties:
This is to announce the creation of the PDL 2.4.3
release candidate 1 branch named: rel_2_4_3rc1
This release is intended as a quick point release
for PDL to share the current progress in the PDL
cvs development with the general PDL community.
Was this applied to the rel_2_4_3rc1 branch?
I would like to keep fixes to get 2.4.3 out the
door in the release candidate branch. General,
non-specific fixes for the 2.4.3 release could go
in the main branch.
However, I'm not familiar with the standard
method for release management and am
least
the Changes should indicate which file(s)
were modified and a brief idea of what and why.
See the DEVELOPMENT file for futher info on
using CVS in PDL development. Thanks!
Chris Marshall
2.4.3 release manager___
Perldl mailing list
Perldl
Recent commits to rel_2_4_3rc1 :
- added Astro::FITS::Header as a dependency
- put John Lapeyre's notes on how to migrate an
external PDL module *into* the man PDL source
tree for distribution with PDL into DEVELOPMENT
- tweak to Graphics/Makefile.PL to be more
cautious about building
, it'll be up
on Sourceforge by Monday and to CPAN shortly after
that.
Thanks in advance for a final push with tests.
Cheers,
Chris Marshall
--the hopes soon to be done PDL-2.4.3 release manager___
Perldl mailing list
Perldl@jach.hawaii.edu
http
Josh Narins writes on 10-Sep-2006:
The following tests were skipped. If someone
wants to tell me what to do to try out these
features, and it involves installing debian
packages and/or adding arguments to perl
Makefile.pl, feel free.
t/fftw..skipped
Kare Edvardsen writes:
...
The PGPLOT library is not included - ok - so I downloaded the pgplot
source and installed it to get hold of the library.
Good, did you install both the pgplot-5.2 library *and* the PGPLOT.pm
perl module?
Then 'make' creates a makefile for PGPLOT without
On Dec 14, 2006, at 4:48 AM, Karl Glazebrook wrote:
points($x-where($y5000), $y-where($y5000));
Inspired by your query and KBG's response, I took a
look at the online docs for where and cooked up the
equivalent, shorter, and kind of cool:
perldl points where $x, $y, $y5000
or with parens:
From: Lino Ramirez [EMAIL PROTECTED]
I am trying to install PGPLOT using
cpan install PGPLOT
But, it is not working for me :-(
The transcript of the session is posted below.
I know the problem is related to the cpgplot.h
library. I did a google search and found many
instances of the
I took a look at the gif driver code in the fortran
pgplot library and found this explanation:
C
C--- IFUNC = 2, Return physical min and max for plot device, and range
C of color indices ---
C (Maximum size is set by GIF format to 2**16
Adam Ginsburg writes:
* Edited the perldl script to change the number of
lines saved in history from 50 to 250
Is that the line @a= @a[($#a-50)..($#a)] if $#a50 ?
(line 239 of unedited perldl)
If that's it, I think it would make sense to set a variable
that you can edit in .perldlrc for
I was looking at the calendar and realized that it
has been more than a year since the PDL-2.4.3
release. There have been several portability
issues and bugs resolved (or at least detected!)
since then.
It seems like we could use a quick point release
of a PDL-2.4.4 to fix:
* xvals.t test
On Fri, 2007-11-02 at 15:05 +1300, Trevor Carey-Smith wrote:
There may be a more elegant way, but you could try:
$work($work-isbad;?) .= $original($work-isbad;?)
This uses the new PDL::NiceSlice syntax. You'll need to
do a 'use PDL::NiceSlice' before using the new syntax for
*each file*.
I am not a debian user but here are some thoughts:
There is not much to the error message but it does not appear
to come from the PDL code. The line the error points to is for
some X window calls (GLX stuff).
A quick google for the error message and Debian came up
with some X11 problems with
Arlindo da Silva wrote:
1) The FAQ link on the nav bar of the home page http://perldl.perl.org is broken
It looks to be fixed now from http://pdl.perl.org
Strange, I still get an Error 404 when going to http://pdl.perl.org/FAQ/
Now I get the same error. Maybe I was
FWIW, it works for cygwin under PDL-2.4.3:
$ perldl
perlDL shell v1.33
PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
'COPYING' in the PDL distribution. This is free software and you
are welcome to redistribute it under certain conditions, see
the same file for details.
Derek Lamb wrote:
Is that really 2.4.3, or
2.4.3-from-CVS-but-the-version-number-never-got-cvs-appended? Because
setops 'OR' should be quite broken in a straight 2.4.3.
I took a look at the code and it is the cvs that the test was run on.
Sorry about the confusion. -chm
Chris Marshall
I've been working on some interpolation
code using a perl/PDL to implement the
basic functionality before optimizing with
PP. There was a reference in PDL::PP
about using perl for threaded operations
but I never found the information (the
pointer was to PDL::Indexing). Some
questions:
* Is
This is a known bug in PDL-2.4.3 and fixed
by patch #1548824 on the sourceforge PDL
site. Go to http://pdl.sourceforge.net and
follow the link to patches on the lower part
of the left side toolbar.
If you have other problems with version
2.4.3 I recommend you check the patches
and bugs on
I am implementing some code that I would
like to thread (in perl/PDL).
(1) What is the signature of a function
having some threading args (usually the
piddles) and some non-threading args
(like parameters,..., often perl SVs
although I guess piddles could be used
as well)
(2) I thought it would
is more than a little hairy and baroque.
I have about two weeks I'm setting aside in the fall for PDL work. As
a point of interest, would folks rather see something like this fix,
or a smoothly installing graphics engine?
Cheers,
Craig
On May 11, 2008, at 7:18 PM, Chris Marshall wrote
Greg Ederer wrote:
Hi All:
I'm working on an aggregation algorithm. Basically, it takes a
rectangular window, moves it through the input pdl, and computes a
weighted avg of the pixels overlapped by the window. Note that the
window dimensions are not necessarily integers. Also, the window
As an alternative to range(), take a look at rotate():
perldl $a = sequence(4,4)
perldl p $a
[
[ 0 1 2 3]
[ 4 5 6 7]
[ 8 9 10 11]
[12 13 14 15]
]
perldl $b = $a-rotate(2)-mv(0,1)-rotate(2)-mv(1,0);
perldl p $b
[
[10 11 8 9]
[14 15 12 13]
[ 2 3 0
I would be interested to know why
use PDL;
$a = PDL::pdl([1,2,3],[2,4,3]);
doesn't work as well. This incantation does work for me
use PDL;
$a = PDL-new([1,2,3],[2,4,3]);
print \$a is $a\n;
--Chris
Hugh Sasse wrote:
With reference to
Apologies if I missed it, do we have a bug report
on this? With work for 2.4.4 underway, I would
like to address the known outstanding issues with
PDL-2.4.3 there. At the very least a full build
log (and tests if that is where things go awry) with
perl -V info would be helpful.
In the process
Well, from what you've described it
sounds like PDL-2.4.3 built just fine.
Try running 'make test' from the top
level PDL-2.4.3 build directory. Do a
bunch of tests run and and all passed
message at the end? If so, you built a
working PDL-2.4.3!
You should be able to run 'perl -Mblib
perldl' from
definitely did not catch that. :-)
-Chris
Gregory Vanuxem wrote:
Hello Chris,
Le jeudi 26 juin 2008 à 22:44 -0400, Chris Marshall via RT a écrit :
Queue: PDL
Ticket URL: http://rt.cpan.org/Ticket/Display.html?id=37000
I am unable to reproduce this problem with PDL-2.4.3 on cygwin
or PDL
My goal for bug fixes for 2.4.4 relate to portability
problems (alot of them coming from the cygwin and/or
win32 environments) and improving TriD portability
(with the ultimate goal of providing a baseline
display capability across all supported platforms).
I've been working with Bob Free, the
Sisyphus wrote:
- Original Message - From: Chris Marshall [EMAIL PROTECTED]
.
.
POGL is transitioning to using GLUT (actually
FreeGLUT) rather than GLX for the base window
functionality. This should allow the same code to
run on X/OpenGL systems *and* win32/OpenGL
systems
. This is something
very strange and never had it before.
Anyway, thanks for the advice and the help.
Hernán
2008/7/16 Chris Marshall [EMAIL PROTECTED]:
Hi Hernán,
I haven't seen if you have had any further luck with this.
There are two parts to getting the TriD (OpenGL based)
stuff
Could you please run 'perldl -V' and send the output.
I could not reproduce the problem as I had out of memory
errors at that point.
Maybe someone with a large memory 64bit OS and
PDL could take a look further to debug the internals.
As a work around, just loop over your large $a values
by
Doyou have the same error with $c=($a==$b-dummy) ?
Steve Cicala wrote:
Thanks for the DiskCache pointer.
The exact expression that gives me the error (even after invoking
$PDL::BIGPDL=1) is
$c=$a==$b-dummy
where
$b is Double D [500]
$a is Double D [48]
On Sun, Sep 14, 2008 at 3:41
Hugh Sasse wrote:
On Fri, 19 Sep 2008, Craig DeForest wrote:
PDL::Complex was never fully implemented, in the sense of overloading all the
basic operators. Hence many operations will fall through to the PDL
implementation that is under the hood. PDL::Complex places the
(real,imaginary)
I think you just need to set the bad flag, otherwise the bad value is just
another number. Here is an example from the perldl shell from the current cvs
PDL:
perldl:/cygdrive/c $a = long(random(10,5)*10)
perldl:/cygdrive/c p $a
[
[6 1 2 4 3 4 1 1 8 6]
[7 4 2 5 5 9 8 6 0 8]
[9 2 0 5 6 2 7
...and I'm looking for PDL users to test.
I'm working to refactor the existing TriD modules
to use OpenGL rather than PDL::Graphics::OpenGL
for improved support for the OpenGL APIs, better
functionality, more portability.
I need the output from config, build and test for
OpenGL-0.57 and
The way I expected to get this to work would be to set the badvalue flag for
the non-positive elements of your arrays and then the oddpctover() would just
work:
(1) the various pctover() routines do not seem to handle bad values so this
doesn't work
(2) lack of bad value support is not
team
Chris Marshall wrote:
As advertised, PDL-2.4.3_01, a developers pre-release of
PDL-2.4.4, has just been posted to CPAN. This release
serves several purposes:
(1) make the PDL-2.4.4 pre-release 1 available for wider testing
(2) verify the release push process
(3) check any issues
,
BADVAL support is needed. I hope this doesn't cause problems!
Regards,
Doug
[EMAIL PROTECTED]
Software Engineer III
UCAR - COSMIC, Tel. (303) 497-2611
On Tue, 21 Oct 2008, Chris Marshall wrote:
FYI, now that I have the correct permissions, I also get the e-mails
from the rt bug system
To All Eager PDL Developers,
Here is a quick analysis of the PDL-2.4.3_01 build failures
as reported by CPAN Testers. Basically, perl 5.6 works
but 5.8 and 5.10 fail. Darwin has issues with the autoload
test and NetBSD has broken uudecod options set.
*BUT*
inlinepdlpp is the Gorilla problem.
I have tried cygwin/XP with perl 5.8.8 and perl 5.8.10 and
both passed all tests successfully. Has anyone tried a vanilla
build of PDL with only the dependencies that have been on
the FAILing systems?
--Chris
Chris Marshall wrote:
To All Eager PDL Developers,
Here is a quick analysis
There is an Inline config option to set the directory
used. Maybe we could use that? I don't know if
that would be the same as a clean directory and config.
--Chris
Sisyphus wrote:
- Original Message - From: Sisyphus [EMAIL PROTECTED]
To: Chris Marshall [EMAIL PROTECTED]; perldl
Here are the results of a quick scan through the most common
readme and informational files in the current PDL-2.4.4-pre-1
(a.k.a. PDL-2.4.3_01):
Release_Notes: need to add 2.4.4 notes
Doc/README: is this current/still correct?
Example/Benchmark/README: does this example still run?
Sisyphus wrote:
- Original Message - From: Chris Marshall [EMAIL PROTECTED]
To: perldl list perldl@jach.hawaii.edu
Sent: Thursday, October 23, 2008 12:12 PM
Subject: [Perldl] please test PDL-cvs for round 02
All-
Fixes for the dumper.t and inlinepdlpp.t
problems with PDL
PDL-2.4.3_03 (a.k.a. PDL-2.4.4 pre-release 3) has
been uploaded and should be coming to a CPAN
mirror near you soon.
The goal of this release is to improve the test coverage
of the CPAN Testers in the hopes of debugging the
remaining platform test failures.
Changes:
* enabled WITH_BADVAL and
PDL-2.4.3_04 (a.k.a. PDL-2.4.4 pre-4)
has been uploaded to CPAN and should
be available at a mirror near you.
Please test and report any issues. No
additional code changes are planned before
the official PDL-2.4.4 release next week.
Documentation and release notes changes
will continue to be
.
Developers, get your final testing and
doc edits in now!
Thanks much,
Chris Marshall
for the PDL developers
___
Perldl mailing list
Perldl@jach.hawaii.edu
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
Alan W. Irwin wrote:
On 2008-12-03 17:09-0700 Doug Hunt wrote:
Hi Alan, Jerry, PLplot list.
I just started updating the perl/PDL examples for plplot and have run into
a question.
I updated x02.pl to clean it up and add the second plot that was missing
(I have not checked anything into
Doug Hunt wrote:
So, I would like to propose one of two remedies (attached).
The first (pdlcore.c.PL.diff) would be to get rid of
pdl_whichdatatype_double and just assume that scalars convert to
doubles, not floats. This would be a change to a long-standing rule,
but I think it would
Another thing that makes testing go faster:
Edit the perldl.conf file to disable all the
optional component that you don't need for
build testing. Some of the libraries take
a long time to configure and build---time
you don't need to spend every time you change
an option for the HDF stuff.
David Donovan wrote:
Maybe one day somebody will heal PGPLOT's bit-rot and this will become
simpler. :)
PGPLOT generates nice plots but it is missing
a couple of features that would make things
simpler:
(1) support for RGB bitmap images
(I think there is a patch floating around that
in the entire file and toss what I don't need than
to uncompress/read/compress, in this case, so I ended up not using
open/seek/close at all. TMTOWTDI
Thanks,
--Edward H.
-Original Message-
From: Chris Marshall [mailto:c...@alum.mit.edu]
Sent: Tuesday, March 10, 2009 7:42 PM
An FFT[W] overhaul has been an itch of mine for
a while. Preliminary review of the problem led
to several goals related to your discussions
below:
(1) Migrate from FFTW2 to FFTW3
The first step is to replace the FFTW2 library
calls with the appropriate ones from FFTW3.
Although the API
Craig DeForest wrote:
On Mar 27, 2009, at 12:11 PM, Hugh Sasse wrote:
Well, since I primarily interested in N dimensional FFTs I'm capable
of getting myself in enough knots dimensionally without having to
track which slices are not actually slices, but what would be, in
an Object
Could you please send the information requested in the
BUGS file of the PDL distribution for help with your
problem.
To get more diagnostics, you can run the tests by
hand from the PDL build directory:
perl -Mblib t/flexraw.t
This can give more specific messages that may help
to resolve the
This is a problem with gfortran file IO formatting
as reported in this thread:
http://www.mail-archive.com/pdl-port...@jach.hawaii.edu/msg00729.html
gfortran 4.2 and above are compatible with g77 formatting.
If upgrading gfortran does not work, you could use the option
-frecord-marker=4 to the
A snapshot of the latest PDL developers' tree
has been released as CPAN PDL-2.4.4_01.
It includes fixes for a number of reported bugs.
Enjoy,
Chris___
Perldl mailing list
Perldl@jach.hawaii.edu
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
This is another developer's release of the latest
git snapshot. Includes some added diagnostics
for proj4 and 16bit pic tests and better error
handling for the tests.
If you try it out, please consider reporting the result
to the CPAN testers. If you use the cpan shell to
do the install, then
Sisyphus wrote:
Looks like primitive.t failure is simply the result of srand not behaving as
expected. The burning question is, of course, Why are yours different?
I did a quick search on MSDN for rand/srand on vista and
found discussion of rand_s to generate pseudorandom integers
in the
Gabor Szabo wrote:
...
Certainly price is a big difference and the
fact that PDL is open source while Matlab is
proprietary so I am more interested in the
technical aspects.
I use PDL and Matlab at work. At home I can
only afford to run PDL.
I searched a bit and found this
Jan Hoogenraad wrote:
Victory.
Congratulations and happy Pldpp-ing!
Some suggestions below for the PDL testing...
Attached the first lapack call I have compiled on an Ubunto linux machine.
Dependencies:
- f2c (for the f2c.h header file)
- lapack (compiled package)
- clapack.h (from
If you sort the (z,r) data by z you can use the
histogram counts to calculate ranges of index values
corresponding to each bin. range() or other indexing
operation can select the sets to calculate your
desired stats.
--Chris
Hernán De Angelis wrote:
Dear PDL'ers,
I am stuck with an
Does this do what you want?
perldl $this=pdl(3,4,5,5,5,5,5,5,5,5)
perldl p $this
[3 4 5 5 5 5 5 5 5 5]
perldl $that = sequence(11)
perldl p $this
[3 4 5 5 5 5 5 5 5 5]
perldl p $that
[0 1 2 3 4 5 6 7 8 9 10]
perldl indadd($this-ones,$this,$that)
perldl p $that
[0 1 2 4 5 13 6 7 8 9 10]
Hyer,
, Chris.
On Jul 1, 2009, at 9:57 PM, Chris Marshall wrote:
Does this do what you want?
perldl $this=pdl(3,4,5,5,5,5,5,5,5,5)
perldl p $this
[3 4 5 5 5 5 5 5 5 5]
perldl $that = sequence(11)
perldl p $this
[3 4 5 5 5 5 5 5 5 5]
perldl p $that
[0 1 2 3 4 5 6 7 8 9 10]
perldl indadd
Attention PDL-ers!
The PDL-2.4.4_04 developers' release of the Perl Data
Language module has been uploaded and should be
available soon at a CPAN mirror near you. It includes
several fixes for test failures.
Enjoy!
Chris
Release notes for PDL 2.4.4_04 ---
General
I would appreciate your thoughts
(and maybe a show of hands) about
maintaining the current X11 component
of the PDL::Graphics::TriD modules.
Looking at the code, it appears that
most of the X11 and GLX stuff was put
in to support the creation of the
basic drawing window.
The new Perl OpenGL
Sisyphus wrote:
- Original Message - From: Chris Marshall c...@alum.mit.edu
To: perldl@jach.hawaii.edu
Sent: Saturday, July 11, 2009 6:00 AM
Subject: [Perldl] PDL-2.4.4_04 uploaded to CPAN
Attention PDL-ers!
The PDL-2.4.4_04 developers' release of the Perl Data
Language
The use of developer's releases of PDL is proving
as effective as I had hoped. Because of the
automated test reports, it has been possible to
fix bugs, modify the code, and make the latest
version available on CPAN without breaking the
availability of the PDL-2.4.4 official release.
To that end,
just downloaded the flux source
and I assume you would not being averse to the new functionality
if it supported your needs? This is exactly the type of use case
info I was hoping for.
Thanks!
Chris
Cheers,
Craig
On Jul 11, 2009, at 7:35 AM, Chris Marshall wrote:
I would appreciate
This is a re-release of PDL to fix a
Makefile typo in PDL-2.4.4_04.
Please try. --Chris
___
Perldl mailing list
Perldl@jach.hawaii.edu
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
Orion Poplawski wrote:
On 07/16/2009 09:25 AM, Judd Taylor wrote:
Orion,
Keep me informed... Also check that your environment variable PROJ_LIB
is set:
PROJ_LIB=/usr/share/proj
From what I see, it can't find something, and the PROJ_LIB variable is
where proj usually looks to find
John Comeau wrote:
Rob-
I didn't have either lapack or blas installed, and after I installed
them, I got a different error in one of the commands of 'make test' on
PDL::LinearAlgebra:
$ perl -Mblib t/1.t
perl: symbol lookup error: /usr/lib/atlas/liblapack.so.3gf: undefined
symbol:
Chris Marshall wrote:
...And should be available at a CPAN mirror near
you soon. This is another developers release in
the PDL-2.4.4 series based on the latest git.
A few more bug fixes are present and work continues
towards the TriD refactoring to use OpenGL rather
than PDL::Graphics
This is a snapshot of the latest git sources.
The main change is a fix for cygwin library
locations and include files that broke the TriD
compile for recent cygwin releases. This is
part of the continuing work to refactor the
3D graphics to use Perl OpenGL instead of
PDL::Graphics::OpenGL to
Ganesh Krishnan wrote:
If this is a duplicate please ignore. I wasn’t sure if my
first message got through--
I am having problems compiling PDL. I am installing to a non-standard
location and specified the PREFIX as ../bin/PDL and LIB as ../PDL. I
have perl 5.8.6 on a
P Kishor wrote:
On Fri, Aug 28, 2009 at 7:59 PM, P Kishorpunk.k...@gmail.com wrote:
In my quest to learn PDL, I am trying to create simple 2D arrays of z
values and plotting them, kinda like possible with this little R
program at
P Kishor wrote:
a damn! From perldl.conf
# Try to build Graphics/TriD
#
# There are problems with the build on OS-X, so we turn it off by default
# for such systems
#
WITH_3D = $^O eq darwin || $^O eq 'MSWin32' ? 0 : undef,
I guess I am sol using PDL for graphics because I am
P Kishor wrote:
Starting a new thread. Background -- wanted to create surface plots a
la R (http://addictedtor.free.fr/graphiques/RGraphGallery.php?graph=27)
but with PDL.
Was unable to install PDL::Graphics::TriD and PDL::Graphics::PLplot
P::G::T kept on choking up on various issues, and
is released this Fall.
Enjoy!
Chris Marshall
Bob Free
___
Perldl mailing list
Perldl@jach.hawaii.edu
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
On 09/08/2009, Orion P wrote:
On 09/06/2009 02:29 PM, Chris Marshall wrote:
OpenGL-0.58 has been released to PAUSE and
should be
It appears to be impossible to build an RPM
package of the perl OpenGL package because
DISPLAY is not set:
Executing(%build): /bin/sh -e /tmp/rpm/rpm
Hi Stefan,
The problem with the glutBitmapHeight() error was that
you are not using FreeGLUT. However, I would like POGL
to build and run (as much as possible) without requiring
FreeGLUT specifically. I've added some ifdefs to prevent
building the FreeGLUT only functions to the current git at:
On 11-Sep-2009 Stefan wrote:
Thanks for the quick answer.
You're welcome.
The problem with the glutBitmapHeight()
error was that you are not using
FreeGLUT.
So it is recommended to install FreeGLUT
first?
Yes
I took the following comment in the INSTALL file
On Windows,
Stefan Evert wrote:
It is my understanding that GLUT is layered over GLX as well.
I suppose it is on Linux, but on the Mac the GLUT.framework is separate
and can open an OpenGL window without going through the X server (which
most Mac users prefer!).
Interesting.
But now for the
Christian Soeller wrote:
I have assembled a bit of code that tries to determine the location of
'typemap' in a more robust way, see below. Only tested on OS X 10.5.8
so far. Would this be a viable replacement for the current logic in
PP.pm (or does anybody know of a better way)? If so it
This is a CPAN Developers release of the latest git
for the Perl OpenGL module (a.k.a. POGL). POGL is
the target of refactoring of the PDL::Graphics::TriD
module to replace PDL::Graphics::OpenGL with POGL
for portability and robustness.
Release highlights:
* This is a developers release, so
This is to announce the availability, via the PDL git
repository, of a first cut version PDL with TriD using
the perl OpenGL (a.k.a. POGL) module version 0.58_003
to replace PDL::Graphics::OpenGL (the original, internal,
PP version).
The build configuration is hardwired with USE_POGL set
in
Hi Brock,
As Derek Lamb pointed out, the problem here is in the
build for the 3D graphics, PDL::Graphics::TriD. I
suggest you edit the perldl.conf file and set WITH_3D
to 0, explicitly to prevent building the TriD code.
For my first PDL build on a new platform, I usually
disable any problem
that
it may not play nice with that. Running just plain 'make' in a regular
shell worked fine.
The PDL build process is not parallel make safe, at least not
without some tweaking. I've never gotten make -j N to build.
If you really need 3D graphics, see the note from Chris Marshall
Doug Hunt wrote:
Hi Leslie: Both PDL and PDL::NetCDF require some manual tuning to
install, so they don't install automatically from the cpan shell.
The approach I always take is to download the latest PDL from CPAN:
http://search.cpan.org/CPAN/authors/id/C/CH/CHM/PDL-2.4.4.tar.gz
The
Other than the recommendation to start with PDL-2.4.4_08
rather than 2.4.4, I don't have personal experience with
PDL::NetCDF since the NetCDF library is not on my system.
Doug Hunt is listed as the author for PDL::NetCDF and
it looks like he has already made some suggestions on
the perldl list.
Hi David,
Thanks for taking on the documentation update.
Here are some quick thoughts:
1) How about Installing PDL Manually as the title? The other
seems like it might discourage folks from working with PDL.
2) Add why one would want or need to do a manual build/install to overview:
I'm happy to announce a CPAN developers release of
PDL-2.4.4_09 and OpenGL-0.58_004 supporting the TriD
refactoring work. Both distributions should be at
a CPAN mirror near you soon. Check for downloads at
http://search.cpan.org/~chm/
You'll need to install the OpenGL-0.58_004 or greater
Hi David,
A little slim on the debugging info :-) (see BUGS in the
PDL source for info on what is useful for problem reports)
but you might want to check that you don't have more than
one PDL installation in your path.
I mention this because the default perldl.conf in the git
has a number of the
This changes the external build defaults back
to undef for all the external modules except for
USE_POGL which was left set on. People got some
surprising results when modules that were
expected to be built, weren't built.
Enjoy,
Chris
___
Perldl
1 - 100 of 1119 matches
Mail list logo
