Oooo. Would be nice if that could make it into the manual.
--Wez.
On 5/10/06, Sara Golemon <[EMAIL PROTECTED]> wrote:
> I'd like to add a function that returns tsrm_thread_id().
> It would be present in ZTS builds only, and could be used
> by code that needs to generate "unique" identifiers.
>
I'd like to add a function that returns tsrm_thread_id().
It would be present in ZTS builds only, and could be used
by code that needs to generate "unique" identifiers.
I'm open for ideas on what to name it; sys_get_thread_id()
or something?
How about zend_thread_id()? (Present since 5.0.0)
I
On 5/8/06, Antony Dovgal <[EMAIL PROTECTED]> wrote:
Agree, we need to enable it by default, otherwise including it in the core
doesn't make much sense.
Please read my answers in this thread and my post from today about the
current filter status.
--Pierre
--
PHP Internals - PHP Runtime Devel
On 07.05.2006 20:27, Derick Rethans wrote:
On Sun, 7 May 2006, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
> Well that can still work, we can access the data from PG(http_globals)
> without having to duplicate the data at the onset.
Not if we don't enable the extension which is what we are t
On Sun, 7 May 2006, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote:
> > Well that can still work, we can access the data from PG(http_globals)
> > without having to duplicate the data at the onset.
>
> Not if we don't enable the extension which is what we are talking about.
Well, we should enabl
Ilia Alshanetsky wrote:
Well that can still work, we can access the data from PG(http_globals)
without having to duplicate the data at the onset.
Not if we don't enable the extension which is what we are talking about.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
On 7-May-06, at 11:53 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
On 7-May-06, at 11:02 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
I am +0 on these two extensions, hence the "to be discussed", as
long as they are not enabled by default I see no problem with
symlinking them in
Hello,
On 5/7/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
What impact would it have on the speed of input processing if it is
always there, but not doing anything? I'd prefer to avoid adding
extra overhead for something that does nothing by default, we have
enough performance issues as is i
Ilia Alshanetsky wrote:
On 7-May-06, at 11:02 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
I am +0 on these two extensions, hence the "to be discussed", as long
as they are not enabled by default I see no problem with symlinking
them in.
I'd like to see the json extension enabled by d
On 7-May-06, at 11:02 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
I am +0 on these two extensions, hence the "to be discussed", as
long as they are not enabled by default I see no problem with
symlinking them in.
I'd like to see the json extension enabled by default. It's a
trivi
On Sun, 7 May 2006, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote:
> > I am +0 on these two extensions, hence the "to be discussed", as long as
> > they are not enabled by default I see no problem with symlinking them in.
...
> And I think the filter extension should be enabled as well, but wit
Hello Rasmus,
same here, i see nothing that speaks against enabling by default. Indeed
didn't we all want to have ext filter as default enabled from the start?
And i can only second Rasmus that json is necessary for Web 2.0 to name the
beast.
marcus
Sunday, May 7, 2006, 5:02:07 PM, you wrote:
On Sun, 07 May 2006 08:02:07 -0700
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
> Ilia Alshanetsky wrote:
> > I am +0 on these two extensions, hence the "to be discussed", as
> > long as they are not enabled by default I see no problem with
> > symlinking them in.
>
> I'd like to see the json extens
Ilia Alshanetsky wrote:
I am +0 on these two extensions, hence the "to be discussed", as long as
they are not enabled by default I see no problem with symlinking them in.
I'd like to see the json extension enabled by default. It's a trivially
small extension with no external deps and pretty m
Yeah, feel free to MFH that patch.
On 6-May-06, at 8:01 PM, Brian J. France wrote:
Could the curl_multi_info_read patch be considered for the 5.2 branch?
Thanks,
Brian
On May 6, 2006, at 6:27 PM, Ilia Alshanetsky wrote:
I've just created the PHP 5.2 branch from which future 5.X release
w
I am +0 on these two extensions, hence the "to be discussed", as long
as they are not enabled by default I see no problem with symlinking
them in.
On 7-May-06, at 1:10 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
Pending Discussion:
* Add input filter extension via a symlink from pec
On Sat, 06 May 2006 22:10:46 -0700
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
> Ilia Alshanetsky wrote:
> > Pending Discussion:
> >
> > * Add input filter extension via a symlink from pecl into core as
> > experimental (derick)
> > * Add json extension via a symlink from pecl into core as
> > exp
Hello Rasmus,
Sunday, May 7, 2006, 7:10:46 AM, you wrote:
> Ilia Alshanetsky wrote:
>> Pending Discussion:
>>
>> * Add input filter extension via a symlink from pecl into core as
>> experimental (derick)
>> * Add json extension via a symlink from pecl into core as experimental
> Haven't we dis
Ilia Alshanetsky wrote:
Pending Discussion:
* Add input filter extension via a symlink from pecl into core as
experimental (derick)
* Add json extension via a symlink from pecl into core as experimental
Haven't we discussed these two enough? Does someone actually disagree
with pushing thes
Could the curl_multi_info_read patch be considered for the 5.2 branch?
Thanks,
Brian
On May 6, 2006, at 6:27 PM, Ilia Alshanetsky wrote:
I've just created the PHP 5.2 branch from which future 5.X release
will be made, so please update your local trees to this branch. The
5.1 branch is dead
I'd like to add a function that returns tsrm_thread_id(). It would be
present in ZTS builds only, and could be used by code that needs to
generate "unique" identifiers.
I'm open for ideas on what to name it; sys_get_thread_id() or something?
--Wez.
On 5/6/06, Ilia Alshanetsky <[EMAIL PROTECTED
I've just created the PHP 5.2 branch from which future 5.X release
will be made, so please update your local trees to this branch. The
5.1 branch is dead to patches except for those fixing security issues
or critical regressions, once 5.2.0 is released, the 5.1 branch will
be discontinued.
22 matches
Mail list logo
