Hi,
The arguments why to deprecate didn't seem much more than, this maybe could be
deprecated. I think there should usually be some
benefits of deprecating, otherwise why not just leave it as it is?
But some comments that I didn't notice in others.
>- php_uname (use PHP_OS constant)
PHP_OS
Hi,
> Even if you leave the interface as is and just pass the parameter
> additionally, it could have been extended by users just like in your example
> and pass a
> wrong value then.
Yes, it might. I don't come up an idea why, but maybe someone has had a reason,
as the json_encode calling won
Hi.
>> What BC break are you talking about? There is no need for using the
>> parameter in old codes. Even if we pass that depth to jsonSerialize
>> doing something like: "public function jsonSerialize() {...}" will still
>> work without any problems.
> That BC break: https://3v4l.org/L1u7q
And
Hi,
> This looks like a hack covering for deficient design. Having objects that
> look differently depending on hidden parameters without anybody explicitly
> modifying them is a recipe for very hard to track bugs. I don't think we
> should encourage this.
>
> There are ways to present serialize
Hi,
> I don't really like this. The reason is that you don't actually modify
> JsonSerializable interface for the obvious BC break that it would cause it.
> It means that the > function just gets this parameter and it kind of raises a
> question how we should document it? The solution would be
d
serialized.
If you are thinking why don't you just use the depth option of json_encode,
well unfortunately it doesn't help. It seems to go too deep and get recursion
errors and would just later limit the depth it's going as my example will show
if you try if you run it without
Hi,
On 21.12.2012 11:24, Patrick Schaaf wrote:
I understand your sentiment.
And I try to understand your technical point of view. I've thought
that PHP handles concurrent stuff so that those kind of things
won't happen and the user won't need to have for example mutexes
to do stuff.
But I thi
Hi,
On 21.12.2012 8:15, Patrick Schaaf wrote:
APC takes a LOCK_EX in exactly one place, apc_bin_dumpfile(), which does not
look to me like it's related to "include". The usage there is fishy anyway,
not exactly sure, but I think the open that happens before taking LOCK_EX,
will have truncated
S_CC);
- if (len != 0
+ if (0 && len != 0
#if HAVE_MMAP || defined(PHP_WIN32)
&& ((len - 1) % page_size) <= page_size - ZEND_MMAP_AHEAD
#endif
Without that patch the crash comes in under half minute.
And now I'm out of ideas of w
On 19.12.2012 22:27, Stas Malyshev wrote:
https://bugs.php.net/bug.php?id=52752
Just tried to reproduce it on Centos 6.2 install (without APC), works
just fine for me. I suspect it's some APC issue, does it reproduce for
you without APC loaded?
Yes, as I mentioned in previous message and in th
Hi,
I did come up with a problem in my server crashing with SIGBUS.
After long testing/tracing found:
https://bugs.php.net/bug.php?id=52752
Which seems to be totally the same! But for different enviroment.
Unfortunately that bug report seems to have only some workaround to
disable mmap(). I h
Hi,
I did come up with a problem in my server crashing with SIGBUS.
After long testing/tracing found:
https://bugs.php.net/bug.php?id=52752
Which seems to be totally the same! But for different enviroment.
Unfortunately that bug report seems to have only some workaround to
disable mmap(). I h
12 matches
Mail list logo
