Hi,
$str{} was considered a best practice for a while so as you can see via
Google Code Search it's been used quite a bit.
I take the blame for introducing it with the intention to not only
create a better separation between arrays and string offsets but by also
then allowing for a cleaner impleme
>So unless this thread changes something, an E_DEPRECATED will be added to
HEAD (PHP >6.0.0) for curly brace string access ( $str{42} ) and the
documentation will remain as is.
I'm well aware that I don't get a vote, so I'll skip the +1.
That being said, I'd like to argue in favour of depricating
Correct me if I'm wrong but wasn't that the last decision we made about it the
last time this was brought up? Just undocument it. Totally. It exists, only
works with strings (right?! :) and is not recommended. So simply make it
disappear from the docs. "See no evil, hear no evil, speak no evil..
Hi Markus,
Am Mittwoch, den 11.06.2008, 01:04 +0200 schrieb Markus Fischer:
[...]
> I don't get this deprecation and thus the forced code change at all.
> Considering the amount of code using this style, see
> http://www.google.com/codesearch?as_q=\%24[a-z][a-z0-9_]*{[^}]%2B}&hl=en&as_lang=php
>
Hi,
I don't get this deprecation and thus the forced code change at all.
Considering the amount of code using this style, see
http://www.google.com/codesearch?as_q=\%24[a-z][a-z0-9_]*{[^}]%2B}&hl=en&as_lang=php
and given that no PHP code change has been done I would rather suggest
removing the
Hello geeks,
This email is to confirm that $str{42} is deprecated in favour of
$str[42] as of PHP 6. There is some confusion so let's make something
official here.
A little history:
- May, 2001: $str[42]: is documented as deprecated since PHP 4
- Nov, 2005: $str[42]: kept while $str{42} i
Yes, good idea. PRE-BFUC (PRE-BigFreakingUnicodeCleanup)
-Andrei
Stanislav Malyshev wrote:
Hi!
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be n
So now I have:
PHP_RINIT_FUNCTION(vardumpoverload)
{
zend_function *orig_1;
TSRMLS_FETCH();
You don't need fetch here, RINIT already gets it as a parameter.
When I don't use TSRMLS_FETCH(); at all I get a "Bus error" when running
the extension and calling require_once().
You should
> That's TSRMLS_FETCH() (you have extra S).
So now I have:
PHP_RINIT_FUNCTION(vardumpoverload)
{
zend_function *orig_1;
TSRMLS_FETCH();
/* Override require_once with our own function */
zend_hash_find(CG(function_table), "require_once", 13, (void
**)&orig_1);
VARDUMPOVERLOA
Hi!
I am trying to call CG(function_table) from within my
PHP_RINIT_FUNCTION() and from what I have found I need to call
TSRMSLS_FETCH() first to populate the function table in a thread safe way.
That's TSRMLS_FETCH() (you have extra S).
--
Stanislav Malyshev, Zend Software Architect
[EMAIL P
I am trying to call CG(function_table) from within my
PHP_RINIT_FUNCTION() and from what I have found I need to call
TSRMSLS_FETCH() first to populate the function table in a thread safe way.
When I run the extension I get:
dyld: lazy symbol binding failed: Symbol not found: _TSRMSLS_FETCH
Refe
I will do it before commit. Didn't have time to check Windows version yet.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
Tuesday, June 10, 2008, 1:11:57 PM, you wrote:
Index: Zend/zend.h
===
RCS file: /repository/ZendEngin
Hello Dmitry,
Tuesday, June 10, 2008, 1:11:57 PM, you wrote:
> Index: Zend/zend.h
> ===
> RCS file: /repository/ZendEngine2/zend.h,v
> retrieving revision 1.293.2.11.2.9.2.20
> diff -u -p -d -r1.293.2.11.2.9.2.20 zend.h
> --- Zend/ze
Dmitry Stogov wrote:
Exactly. The "fastcall" attribute wasn't supported before.
As 3.4 is quite old this should not be a problem. I somehow read 4.3
initially ;-)
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5
Exactly. The "fastcall" attribute wasn't supported before.
Thanks. Dmitry.
Sebastian Bergmann wrote:
Dmitry Stogov wrote:
The proposed patch for PHP improves the executor.
ZEND_GCC_VERSION >= 3400 means >= GCC 3.4.0, right?
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
The recursion elimination itself doesn't show any significant speed
difference.
Thanks. Dmitry.
Nuno Lopes wrote:
Nuno Lopes wrote:
Out of curiosity, what's the slowdown without fastcall?
fastcall calling convention assumes passing parameters in registers
instead of pushing them on stack.
I'm working on the patch to remove stuff from Zend/*, I've yet to change
any of the macros. Will most likely leave that to last.
Scott
Stanislav Malyshev wrote:
- Changed:
- ZEND_STR_TYPE -> IS_UNICODE
- convert_to_text -> convert_to_unicode
- convert_to_text_ex -> convert
Hi Stas,
- Changed:
- ZEND_STR_TYPE -> IS_UNICODE
- convert_to_text -> convert_to_unicode
- convert_to_text_ex -> convert_to_unicode_ex
Would the cleanup include the engine - i.e. all the UG-ly stuff in
macros, functions, etc. - or only ext/* part?
Scott's working on t
- Changed:
- ZEND_STR_TYPE -> IS_UNICODE
- convert_to_text -> convert_to_unicode
- convert_to_text_ex -> convert_to_unicode_ex
Would the cleanup include the engine - i.e. all the UG-ly stuff in
macros, functions, etc. - or only ext/* part?
--
Stanislav Malyshev, Zend Softw
Nuno Lopes wrote:
Out of curiosity, what's the slowdown without fastcall?
fastcall calling convention assumes passing parameters in registers
instead of pushing them on stack.
yeah, I know. I was asking what's the slowdown that this patch introduces
without the fastcall bits.
I'm asking thi
Dmitry Stogov wrote:
The proposed patch for PHP improves the executor.
ZEND_GCC_VERSION >= 3400 means >= GCC 3.4.0, right?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals
Nuno Lopes wrote:
Out of curiosity, what's the slowdown without fastcall?
fastcall calling convention assumes passing parameters in registers
instead of pushing them on stack.
Thanks. Dmitry.
Despite the potential slowdown, I still think this is the way to go. The
engine isn't supposed to
Out of curiosity, what's the slowdown without fastcall?
Despite the potential slowdown, I still think this is the way to go. The
engine isn't supposed to crash!
Nuno
- Original Message -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "PHP Internals List"
Cc: "Andi Gutmans" <[EMAIL PRO
Hi,
The proposed patch for PHP improves the executor.
At first it eliminates direct execute() recursion so the following
script won't produce SIGSEGV anymore (It'll produce memory overflow
error instead).
Note that in case some extension (e.q. xdebug) override zend_execute(),
VM will use
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be nice to tag it before the change, just in case.
Oooh, exciting stuff :)
- Steph
--
Stanislav M
On 2008-06-09, at 14:43, Antony Dovgal wrote:
On 09.06.2008 15:39, Michal Dziemianko wrote:
Hello,
Here: http://212.85.117.53/DIFF.txt is small patch that will
speed up following functions:
strpos,
stripos,
strrpos
strripos,
and probably some others (all that use zend_memnstr/php_memnstr
Hello
On 2008-06-09, at 14:58, Scott MacVicar wrote:
There is rabin-karp too but its worse case is O(nm) so that might
not be ideal, perhaps we should try to compare all of them.
OK. I think RK will not be much better than original piece of code
which runs in time o(n + m) i most cases
Hi!
So here's my offer: if two core committers, or even just one, were
willing to champion this feature, I will take full responsibility for
"if" is redundant here - at least three core committers are already for
this feature. In any case, not rehashing all the past arguments and
their vali
On 10.06.2008 11:04, Stanislav Malyshev wrote:
Hi!
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be nice to tag it before the change, just in case.
Hi!
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be nice to tag it before the change, just in case.
--
Stanislav Malyshev, Zend Software Architect
30 matches
Mail list logo
