Just a friendly prodding. Was this ever added?
Thanks,
Justin Martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Mark Karpeles wrote:
> http://php.magicaltux.net/browse/ (lots of memleaks reported on 5.3 &
> HEAD, seems to be glibc-related and not real memleaks, and this is not
> up-to-date as I didn't run the tests for a while and didn't automate it
> because it takes a lot of cpu)
Wondering why you did thi
On 27 Jun 2009, at 03:30, Mark Karpeles wrote:
Hi,
Le samedi 27 juin 2009 à 02:24 +0100, Scott MacVicar a écrit :
I think we should look at getting buildbot setup and deployed to as
many machines as humanly possible. It would at least give us a heads
up when we've written something that doesn'
Hi,
Le samedi 27 juin 2009 à 02:24 +0100, Scott MacVicar a écrit :
> I think we should look at getting buildbot setup and deployed to as
> many machines as humanly possible. It would at least give us a heads
> up when we've written something that doesn't work.
>
> You can see the ones for Goo
Hi,
Are there any resources that summarize the internal differences in the
unicode implementation (things like zend_u_hash_*, how to do strcmp()
with IS_UNICODE zvals, etc.)?
Also, since this is for ext/phar, I need to be able to convert to/from
unicode to binary easily (is this just changing the
Rasmus Lerdorf wrote:
> And 10 years ago I'd be hacking on this for the next 3 hours, but right
> now I am spending the next 3 hours picking up Carl from Lego Camp and
> taking him to his piano lesson...
What, no cello lesson?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To uns
On 26 Jun 2009, at 23:29, Hannes Magnusson wrote:
Hi all
Is there *anyone* who needs anything to be able to debug bug reports,
run sanitychecks, developing.. or whatever?
We really need to improve our architecture/platform/os testing, even
if its just "make all" compile checks.
On php-webmaste
Ilia Alshanetsky wrote:
> After some conversations with Rasmus on IRC i've come up with the
> following patch:
>
> http://ilia.ws/patch/curl.txt
>
> This basically forces flush() on the header & output streams right after
> curl_exec(), this ensures that the data retrieved by curl is synched to
>
Hi,
ok, just came home from some family business and on my way to bed, but
some general comments from my side, I will answer to individual things
tomorrow morning my time.
5.3 was branched off September 2007 and we aimed for releasing it
multiple times since then, just some random comment I r
After some conversations with Rasmus on IRC i've come up with the
following patch:
http://ilia.ws/patch/curl.txt
This basically forces flush() on the header & output streams right
after curl_exec(), this ensures that the data retrieved by curl is
synched to disk. The patch is also self con
Just to keep the list in synch with the irc discussion. I pointed out
that this is only half of the fix. The refcount still prevents fclose
from flushing the data, so if you do:
$url = 'http://slowgeek.com/test.xml';
$cfile = 'out.xml';
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_FILE, $fp =
Thanks Scott, it helps to save files before quitting ;-)
Here is the updated patch.
Ilia Alshanetsky
Index: ext/curl/interface.c
===
RCS file: /repository/php-src/ext/curl/interface.c,v
retrieving revision 1.62.2.14.2.57
diff -u -
You have an assignment instead of a comparison there.
Scott
On 27 Jun 2009, at 00:52, Ilia Alshanetsky wrote:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Here is the least intrusive fix I can come up for this bug. When doing
curl_close() the dtor will force flush of data on a file stream
synching the data to disk. As far as I can tell (using Rasmus'
example) this appears to adequately fix the problem and I see no
immediate side-effects.
In
I can provide multiple machines as well from single chip dual core to
quad chip quad core...
Sent from my iPhone
On Jun 26, 2009, at 3:29 PM, Hannes Magnusson > wrote:
Hi all
Is there *anyone* who needs anything to be able to debug bug reports,
run sanitychecks, developing.. or whatever?
Hi!
I have critical (no, not PHP-language critical) patches which I think
need to get into 5.3.0.
I found _39_ missing php.ini-both entries, and some missing deprecated
entries for the UPGRADING file.
See "my notes" at: http://pastebin.com/d7aa19753
I haven't "wasted" time on finding out wtf th
5.2 is already released so you can commit anyway.
For 5.3, I'm not sure (well I am), but wait until Johannes and Lukas
are back online please.
On Sat, Jun 27, 2009 at 12:15 AM, Andrei Zmievski wrote:
> Stanislav Malyshev wrote:
>>
>> You just did safe_address in _safe_malloc(nmemb, len, 0) which
Hi all
Is there *anyone* who needs anything to be able to debug bug reports,
run sanitychecks, developing.. or whatever?
We really need to improve our architecture/platform/os testing, even
if its just "make all" compile checks.
On php-webmaster@ we get a lot of companies who can provide us with
Stanislav Malyshev wrote:
You just did safe_address in _safe_malloc(nmemb, len, 0) which should
have called E_ERROR if nmemb*len overflows, so do you need to do it again?
Leaving a comment about it wouldn't hurt though :)
Yeah, you're right, but I didn't write the code. :) Regardless, I think
Pierre Joye wrote:
> On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf wrote:
>> Lukas Kahwe Smith wrote:
>>> Exactly.
>>> I will do my best to track things that need to be merged. Best is to
>>> note if something needs to be merged.
>>>
>>> But if you all feel it's such a huge burden then you can of
Hi!
pecalloc() uses the wrong length to zero out the memory. Patch is
attached, although I'm somewhat concerned about using just (nmemb*len)
instead of something like safe_address(nmemb*len), but safe_address() is
inlined in zend_alloc.c not in the header file.
You just did safe_address in _
same here :)
On Fri, Jun 26, 2009 at 11:32 PM, Andrei Zmievski wrote:
> Gwynne Raskind wrote:
>>
>> I'm proposing the inclusion of this patch in HEAD (which I'll port it to
>> if I get a thumbs-up here), and possibly 5.3.2. Criticism and angry flames
>> welcome. Constructive critcism and good-natu
Gwynne Raskind wrote:
I'm proposing the inclusion of this patch in HEAD (which I'll port it to
if I get a thumbs-up here), and possibly 5.3.2. Criticism and angry
flames welcome. Constructive critcism and good-natured comments will be
ignored ;) (just kidding... or am I?).
I'm fine with this
I found what is effectively a memory corruption bug in all the branches. pecalloc() uses
the wrong length to zero out the memory. Patch is attached, although I'm somewhat
concerned about using just (nmemb*len) instead of something like safe_address(nmemb*len),
but safe_address() is inlined in ze
I've just finished making this patch for my own use (diffed against
5.3 CVS):
http://darkrainfall.org/php-5.3-shellbypass.patch
In short, what it does is make proc_open()'s shell_bypass option
available to UNIX systems. This is accomplished by allowing the
"command" parameter to proc_open(
Hi
2009/6/26 Stanislav Malyshev :
> Hi!
>
> I see that ext/json functions are exported in 5.x branches but not exported
> in 6. Is there any specific reason for that?
I belive Andrei put in a UTODO in there about some additional work
that needed to be done while exporting them:
/*
* UTODO
* -
On Fri, Jun 26, 2009 at 22:35, Scott MacVicar wrote:
> If the reason that you're about to be given is, we might find something
> critical and need to re-roll 5.3.0 then branch from the tag you've created,
> fix what's needed and re-tag. Even though CVS sucks it does allow this.
Fair enough.
Howeve
this process is known and we already said that we have to change the
way we do it after 5.3.0.
On Fri, Jun 26, 2009 at 10:35 PM, Scott MacVicar wrote:
> I *completely* agree with making sure 5.3.0 is stable and stopping extra
> things sneaking their way in. I just don't like the way that it is bei
I *completely* agree with making sure 5.3.0 is stable and stopping
extra things sneaking their way in. I just don't like the way that it
is being done.
If the release is tagged and built, then why continue with the freeze?
Why not open it up for bug fixes towards 5.3.1?
If the reason that
you totally misunderstood the mail. The freeze is about the days
between now and the release itself on Tuesday (monday evening
actually). That's perfectly valid.
The idea then is to allow only bug fixes in 5.3.1, and only bug fixes.
What's wrong with that?
--
Pierre
On Fri, Jun 26, 2009 at 9:
Scott MacVicar wrote:
> If we're freezing some more after this release for the SVN conversion
> then we could have a pretty cold branch for another week or so.
>
> As I've already said, I agree with only allow verified bug fixes by
> Johannes into 5.3.0. it's this extra bureaucracy that is gettin
Hi!
I believe that Dmitry was interested in actually *replacing* the FastCGI
SAPI with it (or at least patching it 100%) - the configuration options
and "userland" usage of it is where I am not sure how it would "bundle"
with PHP properly. It uses a different config syntax (not ini compatible)
On Fri, Jun 26, 2009 at 12:14 PM, Stanislav Malyshev wrote:
> Hi!
>
> It would be great if someone would examine the impact of adopting it
>> as the FastCGI SAPI replacement or looking at what hooks are required
>> to get it in and perhaps keep the "userland" stuff in PECL...
>>
>
> Why it needs
On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote:
On 26.06.2009, at 20:26, Pierre Joye wrote:
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar
wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
Aloha,
So the last fix is just being prepared for a commit and so we
will be
tagging
Pierre Joye wrote:
> On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf wrote:
>> Lukas Kahwe Smith wrote:
>>> Exactly.
>>> I will do my best to track things that need to be merged. Best is to
>>> note if something needs to be merged.
>>>
>>> But if you all feel it's such a huge burden then you can of
On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf wrote:
> Lukas Kahwe Smith wrote:
>> Exactly.
>> I will do my best to track things that need to be merged. Best is to
>> note if something needs to be merged.
>>
>> But if you all feel it's such a huge burden then you can of course
>> insist on puttin
Hi!
It would be great if someone would examine the impact of adopting it
as the FastCGI SAPI replacement or looking at what hooks are required
to get it in and perhaps keep the "userland" stuff in PECL...
Why it needs to replace existing fcgi SAPI? I would think it is better
to have it just a
Lukas Kahwe Smith wrote:
> Exactly.
> I will do my best to track things that need to be merged. Best is to
> note if something needs to be merged.
>
> But if you all feel it's such a huge burden then you can of course
> insist on putting the burden on the RMs. The fact of the matter is that
> our
On 26.06.2009, at 20:26, Pierre Joye wrote:
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar
wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
Aloha,
So the last fix is just being prepared for a commit and so we will
be
tagging 5.3.0 soon.
We would like to up hold the commit
hi,
laziness is certainly the reason :)
Cheers,
--
Pierre
On Fri, Jun 26, 2009 at 8:41 PM, Stanislav Malyshev wrote:
> Hi!
>
> I see that ext/json functions are exported in 5.x branches but not exported
> in 6. Is there any specific reason for that?
> --
> Stanislav Malyshev, Zend Software Archi
Andrei has turned the project over to me, and I am trying to keep it
going full steam ahead.
Rasmus told me the only thing stopping it from being adopted into PHP
or PECL was the license. That has now changed.
I don't believe it can be done in PECL, as it needs too many changes
in PHP core.
It w
Hi!
I see that ext/json functions are exported in 5.x branches but not
exported in 6. Is there any specific reason for that?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar wrote:
> On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
>
>> Aloha,
>>
>> So the last fix is just being prepared for a commit and so we will be
>> tagging 5.3.0 soon.
>>
>> We would like to up hold the commit freeze until 5.3.0 is announced next
>
On Jun 26, 2009, at 2:22 PM, Hannes Magnusson wrote:
We would like to up hold the commit freeze until 5.3.0 is announced
next
Tuesday.
And the move to SVN? It'll require a complete cvs.php.net freeze for
couple of days, I think?
Yes, but it's not ready for that yet; an unfreeze after 5.3's
On Fri, Jun 26, 2009 at 17:26, Lukas Kahwe Smith wrote:
> We would like to up hold the commit freeze until 5.3.0 is announced next
> Tuesday.
And the move to SVN? It'll require a complete cvs.php.net freeze for
couple of days, I think?
-Hannes
--
PHP Internals - PHP Runtime Development Mailing
On 26-Jun-09, at 1:30 PM, Scott MacVicar wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
Aloha,
So the last fix is just being prepared for a commit and so we will
be tagging 5.3.0 soon.
We would like to up hold the commit freeze until 5.3.0 is announced
next Tuesday.
This
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
Aloha,
So the last fix is just being prepared for a commit and so we will
be tagging 5.3.0 soon.
We would like to up hold the commit freeze until 5.3.0 is announced
next Tuesday.
This freeze that you guys have implemented is frustrati
I have been looking through the curl changes. Nothing really jumps out
at me though. Jani's curl handle change perhaps? Doesn't seem like
that would cause this.
Anyway, here is a standalone little test case:
http://slowgeek.com/test.xml';
$cfile = '/var/tmp/test_'.$prefix.md5($url).'.xml';
$ch
Mikko Koppanen wrote:
> Hi,
>
> is there any objection on supporting multiple paths separated by path
> separator in PHP_INI_SCAN_DIR value? The patch seems to be quite trivial
> change in main/php_ini.c. Is this acceptable for 5.3 after the commit freeze
> is over?
ok by me
--
PHP Internals -
Aloha,
So the last fix is just being prepared for a commit and so we will be
tagging 5.3.0 soon.
We would like to up hold the commit freeze until 5.3.0 is announced
next Tuesday.
After this period bug fixes can be applied again. However feature
additions should wait until after 5.3.1, w
Hi,
is there any objection on supporting multiple paths separated by path
separator in PHP_INI_SCAN_DIR value? The patch seems to be quite trivial
change in main/php_ini.c. Is this acceptable for 5.3 after the commit freeze
is over?
--
Mikko Koppanen
51 matches
Mail list logo
