Andrew Rose wrote:
Hi
I'm looking into making a few changes to the PHP session code in
respect to the CLI SAPI. But before I did, I wanted to see if the
changes (patch) would be excepted (I really hate wasting my time).
The changes are as such:
1. Update the session code to suppress "headers a
Andrew Rose wrote:
Hi
I'm looking into making a few changes to the PHP session code in
respect to the CLI SAPI. But before I did, I wanted to see if the
changes (patch) would be excepted (I really hate wasting my time).
The changes are as such:
1. Update the session code to suppress "headers a
Andrei Zmievski wrote:
Or people that worry too much about characters being bytes.
-Andrei
Steph Fox wrote:
Well maybe half the problem with this is that people aren't really
aware of what is or isn't the issue. As I (now) understand it, the
only people affected by Unicode support will be tho
Is it possible to take a page out of the database engine's handbook and
tie a charset to a namespace like charsets are tied to tables?
namespace myNamespace charset=utf8
{
...
}
Then when no charset is defined it defaults to current PHP semantics.
Win-win?
Cheers,
Rob.
On Wed, 2008-01-23 a
The question here isn't so much where we are going, but exactly how we
will get there and how long that might take.
Absolutely.
- Steph (who has taken several queries over this today thank you)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Or people that worry too much about characters being bytes.
-Andrei
Steph Fox wrote:
Well maybe half the problem with this is that people aren't really aware
of what is or isn't the issue. As I (now) understand it, the only people
affected by Unicode support will be those currently using mbstr
Well maybe half the problem with this is that people aren't really aware of
what is or isn't the issue. As I (now) understand it, the only people
affected by Unicode support will be those currently using mbstring, is that
correct?
- Steph
- Original Message -
From: "Andrei Zmievski"
No, sorry, I agree that was a badly written statement where the
"crippling" part didn't refer to the previous sentence. I meant that if
we remove the unicode semantics switch, then we are crippling the
implementation because we wouldn't be able to make the default string
literal IS_UNICODE which,
Hey, I can't do everything.
-Andrei
Steph Fox wrote:
Right, and that's something that does NOT appear in any notes anywhere.
- Original Message - From: "Andrei Zmievski"
<[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Chris Stockton"
Unicode is a 'big scary beast' because people don't know what impact it will
or won't have on their applications. If they're ISO-8859-1 apps there
shouldn't be an issue - but where has anyone ever said that?
There are two options open at this point for PHP 6: unicode-only and a
MASSIVE push fo
Right, and that's something that does NOT appear in any notes anywhere.
- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Chris Stockton"
<[EMAIL PROTECTED]>; "php-dev"
Sent: Thursday, Janua
..
On Jan 23, 2008 11:14 AM, Chris Stockton <[EMAIL PROTECTED]> wrote:
> I partially agree, I have been watching this discussion and it's funny
> how we have such a class of high end developers saying to break old
> PHP code. But, the majority of the success of PHP is not due to this
> small clas
Pass in "Hello World" where? And yes, you shouldn't have to do anything
special (especially for English). The functions will work transparently.
-Andrei
Steph Fox wrote:
Hey Andrei,
You can't just say that without giving full details.
We've seen all your 'this will cope with Russian, Hebrew,
What's going to make PHP 7 different than PHP 6? We'll be back to the
same discussion then. PHP 5 people have had a long time to work with
mbstring, etc and still Unicode a big scary beast.
-Andrei
Steph Fox wrote:
Blimey. I agree with Rasmus. That's twice now!
I think PHP 6 should be an int
Hey Andrei,
You can't just say that without giving full details.
We've seen all your 'this will cope with Russian, Hebrew, Greek, Japanese
and Icelandic' demos. We haven't seen what happens to English, French or
German - ever.
So what happens if I pass in "Hello World", in English, and it's
It seems we're only talking about literals here. What about the rest of
the places where unicode.semantics switch matters right now, like
streams (works in binary or unicode mode), incoming request decoding,
etc? It would be a shame to go back to binary by default mode and have
to jump through
Did you mean to say "can't make the default string IS_STRING"? Because
that's the only reading that makes sense given the rest of the message.
-Andrei
Rasmus Lerdorf wrote:
If we get rid of the switch, then I agree that we can't make the default
string IS_UNICODE. We would be crippling the im
Blimey. I agree with Rasmus. That's twice now!
I think PHP 6 should be an interim period with support for both scenarios,
but with the default being bog-standard as-we-know-it IS_STRING and anything
IS_UNICODE needing to be marked.
Perhaps PHP 7 can drop the IS_STRING stuff and have it all IS
Ah. Right. I remember now. Sorry for the noise ;)
David
Am 23.01.2008 um 23:14 schrieb Antony Dovgal:
On 24.01.2008 01:08, David Zülke wrote:
How about allowing b"foo" in 5.3 (so people can start migrating their
code early) and making unicode strings default in PHP7? :D
Too late..
It's a
David Zülke wrote:
> How about allowing b"foo" in 5.3 (so people can start migrating their
> code early) and making unicode strings default in PHP7? :D
That's been there for a very long time now.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
On 24.01.2008 01:08, David Zülke wrote:
> How about allowing b"foo" in 5.3 (so people can start migrating their
> code early) and making unicode strings default in PHP7? :D
Too late..
It's already done =)
08 Feb 2007, PHP 5.2.1
- Added forward support for (binary) cast. (Derick)
--
Wbr,
Ant
How about allowing b"foo" in 5.3 (so people can start migrating their
code early) and making unicode strings default in PHP7? :D
David
Am 23.01.2008 um 22:30 schrieb Andi Gutmans:
Hi Rasmus, Chris,
I agree with you which is why I suggested to not have a switch but to
make the default str
On 23 Jan 2008, at 20:21, Rasmus Lerdorf wrote:
u"foo" is a hack that will eventually disappear from the various
languages that have it or something similar.
I think we need to have binary strings as default with u"…" for a
while (whenever that gets merged into the default string type it i
Hi Rasmus, Chris,
I agree with you which is why I suggested to not have a switch but to
make the default string binary and require u"foo" for Unicode strings.
It supports the existing community incl. hosters and as Chris and you
pointed out, the broad community of non-"high class" developers to wh
Sam Barrow wrote:
PHP has ZIP, GZip, and BZ2 support, but nothing for tar archives. Is
anyone interested in working on a tar extension?
FYI, pecl/phar has full tar support plus tar.gz/tar.bz in the
soon-to-be-released 2.0.0 version. Development on tar features has
stabilized, I'm focusing on
On Wed, January 23, 2008 2:21 pm, Rasmus Lerdorf wrote:
> Richard Lynch wrote:
>> On Wed, January 23, 2008 1:28 pm, Rasmus Lerdorf wrote:
>>> I don't disagree with this, and that is actually why I insisted on
>>> having the unicode-semantics switch from the early days of the
>>> Unicode
>>> discuss
Richard Lynch wrote:
On Wed, January 23, 2008 1:28 pm, Rasmus Lerdorf wrote:
I don't disagree with this, and that is actually why I insisted on
having the unicode-semantics switch from the early days of the Unicode
discussions, so you can blame me, again, if you consider it a bad
design
decision
On Wed, January 23, 2008 1:28 pm, Rasmus Lerdorf wrote:
> I don't disagree with this, and that is actually why I insisted on
> having the unicode-semantics switch from the early days of the Unicode
> discussions, so you can blame me, again, if you consider it a bad
> design
> decision.
Would the w
I don't disagree with this, and that is actually why I insisted on
having the unicode-semantics switch from the early days of the Unicode
discussions, so you can blame me, again, if you consider it a bad design
decision.
My take on it was that just about all ISPs would run with Unicode
semant
I partially agree, I have been watching this discussion and it's funny
how we have such a class of high end developers saying to break old
PHP code. But, the majority of the success of PHP is not due to this
small class of high end developers, it's due to it's availability in a
shared hosting envir
Hi
I'm looking into making a few changes to the PHP session code in
respect to the CLI SAPI. But before I did, I wanted to see if the
changes (patch) would be excepted (I really hate wasting my time).
The changes are as such:
1. Update the session code to suppress "headers already sent" warnings
On 23.01.2008 20:37, Sam Barrow wrote:
> PHP has ZIP, GZip, and BZ2 support, but nothing for tar archives. Is
> anyone interested in working on a tar extension?
>
Like PECL/archive?
http://pecl.php.net/package/archive
You can take it over if you like.
--
Wbr,
Antony Dovgal
--
PHP Internals
As a side note, I think the following code could be optimized:
Probably it could, but note that the code not just moves the stack
pointer, but also destroys arguments there (zval_ptr_dtor).
+ while (zend_vm_stack_top(TSRMLS_C) != stack_frame) {
+ zval *stack_zval_p = zend_vm_stack_pop(TSRMLS
PHP has ZIP, GZip, and BZ2 support, but nothing for tar archives. Is
anyone interested in working on a tar extension?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Nuno,
Thank you for your notes.
Nuno Lopes wrote:
Hi Dmitry,
The patch looks fine. Although it wastes a bit more memory than the
current implementation, I think it's ok.
I think the patch uses exactly the same amount of memory, except that
the current implementation uses CPU stack and t
35 matches
Mail list logo
