apache version?
php version? thread safe, or nts?
does it crash with a hello world script, or only with your complex script.
if its crash only with your script, then we cant help without a testcase.
btw: I think you've chosen the wrong mailing list with your problem, the
internals mailing list is f
PHP 5.2.13 on Windows XP SP3 w/ Apache (PHP as a module) is crashing for
me. I've tried to create a simple test case to reproduce but I'm not
able to. Any hints/tips or a guide on how to debug this would be highly
appreciated. I'm not adverse to debuggers and I have VS2008
Professional on th
On 3/24/2010 6:41 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Wouldn't it suffice to add a field for the hash value and a flag that
>> indicates its validity to zval instead of appending zend_literal
>> everywhere?
>
> Enlarging zval would be costly (the engine uses tons of zvals) and may
> also be
Hi!
Wouldn't it suffice to add a field for the hash value and a flag that
indicates its validity to zval instead of appending zend_literal
everywhere?
Enlarging zval would be costly (the engine uses tons of zvals) and may
also be more complicated to track (all zval operations now would also
Hi!
I really do not see why this even needs a discussion. Its been in
trunk for years already. People have had plenty of time to give
feedback.
Is there really anyone who doesn't want this committed? For what reason?
I don't think there's a reason not to commit it - but it also would be
very
On 24.03.2010, at 21:26, Hannes Magnusson wrote:
> On Wed, Mar 24, 2010 at 21:12, Lukas Kahwe Smith wrote:
>>
>> On 24.03.2010, at 21:10, Hannes Magnusson wrote:
>>
>>> On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith
>>> wrote:
Hey,
Could one of you write up a short RFC on t
hi Hannes,
On Wed, Mar 24, 2010 at 9:10 PM, Hannes Magnusson
wrote:
> On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith wrote:
>> Hey,
>>
>> Could one of you write up a short RFC on this patch? Just some details about
>> the bugs fixed, known BC breaks and (undocumented) edge case changes. This
On Wed, Mar 24, 2010 at 21:12, Lukas Kahwe Smith wrote:
>
> On 24.03.2010, at 21:10, Hannes Magnusson wrote:
>
>> On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith wrote:
>>> Hey,
>>>
>>> Could one of you write up a short RFC on this patch? Just some details
>>> about the bugs fixed, known BC bre
On 24.03.2010, at 21:10, Hannes Magnusson wrote:
> On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith wrote:
>> Hey,
>>
>> Could one of you write up a short RFC on this patch? Just some details about
>> the bugs fixed, known BC breaks and (undocumented) edge case changes. This
>> would be helpf
On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith wrote:
> Hey,
>
> Could one of you write up a short RFC on this patch? Just some details about
> the bugs fixed, known BC breaks and (undocumented) edge case changes. This
> would be helpful for anyone wanting to review their code and testing as w
Hi,
Wouldn't it suffice to add a field for the hash value and a flag that
indicates its validity to zval instead of appending zend_literal
everywhere?
Moriyoshi
On Wed, Mar 24, 2010 at 11:12 PM, Zeev Suraski wrote:
> Hi,
>
> Over the last few weeks we've been working on several ideas we had for
On Wed, Mar 24, 2010 at 6:17 PM, Jani Taskinen wrote:
> 24.3.2010 12:54, Lukas Kahwe Smith wrote:
> > Hey,
> >
> > Could one of you write up a short RFC on this patch? Just some details
> about the bugs fixed, known BC breaks and (undocumented) edge case changes.
> This would be helpful for anyon
On 2010-03-24, Derick Rethans wrote:
> On Wed, 24 Mar 2010, Lukas Kahwe Smith wrote:
>
>> On 23.03.2010, at 23:04, Andi Gutmans wrote:
>>
>> > What about defining a release manager for the next release? I think that
>> > is an important aspect of moving things forward. I also thought the dual
>>
On Wed, Mar 24, 2010 at 10:26:45AM +0100, Pierre Joye wrote:
> As far as I can tell that's not only for the hash module. Many areas
> in php and its libraries rely on (u)int instead of size_t. It is or
> was a common mistake. The problem is to change the signature now
> without breaking ABI.
>
> T
Hi Lukas,
Hi Jonathan:
Just a quick response on the renaming issue.
On 24 Mar 2010, at 18:04, Jonathan Bond-Caron wrote:
> On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
>> The third sentence is not so clear to me, but if I guess it its also
>> just a typo as it makes more sense to me when re
On Wed, Mar 24, 2010 at 6:19 PM, Jani Taskinen wrote:
> 24.3.2010 12:02, Lukas Kahwe Smith wrote:
>>
>> On 23.03.2010, at 23:04, Andi Gutmans wrote:
>>
>>> What about defining a release manager for the next release? I think that
>>> is an important aspect of moving things forward. I also thought t
24.3.2010 12:02, Lukas Kahwe Smith wrote:
>
> On 23.03.2010, at 23:04, Andi Gutmans wrote:
>
>> What about defining a release manager for the next release? I think that
>> is an important aspect of moving things forward. I also thought the dual
>> RM in PHP 5.3 worked quite well although it is no
24.3.2010 12:54, Lukas Kahwe Smith wrote:
> Hey,
>
> Could one of you write up a short RFC on this patch? Just some details about
> the bugs fixed, known BC breaks and (undocumented) edge case changes. This
> would be helpful for anyone wanting to review their code and testing as well
> as docu
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
> The third sentence is not so clear to me, but if I guess it its also
> just a typo as it makes more sense to me when replacing "renaming" to
> "result in renaming". But maybe you could tweak that paragraph to be a
> bit clearer. For example its
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
> Ahoi,
>
> Thought it would be better to open up a new thread and also using the
> term "horizontal reuse" in the subject so that we make it clearer that
> there are actually two approaches. Here is the URL for Stefan's
> proposal:
> http://wiki.
Hi,
2010/3/24 Zeev Suraski :
> Hi,
>
> Over the last few weeks we've been working on several ideas we had for
> performance enhancements. We've managed to make some good progress. Our
> initial tests show roughly 10% speed improvement on real world apps. On
> pure OO code we're seeing as much as
Hi Rasmus,
Rasmus Lerdorf wrote:
On 03/24/2010 07:12 AM, Zeev Suraski wrote:
Hi,
Over the last few weeks we've been working on several ideas we had for
performance enhancements. We've managed to make some good progress. Our
initial tests show roughly 10% speed improvement on real world apps.
On 03/24/2010 08:09 AM, Felix De Vliegher wrote:
> Hi
>
> Ulf already indicated this in a bug report, but I'd like to bring it up here
> too:
> "There's no PHP 6 any more. What shall happen to those reports: close, bogus,
> test against 5.3, test against new trunk?"
>
> There's a lot of open PH
On 03/24/2010 07:12 AM, Zeev Suraski wrote:
> Hi,
>
> Over the last few weeks we've been working on several ideas we had for
> performance enhancements. We've managed to make some good progress. Our
> initial tests show roughly 10% speed improvement on real world apps. On
> pure OO code we're se
Hi,
I'm intending on doing some things to ext/dba as I've noticed there's a
few user notes about insert and update not working properly in some
cases, but as a starter, I have a patch to add the basics of Tokyo
Cabinet[1] support to ext/dba. It lets you use TC's abstract DB API, so
it can open more
Hi
Ulf already indicated this in a bug report, but I'd like to bring it up here
too:
"There's no PHP 6 any more. What shall happen to those reports: close, bogus,
test against 5.3, test against new trunk?"
There's a lot of open PHP6 / SVN snaps bugs, some of them obviously not valid
anymore wi
On 03/24/2010 08:01 AM, Martin Jansen wrote:
> Inspired by the recent addition of FNV hashing, I had a look at how hard
> it would be to add support for Jenkins's one-at-a-time hashing to
> ext/hash. The result is attached to this mail. I don't think I have
> karma for php-src, so given enough in
Inspired by the recent addition of FNV hashing, I had a look at how hard
it would be to add support for Jenkins's one-at-a-time hashing to
ext/hash. The result is attached to this mail. I don't think I have
karma for php-src, so given enough interest feel free to commit the patch.
- Martin
Index
Hi,
Over the last few weeks we've been working on
several ideas we had for performance
enhancements. We've managed to make some good
progress. Our initial tests show roughly 10%
speed improvement on real world apps. On pure OO
code we're seeing as much as 25% improvement (!)
While this s
On Wed, 24 Mar 2010, Lukas Kahwe Smith wrote:
> On 23.03.2010, at 23:04, Andi Gutmans wrote:
>
> > What about defining a release manager for the next release? I think that
> > is an important aspect of moving things forward. I also thought the dual
> > RM in PHP 5.3 worked quite well although it
On 24.03.2010, at 11:08, Pierre Joye wrote:
> skills. You suggested Chris and I think he could do a great job. My
Just to clarify as I mentioned this on IRC and not on here. I think it would be
great to have Chris Jones do the "organizational" co-RM. For one I have great
trust in him keeping a
Hey,
Could one of you write up a short RFC on this patch? Just some details about
the bugs fixed, known BC breaks and (undocumented) edge case changes. This
would be helpful for anyone wanting to review their code and testing as well as
documentation.
regards,
Lukas Kahwe Smith
m...@pooteeweet
Ahoi,
Thought it would be better to open up a new thread and also using the term
"horizontal reuse" in the subject so that we make it clearer that there are
actually two approaches. Here is the URL for Stefan's proposal:
http://wiki.php.net/rfc/horizontalreuse
"In case of the above definition o
At 12:08 24/03/2010, Pierre Joye wrote:
> Yeah, lets get that clarified. Derick has stepped up and seems
quite committed and nobody seemed to oppose him RMing the next
release. In case he feels he needs support he can propose a co-RM,
after all its important that the two RM's know and trust eac
Wait a sec,
As a previous maintainer, I dont believe I should really have as much
weight in this decision as the rest of the internals group. It does
seem like plenty enough discussion over this INI business. Theres now
over 40+ mails on this thread, mostly about ini. And this is not the
only disc
At 10:46 24/03/2010, Antony Dovgal wrote:
On 24.03.2010 11:29, Zeev Suraski wrote:
>>I think you're missing something.
>>
>>I don't care if FPM is in or out of the core.
>
> FWIW, I don't think it's a good start for a component that goes into
> our distribution.
> In this case I'm willing to tak
hi,
On Wed, Mar 24, 2010 at 11:02 AM, Lukas Kahwe Smith wrote:
>
> On 23.03.2010, at 23:04, Andi Gutmans wrote:
>
>> What about defining a release manager for the next release? I think that
>> is an important aspect of moving things forward. I also thought the dual
>> RM in PHP 5.3 worked quite w
On 23.03.2010, at 23:04, Andi Gutmans wrote:
> What about defining a release manager for the next release? I think that
> is an important aspect of moving things forward. I also thought the dual
> RM in PHP 5.3 worked quite well although it is not necessarily a must.
Yeah, lets get that clarif
hi Sean,
On Wed, Mar 24, 2010 at 7:48 AM, sean finney wrote:
> okay, so the hash module is generally broken for files > 2GB? didn't
> know that. i see update functions using both uint and size_t, but the
> function pointer signature uses uint so i doubt the hash results would
> be correct.
As
On 24.03.2010 11:29, Zeev Suraski wrote:
>>I think you're missing something.
>>
>>I don't care if FPM is in or out of the core.
>
> FWIW, I don't think it's a good start for a component that goes into
> our distribution.
> In this case I'm willing to take responsibility for doing the
> conversio
At 10:21 24/03/2010, Antony Dovgal wrote:
On 24.03.2010 01:16, Zeev Suraski wrote:
> For me it is a requirement before the code makes it into a released
> version of PHP, and I think many others think that way if past
> discussions are any indication. That's what RFCs are for - if people
> can
On 24.03.2010 01:16, Zeev Suraski wrote:
> For me it is a requirement before the code makes it into a released
> version of PHP, and I think many others think that way if past
> discussions are any indication. That's what RFCs are for - if people
> can just go ahead and implement their original
On 24.03.2010 09:36, Stanislav Malyshev wrote:
> fpm.myworker.server.start_servers = 20
> fpm.myworker.php_defines.memory_limit = 64M
>
> etc. It's not that bad.
"Not that bad" doesn't sound very convincing.
I'd personally prefer something better than that.
> As for spaces in pool names - come
On 24.03.2010, at 0:58, Antony Dovgal wrote:
> On 24.03.2010 00:05, Zeev Suraski wrote:
>>> How do you propose to describe the same set of options using php.ini syntax?
>>> Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine
>>> into php.ini.
>>> But how would decribe a set of po
44 matches
Mail list logo
