I think YES.
Dmitry.
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 16, 2005 10:30 PM
> To: Dmitry Stogov
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-CVS] cvs: php-src /ext/standard md5.c
> /ext/standard/tests/strings explode.php
I think we should make the following assumptions:
a) Being able to create and manipulate IS_UNICODE zvals when
unicode_semantics=off will be very useful to people including the exposing
of the ICU extension.
b) Defining Unicode identifiers like classes/properties/functions if
unicode_semantics=
On Aug 16, 2005, at 2:57 PM, Peter Brodersen wrote:
For what it's worth, would \1 be interpreted as well in single quotes
(as it currently is in double quotes)?
No. Only \u and \U have meaning in single quotes (in addition to
current ones).
-Andrei
--
PHP Internals - PHP Runtime Developme
It does make the engine more complicated though, because we can't just
check for UG(unicode) and expect all identifiers to be of the same
type. We would actually need to amend a lot of API functions to include
passing the identifier type along, e.g. zend_get_active_function()
would need to retu
On Wed, 10 Aug 2005 00:31:30 -0700, in php.internals
[EMAIL PROTECTED] (Andrei Zmievski) wrote:
> - existing PHP escape sequences are also interpreted as Unicode codepoints,
>including \xXX (hex) and \OOO (octal) numbers, e.g. "\x20" => U+0020
[..]
>The single-quoted string is more restrictiv
Hello Michael,
a few questions/comments so that i can understand better:
1) Zend/zend_API.c:
+ZEND_API int zend_declare_class_constant_stringl(zend_class_entry *ce, char
*name, size_t name_length, char *value, size_t value_length TSRMLS_DC)
+{
+ zval *constant = new_zval(ce->type & ZEND_I
IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets
and properties (and do auto-conversion). however, if unicode = off, we
should not do auto conversion but allow php users to manually create
unicode data. when it comes to arrays we agreed that in this case they can
use st
> Please don't use stupid caps, these are functions not methods.
>
>
> Andrey
of course not. see
http://icu.sourceforge.net/apiref/icu4c/uchar_8h.html
, but note that functions conform to PHP's function naming conventions
( lower_case_words_separated_by_underscores() ).
clayton
--
PHP Internal
Hello Andrei,
if unicode is enabled we could handle all property/class and function
names as unicode internally and as native strings if unicode is disabled.
However that would be a slowdown, so i asked which is better, ease of coding
or speed. Anyway i'd like to have property keys always be sto
[EMAIL PROTECTED] wrote:
It will be nice to have functions like this: isNumber(char),
isAlphabetic(char), isWhitespace(char) ...
It is on the plan or not?
its done already, just not committed yet...
clayton
""Ondrej Ivanic"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I couldn't parse this. Could you restate your question?
-Andrei
On Aug 16, 2005, at 11:40 AM, Marcus Boerger wrote:
Another thing is if we simply shouldn't treat all class/prop/fun
names as
native strings if unicode is off and as unicode strings if it is on.
Or do
you guys think that woul
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at jdi-ict.nl
X-Amavis-Alert: BAD HEADER Improper folded header field made up entirely of
Hello Andrei,
i am actually convinced that property and class names should always be of
same string type at least for the property key. If not then how the heck can
we ensure that the code will work? That's why i was asking for %R being used
twice and referencing the same type, that of the hash.
Should we have md5() return an IS_BINARY string when raw_output
parameter is set?
-Andrei
On Aug 16, 2005, at 3:18 AM, Dmitry Stogov wrote:
dmitry Tue Aug 16 06:18:43 2005 EDT
Modified files:
/php-src/ext/standard md5.c
/php-src/ext/standard/tests/strings explode.ph
http://www.php.net/distributions/php-5.1.0RC1.tar.bz2
http://www.php.net/distributions/php-5.1.0RC1.tar.gz
http://www.php.net/distributions/php-5.1.0RC1-Win32.zip
http://www.php.net/distributions/pecl-5.1.0RC1-Win32.zip
Enjoy!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
Hmm, should we allow this? It is much easier to deal with having common
identifier type everywhere.
-Andrei
On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote:
You aren't right.
It is posiible to have unicode property in non-unicode mode (class
name is
string and property name is unicode).
Where should we save the script encoding from which an oparray was
built? In the oparray itself?
-Andrei
On Aug 15, 2005, at 3:13 PM, Andi Gutmans wrote:
If you want to optimize then I guess "remembering" the script_encoding
is the only way to do it. We could do it similar to the way we "cach
We certainly could, but we lose some speed, especially when
script_encoding == output_encoding (where we don't really need to
transcode HTML blocks). Are we up for that?
-Andrei
On Aug 15, 2005, at 3:03 PM, Andi Gutmans wrote:
Wouldn't it be easiest to have inline html become IS_UNICODE and t
Thanks sara for responding.
Will write a snippet to address this and get back to you.
With regards
Kamesh Jayachandran
On Thu, 11 Aug 2005 07:52:56 -0700, "Sara Golemon" <[EMAIL PROTECTED]>
said:
> > Version PHP 5.1
> > file main/php_init.c
> > function int php_init_config() uses realpath.
> > In
On Aug 12, 2005, at 1:48 PM, Rasmus Lerdorf wrote:
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
This is a sweet carrot to drive adoption despite a few minor BC issues.
--
PHP Internals - PHP Runtime Devel
At 16:07 16/08/2005, Michael Wallner wrote:
Hi Zeev Suraski, you wrote:
> Michael,
>
> I'll roll RC1 as planned, and I'll try to sort this issue out before RC2
> (hopefully with a much shorter patch). Since it is a bug, even if 5.1.0
> comes out with this bug, it can still be fixed in the 5.1.0
Hi Zeev Suraski, you wrote:
> Michael,
>
> I'll roll RC1 as planned, and I'll try to sort this issue out before RC2
> (hopefully with a much shorter patch). Since it is a bug, even if 5.1.0
> comes out with this bug, it can still be fixed in the 5.1.0 branch.
Fair enough, but even breaking binar
Michael,
I'll roll RC1 as planned, and I'll try to sort this issue out before RC2
(hopefully with a much shorter patch). Since it is a bug, even if 5.1.0
comes out with this bug, it can still be fixed in the 5.1.0 branch.
Zeev
At 14:06 16/08/2005, Michael Wallner wrote:
Hi Zeev Suraski, yo
I'm looking into it. The patch generally looks fine but then again, they
always do :)
Zeev
At 14:06 16/08/2005, Michael Wallner wrote:
Hi Zeev Suraski, you wrote:
> zeev Tue Aug 16 06:59:57 2005 EDT
>
> Modified files: (Branch: PHP_5_1)
> /php-src NEWS configure.
Hi Zeev Suraski, you wrote:
> zeev Tue Aug 16 06:59:57 2005 EDT
>
> Modified files: (Branch: PHP_5_1)
> /php-src NEWS configure.in
> /php-src/main php_version.h
> Log:
> Roll RC1
So fixing internal class' static properties won't be considered?
It would be
At 11:00 16/08/2005, Derick Rethans wrote:
On Tue, 16 Aug 2005, Zeev Suraski wrote:
> We're looking into rolling PHP 5.0.5 sometime soon. Does anybody have any
> outstanding patches they plan to put into it? If not and unless we hear
> objections, I'll roll RC1 later this week.
I'll be rollin
Hi Andi Gutmans, you wrote:
> Thanks for sending this. Has anyone else reviewed it already?
I don't know if Marcus had a look at it. I updated the patches
to reflect current CVS. It should work with 5.1 pretty well,
no idea about HEAD though, as I'm not familiar with the changes
yet.
Thanks,
-
>
> It will be nice to have functions like this: isNumber(char),
> isAlphabetic(char), isWhitespace(char) ...
>
> It is on the plan or not?
its done already, just not committed yet...
clayton
""Ondrej Ivanic"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Andrei Zmievski wrot
I am experiencing a segfault with spl_autoload in the PHP_5_1 branch
with the upcoming PHPUnit 2.3.0.
The nature of PHPUnit's complexity makes it almost impossible for me to
come up with a simple, reproducing script (I already invested hours into
this, to no avail so far).
It is weird that
Derick Rethans wrote:
On Tue, 16 Aug 2005, Zeev Suraski wrote:
We're looking into rolling PHP 5.0.5 sometime soon. Does anybody have any
outstanding patches they plan to put into it? If not and unless we hear
objections, I'll roll RC1 later this week.
I'll be rolling 4.4.1 alongside, so i
Yes!
I have struggled with bundling PEAR in PHP's Windows distro for quite
some time, and hopefully this will make my life easier too :)
Edin
Ilia Alshanetsky wrote:
To echo Andi's comments on php-src, this should definitely make the
release process much easier as well as help encourage peo
Ilia Alshanetsky wrote:
Shmop does just that, it takes a string of data (any data) and puts it
in memory. Serialization is something sysvshm extension does.
Ilia
shmop is the solution if you want to store only strings but once you want
to store arrays or objects then the ser/deser is needed.
Andrei Zmievski wrote:
+ Determining length of Unicode strings via strlen() function, some
simple string functions ported (substr).
It's not a problem to determine kind of char in single byte character
sets, but in the unicode with various encoding schemas I don't see easy
way how t
On Tue, 16 Aug 2005, Zeev Suraski wrote:
> We're looking into rolling PHP 5.0.5 sometime soon. Does anybody have any
> outstanding patches they plan to put into it? If not and unless we hear
> objections, I'll roll RC1 later this week.
I'll be rolling 4.4.1 alongside, so if you have patches for
Hi Andi Gutmans, you wrote:
> Hi Michael,
>
> Thanks for sending this. Has anyone else reviewed it already? I'm
> assuming that this supports arrays too (unlike today as emalloc needs to
> be available for arrays) and has to be created/freed during
> RINIT/RSHUTDOWN...
Yes, there are two convenie
Hey,
We're looking into rolling PHP 5.0.5 sometime soon. Does anybody have any
outstanding patches they plan to put into it? If not and unless we hear
objections, I'll roll RC1 later this week.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
At 00:26 16/08/2005, Pasha Zubkov wrote:
Zeev Suraski wrote:
> Finally, the main issue I'm going against is the 'we can now break
> things!' approach. I don't have a problem with all of the points Rasmus
> made, just some of them. And the biggest problem is the mindset of the
> thread that foll
37 matches
Mail list logo
