#168 cannot install PDL without force

closed
core (120)
5
2008-06-25
2007-06-27
No

Hello,

I cannot install PDL without force. Have the
output attached.

Greetings
Holger Seelig

holger.seelig@yahoo.de

Discussion

  • Holger Seelig

    Holger Seelig - 2007-06-27

    stdout & stderr

     
  • Sisyphus

    Sisyphus - 2007-06-27

    Logged In: YES
    user_id=1195342
    Originator: NO

    Second attempt at posting (apologies if there's any duplication):
    I think the problem is with the placement of the line 'print "1..4\n";' (in t/xvals.t).
    I think it needs to be closer to the top of the file - say, immediately below 'use PDL::LiteF;'.

    Holger, I don't know how to apply that fix in the CPAN.pm environment (as I don't use CPAN.pm) - but if you could run 'make test', with that change to t/xvals.t in place, and confirm that it works, then we can at least amend t/xvals.t in the current CVS version, in preparation for the next CPAN relase of PDL.
    Derek Lamb reported the same problem on the PDL-porters list a while back, but never followed up. Derek?

    The problem appears to arise only on certain operating systems and/or certain versions of perl/ExtUtils::MakeMaker.

    (Here goes again - this time I've kept a text file copy so I won't have to re-type if things go awry.)

    Cheers,
    Rob

     
  • Derek Lamb

    Derek Lamb - 2007-06-27

    Logged In: YES
    user_id=1357170
    Originator: NO

    I tried Rob's idea last month (perldl list, 18-May-2007), but was not successful in getting xvals.t to pass. 'make install' was successful, as far as I can tell. Those machines that failed the test are 64-bit, if that makes any difference. I wondered if my version of Test or Test::Harness or similar is too new, but have not had the time to check that.

     
  • Holger Seelig

    Holger Seelig - 2007-06-28

    Logged In: YES
    user_id=1635510
    Originator: YES

    Hello Rob,

    i will follow your suggestion as soon as posible,
    will report you then.

    Cheers.
    Ho

     
  • Holger Seelig

    Holger Seelig - 2007-07-11

    Logged In: YES
    user_id=1635510
    Originator: YES

    I commented out the second line (in t/xvals.t). Then it works.

    line 2:#kill INT,$$ if $ENV{UNDER_DEBUGGER}; # Useful for debugging.

    Cheers Ho

     
  • Diab Jerius

    Diab Jerius - 2007-07-11
    • labels: --> core
    • assigned_to: nobody --> djerius
     
  • Diab Jerius

    Diab Jerius - 2007-07-11

    Logged In: YES
    user_id=260478
    Originator: NO

    I've just committed a fix which uses Perl's Test module to provide the testing framework. I've verified it works on Perl versions 5.8.8, 5.8.5, and 5.8.4.

     
  • Sisyphus

    Sisyphus - 2007-07-12

    Logged In: YES
    user_id=1195342
    Originator: NO

    That's strange, Ho. By my rough figuring there's another 30 or so test files that have the same line of code in them - yet those other tests don't suffer the same fate.
    I wonder what it is that sets $ENV{UNDER_DEBUGGER} for xvals.t, but not the other test files.

    Cheers,
    Rob

     
  • Derek Lamb

    Derek Lamb - 2007-07-12

    Logged In: YES
    user_id=1357170
    Originator: NO

    I find that the new t/xvals.t (Diab's patch) does not fail on the same machine that had previously failed. I'll let Holger close his own bug report if the test also succeeds for him. Perhaps more of the tests should use the standard Perl apparatus, it would probably increase the number of successful builds and put more of the testing burden on Perl rather than PDL.

    Derek

     
  • anicka

    anicka - 2008-02-28

    Logged In: YES
    user_id=1360712
    Originator: NO

    I am also getting failure of xvals.t on 64bit machines, it looks like this:

    t/xvals.....................ok 1/0Don't know which tests failed: got 1 ok, expected 0
    Failed Test Stat Wstat Total Fail List of Failed
    -------------------------------------------------------------------------------
    t/xvals.t 0 ?? ??

    What is strange, the difference makes commenting of random lines at the beginning of the testfile, ie this one:
    $dummy2->dump();

    This is my minimal testcase to fail in a described way (it does not test anything in fact):

    use PDL::LiteF;
    print "1..1\n";

    sub ok {
    my $no = shift ;
    my $result = shift ;
    print "not " unless $result ;
    print "ok $no\n" ;
    }

    $a0 = zeroes(3,2);
    $a1 = $a0->slice('(1)');
    $dummy = PDL::Core::new_or_inplace($a0);
    print $dummy;
    $dummy2 = $dummy->xchg(0,0);
    print $dummy2;
    $dummy2->dump();
    $dummy->dump();
    PDL::Primitive::axisvalues($dummy2);
    $dummy2->dump();
    $dummy->dump();

    ok(1,1 == 1);

    Commenting of nearly any of the lines in the longest block make this mysteriously failing test pass again.

     
  • Derek Lamb

    Derek Lamb - 2008-06-10
    • status: open --> pending
     
  • Derek Lamb

    Derek Lamb - 2008-06-10

    Logged In: YES
    user_id=1357170
    Originator: NO

    Marked as pending awaiting confirmation that Diab's patched version of xvals.t available at http://pdl.cvs.sourceforge.net/\*checkout*/pdl/PDL/t/xvals.t?revision=1.2 solves Holger's & anicka's problems.

     
  • SourceForge Robot

    • status: pending --> closed
     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks