date:20100325


Rene Veerman wrote:

+1 for top-posting..

proper nettiquette is to put replies beneath the quotes you're
replying to, and deleting the rest.

ultimately this 'rule' of bottomposting is laziness of the ones who
like that style of quoting.
they want everyone to conform to their favorite method, so they can
read more efficiently.


Adherence to standards generally makes lives easier. Since the 
netiquette document likely pre-dates your cognitive awareness of the 
Internet, I think you're in poor company to ignore it. Iconoclasm can be 
a fun lifestyle, but sometimes iconoclasts are just pricks.


Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.


Robert Cummings wrote:

Rene Veerman wrote:

+1 for top-posting..

-1 to compensate .


proper nettiquette is to put replies beneath the quotes you're
replying to, and deleting the rest.

ultimately this 'rule' of bottomposting is laziness of the ones who
like that style of quoting.
they want everyone to conform to their favorite method, so they can
read more efficiently.


Lists have their own rules for consistency. It is simply discourteous not to 
follow those rules just because you do not like them.



Adherence to standards generally makes lives easier. Since the
netiquette document likely pre-dates your cognitive awareness of the
Internet, I think you're in poor company to ignore it. Iconoclasm can be
a fun lifestyle, but sometimes iconoclasts are just pricks.


I would have no problem with top posters if they BOTHERED to actual read what 
they ARE quoting. Have a look at some of the threads on the likes of yahoogroups 
where every copy of the advertising is included in the reply. Here is not quite 
so bad, although the security mesages included with some sigs add to the noise.


We have lost the best FUD from Daevid ...

That bottom posting crap is so antiquated and outdated my dinosaur doesn't
even follow it.


BOTH methods have been around as long as one another and BOTH have a place if 
used properly. As far as *I* am concerned, top posters should have 'autoquote' 
simply switched off! And YES bottom posters should kill the quoting if only 
including a 'me to' line!


What is really needed is a GOOD email client that does a proper job ( including 
replying to the list automatically to get around the other anoyance of having to 
'reply all' on lists like this and include several direct addresses - but that 
is another thread! ). I have all of my email correspondence back to 1998 ( and 
some well before that ) filed and search-able so I can go back and check things 
when I need to. Yes 95% is probably crap, and some day I will destroy a few 
folders, but I can scan any thread and see what has gone on, so I only need 
appropriate quoting - INLINE!


Rule one should be don't include anything AFTER what you have written unless it 
IS actually necessary. Don't quote just because someone may not be following the 
thread.


( And I make no apology for the upper case as I am a dinosaur who found things a 
lot easier with text messages when teletype machines added lower case characters 
:) In those days NOTHING unnecessary was included )


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading? - vote.


Daevid Vincent wrote:

Why don't you set up a vote to see how many developers actually *want*
threading. That would be a good indication of whether or not it is
actually worth the PHP development team spending a lot of
time on it at the loss of other features which people want more.


I already did that with the initial post!

http://www.rapidpoll.net/show.aspx?id=awp1ocy

And so far, as I expected, the majority is for threading.


The majority have not voted yet ;)
Although I don not classify 'thread safe' as the same thing as 'provide 
threading' so the poll is already skewed.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Will PHP ever grow up and have threading?

Daevid Vincent wrote:

 Well, since I was the one that started this shit-storm, I'll chime in
 for a minute... ;-)
 
 If you added threading to the bag of tricks it already has, you're
 getting into areas that make it more difficult to pick up for
 beginners (and that's not to mention the technical elements involved
 in actually adding threading to PHP) Currently the only other 'easy'
 language I know for  beginners is ColdFusion, and that's just
 horrible. You wouldn't want to be responsible for sending the newbies
 down that path would you?! :p 
 
 I'm sorry. I didn't realize PHP was designed for beginers.
 

There is something about the entire environment that makes coding PHP
for a webpage attractive to beginners.  The runtime is your
web-browser, you don't need to compile anything, you just edit, and hit
F5. Combine that with weak typing and an easy syntax, and you've got
something that is easy to pick up. 

Contrast that with perhaps Java and j2ee, a language and a framework
often used in large, long term projects with long life expectancies -
not really a beginners sandbox.

 You all think to shallow and narrow minded. You keep thinking in terms
 of using PHP as simply a web language. You need to think in terms of
 using it like Perl, Python, Ruby, Java, C/++, etc. Computers do a lot
 more than just spit out web pages these days. I know most of you seem
 to only think in terms of the cloud and other stupid technologies
 like that, but there's a great big world of computing that doesn't.
 There's no reason that PHP shouldn't be a viable language to use in
 those arenas either.

PHP is perfectly viable for those areas today.  I wouldn't personally
use it for anything non-web unless it is less than 1000 lines.  My
experience has taught me not to (not just PHP, any script language).

 Spot on again. I have maybe 12 YEARS of PHP expertise, knowledge,
 libraries, tools, code snippets, etc that are battle tested and
 hardened and improved constantly. Now I'd have to toss all that out
 just to write some things in a language that has threading --
 something that is a given in most EVERY other language.

Actually, most don't have it built-in, it usually comes in separate
libraries and is an operating-system feature, not a language feature.
Two notable exceptions I can think of are Ada and PL/1. 


-- 
Per Jessen, Zürich (11.4°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Will PHP ever grow up and have threading?

2010-03-25 Thread Hans Åhlin

MvH / Hans Åhlin
Tel: +46761488019
http://www.kronan-net.com/
irc://irc.freenode.net:6667 - TheCoin



2010/3/25 Rene Veerman rene7...@gmail.com:
 On Thu, Mar 25, 2010 at 6:13 AM, Hans Åhlin ahlin.h...@kronan-net.com wrote:
I admit that if there were native support for threading I
 would use it. But I don´t want the support for threading if it
 slowdown the performance.

 hmm i bet you can use any feature of php to slow things down..

 i think what's been proven by the pro-camp by now is that at least
 some application designs would benefit from threading and shared
 memory.

 imo there's no way to tell up front if threading will be detrimental
 or benefitial to all projects built with php.
 itsa case-by-case thing... aint it?

The problem as I understand it, is that the whole language would be affected,
and project that doesn't use shared memory and/or threading is going
to be affected negatively.
But if there is some way to implement threading and shared memory
without the side effects and keeping the security that php provide to
day, and with the resources that the project have. Then i'm totally
for it.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Will PHP ever grow up and have threading?

Tommy Pham wrote:

 I think you're missing my point.  Given your current hardware,
 software, product list, etc... how long does it take to run your
 queries in series?  If you were able to run them in parallel and
 deliver faster response time to the users, would you implement PHP
 thread, if it's available?

I mentioned it yesterday, but perhaps you overlooked it - the mysqlnd
driver supports asynchronous queries.  If you really have an issue with
the elapse time of sequential, but independent database queries,
executing them asynchronously is the obvious solution.  (apart from
tuning the database, but I'm assuming you've already been there).


-- 
Per Jessen, Zürich (11.9°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Tommy Pham wrote:

 As such, let's dissect what you mentioned:
 
 1) PHP with internal thread support
 2) PHP with external C/C++ thread support

That's not quite what I mentioned, but I'll accept it for the sake of
argument. 

 * Performance - having external thread support, now you have to call
 an extension (more memory usage and CPU cycles). 

Tommy, you are already using millions of more cycles by running PHP
instead of C.  It's a reasonable trade-off of course, but using more
cycles is not a valid counter-argument. 

 If you happen to have a C/C++ guru who can then code that thread
 support into PHP extension, wouldn't it still perform better at the
 core vs as an extension because it's not talking to a 'middle man'? 

It's another trade-off Tommy - you run two separate processes, talking
to each other over TCP (for instance) to gain 1) performance and 2)
flexibility/scalability.  You gain performance by having processes that
can be independently scheduled by the OS, and you gain flexibility by
being able to move a process to another box (for scalability). You pay
for that with a few thousand cycles.  When you decide to use a database
(e.g. mysql) you also make a trade-off - well-managed data, a
structured query-language and some overhead vs. doing it all in your
own code. 

 * Portability - if you're currently running PHP on Windows, but manage
 to convince management to switch to *BSD/Linux, then you'd have to
 rewrite that external thread support. 

If portability is a concern, I'd make sure my threaded backend would run
on all the platforms I could envision.  Portability is merely one of
many factors that affect choice of programming language. 

 * Managability - should your need to upgrade PHP for either bug fix,
 new features you'd want to implement to add more functionality to your
 site, will that then break your custom external solution?  How much
 more manageable is it if it's done under 1 language versus 2+?

I said it yesterday already - having a single implementation language IS
a positive, but it may not always be possible due to requirements. 



-- 
Per Jessen, Zürich (12.3°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Tommy Pham wrote:

  I don't
 use Linux nor an expert in it but implementing custom thread solution
 like that means understanding about SELinux vs AppArmor vs Grsecurity
 or am I wrong? 

Yes, you are wrong.  The Posix thread model implemented in the pthread
library in Linux is easy to pick up for anyone who has studied computer
science - where he or she will already have been introduced to mutexes,
semaphores, the Dining Philosophers, race conditions, deadlocks and
such. 



-- 
Per Jessen, Zürich (12.6°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Tommy Pham wrote:

 As some of you mention that implementing threads will make the DB work
 harder than the standard serial operations queries, let me ask you
 these then:
 
 * How often does your DB server(s)/cluster utilizes 100% CPU (SMP/MC),
 memory, and disk IO?

Assuming we're talking under heavy load - my database server is an
old(ish) HP Proliant ML570 - 4 x 3GHz Xeons with HT, dual U320 SCSI
busses, 48GB RAM :

CPU 100% - rarely, but it happens.
Memory 100% - all the time. 
Disk IO 100% - less than all the time, but it's very busy.

 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak? 

Use mysqlnd - asynchronous mysql queries.

 (I remember a list member, not mentioning his name, does optimization
 of PHP coding for just microseconds.  Do you think how much more he'd
 benefit from this?)

Anyone who optimizes PHP for microseconds has lost touch with reality -
or at least forgotten that he or she is using an interpreted language.

 * If the requests are executed in parallel, the sooner the request
 fulfillment completes, the faster it is to move to the next request
 and complete it right?

Correct. 


-- 
Per Jessen, Zürich (12.7°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Per Jessen wrote:

 CPU 100% - rarely, but it happens.
 Memory 100% - all the time.
 Disk IO 100% - less than all the time, but it's very busy.

FYI, it's actually quite difficult to drive a disk subsystem to
consistent 100% utilization over a period of time.  Oracle uses
asynchronous I/O and could probably drive a disk subsystem quite hard,
but AFAIK, mysql doesn't.


-- 
Per Jessen, Zürich (13.9°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Daniel Egeberg

On Thu, Mar 25, 2010 at 07:28, Rene Veerman rene7...@gmail.com wrote:
 +1 for top-posting..

 proper nettiquette is to put replies beneath the quotes you're
 replying to, and deleting the rest.

So why are you not doing it?

 ultimately this 'rule' of bottomposting is laziness of the ones who
 like that style of quoting.
 they want everyone to conform to their favorite method, so they can
 read more efficiently.

It's not laziness. It's just easier reading from top to bottom than
having to jump around in the text like you have to when people are top
posting.

On the contrary, I would say it's more lazy just dumping the entire
email you're replying to on the bottom without trimming things that
are irrelevant to your reply, advertisements (die Hotmail!), mailing
list footers, signatures, etc.

 however, given that this is a tips-list, i'd like this bottom posting
 rule removed from the mailinglist rules.
 it's been used yesterday as a way to attack me on a second front
 during a heated debate about the future evolution of php
 (threading+shared-mem).. up until yesterday, nobody complained about
 my top-posting, because the tips i give are apparently considered
 useful.

 And thats the point eh? The quality of the tips?

The point is that it's easier to read correspondence when things are
formatted properly with *inline* quoting. This becomes even more
important on mailing lists where there are multiple participants, and
on threads like the one you are referring to that is now up to 228
replies.

 Seriously, programmers who are not flexible enough to accept tips in a
 top _or_ bottom _or_ mixed format
 It sounds really silly to me.

It has nothing to do with flexibility. It's easier reading inline
posted replies than top posted replies. That's how quoting works all
other places as well. It also makes it easier to address multiple
points in an email when you are inline posting. It's very clear what
you are referring to.

Any proper client will differentiate visually between quotes and and
non-quotes, so if you can remember *all* the emails in the thread you
can just skip over the quotes.

 Pushing all other humans to use your habits is silly when you can code
 an addon for any email program that puts things in the right order.

Sorry, that's just ridiculous. Why should we code a plugin that fixes
your emails to put them in the right order when you can just do it
from the start? You're even acknowledging that you're posting in the
wrong order now.

-- 
Daniel Egeberg

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Robert P. J. Day

On Thu, 25 Mar 2010, Rene Veerman wrote:

 +1 for top-posting..

  *sigh*.  you're joking, right?  you're seriously telling me that
there are people who are still sufficiently ignorant and childish that
they're still fighting this top- versus bottom-posting war?

  the war is over.  the consensus is that bottom-posting, accompanied
by sufficient trimming of extraneous material, is the norm.  it's
accepted.  it's documented.  it's the standard.  if you can't deal
with that, then i suggest you find another medium for communication.

  honestly, i can't take another one of these idiotic top- versus
bottom-posting debates.  while this mailing list has been immensely
useful so far, i'm unsubscribing.  when the whiny children on this
list have either grown up or moved on, let me know.  life is too short
to fight these same bullshit battles over and over again.

rday
--


Robert P. J. Day   Waterloo, Ontario, CANADA

Linux Consulting, Training and Kernel Pedantry.

Web page:  http://crashcourse.ca
Twitter:   http://twitter.com/rpjday


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP]Zip and text files generated are corrupted

2010-03-25 Thread Bastien Helders

So I tested two scenario:

- First, I gather all the files selected for the patch and then compress
them together and here is what is displayed:

[Begin display]
The command zip -gr ../../build/Patch-6-3-2_Q3P15.zip * returned a status of
14 and the following output:
adding: bin/ (stored 0%)
adding: bin/startHotFixInstaller.bat (deflated 41%)
adding: bin/startHotFixInstaller.sh (deflated 49%)
adding: software/ (stored 0%)
adding: software/hotfixes/ (stored 0%)
[snip]

bWarning/b:
rename(build/Patch-6-3-2_Q3P15.zip,P:/Path_For_Deposit/Patch-6-3-2_Q3P15/Patch-6-3-2_Q3P15.zip)
[function.rename]: No such file or directory
[End display]

I know that the rename didn't work, while the zip command aborted and
generated no zip file.
There is no problem with the README text file.

- Second scenario, I take the previous patch, compare the list of folders in
the previous patch with list of selected folder, add the folders not in the
previous patch and eventually remove folders that weren't selected but were
in the previous patch.

In this case, all the commands, may it be of the type
zip -gr ../../build/Patch-6-3-2_Q3P15.zip
software/hotfixes/hfFolder/HF-632Q3-152/* to add a folder or zip -d
build/Patch-6-3-2_Q3P15.zip software/hotfixes/hfFolder/HF-632Q3-127\* to
delete an unwanted folder returns all with status 2 and no output.

2010/3/24 Richard Quadling rquadl...@googlemail.com

On 24 March 2010 15:19, Bastien Helders eldroskan...@gmail.com wrote:
Hi Ashley,

No, I set the time limit high enough (set_time_limit(2*HOUR+8*MINUTE);),
and
the execution stops a long time before the time limit is reached.

It might be relevent that the web application is hosted on a Windows
Machine.

I asked myself, would setting the parameter memory_limit of the php.ini
file to a higher value help? Actually it is set to 128M. But I actually
don't have problems with creating a zip archive of about 250M (~80
folders),
it actually occurs with 3 times bigger archives.

Best Regards,
Bastien

2010/3/24 Ashley Sheridan a...@ashleysheridan.co.uk

On Wed, 2010-03-24 at 15:34 +0100, Bastien Helders wrote:

Hi list,

I've got this web app, which from a list of selected folders (with
content)
want to create a zip containing them as well as creating a text file
with
information about the chosen folders and how to use them.

To create the zip file I use exec('zip -gr ' .$zipname.' *
mylog.log');
in the temporary folder where I gathered all the data (using a
zipArchive
object was more time consuming). I then create the text file using
fopen,
many fwrites and a fclose.

My problem is the following, normally it creates the archive and text
file
without any problem, but as soon as the number of selected folder has an
high value (let's say about 150 of them), I've got problems with the
generated files: The zip archive doesn't contain all the folders and
there
is an unexpected end of file on both zip and text files.

My guess is, as it takes too much time, the script goes on to the next
operation and close the streams uncleanly. But I can't be sure about
that,
and I don't know where to investigate.

Regards,
Bastien

Is the script maybe running past the max_execution_time before the zip
files are completed?

Thanks,
Ash
http://www.ashleysheridan.co.uk

--
haXe - an open source web programming language
http://haxe.org

Make sure you have ...

error_reporting(-1); // show ALL errors/warnings/notices/etc.

and ...

exec($Command, $Output, $Status); // Capture the output.
echo The $Command returned a status of $Status and the following
output:, PHP_EOL, implode(PHP_EOL, $Output), PHP_EOL;

sort of thing.

The error may be in the zip.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
haXe - an open source web programming language
http://haxe.org

Re: [PHP]Zip and text files generated are corrupted

2010-03-25 Thread Bastien Helders

Forgot to say, it is the second scenario that generate corrupted zip and
text files with unexpected end of files.

2010/3/25 Bastien Helders eldroskan...@gmail.com

 So I tested two scenario:

 - First, I gather all the files selected for the patch and then compress
 them together and here is what is displayed:

 [Begin display]
 The command zip -gr ../../build/Patch-6-3-2_Q3P15.zip * returned a status
 of 14 and the following output:
 adding: bin/ (stored 0%)
 adding: bin/startHotFixInstaller.bat (deflated 41%)
 adding: bin/startHotFixInstaller.sh (deflated 49%)
 adding: software/ (stored 0%)
 adding: software/hotfixes/ (stored 0%)
 [snip]

 br

 bWarning/b:
 rename(build/Patch-6-3-2_Q3P15.zip,P:/Path_For_Deposit/Patch-6-3-2_Q3P15/Patch-6-3-2_Q3P15.zip)
 [function.rename]: No such file or directory
 [End display]

 I know that the rename didn't work, while the zip command aborted and
 generated no zip file.
 There is no problem with the README text file.

 - Second scenario, I take the previous patch, compare the list of folders
 in the previous patch with list of selected folder, add the folders not in
 the previous patch and eventually remove folders that weren't selected but
 were in the previous patch.

 In this case, all the commands, may it be of the type
 zip -gr ../../build/Patch-6-3-2_Q3P15.zip
 software/hotfixes/hfFolder/HF-632Q3-152/* to add a folder or zip -d
 build/Patch-6-3-2_Q3P15.zip software/hotfixes/hfFolder/HF-632Q3-127\* to
 delete an unwanted folder returns all with status 2 and no output.

 2010/3/24 Richard Quadling rquadl...@googlemail.com

 On 24 March 2010 15:19, Bastien Helders eldroskan...@gmail.com wrote:
  Hi Ashley,
 
  No, I set the time limit high enough (set_time_limit(2*HOUR+8*MINUTE);),
 and
  the execution stops a long time before the time limit is reached.
 
  It might be relevent that the web application is hosted on a Windows
  Machine.
 
  I asked myself, would setting the parameter memory_limit of the
 php.ini
  file to a higher value help? Actually it is set to 128M. But I actually
  don't have problems with creating a zip archive of about 250M (~80
 folders),
  it actually occurs with 3 times bigger archives.
 
  Best Regards,
  Bastien
 
  2010/3/24 Ashley Sheridan a...@ashleysheridan.co.uk
 
   On Wed, 2010-03-24 at 15:34 +0100, Bastien Helders wrote:
 
  Hi list,
 
  I've got this web app, which from a list of selected folders (with
 content)
  want to create a zip containing them as well as creating a text file
 with
  information about the chosen folders and how to use them.
 
  To create the zip file I use exec('zip -gr ' .$zipname.' * 
 mylog.log');
  in the temporary folder where I gathered all the data (using a
 zipArchive
  object was more time consuming). I then create the text file using
 fopen,
  many fwrites and a fclose.
 
  My problem is the following, normally it creates the archive and text
 file
  without any problem, but as soon as the number of selected folder has
 an
  high value (let's say about 150 of them), I've got problems with the
  generated files: The zip archive doesn't contain all the folders and
 there
  is an unexpected end of file on both zip and text files.
 
  My guess is, as it takes too much time, the script goes on to the next
  operation and close the streams uncleanly. But I can't be sure about
 that,
  and I don't know where to investigate.
 
  Regards,
  Bastien
 
 
  Is the script maybe running past the max_execution_time before the zip
  files are completed?
 
 
Thanks,
  Ash
  http://www.ashleysheridan.co.uk
 
 
 
 
 
  --
  haXe - an open source web programming language
  http://haxe.org
 


 Make sure you have ...

 error_reporting(-1); // show ALL errors/warnings/notices/etc.

 and ...

 exec($Command, $Output, $Status); // Capture the output.
 echo The $Command returned a status of $Status and the following
 output:, PHP_EOL, implode(PHP_EOL, $Output), PHP_EOL;

 sort of thing.

 The error may be in the zip.
 --
 -
 Richard Quadling
 Standing on the shoulders of some very clever giants!
 EE : http://www.experts-exchange.com/M_248814.html
 EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
 Zend Certified Engineer :
 http://zend.com/zce.php?c=ZEND002498r=213474731
 ZOPA : http://uk.zopa.com/member/RQuadling




 --
 haXe - an open source web programming language
 http://haxe.org




-- 
haXe - an open source web programming language
http://haxe.org

[PHP] Temporary failure in name resolution - fsockopen()

2010-03-25 Thread David Lidstone

We recently para-virtualised a Xen / CentOS box which is running script 
which uses fsockopen() to get a connection to an SMTP server.


Since the server changes it fails approx 50% of the time with:

php_network_getaddresses: getaddrinfo failed: Temporary failure in name 
resolution


We've tried the solutions from Googling this error (such as restarting 
Apache etc), but without success.


Why am I wasting your time with a Linux upgrade issue? Well, 
gethostbyname() seems to resolve the IP every time. Manual lookups on 
from the server seem to work with no problems.


Any help greatly appreciated. Should I perhaps be pointing this out on 
the 'internals' list?


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak?

 Use mysqlnd - asynchronous mysql queries.


You're assuming that everyone in the PHP world uses MySQL 4.1 or
newer.  What about those who don't? Which goes back to being
portability.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak?

 Use mysqlnd - asynchronous mysql queries.

 
 You're assuming that everyone in the PHP world uses MySQL 4.1 or
 newer.  What about those who don't? 

They don't get to use threading, nor asynchronous mysql queries. 

Come on, you're asking about a future feature in PHP 7.x , but would
like to support someone who is seriously backlevel on mysql??


-- 
Per Jessen, Zürich (16.9°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Ashley Sheridan

On Thu, 2010-03-25 at 08:28 +0200, Rene Veerman wrote:


 proper nettiquette is to put replies beneath the quotes you're
 replying to, and deleting the rest.
 
 ultimately this 'rule' of bottomposting is laziness of the ones who
 like that style of quoting.
 they want everyone to conform to their favorite method, so they can
 read more efficiently.

It's not laziness, it's netiquette. There are rules for this mailing
list, and following them helps everyone. You're blatantly ignoring the
rules in an 'I know best attitude again'.

 
 however, given that this is a tips-list, i'd like this bottom posting
 rule removed from the mailinglist rules.
 it's been used yesterday as a way to attack me on a second front
 during a heated debate about the future evolution of php

Not every person who disagrees with you is doing so out of spite to you.
There isn't a secret group of people with a vendetta against you, just
people trying to put their point of view across. The top-vs-bottom
posting isn't an issue that needs to be discussed though. It's been
in-place since the beginning of the list, and for the main, people
conform to it. It's the exceptions that cause problems and make the
threads harder to follow.

What gives you the right to demand it's changed? I've been posting to
the list for well over a year now, and even I wouldn't presume to start
changing rules just because I didn't like them or I was too lazy to
bother with them.


 Seriously, programmers who are not flexible enough to accept tips in a
 top _or_ bottom _or_ mixed format
 It sounds really silly to me.

This list isn't just for programmers. It's for professionals and
beginners alike. Surely it makes sense to make the list as accessible as
possible for people?

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Will PHP ever grow up and have threading?

2010-03-25 Thread Ashley Sheridan

On Thu, 2010-03-25 at 08:11 +0200, Rene Veerman wrote:

 right now my cms is 2D, and indeed most of the graphics are static
 then.
 
 but i have plans to lift it into 3D, with rooms interacting via
 avatars, and then the graphics-selection and avatar-behavior
 (animations) selections alone i suspect will put much extra stress on
 the servers. especially if i have to use sql servers to handle the
 datastreams.


Have you had a look at Papervision? It's about the best thing for 3D on
the web right now, and has even garnered some official Adobe support.


Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Will PHP ever grow up and have threading?

2010-03-25 Thread Rene Veerman

On Thu, Mar 25, 2010 at 12:02 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:

  On Thu, 2010-03-25 at 08:11 +0200, Rene Veerman wrote:

 right now my cms is 2D, and indeed most of the graphics are static then.

 but i have plans to lift it into 3D, with rooms interacting via
 avatars, and then the graphics-selection and avatar-behavior
 (animations) selections alone i suspect will put much extra stress on
 the servers. especially if i have to use sql servers to handle the
 datastreams.


 Have you had a look at Papervision? It's about the best thing for 3D on the
 web right now, and has even garnered some official Adobe support.


yup. papervision, away3d, i've had a look at them.

my current thinking is to build an abstraction layer for 3D in
flashdevelop.org that interfaces with either papervision or away3d.. no
telling which'll be the victor in the end of that race.

but the real reason for me to invest in an extra abstraction layer is those
unlimited detail guys (http://www.youtube.com/watch?v=Q-ATtrImCx4ttl=1)
who are likely to change the entire 3D stack (from graphicscard up).

Re: [PHP] Temporary failure in name resolution - fsockopen()

2010-03-25 Thread Nilesh Govindarajan


On 03/25/2010 03:51 PM, David Lidstone wrote:

We recently para-virtualised a Xen / CentOS box which is running script
which uses fsockopen() to get a connection to an SMTP server.

Since the server changes it fails approx 50% of the time with:

php_network_getaddresses: getaddrinfo failed: Temporary failure in name
resolution

We've tried the solutions from Googling this error (such as restarting
Apache etc), but without success.

Why am I wasting your time with a Linux upgrade issue? Well,
gethostbyname() seems to resolve the IP every time. Manual lookups on
from the server seem to work with no problems.

Any help greatly appreciated. Should I perhaps be pointing this out on
the 'internals' list?



I feel its something do with your DNS settings and/or the server.

If that's not the problem then just as a temp solution add your SMTP 
server's address provided it has a static IP (99.9% it has) to your 
/etc/hosts file.


It should not give trouble then.

--
Nilesh Govindarajan
Site  Server Administrator
www.itech7.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Recommended Books on Object Oriented Programming

 Hi,
 
 I want to properly learn object oriented programming as I've been coding in
 procedural style since I started with PHP a few years ago, and want to give
 OOP a shot. The web isn't really a good resource to learn OOP in PHP to be
 honest, as a lot is outdated for PHP4's style of OOP. I've looked into OOP
 quite a bit and understand the concept of it, and want to take it further.
 Any recommendations appreciated :).

I bought beginning PHP 5 and MySQL E-Commerce from Novice to Professional by 
Christian Darie and beginning php and MySQL E-Commerce from Novice to 
Professional 2nd edition and they have helped me a lot with OO. It's a 
tutorial book that builds an E-Commerce website from start to finish and 
teaches how to build and use SMARTY templates, how to use PEAR and Ajax.

1st edition

http://www.amazon.com/Beginning-PHP-MySQL-E-Commerce-
ebook/dp/B001IKJL38/ref=sr_1_2?ie=UTF8s=digital-textqid=1269518047sr=8-2 

2nd edition

http://www.amazon.com/Beginning-PHP-MySQL-E-Commerce-
Professional/dp/1590598644/ref=sr_1_fkmr1_3?ie=UTF8qid=1269518108sr=8-3-
fkmr1
 
-- 
Blessings
David M.
I have been driven to my knees many times by the overwhelming conviction that 
I had nowhere else to go.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

 On Thu, 2010-03-25 at 08:28 +0200, Rene Veerman wrote:

 
 This list isn't just for programmers. It's for professionals and
 beginners alike. Surely it makes sense to make the list as accessible as
 possible for people?

I am somewhat still a beginner and signed up on this list about 5 days ago, 
hoping I could get some valuable insight from it.

-- 
Blessings
David M.
I have been driven to my knees many times by the overwhelming conviction that 
I had nowhere else to go.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Jay Blanchard

[snip]
...like any good bottom poster should
[/snip]

RTFA's, it has been discussed ad nauseum. Let's get back to PHP.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Floyd Resler

Absolutely top posting is the most efficient way of doing it!  If I  need to 
see what the thread is all about, I have no problems starting from the bottom 
and working my way up.  It would be nice if everyone adopted top posting, 
though.  Trying to read threads where postings are at the top and bottom makes 
it really difficult to follow!

Take care,
Floyd

On Mar 24, 2010, at 9:34 PM, Daevid Vincent wrote:

 ...and where's the stupid little netiquette link about hijacking another
 thread? ;-)
 oh, here it is: 
 http://en.wikipedia.org/wiki/User:DonDiego/Thread_hijacking
 http://linux.sgms-centre.com/misc/netiquette.php#threading
 
 That bottom posting crap is so antiquated and outdated my dinosaur doesn't
 even follow it.
 
 Top posting is efficient and useful for everyone involved in the thread. 
 
 If someone is not smart enough to realize they're reading the end of the
 thread, and have to scroll to the bottom of it one time to catch up, then
 to me that's natural selection and they just don't deserve to be
 participating. Go read a coloring book or watch WoW!Wow!Wubbzy! or
 something equally trite because clearly their brain can't grasp basic
 concepts even.
 
 
  _  
 
 From: Yousif Masoud [mailto:yousif.mas...@gmail.com] 
 Sent: Wednesday, March 24, 2010 6:27 PM
 To: Daevid Vincent
 Cc: php-general@lists.php.net
 Subject: Re: [PHP] Will PHP ever grow up and have threading?
 
 
 
 P.S. I HATE bottom posting. WTF do I have to scroll all the way down past
 hundreds of useless lines just to read a me too or some other comment. If
 it's at the top, I can simply just keep moving from header to header in
 Outlook (or your email GUI of choice). DELETE as I go. Easy. Simple.
 Efficient.
 
 
 
 http://www.netmeister.org/news/learn2quote.html 
 


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?


Per Jessen wrote:

Tommy Pham wrote:


(I remember a list member, not mentioning his name, does optimization
of PHP coding for just microseconds.  Do you think how much more he'd
benefit from this?)


Anyone who optimizes PHP for microseconds has lost touch with reality -
or at least forgotten that he or she is using an interpreted language.


But sometimes it's just plain fun to do it here on the list with 
everyone further optimizing the last optimized snippet :)


Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP]Zip and text files generated are corrupted

2010-03-25 Thread Bastien Helders

I'm really stumped, it seems that although the script is running under the
time limit, if a single instruction such as exec(zip) in the first case,
or copy() in the second case are timing out, because it takes too much time
processing the big file.

Is there any configuration in php.ini (or anywhere else) that I could change
to permit copy() or exec(zip) to run through without being interrupted?

Regards,
Bastien

2010/3/25 Bastien Helders eldroskan...@gmail.com

 Forgot to say, it is the second scenario that generate corrupted zip and
 text files with unexpected end of files.

 2010/3/25 Bastien Helders eldroskan...@gmail.com

 So I tested two scenario:

 - First, I gather all the files selected for the patch and then compress
 them together and here is what is displayed:

 [Begin display]
 The command zip -gr ../../build/Patch-6-3-2_Q3P15.zip * returned a status
 of 14 and the following output:
 adding: bin/ (stored 0%)
 adding: bin/startHotFixInstaller.bat (deflated 41%)
 adding: bin/startHotFixInstaller.sh (deflated 49%)
 adding: software/ (stored 0%)
 adding: software/hotfixes/ (stored 0%)
 [snip]

 br

 bWarning/b:
 rename(build/Patch-6-3-2_Q3P15.zip,P:/Path_For_Deposit/Patch-6-3-2_Q3P15/Patch-6-3-2_Q3P15.zip)
 [function.rename]: No such file or directory
 [End display]

 I know that the rename didn't work, while the zip command aborted and
 generated no zip file.
 There is no problem with the README text file.

 - Second scenario, I take the previous patch, compare the list of folders
 in the previous patch with list of selected folder, add the folders not in
 the previous patch and eventually remove folders that weren't selected but
 were in the previous patch.

 In this case, all the commands, may it be of the type
 zip -gr ../../build/Patch-6-3-2_Q3P15.zip
 software/hotfixes/hfFolder/HF-632Q3-152/* to add a folder or zip -d
 build/Patch-6-3-2_Q3P15.zip software/hotfixes/hfFolder/HF-632Q3-127\* to
 delete an unwanted folder returns all with status 2 and no output.

 2010/3/24 Richard Quadling rquadl...@googlemail.com

 On 24 March 2010 15:19, Bastien Helders eldroskan...@gmail.com wrote:
  Hi Ashley,
 
  No, I set the time limit high enough
 (set_time_limit(2*HOUR+8*MINUTE);), and
  the execution stops a long time before the time limit is reached.
 
  It might be relevent that the web application is hosted on a Windows
  Machine.
 
  I asked myself, would setting the parameter memory_limit of the
 php.ini
  file to a higher value help? Actually it is set to 128M. But I actually
  don't have problems with creating a zip archive of about 250M (~80
 folders),
  it actually occurs with 3 times bigger archives.
 
  Best Regards,
  Bastien
 
  2010/3/24 Ashley Sheridan a...@ashleysheridan.co.uk
 
   On Wed, 2010-03-24 at 15:34 +0100, Bastien Helders wrote:
 
  Hi list,
 
  I've got this web app, which from a list of selected folders (with
 content)
  want to create a zip containing them as well as creating a text file
 with
  information about the chosen folders and how to use them.
 
  To create the zip file I use exec('zip -gr ' .$zipname.' * 
 mylog.log');
  in the temporary folder where I gathered all the data (using a
 zipArchive
  object was more time consuming). I then create the text file using
 fopen,
  many fwrites and a fclose.
 
  My problem is the following, normally it creates the archive and text
 file
  without any problem, but as soon as the number of selected folder has
 an
  high value (let's say about 150 of them), I've got problems with the
  generated files: The zip archive doesn't contain all the folders and
 there
  is an unexpected end of file on both zip and text files.
 
  My guess is, as it takes too much time, the script goes on to the next
  operation and close the streams uncleanly. But I can't be sure about
 that,
  and I don't know where to investigate.
 
  Regards,
  Bastien
 
 
  Is the script maybe running past the max_execution_time before the zip
  files are completed?
 
 
Thanks,
  Ash
  http://www.ashleysheridan.co.uk
 
 
 
 
 
  --
  haXe - an open source web programming language
  http://haxe.org
 


 Make sure you have ...

 error_reporting(-1); // show ALL errors/warnings/notices/etc.

 and ...

 exec($Command, $Output, $Status); // Capture the output.
 echo The $Command returned a status of $Status and the following
 output:, PHP_EOL, implode(PHP_EOL, $Output), PHP_EOL;

 sort of thing.

 The error may be in the zip.
 --
 -
 Richard Quadling
 Standing on the shoulders of some very clever giants!
 EE : http://www.experts-exchange.com/M_248814.html
 EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
 Zend Certified Engineer :
 http://zend.com/zce.php?c=ZEND002498r=213474731
 ZOPA : http://uk.zopa.com/member/RQuadling




 --
 haXe - an open source web programming language
 http://haxe.org




 --
 haXe - an open source web programming language
 http://haxe.org




-- 
haXe - an open source web programming language
http://haxe.org

Re: [PHP] Temporary failure in name resolution - fsockopen()

2010-03-25 Thread David Lidstone


Nilesh Govindarajan wrote:

On 03/25/2010 03:51 PM, David Lidstone wrote:

We recently para-virtualised a Xen / CentOS box which is running script
which uses fsockopen() to get a connection to an SMTP server.

Since the server changes it fails approx 50% of the time with:

php_network_getaddresses: getaddrinfo failed: Temporary failure in name
resolution

We've tried the solutions from Googling this error (such as restarting
Apache etc), but without success.

Why am I wasting your time with a Linux upgrade issue? Well,
gethostbyname() seems to resolve the IP every time. Manual lookups on
from the server seem to work with no problems.

Any help greatly appreciated. Should I perhaps be pointing this out on
the 'internals' list?



I feel its something do with your DNS settings and/or the server.

If that's not the problem then just as a temp solution add your SMTP 
server's address provided it has a static IP (99.9% it has) to your 
/etc/hosts file.


It should not give trouble then.



Thanks for your suggestion Nilesh, but the hosts file would seem to just 
defeat the object of being able to look up DNS addresses.


It is possible to by-pass the issue by using gethostbyname() and just 
passing in the IP, but this is not really a solution (e.g. we regularly 
use a PEAR package which is now effected). The real questions in my mind 
are:


If there is a reliable call to resolve IPs, then what is fsockopen() 
doing which is different? Given the recurrence of this error over the 
last 8 - 9 years, can it be changed to improve reliability, or is this 
just a one-off with our server?


I do agree that it is almost certainly an issue with the server or a 
library being used (me != serverexpert). But what and why and can PHP 
work around this better internally? Thanks again.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.


Floyd Resler wrote:

Absolutely top posting is the most efficient way of doing it!  If I  need to 
see what the thread is all about, I have no problems starting from the bottom 
and working my way up.  It would be nice if everyone adopted top posting, 
though.  Trying to read threads where postings are at the top and bottom makes 
it really difficult to follow!


So you claim, I find that it is most UNPRODUCTIVE!

But as we have already said - the RULE for this list is bottom posting since as 
you rightly say mixing it up is making things even more unproductive. If you 
must campain for a CHANGE to the rules please at least be courteous and follow 
the rules until there IS a consensus to change that rule. But the current 
consensus IS to stop debating it at all and leave the rule in place :)


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP]Zip and text files generated are corrupted

2010-03-25 Thread Mike Roberts

remove





 Sincerely,

 Michael Roberts
Executive Recruiter
 Corporate Staffing Services
 150 Monument Road, Suite 510
 Bala Cynwyd, PA 19004
 P 610-771-1084
 F 610-771-0390
 E mrobe...@jobscss.com
Check out my recent feature article in Professional Surveyor 12/09
edition. 
http://www.profsurv.com/magazine/article.aspx?i=70379






-Original Message-
From: Bastien Helders [mailto:eldroskan...@gmail.com] 
Sent: Thursday, March 25, 2010 9:32 AM
To: rquadl...@googlemail.com
Cc: a...@ashleysheridan.co.uk; php-general@lists.php.net
Subject: Re: [PHP]Zip and text files generated are corrupted

I'm really stumped, it seems that although the script is running under
the
time limit, if a single instruction such as exec(zip) in the first
case,
or copy() in the second case are timing out, because it takes too much
time
processing the big file.

Is there any configuration in php.ini (or anywhere else) that I could
change
to permit copy() or exec(zip) to run through without being
interrupted?

Regards,
Bastien

2010/3/25 Bastien Helders eldroskan...@gmail.com

 Forgot to say, it is the second scenario that generate corrupted zip
and
 text files with unexpected end of files.

 2010/3/25 Bastien Helders eldroskan...@gmail.com

 So I tested two scenario:

 - First, I gather all the files selected for the patch and then
compress
 them together and here is what is displayed:

 [Begin display]
 The command zip -gr ../../build/Patch-6-3-2_Q3P15.zip * returned a
status
 of 14 and the following output:
 adding: bin/ (stored 0%)
 adding: bin/startHotFixInstaller.bat (deflated 41%)
 adding: bin/startHotFixInstaller.sh (deflated 49%)
 adding: software/ (stored 0%)
 adding: software/hotfixes/ (stored 0%)
 [snip]

 br

 bWarning/b:

rename(build/Patch-6-3-2_Q3P15.zip,P:/Path_For_Deposit/Patch-6-3-2_Q3P15
/Patch-6-3-2_Q3P15.zip)
 [function.rename]: No such file or directory
 [End display]

 I know that the rename didn't work, while the zip command aborted and
 generated no zip file.
 There is no problem with the README text file.

 - Second scenario, I take the previous patch, compare the list of
folders
 in the previous patch with list of selected folder, add the folders
not in
 the previous patch and eventually remove folders that weren't
selected but
 were in the previous patch.

 In this case, all the commands, may it be of the type
 zip -gr ../../build/Patch-6-3-2_Q3P15.zip
 software/hotfixes/hfFolder/HF-632Q3-152/* to add a folder or zip -d
 build/Patch-6-3-2_Q3P15.zip
software/hotfixes/hfFolder/HF-632Q3-127\* to
 delete an unwanted folder returns all with status 2 and no output.

 2010/3/24 Richard Quadling rquadl...@googlemail.com

 On 24 March 2010 15:19, Bastien Helders eldroskan...@gmail.com
wrote:
  Hi Ashley,
 
  No, I set the time limit high enough
 (set_time_limit(2*HOUR+8*MINUTE);), and
  the execution stops a long time before the time limit is reached.
 
  It might be relevent that the web application is hosted on a
Windows
  Machine.
 
  I asked myself, would setting the parameter memory_limit of the
 php.ini
  file to a higher value help? Actually it is set to 128M. But I
actually
  don't have problems with creating a zip archive of about 250M (~80
 folders),
  it actually occurs with 3 times bigger archives.
 
  Best Regards,
  Bastien
 
  2010/3/24 Ashley Sheridan a...@ashleysheridan.co.uk
 
   On Wed, 2010-03-24 at 15:34 +0100, Bastien Helders wrote:
 
  Hi list,
 
  I've got this web app, which from a list of selected folders
(with
 content)
  want to create a zip containing them as well as creating a text
file
 with
  information about the chosen folders and how to use them.
 
  To create the zip file I use exec('zip -gr ' .$zipname.' * 
 mylog.log');
  in the temporary folder where I gathered all the data (using a
 zipArchive
  object was more time consuming). I then create the text file
using
 fopen,
  many fwrites and a fclose.
 
  My problem is the following, normally it creates the archive and
text
 file
  without any problem, but as soon as the number of selected folder
has
 an
  high value (let's say about 150 of them), I've got problems with
the
  generated files: The zip archive doesn't contain all the folders
and
 there
  is an unexpected end of file on both zip and text files.
 
  My guess is, as it takes too much time, the script goes on to the
next
  operation and close the streams uncleanly. But I can't be sure
about
 that,
  and I don't know where to investigate.
 
  Regards,
  Bastien
 
 
  Is the script maybe running past the max_execution_time before
the zip
  files are completed?
 
 
Thanks,
  Ash
  http://www.ashleysheridan.co.uk
 
 
 
 
 
  --
  haXe - an open source web programming language
  http://haxe.org
 


 Make sure you have ...

 error_reporting(-1); // show ALL errors/warnings/notices/etc.

 and ...

 exec($Command, $Output, $Status); // Capture the output.
 echo The $Command returned a status of $Status and the following
 output:, PHP_EOL, implode(PHP_EOL,

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Floyd Resler


On Mar 25, 2010, at 9:48 AM, Lester Caine wrote:

 Floyd Resler wrote:
 Absolutely top posting is the most efficient way of doing it!  If I  need to 
 see what the thread is all about, I have no problems starting from the 
 bottom and working my way up.  It would be nice if everyone adopted top 
 posting, though.  Trying to read threads where postings are at the top and 
 bottom makes it really difficult to follow!
 
 So you claim, I find that it is most UNPRODUCTIVE!
 
 But as we have already said - the RULE for this list is bottom posting since 
 as you rightly say mixing it up is making things even more unproductive. If 
 you must campain for a CHANGE to the rules please at least be courteous and 
 follow the rules until there IS a consensus to change that rule. But the 
 current consensus IS to stop debating it at all and leave the rule in place :)
 

Sounds good to me!

Take care,
Floyd


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread tedd


At 6:34 PM -0700 3/24/10, Daevid Vincent wrote:
-snip-

You didn't used to be so difficult, what changed?

For me it's preferable to select windmills that are in my best 
interest to tilt. Otherwise, what's the point?


Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP]Zip and text files generated are corrupted

2010-03-25 Thread Richard Quadling

On 25 March 2010 13:31, Bastien Helders eldroskan...@gmail.com wrote:
 I'm really stumped, it seems that although the script is running under the
 time limit, if a single instruction such as exec(zip) in the first case,
 or copy() in the second case are timing out, because it takes too much time
 processing the big file.

 Is there any configuration in php.ini (or anywhere else) that I could change
 to permit copy() or exec(zip) to run through without being interrupted?

 Regards,
 Bastien


What is the output of the exec when the command fails?

Not the return value of exec() which is the last line, but the whole
thing, which is returned in the second parameter.

If you can't see it due to pushing the file as part of the script,
then try something like ...


exec('zip ', $Output);
file_put_contents('./ZipResults.txt', $Output);



-- 
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] A cleaner way to do this?

2010-03-25 Thread Paul Halliday

I am working on a parser for logs from a spam firewall. The format is
predictable until it reaches a certain point. It then varies greatly.

There are 2 things I want to grab from this area; the size of the
message (if it exists) and the subject (if it exists)

The line might look something like this:

- 2 39 some.text.here SZ:1825 SUBJ: A subject here

but it could also look like this:

5 6 421 Error: timeout

or this:

5 6 421 Client disconnected

All I really want is the value for each, not the prefix stuff. Which
means I still need more below, yuck.

I am doing it like this:

$remainder = explode( , $theLine, 18);
$s_size = '/SZ:\d+/';
$s_subject = '/SUBJ:.+/';

preg_match($s_size,$remainder[17],$a);
preg_match($s_subject,$remainder[17],$b);

if (count($a)  0) {
$size = $a[0];
} else {
$size = 0;
}

if (count($b)  0) {
$subject = $b[0];

} else {
$subject = -;
}

Is there any way to clean this up a bit?

thanks.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] A cleaner way to do this?

2010-03-25 Thread Richard Quadling

On 25 March 2010 16:42, Paul Halliday paul.halli...@gmail.com wrote:
 I am working on a parser for logs from a spam firewall. The format is
 predictable until it reaches a certain point. It then varies greatly.

 There are 2 things I want to grab from this area; the size of the
 message (if it exists) and the subject (if it exists)

 The line might look something like this:

 - 2 39 some.text.here SZ:1825 SUBJ: A subject here

 but it could also look like this:

 5 6 421 Error: timeout

 or this:

 5 6 421 Client disconnected

 All I really want is the value for each, not the prefix stuff. Which
 means I still need more below, yuck.

 I am doing it like this:

 $remainder = explode( , $theLine, 18);
                $s_size = '/SZ:\d+/';
                $s_subject = '/SUBJ:.+/';

                preg_match($s_size,$remainder[17],$a);
                preg_match($s_subject,$remainder[17],$b);

                if (count($a)  0) {
                    $size = $a[0];
                } else {
                    $size = 0;
                }

                if (count($b)  0) {
                    $subject = $b[0];

                } else {
                    $subject = -;
                }

 Is there any way to clean this up a bit?

 thanks.

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



You can do it handraulically using string functions. You can also use
regular expressions.

If you can supply a sensible chunk, I can build a regex for you.
Indicate the exact elements you want to retrieve.

If you want to email me the log file directly that's fine.

-- 
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] A cleaner way to do this?

Paul Halliday wrote:

 
 Is there any way to clean this up a bit?
 

This is what I usually do:

if ( ($matches=preg_match(linepattern1,text,match))0 )
{
// do stuff speicifc to linepattern1
}
else
if ( ($matches=preg_match(linepattern2,text,match))0 )
{
// do stuff speicifc to linepattern2
}
else
if ( ($matches=preg_match(linepattern3,text,match))0 )
{
}
else
if ( ($matches=preg_match(linepattern4,text,match))0 )
{
}



-- 
Per Jessen, Zürich (15.9°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Daniel Brown

On Wed, Mar 24, 2010 at 22:45, Nilesh Govindarajan li...@itech7.com wrote:
 Bottom posting helps in users who are not participating in the thread from
 the start and would like to do so.

Particularly for uniformity for archival purposes.

As has been discussed time and time again, there are many
preferences for top-versus-bottom.  Those arguments are not without
merit, but the fact is that, for the lists operated by php.net, the
rules[1] clearly state that bottom-posting is the way to go.  And the
biggest reason for this is not conformity with antiquated procedures,
but rather for uniformity and accessibility.  It's a disaster when you
read through some newsgroups and archives, particularly for
non-English-native folks.  It's no wonder we receive so many of the
same questions, especially from novices and newbies: why should you
need to learn how to navigate through a conversation to get a simple
answer when you can just bug the folks who can answer it for you
directly?  The unfortunate side-effect with non-conformity to the
rules is that, then, folks who come here to ask questions are referred
to the archives and flamed for not doing so in the first place.

The fact is, that rule will not be changed.  And it's not to take
away your right to democracy in the community, it's because it's a
very purposeful rule.  Those who choose to ignore it, even knowing the
detrimental effects it has on present and future generations of
developers are unfortunately looking at things in a very short-sighted
manner.  Yes, your words and assistance to the community today are
guaranteed to be read by another developer a decade or more from now.
Think about the great impact you're having beyond your own useful
years.  That is not to say by any means that I think it's an
intentional short-sightedness, or that I consider anyone here to
personally be short-sighted, but when one puts personal preference
over the benefit of his or her peers in the community, that is
completely counter to the spirit of what we aim to accomplish here on
a daily basis --- indeed, counter to the very spirit of open source.

It's understandable that everyone has a preference for positioning
within Internet messages.  This is because you have a choice.
Thinking of instant messaging clients, you likely don't even consider
the confusion that would result if there were a choice of where your
message would be posted there.  Why?  Because you're reading the
messages as they stream in, in real-time, without [much] delay.  The
same is true in archives; there is no hours-long - even days-long -
delay between messages.  Click a link or scroll down the page and,
unless you're cursed with a 2400bps Commodore 64 connection, it's a
matter of seconds or microseconds before the next message is
displayed.  The time to decipher where the discussion begins anew in
the latest message can sometimes take longer --- especially for those
who fail to trim out unnecessary and repetitive information, and
doubly for those who quote improperly and begin their reply after the
final carat of the previous message (this is happening frequently
between this thread and the one that spawned it).

Choice is great.  If it weren't for choices, you wouldn't be here.
 If, in fact, you were physically here and all choices leading up to
your choice of programming language were still in line, there's a
very, very, very likely chance that you wouldn't have chosen PHP, and
would thus not be participating in this thread.  The reason behind
that is the sheer number of competing languages.  The difference is
that, at least for the time being, you *prefer* PHP, and have made the
*choice* to utilize it.  Further, you *chose* to become part of the
group.  You weren't drafted against your will.

As such, you *choose* to adhere to the rules set forth if for no
other reason than common courtesy, and professional and mutual
respect.  It matters nil if you respect the individual or the rule
itself, but you understand that you're part of something that is far
bigger than you.  In all honesty, that alone should humble folks
enough to agree to abide by the rules: the fact that, long after you
have ceased to participate within the community for one reason or
other, your words and wisdom will teach thousands of people of whom
you'll never even be aware yet they will be aware of you, and will
be appreciative of your contributions.  You are all teachers, every
single one of you, regardless of whether or not you choose yet to
accept that, or how seriously you take the role.

The bottom line is that, not only is it the preference of the
majority, the accepted manner for the majority of those who remain,
and the rule of this list, it is just good, common courtesy.  For
those who use a mail client such as Outlook Express or a derivative,
clone, or competing client, keep in mind that the very first Internet
messages sent on ARPANET, et al, were sent top-to-bottom.  It's only
in the last

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Daniel Brown

On Thu, Mar 25, 2010 at 13:40, Daniel Brown danbr...@php.net wrote:
 On Wed, Mar 24, 2010 at 22:45, Nilesh Govindarajan li...@itech7.com wrote:
 Bottom posting helps in users who are not participating in the thread from
 the start and would like to do so.

    As has been discussed time and time again, there are many
 preferences for top-versus-bottom.  Those arguments are not without
 merit, but the fact is that, for the lists operated by php.net, the
 rules[1] clearly state that bottom-posting is the way to go.

There I go, getting all long-winded and Dan'ing up the thread so
much that I forget my appendices.  I'd forget my appendages as well,
if I didn't clumsily bump them into things frequently enough to remind
myself to drag them with me.

^1: http://php.net/reST/php-src/README.MAILINGLIST_RULES

-- 
/Daniel P. Brown
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Looking for hosting or dedicated servers?  Ask me how we can fit your budget!

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Web Design

2010-03-25 Thread Daniel Brown

On Thu, Mar 25, 2010 at 09:05, Parham Doustdar parha...@gmail.com wrote:

 P.S.: Please, if this is off-topic, do not shout at me. I tried going to
 http://news.php.net to find any rules regarding what is and isn't allowed on
 the list, but found none. This is of course my shortcoming, but I prefer
 being contacted off-list, rather than being bombarded by messages that read,
 read the rules or just fucking google it; believe me, I have tried.
 Thank you once again, and sorry for the long email.

Such a well-formed request is absolutely permitted here, Parham.
I wish you the best of luck in finding a partner.  I would also
recommend checking forums such as PHP Builder
(http://www.phpbuilder.com/) and other such places.

Hopefully others here in the community will be able to offer even
better suggestions as well.

-- 
/Daniel P. Brown
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Looking for hosting or dedicated servers?  Ask me how we can fit your budget!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Top vs. Bottom Posting.

2010-03-25 Thread Paul M Foster

On Thu, Mar 25, 2010 at 12:22:31PM -0400, tedd wrote:

 At 6:34 PM -0700 3/24/10, Daevid Vincent wrote:
 -snip-

 You didn't used to be so difficult, what changed?

snip

Oh no, he gets testy from time to time. 

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Temporary failure in name resolution - fsockopen()

2010-03-25 Thread Nilesh Govindarajan


On 03/25/2010 07:01 PM, David Lidstone wrote:

Nilesh Govindarajan wrote:

On 03/25/2010 03:51 PM, David Lidstone wrote:

We recently para-virtualised a Xen / CentOS box which is running script
which uses fsockopen() to get a connection to an SMTP server.

Since the server changes it fails approx 50% of the time with:

php_network_getaddresses: getaddrinfo failed: Temporary failure in name
resolution

We've tried the solutions from Googling this error (such as restarting
Apache etc), but without success.

Why am I wasting your time with a Linux upgrade issue? Well,
gethostbyname() seems to resolve the IP every time. Manual lookups on
from the server seem to work with no problems.

Any help greatly appreciated. Should I perhaps be pointing this out on
the 'internals' list?



I feel its something do with your DNS settings and/or the server.

If that's not the problem then just as a temp solution add your SMTP
server's address provided it has a static IP (99.9% it has) to your
/etc/hosts file.

It should not give trouble then.



Thanks for your suggestion Nilesh, but the hosts file would seem to just
defeat the object of being able to look up DNS addresses.

It is possible to by-pass the issue by using gethostbyname() and just
passing in the IP, but this is not really a solution (e.g. we regularly
use a PEAR package which is now effected). The real questions in my mind
are:

If there is a reliable call to resolve IPs, then what is fsockopen()
doing which is different? Given the recurrence of this error over the
last 8 - 9 years, can it be changed to improve reliability, or is this
just a one-off with our server?

I do agree that it is almost certainly an issue with the server or a
library being used (me != serverexpert). But what and why and can PHP
work around this better internally? Thanks again.


One point to be noted here is that you're using CentOS. CentOS has very 
old packages and libraries. So that could be a reason. I don't deny that 
CentOS is a free alternative to most used RHEL, but still old is old, 
new is new. Old is gold doesn't apply in the IT world.


Try upgrading to a new version or use Arch Linux / Gentoo to get the 
latest software and libraries.


--
Nilesh Govindarajan
Site  Server Administrator
www.itech7.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote:
 Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak?

 Use mysqlnd - asynchronous mysql queries.


 You're assuming that everyone in the PHP world uses MySQL 4.1 or
 newer.  What about those who don't?

 They don't get to use threading, nor asynchronous mysql queries.

 Come on, you're asking about a future feature in PHP 7.x , but would
 like to support someone who is seriously backlevel on mysql??


 --
 Per Jessen, Zürich (16.9°C)


I'm not talking about MySQL 4.0 or older.  I'm talking about other
RDBMS.  I think you should open your eyes a bit wider and take a look
at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc).

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote:
 Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak?

 Use mysqlnd - asynchronous mysql queries.


 You're assuming that everyone in the PHP world uses MySQL 4.1 or
 newer.  What about those who don't?

 They don't get to use threading, nor asynchronous mysql queries.

 Come on, you're asking about a future feature in PHP 7.x , but would
 like to support someone who is seriously backlevel on mysql??


 --
 Per Jessen, Zürich (16.9°C)


 I'm not talking about MySQL 4.0 or older.  I'm talking about other
 RDBMS.  I think you should open your eyes a bit wider and take a look
 at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc).

http://www.php.net/manual/en/function.pg-send-query.php

Looks to me like the PHP postgresql library already handles that. Not
to mention: you're not presenting an argument for threads, you're
presenting an argument for implementing asynchronous queries in the
other DBMS libraries.

Of course, the problem could also be solved by introducing threads in
PHP. I'd personally guess modifying DBMS libraries would be less
costly, but as I haven't been involved in writing the PHP code my
guess isn't worth much.

Regards
Peter


 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote:
 Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak?

 Use mysqlnd - asynchronous mysql queries.


 You're assuming that everyone in the PHP world uses MySQL 4.1 or
 newer.  What about those who don't?

 They don't get to use threading, nor asynchronous mysql queries.

 Come on, you're asking about a future feature in PHP 7.x , but would
 like to support someone who is seriously backlevel on mysql??


 --
 Per Jessen, Zürich (16.9°C)


 I'm not talking about MySQL 4.0 or older.  I'm talking about other
 RDBMS.  I think you should open your eyes a bit wider and take a look
 at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc).

 http://www.php.net/manual/en/function.pg-send-query.php

 Looks to me like the PHP postgresql library already handles that. Not
 to mention: you're not presenting an argument for threads, you're
 presenting an argument for implementing asynchronous queries in the
 other DBMS libraries.

 Of course, the problem could also be solved by introducing threads in
 PHP. I'd personally guess modifying DBMS libraries would be less
 costly, but as I haven't been involved in writing the PHP code my
 guess isn't worth much.

 Regards
 Peter


I'm presenting the argument for threading.  Per is presenting the work
around using asynchronous queries via mysqlnd.  I did read that link a
few days ago, Although the user can send multiple queries at once,
multiple queries cannot be sent over a busy connection. If a query is
sent while the connection is busy, it waits until the last query is
finished and discards all its results.  Which sounds like threads -
multiple connections to not run into that problem.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On 25 March 2010 20:09, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote:
 Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak?

 Use mysqlnd - asynchronous mysql queries.


 You're assuming that everyone in the PHP world uses MySQL 4.1 or
 newer.  What about those who don't?

 They don't get to use threading, nor asynchronous mysql queries.

 Come on, you're asking about a future feature in PHP 7.x , but would
 like to support someone who is seriously backlevel on mysql??


 --
 Per Jessen, Zürich (16.9°C)


 I'm not talking about MySQL 4.0 or older.  I'm talking about other
 RDBMS.  I think you should open your eyes a bit wider and take a look
 at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc).

 http://www.php.net/manual/en/function.pg-send-query.php

 Looks to me like the PHP postgresql library already handles that. Not
 to mention: you're not presenting an argument for threads, you're
 presenting an argument for implementing asynchronous queries in the
 other DBMS libraries.

 Of course, the problem could also be solved by introducing threads in
 PHP. I'd personally guess modifying DBMS libraries would be less
 costly, but as I haven't been involved in writing the PHP code my
 guess isn't worth much.

 Regards
 Peter


 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.


Have you looked into what it would cost in development to improve the
library? Have you compared that to the cost in development to
introduce threads into PHP? No, I don't think you're presenting the
argument for threading - but I don't expect you to see it that way.

-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

2010-03-25 Thread Ashley Sheridan

On Thu, 2010-03-25 at 12:09 -0700, Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote:
  On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote:
  On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote:
  Tommy Pham wrote:
 
  On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
  * If you could implement threads and run those same queries in 2+
  threads, the total time saved from queries execution is 1/2 sec or
  more, which is pass along as the total response time reduced.  Is it
  worth it for you implement threads if you're a speed freak?
 
  Use mysqlnd - asynchronous mysql queries.
 
 
  You're assuming that everyone in the PHP world uses MySQL 4.1 or
  newer.  What about those who don't?
 
  They don't get to use threading, nor asynchronous mysql queries.
 
  Come on, you're asking about a future feature in PHP 7.x , but would
  like to support someone who is seriously backlevel on mysql??
 
 
  --
  Per Jessen, Zürich (16.9°C)
 
 
  I'm not talking about MySQL 4.0 or older.  I'm talking about other
  RDBMS.  I think you should open your eyes a bit wider and take a look
  at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc).
 
  http://www.php.net/manual/en/function.pg-send-query.php
 
  Looks to me like the PHP postgresql library already handles that. Not
  to mention: you're not presenting an argument for threads, you're
  presenting an argument for implementing asynchronous queries in the
  other DBMS libraries.
 
  Of course, the problem could also be solved by introducing threads in
  PHP. I'd personally guess modifying DBMS libraries would be less
  costly, but as I haven't been involved in writing the PHP code my
  guess isn't worth much.
 
  Regards
  Peter
 
 
 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.
 


Wouldn't there still be the same issue though?

If several threads of PHP are all trying to connect to to a database
that can only handle a finite number of connections, the database must
still wait until a query has been pushed off of it's queue before it can
process another. As far as I can see, this isn't an issue that can be
solved by threading in PHP, but by allowing more concurrent connections
in the database.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 12:13 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 25 March 2010 20:09, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote:
 Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
 * If you could implement threads and run those same queries in 2+
 threads, the total time saved from queries execution is 1/2 sec or
 more, which is pass along as the total response time reduced.  Is it
 worth it for you implement threads if you're a speed freak?

 Use mysqlnd - asynchronous mysql queries.


 You're assuming that everyone in the PHP world uses MySQL 4.1 or
 newer.  What about those who don't?

 They don't get to use threading, nor asynchronous mysql queries.

 Come on, you're asking about a future feature in PHP 7.x , but would
 like to support someone who is seriously backlevel on mysql??


 --
 Per Jessen, Zürich (16.9°C)


 I'm not talking about MySQL 4.0 or older.  I'm talking about other
 RDBMS.  I think you should open your eyes a bit wider and take a look
 at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc).

 http://www.php.net/manual/en/function.pg-send-query.php

 Looks to me like the PHP postgresql library already handles that. Not
 to mention: you're not presenting an argument for threads, you're
 presenting an argument for implementing asynchronous queries in the
 other DBMS libraries.

 Of course, the problem could also be solved by introducing threads in
 PHP. I'd personally guess modifying DBMS libraries would be less
 costly, but as I haven't been involved in writing the PHP code my
 guess isn't worth much.

 Regards
 Peter


 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.


 Have you looked into what it would cost in development to improve the
 library? Have you compared that to the cost in development to
 introduce threads into PHP? No, I don't think you're presenting the
 argument for threading - but I don't expect you to see it that way.


Aren't all feature requests must be analyzed the same way?  Example,
namespace, how many of us actually uses it now when there is an
alternative solution- subfolders - that we've been using since who
knows how long.  I don't know if threads was asked a feature prior
namespace was implemented.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 12:11 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:

 On Thu, 2010-03-25 at 12:09 -0700, Tommy Pham wrote:

 On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote:
  On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote:
  On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote:
  Tommy Pham wrote:
 
  On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote:
  * If you could implement threads and run those same queries in 2+
  threads, the total time saved from queries execution is 1/2 sec or
  more, which is pass along as the total response time reduced.  Is it
  worth it for you implement threads if you're a speed freak?
 
  Use mysqlnd - asynchronous mysql queries.
 
 
  You're assuming that everyone in the PHP world uses MySQL 4.1 or
  newer.  What about those who don't?
 
  They don't get to use threading, nor asynchronous mysql queries.
 
  Come on, you're asking about a future feature in PHP 7.x , but would
  like to support someone who is seriously backlevel on mysql??
 
 
  --
  Per Jessen, Zürich (16.9°C)
 
 
  I'm not talking about MySQL 4.0 or older.  I'm talking about other
  RDBMS.  I think you should open your eyes a bit wider and take a look
  at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc).
 
  http://www.php.net/manual/en/function.pg-send-query.php
 
  Looks to me like the PHP postgresql library already handles that. Not
  to mention: you're not presenting an argument for threads, you're
  presenting an argument for implementing asynchronous queries in the
  other DBMS libraries.
 
  Of course, the problem could also be solved by introducing threads in
  PHP. I'd personally guess modifying DBMS libraries would be less
  costly, but as I haven't been involved in writing the PHP code my
  guess isn't worth much.
 
  Regards
  Peter
 

 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.


 Wouldn't there still be the same issue though?

 If several threads of PHP are all trying to connect to to a database that can 
 only handle a finite number of connections, the database must still wait 
 until a query has been pushed off of it's queue before it can process 
 another. As far as I can see, this isn't an issue that can be solved by 
 threading in PHP, but by allowing more concurrent connections in the database.

 Thanks,
 Ash
 http://www.ashleysheridan.co.uk


That's why I asked about the DB utilization earlier.  Since the having
the threads can open multiple connections and finish the request
sooner, it can move on to the next request.  Since Java  ASP.NET have
connection pooling, this adds to benefit of threads even more.  I
don't know if PHP has connection pooling now.  I haven't code in PHP a
some years.

Regards,
Tommy

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On 25 March 2010 20:19, Tommy Pham tommy...@gmail.com wrote:
 Aren't all feature requests must be analyzed the same way?  Example,
 namespace, how many of us actually uses it now when there is an
 alternative solution- subfolders - that we've been using since who
 knows how long.  I don't know if threads was asked a feature prior
 namespace was implemented.


Yes, you're right. But feature requests are not equal: some present a
bigger payoff than others, and some will be more problematic to
implement than others. If a given language can solve the problems it
meets based on it's current structure, should you necessarily
implement new shiny features, that may present problems?

I'm not against threads in PHP per se ... I just haven't seen a very
convincing reason for them yet, which is why I'm not very positive
about the thing. The DB scenario could be handled without threads and
current libraries could be improved ... and as long as that's cheaper
than implementing threads, then - personally - I'd need to see more
powerful reasons for threads.

Luckily, I have no say in the development of PHP, so I won't get in
anyone's way should they choose to implement threads :)


-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 25 March 2010 20:19, Tommy Pham tommy...@gmail.com wrote:
 Aren't all feature requests must be analyzed the same way?  Example,
 namespace, how many of us actually uses it now when there is an
 alternative solution- subfolders - that we've been using since who
 knows how long.  I don't know if threads was asked a feature prior
 namespace was implemented.


 Yes, you're right. But feature requests are not equal: some present a
 bigger payoff than others, and some will be more problematic to
 implement than others. If a given language can solve the problems it
 meets based on it's current structure, should you necessarily
 implement new shiny features, that may present problems?

 I'm not against threads in PHP per se ... I just haven't seen a very
 convincing reason for them yet, which is why I'm not very positive
 about the thing. The DB scenario could be handled without threads and
 current libraries could be improved ... and as long as that's cheaper
 than implementing threads, then - personally - I'd need to see more
 powerful reasons for threads.

 Luckily, I have no say in the development of PHP, so I won't get in
 anyone's way should they choose to implement threads :)



Here's my analysis, let's say that you have 1000 requests / second on
the web server.  Each request has multiqueries which take a total of 1
second to complete.  In that one second, how many of those 1000 arrive
at the same time (that one instant of micro/nano second)?  You see how
threads come in?  If you have threads that are able finish the
requests that come in that instant and able to complete them before
the next batch of requests in that same second, wouldn't you agree
then that you're delivering faster response time to all your users?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Temporary failure in name resolution - fsockopen()

2010-03-25 Thread shiplu

For faster dns lookup you can install dnsmasq package and make the local
server cache.
May be that'll solve your problem and the server will be faster.


Shiplu Mokaddim
My talks, http://talk.cmyweb.net
Follow me, http://twitter.com/shiplu
SUST Programmers, http://groups.google.com/group/p2psust
Innovation distinguishes bet ... ... (ask Steve Jobs the rest)

Re: [PHP] Will PHP ever grow up and have threading?

On 25 March 2010 20:59, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 25 March 2010 20:19, Tommy Pham tommy...@gmail.com wrote:
 Aren't all feature requests must be analyzed the same way?  Example,
 namespace, how many of us actually uses it now when there is an
 alternative solution- subfolders - that we've been using since who
 knows how long.  I don't know if threads was asked a feature prior
 namespace was implemented.


 Yes, you're right. But feature requests are not equal: some present a
 bigger payoff than others, and some will be more problematic to
 implement than others. If a given language can solve the problems it
 meets based on it's current structure, should you necessarily
 implement new shiny features, that may present problems?

 I'm not against threads in PHP per se ... I just haven't seen a very
 convincing reason for them yet, which is why I'm not very positive
 about the thing. The DB scenario could be handled without threads and
 current libraries could be improved ... and as long as that's cheaper
 than implementing threads, then - personally - I'd need to see more
 powerful reasons for threads.

 Luckily, I have no say in the development of PHP, so I won't get in
 anyone's way should they choose to implement threads :)



 Here's my analysis, let's say that you have 1000 requests / second on
 the web server.  Each request has multiqueries which take a total of 1
 second to complete.  In that one second, how many of those 1000 arrive
 at the same time (that one instant of micro/nano second)?  You see how
 threads come in?  If you have threads that are able finish the
 requests that come in that instant and able to complete them before
 the next batch of requests in that same second, wouldn't you agree
 then that you're delivering faster response time to all your users?


That sounds like your webserver spawning new processes dealing with
requests ... possibly combined with connection pooling and
asynchronous queries and load balancing, etc, etc. So no, I'm not
convinced that PHP with threads would actually deliver much faster
than a properly built setup that makes good usage of technology you'll
have to use anyway.

-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Tommy Pham wrote:

 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.

You must have read the wrong page.  This is NOT about multiple queries,
it's about _asynchronous_ queries. 


-- 
Per Jessen, Zürich (15.1°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Peter Lind wrote:

 I'm not against threads in PHP per se ... I just haven't seen a very
 convincing reason for them yet, which is why I'm not very positive
 about the thing. 

Roughly the same here - I don't think threading belongs in PHP, but if
someone decides it's a good idea, I won't be arguing against someone
volunteering the effort. 

/Per

-- 
Per Jessen, Zürich (15.7°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

Tommy Pham wrote:

 Here's my analysis, let's say that you have 1000 requests / second on
 the web server.  Each request has multiqueries which take a total of 1
 second to complete.  In that one second, how many of those 1000 arrive
 at the same time (that one instant of micro/nano second)? 

On average, exactly one per millisecond. 


/Per

-- 
Per Jessen, Zürich (15.4°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] MySQL: Return Number of Matched Rows

2010-03-25 Thread James Colannino

Hey everyone,

I have a question.  If I do a mysql query that updates a column in a row
to the same value, I get 0 rows affected.  However, I also get 1 or more
 matched rows.  Is there a way that I can return the number of matched
rows, rather than the number of rows affected?

I'm trying to get something done with as few SQL queries as possible.
Thanks!

James

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] MySQL: Return Number of Matched Rows

2010-03-25 Thread Floyd Resler


On Mar 25, 2010, at 5:10 PM, James Colannino wrote:

 Hey everyone,
 
 I have a question.  If I do a mysql query that updates a column in a row
 to the same value, I get 0 rows affected.  However, I also get 1 or more
 matched rows.  Is there a way that I can return the number of matched
 rows, rather than the number of rows affected?
 
 I'm trying to get something done with as few SQL queries as possible.
 Thanks!
 
 James
 

As for as I know, MySQL simply just doesn't report a row as being affected if 
nothing has changed in it.  To get the number of matched rows, try doing a 
SELECT query before you do the UPDATE query.  I don't know if that will produce 
the results you're looking for, but it might.

Take care,
Floyd


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] MySQL: Return Number of Matched Rows

2010-03-25 Thread James Colannino

Floyd Resler wrote:
 As for as I know, MySQL simply just doesn't report a row as being affected if 
 nothing has changed in it.  To get the number of matched rows, try doing a 
 SELECT query before you do the UPDATE query.  I don't know if that will 
 produce the results you're looking for, but it might.
   

Yeah, the extra select is what I was hoping to avoid :-P  The MySQL
client will return both the number of rows matched and the number of
rows affected by the query; I was hoping perhaps the PHP API offered a
way for me to do the same.  Ah well...  Thanks!

James


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?


Per Jessen wrote:

Tommy Pham wrote:


I'm presenting the argument for threading.  Per is presenting the work
around using asynchronous queries via mysqlnd.  I did read that link a
few days ago, Although the user can send multiple queries at once,
multiple queries cannot be sent over a busy connection. If a query is
sent while the connection is busy, it waits until the last query is
finished and discards all its results.  Which sounds like threads -
multiple connections to not run into that problem.


You must have read the wrong page.  This is NOT about multiple queries,
it's about _asynchronous_ queries.


The only problem here is what the database client can handle. If it can only 
handle one active query, then that is all that can be used. It can be started 
asynchronously and then you come back to pick up the results later, and so you 
can be formating the page ready to insert the results. PDO requires that you 
start a different connection in a different transaction for each of these 
queries, but that is another hot potato. Running 10 asynchronous queries would 
require 10 connections as that is how the database end works. Adding threading 
to PHP is going to make no difference?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] MySQL: Return Number of Matched Rows

2010-03-25 Thread Yousif Masoud

On Thu, Mar 25, 2010 at 9:19 PM, James Colannino ja...@colannino.orgwrote:

 Yeah, the extra select is what I was hoping to avoid :-P  The MySQL
 client will return both the number of rows matched and the number of
 rows affected by the query; I was hoping perhaps the PHP API offered a
 way for me to do the same.  Ah well...  Thanks!


You can access data about the latest query via mysql_info()

http://php.net/manual/en/function.mysql-info.php

You can parse the string for the values you need.

There may be a more elegant solution.

Re: [PHP] Will PHP ever grow up and have threading?

On 25 March 2010 22:51, Lester Caine les...@lsces.co.uk wrote:
 Per Jessen wrote:

 Tommy Pham wrote:

 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.

 You must have read the wrong page.  This is NOT about multiple queries,
 it's about _asynchronous_ queries.

 The only problem here is what the database client can handle. If it can only
 handle one active query, then that is all that can be used. It can be
 started asynchronously and then you come back to pick up the results later,
 and so you can be formating the page ready to insert the results. PDO
 requires that you start a different connection in a different transaction
 for each of these queries, but that is another hot potato. Running 10
 asynchronous queries would require 10 connections as that is how the
 database end works. Adding threading to PHP is going to make no difference?

Actually, this sounds very close to having 10 threads each opening a
connection to the database and running the query ... which was the
solution to the scenario presented, if memory serves.

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk//
 Firebird - http://www.firebirdsql.org/index.php

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 1:50 PM, Per Jessen p...@computer.org wrote:
 Tommy Pham wrote:

 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.

 You must have read the wrong page.  This is NOT about multiple queries,
 it's about _asynchronous_ queries.


 That quote is comming directly from that link Peter Lind gave, which
I read a few days ago.  Did you read it?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 3:04 PM, Tommy Pham tommy...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 1:50 PM, Per Jessen p...@computer.org wrote:
 Tommy Pham wrote:

 I'm presenting the argument for threading.  Per is presenting the work
 around using asynchronous queries via mysqlnd.  I did read that link a
 few days ago, Although the user can send multiple queries at once,
 multiple queries cannot be sent over a busy connection. If a query is
 sent while the connection is busy, it waits until the last query is
 finished and discards all its results.  Which sounds like threads -
 multiple connections to not run into that problem.

 You must have read the wrong page.  This is NOT about multiple queries,
 it's about _asynchronous_ queries.


  That quote is comming directly from that link Peter Lind gave, which
 I read a few days ago.  Did you read it?


Here's the entire description:

 pg_send_query() sends a query or queries asynchronously to the connection
. Unlike pg_query(), it *can send multiple queries at once to PostgreSQL*and
*get the results one by one using pg_get_result().*

Script execution is not blocked while the queries are executing. Use
pg_connection_busy() to check if the connection is busy (i.e. the query is
executing). Queries may be cancelled using pg_cancel_query().

*Although the user can send multiple queries at once, multiple queries
cannot be sent over a busy connection. If a query is sent while the
connection is busy, it waits until the last query is finished and discards
all its results.*

Any case, that's only workaround for mysql (mysqlnd)  postgresql.  What
about those that uses other RDBMS?

Re: [PHP] Will PHP ever grow up and have threading?

?php
  $dbconn = pg_connect(dbname=publisher) or die(Could not connect);

  if (!pg_connection_busy($dbconn)) {
  pg_send_query($dbconn, select * from authors; select count(*)
from authors;);
  }

  $res1 = pg_get_result($dbconn);
  echo First call to pg_get_result(): $res1\n;
  $rows1 = pg_num_rows($res1);
  echo $res1 has $rows1 records\n\n;

  $res2 = pg_get_result($dbconn);
  echo Second call to pg_get_result(): $res2\n;
  $rows2 = pg_num_rows($res2);
  echo $res2 has $rows2 records\n;
?

There's the code example from that same link.  You may have executed
the queries asynchronously, but the process of the results are still
serial.  Let's face it, all of our processing of queries are not a
simple echo.  We iterate/loop through the results and display them in
the desired format.  Having execute the query and the processing of
the result in threads/parallel, you get the real performance boost
which I've been trying to convey the concept of serial versus
parallel.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On 25 March 2010 23:23, Tommy Pham tommy...@gmail.com wrote:

 There's the code example from that same link.  You may have executed
 the queries asynchronously, but the process of the results are still
 serial.  Let's face it, all of our processing of queries are not a
 simple echo.  We iterate/loop through the results and display them in
 the desired format.  Having execute the query and the processing of
 the result in threads/parallel, you get the real performance boost
 which I've been trying to convey the concept of serial versus
 parallel.

Actually, you haven't mentioned the processing as part of what the
threads do until now. I see your point though: if you split that part
off, you might gain some performance, that would otherwise be hard to
get at.
 I wonder though, if the performance is worth it in the tradeoff for
the maintenance nightmare it is when you split out content processing
between 10 different threads. I wouldn't personally touch it unless I
had no other option, but that's just my opinion.

Anyway, I don't think either of us will change point of view much at
this point - so we should probably just give the mailing list a rest
by now. Thanks for the posts, it's been interesting to read :)

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever grow up and have threading?

On Thu, Mar 25, 2010 at 3:35 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 25 March 2010 23:23, Tommy Pham tommy...@gmail.com wrote:

 There's the code example from that same link.  You may have executed
 the queries asynchronously, but the process of the results are still
 serial.  Let's face it, all of our processing of queries are not a
 simple echo.  We iterate/loop through the results and display them in
 the desired format.  Having execute the query and the processing of
 the result in threads/parallel, you get the real performance boost
 which I've been trying to convey the concept of serial versus
 parallel.

 Actually, you haven't mentioned the processing as part of what the
 threads do until now. I see your point though: if you split that part
 off, you might gain some performance, that would otherwise be hard to
 get at.

Because in the past, when someone mention performance issues, the
replies come in with:  is DB structure optimized,  are queries
optimized, is the code optimized?  For those in the field long enough
and have all that optimized and want additional performance boost,
what else are there?  Thus, when I mentioned threads/parallel, I don't
mean execution of queries, but of everything in the entire app/project
where the gain is desired.

  I wonder though, if the performance is worth it in the tradeoff for
 the maintenance nightmare it is when you split out content processing
 between 10 different threads. I wouldn't personally touch it unless I
 had no other option, but that's just my opinion.

 Anyway, I don't think either of us will change point of view much at
 this point - so we should probably just give the mailing list a rest
 by now. Thanks for the posts, it's been interesting to read :)


Agreed. :)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Authorize.net test

Does anyone have any experience with authorize.net?

I have a test account with authorize.net and I have written a script to use 
the checkout of authorize.net but I keep getting this error:

3|2|13|The merchant login ID or password is invalid or the account is 
inactive.||P|0|||45.99||auth_capture||
C6625114C7C848C859D5D0C446C1F7CE||

and this error:

3|2|13|The merchant login ID or password is invalid or the account is 
inactive.||P|0|||0.00||auth_capture||
F68A9C87C1E1472521704EF38C21F647||

I have checked and rechecked my login ID and password with no results.

The code is spread across 3 files config.php, authorize_net_request.php, and 
test_authorize_net.php and I have posted these files to pastebin because I 
didn't know if I could post the code here.

Could someone give these files a look over and see what I've done wrong?

The pastebin URL is:
http://pastebin.com/5xacghDR

Thanks so much.
-- 
Blessings
David M.
I have been driven to my knees many times by the overwhelming conviction that 
I had nowhere else to go.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Authorize.net test

2010-03-25 Thread Michelle Konzack

Hello David McGlone,

Am 2010-03-25 20:45:19, hacktest Du folgendes herunter:
 Does anyone have any experience with authorize.net?

Yes, I get currently per day arround 16.000 phishing
spams or something like this...

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
http://www.tamay-dogan.net/ Michelle Konzack
http://www.can4linux.org/   Apt. 917
http://www.flexray4linux.org/   50, rue de Soultz
Jabber linux4miche...@jabber.ccc.de   67100 Strasbourg/France
IRC#Debian (irc.icq.com)  Tel. DE: +49 177 9351947
ICQ#328449886 Tel. FR: +33  6  61925193


signature.pgp
Description: Digital signature

Re: [PHP] Re: Authorize.net test

On Thursday 25 March 2010 21:17:38 Michelle Konzack wrote:
 Hello David McGlone,
 
 Am 2010-03-25 20:45:19, hacktest Du folgendes herunter:
  Does anyone have any experience with authorize.net?
 
 Yes, I get currently per day arround 16.000 phishing
 spams or something like this...

Huh? what does my post have to do with phishing? The code I posted is from a 
book that I am trying to learn from.

-- 
Blessings
David M.
I have been driven to my knees many times by the overwhelming conviction that 
I had nowhere else to go.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Top vs. Bottom Posting

2010-03-25 Thread Daevid Vincent

 -Original Message-
 From: tedd [mailto:tedd.sperl...@gmail.com] 
 Sent: Thursday, March 25, 2010 9:23 AM
 To: Daevid Vincent; php-general@lists.php.net
 Subject: Re: [PHP] Top vs. Bottom Posting.

 At 6:34 PM -0700 3/24/10, Daevid Vincent wrote:
 -snip-

 You didn't used to be so difficult, what changed?

 For me it's preferable to select windmills that are in my best 
 interest to tilt. Otherwise, what's the point?

 Cheers,

 tedd

(look I'm bottom posting!)

I wasn't trying to be difficult! Honest!

Yousif hijacked my thread to tell me to bottom post. I did the right thing
IMHO, and split to a brand new message/thread (to keep the 'thread' thread
on track), with relevant subject line, and gave my retort as to why I don't
agree and why I prefer top posting. I didn't intend for it to be the same
tired top/bottom post argument we've seen numerous times in the decade or
so I've been on this list.

But I have to say, I'm a little bit honored and flattered even, that the
legendary Tedd Sperling even knows who I am let alone takes note of how I
used to be. :)  That makes my day!

d

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Authorize.net test

2010-03-25 Thread Paul M Foster

On Thu, Mar 25, 2010 at 08:45:19PM -0400, David McGlone wrote:

 Does anyone have any experience with authorize.net?
 
 I have a test account with authorize.net and I have written a script to use
 the checkout of authorize.net but I keep getting this error:
 
 3|2|13|The merchant login ID or password is invalid or the account is
 inactive.||P|0|||45.99||auth_capture||
 C6625114C7C848C859D5D0C446C1F7CE||
 
 and this error:
 
 3|2|13|The merchant login ID or password is invalid or the account is
 inactive.||P|0|||0.00||auth_capture||
 F68A9C87C1E1472521704EF38C21F647||
 
 I have checked and rechecked my login ID and password with no results.
 
 The code is spread across 3 files config.php, authorize_net_request.php, and
 test_authorize_net.php and I have posted these files to pastebin because I
 didn't know if I could post the code here.
 
 Could someone give these files a look over and see what I've done wrong?
 
 The pastebin URL is:
 http://pastebin.com/5xacghDR

Last time I encountered an error like this with an e-gateway, the
problem was that, despite what I thought, the account was actually
inactive. It wasn't authorize.net, but I'm betting that your gateway ID
and password are fine, just like mine were. I had to call them to find
out the account was, for some reason, deemed inactive.

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] RE: optimizing PHP for microseconds

2010-03-25 Thread Daevid Vincent

 -Original Message-
 From: Robert Cummings [mailto:rob...@interjinn.com] 
 Sent: Thursday, March 25, 2010 6:25 AM
 To: Per Jessen
 Cc: php-general@lists.php.net
 Subject: Re: [PHP] Will PHP ever grow up and have threading?

 Per Jessen wrote:
  Tommy Pham wrote:

  (I remember a list member, not mentioning his name, does optimization
  of PHP coding for just microseconds.  Do you think how much more he'd
  benefit from this?)

  Anyone who optimizes PHP for microseconds has lost touch with reality -
  or at least forgotten that he or she is using an interpreted language.

 But sometimes it's just plain fun to do it here on the list with 
 everyone further optimizing the last optimized snippet :)

 Cheers,
 Rob.

Was that someone me? I do that. And if you don't, then you're the kind of
person I would not hire (not saying that to sound mean). I use single
quotes instead of double where applicable. I use -- instead of ++. I use
$boolean = !$boolean to alternate (instead of mod() or other incrementing
solutions). I use LIMIT 1 on select, update, delete where appropriate. I
use the session to cache the user and even query results. I don't use
bloated frameworks (like Symfony or Zend or Cake or whatever else tries to
be one-size-fits-all). The list goes on.

I would counter and say that if you are NOT optimizing every little drop of
performance from your scripts, then you're either not running a site
sufficiently large enough to matter, or you're doing your customers a
disservice.

I come from the video game world where gaining a frame or two of animation
per second matters. It makes your game feel less choppy and more fluid and
therefore more fun to play.

If I have to wait 3 seconds for a page to render, that wait is noticeable.
Dumb users will click refresh, and since (unbelievably in this day and age)
PHP and mySQL don't know the user clicked 'stop' or 'refresh', and
therefore mySQL will execute the same query a second time. That's an
entirely different thread I've already ranted on about.

If you can shave off 0.1s from each row of a query result, after only 10
rows, you've saved the user 1 full second. But realistically, you are most
likely displaying hundreds (or in my case, thousands) of rows. Now I've
just saved this user 10s to 100s (that's a minute and a half!)

I'm dealing with TB databases with billions of rows and complex queries
that would make you (and often times me too) cringe in fright. Sure, if
you're dealing with your who-gives-a-shit blog website and all 20 entries
of crap-nobody-cares-about, then do whatever you want. But if you're doing
professional, enterprise level work, or have real customers who expect
performance, then you sure as hell better be considering all the ways to
speed up your page. They don't run in a vacuume. They don't just have a
single query.

d

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] RE: optimizing PHP for microseconds


Daevid Vincent wrote:


If I have to wait 3 seconds for a page to render, that wait is noticeable.
Dumb users will click refresh, and since (unbelievably in this day and age)
PHP and mySQL don't know the user clicked 'stop' or 'refresh', and
therefore mySQL will execute the same query a second time. That's an
entirely different thread I've already ranted on about.


You may find the following enlightening:

http://www.php.net/manual/en/function.ignore-user-abort.php
http://www.php.net/manual/en/function.connection-aborted.php
http://www.php.net/manual/en/function.connection-status.php

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] RE: optimizing PHP for microseconds

2010-03-25 Thread Daevid Vincent

 

 -Original Message-
 From: Robert Cummings [mailto:rob...@interjinn.com] 
 Sent: Thursday, March 25, 2010 7:16 PM
 
 Daevid Vincent wrote:
 
  If I have to wait 3 seconds for a page to render, that wait 
 is noticeable.
  Dumb users will click refresh, and since (unbelievably in 
 this day and age)
  PHP and mySQL don't know the user clicked 'stop' or 'refresh', and
  therefore mySQL will execute the same query a second time. That's an
  entirely different thread I've already ranted on about.
 
 You may find the following enlightening:
 
  http://www.php.net/manual/en/function.ignore-user-abort.php
  http://www.php.net/manual/en/function.connection-aborted.php
  http://www.php.net/manual/en/function.connection-status.php
 

Except there is no way to tell mySQL cancel that last request/query.
Well, no graceful way.

We actually have a script that runs on a crontab and seeks and destroys
long running queries. As you may have guessed, just because a query takes
a long time, it's difficult to know if it's actually hung or just really
taking that long. So we do some smarts to compare against others and see if
it seems like the same one and stuff like that. Not great, but sure stops
the load from shooting through the roof.

Again, not going into the rant I've done before. Look in the archives
2009-06-02 for Why doesn't mySQL stop a query when the browser tab is
closed for that thread and even more indepth info on the
my...@lists.mysql.com archives (same date and subject).


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] RE: optimizing PHP for microseconds