Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Perl Books Media Programming Book Reviews

Extending and Embedding Perl 124

ggoebel writes "Extending and Embedding Perl is, as it boldly states on the cover, 'The definitive guide to XS, embedding, and the Perl internals.' This book is well organized and information dense. One could spend days sifting through the available perlapi, perlcall, perlembed, perlguts perlxs, perlxstut, and h2xs documentation. After which you'll probably understand very well references to nethack's 'You are in a maze of twisty little passages all alike.' Or you could get yourself a copy of this book and find your way out of the maze." Read on for the rest of ggoebel's review.
Extending and Embedding Perl
author Tim Jenness and Simon Cozens
pages 384
publisher Manning (August 2002)
rating 9 of 10
reviewer ggoebel
ISBN 1930110820
summary The definitive guide to XS, embedding, and the Perl internals

Most of the available documentation on extending and embedding perl is written from the prospective of the core perl developers for core perl developers. This book is written for advanced Perl programmers who for whatever reason need or wish to peer into that netherworld between Perl, C, and the glue that interfaces Perl with other languages. It is a deliberate thorough guide led by authors that are both extremely knowledgeable and also capable of communicating that knowledge.

While it would greatly reduce the learning curve, no prior knowledge of C is required to read this book. This is a surprising claim and while it won't be easy, this reader is proof that someone with little true knowledge of C can in fact read and for the most part comprehend what the authors wish to convey.

There are clearly areas for improvement. Things like NULL being used throughout chapter 3, only to finally be defined later in a footnote in chapter 4. And other cases of terms being used before they are explained. Things that leave the reader juggling unnecessarily until the information is provided that lets understanding fall into place. But for the most part, if you are a competent juggler and are patient your questions will eventually be answered. You won't walk away a C programmer, but you will learn enough to solve the problems which led you to consider reading this book in the first place.

One thing I liked very much about the layout of the book is how it switches back between presenting sections on C programming and Perl. The authors revisit C each time it is necessary to understand the next Perl internals topic. Those that are learning C or need the review receive the relevant information just before it is required.

Over the course of the book, you'll learn about interfacing from Perl to C and C back to Perl. For those that must plug references to Tolkien in things Perl... you can go back and rephrase that into an appropriate reference to Bilbo's book "There and Back Again". You'll also learn the perl api, data structures for core variable types, and how to work with scalars, arrays, hashes, strings, regular expressions, file handles, typeglobs, typemaps, objects, callbacks and PDL with C and C++. And there is even mention of working with Fortran, Java, and more esoteric alternatives.

The book finishes with an in depth look at Perl internals: the parser, tokenizer, op code trees, execution, and compiler. And closes with a discussion of the Perl development process: How it may be monitored and participated in.

What's missing? Detailed coverage of the I/O subsystem and the regular expression engine. I.e., topics which might themselves make for a good book. There was also light coverage on things like scratchpads. There were times while reading when I didn't know whether the issue being discussed was fully covered or curtailed. But you will certainly find better coverage of the issues in this book than elsewhere. This is an impressive book. I hope it will greatly influence the way Perl6 internals are documented.


You can purchase Extending and Embedding Perl from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Extending and Embedding Perl

Comments Filter:
  • After which you'll probably understand very well references to nethack's 'You are in a maze of twisty little passages all alike.'

    Funny, I remember that exact phrase from Zork.
  • by Photon01 ( 662761 ) on Tuesday April 08, 2003 @12:08PM (#5686477)
    misread that title at first glance, was dreading to see what microsoft had done to perl :)
  • This is a dead end (Score:4, Informative)

    by Ars-Fartsica ( 166957 ) on Tuesday April 08, 2003 @12:24PM (#5686566)
    One of the key reasons the Perl 6 project is taking such radical steps in remaking the language is precisely because extending and embedding Perl 5 is HELL.

    Investing in this book and this knowledge at this point is practically a dead-end, as most of the annoying kludges will end with Perl 5.

    Only invest in this book and this knowledge if there is a project you are working on that requires embedding or exteninding perl now. Otherwise wait for the sane cleaned-up world of Perl 6.

    • Otherwise wait for the sane cleaned-up world of Perl 6.
      Coming when, exactly? This book could be useful for years.
    • Perl 6 is not a big switch, such that when it is thrown/released we will be doing all Perl development with it and dumping 5. Perl 5 development is going to continue for a long time, making this book far from a dead-end.
    • How is this going to happen? The core perl developers are broke and nobody is funding them!

      Plus, Perl 6 is a totally new language. If I want to learn a new language, I'll bite the bullet and learn Python.
      • by Anonymous Coward
        The core perl developers are broke and nobody is funding them!

        Nevermind Perl6, its Parrot VM team is directionless and hasn't produced anything useful in two years. Parrot still has no exceptions, no thread support, no external module loading and no object support. But there's a real-life metric it excels at: MOPS. Parrot can decrement an integer in a loop faster than any other interpretor. They should be proud.

        Here's something to put it into perspective: Mono and Parrot development started at the same t
      • Plus, Perl 6 is a totally new language. If I want to learn a new language, I'll bite the bullet and learn Python.
        Perl 6 will be backward-compatible with perl 5. The interpreter will automatically recognize whether your module was written in Perl 5 or Perl 6. You'll be able to take advantage of the improved implementation of the language without having to learn anything new.
        • If I have perl 5 code and years of experience writing it, what is going to make me want to re-code everything when all my old stuff works anyway?

          perl 6 is a solution without a problem -- which is why commercial sponsors aren't sponsoring it.
          • If I have perl 5 code and years of experience writing it, what is going to make me want to re-code everything when all my old stuff works anyway?
            You don't have to re-code. Please read my previous post more carefully.
            • I don't think that I was clear enough.

              If I can just run everything from Perl 5 in Perl 6, why would I want to write code in Perl 6? (that won't work on the millions of currently deployed machines with perl 5 already installed)

              The cool thing about Perl 6 is that you get a commmon runtime engine that can run multiple language on multiple platforms. That's neato.

              But why a new language with new syntax, bugs and oddities?

        • Perl 6 will be backward-compatible with perl 5.
          If true, this would cancel out the best advantage of Perl 6, which would be to rid the language of all of those incomprehensible syntactic quirks that Perl 5 has accreted. The Perl book is already over 1000 pages long--will it be 2000 pages for Perl 6?

          --Mike

    • Tcl was designed from the ground up to be 'embedded and extended', and it shows. The core C code is well documented and easy to read, and there are man pages for all the functions in the public API. It's very easy to create little extensions without using any wierd half perl, half c languages. Tcl exposes a huge portion of its internals at the C level, which lets you do all kinds of cool stuff in your C code. It's very easy to create code where all the performance critical sections are coded in C, and th
      • Re:Tcl (Score:2, Funny)

        by cymen ( 8178 )
        "...without using any wierd half perl, half c languages."

        This is somewhat ironic considering Tcl's own syntax. Maybe it's just me...
    • extending and embedding Perl 5 is HELL.
      It's not just hell for developers, it's hell for users, too. For instance, if you upgrade from Perl 5.6 to Perl 5.8, you have to recompile every single C library that your Perl code links too. Ouch! Try explaining that to your typical end-user.
      • Ok. Let's try:

        "If you upgrade from 5.6 to 5.8, you have to recompile your C based Perl modules."

        Fairly simple. Making a snapshot bundle and installing said bundle is also trivial.

        Depending on how your previous Perls were compiled, you may or may not have had to do this previously anyway. On the bright side, it also means that users will probably have more up to date versions of modules rather than whatever version existed 3 years ago (5.6.0) or longer (5.005 was 5 years ago). Modules can change a lot in
  • NULL? (Score:2, Insightful)

    by Anonymous Coward
    >Things like NULL being used throughout chapter 3, only to finally be defined later in a footnote in chapter 4.

    You said yourself that this book is intended for experienced programmers. If you don't know what a NULL is as well as the implications, and are a programmer, you are in deep doo doo. You definitely cannot be considered to be an advanced programmer. I am suprised this book even defines NULL.

    However, I have seen a lot of programmers that have trouble and bugs related to NULL values ... of course
  • by Andy Dodd ( 701 ) <atd7NO@SPAMcornell.edu> on Tuesday April 08, 2003 @12:49PM (#5686693) Homepage
    Or does the book cover easier ways to embed C into Perl, such as SWIG.

    SWIG rocks. SWIG is your friend. I'll agree that extending Perl by embedding C is hell and the documentation sucks, but SWIG makes it all (relatively) easy. With SWIG all you have to do is be careful about data types. (Mainly, you can't directly pass a Perl array to C code, you have to convert it into a C array first. How to handle situations like this with SWIG is well documented.)

    I spent five days trying to figure out how to embed some C functions into Perl. Then I discovered SWIG and was up and running in 3-4 hours.
  • I used perl once, and that was for doing
    bash$ perl -e "while(1){fork()}"
  • I am in no way embedding Perl, I don't even like her that way. All rumours of me extending anything towards her are purely fictitious.
  • twisty passages (Score:4, Insightful)

    by syle ( 638903 ) <syle.waygate@org> on Tuesday April 08, 2003 @01:08PM (#5686820) Homepage
    As an experienced C coder, I can happily testify about the need for this book. The man pages to perlembed, perlapi, perlguts are obviously written without regard to the reader actually understanding the content.

    I consider myself a competant programmer, but years of experience have never taught me what it means to 'assign magic to a variable' or deterime the 'taintedness' of a string I found to be magical. Problems of global scope of the loaded programs alone merit a book, or at least a chapter.

    The documention behind it is some of the most befuddled I've ever had this displeasure of witnessing, so nearly all my learning came from studying other programs who managed to do it, along with a brief and ill-advised stint into the garbage collection routines of the interpreter source.

    Merely by existing and being written in English, this is already the best reference on the planet. Hell, it could be written in Klingon and still be more understandable than half the API documents.

    • Merely by existing and being written in English, this is already the best reference on the planet. Hell, it could be written in Klingon and still be more understandable than half the API documents.

      You have no idea how much better this makes me feel. I was really starting to doubt my own knowledge and abilities. It's so nice to feel that I'm not alone.
  • Embedded. Please no, not that word again!

    - IP
  • This book has been a long time in waiting. I've used PerlXS to preserve legacy code written in C with more than satisfactory results. I had to do this on a win32 platform, where the man pages (usually written for *NIX environments) don't always 100% translate to a win32 environment.

    I'll probably get the book.
  • by Anonymous Coward
    check out this tutorial [std.com]. It's a better starting place than the book reviewed here, which seems more like a reference than a tutorial to me.

    XS really isn't as horrible as some people make it out to be.

    Posting anonymously from work, someone mod me up, okay?

  • I haven't read the mentioned book, but O'reilly's advanced Perl programming book covers most of this in one chapter. But what is very valuable in it is they have a C function called perl_call_va() which handles the hassles of passing params in and out of the perl functions so you don't have to worry about the stack yourself.

    I did change their code to use strncpy instead of strcpy for copying string return values to a char array in C. Can't believe that was in there... :(

    (This is for embedding Perl inte

  • Two sample chapters from the book are available in PDF format from the publisher's website, here [manning.com].
  • There was another review [slashdot.org] of this book on Slashdot last October.

What is research but a blind date with knowledge? -- Will Harvey

Working...