Re: [PHP] Question
Am 03.11.12 01:30, schrieb Silvio Siefke: > Hello, > > i have compile PHP 5.4.8 on my Debian System. I have before Version 5.4.7. > I delete before all old Files from PHP and then run the commands: > > ./configure --sysconfdir=/usr/local/etc --with-pear --enable-bcmath > --with-bz2=/usr --disable-calendar --enable-ctype --without-curl > --without-curlwrappers --enable-dom --without-enchant --enable-exif > --enable-fileinfo --enable-filter --disable-ftp --with-gettext=/usr > --without-gmp --enable-hash --with-mhash=/usr --with-iconv --disable-intl > --disable-ipv6 --enable-json --without-kerberos --enable-libxml > --with-libxml-dir=/usr --enable-mbstring --with-mcrypt=/usr --without-mssql > --with-onig=/usr --with-openssl=/usr --with-openssl-dir=/usr --disable-pcntl > --enable-phar --enable-pdo --without-pgsql --enable-posix --with-pspell=/usr > --without-recode --enable-simplexml --disable-shmop --without-snmp > --enable-soap > --enable-sockets --with-sqlite3=/usr --without-sybase-ct --disable-sysvmsg > --disable-sysvsem --disable-sysvshm --without-tidy --enable-tokenizer > --disable-wddx --enable-xml --disable-xmlreader --disable-xmlwriter > --without-xmlrpc --without-xsl --enable-zip --with-zlib=/usr --disable-debug > --without-cdb --disable-flatfile --disable-inifile --without-qdbm > --with-freetype-dir=/usr --with-t1lib=/usr --disable-gd-jis-conv > --with-jpeg-dir=/usr --with-png-dir=/usr --without-xpm-dir --with-gd > --with-imap=/usr --with-imap-ssl=/usr --with-mysql=/usr > --with-mysqli=/usr/bin/mysql_config --without-pdo-dblib --with-pdo-mysql=/usr > --without-pdo-pgsql --with-pdo-sqlite=/usr --without-pdo-odbc > --with-readline=/usr > --without-libedit --without-mm --with-pcre-regex=/usr --with-pcre-dir=/usr > --disable-embed --disable-cli --disable-cgi --enable-fpm --without-apxs2 > --with-kerberos > > make -j3 ; make install > > But when i look in the directorys i miss pear and the php-cgi. > > root:/usr/local/src/php-5.4.8# ls /usr/local/bin > php-config phpize > > root:/usr/local/src/php-5.4.8# ls /usr/local/sbin > php-fpm > > Must under bin not be php-cgi and pear, or is my thinking wrong? maybe because of --disable-cgi > > > Thank you for help and Greetings > Silvio > -- Marco Behnke Dipl. Informatiker (FH), SAE Audio Engineer Diploma Zend Certified Engineer PHP 5.3 Tel.: 0174 / 9722336 e-Mail: ma...@behnke.biz Softwaretechnik Behnke Heinrich-Heine-Str. 7D 21218 Seevetal http://www.behnke.biz signature.asc Description: OpenPGP digital signature
[PHP] Java guru?
Hi gang: Anyone here a Java guru? If so, please contact me privately -- I have a question. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Multithreading for OOP PHP
> As far as php side goes, it's a
> problem of design of the apps. Just because people decided to go through
> hoops to use the threaded model doesn't mean that it is any faster than
> writing to the same thing in event driven model, event driven way is
> sometimes much faster than threads.
I'm on both sides of the fence on this one. Imagine the database
operation (not necessarily a SELECT statement) that could take an
arbitrarily long time to complete. PHP should be able to hand that off
to another thread and be done with it:
$dbOpertation = dbThread($sql)
$dbOpertation->start();
Currently, we've got to to write an alternative file dbOperation.php
and call it via exec(), complete with shell-escaping arguments and all
the dangers that go with that:
exec('dbOperation.php'.escapeshellarg($sql));
Now who knows what escapeshellarg() will do to my precious
hand-crafted SQL so I'll have to debug and test that as well. Wait
until you see what that does to your single quotes, and you are in a
world of hurt if your SQL contains literals that also happen to
contain escaped quotes. I don't even know what other characters
escapeshellarg() will mungle, it is not mentioned in the fine manual
so I can either go read the source or start experimenting. And I
happen to be a hobbiest sysadmin, what happens to the poor PHP dev who
doesn't even quite understand the shell or think to escape the
arguments. The prevalence of PDO for simple queries even further
removes many (novice) PHP devs from thoughts of escaping
> Don't blame the language, blame the
> poor dev who made it harder on themselves... There are plenty of big and
> well performing systems online that pull data from many a locations on the
> back end and still manage to serve it to you in less than 2 hundredth of a
> second without the need for threading server side code. That's because they
> are designed well and implemented well as a system.
That is either naive or trolling. You either know very well that some
database operation cannot be completed in n/100 of a second, and we
haven't even started to talk about curl or other potentially
long-running operations.
> Finally another thing to consider is how the operating systems deal with
> high amounts of threads, how different architectures deal with them, while
> Linux is pretty good about threads, other systems have significant
> problems. Php is meant to run on all of them so you choose the model that
> works for all.
I see. Due to a Windows deficiency my PHP-on-*Nix code should suffer.
Are you not aware that some PHP features are available on some OS but
not others? Or that function differently by OS? Seriously, it looks
like you are trolling.
> Lastly I am sorry, but massively parallel architecture for general
> computing is still about 10 years out. That's where parallel processing
> design will be bore efficient and beneficial. When we have that, and
> programmers learn massively parallel design, maybe then we will have a need
> for parallel php (pphp?) for now, there is no need, only poor design.
What? i don't know what you mean by "massively parallel architecture"
but it certainly has no relevancy to the PHP dev who wants to run a
long SQL query.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Multithreading for OOP PHP
Threading doesn't increase complexity? Spoken truly like somebody who has not had to actually write, test and debug proper, high performance threaded code. Please tell me how threading doesn't increase complexity of any data structure? I may agree if you talk about php running in cli, but then the very choice of using php is arguable, you want to thread your console apps, write them in a language that is threaded. That once again brings up the point that that is not the market that is meant to be addressed. As far as your phone goes, again why would you want to run even more threads, if you have 24 threads on your system, you will configure Apache to run 24 threads, each of you which will serve a request in parallel which will make your server capable of handling significant load. As far as php side goes, it's a problem of design of the apps. Just because people decided to go through hoops to use the threaded model doesn't mean that it is any faster than writing to the same thing in event driven model, event driven way is sometimes much faster than threads. Don't blame the language, blame the poor dev who made it harder on themselves... There are plenty of big and well performing systems online that pull data from many a locations on the back end and still manage to serve it to you in less than 2 hundredth of a second without the need for threading server side code. That's because they are designed well and implemented well as a system. Finally another thing to consider is how the operating systems deal with high amounts of threads, how different architectures deal with them, while Linux is pretty good about threads, other systems have significant problems. Php is meant to run on all of them so you choose the model that works for all. Lastly I am sorry, but massively parallel architecture for general computing is still about 10 years out. That's where parallel processing design will be bore efficient and beneficial. When we have that, and programmers learn massively parallel design, maybe then we will have a need for parallel php (pphp?) for now, there is no need, only poor design.
Re: [PHP] Creating an Advanced Form
Op 3 nov. 2012 02:12 schreef "tamouse mailing lists" < tamouse.li...@gmail.com> het volgende: > > I'm sorry. This code just makes me weep. > > Let's just take a quick look at this line here: > > > $rsSearch = mysql_query($sqlSearch); > > You have not supplied a database connection, so mysql_query will fail. > Further, you have not even checked the result to *see* if it failed. Have you ever used mysql in this form? It works perfectly. Having something like or die(mysl_error()); is recommended, atleast for debugging, not for production where you should check the return value and silently fail. - Matijn
Re: [PHP] Re: Multithreading for OOP PHP
On 31/10/2012 13:46, Alex Nikitin wrote: Hey guys (and/or gals), I have heard this question entirely too many times, I think at some point Rasmus just stopped responding to it. The real reason that PHP is not threaded has nothing to do with PHP internal or extension thread safety, the reason is more to the extent that it doesn't make sense to add threading to PHP, it will only increase code and model complexity and create more points of failure, but again the reason is not this, the reason is that it doesn't make sense in PHP's native environment to add threading in the first place. Natively PHP is summoned by a web server, yes you can call PHP in CLI, but that's not it's point market, PHP is first and foremost a server-side language for the web and it is ran by a web server such as Apache or Nginx or IIS(i wouldn't know why you would use IIS, but it could be). All of these web servers (maybe with exception of IIS, i wouldn't know) work pretty much on the same principal, you have the main process that spawns a bunch of worker threads (this is adjustable in configuration, but is typically 1 per cpu thread). These threads are what actually process the requests and call PHP, meaning that if multiple threads are processing multiple requests, multiple instances of PHP will be called. This is why adding threading to PHP makes absolutely no sense, why would you spawn threads in something that is already being called by a thread? Don't get me wrong, threads spawning other threads is a solution, but it is a solution on massively parallel architectures, such as the GPGPUs that can handle over a thousand threads, and it is a solution for an entirely different problem, namely costly conditional statements; PHP on the other hand runs on a general purpose processor that already cache thrashes and runs into issues with instruction pipelines in parallel execution, adding more threads to it would do nothing for performance (or make it worse), make for more complex code and introduce new issues, like for example how do you test threaded code, debugging, messaging, etc, which will introduce new places where php apps fail, new security concerns, etc, and I think we are far from having current issues fixed... Want to parallelize your PHP execution? Learn to love curl_multi :) In this case, fix the program, not the programming language. Just my $0.02 -- Alex -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray You're very wrong. Adding threading doesn't increase complexity at all, the fact is, that people are coming up with horrible ways to execute what they should be executing in threads. It's 2012, my mobile phone has a dual core processor !! All that adding threading does is allow those people bending over backwards - using horrible hacks just to do two things at once - to do things properly. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
