From the other comments above, it sounds like you'll need to track down the problem yourself. By the sounds of it you have full control of the box, and can mess with the installed modules safely; if not you'll want to install local copies of the modules before you do so.
The error message is coming from Math::Pari::can:
sub can { my ($obj, $meth) = (@_); my $f = $obj->SUPER::can($meth); return $f if defined $f; # There is no "usual" way to get the function; try loadPari() $f = eval { loadPari($meth) }; # Math/Pari.pm line 1136 return $f if defined $f; return; }
Since that isn't dying itself, clearly some caller is dying with this eval's $@ upon getting a failure returned.
I'd suggest the first thing you need to do is find out the full context in which that's happening, and that's easiest done by putting diagnostics in where you know the problem is occurring:
$f = eval { loadPari($meth) }; return $f if defined $f; + if ($meth eq 'as_number') { + require Carp; + Carp::cluck("failed to find as_number"); + } return; }
For this sort of debugging, I tend to keep the vi session open for any module I change, so that I can easily restore the integrity of the modules by (u)ndoing all edits and re-saving. An alternative approach is to copy each module to a .orig file before editing.
Once you have the full stack trace, you can start the debugging proper.
Hope this helps,
Hugo
In reply to Re: Bug in Math::Pari ?
by hv
in thread Bug in Math::Pari ?
by SineSwiper
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |