Extending and Embedding Perl 124
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.
You are likely to be eaten by a grue (Score:5, Funny)
Funny, I remember that exact phrase from Zork.
Re:You are likely to be eaten by a grue (Score:1)
Heck, Nethack didn't have *any* room descriptions, since it's traditionally all ASCII art.
Re:You are likely to be eaten by a grue (Score:1)
Re:You are likely to be eaten by a grue (Score:5, Informative)
Re:You are likely to be eaten by a grue (Score:1)
Yep. It's from Adventure. I remember it well...
brings back memories (Score:1)
I used to play it on a teletype my dad had in our shed. I forget what it was dialing into. Nice thing about the teletype was that you then had a printed record that you could go through offline and create a map from.
Re:brings back memories (Score:1)
Re:You are likely to be eaten by a grue (Score:1)
http://www.bf.rmit.edu.au/~fayep/Zork~fayep/Zork/
Actually it is from Zork... (Score:1)
Originally written on MIT-DM during 1977-1979, later distributed with BSD Unix (as a patched, sourceless RT-11 FORTRAN binary) The FORTRAN source was later rewritten for portability and released to Usenet under the name "Dungeon". Both FORTRAN "Dungeon" and translated C versions are available at many FTP sites.
Re:Actually it is from Zork... (Score:2, Informative)
Well... To get this right would take a while, and is massively off-topic, but IIRC, the original Colossal Caves (Adventure, by Crowther and Woods) was written in Fortran, and had a twisty maze of passages, which was also used in Dungeon/Zork, which was very heavily influenced by Adventure.
The commercial (Infocom) Zork series is a splitting up of the Dungeon/Zork program, which was not originally written in Fortran, it was in fact originally written in MDL by Marc Blank and Dave Lebling, and tran
Re:I must be silly (Score:1)
misread that title :) (Score:4, Funny)
Re:misread that title :) (Score:2)
Re:misread that title :) (Score:2)
[1] But they aren't written by Microsoft.
Re:Or just use Python (Score:2)
Just IME and IMHO.
Re:Or just use Python (Score:2)
Hm I see most scripts have a .pl extension - does slashdot use Acme::Inline::PERL [cpan.org] then? :)
Re:Or just use Python (Score:2)
This is a dead end (Score:4, Informative)
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.
Re:This is a dead end (Score:3, Funny)
Re:This is a dead end (Score:2)
Re:This is a dead end (Score:2, Flamebait)
Plus, Perl 6 is a totally new language. If I want to learn a new language, I'll bite the bullet and learn Python.
Re:This is a dead end (Score:1, Informative)
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
Re:This is a dead end (Score:2, Informative)
Here [sidhe.org], why [sidhe.org] not [sidhe.org] learn [sidhe.org] something [sidhe.org].
Re:This is a dead end (Score:2)
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.
Re:This is a dead end (Score:2)
perl 6 is a solution without a problem -- which is why commercial sponsors aren't sponsoring it.
Re:This is a dead end (Score:1)
You don't have to re-code. Please read my previous post more carefully.
Re:This is a dead end (Score:2)
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?
Re:This is a dead end (Score:2)
--Mike
Tcl (Score:1)
Re:Tcl (Score:2, Funny)
This is somewhat ironic considering Tcl's own syntax. Maybe it's just me...
Re:Tcl (Score:1)
http://www.tcl.tk/scripting/syntax.html [www.tcl.tk] has a good introduction to it - as you can see, anyone can figure it out in a few minutes! Definitely one of Tcl's strong points.
Re:This is a dead end (Score:1)
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.
Re:This is a dead end (Score:1)
"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)
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
Guide to doing it the hard way? (Score:4, Informative)
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.
Re:Guide to doing it the hard way? (Score:3, Informative)
Re:Guide to doing it the hard way? (Score:4, Informative)
There's a whole chapter on "Alternatives to XS", covering SWIG and Inline::*.
The only time I have used perl.. (Score:1)
Whoa whoa whoa... (Score:1)
twisty passages (Score:4, Insightful)
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.
Re:twisty passages (Score:2)
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.
Words, Etc. (Score:1)
- IP
It's About Time (Score:1)
I'll probably get the book.
If you really want to learn XS (Score:1, Informative)
XS really isn't as horrible as some people make it out to be.
Posting anonymously from work, someone mod me up, okay?
Oreilly Advanced Perl Programming covers this too. (Score:2)
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
Re:Oreilly Advanced Perl Programming covers this t (Score:1)
In fact, APP only skims all the topics it covers. It appears to mostly be an introduction to various topics that one can then further explore elsewhere.
These days, you're better off purchasing the TPJ books if you want the sort of thing APP gave.
For mixing C and Perl, EaEP is excellent.
Re:Oreilly Advanced Perl Programming covers this t (Score:1)
Sample Chapters (Score:2)
second review of this book on Slashdot (Score:2)
Re:Hmm, let's see ... (Score:3, Insightful)
I use PHP for web interfaces, Perl for unix scripts, and C++ for
PHP's function handling has a certain ellegance that Perl seems to totally and completely lack.
function MyFunction($line1, $line2)
{
print $line1 . "\n" . $line2;
}
vs.
sub MyFunction {
my ($line1, $line2) = @_;
print $line1 . "\n" . $line2;
}
People argue with me endlessly that perl's method "isn't a hassle". I use Eclipse to edit PHP, and thanks to a
Re:Hmm, let's see ... (Score:2)
Re:Hmm, let's see ... (Score:1)
Re:Hmm, let's see ... (Score:2)
I would chalk this one up to personal preference - don't think I've ever noticed the absence of named parameters in perl (my experience is about equal parts perl and java, but mostly perl lately), but I guess it's important to some people.
Now extend your example.... (Score:2, Insightful)
PHP:
function MyFunctionWith2Args($line1, $line2)
{
print $line1 . "\n" . $line2;
}
function MyFunctionWith3Args($line1, $line2, $line3)
{
print $line1 . "\n" . $line2 . "\n" . $line3;
}
function MyFunctionWith4Args($line1, $line2, $line3, $line4)
{
print $line1 . "\n" . $line2 . "\n" . $line3 . "\n" . $line4;
}
You get the picture...
Perl:
sub MyFunction {
print join( "\n", @_ );
}
this works for any number of arguments. Perl's argument passing seman
Re:Now extend your example.... (Score:2)
Re:Now extend your example.... (Score:2)
Piece of piss:
function MyFunction($lines)
{
print join("\n", $lines);
}
And then to call:
MyFunction(array("Hello", "World"));
MyFunction(array("You", "are", "stupid"));
et cetera
Re:Now extend your example.... (Score:2)
Why not a function, anyway? Array initialisers takesinput and return something - sounds like a function to me.
Re:Hmm, let's see ... (Score:1)
What's wrong with:
sub MyFunction{print "$_[0]\n$_[1]"}
Not very versatile, but that was the routine specified.
Re:Hmm, let's see ... (Score:1)
Re:Hmm, let's see ... (Score:5, Interesting)
Things can be done in other "structured" languages that would be as unreadable as the most obfuscated perl code. Being able to read your code 9 months from now is more a function of programmer discipline than the language used.
This game [netnexus.com] was written in perl, when I was learning, 5 years ago, and because I used good design and comments, I can still read and update the code.
An online Starcraft RPG? Only at [netnexus.com]
Re:Hmm, let's see ... (Score:2)
You have a very valid point
Have you ever played Perl Golf? Looking at the answers to that competition makes my brain cry. But then, I suppose that's the point
Has anyone ever made a Perl IDE? And I don't mean vi
Re:Hmm, let's see ... (Score:2)
Perl + Eclipse is coming... you can see the beginning at the EPIC project home page [sourceforge.net].
(I can't wait! Go, guys, go!)
Re:Hmm, let's see ... (Score:1)
why would you need C++ style comments when everybody ends up writing...
*
* Like this
*
*/
which is not too different...
#
#
# From this.
#
# =)
Re:Hmm, let's see ... (Score:2)
Sometimes I like to write big long descriptions of any moderately-complex procedures being stored in a file.
I really don't like having to put a hash in front of each line.
It gets rather cumbersone and ugly after a while.
*/
Re:Hmm, let's see indeed... (Score:1)
Sometimes I like to write big long descriptions of any moderately-complex procedures being stored in a file.
I really don't like having to put a hash in front of each line.
It gets rather cumbersone and ugly after a while.
L.
=end
Re:Hmm, let's see ... (Score:2, Informative)
(b) get a better editor. sane editors (vim, emacs, presumably others) are able to comment regions, or automatically insert comment leaders as you type, or both.
(c) Acme::Comment [cpan.org]
Re:Hmm, let's see ... (Score:1)
True that one can write obfuscated code in Perl, but it is because you can pack a LOT of functionality into a single expression. Maybe it's just me, but I was sold on this point - you don't need to be elaborate when all you want is to do an operation that can be expressed in one sentence of English. Also, the confusion is a result of There is More Than One Way to Do It philosophy - each programmer has his own ways of "obfuscating" the co
Re:Hmm, let's see ... (Score:1)
Re:Hmm, let's see ... (Score:2)
I really like Komodo. [activestate.com]
Perl IDE (Score:2, Informative)
Anyway, ActiveState produces Komodo [activestate.com], a perl IDE, and they also sell a perl environment for Visual Studio .NET.
I still write perl in vim, but I do use ddd for debugging my code.
Re:Hmm, let's see ... (Score:2)
The funny thing is that I now wish the other languages that I use had some of the Perl shortcuts in them. It really speeds things up.