Tricky code - tricky result. Do you think php-5.1 result is perfect? :)
BTW the difference is in implementation of %G format specifier.
It seems, now it tries to produce the shortest string representation of
float (I cannot remember why), but this is not conformed to POSIX
specification
Linux ma
For what it's worth, this would be very nice. I always use my own
custom HTTP handling for this reason (and related reasons, such as
keep-alive.)
However, it's also very complicated; the cached data has to be managed,
has to be stored somewhere... and at what point do you add cookie
manageme
On Tue, April 17, 2007 3:16 am, David Sklar wrote:
> Richard Lynch <[EMAIL PROTECTED]> wrote:
>> You might also come at it from the other direction and detect/notify
>> at some number smaller than the current hard limit, configurable in
>> php.ini...
>>
>> This might play better with anything relyi
On Tue, April 17, 2007 3:18 am, David Sklar wrote:
> On 4/17/07, Peter Hodge <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> A soft memory limit could be very useful; it doesn't necessarily
>> need to throw
>> an error, but it would provide an opportunity to free some memory
>> and prevent
>> the script
On Tue, April 17, 2007 8:15 am, Hannes Magnusson wrote:
> On 4/17/07, Christian Schneider <[EMAIL PROTECTED]> wrote:
>> Hannes Magnusson wrote:
>> >> 7. add E_STRICT to E_ALL DONE (dmitry)
>> >
>> > My dictionary says that "all" means *all*, not "all except this
>> and
>> > this and sometimes not t
I have code at Facebook that currently does something similar by
catching fatal errors but there's a lot of gotcha's obviously that
need to be handled properly when the engine is in this state. When
possible we enable the printing of backtraces and other debug
information, however you ru
PHP 5.2.1:
-1689934592
2147483647
PHP 5.2.2:
-1689934592
6
Huh, that's a strange thing. Why it happens?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Hello Sebastian,
sometimes persistence is good. I take it all back after realising that we
are speaking of the general outputformat. That should of cause stay the
same. Tony mentioned he can fix it. So let the format just stay the same
as Rasmus suggested.
best regards
marcus
Tuesday, April 17
Sebastian Nohn wrote:
> $c = $a."";
> $d = (string)$a;
Forget that.
- Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 04/17/2007 10:37 PM, Sebastian Nohn wrote:
$a = 69;
$b = "69";
$c = $a."";
$d = (string)$a;
You're converting float to string and THEN trying to output as integer.
My patch returns the old behaviour, though you're code is still wrong.
--
Wbr,
Antony Dovgal
--
PHP Intern
Antony Dovgal wrote:
> On 04/17/2007 10:16 PM, Sebastian Nohn wrote:
>> Dmitry Stogov wrote:
>>
>>> It is bad practice to use echo $float or var_dump($float)
>>> because they depends on php.ini settings.
>>> You should use printf() of number_format() for deterministic result.
>
> $a = 69;
On 04/17/2007 10:16 PM, Sebastian Nohn wrote:
Dmitry Stogov wrote:
It is bad practice to use echo $float or var_dump($float)
because they depends on php.ini settings.
You should use printf() of number_format() for deterministic result.
You're converting float to string and THEN trying to ou
Dmitry Stogov wrote:
> It is bad practice to use echo $float or var_dump($float)
> because they depends on php.ini settings.
> You should use printf() of number_format() for deterministic result.
PHP 5.2.1:
-1689934592
2147483647
PHP 5.2.2:
-1689934592
6
- Sebastian
--
PHP Internals - PHP
Antony Dovgal wrote:
> On 04/17/2007 09:57 PM, Sean Coates wrote:
>>> lemme try this again. You can in no way rely on the last digits of
>>> a float
>>> output. Those depend on your system, your CPU, your ini settings and any
>>> operation you do with floats reduces the accuracy
>>
>> It's st
On 04/17/2007 09:57 PM, Sean Coates wrote:
lemme try this again. You can in no way rely on the last digits of a float
output. Those depend on your system, your CPU, your ini settings and any
operation you do with floats reduces the accuracy
It's still a regression, and should be documente
Marcus Boerger wrote:
Hello Sebastian,
lemme try this again. You can in no way rely on the last digits of a float
output. Those depend on your system, your CPU, your ini settings and any
operation you do with floats reduces the accuracy
yes .. but given no changes to all of the above men
Marcus Boerger wrote:
> lemme try this again. You can in no way rely on the last digits of a float
> output. Those depend on your system, your CPU, your ini settings and any
> operation you do with floats reduces the accuracy
If I do the same operation with the same ini setting on exakt the
2007. 04. 17, kedd keltezéssel 10.18-kor David Sklar ezt írta:
> My intention with the grace limit was to provide a graceful way of
> failing, not to continue processing in a reduced state -- as Stanislav
> said above, it could be difficult to do a lot after the allocation has
> failed.
What if t
> lemme try this again. You can in no way rely on the last digits of a float
> output. Those depend on your system, your CPU, your ini settings and any
> operation you do with floats reduces the accuracy
It's still a regression, and should be documented.
S
--
PHP Internals - PHP Runtime D
Hello Sebastian,
lemme try this again. You can in no way rely on the last digits of a float
output. Those depend on your system, your CPU, your ini settings and any
operation you do with floats reduces the accuracy
best regards
marcus
Tuesday, April 17, 2007, 7:45:57 PM, you wrote:
> Marc
Marcus Boerger wrote:
> float numbers are never perfect values. So should in anyway never rely
> on a certain output format. So there is nothing to document here.
We have a changed behavior here that should be documented. Otherwise
users will run into problems. As the non-academic example that
Hello Lukas,
float numbers are never perfect values. So should in anyway never rely
on a certain output format. So there is nothing to document here.
best regards
marcus
Tuesday, April 17, 2007, 10:16:39 AM, you wrote:
> Dmitry Stogov wrote:
>> It is bad practice to use echo $float or var_dum
In my current situation, bail out, but gracefully -- perhaps just send
a 302 to an error page and exit; maybe instead throw away the output
buffer and then directly output some friendly error text.
I think you can do it with shutdown handler, shouldn't it work? I.e. you
can do it this way:
1.
On Tue, April 17, 2007 9:55 am, Dmitry Stogov wrote:
> The float formatting algorithms were changed because of
> licensing issues and new ones are not 100% compatible with
> previous ones.
Could you please provide more details on that?
- Sebastian
--
PHP Internals - PHP Runtime Development Mai
Unless anyone sees a way to do this without adding the lock, I'd like to
commit this patch.
It adds a php_flock call only for windows. In doing so I got rid of the
win32/flock files and now compile with flock_compat from main.
Rob
Richard Quadling wrote:
The testing I'm using is to launch m
On 4/17/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Hey,
What is the status regarding reflection and spl. Do we still want to
allow disabling?
Most of its features could (should?) be moved to ZE2 as they are what
can be considered as part of the language. It is even more important
as some
Hannes Magnusson wrote:
>> 7. add E_STRICT to E_ALL DONE (dmitry)
>
> My dictionary says that "all" means *all*, not "all except this and
> this and sometimes not that".
E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this
confusion but in reality changing E_ALL to include every
On 17/04/07, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
On 4/17/07, Christian Schneider <[EMAIL PROTECTED]> wrote:
> Hannes Magnusson wrote:
> >> 7. add E_STRICT to E_ALL DONE (dmitry)
> >
> > My dictionary says that "all" means *all*, not "all except this and
> > this and sometimes not that".
>
Hey,
I have a few more questions:
Other Additions/Changes:
7. add E_STRICT to E_ALL DONE (dmitry)
Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED
in PHP 5.3. Once we do that I think this change should be adjusted to
only include E_DEPRECATED in E_ALL and not E_STRICT.
On 4/17/07, Christian Schneider <[EMAIL PROTECTED]> wrote:
Hannes Magnusson wrote:
>> 7. add E_STRICT to E_ALL DONE (dmitry)
>
> My dictionary says that "all" means *all*, not "all except this and
> this and sometimes not that".
E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid t
On 4/17/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Hey,
I have a few more questions:
Other Additions/Changes:
7. add E_STRICT to E_ALL DONE (dmitry)
Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED
in PHP 5.3. Once we do that I think this change should be adjusted
Fernando chucre wrote:
> I build a patch for wrapper php fopen. In this patch I create a way for
> the script access the filedescriptos opened by process. Ex:
I assume this is non-portable anyway so you could also simply use
something like "/dev/fd/7" instead of "php://fd/7" if you're on Linux or
Hey,
What is the status regarding reflection and spl. Do we still want to
allow disabling?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 4/16/07, Fernando chucre <[EMAIL PROTECTED]> wrote:
Hello all,
I build a patch for wrapper php fopen. In this patch I create a way for
the script access the filedescriptos opened by process. Ex:
php file.php 3file_out.txt
In this case the script can't read the filedescriptor 3 and 7. Not
ha
Hi,
FYI I have updated the todo list according to the recent discussions:
http://oss.backendmedia.com/index.php?area=PHPTODO&page=PhP60&view=diff&to=2007-04-17+10%3A47%3A32&from=2007-04-12+16%3A32%3A02
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 4/17/07, Peter Hodge <[EMAIL PROTECTED]> wrote:
Hello,
A soft memory limit could be very useful; it doesn't necessarily need to throw
an error, but it would provide an opportunity to free some memory and prevent
the script from crashing. Perhaps something like:
// function to call when me
Dmitry Stogov wrote:
It is bad practice to use echo $float or var_dump($float)
because they depends on php.ini settings.
You should use printf() of number_format() for deterministic result.
The float formatting algorithms were changed because of
licensing issues and new ones are not 100% compat
On 4/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> - in addition to a memory_limit configuration directive, there could
> be a "memory_limit_grace" configuration directive. This gets stored in
> the struct _zend_mm_heap, along with the limit.
That could be a problem because it's very ha
It is bad practice to use echo $float or var_dump($float)
because they depends on php.ini settings.
You should use printf() of number_format() for deterministic result.
The float formatting algorithms were changed because of
licensing issues and new ones are not 100% compatible with
previous one
39 matches
Mail list logo