VCS Account Rejected: sverbeek rejected by bjori /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
VCS Account Rejected: mehdone rejected by bjori /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I want to start reading the source code and contribute to the development of
the PHP runtime.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Mar 5, 2013 at 7:45 PM, David Muir wrote:
>
> When do you upgrade to a new release of php e.g. 5.3 -> 5.4
>> - As soon as released
>> - wait for the x.1 release
>> - Once our OpCode cache supports it
>> - When previous version hits EOL
>> - When a new feature warrants the upgra
When do you upgrade to a new release of php e.g. 5.3 -> 5.4
- As soon as released
- wait for the x.1 release
- Once our OpCode cache supports it
- When previous version hits EOL
- When a new feature warrants the upgrade
- When my Framework (Zend/Symfony/cake) or Software (Wordpress,
On Wed, Feb 20, 2013 at 1:54 PM, David Soria Parra wrote:
I ran into this myself and I personally consider date() assuming your
configured TZ A
bug.
The description for date() says "local time/date" => considering TZ is not a
bug.
Timestamps are defined as UTC and the behaviour of DateTime
>This is not the same at all. When are you going to run this code? Memory
>allocations happen all the time. What Nathan asked for is an event that is
>triggered when the memory consumption reaches a >threshold.
>
>However, there is a different solution, which is better IMHO in the case of
>caches
2013/3/5 Lazare Inepologlou
> 2013/3/5 Tom Boutell
>
> > Can't you do this already? memory_limit can be fetched via ini_read,
> > and together with memory_get_usage you should be able to check for
> > this sort of thing. Admittedly having to parse memory_limit (which can
> > be in various units)
2013/3/5 Tom Boutell
> Can't you do this already? memory_limit can be fetched via ini_read,
> and together with memory_get_usage you should be able to check for
> this sort of thing. Admittedly having to parse memory_limit (which can
> be in various units) is not perfect.
>
This is not the same
On Tue, 2013-03-05 at 12:23 -0600, nat...@starin.biz wrote:
> As PHP applications are turning into large frameworks one of the issues
> arriving is memory management. One of the issues is that many frameworks use
> sophisticated caching techniques to make accessing the same data quickly,
> this imp
Can't you do this already? memory_limit can be fetched via ini_read,
and together with memory_get_usage you should be able to check for
this sort of thing. Admittedly having to parse memory_limit (which can
be in various units) is not perfect.
On Tue, Mar 5, 2013 at 1:23 PM, wrote:
> As PHP appl
As PHP applications are turning into large frameworks one of the issues
arriving is memory management. One of the issues is that many frameworks use
sophisticated caching techniques to make accessing the same data quickly,
this improves speed it is at the cost of memory. Often the developer knows
t
On Fri, Feb 22, 2013 at 3:06 PM, Keyur Govande wrote:
> On Fri, Feb 22, 2013 at 2:59 PM, Hannes Magnusson <
> hannes.magnus...@gmail.com> wrote:
>
>> On Fri, Feb 22, 2013 at 11:52 AM, Rasmus Lerdorf
>> wrote:
>> > On 02/22/2013 11:48 AM, Hannes Magnusson wrote:
>> >> On Thu, Feb 21, 2013 at 4:42
Hi Everyone,
So I threw this idea out there, then I sat down and tried to come up with
questions I'd want answered. There's a bunch, those questions are easy.
Then I tried to focus my questions, I wanted questions that could possibly
affect or guide the development of PHP as a language. That got m
On Wed, Feb 20, 2013 at 1:54 PM, David Soria Parra wrote:
> On 2013-02-19, Stas Malyshev wrote:
>> Hi!
>>
>>> echo date_create('@1361240634')->format('Y-m-d');
>>> // output: 2013-02-19
>>>
>>> echo date('Y-m-d',1361240634);
>>> // output: 2013-02-18
>>
>> timestamp dates are created with UTC TZ,
Sorry, the correct one is bug #53437 ...
On Tue, March 5, 2013 12:42, Anatol Belski wrote:
> Hi,
>
>
> I've reworked the patch from
> http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff
> (mentioned by tony2001) for bug #63437, that seems to fix the issue. That
> patch was ported bac
Hi,
I've reworked the patch from
http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff
(mentioned by tony2001) for bug #63437, that seems to fix the issue. That
patch was ported back to 5.3 and adapted to the current 5.4+. Both
variants are posted to the ticket.
Also the test for bug
17 matches
Mail list logo
