On Apr 6, 2012, at 5:23 PM, "Johannes Schlüter" wrote:
> Hi,
>
> On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote:
>>
>>
>> From what I've gathered thus far, it is impossible to do without
>> copying the non-persistent memory into persistent memory, and then
>> back again. I'm assuming this is
On Apr 6, 2012, at 5:16 PM, Stas Malyshev wrote:
Hi!
>From what I've gathered thus far, it is impossible to do without copying the
non-persistent memory into persistent memory, and then back again. I'm
assuming this is because all the memory associated with PHP variables use
emalloc, which p
-Original Message-
From: Reindl Harald [mailto:h.rei...@thelounge.net]
> Am 07.04.2012 01:30, schrieb Chris Stockton:
> > Hello,
> >
> > On Fri, Apr 6, 2012 at 3:08 PM, Reindl Harald
> > wrote:
> >>
> >>
> >> Am 06.04.2012 23:54, schrieb Tom Boutell:
> >>> On Fri, Apr 6, 2012 at 5:39 P
Hi,
On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote:
>
>
> From what I've gathered thus far, it is impossible to do without
> copying the non-persistent memory into persistent memory, and then
> back again. I'm assuming this is because all the memory associated
> with PHP variables use emall
Hi!
> From what I've gathered thus far, it is impossible to do without copying the
> non-persistent memory into persistent memory, and then back again. I'm
> assuming this is because all the memory associated with PHP variables use
> emalloc, which places it onto a stack that is disposed of at the
I've spent the last few days pouring over the Zend engine source code. I
think I have a basic understanding on the memory management. Likely what I
say may be incorrect, so I apologize in advance.
What I'm trying to do is write an extension to persist PHP variables past
the end of the request in t
Am 07.04.2012 01:30, schrieb Chris Stockton:
> Hello,
>
> On Fri, Apr 6, 2012 at 3:08 PM, Reindl Harald wrote:
>>
>>
>> Am 06.04.2012 23:54, schrieb Tom Boutell:
>>> On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald
>>> wrote:
>>
>> the "who" in such cases are ALL developers out there damned
>> c
Hello,
On Fri, Apr 6, 2012 at 3:08 PM, Reindl Harald wrote:
>
>
> Am 06.04.2012 23:54, schrieb Tom Boutell:
>> On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald wrote:
>
> the "who" in such cases are ALL developers out there damned
> can i send you the invoice for my time if your ideas
> would be re
> yes, i am not able to stop calling people to lazy writing whitespaces in front morons
The constant personal attacks are a violation of the mailing list rules. Nobody
likes getting this in their inbox. Please let's keep this civil.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime D
Am 06.04.2012 23:54, schrieb Tom Boutell:
> On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald wrote:
>> what do you expect by propose work for many people
> Oh I'm sorry, do we need to start every feature suggestion with a
> description of exactly who will do the work?
the "who" in such cases are
On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald wrote:
>
> what do you expect by propose work for many people
Oh I'm sorry, do we need to start every feature suggestion with a
description of exactly who will do the work?
> is it so hard to write
It is so embarrassing. Every time I type it a Ruby
Tom Boutell wrote:
Knock it off with the ad-hominem attacks please.
You are entitled to your views, but I suspect that this would be a nail far too
far. I for one would be only too happy to cut loose and keep a REAL copy of PHP
running as all this ballast is simply destroying what used to be
Am 06.04.2012 23:30, schrieb Tom Boutell:
> Knock it off with the ad-hominem attacks please.
what do you expect by propose work for many people
> It's not "change for the sake of change" to propose that PHP move on from
> needing (and breaking mysteriously in weird
> subtle ways if it's miss
I should have said "breaking mysteriously in weird subtle ways if
there are blank lines before wrote:
> Knock it off with the ad-hominem attacks please. It's not "change for
> the sake of change" to propose that PHP move on from needing the stop of every class file (and breaking mysteriously in w
Knock it off with the ad-hominem attacks please. It's not "change for
the sake of change" to propose that PHP move on from needing wrote:
> what exactly is your problem?
> having solution searching problem?
>
> what are people like you try to achieve?
> what would make you happy in breaking BC?
>
what exactly is your problem?
having solution searching problem?
what are people like you try to achieve?
what would make you happy in breaking BC?
what would you make happy generate lot of work for others?
what would be better for anybody?
change for the sake of the change is blindly stupid
Am
To tell the truth I'd be more excited by a proposal to kill wrote:
> I have to agree with that. Also: does PHP need to be a templating
> language anymore, given excellent templating language implementations
> in PHP, like Twig?
>
> On Fri, Apr 6, 2012 at 3:05 PM, John Crenshaw
> wrote:
>>> -
I have to agree with that. Also: does PHP need to be a templating
language anymore, given excellent templating language implementations
in PHP, like Twig?
On Fri, Apr 6, 2012 at 3:05 PM, John Crenshaw wrote:
>> -Original Message-
>> From: Sébatien Durand [mailto:sun...@live.com]
>> Sent:
> -Original Message-
> From: Sébatien Durand [mailto:sun...@live.com]
> Sent: Thursday, April 05, 2012 10:55 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] PHP as a template language
>
> IMHO, PHP is a great template language. This is what makes it so simple and
> powerful, compare
On Thu, Dec 8, 2011 at 14:58, Hannes Magnusson
wrote:
> On Fri, Sep 30, 2011 at 18:29, Michael Maclean wrote:
>> On 30/09/11 12:37, Hannes Magnusson wrote:
>>
>>> Preferably replace it with Kyoto Cabinet support I suppose.
>>
>>
>> I added the TC support initially, so I can look at replacing it o
Rasmus,
I think you're missing the difference here. Let's look at an exception.
try {
doFoo();
throwsException();
doBar();
} catch (Exception $e) {
doBaz();
}
This is NOT the same as:
doFoo();
throwsException('doBaz');
doBar();
To emulate the exception using continuation passi
2012/4/5 Anthony Ferrara :
> Why not just do:
>
> function foo(callable $callback) {
> $a = 0;
> $callback();
> $a = 1;
> $callback();
> }
>
> function bar() {
> foo(function() { echo 1; });
> }
>
> It's functionally the same, but doesn't have the stack magic.
>
> Now, it won't be ab
Hi:
and, yes, extension can change their code to alloc a zend_gc_info
size(what I do now).
however, I think, it's no need for zend_gc care about persistent
memorys, right?
thanks
On Fri, Apr 6, 2012 at 8:21 PM, Laruence wrote:
> Hi Dmitry:
>
> zend gc was introducted in 5.3
>
> thinki
Hi Dmitry:
zend gc was introducted in 5.3
thinking of a zval which is a Hashtable allocated by a extension in persistent,
and it also has hashtable children in it,
then , if the extension return this to php script:
array_init(return_value);
zend_hash_copy(Z_ARRVAL_P(return_value), Z_ARRVAL_P
Am 06.04.2012 04:55, schrieb Sébatien Durand:
> IMHO, PHP is a great template language. This is what makes it so simple
> and powerful, compared to other web languages.
>
> So far, we have "
> A suggestion : deprecate these old tags and replace them with a more
> elegant and a shorter impleme
25 matches
Mail list logo