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
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 <
# [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 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 type
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.
I
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 MySQL.
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 m
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 wa
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:
>>
>
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 somet
iday, November 17, 2006 7:15 AM
> 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.
> >
&g
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 eva
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 typ
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 is_bool
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, bu
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() yo
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 ex
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??)
Th
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 !==
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
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
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 don
[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, wh
[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 copi
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
> removi
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 di
[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 show
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: Th
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
Jay Blanchard wrote:
and how do I fix
http://distrowatch.com/
I have no idea, I don't do Windows.
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 List (http://www.php.net/)
To u
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
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 u
* 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,
> > arra
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 whe
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 usi
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 fi
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,
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 numb
38 matches
Mail list logo
