PHP and Perl in One Script? 174
gbulmash asks: "Recently, I began working on a graphics project and wanted to use ImageMagick. As a PHP coder, I figured I'd use MagickWand for PHP. But after some investigation, I decided that an alpha at 0.1.8 with sparse documentation just wasn't going to be good enough for production use. I decided that PerlMagick would be a much better API, but I didn't want to code the whole project in Perl. In the end, I found a cool package for embedding Perl code in PHP scripts (with an article on its use) and it went to a 1.0.0 release, earlier this year. I think I've found my answer, but before I make a final decision and go ahead with it, I thought I'd ask the knowledgeable Slashdot crowd: Is there a better way of interfacing Perl with PHP so you can get the best of both worlds?"
So you've got Perl in your PHP, is there a way to do PHP in your Perl?
A bit extreme (Score:5, Insightful)
Why didn't you use the ImageMagick extension in PECL [php.net]? There's plenty of image processing options with PHP, just because MagickWand didn't work out for you, that doesn't mean you have to concoct a monstrous hybrid of PHPerl.
Re:A bit extreme (Score:3, Interesting)
</outraged>
Re:A bit extreme (Score:3, Funny)
Shot through the code,
and you're too lame.
You give PHP
a bad name.
<? } ?>
We've known this for a while (Score:2)
If you want to use Perl, use Perl! (Score:5, Informative)
I used this same trick to interface a binary-only executable to my PHP script. You can even use XML to pass the data back and forth, if you swing that way. I don't know how this might work on Windows, if that's what you're running on.
By the way, version numbers mean absolutely nothing except the author's opinion of his own software. In fact, the article you posted says: "the extension is still marked EXPERIMENTAL". Sounds like alpha to me.
Not to mention, this is the same guy that wrote Turck MMCache and in my testing, mmcache couldn't stay stable for more than a day or two, and would randomly return junk characters instead of output from our PHP scripts. Not exactly an author I'd trust for this kind of lower-level stuff. (Yeah, I know, there are 10 billion geeks who used MMCache on their 5-hit-per-day blog and it worked perfectly, and will not hesitate to point this out. It just didn't work for me, and other products did, sorry!)
For what it's worth, I've used "pecl-imagick-0.9.11" on my Gentoo servers to manipulate images (basically, to generate thumbnails by resizing and sharpening) and it works perfectly. I think this is different than what you're talking about. So unless you really just can't live without Perl (?), try that first.
Instead of looking at version numbers, test thoroughly.
Turck MMCache (Score:3, Interesting)
It's like peanut butter and chocolate... (Score:5, Funny)
Re:It's like peanut butter and chocolate... (Score:4, Funny)
Dude #2: You got your PHP in my Perl!
Announcer: Two great languages that only taste a little bit funny together. Now with less whitespace!!!
Oh yeah, kids. Don't forget to try our other product, "Mac & PC". It's the cheesiest!
Re:It's like peanut butter and chocolate... (Score:2)
CPAN! (Score:3, Informative)
aside from that, i really don't understand why you'd use PHP if you're familiar enough with perl to use it.
Re:CPAN! (Score:2)
mod_perl really is a big issue. In PHP, something that runs under two identical setups, one that uses mod_php and the other that uses PHP CGI will run identically.
mod_perl's caching and function wrapping can lead to unexpected results with global variables and modules (See: perldoc FindBin).
Embperl (Score:2)
Re:CPAN! (Score:2)
Ruby on Rails (Score:5, Funny)
That's what I'd do anyway, RoR running on gentoo with some kicking USE flags. I'm developing a complete Ajax OS in my spare time using this system. It's going to revolutionize the OS market and yes, it will have use flags.
Ooo, nice! (Score:2)
Re:Ruby on Rails (Score:2)
dreamhost [dreamhost.com], which has RoR hosting
Re:Ruby on Rails (Score:2)
Negative. I'm a happy customer. I looked at your BBB report, and there is no apparent reason for the rating:
Although in some cases the company failed to respond to complaints.
The sole negative in the entire report is the failure to respond to some complaints
Well, duh! (Score:2)
Sure! [perl.org]
</joke>
Just use php's functions? (Score:4, Interesting)
Allows you to avoid the problems of calling ImageMagik, piping it through perl, then doing whatever you need to do in PHP. Sounds like a recipie for excessive server load, to me.
Re:Just use php's functions? (Score:2)
Re:Just use php's functions? (Score:2)
You'd probably be a LOT better off it you used Python and the Python Imaging Library [pythonware.com], instead of trying to noodle around with combining PHP/Perl/ImageMagick.
First of all, PIL can solve your imaging problem, but more importantly, Python can solve your PHP problem. And then you won't have to get yourself hooked on a Perl problem as well.
There is of course an ImageMagick module for Python [python.net]. But I prefer to use PIL, which is full featured, well integrated with Python, robust and efficient, and plays nicely will with Numerical Python [scipy.org].
-Don
Re:Just use php's functions? (Score:2)
And yes, we know you have a favorite language. Most developers have one for interpreted and one for compiled (except those weird java guys who think they have the best of both worlds). I'm partial to C++ and perl myself. I could sit here and tout all the things that make me like it, but lets face it, most of the stuff I like about Perl, a Ruby user (to pull a random non-perl human from the air) would find intolerably designed.
Yeah. Point is, unless someone asks, "Well, what SHOULD I use?", leave it at criticisms or appraisals of the technique asked about.
ImageMagick? (Score:4, Informative)
Dear Slashdot, (Score:5, Funny)
Thank you
A. T. Roll
You shure you're a PHP developer? (Score:3, Informative)
Semi OT question (Score:2)
I'm a 3D artist working in the VFX industry. Recently, I've been scripting within my 3D app. (The syntax of this language is a lot like PHP...) There are a lot of things you can do with the scripting portion of the app. You can write modeling plugins that play with the geometry. You can write shaders. You can automate tedious tasks. You can work on the RGB buffers after they've been written. Etc. There was a rumor flying around that they were going to switch from the PHP'esque syntax to Python, the justification being that they can do much more powerful things with it. I'm unfamiliar with Python, so please forgive my ignorance. I just wanted to ask: Can anybody describe in laymen's terms what this sort of change could mean towards writing better/more efficient code? I'm almost afraid to ask this question for fear of starting a PHP vs. Python war, but I'm just curious if there's a significant difference in philosophy with this language or if the company making this app is just trying to follow in the footsteps of more successful apps that already use Python.
Re:Semi OT question (Score:2)
For short scripts it'd probably not mean much for you to switch from PHP (or a similar language) but for larger scripts the clean syntax and object oriented nature would save you a lot of work. The kicker being that you need to understand the concept of objects to work well in Python.
Re:Semi OT question (Score:2)
Good languages are hard to design. Scriptable applications that dream up their own special-purpose scripting languages tend to have a lot of deep flaws and fundamental limitations. Most of the developer's resources go into the main application, not designing and supporting the scripting language. And special purposes non-standard languages usually don't have good development and debugging tools, either.
Python is a very well designed language, with a huge active community and robust collection of tools and extension modules, which was designed to be used as a general purpose application scripting language, from day one. Its syntax is quite simple, and there aren't a lot of exceptions to the rules (like Perl) or subtle nuances and inexplicable quirks (like PHP), so it's quite easy to learn.
One of the big upsides to using Python as an application scripting language is that all of the standard and add-on Python modules are at your disposal, and if you need to do anything specialized, you can write your own Python modules (using SWIG [swig.org] makes that quite easy).
Why would you want to plug your own custom Python modules into a scripable application like Maya? You might want to call libraries that import and export content, and integrate existing i/o and previewing code from the applications that consume the content you're building in Maya. And if your other applications are also scripted in Python, then you can use the same code and modules in your application and your tools, which really rocks! Python on Windows also has full support for OLE Automation, so you can easily integrate applications like Excel, and ActiveX controls, too.
But to stay on topic: Despite its crystal-meth-like popularity, PHP is an ameteurishly designed language, and has a long track record of each new version breaking compatibility by attempting to paper-machete over stupid mistakes of the past, that shouldn't have been made in the first place. But the difference between PHP and Perl, is that PHP is just naive, and didn't know it was making those mistakes. But Perl is totally malevolent, it chose to make all those mistakes on purpose, and it revels in its own fractal complexity.
Sure, go ahead with your experiment to arrange a shotgun marriage of PHP and Perl. But beware: this could happen to you [theinquirer.net]!
-Don
You want PHP in your perl (Score:2)
Congratulations (Score:2, Funny)
Why not use http as your connector? (Score:5, Informative)
Haven't you ever heard of that Loverboy song? (Score:2, Funny)
GD? (Score:2, Informative)
Just wondering. :-)
Quality and GIF (Score:2)
GD didn't support GIF files (legally) for a long time (you could always compile it in, but that meant nothing to people on shared hosting). Also, ImageMagick produced, in my opinion, better quality files at smaller sizes than GD used to.
Of course, today, with no GIF problems and the quality on both about par, there's not a lot of difference.
Our system offers a plugin based solution, use GD or ImageMagick with a single config file change. As far as calling ImageMagick from PHP goes, we just use the command execution functions.
I've used both PHP and Perl. Advice: Don't do it. (Score:2)
There is a clearly defined functional separation in this case, though. It would seem to me that you want to do your web stuff in PHP and your images in Perl. Write your image scripts in perl then; There's nothing wrong with generating in PHP. Perl people will be able to maintain your image scripts, PHP people will be able to maintain your web scripts.
Re:I've used both PHP and Perl. Advice: Don't do i (Score:2)
Re:I've used both PHP and Perl. Advice: Don't do i (Score:3, Informative)
Hell, then a page of mine that uses all of:
* bash
* C
* C++
* Perl
* perhaps even Python or some such (hell, I don't look under the pants of programs I call)
* sed
* grep
And as far as I know, this is not a rare practice. If it's not a CPU-critical script, bash makes for good glue code. And you can't call it hard to maintain (at least until you look at sourceless configure scripts).
7 languages in one program (Score:2, Funny)
Embed all your languages, this file can be interpreted or compiled in 7 different coding languages:
$ php poly.sh.pl.php.tcl.cpp.bf.py.c.lhs.txt
#I'm a PHP script
$ python poly.sh.pl.php.tcl.cpp.bf.py.c.lhs.txt
I'm a Python program.
$ perl poly.sh.pl.php.tcl.cpp.bf.py.c.lhs.txt
I'm a Perl program.
$ tclsh poly.sh.pl.php.tcl.cpp.bf.py.c.lhs.txt
I'm a tcl script.
$ sh poly.sh.pl.php.tcl.cpp.bf.py.c.lhs.txt
I'm a sh script.
Rename file to compile in C/C++:
$ gcc p.c -o c;./c
I'm a C program (C89 with
$ g++ p.c -o cp;./cp
I'm a C++ program, trigraphs disabled.
Re:7 languages in one program (Score:2)
Calling PHP from Perl (Score:3, Informative)
I am in the joyous position of having to maintain a monstrosity of an application that was written by at least 4 different programmers over a period of years with numerous kludges plastered on top of a highly dodgy initial design.
A lot of the early code was in Perl. Obfuscated, unreadable, indecipherable (and uncommented) Perl. So I decided to re-implement whole libraries of functions in PHP instead. But...a lot of what goes on in the application is driven by 2 Perl daemons, and they needed access to the new PHP libraries too.
So:
Do they both need to be in a PHP script? (Score:2)
PHP = PHthon = Python = Perlthon = Perl (Score:2)
Well you could use the PHthon PHP/Python bridge, then the Perlthon Python/Perl bridge.
Wasn't Parrot supposed to solve all these problems? Or was that just a sick joke that some misguided people too much too seriously?
-Don
PHP => PHthon => ... (Score:2)
Thanks a lot, slashdot subject line filter. Those equal signs were suppost to be => arrows -- I didn't mean that they were equal (or ordered).
-Don
Again with the PHP bashing... (Score:2)
For your consideration: http://us3.php.net/manual/en/ref.image.php [php.net]
If you would like to see a simple script which generates a graph on the fly, help yourself to this [zaphodforpresident.com].
Yes, there are languages far more powerful than PHP. But, as I say EVERY TIME this flamewar goes down- are you sure you need them? As my grand-pappy used to say: why go deer hunting with a tank when a shotgun will do just fine?
Re:Again with the PHP bashing... (Score:2)
Re:If you use PHP.... (Score:2, Funny)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2, Insightful)
Re:If you use PHP.... (Score:4, Insightful)
Re:If you use PHP.... (Score:2)
It's a basic security best practice.
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Only if "basic security best practices" involve giving users a false sense of security.
Re:If you use PHP.... (Score:4, Interesting)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
That said I already have a Dreamhost account, cost me $10 for a whole year for their crazy domain insane plan, so it it's almost worth it for the laughs if they turn out to be total shizzle. So far no probs though...
Re:If you use PHP.... (Score:2)
What if you don't like cats?
Hey, I might have found the first legit reason for using PHP!
Re:If you use PHP.... (Score:2)
It's not PHP's fault. As a language it is more than capable of delivering security and stability. It just happens to not be idiot-proof while being quite idiot-accessible.
In that regard, its existence is no worse than the number of Windows machines running right now. Or for that matter, how many apps have been coded in Visual BASIC?
I've done C++, Perl and some Tomcat stuff ... On the whole, it has been more worthwhile to take the time committed to those approaches and re-apply it tightening up PHP code.
Now, that's a huge qualifier, I admit -- a lot of noobs aren't going to do commit that time.
But, I think it's not necessarily the right characterization to blame a language for empowering stupid people. It's right to blame the stupid people.
Re:If you use PHP.... (Score:2)
Well, that's one of its problems, but that's hardly what I'd call its main fault. Though I use it quite a bit, PHP is not an easy-to-use language if you care about correctness, robustness or security. I have a webpage [dlitz.net] that lists, in point form, some of the criticisms of PHP that I have accumulated over the last few years. The page is about PHP 4, since that's still what my customers' systems are using, but some of the criticisms apply to PHP 5 as well.
Question on one of those (Score:2)
My understanding has always been this was a hypothetical set of attack.
None of the problems you list on your site are that extreme. In point of fact, I use almost none of them (for example, I have my own function for XML parsing, probably a leftover habit from every other language where parsing was my problem). Every language has its issues (buffer overruns, too much file system access, etc.).
Re:If you use PHP.... (Score:3, Insightful)
For instance, accessing variables that are not defined returns nothing by default (most languages will throw an exception should this happen). This results in problems like this occuring [thedailywtf.com].
There are plenty of easy to learn languages such as Python and Ruby out there that do not have nearly as many problems, so there is not too much of an excuse to use PHP for anything but the simplest web page. What this guy is trying to do, use PHP despite the fact that it is obviously not powerful enough for his requirements), is just wrong.
I'll buy that argument (Score:2)
Fair enough.
Hello there, Comrade Molotov! (Score:3, Funny)
$x["a"]["b"]["c"] = "d";
I mean, can you do it the Perl way, with less keystrokes?
Re:Hello there, Comrade Molotov! (Score:2)
The perl equivalent of $x["a"]["b"]["c"] = "d";
would be $x["a"]["b"]["c"] = "d";
Gee
What? I'm not allowed to use references?
What about the ones that are implied? Like those cute little '[]' your statement used.
Similar to the implied reference that makes ANY array code work, by taking the starting address and jumping X units into the array to access a member.
Re:Hello there, Comrade Molotov! (Score:2)
foo
Re:Hello there, Comrade Molotov! (Score:2)
[~] 0 (jon@foo)
$ perl -e "$x['a']['b']['c'] = 'foo'; print $x['a']['b']['c'];"
syntax error at -e line 1, near "]["
syntax error at -e line 1, near "]["
Execution of -e aborted due to compilation errors.
The correct way to do this is:
[~] 0 (jon@foo)
$ perl -e '$x->{a}->{b}->{c} = qq{foo\n}; print $x->{a}->{b}->{c};'
foo
If you were only dealing with numbers, then this would work:
$ perl -e '$x[1][2][3] = qq{foo\n}; print $x[1][2][3];'
foo
Either way, you're still "using references". I don't know why you would want to avoid them, though, they're an excellent feature and they're very easy to use.
Re:Hello there, Comrade Molotov! (Score:2)
He used Perl on Windows, where you need double quotes around the argument, and OS variables do not start with $.
On linux, it would be:
$ perl -e '$x[a][b][c] = "foo"; print $x[a][b][c];'
foo
(basically the same as in PHP, except that you can omit a few quotes in this case.)
Re:Hello there, Comrade Molotov! (Score:2)
Please learn perl before posting.
[~] 0 (jon@foo)
$ perl -Mstrict -e '$x[a][b][c] = "foo"; print $x[a][b][c];'
Global symbol "@x" requires explicit package name at -e line 1.
Global symbol "@x" requires explicit package name at -e line 1.
Bareword "a" not allowed while "strict subs" in use at -e line 1.
Bareword "b" not allowed while "strict subs" in use at -e line 1.
Bareword "c" not allowed while "strict subs" in use at -e line 1.
Bareword "a" not allowed while "strict subs" in use at -e line 1.
Bareword "b" not allowed while "strict subs" in use at -e line 1.
Bareword "c" not allowed while "strict subs" in use at -e line 1.
Execution of -e aborted due to compilation errors.
Re:Hello there, Comrade Molotov! (Score:5, Informative)
Erm... how about
Yes, it uses references, but if you're scared of them, pretend it's a 'real' multidimensional hash.
Re:Hello there, Comrade Molotov! (Score:2)
PHP:
$x["a"]["b"]["c"] = "d";
Perl:
$x[a][b][c] = "d";
You can put also write it the PHP way (with all the quotes) in Perl, if you really want to.
Re:Hello there, Comrade Molotov! (Score:2)
Re:Hello there, Comrade Molotov! (Score:2)
The old syntax you might be thinking of was:
Perl has auto-reference traversal for adjacent {}/[] for some time now.
You still might need a single arrow:
if myref is a reference and not a strict hash or array like the first two examples.
(You often get "real references" thrown from functions that don't want to shallow copy
hashes for no good reason onto the stack, and OO Perl uses them heavily)
Incidentally... (Score:2)
$x->{"outer hash of references to hashes"}->{"inner hash of scalars or refs"}
Was Perl just being precise
The outer '$' sigil indicates you wish to treat the whole expression as a scalar lvalue or rvalue.
The first '->' indicates you wish to deference a scalar named 'x'.
The first '{...}' indicates you wish to treat (deferenced x) as a hash and use the lookup operator on it.
The second '->' indicates you wish to treat the return value of the lookup as a reference, and dereference that.
The inner '{...}' is the final hash lookup, which returns the scalar you wanted originally.
Incidentally, whenever you see this notation:
@array[$index]
Internally perl is really doing:
*array->[$index]
Because array is just an entry in a symbol table that is a reference (just like how arrays in C are pointers, or in Java are objects references).
But the @ notation carries additional connatations: when you use it as an lvalue it performs a shallow copy of the array in the rvalue (unlike a scalar reference assignment which only gives you a new handle to the _same_ array)... and it allows you to indicate when you want array or scalar context for functions or operators.
Anyway, at some point (last decade, *eye roll*) someone (Larry) decided that since Perl can tell what kind of reference something is before dereferencing it, that the syntatic sugar that @ and % operators get should apply everywhere (so [] and {} both deference AND lookup, all the time). So all the ->{}/->[] groups can collapse... just like in other languages.
But Perl can do this safely since it already knows what you're trying to do and won't let you do otherwise (using array lookup on a hash reference, for example).
Re:Incidentally... (Score:2, Informative)
Whoa, not for lexicals.
Nope, only after you've already dereferenced one level.
I was glossing over the details of lexicals... (Score:2)
But under the hood both @foo and $foo are both ARRAY refs, it's just that @foo has special copy-by-value semantics and array-context-when-lvalue-ness and other implicit connotations.
And you're right (oops), yeah that first -> is required because then you have this ambiguity:
my $foo = [1, 2, 3];
my @foo = (4, 5, 6);
print $foo[2]; ### Which foo is this?
The answer being it's always '6', and this:
$foo->[2]
Is always '3'.
Re:Hello there, Comrade Molotov! (Score:2, Informative)
$x{a}{b}{c} = 'd';
Beat you by 6 characters on that second one. And if I'm not allowed to use references, you're not allowed to use strings. Perl is designed with references in mind.
Re:Hello there, Comrade Molotov! (Score:2)
Re:Hello there, Comrade Molotov! (Score:2)
is perfectly valid in PHP, but it throws a notice (similar to perl's warnings) that shows up in log files, or as output if error_reporting(E_ALL) is set.
I always program with use strict in effect, and most of the time, -w or use warnings as well. Similarly, I like setting error_reporting(E_ALL) if I'm using PHP.
Re:Hello there, Comrade Molotov! (Score:2)
Is there a reason for this restriction? I mean, if you take out a major part of a language, you are going to be limited in what you can do with it. That doesn't mean the language is no good or another language is better, it just means you have to learn how to use that feature.
Re:Hello there, Comrade Molotov! (Score:2)
Is there a reason for this restriction?
Yes, the main reason for the existence of interpreted languages: simplicity. If I have to start worrying about references, then I'd rather do it in C and worry about pointers instead. For the same development effort I gain a couple of orders of magnitude in execution speed.
PHP has this advantage over Perl, arrays, dictionaries, hashes, they all behave more or less the same way, you need not worry too much about them. In Perl you have to be careful about that distinction. Also, there is no multidimensional array of values, only references. Handling multidimensional arrays is much easier in PHP.
Re:Hello there, Comrade Molotov! (Score:3, Insightful)
Translation: You are lazy.
Come on, if your point was just that it is easier to work in PHP, you could have just compared the code needed to maintain multidimensional arrays in both languages. Instead you challenged Perl programmers to do something with only a subset of their languages features, implying (at least to young programmers visiting this thread and who do not know better) that such a feat was not possible with Perl and you need some sort of hack to get it to work. That is disingenuous at best. I want to see a valid technological reason why you would be required to develop a Perl app without using references.
Re:Hello there, Comrade Molotov! (Score:2)
How about, "I'm too stupid to read the manual."
Re:If you use PHP.... (Score:3, Funny)
(And PHP can do funky things like change colours on events like mouseover etc? groovy! )
Re:If you use PHP.... (Score:2, Funny)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:3, Insightful)
Re:If you use PHP.... (Score:4, Informative)
Yeah
Re:If you use PHP.... (Score:4, Informative)
http://www.slashcode.com/ [slashcode.com]
http://scoop.kuro5hin.org/ [kuro5hin.org]
I have been trolled. Hope this helps. Have a nice day.
Personally I prefer Java Servlets, with perl a second place, then python, then bash, then C, then php.
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Re:If you use PHP.... (Score:2)
Right now I'm trying to figure out how to migrate away from IIS (we're debating what language / configuration we're going to go with...) which is VBScript. I've got Perl books, java books, maybe even some PHP books.
I know that I'm not entirely comfortable with a move from VBScript to PHP (even though they're about equal in capabilities), plus there's the immaturity of PHP. Perl seems likely due to its maturity and I don't think I'll have a problem groking it. (I know C, C++, REXX, VB, FORTRAN, PASCAL, with exposure to half a dozen other application languages.)
But where do you start with Java Servlets? (JSP?) I know, it's a lazy question, but why JSP instead of perl?
Re:#include "sarcasm.h" (Score:2)
Re:If you use PHP.... (Score:2)
One C to find them
One bash to bring them all
and in PHP bind them!
Re:If you use PHP.... (Score:2)
Re:Real men... (Score:2)
Haven't tried anything in depth with this yet but have you heard about how it fares with mod_perl (as far as turning "query arguments and cookies into global variables", as stated on the PerlHP web site)?