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
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
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 =
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 -
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
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
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
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 world
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
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
discussions, so you
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
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 ufoo 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 who
On 23 Jan 2008, at 20:21, Rasmus Lerdorf wrote:
ufoo 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 is
How about allowing bfoo 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
On 24.01.2008 01:08, David Zülke wrote:
How about allowing bfoo 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,
Antony
David Zülke wrote:
How about allowing bfoo 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:
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 bfoo in 5.3 (so people can start migrating their
code early) and making unicode strings default in PHP7? :D
Too late..
It's
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
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
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
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
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
..
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 class of
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 internals@lists.php.net
Sent: Thursday,
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
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
[EMAIL
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, I
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
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
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:
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
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
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
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
34 matches
Mail list logo
