Slashdot Mirror
PHP and Perl in One Script?
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?
...God kills a kitten.
But seriously, I understand if someone wants to use PHP, their choice (of masochism). But why on earth would you want to use PHP and Perl together? Perl is clearly a better language, so why don't you use Perl by itself? You'd get rid of the useless interfacing and the idiocy that is PHP.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Just use the Windows Scripting Host!
Whenever I hear the word 'Innovation', I reach for my pistol.
Why didn't you use the ImageMagick extension in PECL? 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.
Bogtha Bogtha Bogtha
I thought this was already publicized, Perl & PHP in one script? Isn't that just a brain fuck :)
Error 407 - No creative sig found
Instead of going with some bizarre rube-goldberg hack like this (does it even work with dynamically loadable Perl modules?), just write a separate Perl script that does what you need and receives data on standard input and gives responses on standard output. Use PHP's proc_open() function. You can even set up the Perl script as a daemon, if you like, and get higher performance.
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.
Regards, Phil
http://uk.php.net/manual/en/function.apache-note.p hp
Hopefully you'll come to your senses first.
All the security of PHP and all the readability of Perl? It's a surefire win. I wonder why the whole world hasn't caught on to this one yet?
Slashdot - where whining about luck is the new way to make the world you want.
> To be fair, they were plenty responsive the one time I asked for anything.
That's enough about butt-sex, plz stay on topic in future.
Ahhh, nothing like a good flamewar! OK, I'll bite. Tell me, please, how do you write multidimensional arrays in Perl? No, no, you are *not* allowed to use references! Or what about a multidimensional hash? Suppose I wanted to migrate from PHP to Perl, how would I translate this perfectly valid PHP code to Perl:
$x["a"]["b"]["c"] = "d";
I mean, can you do it the Perl way, with less keystrokes?
as almost always, CPAN is your friend in all things perl-related.
aside from that, i really don't understand why you'd use PHP if you're familiar enough with perl to use it.
I'm probably going to get flamed for this but have you considered using rails? Seriously, you just spend a couple of hours installing it on your development box before you discover the speed and power of rails. Then when you've used the programming equivilent of a lumphammer to sculpt your fine detailed script, you get to spend the next week looking for hosting. I do all my development on a gentoo box, it only took me a weekend to set up from stage 1. I have some great USE flags that make my RAILS development go super fast and gentoo only takes about 1.5 hours a week to maintain. Well, sometimes it takes a little longer because the QA is non-existent of late.
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.
So you've got Perl in your PHP, is there a way to do PHP in your Perl?
Sure!
</joke>
That green slime had it coming.
You'd never guess it from the moronic comments here but mixing dynamic languages will be common one day, until then:
http://parrotcode.org/
http://nekovm.org/
I know ImageMagik is the kitchen sink of image editing, but have you looked into PHP's embedded image functions? There's very few effects you couldn't produce on your own with those functions. I'll grant it's probably easier to just pass arguments to the ImageMagik library, but probably not more efficient.
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.
I'm writing a processor in RoR, wanna cooperate? :P
Send email from the afterlife! Write your e-will at Dead Man's Switch.
I tend to use ImageMagick a lot via PHP scripts, but not with any sort of polyglot of code or anything – I just use exec("convert ... ");. It's probably not the most cross-platform way, but since I tend to do exclusively Linux/UNIX-based stuff, and most of the code is only used by me for my own sites anyway, it's not a problem at least as far as I'm concerned.
Creative misinterpretation is your friend.
The fact that you had to do this:
$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).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Anywayz, thanks for sharing cuz sharing is caring. LOL!
Important Stuff * Please try to keep posts on topic. * Try to reply to other people's comments instead of starting new threads. * Read other people's messages before posting your own to avoid simply duplicating what has already been said. * Use a clear subject that describes what your message is about. * Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) * If you want replies to your comments sent to you, consider logging in or creating an account Problems regarding accounts or comment posting should be sent to CowboyNeal
Real men program in PerlHP!
Thank you
A. T. Roll
"Seven Deadly Sins? I thought it was a to-do list!"
There's like ten bazillion ways to integrate PHP with Image processing tools like Image Magick just like with any other OSS language. Only more so because the PHP userbase is largest. No need to use some Hack involving Perl. Typo3 (www.typo3.org) uses Image Processing to generate Menubuttons and stuff, there are countless other PHP projects out there doing the same, and it's no sweat at all to start the imagemagick CLI tools (contvert, etc.) including parameters from PHP. 30 lines of code max I'd say. Do you homework and then ask in some PHP forums and mailinglists for sample code. You'll get answers in no time.
We suffer more in our imagination than in reality. - Seneca
This question isn't all that relevent to the topic other than a brief mention of PHP. No hard feelings if modded off-topic.
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.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
I have to say I used Turck MMCache on an 80 server farm serving up >4 million page loads (not hits) per day with not a single problem. This was back in the PHP4 days. Based on the load on the machines it could have easily been done with 5 but management wanted to spread the risk in an insanely large manner.
rodent...
Tactical nuclear weapons are a viable alternative!
How about Catalyst-View-PHP.
Never underestimate the dark side of the Source
PHP would be a good tool, for a black man. 97% of negros have the P-H-Pizzle chromosome, while 97% of whites use more logical languages like Perl. The difference is clear in the supremecy of the language and its symantics. I fail to see a use for calling perl code from php. Let me make a simple comparison for you, when a white man goes into a bank, it must be to invest money to maintain his supremacy. While a black man starts gatt'n nigga's to clean the place out. The difference is clear, I don't wish you to agree with me. I simply wish you to see my point of view.
White as always,
GWB
Congratulations! You found the worst of both worlds.
Why do you need them to work in the same script? Have your PHP generate an img tag that references the perl script in the src attribute. Then the web browser will fetch the image data directly from the perl script and you don't need a Frankensteinian monster.
"Pearl and PHP DNA... just don't mix"
Just wondering. :-)
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 am NaN
I've used both PHP and Perl for web development. I'd discourage mixing PHP and Perl in the same script, it's not necessary. Sure, it can be done, but just because it can be done doesn't necessarily make it a good idea. It will make your website harder to maintain, because whoever is going to maintain your website in the future will need to know both perl and PHP (granted, they are relatively similar languages).
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.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Okay, so slashdot doesn't properly replace brackets. That sentence ought to have been "There's nothing wrong with generating in PHP".
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
http://blog.sykosopp.com/2006/02/26/one-file-to-ru le-them-all/
// comments, trigraphs disabled).
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.
Hallvar Helleseth (hallvar)
Using too many languages is bad?
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).
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.).
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
Meet Embperl
Promote civility: mod down any post starting with 'ummm'.
Fair enough.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
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:
Day by day, the penguins steal my sanity
http://outcampaign.org/
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
I take issue at your vile insinuation that pure innocent peanut cups which taste so wonderful and never hurt anyone, could possibly have any poisonous PHP or Perl in them!
I throw down this gauntlet to defend the reputation of peanut butter cups! Dual at 11:00.
-The Peanut Butter Cup Monster
That @foo and $foo are entirely seperate "slots" in the symbol table as far as Perl is concerned.
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'.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
... we wrote it.
http://cpan.uwinnipeg.ca/dist/PHP
For your consideration: http://us3.php.net/manual/en/ref.image.php
If you would like to see a simple script which generates a graph on the fly, help yourself to this.
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?
barack to the future?
How long before they let you out of the padded cell, anyway?
I remember the bad old days of shell programming. There's a reason we stopped doing that, you know. Ask the nice men in the white outfits to explain it to you if you ever go-outpatient, will you?
The only reason I can think of for a mish-mash of programming language is that you want to be the only person around who can figure it out. I have seen it done quite often in the IT industry. I personally don't agree with it, but it can be a very effective tool for making sure that you don't visit the unemployment office too often.
If that is the case, then mix in everything that you can possibly think of. XML, PHP, Perl, put in some VBScript, maybe even javascript. Learn some Flash and throw that in as well, for some video or splash screen or something. Doesn't really matter what you use it for. If you are using a database backend, and chances are good that you are, don't just use one database. Use a variety of database programs, each with one table. That way you can make tons of database connections in the code and they will all look different. It will leave them guessing for years why you did it that way. (People will usually assume that you had a reason for doing it that way, even if they can't figure out why.) Just as long as the next guy to try and work on it can't figure it out. That way, you can sit by the phone and wait for it to ring.
Now of course, if you are just trying to make an efficient streamlined program, then I would pick PERL as the language and go from there. You may find that PERL doesn't meet all your needs, and you can add in things as needed, but just keep it small. Oh, and don't forget to document everything. Chances are, that unless it is an overly easy application, you aren't going to remember everything.