Slashdot Mirror
Extending and Embedding Perl
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.
Will write "embracing and extending PEARL". Boy! I can't WAIT for that one to come out!
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.
I'm out of my mind right now, but feel free to leave a message.....
Does anyone else confuse CPAN with CSPAN?
I cannot be the only one
misread that title at first glance, was dreading to see what microsoft had done to perl :)
Nice try at the submitter trying to be a dork though.
hmmm
methinks if you can't understand what your wrote in the past, your time would be better spend learning how to write good perl than bitching about how you can't...
just a thought
_g-)
To extend/embed Perl you apparently need a book. For the same task with Python, simply look up the fine documentation on their web page, and you're ready do go in less than an hour.
Let the flames come...
Cheap php hack! STFU.
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.
>Things like NULL being used throughout chapter 3, only to finally be defined later in a footnote in chapter 4.
... of course I tend to immediately not listen to anything they say anymore, but some have produced code that does work. I hate to imagine what else they don't know... especially about other important stuff like security and database efficiency.
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
l8,
AC
You're dissing perl for being quick and dirty, but just because you can use a shortcut, doesn't mean you have to. I can code with perl and have it come out looking as clean as Pascal (or even *gulp* Java).
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 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
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
use Perl or die();
... well ... Windows crap. Gawd I hate MFC. But that's another story.
s ThemOnSeparateLines {}
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 an add-on, whenever I'm working on a PHP page, I have instant access to every function and object in that file, complete with the function prototype - at a glance, I can see what any given function needs as input. And, given the fact that all of those variables in the prototype are named, one can indirectly provide information on what the whole function is intended to do, if the function name and variable names are written properly.
I suppose there's always the alternative.
sub MyPerlFunctionWhatTakesTwoScalarVariablesAndPrint
But like I said, I prefer PHP's method.
Take that troll and stick it up your ass. This is more of an issue with your programming skills than it is with the actual language. Perl allows for freedom. A lot freedom in the way you wish to, or wish not to control the syntax/structure of the project. Although for you it seems that you do not have the skill in which to grok the language and produce coherent code. Again this is not a problem with the language.
s/ellegance/elegance/ :)
I felt exactly the same way when I started to use Perl. Like everything else it just takes getting used to. After a while you have screwed your brain up and it all starts to make sense. You look at the goofy syntax and it means something to you. Then the syntax actually starts to feel elegant.
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.
Argh ... perl comments ... I don't want hashed comments, I want C++-style comments! But that's nitpicking :)
:) It's just far far easier to obfuscate perl than with other common languages. At least in my own limited experience.
:)
... I might be interested in using some sort of VisualStudio-style IDE, if one existed. Maybe as an add-on to Eclipse? I'm very big about function prototypes and having "outlined" displays of code. It better fits my compulsion towards laziness.
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
Yeah, Perl's argument handling is a bit messy. But it's completely flexible as well. You can have named arguments even though there's no special support for them, for example. And it's easy to write generic code to say, log all the arguments passed to a function.
sub crap1 { print join "\n", @_ }
sub crap2 { print $_, "\n" for @_ }
sub crap3 { print "You're an idiot!" }
Yes, Perl's argument handling functionality leaves something to be desired (hint: it's fucked) but if I were to start looking for "better" languages to use (hint: a language I can use for something other than web shite) I would look yonder Python.
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.
retrorocket.o not found, launch anyway?
as lame as your mother, you slut.
/|||||\ - Server: goatse.info /\O | - (Website coming soon, fagG0tZ!) /8S8S8\
-- TROLL-KORE FOREVER!!!1
- I hate you, I hate your country, and I hate your face!
___
/ | \
|_____| - Channel: #TROLLKORE
| o
| UUUUU |
\_____/
| | LOOK AT MY SHINY BELL,
| | AND MY HUMPED BACK!
| 8 | - Prince of Knobstradamus
|S S|
|8S8S8S8|
|S8S8S8S|
\__/__/
Note to self: get smarter troll to guard door.
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.
sic transit gloria mundi
Except that Perl(at least Perl5, since Perl6 will change this), isn't big on function prototypes.
It's a more dynamic language, so it takes a more dynamic way of thinking.
Anyway, ActiveState produces Komodo, 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.
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.
Perl + Eclipse is coming... you can see the beginning at the EPIC project home page.
(I can't wait! Go, guys, go!)
Happy Premise #3: Even though I feel like I might ignite, I probably won't.
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.
/syle
Embedded. Please no, not that word again!
- IP
of one that appeared a month or two ago
... to handle an arbitrary number of arguments
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 semantics are inherently varardic. I prefer this rather than having to define n number of functions for n possibilities of argument passing.
In the course of every project, it will become necessary to shoot the scientists and begin production.
I don't want hashed comments, I want C++-style comments!
/*
why would you need C++ style comments when everybody ends up writing...
*
* Like this
*
*/
which is not too different...
#
#
# From this.
#
# =)
Well, like any language, it gets easier when you learn the idioms, rather than trying to speak another language using the syntax of your native language. A little intelligence will always create more compact and elegant code than a generic code-munger. That's why nobody who speaks sign language uses finger-spelling (unless there's no option).
What's wrong with:
sub MyFunction{print "$_[0]\n$_[1]"}
Not very versatile, but that was the routine specified.
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.
/*
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.
*/
AWK YOU!
Perl Sucks. AWK Rules. Stop wasting everyone's time with silly perl tricks.
You're welcome
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 code, which is probably difficult to work with if you've to read someone else's code. But it shouldn't be a problem reading your own code.
languages that are self-obfuscating, are full of 'shortcuts', are needfully open to change, difficult to extend, and allow for maximum unreadability should be shifted off the programming coil. Perl is one of these. Its for people who like to say "Guess what this does!" and have other programmers respond, "I have no clue.".
This book will probably be useless in a few days, might as well give it a speed read and throw it away unless you plan on using perl 5.x.x for a while.
ActiveState makes a perl plugin for VS.Net. Visual Perl
=begin comment
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
Generally, it is very poor practice to use global vars in a subroutine. They should always be assigned to another variable so you don't accidentally corrupt them and it makes the routine much more readable.
This is a huge problem with Perl programmers, they often just do quick hacks which lead to God awful code and then Perl gets a bad rap as a result.
If Perl programmers would just:
1.) use English
2.) assign globals to a lexical
3.) stop writing code in the fewest chars possible and start writing code that is clear and self explainatory
4.) use comments where it's not self explainatory
5.) pick a coding style and stick with it
Most Perl code would be a helluva lot more maintainable and I wouldn't have to hear the constant whining of Python and Java programmers about how Perl code is garbage.
There's more than one way to fuck it up.
You can't shine a turd, you can't unscramble an egg, and you can't maintain someone else's Perl code.
XS really isn't as horrible as some people make it out to be.
Posting anonymously from work, someone mod me up, okay?
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.
Right on. I don't understand what's up with all these perl freaks.
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 interpreter into your C program, but the book also covers visa-versa too)
Um, actually he's not using globals. The @_ array is local to the subroutine and contains any parameters passed to it.
Two sample chapters from the book are available in PDF format from the publisher's website, here.
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 then tied together with Tcl.
Python's C API is also pretty good.
http://www.welton.it/davidw/
There was another review of this book on Slashdot last October.
Find free books.
Larry Wall loves to dismiss awk, and emphasize how brillant he thinks he is, but the fact is he should bow down to awk. Oh, so he ran into a stumbling block with awk and wet his pants and so decided to build a better scripting language. So what. Do you know anyone who can sit through the Camel book? huh? No. Someone said it was a great example of technical writing. There is so much in that book, yet its missing almost everything. Thats where all the other gigantic Perl books come from. If he knew how to write he could have fitted all the info into one book. But instead, you get him blabbing about how he is a hacker and this and that. BOW!
coding too much Parrot makes you crazy?
Or rather, what became Zork.
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.
Yes, @_ is local, however, read page 219 of Camel III (Chap 6, Subroutines):
"The array @_ is a local array, but its values are aliases to the actual scalar parameters. (This is known as pass-by-reference semantics.) Thus you can modify the acutal parameters if you modify the corresponding element of @_."
Therefore, you should almost always copy this array to a lexical variable(s). It is safer and much more readable.
A related example is given on P.220:
upcase_in($v1, $v2); # this changes $v1 and $v2
sub upcase_in {
for (@_) { tr/a-z/A-Z/ }
}
This IMO is a great example of WHAT NOT TO DO! It may be short, but it is very very very poor programming practice to do such a thing.
So, DON'T use globals... DON'T EVER USE GLOBALS!!! Unless you really really have to.
A 0? What, don't these idiots on slashdot know the first thing about Perl. This guy hits it right on the head. I dread to see what shitty Perl code lurks on this webserver. Get a fucking clue /.
APP is a _very_ brief skim of the material. EaEP goes into far more detail.
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.
-- koschei
(a) use pod (q.v. perldoc perlpod )
(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
-- koschei
Thanks. Beings that I am just getting into this myself, I'm more than a bit interested. Can never have too much good information!
I really like Komodo.
I feel fantastic, and I'm still alive.
You really are quite the silly man. Use POD.
=pod
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.
=cut
Was that so hard? Or if C++ or any other style of commenting still floats your boat try Acme::Comment.