[32619] in Perl-Users-Digest
Perl-Users Digest, Issue: 3893 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 6 16:09:20 2013
Date: Wed, 6 Mar 2013 13:09:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 6 Mar 2013 Volume: 11 Number: 3893
Today's topics:
Re: getting perl and php to talk to each other, was Re <tnp@invalid.invalid>
Re: getting perl and php to talk to each other <ben@morrow.me.uk>
Re: getting perl and php to talk to each other <PointedEars@web.de>
Re: getting perl and php to talk to each other <jstucklex@attglobal.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 05 Mar 2013 19:20:08 +0000
From: The Natural Philosopher <tnp@invalid.invalid>
Subject: Re: getting perl and php to talk to each other, was Re: randomly sorting files in php
Message-Id: <kh5gh5$jp4$2@news.albasani.net>
On 05/03/13 18:43, M. Strobel wrote:
> Am 05.03.2013 10:19, schrieb Cal Dershowitz:
>>
>> This article has me convinced that I want perl and php able to deal with each other:
>>
>> http://www.linuxjournal.com/article/9282?page=0,1
>>
>
> Why not instantiate a Lua interpreter in perl? Or Ruby? And the picture on the
> provided links show _who_ is doing that.
>
> Now, seriously, this is of limited use.
>
> /Str.
>
I am sure there is a huge market for anything that can translate between
Gaelic and Linear B.
Someone told me so, when they were trying to raise the capital:-)
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
------------------------------
Date: Tue, 5 Mar 2013 22:06:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: getting perl and php to talk to each other
Message-Id: <sr6i0a-mdq1.ln1@anubis.morrow.me.uk>
Quoth Cal Dershowitz <cal@example.invalid>:
> [x-posted to clp.misc]
[...]
>
> This article has me convinced that I want perl and php able to deal with
> each other:
>
> http://www.linuxjournal.com/article/9282?page=0,1
Why on Earth would you want to do that? Seriously, I can't think of any
situation where mixing PHP and Perl is easier than just writing in Perl
in the first place.
Note that the Perl in that article (or at least, the first page, which
was all I read) is pretty bad:
- use of global filehandles, unnecessary since 2000,
- use of Thread.pm, deprecated since 2002,
- use of threads at all for such a trivial problem,
- using rindex and substr rather than pattern matching,
- using backticks instead of system(),
- using PHP to talk to a database, when Perl's DBI module is
considerably better than PHP's rather random database functions.
I don't know PHP well enough to comment on it, but I wouldn't be
surprised if the PHP code was just as bad (for instance, I understand
PHP has a saner database interface these days; I don't know if it
existed in 2007, though).
> so far so good, and then this thing which I've seen in the literature:
>
> using php_config 'php-config'
> Can't exec "php-config": No such file or directory at Makefile.PL line 55.
> Failed to find the 'php-config' executable. Make sure you have PHP and
> PHP sources installed, and that 'php-config' is in PATH. at Makefile.PL
> line 55.
> ...
>
> bla bla bla do not pass Go. Right now I have a default installation.
>
> Simple question: What types of things can I get configured with
> php-config? envelope data available? ftp data?
php-config is a program installed with php, which tells other programs
how php was installed. For instance, on my system
~% php-config --libs
-lcrypt -lcrypt -lpcre -lm -lxml2 -lz -liconv -lm -lcrypt -lcrypt
~% php-config --includes
-I/usr/local/include/php -I/usr/local/include/php/main
-I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend
-I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib
~%
and so on. If you've installed php properly (including any required
development packages, if you're using a package system), you should have
a php-config executable somewhere. Make sure it's in your PATH before
running Makefile.PL.
Ben
------------------------------
Date: Wed, 06 Mar 2013 00:20:57 +0100
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Subject: Re: getting perl and php to talk to each other
Message-Id: <2933000.lxfid8jaWL@PointedEars.de>
[X-Post & F'up2 comp.lang.php; please do not X-Post without F'up2]
Ben Morrow wrote:
> Quoth Cal Dershowitz <cal@example.invalid>:
>> [x-posted to clp.misc]
> [...]
>>
>> This article has me convinced that I want perl and php able to deal with
>> each other:
>>
>> http://www.linuxjournal.com/article/9282?page=0,1
>
> Why on Earth would you want to do that? Seriously, I can't think of any
> situation where mixing PHP and Perl is easier than just writing in Perl
> in the first place.
Other people would say the same about writing PHP instead of a mix.
However, there can be value in two programming languages in the same
program. Just consider what kinds of data you can pass via the command
line and what kinds you cannot pass that way (yes, there are text files,
named pipes, and other equally ugly workarounds).
> Note that the Perl in that article (or at least, the first page, which
> was all I read) is pretty bad:
>
> […]
> - using PHP to talk to a database, when Perl's DBI module is
> considerably better than PHP's rather random database functions.
>
> I don't know PHP well enough to comment on it,
Yet you did, which shows that you have never used PHP Data Objects (PDO).
“*Random* database functions”? IBTD.
> but I wouldn't be surprised if the PHP code was just as bad (for instance,
> I understand PHP has a saner database interface these days; I don't know
> if it existed in 2007, though).
It did; for example, “PDO [shipped] with PHP 5.1”, “[r]eleased: 24 Nov
2005”, which is not that hard to find out:
<http://www.php.net/manual/en/intro.pdo.php>
<http://www.php.net/releases/>
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>
------------------------------
Date: Tue, 05 Mar 2013 20:08:03 -0500
From: Jerry Stuckle <jstucklex@attglobal.net>
Subject: Re: getting perl and php to talk to each other
Message-Id: <kh64r2$fa4$1@dont-email.me>
On 3/5/2013 6:59 PM, Ben Morrow wrote:
>
> Quoth Thomas 'PointedEars' Lahn <php@PointedEars.de>:
>> [X-Post & F'up2 comp.lang.php; please do not X-Post without F'up2]
>
> OK. As such I won't see any replies.
>
Don't worry about Pointed Head. He's a well known troll in several
newsgroups.
<snip>
>>> Why on Earth would you want to do that? Seriously, I can't think of any
>>> situation where mixing PHP and Perl is easier than just writing in Perl
>>> in the first place.
>>
>> Other people would say the same about writing PHP instead of a mix.
>
> Yes, of course.
>
A long shot - maybe you have a package in one language you need to feed
input to. But that input must first be processed by a package in the
other language. Rather than rewrite everything, merge them together.
Or, perhaps you need to build the data preprocessor, and aren't familiar
with the language the package is written in.
I agree it would be quite rare, but it's about the only reason I could
think of people would need both languages. I'm sure there are more, though.
>> However, there can be value in two programming languages in the same
>> program. Just consider what kinds of data you can pass via the command
>> line and what kinds you cannot pass that way (yes, there are text files,
>> named pipes, and other equally ugly workarounds).
>
> The methods used by PHP::Interpreter are not really any less ugly. Until
> you get to the point of being able to run the two languages on the same
> VM with properly interworking data structures (such as Parrot is trying
> to achieve, for instance) I don't see much point stuffing the two
> languages into the same process and then just passing strings to eval
> back and forth.
>
I doubt that they'll ever have internetworking data structures, though.
Just not a need for it.
>>> Note that the Perl in that article (or at least, the first page, which
>>> was all I read) is pretty bad:
>>>
>>> […]
>>> - using PHP to talk to a database, when Perl's DBI module is
>>> considerably better than PHP's rather random database functions.
>>>
>>> I don't know PHP well enough to comment on it,
>>
>> Yet you did, which shows that you have never used PHP Data Objects (PDO).
>> “*Random* database functions”? IBTD.
>
> I have not. The database functions used in the article referenced were
> mssql_connect and so on, which last time I used PHP (a long time ago)
> was all there was. I don't think you can deny that *those* functions
> (and the equivalent set for other databases) are a nasty mess. I tried
> to make it clear that I understand the state of the PHP art has improved
> since then.
>
> My major point was that I don't see any good reason to call into PHP
> just to connect to a database, when Perl already has perfectly good
> database code. Had the example been written the other way around the
> equivalent point could of course have been made about calling into Perl.
>
I agree with both of your points. Both languages have reasonable means
of accessing data. I don't think there are any databases one language
can access but not the other.
However, I wouldn't call those functions a "nasty mess". But then I was
writing C code > 25 years ago, and these are just wrappers around C
functions. And while there are other ways such as PDO, they also
typically add an extra layer of overhead. In a busy system, this may or
may not be important. However, if the system is that busy, I wouldn't
be switching back and forth between languages, either.
>>> but I wouldn't be surprised if the PHP code was just as bad (for instance,
>>> I understand PHP has a saner database interface these days; I don't know
>>> if it existed in 2007, though).
>>
>> It did; for example, “PDO [shipped] with PHP 5.1”, “[r]eleased: 24 Nov
>> 2005”, which is not that hard to find out:
>
> Not that hard had I been interested, which I'm not, and had I known
> 'PDO' was the term to look for, which I didn't. (I was actually thinking
> of the PEAR DB module, which I've observed is a thing that exists.
> Again, I've no idea if this is the currently-recommended database
> interface, or how it compares with the Perl DBI.)
>
> Ben
>
I wouldn't have bothered looking up when a Perl module was shipped, either.
BTW - comp.lang.perl.misc added back since this is about both languages.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3893
***************************************
