Extending and Embedding Perl 145
Extending and Embedding Perl | |
author | Tim Jenness and Simon Cozens |
pages | 375 |
publisher | Manning (http://www.manning.com/) |
rating | 8.7 out of 10 |
reviewer | habit forming |
ISBN | 1930110820 |
summary | Get in touch with the inner Perl. |
What's that up your sleeve?
It is my experience that many situations require us to "look under the hood" of (thoroughly examine) a solution to understand how to best use it effectively. Perl is no exception. The ability to bring such a force as Perl to a project at the proper time is a valuable skill to possess. However, wading chest-deep into XS and the Perl internals is not for the faint of heart. Jenness and Cozens ease this process by stepping in lightly at first.
What's in it?
The book begins with simple C examples that are then related back to the readers' knowledge of Perl. Then the text seems to throw us a curve by leaping off into building Perl modules. But there is method to the madness: building Perl modules correctly is inextricably linked to XS. Light introductions to XS are performed and the reader is well on his/her way to building .so extensions to any .pm.
After building a very specific foundation of simple C examples, module building, and some XS, the text returns to C to introduce pointers, arrays, file I/O and memory management. With these new skills, we begin to explore the structure and implementation of Perl variable types. Chapter 4 provides many useful diagrams of how Perl variables "look" and what C structures they translate into.
Still following a logical and constant order, we explore the Perl 5 API, learning how to post and retrieve information to the variable types explored in the previous chapter. As much as it might seem, this is not a rehash of the perlapi doc. It is consistent with the perlapi doc, but Jenness and Cozens provide extensively annotated C code examples.
Casting deeper still, we add the advanced C of pointers, arrays, file I/O and memory management to our knowledge of XS. At this point we have everything we need to effectively extend Perl, but the text continues deeper still by exploring how XSUB interfaces to Perl's internals. It is only the clearly documented, step-by-step explanations of this chapter that make it manageable for an average user like myself. Chapter 7 ends our stint with XS by discussing some alternative XS (or equivalent code) generation suites.
Switching gears entirely, we grab libperl.a and stuff into a C program. Chapter 8 begins the task of embedding Perl into a C program. Jenness and Cozens continue the embedded discussion through a Case Study in Chapter 9 and end with a look through the Perl internals in Chapter 10.
The final chapter (Chapter 11) details some of Perl's history, its development process, how we could become involved and what the future of Perl and Perl 6 may entail.
Final Thought
This book was indispensable in gaining a good foothold on using Perl in, from, and around C. I found it a good reference guide as well as an easy ,linear read. It is not a replacement for the perlguts, perlapi and perlxs documentation, but then again, it doesn't try to be. The annotated code examples with every line explained make following the book with development of your own solution a lot easier than in some other books. However, the in-depth explanations can be a bit frustrating for the impatient.
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.
XS Isn't the only way. (Score:5, Informative)
XS Mechanics (Score:5, Informative)
XS Mechanics
Re:What's with the Related Links? (Score:2, Informative)
My $0.02 (Score:4, Informative)
It's amazing how much this book covers: Not only does Sam Tregar show how object-oriented Perl modules are architected, how to write regression test suites, how to extend Perl modules with C code, but he gets also the community aspects right -- how does your module get really popular? You can tell that Sam is a successful Perl module author himself.
-dk
Re:Perl 5 API??? (Score:5, Informative)
Isn't Perl 6 coming out soon?
"Soon"? Considering that they haven't even finished [perl.org] deciding the features and changes of Perl 6, I think it's safe to say that a release version is at least a few years off, with 50% adoption being another three years plus after that.
Re:Perl 5 API??? (Score:2, Informative)
True, Perl 6 is coming, but the shape of the language is still being discussed, the virtual machine isn't doing that much yet, and there's not really anything substantial yet... it may take a year or two until Perl 6 is out (not sure about the developers' actual schedule, though).
As far as I know, there's not many (if any?) books that discuss the XS or Perl embedding. It sure isn't covered that widely in the Camel or Ram, and the only reference has been "go RTF 'perldoc perlxs'"... =)
And most importantly, the Perl 6 folks have not said a word about how XS and embedding stuff works in Perl 6. (I suspect that it will be radically different, because of the Parrot...)
Re:Perl 5 API??? (Score:3, Informative)
Maybe the author will make more $$$ releasing the perl 5 book now, and the 'revised' perl 6 version next year
Also don't forget the sometimes extremely long lead times for book publishing, it is entirely possible that the author finished this book 6+ months ago.
And last but not least, yeah, perl 6 is going to come out soon, but do you really think I'm going to use it for production code right away? I really don't think so, perl 5 will be the tool of choice for quite a while longer.
Re:Perl 5 API??? (Score:5, Informative)
You'll still be able to run your Perl 5.x scripts under 6, but not vice-versa. Thus, with all the existing Perl 5.x scripts existing in the wild, having a Perl 5 book around may still be handy.
If you like analogies: why would you buy a C book when C++ has been around for years?
-- Hamster
Re:Perl: Fitting into the Big Picture (Score:5, Informative)
Uh, no. Thanks for playing. There are things that C++ does that Java does not -- some of which I'm thankful do not exist in Java (preprocessor) and some of which I miss (generics). But despite its C-like syntax and superficial resemblances (finalizers seem like destructors but aren't) Java is more like Smalltalk than C++.
Take a quick gander the section For C, C++ Fans [sun.com] in Peter van der Linden's Java Programmers FAQ [afu.com]
But then, why am I arguing over the relative merits of Perl, Java, C++, and C# with a user having the handle "Microsoft Research" who posts pure FUD?
I think Perl5/XS will be with us for long time... (Score:4, Informative)
Recently, the DotGNU have made an overture [develooper.com] to try to use the Parrot runtime for their C# compiler but found that Parrot needs a lot of work to get to the point where they could use it.
Some Parrot VM problems:
no calling conventions yet for subroutines. There is no hope of offering mixed language support unless they do this.
no conversion opcodes for various builtin types (float, char, short, int)
non-perl languages expected to provide additional support in the form of C code libraries for their opcodes. This would nix any hope of having a single standard universal virtual machine.
no way to call out to C code
no equivalent of Java's jar file or CLR's assemblies for parrot library distribution
way too many registers: their register based VM (32 int registers, 32 double registers, 32 string registers, 32 PMC registers plus various stacks) requires a sophisticated compiler to do proper register allocation and needlessly complicates their VM.
no consideration of threads in their design. How will they handle synchronization, for example?
The points above are not coding issues, but issues of design. It seems that Parrot is too hung up on making the VM efficient and are not seeing the bigger picture - to get the features in place first so that high-level languages can work. Or perhaps they should simply concentrate on getting Perl6 to work first. They need more focus. The project tries to be all things to all people, but ends up satisfiying no one.
Save some money (Score:3, Informative)
----
Associates Link
Re:interpreter for other applications (Score:5, Informative)
Our ASCII file import parsers are written in Perl and the data read into Perl data-structures. The contents of these data structures can then be accessed directly from C++.
The code is on the web (it has some subtle C++ bugs needed fixes using the base-from-member inititialisation idiom) here [willnolan.com]
umm... hello? (Score:4, Informative)
As for C in Perl... Perl is a scripting language, it's simply not fast enough for everything, and you're going to need C to access different things, like joysticks, video, graphics libraries, etc...
Re:My $0.02 (Score:4, Informative)
You seem to be thinking of Writing Perl Modules for CPAN [slashdot.org]. There are similarities, but the Jenness/Cozens book goes into more detail about XS than the Tregar book. That's to be expected.
pcre (Score:4, Informative)
Interfacing Perl with C... (Score:5, Informative)
In my case, I'm part of a large scale C++ project. I have the ownership of a module with clearly defined interfaces with the other modules written in this project.
Since my module relies heavily on XML and strings, I have always wanted to pair it with the power of Perl for testing purpose.
Among various possibles solutions (XS, SWIG, etc.), I settled on SWIG because it could handle 'shallow' classes. (allowing to expose my module as a perl object)
This has been the best decision I have made over the last year: when I get a bug case, I simply write a perl script to try to reproduce the problem, add some loops to get some combinatory, then check the result. This drastically cuts down on the time spent on debugging my module (or the modules used by it, for that matter :)
Pros:
Summary: If you are a C/C++ developper and your code can use XML/text files/strings, consider using SWIG or XS for testing purpose.
PS: if you want to Quantify/Purify your module/Perl script, using ActiveState Perl, you need to recompile Perl with the -DPURIFY option toggled on.
Re:I think Perl5/XS will be with us for long time. (Score:5, Informative)
Finally
If you'll look, you'll notice that perl 6 isn't fully designed yet, but the bits that are have been implemented.Just because you can't (or won't, or don't want to) see the focus doesn't mean it's not there. It is, thanks very much, and we're well on track to do what we need and do it well. The design's flexible enough to pick up things like JVM or .NET compatibility without a loss of focus or efficiency, so there's no reason not to.
The trouble with mixed-language work (Score:3, Informative)
The result, of course, is undebuggable random crashes in the high-level part of the system. Here's are some typical bug reports from mixed Perl/C work:
I'd like to see safe inter-language calls across a protection boundary. CORBA is about as good as it gets, but it's slow, because it marshalls the data into a stream and pumps it through a socket to the other side. There are faster approaches (look at Multics protection rings) but they need some hardware support, which we don't have today.
Tcl and other languages (Score:2, Informative)
Perl, IMO, is the worst of the scripting languages to combine with C... the interface is not pretty. Other languages like Python aren't bad. Lua is good if you want something really small and fast.
Re:Save some money (Score:5, Informative)
http://www.manning.com/jenness/index.html
Re:I think Perl5/XS will be with us for long time. (Score:5, Informative)
There's nothing particularly wrong with saying "You must have the X library/module/kit to do Y". Requiring the install of the
What's next, will you start complaining next that we're going to require installing Postgres to access Postgres databases? (Or will the next complaint be about the bloated size of the distribution to provide the features that match your expectations?)
Re:XS Isn't the only way. (Score:3, Informative)
Python makes it much easier to interact with C libraries, and Ruby has the nicest C library support of all. Also, for embedding a program language into an application, why not use Scheme? It was designed to be embedded from the beginning and should impose much less overhead. Since it's a functional language, it's also very well suited for AI, which makes it a good choice for games and such.
I'm not knocking Perl. It has a special place in my heart as the first language I really learned; however, it's best used for what it's really good at, and that's scripting.
Re:I think Perl5/XS will be with us for long time. (Score:1, Informative)
PPC G4 lacks key builtin opcodes for universal language support - like support for 64 bit ints.
Java VM lacks key builtin opcodes for universal language support - like support for 64 bit ints.
You do understand that Parrot is a VM, don't you?
Re:The author talks about alternatives (Score:2, Informative)
Re:Perl 5 API??? (Score:3, Informative)
They have said a lot about it: XS is going away completely, and interfacing C to Perl is going to get a lot easier. (The quote I remember from their FAQ was something like "how could it be any harder than it already is?")
As far as embedding Perl, well, the Perl interpreter is going to be written in Perl starting with Perl 6. Instead of embedding an interpreter, I think you'd just embed a Parrot VM and hook your compiled Parrot bytecode into your program.
Re:Not intended as a flamebait, but... (Score:2, Informative)
It's a good thing, according to Larry, because Perl more closely maps to spoken language patterns. His theory is that the computer should do extra work to make the life of a programmer easier.
I don't understand your comment about interpreting that code as a boolean construct. That's exactly how Perl does evaluate it. See B::Deparse for clarification.