On Tue, Feb 28, 2012 at 10:38 AM, Xinchen Hui wrote:
> On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
>> I initially looked at the final fix when I discovered the issue.
>> Follow me out on this. This is the current code as-implemented in
>> r323563:
>>
>> 265 zval *o
On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
> I initially looked at the final fix when I discovered the issue.
> Follow me out on this. This is the current code as-implemented in
> r323563:
>
> 265 zval *obj;
> 266 MAKE_STD_ZVAL(obj);
> 267
I initially looked at the final fix when I discovered the issue.
Follow me out on this. This is the current code as-implemented in
r323563:
265 zval *obj;
266 MAKE_STD_ZVAL(obj);
267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
Sent from my iPad
在 2012-2-28，0:10，Anthony Ferrara 写道：
> Out of curiosity, why are you changing it to copy the object for the
> result of the cast operation? cast_object should init the result
> zval, so why go through the step of copying the starting object to
plz look at the final fix： r32356
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to it?
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
On Mon, February 27, 2012 2:31 am, Laruence wrote:
> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
> wrote:
>> Hi Laruence,
>>
>> The attached patch looks wired. The patch on top of it (r323563)
>> makes it
>> better. However, in my opinion it fixes a common problem just in a
>> single
>> place.
On 02/27/2012 12:53 PM, Stas Malyshev wrote:
Hi!
so I think, maybe it's okey for a temporary fix :)
what I mean temporary is, apply this fix to 5.3 and 5.4
Don't apply anything to 5.4 now, please.
No, we are thinking about the trunk, and "temporary" fix for 5.4 is
delayed.
Thanks. Dmitr
On Mon, Feb 27, 2012 at 4:53 PM, Stas Malyshev wrote:
> Hi!
>
>
>>> so I think, maybe it's okey for a temporary fix :)
>>
>> what I mean temporary is, apply this fix to 5.3 and 5.4
>
>
> Don't apply anything to 5.4 now, please.
Sure, won't do it without your permission. :)
thanks
>
> --
> Stan
Hi!
so I think, maybe it's okey for a temporary fix :)
what I mean temporary is, apply this fix to 5.3 and 5.4
Don't apply anything to 5.4 now, please.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Deve
On Wed, 2012-02-15 at 07:09 -0800, Christopher Jones wrote:
> Of course it warrants a NEWS entry. Unless no one in the world was
> using it (in which case why have any code there?), a news entry will
> help explain a behavior difference, or identify when something broke
> (if you just accidentally
On Feb 15, 2012, at 1:07 AM, Michael Wallner wrote:
> On Tue, 14 Feb 2012 12:50:40 -0800, Christopher Jones wrote:
>
>> It would be great to have a NEWS entry and a testcase and a bug number.
>>
>
> Definitely.
>
> Seriously, there's no code in core using it, so there's no test case.
> ...a
On Wed, 15 Feb 2012 10:07:50 +0100, Michael Wallner wrote:
On Tue, 14 Feb 2012 12:50:40 -0800, Christopher Jones wrote:
It would be great to have a NEWS entry and a testcase and a bug number.
Definitely.
Seriously, there's no code in core using it, so there's no test case.
...and it's bee
On Wed, Feb 8, 2012 at 10:57 AM, Stas Malyshev wrote:
> Hi!
>
>
> We're in violent agreement. I don't think it's the right approach at
>> all — the right fix is to either fall back on ITIMER_REAL or come up
>> with some other approach on OS X — but I'm trying to come up with a
>> stopgap for 5.4.
Hi!
We're in violent agreement. I don't think it's the right approach at
all — the right fix is to either fall back on ITIMER_REAL or come up
with some other approach on OS X — but I'm trying to come up with a
stopgap for 5.4.0 to make sure the test is XFAILed where we already
know it fails as p
On 8 February 2012 04:09, Stas Malyshev wrote:
>> Specifically, how about the attached patch (also available at
>> http://www.adamharvey.name/patches/osx-max_execution_time-test-patch.diff,
>> in case the mailing list decides to strip it)? This only patches the
>> test to XFAIL this test on OS X,
Hi!
Specifically, how about the attached patch (also available at
http://www.adamharvey.name/patches/osx-max_execution_time-test-patch.diff,
in case the mailing list decides to strip it)? This only patches the
test to XFAIL this test on OS X, which makes the PHP_5_4 test suite
run without any un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> This following patch looks good to me:
> Derick, thanks ,
>
> Stas, should I commit this into 5.4 now or hold from ci until the
> release of 5.4?
Please wait for stas okay, but personally I want to see this committed.
>
> thanks
>>
>>> Index:
On Tue, Feb 7, 2012 at 6:00 PM, Derick Rethans wrote:
> On Mon, 6 Feb 2012, Laruence wrote:
>
>> there comes a new bug relate to this change, #60978, in php_cli.c
>>
>> case PHP_MODE_CLI_DIRECT:
>> cli_register_file_handles(TSRMLS_C);
>> if (zend_eval_string_ex(ex
On Mon, 6 Feb 2012, Laruence wrote:
> there comes a new bug relate to this change, #60978, in php_cli.c
>
>case PHP_MODE_CLI_DIRECT:
> cli_register_file_handles(TSRMLS_C);
> if (zend_eval_string_ex(exec_direct, NULL, "Command line
> code", 1 TSRMLS_CC) == FAILUR
On 3 February 2012 12:15, Adam Harvey wrote:
> On 3 February 2012 12:05, Stas Malyshev wrote:
>>> For me at least, tests/func/005a.phpt is the last failing test on
>>> PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
>>> pre-5.4.0 to help get cleaner test suite results.
>>
>
On Tue, Feb 7, 2012 at 1:47 AM, Stas Malyshev wrote:
> Hi!
>
>
>> there comes a new bug relate to this change, #60978, in php_cli.c
>
>
> I'm not sure this bug is critical enough to keep messing with the code base
> this close to the release. Could you please describe what is the current
> stat
Hi!
there comes a new bug relate to this change, #60978, in php_cli.c
I'm not sure this bug is critical enough to keep messing with the code
base this close to the release. Could you please describe what is the
current status, what was before the fix and what exactly the problems
are her
Hi Derick:
On Sun, Jan 29, 2012 at 1:03 AM, David Soria Parra wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thank you for catching that. Please go ahead and commit!.
>
> Thanks
>
> On 01/28/2012 04:00 PM, Derick Rethans wrote:
>> Hi David,
>>
>> When I was just checking PHP 5.4 com
On 3 February 2012 12:05, Stas Malyshev wrote:
>> For me at least, tests/func/005a.phpt is the last failing test on
>> PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
>> pre-5.4.0 to help get cleaner test suite results.
>
>
> I really wouldn't want to hold the release for an
Hi!
I've been trying to run down tests/func/005a.phpt failing this
morning, and obviously this is the cause. I don't have a Lion machine
to hand to test this there, but it does look like ITIMER_PROF is
completely broken on OS X 10.6.7 and 10.6.8.
Yes, this test is broken and looks like somethi
(Resurrecting a very old thread. Sorry about the thread necromancy.)
On 8 September 2011 05:20, Rasmus Lerdorf wrote:
> On 09/07/2011 02:12 PM, Stas Malyshev wrote:
>> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
>> itimer implementation at least up to kernel 10.8.0, Ma
On Tue, Dec 27, 2011 at 16:48, Sebastian Bergmann wrote:
> Am 27.12.2011 16:36, schrieb Sebastian Bergmann:
>> And PHP_5_3 does not need this?
>
> I am asking because I cannot build PHP_5_3 with ext/intl on Fedora 16.
Hmh. Do they not ship with PHP5.3?
I would have expect them to submit a build
Am 27.12.2011 16:36, schrieb Sebastian Bergmann:
> And PHP_5_3 does not need this?
I am asking because I cannot build PHP_5_3 with ext/intl on Fedora 16.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://t
Le 26/12/2011 14:09, Pierre Joye a écrit :
> Attached patch should fix this problem but I'm not sure if we have to
> do it in RINIT instead. The handler is set to NULL on dtor, so it
> could be enough already to do it once in MINIT.
At least, it fix the build/run issue.
Thanks.
--
PHP Internals -
hi Remi!
Thanks for the headup!
Attached patch should fix this problem but I'm not sure if we have to
do it in RINIT instead. The handler is set to NULL on dtor, so it
could be enough already to do it once in MINIT.
Cheers,
On Mon, Dec 26, 2011 at 1:52 PM, Remi Collet wrote:
> With 321411 appl
With 321411 applied
(gdb) run -n -m
Starting program: /dev/shm/php5.4-201112261030/build-zts/sapi/cli/php -n -m
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[PHP Modules]
bz2
calendar
Core
... ...
zlib
[Zend Modules]
Program received
I've just noticed that we had a related bugreport, I thought that I
should mention it:
https://bugs.php.net/bug.php?id=55479
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2011/9/15 Hannes Magnusson :
> On Wed, Sep 14, 2011 at 12:36, Alexey Shein wrote:
>> 2011/9/14 Ferenc Kovacs :
Why do we even have this tmp-php.ini? Why not just make test without
any .ini files, i.e. just with -n option?
>>>
>>> [20:44:09] Tyrael: tmp-php.ini is built from the sys
On Thu, Sep 15, 2011 at 12:07 PM, Hannes Magnusson
wrote:
> Running tests exclusively in an environment known to work doesn't help us.
It indeed does, and much more than random failures in random environments.
However it is not about one or the other, it is about both and about
having as much t
On Wed, Sep 14, 2011 at 12:36, Alexey Shein wrote:
> 2011/9/14 Ferenc Kovacs :
>>>
>>> Why do we even have this tmp-php.ini? Why not just make test without
>>> any .ini files, i.e. just with -n option?
>>
>> [20:44:09] Tyrael: tmp-php.ini is built from the system ini
>> [20:44:45] Tyrael: if he
On 13 September 2011 17:27, Pierre Joye wrote:
> hi,
>
> On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
>> Hi!
>>
>> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>>
>>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>>> The make test should create tmp-php.ini for y
2011/9/14 Ferenc Kovacs :
>>
>> Why do we even have this tmp-php.ini? Why not just make test without
>> any .ini files, i.e. just with -n option?
>
> [20:44:09] Tyrael: tmp-php.ini is built from the system ini
> [20:44:45] Tyrael: if he builds php with
> --with-config-file-scan-dir=/where/ever/he
>
> Why do we even have this tmp-php.ini? Why not just make test without
> any .ini files, i.e. just with -n option?
[20:44:09] Tyrael: tmp-php.ini is built from the system ini
[20:44:45] Tyrael: if he builds php with
--with-config-file-scan-dir=/where/ever/he/has/another/php.ini, then
it will u
2011/9/13 Ferenc Kovacs :
> On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
>> Hi!
>>
>> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>>
>>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>>> The make test should create tmp-php.ini for you (and copy your
>>
>> Everyb
no problem, I just mentioned because it is easier to remember, and it
should take care of the similar problems.
On Wed, Sep 14, 2011 at 9:08 AM, Christian Stocker
wrote:
>
>
> On 14.09.11 09:00, Ferenc Kovacs wrote:
>> ./vcsclean && ./buildconf --force
>
> ok, that helped. Thanks a lot and I shou
On 14.09.11 09:00, Ferenc Kovacs wrote:
> ./vcsclean && ./buildconf --force
ok, that helped. Thanks a lot and I should have known that
chregu
>
> On Wed, Sep 14, 2011 at 8:07 AM, Laruence wrote:
>> Hi,
>> FYI, you might should delete the autom4te.cache folder too :-)
>>
>> thanks
>>
>> 2011
./vcsclean && ./buildconf --force
On Wed, Sep 14, 2011 at 8:07 AM, Laruence wrote:
> Hi,
> FYI, you might should delete the autom4te.cache folder too :-)
>
> thanks
>
> 2011/9/14 Christian Stocker :
>> Hi
>>
>> I still have this. even after re-running buildconf (and deleting
>> configure before)
Hi!
On 9/13/11 1:11 PM, Ferenc Kovacs wrote:
Stas, I commited my patch again with the addition --INI-- setting:
http://news.php.net/php.cvs/66511
could you test it?
Passes for me.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Intern
On Tue, Sep 13, 2011 at 8:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 11:04 AM, Ferenc Kovacs wrote:
>>
>> as I mentioned before, make test (at least it should) passes the -n -c
>> argument to run-tests.php
>> see
>> http://svn.php.net/viewvc/php/php-src/trunk/Makefile.global?view=markup#l104
On Tue, Sep 13, 2011 at 8:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 11:04 AM, Ferenc Kovacs wrote:
>>
>> as I mentioned before, make test (at least it should) passes the -n -c
>> argument to run-tests.php
>> see
>> http://svn.php.net/viewvc/php/php-src/trunk/Makefile.global?view=markup#l104
Hi!
On 9/13/11 11:04 AM, Ferenc Kovacs wrote:
as I mentioned before, make test (at least it should) passes the -n -c
argument to run-tests.php
see http://svn.php.net/viewvc/php/php-src/trunk/Makefile.global?view=markup#l104
which means if you run make test that can produce different result,
than
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>
>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>> The make test should create tmp-php.ini for you (and copy your
>
> Everybody has custom php.ini, what do you
hi,
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>
>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>> The make test should create tmp-php.ini for you (and copy your
>
> Everybody has custom php.ini, what do
Hi!
On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
Stas, I still don't know why do have a custom php.ini, and why is it used.
The make test should create tmp-php.ini for you (and copy your
Everybody has custom php.ini, what do you mean "why"? Nobody uses just
defaults. It is used because -n -c is n
After a discussion on irc, I was thinking about something similar:
adding my patch back, but adding -error-log to the --INI--
Stas, I still don't know why do have a custom php.ini, and why is it used.
The make test should create tmp-php.ini for you (and copy your
additional ini files there if you p
Just wanted to say, that I managed to reproduce your results for
./PHP_5_4/ext/session/tests/rfc1867_invalid_settings.phpt by adding
date.timezone=UTC
error_log=file
settings into --INI-- section, this way test passes. I.e. logged
message should go into the file and do not mess the output which is
I forget to reply-all to the list :/
On Mon, Sep 12, 2011 at 7:46 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/12/11 3:14 AM, Ferenc Kovacs wrote:
>>
>> you should pass both -n and -c as the make test pass those to the
>> run-tests.php AFAIK, see:
>
> That's not what I see happening.
>
>> as I mention
Hello, these tests fail for me too, ubuntu 11.04 x86, both trunk and
5.4 branches.
2011/9/12 Ferenc Kovacs :
> On Sun, Sep 11, 2011 at 11:04 PM, Stas Malyshev
> wrote:
>> Hi!
>>
>> On 9/11/11 8:44 AM, Ferenc Kovacs wrote:
>>>
>>> AFAIK you shoud get it(as I did on my debian machines), as both
>>
On Wed, Sep 7, 2011 at 11:20 PM, Rasmus Lerdorf wrote:
> On 09/07/2011 02:12 PM, Stas Malyshev wrote:
>> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
>> itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8.
>> Didn't try it on Lion, maybe the have updated/
On 09/07/2011 02:12 PM, Stas Malyshev wrote:
> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
> itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8.
> Didn't try it on Lion, maybe the have updated/fixed it.
Right, so we need to decide what to do about that.
Hi!
On 9/7/11 2:01 PM, Rasmus Lerdorf wrote:
I am curious, what do you see when you strace it?
On Linux you get:
Darwin has no strace. dtruss is not very helpful:
83310/0x43ee45: 32798 11 7 munmap(0x208B000, 0x11E)
= 0 0
83310/0x43ee45: 32805 9 6 close_n
On 09/07/2011 01:32 PM, Stas Malyshev wrote:
> Hi
>
> On 9/7/11 1:17 PM, Rasmus Lerdorf wrote:
>>
>> Interesting that this is different on Darwin. That doesn't seem like
>> something that should be OS-specific unless Darwin's itimer
>> implementation is messed up.
>
> Looks like it might be the c
Hi
On 9/7/11 1:17 PM, Rasmus Lerdorf wrote:
Interesting that this is different on Darwin. That doesn't seem like
something that should be OS-specific unless Darwin's itimer
implementation is messed up.
Looks like it might be the case:
http://openradar.appspot.com/9336975
REAL timer works, o
On 09/07/2011 01:04 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:43 PM, Rasmus Lerdorf wrote:
>> Actually, it seems to be more than that. That set_time_limit() just
>> speeds up the test. Since we have a default max_execution_time you
>> should still have hit that and the shutdown function shou
Hi!
On 9/7/11 12:43 PM, Rasmus Lerdorf wrote:
Actually, it seems to be more than that. That set_time_limit() just
speeds up the test. Since we have a default max_execution_time you
should still have hit that and the shutdown function should have been
called. But your other max_execution_time-rel
On 09/07/2011 12:28 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
>>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
>>> fails. It's on Darwin.
>>
>> That one doesn't fail for me. What's your diff?
>
> 002+
> 002- Shutdown
> 003+ ** ERROR: pro
On 09/07/2011 12:28 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
>>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
>>> fails. It's on Darwin.
>>
>> That one doesn't fail for me. What's your diff?
>
> 002+
> 002- Shutdown
> 003+ ** ERROR: pro
Hi!
On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
fails. It's on Darwin.
That one doesn't fail for me. What's your diff?
002+
002- Shutdown
003+ ** ERROR: process timed out **
It looks like set_time_limit(1) doesn't work.
--
On 09/07/2011 12:16 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 11:54 AM, Rasmus Lerdorf wrote:
>> Please help me figure out if this fix causes any weird side-effects
>> anywhere. Essentially the problem is that the new deferred signals
>> patch ignores signals when running signal handlers. But s
Hi!
On 9/7/11 11:54 AM, Rasmus Lerdorf wrote:
Please help me figure out if this fix causes any weird side-effects
anywhere. Essentially the problem is that the new deferred signals
patch ignores signals when running signal handlers. But since
register shutdown functions are called by the signal
hi,
the main problem is that the (stupid) windows filesystem APIs consider
" foo", "foo " as being the same than "foo". It has caused all kind of
bad effects and we added checks in some areas already in 5.3.
Now that 5.4 has a "p" parameter we can simply cleanup the given paths
before passing it
Em Wed, 07 Sep 2011 13:41:45 +0100, Hannes Magnusson
escreveu:
On Wed, Sep 7, 2011 at 14:33, Pierre Joye wrote:
pajoye Wed, 07 Sep 2011 12:33:22 +
Revision: http://svn.php.net/viewvc?view=revision&revision=316345
Log:
- reject paths with trainling spa
On 09/06/2011 09:54 PM, Andrey Hristov wrote:
On 09/06/2011 09:08 PM, Stas Malyshev wrote:
Hi!
On 9/6/11 11:05 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it
looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->stat
On 09/06/2011 09:08 PM, Stas Malyshev wrote:
Hi!
On 9/6/11 11:05 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it
looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->data ==
Hi!
On 9/6/11 11:05 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->data == NULL))
When I step through your code, r->dat
Stas,
On 09/06/2011 06:55 PM, Stas Malyshev wrote:
Hi!
On 9/6/11 2:46 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->da
Hi!
On 9/6/11 2:46 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->data == NULL))
When I step through your code, r->data
On 09/06/2011 11:16 AM, Stas Malyshev wrote:
Hi!
Have you actually checked what libmysql returns??!?
If _you_ just have tried to do it, you might actually find that
libmysql does what mysqlnd did long ago, but mysqli was hiding it.
Here is output from what libmysql does, after removing the foll
Hi,
aside from the actual question: run-tests.php already makes heavy usage
of realpath, so it's impossible to run the tests on a system without
realpath.
$ grep realpath run-tests.php | wc -l
14
johannes
On Sun, 2011-09-04 at 16:41 +0200, Ferenc Kovacs wrote:
> Sorry, for the late reply, I
On Sun, Sep 4, 2011 at 22:38, Stas Malyshev wrote:
> Hi!
>
> On 9/4/11 1:35 PM, Kalle Sommer Nielsen wrote:
>>
>> But if its possible to always be available in ZTS, what would the
>> reasoning for it not to be available in NTS? I haven't dug into the
>> code that deeply so I'm just curious.
>
> My
Hi!
On 9/4/11 1:35 PM, Kalle Sommer Nielsen wrote:
But if its possible to always be available in ZTS, what would the
reasoning for it not to be available in NTS? I haven't dug into the
code that deeply so I'm just curious.
My guess - ZTS has virtualized directory handling system (VCWD), NTS
d
Hi Pierre
2011/9/4 Pierre Joye :
> Afaict It is actually always available in userland, but maybe the OS
> realpath function may not be available, but that does not affect
> userland's realpath.
http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/standard/file.c#2275
According to that its commented ou
On Sun, Sep 4, 2011 at 5:11 PM, Ferenc Kovacs wrote:
> it seems that we have more tests using realpath already, what would be
> the best approach here?
> for middle/long term, it would be good to have realpath working on all
> supported platforms, because imo thats a pretty basic function.
Afaic
On 7/19/2011 5:09 PM, Pierre Joye wrote:
On Wed, Jul 20, 2011 at 1:50 AM, Scott MacVicar wrote:
OpenSSL has been FIPS certified, your change has changed this contract and it's
calling back into a Windows API. Has it been reviewed for correctness?
And by the way, the CryptoAPI for the windows
On 07/19/2011 07:09 PM, Pierre Joye wrote:
On Wed, Jul 20, 2011 at 1:50 AM, Scott MacVicar wrote:
OpenSSL has been FIPS certified, your change has changed this contract and it's
calling back into a Windows API. Has it been reviewed for correctness?
And by the way, the CryptoAPI for the window
OK. As I said I don't have strong opinion about this.
So fell free to remove the warning.
Thanks. Dmitry.
On 07/11/2011 12:18 PM, Stas Malyshev wrote:
Hi!
That warning might be only emitted if the first operand is a name of non
existing class.
is_a("NonExistingClass", "MyClass");
I think y
Hi Stas,
On 07/11/2011 11:25 AM, Stas Malyshev wrote:
Hi!
On 7/11/11 12:18 AM, Dmitry Stogov wrote:
Hi Ralph,
I don't have strong opinion about your suggestion.
In some cases this warning might help to find a typo, in others it may
be useless, but anyway, I think that usage of undefined clas
Hi!
That warning might be only emitted if the first operand is a name of non
existing class.
is_a("NonExistingClass", "MyClass");
I think you've missed my point. The point was people use this to check
if first argument is an instance of a certain class or something else -
and "something els
On Mon, Jul 11, 2011 at 09:25, Stas Malyshev wrote:
> Hi!
>
> On 7/11/11 12:18 AM, Dmitry Stogov wrote:
>>
>> Hi Ralph,
>>
>> I don't have strong opinion about your suggestion.
>>
>> In some cases this warning might help to find a typo, in others it may
>> be useless, but anyway, I think that usag
Hi!
On 7/11/11 12:18 AM, Dmitry Stogov wrote:
Hi Ralph,
I don't have strong opinion about your suggestion.
In some cases this warning might help to find a typo, in others it may
be useless, but anyway, I think that usage of undefined class name is a
quite rare situation. I would prefer to keep
Hi Ralph,
I don't have strong opinion about your suggestion.
In some cases this warning might help to find a typo, in others it may
be useless, but anyway, I think that usage of undefined class name is a
quite rare situation. I would prefer to keep it as is.
Thanks. Dmitry.
On 07/08/2011 06
Oh by all means, kill the warning. The behavior is sound though (the fix
for the issue reported in #53727 where a missing parent *ce would affect
the is_a_impl()'s ability to correctly determine it's subtype.
The question is, should we keep the warning in 5.4? I'd say no, I think
false should
Hi Folks:
On Thu, Jul 07, 2011 at 02:20:50PM -0700, Stas Malyshev wrote:
>
> In fact, I'm not sure why would we need such warning at all. Unknown
> class - return false, who cares?
+1
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intens
Hi!
On 7/7/11 2:08 PM, Johannes Schlüter wrote:
On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
what kind of troubles do they see?
https://pear.php.net/bugs/bug.php?id=18656
Even if the Warning is good it's questionable for 5.3, especially during
RC.
Yes, I had problem with it too in
On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
> what kind of troubles do they see?
https://pear.php.net/bugs/bug.php?id=18656
Even if the Warning is good it's questionable for 5.3, especially during
RC.
(note that warnings not only cause the error being reported, which can
be switched off
what kind of troubles do they see?
2011/7/7 Johannes Schlüter :
> Hi,
>
> I was told (didn't verify) that this causes lots of trouble with PEAR
> and other applications. We're in final RC phase of 5.3.7. I don't think
> it is critical for 5.3.7 and I wonder whether we need it for 5.3 at all.
>
> j
Hi!
It is still useful for array | class/interface name. Or?
Not really, since it returned only "array" or "object", while real class
is returned by getClass() and isArray() returns if it's an array. We
could have method that returns class name or "array" if it's an array,
but that'd be d
2011/6/5 Sebastian Bergmann
> Am 05.06.2011 10:59, schrieb Stanislav Malyshev:
> > stas Sun, 05 Jun 2011 08:59:24 +
> >
> > Revision: http://svn.php.net/viewvc?view=revision&revision=311824
> >
> > Log:
> > This method doesn't seem to be very useful without
On Tue, 2011-02-01 at 01:04 +0100, Pierre Joye wrote:
> On Mon, Jan 31, 2011 at 11:33 PM, Stas Malyshev
> wrote:
>
> >> But I strongly believe in a threaded base solution for windows. That's
> >> the only way to get anywhere close to the performance we can see on
> >> other platforms (read: posi
On Tue, Feb 1, 2011 at 10:23 AM, Stas Malyshev wrote:
> Though, of course, maybe I'm wrong - what would you suggest is the problem
> then? I saw similar slowdowns on 1-process benchmarks as on multi-process
> server benchmarks - so I have hard time believing it has anything to do with
> threading
Hi!
This delta has very little impact on real world apps except those
doing exclusively such ops.
The benchmarks I did suggest otherwise. Real world apps do huge number
of file ops like file_exists(). And while many apps aggressively cache
DB calls and such, filesystem calls are still there.
On Tue, Feb 1, 2011 at 9:53 AM, Stas Malyshev wrote:
> Hi!
>
>> The filesystem issues are mostly due to what we do in TS mode, way too
>> much pointless operations, even if the real cache helps a little bit
>> here (take this comment with a bit of salt: as in delta with the cache
>> between TS and
Hi!
The filesystem issues are mostly due to what we do in TS mode, way too
much pointless operations, even if the real cache helps a little bit
here (take this comment with a bit of salt: as in delta with the cache
between TS and NTS).
What we do in TS mode with filesystem that could explain t
Hi Pierre:
On Mon, Jan 31, 2011 at 08:43:40PM +0100, Pierre Joye wrote:
>
> It does not matter what is the latest VC version. What matters is that
> VC6 is a dead cow and we won't support it anymore, even for the
> current stable, 5.3. And to be honest I don't really care about
> Apache.org's use
On Mon, Jan 31, 2011 at 11:33 PM, Stas Malyshev wrote:
>> But I strongly believe in a threaded base solution for windows. That's
>> the only way to get anywhere close to the performance we can see on
>> other platforms (read: posix).
>
> My experience is that performance differnces between Window
1 - 100 of 167 matches
Mail list logo
