We did, but we never arrived at consensus. I don't really see a good
reason for giving people access to code-units with such a low-level
operator. If we fix it, I'd rather fix it so that [] only works on
arrays, and {} on strings, with some sort of BC switch.
-Andrei
On Aug 12, 2005, at 1
I thought we've discussed making one access code-units and the other
code-points?
Ilia
Andrei Zmievski wrote:
> On Aug 12, 2005, at 11:29 PM, Ilia Alshanetsky wrote:
>
>>> 12. {} vs [] cleanup
>>>
>>
>> unicode support already makes such distinction it.
>
>
> No, it doesn't. That's one of the
On Aug 12, 2005, at 11:29 PM, Ilia Alshanetsky wrote:
12. {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny unresolved issues.
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
Marcus Boerger wrote:
> 9. __toString) everywhere, but i already said i'll take care of that unless
> i am being held back. So now go for that or live with the fact that php is
> meant to generate html pages which is text output. Thus sooner or later your
> objects create text simplifying that aas
Why would I need name spaces for basic functions, just so that I need to
rename all my code to use str:replace rather then str_replace and
perform 2 hash table lookups?
Ilia
Marco Tabini wrote:
> Hey Ilia,
>
> On 8/12/05 3:03 PM, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote:
>
>>-1 to namespace
Marcus Boerger schrieb:
> why is this on gravitonic.com ?
Ask Andrei, it's been there for ages.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mai
How about running from serialized opcode memory block (rather than array
of struct'd opcodes...), so writing a thread extension is alot easier ;)
Oh well, I can always dream...
Regards
Alan
On Fri, 2005-08-12 at 23:27 -0400, Marco Tabini wrote:
> Hey Ilia,
>
> On 8/12/05 3:03 PM, "Ilia Alshanet
missing "charset=" in content-type header when unicode.output_encoding
is set to other than utf-8
is_binary() is_unicode()? (while there is is_string())
and is_buffer() for string/binary/unicode?
but pls fix extract() at very first as it inject variable in active
symbol table.
--
PHP Internals -
ahh, i found i'm in wrong list, ignore my previous reply
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Aug 12, 2005, at 3:33 PM, Lukas Smith wrote:
+1 on all the mentioned items, except for case sensitivity for
identifiers where I am -1 (I dont see the benefit).
Aside from that I wouldnt mind an aggressive function name and
parameter order clean up. We could provide a BC lib via runkit (
Hey Ilia,
On 8/12/05 3:03 PM, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote:
>
> -1 to namespaces. As for modifying functions that would require a fair
> number of function aliases for BC as untold number of scripts will
> break. That is something we are trying to eliminate in the first place.
>
i'd suppose u guys going to deprecate+E_STRICT first, remove later
> > George Schlossnagle schrieb:
> >> Radically change all the operator syntaxes.
>
> > http://www.gravitonic.com/software/php/patches/ze2_concat_obj_op.diff.gz
>
FYI: _ is validate char in variable/function name
_("Hello! worl
+1 bundling the opcode cache like APC.
I also wish some elemental debugging features (stack dump, etc.)
like Xdebug has.
Rui
On Fri, 12 Aug 2005 10:48:20 -0700
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> Since we are breaking a lot of stuff in 6.0, at least with
> Unicode_semantics=On I am w
Hello Lukas,
Saturday, August 13, 2005, 1:34:35 AM, you wrote:
> Marcus Boerger wrote:
>> 11. class operator cleanup
>> :: static
>> -> non static
>> this would allow to do more things like accessing static members/consts
>> from anywhere a class is allowed etc. (if proposed that before
We definitely need to start thinking forward and introduct a 64-bit
type. It needn't replace the 32-bit type.
IIRC, Andi promised that we would have this after 5.1, so I think it's
a done deal.
It's especially important now that we have a number of extensions
returning 64-bit data.
And with Visu
Marcus Boerger wrote:
11. class operator cleanup
:: static
-> non static
this would allow to do more things like accessing static members/consts
from anywhere a class is allowed etc. (if proposed that before incl. patch
lookup the archieves).
could you elaborate what you mean with th
Hello Rasmus,
Friday, August 12, 2005, 7:48:20 PM, you wrote:
> Since we are breaking a lot of stuff in 6.0, at least with
> Unicode_semantics=On I am wondering if it may not be time to break some
> more stuff and do a bit of spring cleaning. It would mean many apps
> would need some work to wor
Ron Korving wrote:
13. A built-in code optimizer. Why should something like Zend optimizer be
installed afterwards, if everybody can use increased performance?
IIRC George once played around with a few peekhole optimizations for
APC. I think the performance improvements possible with peekhole
Hello Sebastian,
why is this on gravitonic.com ?
anyway. If we'd use the VBA operator for that then we could use the '.'
for namespaces and wouldn't run into any trouble with namespaces at all.
Besides someone wanted to have functions in namespaces.
marcus
Friday, August 12, 2005, 8:29:29 P
+1 on all the mentioned items, except for case sensitivity for
identifiers where I am -1 (I dont see the benefit).
Aside from that I wouldnt mind an aggressive function name and parameter
order clean up. We could provide a BC lib via runkit (or was it classkit
.. I can never separate the two i
"Andrei Zmievski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yes, this is pretty high impact as far as code changes are concerned.
> Since one should not attempt to access a class entry without
> U_CLASS_ENTRY() macro, should it even be optional?
my uneasiness with this is th
On Fri, 12 Aug 2005, Pierre-Alain Joye wrote:
On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
Very good idea. We do bundle the thing? :)
I do not think we can use the extern GD2 in the same nice way than
we use ours.
But droping _extern_ gd2 support
+1 from here too except 0 for the case sensitivity.
Andrey
Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break some
more stuff and do a bit of spring cleaning. It would mean many apps
would need so
On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
>
> Very good idea. We do bundle the thing? :)
I do not think we can use the extern GD2 in the same nice way than
we use ours.
But droping _extern_ gd2 support is possible. The only remaining
thing is to che
Very good idea. We do bundle the thing? :)
--Jani
On Fri, 12 Aug 2005, Ilia Alshanetsky wrote:
This is a very good, point we really should drop support for things like
gd1 (no reason anymore, latest versions (including bundled) have GIF
support). These only add a hundreds of ifdefs to
> How about doubling integer precision to 64 bits and float/double precision
> to 128 bits? It's in line with 64 bit CPU capabilities, and personally, I
> wouldn't mind it a bit if it would make numerical processing in PHP slower
> on 32 bit systems. I think the advantages are much too great for th
On Fri, 12 Aug 2005, Rasmus Lerdorf wrote:
1. Remove register_globals completely
+1 (then we can cleanup the mess in ext/session too :)
2. Remove magic_quotes_*
+1 (definately, finally, at last! The filter stuff obsoletes those anyway?)
3. Add input filter extension which will in
Oh, and I almost forgot one wishlist item I've had on my list for a long
time (I hope you guys have an open mind)
How about doubling integer precision to 64 bits and float/double precision
to 128 bits? It's in line with 64 bit CPU capabilities, and personally, I
wouldn't mind it a bit if i
Now I'm not the person with the kind of karma that should make you guys
listen, but in case you are interested, I'll just add my 2 cents
> 1. Remove register_globals completely
+1
> 2. Remove magic_quotes_*
+1000
> 6. Remove some stuff that has been marked deprecated since PHP 3/4
+1
> A cou
Wez Furlong wrote:
On 8/12/05, Wez Furlong <[EMAIL PROTECTED]> wrote:
A reasonable goal would be to make sure that all our extensions are
full pecl citizens, so that intermediate fixes to any of these so
called "core" extensions could be released via PECL very easily.
One of the biggest gripe
> 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.
I have no karma to +1, but would if I could. It would be wonderful if
something like xdebug could profile with op code cache on as well,
should it be possible. :
PS: This doesn't necessarily mean that they all need to be physically
unbundled from the main distro.
--Wez.
On 8/12/05, Wez Furlong <[EMAIL PROTECTED]> wrote:
> A reasonable goal would be to make sure that all our extensions are
> full pecl citizens, so that intermediate fixes to any of these so
A reasonable goal would be to make sure that all our extensions are
full pecl citizens, so that intermediate fixes to any of these so
called "core" extensions could be released via PECL very easily.
One of the biggest gripes our SA's have is that if they forget to
enable a core PHP extension and l
David,
Don't know if you read my post from last night, but I played around with
functions in namespaces and they worked (the change was pretty easy). Though
all this allowed was the following:
So, for your string example, all this would buy is that you'd call
str:replace instead of str_replace
Jani and Derick have so far done a very good job doing that, I think
just about all uncommon extensions have been migrated. But, if something
was missed moving it to pecl would be a good idea.
Ilia
Michael Wallner wrote:
> Rasmus Lerdorf wrote:
>
> [lots of reasonable points]
>
> What about mov
Rasmus Lerdorf wrote:
[lots of reasonable points]
What about moving some/many extensions from core to pecl?
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> 1. Remove register_globals completely
>
Amen! +1
> 2. Remove magic_quotes_*
>
Hallelujiah! +1
> 3. Add input filter extension which will include a mechanism for
>application developers to very easily turn it off which would swap
>the raw GPC arrays back in case the site had it turned on
> I have a #9 to share, too:
> Assuming that PHP 6.0 will also have namespaces support (which would be
> cool), it might make sense to move all internal functions to use namespaces
> (if they support functions sitting in there - doesn't seem like Jessie's
> current patch will, but then, maybe there
I wrote:
Though there's already a diff against HEAD, but it's
now about 7 hours old, so it may be inapplicable.
http://dev.iworks.at/PATCHES/
Actually it seems that there were no more commits,
so the available patch should work fine.
Regards,
Mike
--
PHP Internals - PHP Runtime Development
Marcus Boerger wrote:
Hello Michael,
can you do this again please for HEAD (no 5.1) now that the major unicode
work is done?
Uhm, not until Tuesday, sorry.
Though there's already a diff against HEAD, but it's
now about 7 hours old, so it may be inapplicable.
http://dev.iworks.at/PATCHES/
Th
Duh... "internal functions" is the wrong term, of course. I mean all the
functions that ship with PHP. The old ones would still be available, but you
could do PHP.String.pos() and stuff like that alternatively.
- David
> -Original Message-
> From: David Zülke [mailto:[EMAIL PROTECTED]
>
Maybe this is too far reaching but what about making function
parameter orders consistent? For example, make in_array() require
in_array(array haystack, mixed needle[...) just as most of the string
functions.
-D
On Aug 12, 2005, at 12:32 PM, Ilia Alshanetsky wrote:
This is a very good, p
On 8/12/05 2:50 PM, "David Zülke" <[EMAIL PROTECTED]> wrote:
> I have a #9 to share, too:
> Assuming that PHP 6.0 will also have namespaces support (which would be
> cool), it might make sense to move all internal functions to use namespaces
> (if they support functions sitting in there - doesn't
As little as it means, +1
- Davey
Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break some
more stuff and do a bit of spring cleaning. It would mean many apps
would need some work to work on PHP 6,
Attached is a patch to fix the build with zend mm disabled. (just a little
typo)
Nuno
Index: Zend/zend_alloc.h
===
RCS file: /repository/ZendEngine2/zend_alloc.h,v
retrieving revision 1.66
diff -u -r1.66 zend_alloc.h
--- Zend/zend
+1 to all of these.
I have a #9 to share, too:
Assuming that PHP 6.0 will also have namespaces support (which would be
cool), it might make sense to move all internal functions to use namespaces
(if they support functions sitting in there - doesn't seem like Jessie's
current patch will, but then,
On Aug 12, 2005, at 2:19 PM, Derick Rethans wrote:
On Fri, 12 Aug 2005, George Schlossnagle wrote:
3. Add input filter extension which will include a mechanism for
application developers to very easily turn it off which would
swap
the raw GPC arrays back in case the site had it turn
I submitted this request earlier, not sure if it went through. Apologies for
the re-post.
I am working on adding i18n support, more specifically I'm working on the
strings APIs. Andrei Zmievski suggested that I apply for a CVS account here.
If my preferred UID(rolland) is not available, please
This is a very good, point we really should drop support for things like
gd1 (no reason anymore, latest versions (including bundled) have GIF
support). These only add a hundreds of ifdefs to the code or prevent
usage of new(er) functionality.
IMHO we should see what is the lowest possible version
George Schlossnagle schrieb:
> Radically change all the operator syntaxes.
http://www.gravitonic.com/software/php/patches/ze2_concat_obj_op.diff.gz
:-)
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514
I would like to add item #9:
* start commenting the code, plz *
As long as we don't have any documentation describing internals,
comments in the code are something I personally would _really_ like to see.
And the more the better.
On Fri, 12 Aug 2005 10:48:20 -0700
Rasmus Lerdorf <[EMAIL PROTE
Hello,
+1 to all things, same comment as the opcode cache Ilia's one.
I would like to add one from my wishes:
Bump version for the required library as high as possible (or
realist) and do not support museum softwares at all, like droping
freetype v1 for example. Most of the users do not use it a
Rasmus Lerdorf schrieb:
> 1. Remove register_globals completely
+1
> 2. Remove magic_quotes_*
+1
> 3. Add input filter extension which will include a mechanism for
>application developers to very easily turn it off which would
>swap the raw GPC arrays back in case the site had it turn
On Fri, 12 Aug 2005, George Schlossnagle wrote:
> > 3. Add input filter extension which will include a mechanism for
> >application developers to very easily turn it off which would swap
> >the raw GPC arrays back in case the site had it turned on by
> >default.
>
> That seems a bit
+1 to all things here.
-Sterling
On 8/12/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> Since we are breaking a lot of stuff in 6.0, at least with
> Unicode_semantics=On I am wondering if it may not be time to break some
> more stuff and do a bit of spring cleaning. It would mean many apps
> wo
On Aug 12, 2005, at 1:48 PM, Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break
some
more stuff and do a bit of spring cleaning. It would mean many apps
would need some work to work on PHP 6, bu
I agree on all points. Case sensitivity would be nice IMO, but I can
continue to live without it.
--Wez.
On 8/12/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> Since we are breaking a lot of stuff in 6.0, at least with
> Unicode_semantics=On I am wondering if it may not be time to break some
>
Rasmus Lerdorf wrote:
1. Remove register_globals completely
2. Remove magic_quotes_*
3. Add input filter extension which will include a mechanism for
application developers to very easily turn it off which would swap
the raw GPC arrays back in case the site had it turned on by default.
Y
Rasmus Lerdorf wrote:
> 1. Remove register_globals completely
+1
> 2. Remove magic_quotes_*
+1
> 3. Add input filter extension which will include a mechanism for
>application developers to very easily turn it off which would swap
>the raw GPC arrays back in case the site had it turned o
On Aug 12, 2005, at 10:48 AM, Rasmus Lerdorf wrote:
1. Remove register_globals completely
Yes.
2. Remove magic_quotes_*
Yes. Nothing but trouble, this one.
3. Add input filter extension which will include a mechanism for
application developers to very easily turn it off which would sw
On Fri, 12 Aug 2005, Rasmus Lerdorf wrote:
> Since we are breaking a lot of stuff in 6.0, at least with
> Unicode_semantics=On I am wondering if it may not be time to break some
> more stuff and do a bit of spring cleaning. It would mean many apps
> would need some work to work on PHP 6, but at t
Hello Michael,
can you do this again please for HEAD (no 5.1) now that the major unicode
work is done?
marcus
Friday, August 12, 2005, 3:54:58 PM, you wrote:
> The patches are online at:
> http://dev.iworks.at/PATCHES/
> Thanks,
> --
> Michael - < mike(@)php.net >
Best regards,
Marcus
-
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break some
more stuff and do a bit of spring cleaning. It would mean many apps
would need some work to work on PHP 6, but at the same time I think it
is work people would welcome
If you want to see exactly what codepoints comprise a Unicode string,
use the new var_inspect() function.
unicode(3) "aԃ～" { 0061 0503 ff5e }
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in svn trunk
On 8/12/05, steve roussey <[EMAIL PROTECTED]> wrote:
> Has the upload progress patch been ever been voted up or down?
>
> -steve--
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
It doesn't output so many errors as before, but still fails:
"undefined reference to 'zend_ustrdup'"
Nuno
- Original Message -
Should be fixed now.
-Andrei
On Aug 12, 2005, at 9:16 AM, Nuno Lopes wrote:
Just a note to tell you that the build is broken when configured with
'--disab
Should be fixed now.
-Andrei
On Aug 12, 2005, at 9:16 AM, Nuno Lopes wrote:
Just a note to tell you that the build is broken when configured with
'--disable-zend-memory-manager'.
Thats because you forgot to add the eumaloc() and friends in the else
part of USE_ZEND_MALLOC (zend_alloc.h).
Nu
On 8/12/05, Brian J. France <[EMAIL PROTECTED]> wrote:
> I see the code for SO_LINGER in apr_socket_opt_set, but I don't see any
> place in the server code that calls apr_socket_opt_set with
> APR_SO_LINGER.
I stand corrected. I should have used gdb and tested that before I
posted. So they put cod
On Aug 12, 2005, at 8:18 AM, <[EMAIL PROTECTED]> wrote:
Dmitry,
i'm glad its fixed, but i was hoping it wouldnt get fixed this way
;-)
maybe a lower impact way would have been to move the use of
U_CLASS_ENTRY
into zend_parse_parameters, zend_throw_exception, instanceof_function
etc ?
Y
Dmitriy,
I think it might be more clear to use eumalloc() macro instead of
things like this:
UChar *uname = malloc(UBYTES(args[n].name_len));
-Andrei
On Aug 12, 2005, at 4:29 AM, Dmitry Stogov wrote:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Just a note to tell you that the build is broken when configured with
'--disable-zend-memory-manager'.
Thats because you forgot to add the eumaloc() and friends in the else part
of USE_ZEND_MALLOC (zend_alloc.h).
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
On Aug 12, 2005, at 10:52 AM, steve roussey wrote:
On 8/12/05, Brian J. France <[EMAIL PROTECTED]> wrote:
Really? We just did a around of discussion/debugging on this at work
and I found that it uses ap_lingering_close which is like the
lingering_close function in 1.3.
:)
Yes, it does do ap
Has the upload progress patch been ever been voted up or down?
-steve--
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 8/12/05, Brian J. France <[EMAIL PROTECTED]> wrote:
> Really? We just did a around of discussion/debugging on this at work
> and I found that it uses ap_lingering_close which is like the
> lingering_close function in 1.3.
:)
Yes, it does do ap_lingering_close, and it sets SO_LINGER. I have no
srclib/apr/network_io/unix/sockopt.c:if
(setsockopt(sock->socketdes, SOL_SOCKET, SO_LINGER, (char *) &li,
sizeof(struct linger)) == -1)
...
It gets set if APR_SO_LINGER, is set which it is:
srclib/apr/include/apr_network_io.h:#define APR_SO_LINGER1
/**< Linger */
and if
On Aug 11, 2005, at 7:48 PM, steve roussey wrote:
o Apache 2+ uses SO_LINGER by default if it defined for that system.
Really? We just did a around of discussion/debugging on this at work
and I found that it uses ap_lingering_close which is like the
lingering_close function in 1.3.
Apache
http://www.sebastian-bergmann.de/stuff/pdo-zts.txt
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
The patches are online at:
http://dev.iworks.at/PATCHES/
Thanks,
--
Michael - < mike(@)php.net >
signature.asc
Description: OpenPGP digital signature
On Thu, 11 Aug 2005 16:36:56 -0700
Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> By now, Unicode merge into the public tree has taken place. How do you
> get started?
>
> 1. Take a deep breath.
>
> 2. Download and build ICU 3.4.
SuSE users can use fresh 3.4 rpms from the link below.
You'll most
Dmitry,
i'm glad its fixed, but i was hoping it wouldnt get fixed this way ;-)
maybe a lower impact way would have been to move the use of U_CLASS_ENTRY
into zend_parse_parameters, zend_throw_exception, instanceof_function etc ?
clayton
""Dmitry Stogov"" <[EMAIL PROTECTED]> wrote in message
Here:
http://ftp.emini.dk/pub/php/win32/icu-3.4-MSVC-6.0.zip
Edin
Michael Wallner wrote:
I wrote:
Quick question: can one use the provided binary packages for Win32?
Not unless one has MSVC-7.1 -- it seems...
--
Michael - < mike(@)php.net >
--
PHP Internals - PHP Runtime De
I wrote:
> Quick question: can one use the provided binary packages for Win32?
Not unless one has MSVC-7.1 -- it seems...
--
Michael - < mike(@)php.net >
signature.asc
Description: OpenPGP digital signature
Possible fix for error 'void *' : unknown size
Regards,
--
Michael - < mike(@)php.net >
string.c.txt
Description: unknown/unknown
signature.asc
Description: OpenPGP digital signature
On Thu, 11 Aug 2005, Andrei Zmievski wrote:
> 2. Download and build ICU 3.4.
>
> Location: http://www-306.ibm.com/software/globalization/icu/downloads.jsp
For Debian users, doing "apt-get install libicu34-dev" should pull it in
(on debian unstable).
Derick
--
PHP Internals - PHP Runtime
Hi Andrei Zmievski, you wrote:
> 2. Download and build ICU 3.4.
Quick question: can one use the provided binary packages for Win32?
Thanks,
--
Michael - < mike(@)php.net >
signature.asc
Description: OpenPGP digital signature
On Thu, 11 Aug 2005 [EMAIL PROTECTED] wrote:
> i would commit if i had write access...
Please put those patches somewhere online, as they're garbled when you
send them like this:
>
> Index: ext/standard/string.c
> ===
> RCS file:
86 matches
Mail list logo
