Marc Richards wrote:
> I guess this is too late for 5.0, and I feel like there is bound to be
> opposition, but this has been bugging me for a while, so I figured I
> would ask.
>
> I use the alternative syntax for control structures almost exclusively
> within my HTML code but I have to revert t
works fine with the latest CVS-Snap for me
php5-win32-200407121430.zip Win2K Apache2
-- red
Curt Zirzow wrote:
* Thus wrote Antony Dovgal:
On Mon, 12 Jul 2004 15:00:09 +
Curt Zirzow <[EMAIL PROTECTED]> wrote:
* Thus wrote Andi Gutmans:
When did you try that? Did you check with latest CVS beca
i experienced this using PHP4 ( guess it is 4.2.x ) in our local
production enviroment and with one of our clients servers ( 4.3.2 )
-- red
Nuno Lopes wrote:
Hello,
A user have reported a bug in the documentation about ini_get().
Check this:
outputs:
string(1) "0" in PHP 4
-and-
string(0) "" in P
I guess that was <= 4.1.0 as i get errors at work ( 4.0.x ) and
everything went fine as i misstyped today using 5.0.0rc3 :-)
--red
Adam Maccabee Trachtenberg wrote:
On Thu, 17 Jun 2004, Jason Garber wrote:
Is being able to have a comma at the END of an array definition a supported
feature, or
I guess this would only help the lazy guys around. There are many other
ways to get around this without writing that many ternary constructs
eg:
function get_post_var ( $name , $default ) {
return isset ( $_POST[ $name ] ) ? $_POST[ $name ] : $default ;
}
$CUST_ID = (integer) get_post_var (
Actually it seams like it crashes my Apache2 when used within
an error_handler. Backtracing the error generated by
$boolean = FALSE ;
$boolean[2] += 1 ;
will tear down the whole Apache2 process on Win32 Servers
--red
Am Dienstag, 16. März 2004 15:49 schrieb Wez Furlong:
> Seems unlikely; genera
Finally found a script to reproduce the Crash:
http://download.erisx.de/crash.txt
Red Wingate wrote:
Allright tried running PHP as a CGI and the crash is gone. I gave the
source a closer look and found this to be the line which caused the
crash:
$database['user_logins_failed&#
M 3/5/2004 +0100, Red Wingate wrote:
This one is kinda annoying as well:
http://bugs.php.net/bug.php?id=26286&edit=1
Just ran into this just a few minutes ago. Tried to solve
the problem using a new Snapshot but this didn't solve my
problem, also using a diffrent apache2 version didn'
This one is kinda annoying as well:
http://bugs.php.net/bug.php?id=26286&edit=1
Just ran into this just a few minutes ago. Tried to solve
the problem using a new Snapshot but this didn't solve my
problem, also using a diffrent apache2 version didn't change
anything either.
Red
Walter A. Boring I
I guess the way the implementation works is quite fine. But i guess leaving
the calls in a random order gives the use of the destructors a quite bad
taste. The current implementation leaves many room for 'try and error'
writing of code as you are almost unable to make things work the way
you would
Is the removal of a specific order on the __destruct() calls
necessary? It's a pain in the ass the be unable to predict
in which order the __destruct() calls are made.
error_log;
}
function __destruct () {
// Dump Error-Log to User ( E-Mail, HTML etc. )
}
}
Why not just allow this as an optional feature, i don't see any reasons to
keep this out as it doesn't affect any performace and can maybe help some
old-skewl PERL-Coders to convert over to PHP.
One of the best features of PERL is the tight connection between regular
expressions and the scripting-
12 matches
Mail list logo
