Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Exploring Inline::C (Generating primes)

by BrowserUk (Pope)
on Oct 25, 2011 at 10:45 UTC ( #933595=note: print w/ replies, xml ) Need Help??


in reply to Exploring Inline::C (Generating primes)

It took a little time getting used to debugging under Inline::C.... However, you do have to take note that line numbers in error messages won't correspond with those in your Perl source code. Instead, they refer to a C source file that gets placed in the build directory, with an .xs suffix. Again, the error log and screen messages point to that same file.

This may or may not suit your preferences, but I always start my Inline::C files with:

#! perl -slw use strict; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => 'scriptname', CLEAN_AFTER_BUILD => + 0; // XS code here ... END_C # perl code here ...

This has several effects I find extremely useful.

  • BUILD_NOISY => 1 ensures that warnings and errors from the .XS/.c compile phase are also output to the terminal.

    Unfortunately it also produces a lot of clutter -- starting xxx/Finishing xxx -- that I'm not interested in, but getting the direct feedback of the C compiler output is more than compensation.

  • NAME => '....' prevents the default of using the first 4 hex characters of the MD5 as a part of the build subdirectory name.

    This default is annoying because it means that if you've loaded the previous intermediate .c and .xs files into your editor, when you make a change and re-build, they become obsolete and you have to go off hunting to find out where their replacements are located.

    By explicitly naming them, when you've done a re-build, the same files get over written and you only need refresh to view the effects of the changes, My editor keeps track of changes to open files and can either notify you or automatically refresh them when you switch to the appropriate tab.

    This helps prevent one source of the "I edited the (wrong) file and nothing changed" gotcha.

  • CLEAN_AFTER_BUILD => 0 prevents the I::C build process from throwing away the intermediate build files.

    Which is almost essential when debugging.

But the main advantage of using this sequence of exactly 4 lines, is it means that the line numbers produced by the C compiler in its error messages logged to the screen, match exactly with those within the original I::C perl source file. Which means that most of the time there is no need to load the .c/.XS files in order to track down where the errors are, and so avoids another source of the "I edited the (wrong) file and nothing changed" gotcha.

And that is priceless.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.


Comment on Re: Exploring Inline::C (Generating primes)
Select or Download Code
Re^2: Exploring Inline::C (Generating primes)
by MidLifeXis (Prior) on Oct 25, 2011 at 12:45 UTC

    It has been a while since I have coded anything extensive (for some definition of extensive) in C, but I seemed to remember being able to tweak the line number and file name reported by the compiler by using #line... directives. A little searching indicates that my memory was correct.

    Not having used Inline::C to this point, this question is being asked from an ignorant position: is Inline::C able to use the #line directive?

    --MidLifeXis

      is Inline::C able to use the #line directive?

      Theoretically yes. But ...

      The XS pre-compiler already uses (something like) this to try and make error messages produce by the C compiler relate to line numbers in the .XS file.

      Inline::C extracts the source code from the .pl file, places it into an .XS file with some requisite pre- and post-amble, and then pre-compiles that to produce the the .c file. That then gets compiled to build a .dll/.so binary that is then dynamically linked back to the perl binary at runtime.

      I don't think anyone has tried to apply two levels of line control simultaneously. I'm not sure we humans would understand the results :)


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        I think the best way to enable Inline::C using #line directives would be to implement an xsubpp (== ExtUtils::ParseXS) option to NOT generate #line directives. That shouldn't be hard.

        ...

        Oops! Turns out that's already done! Check out the linenumbers option. I haven't tested it, though.

        This being said, I believe Inline::C is a deployment nightmare and should be avoided outside experiments accordingly.

        Once you learned the C and perlapi stuff to write Inline::C, XS is child's play.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://933595]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (14)
As of 2014-11-21 17:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (114 votes), past polls