# [EMAIL PROTECTED] / 2006-12-24 18:11:03 -0800:
function display($list, $in, $out, $save, $req, $x)
{
for($i = 0; $i count($in); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($out); $i++)
{$j = $i + 1;
On Dec 25, 2006, at 7:21 AM, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-12-24 18:11:03 -0800:
function display($list, $in, $out, $save, $req, $x)
{
for($i = 0; $i count($in); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i
2006/12/25, jekillen [EMAIL PROTECTED]:
On Dec 25, 2006, at 7:21 AM, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-12-24 18:11:03 -0800:
function display($list, $in, $out, $save, $req, $x)
{
for($i = 0; $i count($in); $i++)
{$j = $i + 1;
// two sets of links
At 12:24 AM 11/17/2006 , Michael wrote:
HEllo all,
After pulling my hair out for several hours trying to figure out why my code
wasn't working I built this little test and ran it, the results are interesting
in the least, and to me, surprising. It is possible that I have done something
wrong, but
Michael wrote:
Ok, picking gnits...
I should have said NOT true and NOT false at the same time.
As for the return of the integer 0..
The documentation indicates that the === and !== operators take this into
account in fact there is a specific example in the manual.
My point here is that if !==
Michael wrote:
I'm not sure why the === operator does not handle this condition, since the
wonderful people at PHP foresaw the problem and fixed !== to handle it, I would
like to see the === fixed to handle this as well (if it is even possible, not
sure about how this is implemented??)
At 02:10 AM 11/17/2006 , Stut wrote:
Michael wrote:
Ok, picking gnits...
I should have said NOT true and NOT false at the same time.
As for the return of the integer 0..
The documentation indicates that the === and !== operators take this into
account in fact there is a specific example in
At 02:33 AM 11/17/2006 , Stut wrote:
Michael wrote:
I understand that the integer 0 and FALSE are different and I read the
manual so many times my head hurts, heh.
There are a few ways to work around this, probably more than I know.
(according to the documentation for strrpos() you could
Please include the list in replies.
Michael wrote:
Why can't === realize that integer 0 means TRUE? whereas or a BOOLEAN false
does not? === evaluates integer 0 to FALSE :(
the !== operator recognizes the difference.
(integer) 0 !== FALSE is TRUE yet
(integer) 0 === TRUE is FALSE, but it
Michael wrote:
I understand that the integer 0 and FALSE are different and I read the manual
so many times my head hurts, heh.
There are a few ways to work around this, probably more than I know. (according to the
documentation for strrpos() you could test the return from stripos() for
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and === operators work in this
situation is this:
Logic dictates that if something evaluates to NOT FALSE it must be TRUE.
Regardless of the
On 17 November 2006 09:55, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and ===
operators work in this situation is this:
Logic dictates that if something evaluates
To: Michael
Cc: php-general@lists.php.net
Subject: RE: [PHP] odd behavior of stripos() with === operator *LAST POST*
On 17 November 2006 09:55, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem
On Fri, 2006-11-17 at 02:54 -0700, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and === operators work in this
situation is this:
Logic dictates that if something
Robert Cummings wrote:
On Fri, 2006-11-17 at 02:54 -0700, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and === operators work in this
situation is this:
Logic dictates
On Fri, 2006-11-17 at 17:29 +0100, Jochem Maas wrote:
Robert Cummings wrote:
On Fri, 2006-11-17 at 02:54 -0700, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and ===
Robert Cummings wrote:
On Fri, 2006-11-17 at 17:29 +0100, Jochem Maas wrote:
Robert Cummings wrote:
On Fri, 2006-11-17 at 02:54 -0700, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the
At 2:54 AM -0700 11/17/06, Michael wrote:
Logic dictates that if something evaluates to NOT FALSE it must be TRUE.
Regardless of the type, regardless of the species, breed, flavor etc.
Not true -- it depends upon your reference/environment.
For example, NULL is neither true nor false in
Ok, just to shut you all up, I managed to convince the OP earlier today,
but it never made it to the list...
Michael wrote:
At 02:58 AM 11/17/2006 , Stut wrote:
Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
On 17 November 2006 16:50, Stut wrote:
Your basic misunderstanding is that === is the opposite of !==
which it's not.
Complete rubbish -- it so absolutely is!
If $a===$b, then !($a===$b) is the same as $a!==$b, QED.
(INTEGER === true) will always be false because the types
On Fri, 2006-11-17 at 00:24 -0700, Michael wrote:
HEllo all,
After pulling my hair out for several hours trying to figure out why my code
wasn't working I built this little test and ran it, the results are
interesting
in the least, and to me, surprising. It is possible that I have done
At 12:29 AM 11/17/2006 , you wrote:
I have underlined the output I am interested in...
You did??? Where?
Ok, my bad, I sent the mail as plain text instead of styled :P
oops
How can the variable $found be both TRUE and FALSE at the same time?
None of your output above indicates that it is
[snip]
From the offices of You Ain't Gonna' Beleeeve Dis, Inc.
We barked up several trees, but there were no real squirrels.
PHP 4.4.1, the version on the server in question, comes with 2 flavors of
ini file, the dist and the recommended. I had copied the recommended and
renamed it php.ini,
On Thu, 19 Jan 2006 11:53:04 -0600
Jay Blanchard [EMAIL PROTECTED] wrote:
Has anyone experienced this behavior before, and how do I fix that
damned path to the ini? TIA!
Personally, I'd fix it with a Debian install CD, but that's just me.
#;-D
Can't help with the Windoze issue - I don't do
Jay Blanchard wrote:
snip
and how do I fix
http://distrowatch.com/
serious mode
I have no idea, I don't do Windows.
/serious mode
Sucks to be you. ;)
--
John C. Nichel IV
Programmer/System Admin (ÜberGeek)
Dot Com Holdings of Buffalo
716.856.9675
[EMAIL PROTECTED]
--
PHP General Mailing
Ok.. now maybe a constructive answer :)
If I recall, PHP on Windows will look for PHP.INI in your Windows system folder
(in this case C:\WINNT) first, then in the folder where PHP is installed.
Deleting the PHP.INI under WINNT should be fine (sounds like removing that
makes things work ok for
I use PWS with Windows 98 for learning purposes.
I just cut PHP.ini from C:\PHP and paste in %windir% then restart the
server. Works fine for me and I can run ASP and PHP for learning. ^^
Regards, Rodolfo Andrade
- Original Message -
From: Jay Blanchard
To: PHP General (E-mail)
Sent:
[snip]
If I recall, PHP on Windows will look for PHP.INI in your Windows system
folder (in this case C:\WINNT) first, then in the folder where PHP is
installed. Deleting the PHP.INI under WINNT should be fine (sounds like
removing that makes things work ok for you). I'd think phpinfo() would
On Thu, January 19, 2006 11:53 am, Jay Blanchard wrote:
I had PHP installed on a web server, and all was working OK, save for
one
small thing. phpinfo() indicated that the path to the php.ini was
c:\WINNT,
which it was not. So I copy the file from the c:\php directory to the
c:\winnt
On Thu, January 19, 2006 12:31 pm, Jay Blanchard wrote:
[snip]
If I recall, PHP on Windows will look for PHP.INI in your Windows
system
folder (in this case C:\WINNT) first, then in the folder where PHP is
installed. Deleting the PHP.INI under WINNT should be fine (sounds
like
removing
[snip]
...lots of valuable information
[/snip]
From the offices of You Ain't Gonna' Beleeeve Dis, Inc.
We barked up several trees, but there were no real squirrels.
PHP 4.4.1, the version on the server in question, comes with 2 flavors of
ini file, the dist and the recommended. I had copied
Curt Zirzow wrote:
To simplify things:
$a[2] = '1';
$k = (double)2;
echo isset($a[$k]);
unset($a[$k]);
echo isset($a[$k]);
echo - expect 1\n;
Result:
11 - expect 1
Yeah, my version was just a wee bit verbose. :)
It's the behavior that is specific to unset() that I'm
On Thu, 17 Jun 2004 16:52:32 -0500, Michael Sims [EMAIL PROTECTED]
wrote:
ceil() returns a variable of type double. In the above script I
expected $foo to
become an empty array after calling unset(). But it seems that unset()
will not
remove an array element when you refer to its key
Thomas Goyne wrote:
On Thu, 17 Jun 2004 16:52:32 -0500, Michael Sims
[EMAIL PROTECTED] wrote:
ceil() returns a variable of type double. In the above script I
expected $foo to become an empty array after calling unset(). But
it seems that unset() will not remove an array element when you
* Thus wrote Michael Sims:
Thomas Goyne wrote:
On Thu, 17 Jun 2004 16:52:32 -0500, Michael Sims
[EMAIL PROTECTED] wrote:
ceil() returns a variable of type double. In the above script I
expected $foo to become an empty array after calling unset(). But
However,
array indexes are
At 30.04.2002 18:29, you wrote:
When I run this the first time, file.txt contains value of 30. Then I add 15
to it with following script and file now contains value of 45. I look at
file.txt after write and it does indeed contain number 45. But when I run
script 24 hours later via cron job, it
check clearstatcache()
Charles Killmer
-- Original Message --
From: Craig Westerman [EMAIL PROTECTED]
Date: Tue, 30 Apr 2002 18:29:37 -0500
When I run this the first time, file.txt contains value of 30. Then I add 15
to it with following script and file
Sure you got your permissions set right?
On Tuesday 30 April 2002 16:29 pm, you wrote:
When I run this the first time, file.txt contains value of 30. Then I add
15 to it with following script and file now contains value of 45. I look at
file.txt after write and it does indeed contain number
38 matches
Mail list logo
