Hi,
We got some problems with PHP with wddx functions which consider PHP's
side will always be "ISO-8859-1".
I wrote/tested a patch to fix this issue, against PHP 5.2.7rc2.
Bugreport:
http://bugs.php.net/bug.php?id=46496
NB: the bug has been marked "bogus". I believe this is due to the fact
t
Hi,
I assigned this to helly arbitrarily, but wanted to make sure that Stas
and Dmitry also see it. This should be fixed ASAP. The opcode
modification was easy to fix, since we weren't using op1. I also fixed
a cosmetic issue Dmitry wanted fixed, which was replacing the
non-verbose 1 and 2 used
On Wednesday 05 November 2008 9:24:15 pm Stan Vassilev | FM wrote:
> Hi,
>
> I just wanted a clarification on this. Currently many of us have class
> names such as:
>
> Zend_Validate_Interface
> Foo_Utils_Array
>
> ...and so on. This works fine as it's just a single T_STRING.
>
> As you know, with
Hi,
I just wanted a clarification on this. Currently many of us have class names
such as:
Zend_Validate_Interface
Foo_Utils_Array
...and so on. This works fine as it's just a single T_STRING.
As you know, with the new convention, the parser will not encounter T_STRING
"Zend\Validate\Interfac
Lukas Kahwe Smith wrote:
>
> On 04.11.2008, at 18:43, Ryan Panning wrote:
>
>> Just to make my post clear, I'm in favor of this approach for
>> non-qualified calls in a namespace.
>>
>> 1. global
>> 2. autoload
>> 3. fail
>
>
> A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just
- people expect direct access to the vast number of php functions/
constants
Do you know rule 1 in #phpc? This is one of those cases.
People want :: and not backslash.
People want global stuff to resolve in their namespace (how does this make
any sense? the very idea of a namespace is to avoid
Here are some reasons why we felt that functions/constants should
fallback:
- most namespace users will be using classes and not functions
This is a self-fulfilling prophecy, the more you open a gap between classes
and functions, the more people will stick with the richer functionality
since
Hello,
Arnaud Le Blanc a écrit :
...
Thanks, committed to 5.3 and HEAD :)
Wow. Thank you both for your comments, corrections and commit!
Olivier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Here is a reason why we would limit this to international functions only:
- <@Stas> but note that global user-space fallback for function means
run-time resolution (which may be ok, but slower - no caching resolution
in bytecode cache)
Hi,
Not true: you can't resolve it at compile time wit
On Wednesday 05 November 2008 17:30:21 Olivier Grange-Labat wrote:
> Hello,
>
> Here's a patch again PHP_5_3 to add a parse_ini_string() function.
>
> It just works as parse_ini_file(), except it accepts a string instead of
> a filename, obviously.
>
> We've been using for months a simple PHP f
On 04.11.2008, at 18:43, Ryan Panning wrote:
Just to make my post clear, I'm in favor of this approach for non-
qualified calls in a namespace.
1. global
2. autoload
3. fail
A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just
chatting on IRC and we all favor the following:
Hi!
Well, its not like the person is getting Y when he is expecting X. Both
classes have the same name after all, so there is some relation between
They don't have the same name - two classes can't have the same name.
And "relation" is definitely not enough - you really do not want to get
g
Hi!
ok, they have the same non fully qualified named.
That's why we should have unambiguous resolution mechanism. You propose
to add one ambiguity on top of another.
want to get generic \Exception instead of \My\Very\Specific\Exception
- it would probably break all your error handling.
t
On 05.11.2008, at 21:24, Stanislav Malyshev wrote:
Hi!
Well, its not like the person is getting Y when he is expecting X.
Both classes have the same name after all, so there is some
relation between
They don't have the same name - two classes can't have the same
name. And "relation" is
Lukas Kahwe Smith wrote:
>
> On 05.11.2008, at 01:05, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> or in other words give the user the ability to specify when he wants
>>> the
>>> fallback to global and not doing a fallback to global per default.
>>> That way
>>
>> This would be quite complex thing si
On 05.11.2008, at 01:05, Stanislav Malyshev wrote:
Hi!
or in other words give the user the ability to specify when he
wants the
fallback to global and not doing a fallback to global per default.
That way
This would be quite complex thing since this way you can't be sure
which class get
Hi,
On Wed, 2008-11-05 at 17:30 +0100, Olivier Grange-Labat wrote:
> Hello,
>
> Here's a patch again PHP_5_3 to add a parse_ini_string() function.
In general I think it's good to add that function, a few comments below.
>
> +static
> +ZEND_BEGIN_ARG_INFO_EX(arginfo_parse_ini_string, 0, 0, 1)
>
Hi!
Unrelated to this windows compilation problem (thanks Felipe for the
quick fix), I'm concerned to see that I missed an example of opcode
modification. We can't modify opcodes directly because of opcode
Runtime opcode modification is definitely a bad idea. This needs to be
fixed.
--
Stan
获得邮件列表
Hello,
Here's a patch again PHP_5_3 to add a parse_ini_string() function.
It just works as parse_ini_file(), except it accepts a string instead of
a filename, obviously.
We've been using for months a simple PHP function to do that, and while
I had to modify it to accept constants (as parse_i
On 4 Nov 2008, at 22:59, Stanislav Malyshev wrote:
so where do we stand here?
I'd prefer to have it fixed, but then it probably requires changing
the parameters API for 'a', which might lead to some unexpected
results with regard to functions that modify their arguments. I
think we may
Pierre Joye wrote:
> Hi,
>
> A commit in the last 24 hours breaks the builds:
>
> d:\php-sdk\snap_5_3\vc9\x86\snap53_vc9\zend\zend_vm_execute.h(2735) :
> error C2036: 'void *' : unknown size
> d:\php-sdk\snap_5_3\vc9\x86\snap53_vc9\zend\zend_vm_execute.h(10445) :
> error C2036: 'void *' : unknown
Hi,
I played with a patched version of compare_function with this optimization
in it. Other then for strings it didn't seem to make much of a difference. A
quick test showed that in an average php application only about 0.15% of
calls to compare_function actually have the same op1 and op2. Conside
I recently noticed if you want to compile PHP using the suncc compiler,
there are no useful default flags set by configure. Therefore if there
are no objections I want to commit the following patch that introduces
usefull cflags (actually those used by php distributed by sun) for the
suncc comp
On Wed, 2008-11-05 at 17:07 +0800, 张心灵 wrote:
> I 'am a new guy of php internal, I tried to define a class in extension
> just for a attempt.
>
> PHP_MINIT_FUNCTION(zhangjianyu)
> {
> /* If you have INI entries, uncomment these lines
> REGISTER_INI_ENTRIES();
> */
> zend_class_entry ce;
> IN
Hi,
A commit in the last 24 hours breaks the builds:
d:\php-sdk\snap_5_3\vc9\x86\snap53_vc9\zend\zend_vm_execute.h(2735) :
error C2036: 'void *' : unknown size
d:\php-sdk\snap_5_3\vc9\x86\snap53_vc9\zend\zend_vm_execute.h(10445) :
error C2036: 'void *' : unknown size
d:\php-sdk\snap_5_3\vc9\x86\s
I 'am a new guy of php internal, I tried to define a class in extension
just for a attempt.
PHP_MINIT_FUNCTION(zhangjianyu)
{
/* If you have INI entries, uncomment these lines
REGISTER_INI_ENTRIES();
*/
zend_class_entry ce;
INIT_CLASS_ENTRY(ce, WPS_CLASS_NAME, php_wps_method_functions);
php
27 matches
Mail list logo
