Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Inline::CPP Not Loading Properly (Related To Inline::Filters Issue) #1

Closed
shlomif opened this Issue · 26 comments

3 participants

@shlomif

Hi all,

thanks for RPerl and happy new year.

After a successful "perl Makefile.PL" and "make", then "make test" generates many errors on Mageia Linux x86-64 Cauldron (what will be Mageia Linux 4). For the output of make test, see:

I'm using my Acer Laptop whose SPECs are:

Intel Pentium(R) Dual-Core CPU T4300 @ 2.10GHz. (x86-64).
ATI Mobility Radeon™ HD 4570 (r700)
15.6״ 3D HD LCD Screen.
3 GB Memory
320 GB Hard Disk Drive.
“DVD Super Multi DL drive”
Acer Nplify™ 802.11b/g/n.

I installed Inline::CPP and the development version of Inline::Filters from CPAN. Please let me know if there's anything else you need.

Best regards,

-- Shlomi Fish

P.S: first post? ;-)

@rurban
Collaborator

You need to use the fixed Inline::Filters version from lib, as described at docs/install_notes.txt, sorry. It's still a mess.
Inline still uses the global Inline::Filters version,. and not the fixed one in blib and lib.

@shlomif

@rurban : thanks for returning to me so quickly. I've uninstalled Inline::Filters from CPAN and did this:

shlomif@lap:~/Download/unpack/perl/cpan/RPerl/rperl$ perl -MInline::Filters -MDa
ta::Dumper -e 'print Dumper(\%INC)' | grep Filters
          'Inline/Filters.pm' => '/home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.18.1/Inline/Filters.pm'
shlomif@lap:~/Download/unpack/perl/cpan/RPerl/rperl$ 
shlomif@lap:~/Download/unpack/perl/cpan/RPerl/rperl$ ls -l /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.18.1/Inline/Filters.pm
lrwxrwxrwx 1 shlomif shlomif 73 Jan  6 20:42 /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.18.1/Inline/Filters.pm -> /home/shlomif/Download/unpack/perl/cpan/RPerl/rperl/lib/Inline/Filters.pm
shlomif@lap:~/Download/unpack/perl/cpan/RPerl/rperl$ 

And next I did «rm -Rf _Inline» ran perl Makefile.PL and make again and then ran «prove -l t/*.t» only to still get failures. See:

http://www.shlomifish.org/Files/files/text/rperl-prove-l.txt

Please let me know if these are fixable.

Regards,

@shlomif

@rurban
Collaborator

Yes, this is what I also get now. Still working on Inline::Filters.
Work is ongoing in https://github.com/perl11/Inline-Filters

CPP is not being picked up. cpan RURBAN/Inline-Filters-0.12_02.tar.gz is better

You can try to run the better tests in bin/development, like perl -Mblib bin/development/xx.pl
perl bin/test_suite.pl should work now.

@wbraswell
Owner

@shlomif
Thanks for your interest in RPerl! We're still working out all the installation bugs, as you have now discovered...
Any luck getting the tests to pass?

@shlomif

@wbraswell : hi. I don't have any luck getting the tests to pass and don't know what they involve. On my laptop, I am getting:

Test Summary Report
-------------------
t/04_type_scalar.t     (Wstat: 1536 Tests: 273 Failed: 6)
  Failed tests:  23, 34, 116, 127, 206, 217
  Non-zero exit status: 6
t/08_precompiled_sort.t (Wstat: 1280 Tests: 182 Failed: 5)
  Failed tests:  92-94, 99-100
  Non-zero exit status: 5
Files=8, Tests=945, 113 wallclock secs ( 0.35 usr  0.04 sys + 104.77 cusr  6.76 csys = 111.92 CPU)
Result: FAIL

And on my desktop machine (also x86-64 Mageia Linux Cauldron), I am getting:

Test Summary Report
-------------------
t/03_inline_cpp.t      (Wstat: 3328 Tests: 13 Failed: 13)
  Failed tests:  1-13
  Non-zero exit status: 13
t/04_type_scalar.t     (Wstat: 512 Tests: 7 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/05_type_array.t      (Wstat: 512 Tests: 5 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/06_type_hash.t       (Wstat: 512 Tests: 5 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/08_precompiled_sort.t (Wstat: 512 Tests: 6 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Files=8, Tests=62,  6 wallclock secs ( 0.04 usr  0.01 sys +  5.05 cusr  0.61 csys =  5.71 CPU)
Result: FAIL

The difference is strange because the two machine have the same configuration.

This is after following the procedure of perl Makefile.PL ; make ; rm -fR _Inline ; prove -l t/*.t ; . I don't know what getting the tests to pass will entail.

Regards,

-- @shlomif

@wbraswell
Owner

Schlomi,
Please try running individual *.t files directly using perl instead of passing them through prove, that way we can see what is actually causing your errors.
Thanks,
~ Will

@shlomif

@wbraswell : hi. I did what you ask me to on my desktop machine and got:

http://www.shlomifish.org/Files/files/text/shlomif-rperl-test-scripts-running-inidividually.txt

The script I used is:

#!/bin/bash
perl Makefile.PL
make
rm -fr _Inline
for f in t/*.t ; do
    echo "====[[ Running test script $f ]]===="
    perl -Ilib "$f"
done

And I ran it like:

 bash -x ~/test-rperl.bash 2>&1 | tee ~/shlomif-rperl-test-scripts-running-inidividually.txt

Regards,

-- Shlomi Fish

P.S: it's "Shlomi" - not "Schlomi" - see http://www.shlomifish.org/meta/FAQ/#your_name .

@wbraswell
Owner

@shlomif

Sorry about misspelling your name. The problem you're running into is the same issue that Reini, mst, and I are trying to solve. It is a bug in Inline that causes it to not find Inline::CPP correctly, probably due to the fact that there are other issues with Inline that we have temporarily patched.

@rurban

Can you please tell Shlomi how to temporarily fix this issue?

@shlomif

@wbraswell : OK, thanks for the heads-up, I'll wait for @rurban 's answer.

@wbraswell
Owner

@shlomif
Can you please try again with the latest code? It may have been fixed by some of the recent changes... Thanks!

@shlomif

@wbraswell : I tried and it still fails, though this time the failure may be different in nature - see http://www.shlomifish.org/Files/files/text/shlomif-rperl-tests-output--at-commit-c67294a29664cc78be5be32a0898a53ba2feff5c.txt

@wbraswell
Owner

@shlomif
I think this is still the same (or very similar) error, where Inline can't find Inline::CPP because of the installation weirdness...

@rurban can you please advise?

BEGIN EVAL ERROR
Error. You have specified 'CPP' as an Inline programming language.
I currently only know about the following languages:
C, PDLPP, Pdlpp, pdlpp
If you have installed a support module for this language, try deleting the
config-x86_64-linux-thread-multi-5.018001 file from the following Inline DIRECTORY, and run again:
/home/shlomif/Download/unpack/perl/rperl/rperl/_Inline

@shlomif

@wbraswell : thanks for the update. I'll wait for more input from @rurban .

@wbraswell wbraswell was assigned
@rurban rurban was assigned
@wbraswell wbraswell was assigned
@rurban
Collaborator

Will reverted some of my changes and if should work now

@wbraswell
Owner

Reini, what changes of yours did I revert that makes you think this will work now?

@rurban
Collaborator

those two files:

lib/rperltypes_mode.h
lib/rperltypes_mode.h.orig
@rurban rurban closed this
@wbraswell wbraswell reopened this
@wbraswell
Owner

@rurban
Reini you are mistaken, those two files you have listed are automatically changed every time RPerl switches modes. However, in the same commit as those files changing I did "Revert Reini's Change To test_suite.pl", you will see that in test_suite.pl I had to change your "$^X -Mblib" back to my old "perl -Ilib" because it was breaking on my machine.

c67294a

This commit and my reverting of your $^X code is completely unrelated to @shlomif Shlomi's issues and the base problem with Inline::CPP not loading properly. This is a huge outstanding bug and I have hereby re-opened it.

@rurban
Collaborator

Yes, you are right. My bad

@shlomif

@wbraswell : thanks for reopening the issue and correcting @rurban. One thing that frustrates me about the GitHub issue tracker (but certainly not the only thing) is that there isn't an easy way for the reporter to reopen the bug like he can in Bugzilla and maybe also rt.cpan.org, even if he investigates and reports that the bug was not fixed yet. @rurban: thanks for acknowledging that the problem was not fixed - I'd prefer to be given a chance to confirm that it has been fixed next time.

@wbraswell
Owner

@shlomif
Hi Shlomi,
I think we may have finally fixed this bug, please carefully follow the latest RPerl install notes and let me know if it works for you:
https://github.com/wbraswell/rperl/blob/master/docs/install_notes.txt
Thanks!
~ Will

@shlomif

@wbraswell : hi, thanks for the fix and the update. After I followed the instructions and ran "make test" I'm now getting "All tests successful". Yay! I didn't go through all the manual in the install_notes.txt of making sure everything passes manually, because it seems like tedious work. Is there a good reason why it has to be done manually?

That put aside, the test suite emits quite a few warnings like:

Use of uninitialized value $Inline::CPP::ntype in concatenation (.) or string at (eval 921) line 1.

Is this something to worry about?

Regards,

-- Shlomi Fish

@wbraswell
Owner

@shlomif
Thank you sir, I am glad all tests are successful for you!
The copious warnings are buried inside Inline and we have not found them all yet, so you may safely ignore all the warnings for the time being.
If you were able to get full success without following the install notes, then that is fine with me!
Thanks,
~ Will

@shlomif

@wbraswell : hi, sorry for not being clear, but I did go through the install_notes.txt , just skipped some of the manually-verified-testing that was being prescribed there. Thank you again for fixing this problem.

@wbraswell
Owner

@shlomif
Yes thank you sir, it is okay for you to skip the manual tests as long as make test passes all tests.
Fixing this bug was a team effort including many people such as:
@rurban
@ANSI-C
@dk
@bulk88
@shadowcat-mst
Neil Watkiss
...
AND YOU MISTER FISH! :-)

@shlomif

@wbraswell : thanks for the confirmation. I was now able to run a regular "perl Makefile.PL ; make ; make test" scheme here on Mageia Linux x86-64 version 5, and it reported that all tests were successful. (There was a small problem with a dangling symlink to Inline::Filters being present under my user's custom $ENV{PERL5LIB}, which required some investigation, but I was able to fix it).

Thanks to you and everybody else who worked on fixing this bug, and I'm going to close it now.

Regards,

-- Shlomi Fish.

@shlomif shlomif closed this
@rurban
Collaborator

I'm working on the $Inline::CPP::ntype warning also. This is a Inline::CPP issue.

In the meantime you can try
cpan RURBAN/Inline-0.54_02.tar.gz which fixes a couple more Inline bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.