Am 06.12.2012 08:58, schrieb Stas Malyshev:
> I think 5.5, since we're not touching 5.4 that much anymore, especially
> not in the parser department.
I committed the patch to PHP-5.5 and merged it to master from there.
--
Sebastian BergmannCo-Founder and Principal Consultant
2012/11/29 Michael Wallner :
> On 29 November 2012 08:00, Yasuo Ohgaki wrote:
>> However, new code encapsulate output globals. (I mean internally)
>> It would be nice for my extension if output globals are exposed.
>
> This was changed intentionally, why would you need OG what the API
> does not p
hi!
While looking at the bug #63073, I was wondering if we could simply do
not pass open handles to the newly created child process.
The main issue in this bug is the session related handles. They are
passed to the parent process, which hangs until their are closed. It
indeed does not happen (us
I brought this up on #php.pecl yesterday and David already investigated
a bit but I thought I should probably bring this up here as well.
I cannot build PHP-5.5 with --enable-dtrace on Fedora 17, details are
here: https://gist.github.com/4214282
The build aborts with
gcc: error: unrecogn
Am 06.12.2012 09:56, schrieb Sebastian Bergmann:
> I cannot build PHP-5.5 with --enable-dtrace on Fedora 17, details are
> here: https://gist.github.com/4214282
Per Pierre's request, I have opened a ticket for this at
https://bugs.php.net/bug.php?id=63706
--
Sebastian Bergmann
I mean bug #44942. Sorry.
Also to clarify for non C devs. A handle could be an opened file, a
pipe or similar resources. Also important to keep in mind that users
have to pass their own streams to proc_open if they like to pass or
receive data.
On Thu, Dec 6, 2012 at 9:49 AM, Pierre Joye wrote:
On Thu, Dec 6, 2012 at 5:52 PM, Pierre Joye wrote:
> I mean bug #44942. Sorry.
>
> Also to clarify for non C devs. A handle could be an opened file, a
> pipe or similar resources. Also important to keep in mind that users
> have to pass their own streams to proc_open if they like to pass or
> rece
On Thu, Dec 6, 2012 at 7:02 PM, Laruence wrote:
> On Thu, Dec 6, 2012 at 5:52 PM, Pierre Joye wrote:
>> I mean bug #44942. Sorry.
>>
>> Also to clarify for non C devs. A handle could be an opened file, a
>> pipe or similar resources. Also important to keep in mind that users
>> have to pass their
On 06/12/12 09:49, Pierre Joye wrote:
> hi!
>
> While looking at the bug #63073, I was wondering if we could simply do
> not pass open handles to the newly created child process.
Looking at proc_open, where there is an explicit CreateProcess (we seem
to be using the library popen for the exec()...
hi,
On Thu, Dec 6, 2012 at 12:40 PM, Ángel González wrote:
> On 06/12/12 09:49, Pierre Joye wrote:
>> hi!
>>
>> While looking at the bug #63073, I was wondering if we could simply do
>> not pass open handles to the newly created child process.
>
> Looking at proc_open, where there is an explicit
Can someone remove the patch from this bug for me? While it fixes the
problem, it opens up some potential memory leaks, so I'd hate to see
it get implemented by mistake before I get a chance to fix that as
well.
Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
On 06/12/12 13:52, Pierre Joye wrote:
> hi,
>
> On Thu, Dec 6, 2012 at 12:40 PM, Ángel González wrote:
>> On 06/12/12 09:49, Pierre Joye wrote:
>>> hi!
>>>
>>> While looking at the bug #63073, I was wondering if we could simply do
>>> not pass open handles to the newly created child process.
>> Lo
Okay, here is the proper fixed patch, tested via various methods:
$d1 = new DateTime;
while(1) {
// no memory leak
$d1->modify("Tue, 10 Apr 2012 11:27:56 +0300");
// memory leak - now fixed with new patch
$d1->modify("Tue, 10 Apr 2012 11:27:56 CST");
// no memory leak
$d1->modi
hi,
On Thu, Dec 6, 2012 at 3:51 PM, Ángel González wrote:
> On 06/12/12 13:52, Pierre Joye wrote:
>> hi,
>>
>> On Thu, Dec 6, 2012 at 12:40 PM, Ángel González wrote:
>>> On 06/12/12 09:49, Pierre Joye wrote:
hi!
While looking at the bug #63073, I was wondering if we could simply d
Hi!
We've released PHP 5.3.20RC1 and 5.4.10RC1 which can be found here:
5.3.20RC1:
http://downloads.php.net/johannes/php-5.3.20RC1.tar.bz2
http://downloads.php.net/johannes/php-5.3.20RC1.tar.gz
5.4.10RC1:
http://downloads.php.net/stas/php-5.4.10RC1.tar.bz2
http://downloads.php.
On 2012-12-06, Sebastian Bergmann wrote:
> I brought this up on #php.pecl yesterday and David already investigated
> a bit but I thought I should probably bring this up here as well.
>
> I cannot build PHP-5.5 with --enable-dtrace on Fedora 17, details are
> here: https://gist.github.com/42142
Hey guys,
Please forgive me if this has already been addressed, but could somebody
tell me why all the methods for the Exception class are in camelCase? I
don't want to wade too deeply into the "consistency vs. BC" rabbit hole
here, but I'm just wondering what the general consensus is on this rig
On Thu, Dec 6, 2012 at 4:34 PM, Kris Craig wrote:
> Hey guys,
>
> Please forgive me if this has already been addressed, but could somebody
> tell me why all the methods for the Exception class are in camelCase? I
> don't want to wade too deeply into the "consistency vs. BC" rabbit hole
> here, b
On Thu, Dec 6, 2012 at 7:34 PM, Kris Craig wrote:
> Hey guys,
>
> Please forgive me if this has already been addressed, but could somebody
> tell me why all the methods for the Exception class are in camelCase? I
> don't want to wade too deeply into the "consistency vs. BC" rabbit hole
> here, b
On Thu, Dec 6, 2012 at 4:57 PM, Sherif Ramadan wrote:
> On Thu, Dec 6, 2012 at 7:34 PM, Kris Craig wrote:
>
>> Hey guys,
>>
>> Please forgive me if this has already been addressed, but could somebody
>> tell me why all the methods for the Exception class are in camelCase? I
>> don't want to wade
All,
I ended up leaving the vote open for a couple of extra days (been a
busy week), but I've now closed the ext/mysql deprecation vote. The
full results are at https://wiki.php.net/rfc/mysql_deprecation — the
short version is that the final vote was 25-12 in favour of
deprecation in PHP 5.5.
Thi
On Thu, Dec 6, 2012 at 10:19 PM, Adam Harvey wrote:
> All,
>
> I ended up leaving the vote open for a couple of extra days (been a
> busy week), but I've now closed the ext/mysql deprecation vote. The
> full results are at https://wiki.php.net/rfc/mysql_deprecation — the
> short version is that t
22 matches
Mail list logo
