I'm able to reproduce the problem on my system so I would classify this as
a bug.
Opened sf.net bug #396 "online docs for modules only work first time in PDL
shells"
Thanks for reporting the problem.
--Chris
On Thu, Sep 3, 2015 at 1:00 PM, Ingo Schmid wrote:
> Hi Chris,
> yes, I know about th
Hi Chris,
yes, I know about the online docs. I just found this extremely weird. It
appears that only the first call of help in a given shell
works. What info do you need?
My specs: perl 5.22.0, PDL 2.013, pdl2 shell. x86_64, gcc 4.9.3, kernel
4.1.6.
Ingo
On 09/03/2015 06:53 PM, Chris Marshall wro
Hi Ingo-
If you're having glitches with your local docs, you could use the docs from
metacpan.org or search.cpan.org.
If this is a bug report, we'll need more details.
--Chris
On Thu, Sep 3, 2015 at 6:08 AM, Ingo Schmid wrote:
> Hi,
>
> I've been having trouble accessing docs, recently.
>
> he
Hi Karl-
Not all of the missing dependencies are hard ones in the sense
we have tried to make a build of the PDL distribution flexible to
the actual software and modules the user has or desires.
However, for a bundled SciPDL build, I recommend having
everything at the most compatible with all dep
Good points. I definitely think having a warning in each of the PDLA
duplicate modules is going to be important to keep things straight for
users and developers.
I think that staged migration of features from PDLA -> PDL is the way to
go. Once something is really stable in PDLA, we can propagate
My view:
I agree with PDLA and I support basically all goals that where mentioned.
On the other hand I see also couple of possible gotchas.
First is (potential) users confusion. With ongoing work on breaking PDL(A)
into smaller pieces there will be sooner or later more PDLA::* modules than
P
Also-
You seem to be missing some dependencies or they
are not at the current version required. I just noticed
the output in your test log below. Did you use cpanm
to install PDL-2.013 first? That would get your
dependencies up to the latest if needed.
--Chris
On 9/3/2015 06:31, Chris Marsha
The t/badvalue_scalar_cmp.t are the test output which is correct
since the test is supposed to throw those errors to the user in
those cases.
t/inline_with.t needs to have a more recent Inline module to
enable that support.
t/op-eq-warn-for-non-numeric.t is ok with some expecteduser
error output
My 2c:
I’d imagine that with PDLA development proceeding, we could still periodically
have jumbo bundles for those who like and need kitchen sink installs with
complex dependences?
While PDLA is learning to walk and talk and not shit it’s pants, then we will
still have a nice PDL-2.014 version
OK -I got a disturbing number of test fails compared to previous builds for
SciPDL
(Apologies for the rich text but I highlight the new ones in red)
I can probably sort out the model prereq updating and Slatec/F77 issues - but I
was wondering about the badvalue*, op*.t and physical.t errors?
Hi,
I've been having trouble accessing docs, recently.
help PDL::IO::Storable
Runtime error: Documentation error: couldn't find absolute path to
IO/Storable.pm
The funny thing is, I could access the document a few seconds earlier
with the same command, strange.
Ingo
PS:
Here's the pasted pdl2
Looks like a good place to use the $T macro instead. That guy DeForest looks
like kind of a hack…
> On Sep 3, 2015, at 10:19 AM, Karl Glazebrook wrote:
>
> Hi Chris
>
>
> It’s this cheesy code in ufunc.pd
>
> pp_def(
> 'average',
> HandleBad => 1,
> Pars => 'a(n); int+ [o
Hi,
I've just released a new version of PDL-Dims, mainly fixing a few
things. Nowwhile actually using the module,I find the way thingswork a
little awkwardbut I don't knowa solution.
Let me explain:
I have a function like that, nothing fancy.
sub { $a*cos($t*$f)*exp(-$t*$r2) }
At compile time,
Hi Chris
It’s this cheesy code in ufunc.pd
pp_def(
'average',
HandleBad => 1,
Pars => 'a(n); int+ [o]b();',
Code =>
'$GENERIC(b) tmp = 0;
if($SIZE(n)) {
loop(n) %{ tmp += $a(); %} ;
$b() = tmp / ($GENERIC(b)) $SIZE(n);
14 matches
Mail list logo
