Hi,
As I mentioned in my last email, we've developed a custom extension for a
site, that uses a resource that belongs to the mysql extension. Sara kindly
helped me with the "using the mysql resource" part, but now we're having a
strange issue. Everything works in Windows and Unix with PHP5, but wh
Applied.
-Andrei
On Dec 7, 2006, at 2:55 AM, Matt Wilmas wrote:
Hi Andrei, Antony, ...
Attached is a patch for zend_u_strtol() and HANDLE_U_NUMERIC() to only
allow
ASCII digits and not use u_digit(). (Also switched to hex values for
sign
characters, etc.) I tested the changes quickly and
Stefan Esser wrote:
Well, older version of PHP will be totally incapable of parsing it,
creating problems for the many people who use serialized strings as a
means of passing data between PHP applications. This would be an
especially big problem if you would want to add it to a pre-6.0 release.
Hi Andrey,
where one can post some code snippets related to
PHP development in C, from which some people later can
benefit? Anyone aware?
Both Sara and I were thinking of setting one up last year, but neither of us
did so in the end. (Sara had space she was thinking of using for it; I was
pl
where one can post some code snippets related to
PHP development in C, from which some people later can
benefit? Anyone aware?
Ciao,
Andrey
P.S.
Please don't CC: me when answering, I do read the ML ;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php
Oops, apologies to internals@ - that should've gone to php-gtk-doc.
- Original Message -
From: "Steph Fox" <[EMAIL PROTECTED]>
To: ; "Xing Xing" <[EMAIL PROTECTED]>
Sent: Thursday, December 07, 2006 7:32 PM
Subject: Re: [PHP-DEV] CVS Account Request: mikespook
Hi Mike/Xing,
Agreed,
Hi Mike/Xing,
Agreed, but we need to be certain that you know what you're doing before we
set you loose on our nice clean server ;)
Anyone have time to check the latest offerings?
- Steph
- Original Message -
From: "Xing Xing" <[EMAIL PROTECTED]>
To:
Sent: Thursday, December 07,
I translated a part of the php-gtk-doc. And send them to the mail list of
php-gtk-doc.That`s not convenience.
I need a account to submit the zh_cn translation of php-gtk-doc.
Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Excuse me, I don't quite understand what you're concerned about. The
break would occur if you use PHP 6 serialized content in PHP 5, not
vice versa. I already said that having the same escape format in PHP
5.2 is not tractable for BC reasons and the support, as such, must be
left to PHP_Compat.
it's very usefull to have possibility in large php installation (many apache
instance with many differente configuration, in module loaded and
parametter...) to have the possibility to split for each php instance the php
configuration in differente files...
the --with-config-file-scan-dir confi
> Well, older version of PHP will be totally incapable of parsing it,
> creating problems for the many people who use serialized strings as a
> means of passing data between PHP applications. This would be an
> especially big problem if you would want to add it to a pre-6.0 release.
Uhmm you are m
On 7-Dec-06, at 10:17 AM, Zeev Suraski wrote:
At 13:35 07/12/2006, Stefan Esser wrote:
Guys,
why can't you simply introduce a new variable type for serialized
strings like uppercase S:
There is absolutely no need for breaking backward compatibility.
I can't think of a single reason not to u
hi,
i'have made similare patch to make possible to modify the hardcoded by autoconf
configuration of scandir for additional ini by environement variable and/or by
apache directive...
i've used the same solution used with PHPRC env. and PHPINIDir...
i've added PHPRCSCAN_DIR env. and PHPINISCANDir
At 13:35 07/12/2006, Stefan Esser wrote:
Guys,
why can't you simply introduce a new variable type for serialized
strings like uppercase S:
There is absolutely no need for breaking backward compatibility.
I can't think of a single reason not to use a new type like you suggest.
Can anybody thin
Guys,
why can't you simply introduce a new variable type for serialized
strings like uppercase S:
There is absolutely no need for breaking backward compatibility. If you
want to introduce
NEW features then introduce them and do not abuse old ones.
Stefan
Andrei Zmievski schrieb:
> I don't see a
Hi,
I don't think a discussion on programming methods is something for the
PHP internals list. I understand how you do it, but I (and perhaps
others) would like to do it differently. I have tried to explain why and
I hope you understand.
I would like to be able to prevent memory leaks without
On Thu, 2006-12-07 at 11:25 +0100, Thomas Seifert wrote:
> >From a users point of view: you must be kidding, eh?
> You want to break all the strings which were stored serialized in the
> 5.x-series? I can understand that it will break in php6 but not in some
> minor release.
> It will cause havoc w
Hi Andrei, Antony, ...
Attached is a patch for zend_u_strtol() and HANDLE_U_NUMERIC() to only allow
ASCII digits and not use u_digit(). (Also switched to hex values for sign
characters, etc.) I tested the changes quickly and all appears fine.
Provides a pretty good performance increase too. :-)
>From a users point of view: you must be kidding, eh?
You want to break all the strings which were stored serialized in the
5.x-series? I can understand that it will break in php6 but not in some
minor release.
It will cause havoc with a lot of apps which can't read their cached- /
meta-data anymor
The reason I have this base class is that there is equivalent
functionality within the built in object in PHP. No concept of
ownership or relationship.
In my rudimentary framework, nearly my components are related in some
way. VERY little stands alone.
Therefore, for me, the base object having o
20 matches
Mail list logo
