[PHP-DEV] PHP hackers

Hey guys. De-lurking here briefly to ask for a favor. I need to hire one or two people to hack on a pretty complex PHP extension plus supporting C/C++ code and I’m at the end of my wits with going via the usual avenues. If you have any suggestions on where to look next or know of anyone, could you

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

On Sat, Jun 4, 2011 at 4:52 AM, David Zülke wrote: > Yes, I know. Then why are you and others demanding that the resulting syntax > be fully compatible with JSON so it could be parsed by other JSON parsers? > That makes no sense at all. A file with just ["foo"] in it won't be > interpreted by P

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

On Fri, Jun 3, 2011 at 3:11 PM, David Zülke wrote: > It's not FUD. > > It is different from writing json_decode('ä\u0123'), because json_decode() in > PHP only accepts UTF-8 encoded input; > > Give it a shot: > > $chr = "\xC3\xA4"; // "ä" as UTF-8 > var_dump(json_decode('["' . $chr . '\u00e4"]')

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Stop spreading FUD, please. It's no different than writing json_decode("ä\u0123"). Your statement, "the stuff in bar in UTF-8" is wrong. The \u0123 escape sequence is a representation of a Unicode character, not the character itself. This representation can be encoded in any ASCII-compatible enco

Re: [PHP-DEV] PHP 6

On 3/13/10 11:57 AM, Derick Rethans wrote: I am also in favour for getting back to one branch for new development. And that "branch" should be trunk. However, I am a little bit reluctant to just "kill" all Unicode support. I don't think we can get around the fact that propr Unicode support is goi

Re: [PHP-DEV] [PATCH] Bug #47481

On Mon, Jul 13, 2009 at 7:38 PM, Herman Radtke wrote: > This bug only exists in PHP 5.x. The unicode support in PHP 6 takes > care of it already, but I added a PHP 6 version of the test case as > well. > Looks good. -Andrei

Re: [PHP-DEV] Multithreaded C Gearman worker to run PHP scripts

Can you explain how this is different from the worker class provided by pecl/gearman? -Andrei On Tue, Jul 14, 2009 at 10:28 AM, Thomas Koch wrote: > Good evening Europe, good morning America, > > I hacked a gearman worker today that runs PHP scripts. As you can easily > spot > on first sight, I

Re: [PHP-DEV] ctype functions going, going, gone?

On Tue, Jul 14, 2009 at 1:58 PM, Keryx Web wrote: > Hi all! > > I am preparing a Server Side Scripting (using PHP) course for the Web > Standards Project Interact[1]. As I am going through security considerations > I note that the ctype functions are being used in the manual[2] and have not > bee

Re: [PHP-DEV] Patch and RFC for adding DTrace probes to PHP

On Tue, Jul 14, 2009 at 2:31 PM, David Soria Parra wrote: > In the current state the patch introduces a wrapper for the current > executor to fire function-entry probes. It was mentioned that it might > be useful to not use an own funciton for that. As I want to make things > cleaner for the curr

Re: [PHP-DEV] Type hinting/casting request for vote

Ilia Alshanetsky wrote: PHP 6 is too far off in a practical sense (sorry Andrei) from the time where I can see myself using it in production or other people benefiting from this function. The (simpler) variant of provided patch is what is currently being used on production, if it can go into 5.

Re: [PHP-DEV] Type hinting/casting request for vote

Andrei Zmievski wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a

Re: [PHP-DEV] Type hinting/casting request for vote

Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended wi

Re: [PHP-DEV] Memory corruption bug

Pierre Joye wrote: committed. I see that it's not in HEAD though, probably because HEAD has never been updated to use safe-allocation functions? I see no trace of __zend_calloc() there. We should probably port that from 5.3. -Andrei -- PHP Internals - PHP Runtime Development Mailing List T

Re: [PHP-DEV] Memory corruption bug

Stanislav Malyshev wrote: You just did safe_address in _safe_malloc(nmemb, len, 0) which should have called E_ERROR if nmemb*len overflows, so do you need to do it again? Leaving a comment about it wouldn't hurt though :) Yeah, you're right, but I didn't write the code. :) Regardless, I think

Re: [PHP-DEV] A patch for HEAD

Gwynne Raskind wrote: I'm proposing the inclusion of this patch in HEAD (which I'll port it to if I get a thumbs-up here), and possibly 5.3.2. Criticism and angry flames welcome. Constructive critcism and good-natured comments will be ignored ;) (just kidding... or am I?). I'm fine with this

[PHP-DEV] Memory corruption bug

I found what is effectively a memory corruption bug in all the branches. pecalloc() uses the wrong length to zero out the memory. Patch is attached, although I'm somewhat concerned about using just (nmemb*len) instead of something like safe_address(nmemb*len), but safe_address() is inlined in ze

[PHP-DEV] Re: [PHP-CVS] cvs: php-src / README.PARAMETER_PARSING_API /win32/build config.w32 ZendEngine2 Zend.m4 zend_API.c zend_compile.c zend_execute.c zend_execute_API.c zend_operators.c zend_oper

Matt Wilmas wrote: Sure! It makes no difference to me at all. Should I just remove that part completely? I didn't know if it would even be used -- just thinking more of "it's there if someone wants the option..." Do you have examples of functions that might have a use for that? -Andrei --

Re: [PHP-DEV] Notes from the PDM in Chicago

Lukas Kahwe Smith wrote: To me its absolutely critical that we do not give the impression that the next bigger update after 5.3 will be 5.4. The next big thing is 6.0. If we do a 5.4 then it will come after 6.0, just like 4.4 to ease migration. But it makes no sense to release 5.4 with forward

Re: [PHP-DEV] Notes from the PDM in Chicago

Greg Beaver wrote: I think some people were "volunteered" based on prior contributions? The first I heard of my role in phar for PHP 6 was reading it on the wiki. Not that I have a problem with that, but I wonder if there are other people who don't know their names are on the list? Yes, we bas

Re: [PHP-DEV] Notes from the PDM in Chicago

Elizabeth M Smith wrote: yes Hannes - interfaces for userland implemented streams would help people trying to figure out if they have all the methods they need for a particular stream type (SeekableStream et al) - this would be backward compat (you wouldn't HAVE to implement the interfaces IIRC,

Re: [PHP-DEV] Notes from the PDM in Chicago

Hannes Magnusson wrote: I assume the names in parentheses are people who volunteered to do the task, not whoever brought it up? (very ambitious crowd) :) Volunteered to do it or at least guide others. Regarding the stream interface, what does "FIIK" mean? I would really love such an interface

[PHP-DEV] Notes from the PDM in Chicago

Taking advantage of php|tek bringing a lot of people together, we had a PHP developers meeting over 2 days before the conference. Day 1 was dedicated to technical issues in PHP 5 and 6, and day 2 was spent discussing potential features, migration issues, current roadblocks, etc. People who wer

Re: [PHP-DEV] [PATCH] create_function/zend_eval_string aren't binary-safe

Matt Wilmas wrote: Hi all, I first noticed this with preg_replace()'s /e modifier (SO many other issues with that...), but it also happens with create_function() and a few other places where zend_eval_string() is used. Other code evaluation in PHP is binary-safe, so it seems like these areas

[PHP-DEV] Re: ext/filter and rfc1867 problem

Does anyone have any idea what I'm talking about here? Derick? Rasmus? Pierre? Bueller? Andrei Zmievski wrote: I ran into an issue today that seems to be a genuine bug. In rfc1867.c there is code like this: if (sapi_module.input_filter(PARSE_POST, param, &value, value_len, &am

[PHP-DEV] ext/filter and rfc1867 problem

I ran into an issue today that seems to be a genuine bug. In rfc1867.c there is code like this: if (sapi_module.input_filter(PARSE_POST, param, &value, value_len, &new_val_len TSRMLS_CC)) { /* register the variable */ } The sapi_module.input_filter points to php_sapi_filter(). That r

Re: [PHP-DEV] Request decoding in PHP 6 [patch]

Jani Taskinen wrote: This is a good idea. However, we still have the issue of extensions needing some data from the request before $_POST or $_GET are ever mentioned in the script, since the decoding is done only at that time. You just need to call zend_is_auto_global() to trigger the init.

Re: [PHP-DEV] PHP 5.2.10

patch available for review? Ilia Alshanetsky On 14-May-09, at 4:04 PM, Pierre Joye wrote: hi Ilia, On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski wrote: Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

Ilia Alshanetsky wrote: Andrei, I think Moriyoshi has a point here there are several reports by people who are affected by this, I think it makes sense to leave the introduced functionality as is in 5.3/6, but for PHP 5.2 it probably should be rolled back. Fine. Our sorting/comparison is pr

Re: [PHP-DEV] PHP 5.2.10

Ilia Alshanetsky wrote: Andrei, There is no question about functionality being useful for some people. But what is the point of different branches if we put whatever we want into each branch? We may as well stick to one branch and commit features, bug fixes, etc... into it. I would fully ag

Re: [PHP-DEV] PHP 5.2.10

Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) Great, so I'll just end up copying almost all of ext/json code into pecl/memcached then. Hooray for loose coupling. -Andrei -- PHP Internals - PHP Runtime Dev

Re: [PHP-DEV] PHP 5.2.10

ay-09, at 1:39 PM, Andrei Zmievski wrote: Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release befor

Re: [PHP-DEV] Request decoding in PHP 6 [patch]

Ilia Alshanetsky wrote: Andrei, For you point #7 regarding the session extension. Perhaps we should make a simple API allowing extensions to register callbacks to execute on input data. Once request encoding is set, the callbacks can be ran for GPC input allow extensions (not just session) to

Re: [PHP-DEV] PHP 5.2.10

Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued.

[PHP-DEV] Request decoding in PHP 6 [patch]

Request decoding is one of a few remaining pieces of the Unicode puzzle. The proposed solution was outlined in a blog post [1] I wrote a while back. There has been no movement on this front pretty much since then, but now that 5.3 is wrapping up I want to put some momentum behind PHP 6. Towards

Re: [PHP-DEV] rfc1867.c question

Jani Taskinen wrote: What branch and what lines? I checked PHP_5_2 and as far as I can tell, there is no such function that simply returns when passed track_vars_array is NULL.. Maybe HEAD is different, but that branch doesn't even compile so I don't really have time for it.. :) I was talki

[PHP-DEV] rfc1867.c question

Why do we have safe_php_register_variable() calls there with NULL for track_vars_array? The underlying code simply returns if that parameter is NULL. Is it an oversight or some legacy stuff? -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.n

[PHP-DEV] Making ext/filter always-on

The ext/filter extension should be always on in PHP 6, so I am planning on removing the configure switch --disable-filter. Heads up. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variation

Pierre Joye wrote: The new parsing API and the strictness of this "return NULL" rule is new and arguable. As it is not that important (work 'round is easy), I tend to prefer to minimize the wtf instead of being too strict. This "new parsing API" is not so new, dammit. :) It's a few years old by

Re: [PHP-DEV] PHP 6 TODO list

Hannes Magnusson wrote: Regarding the migration item... Wasn't there a gsoc project last year that did exactly that? I think there was, but I don't know if they actually did anything. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/uns

Re: [PHP-DEV] Reserved namespaces

Christian Schneider wrote: Things gettings reserved at a later stage (like originally keywords, now namespaces) can lead to a big deal of frustration. Therefore I think it is crucial to have a clear naming guide now. And these guidelines have to be noticed by everybody who starts to use namespac

[PHP-DEV] PHP 6 TODO list

Hi everyone, I've been cleaning up the TODO items on the Wiki. I created a "Backlog" section and moved all the items from "PHP 5.3/Future PHP releases" and "PHP 6/Undiscussed" to it. This will serve as a general repository for any items that have been mentioned, but on which we have not made a

[PHP-DEV] FD_SETSIZE limitation

Can someone explain why ext/sockets and also stream socket functions care about FD_SETSIZE? # define PHP_SAFE_FD_SET(fd, set) do { if (fd < FD_SETSIZE) FD_SET(fd, set); } while(0) On Linux, it's not a hard limitation imposed by the kernel. It's configurable via sysctl. -Andrei -- PHP Inte

[PHP-DEV] Re: Extension dependency problems

Anyone? Bueller? Andrei Zmievski wrote: It seems that our PHP_ADD_EXTENSION_DEP() macro from acinclude.m4 does not actually do any linking against the dependent extension despite the comment in it: dnl Some systems require that we link $2 to $1 when building The consequence of this is

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

so on, otherwise it's gonna be a mess. Moriyoshi On Wed, Feb 18, 2009 at 11:43 AM, Moriyoshi Koizumi wrote: On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski wrote: SORT_STRING can only reliably deal with strings - its behavior on non-string type is basically broken. Unless we agree that PHP is Tc

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

Moriyoshi Koizumi wrote: As I said earlier, the function is never supposed to be used with objects. Therefore, we cannot declare it to be broken, and any change to the behavior anyway leads to a huge BC break. I got a report that claims the reporter's real-world application behaves strangely with

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

Moriyoshi Koizumi wrote: Ilia Alshanetsky wrote: I've discussed this issue with Andrei at least a month ago (if not longer) when the patch was originally added, and I believe that the introduced behavior is the correct one. IMO correct or not depends on the context where the function is used.

[PHP-DEV] Extension dependency problems

It seems that our PHP_ADD_EXTENSION_DEP() macro from acinclude.m4 does not actually do any linking against the dependent extension despite the comment in it: dnl Some systems require that we link $2 to $1 when building The consequence of this is that if the dependent extension (like igbinary.

Re: [PHP-DEV] Reserved namespaces

Lukas Kahwe Smith wrote: I think the decision was to not yet bother with reserving namespaces or starting to namespace-ify extensions. We might however want to put out a naming guide for namespaces. I agree. Whether the error is raised or not on reserved namespaces can be done later, but we s

Re: [PHP-DEV] Reserved namespaces

Hannes Magnusson wrote: I don't think we have to treat our users like a total fcking idiots. If anyone thinks using "SPL" or "PHP" as their root namespace is a good idea they deserve to be kicked in the nuts. And who's going to administer this kicking? -Andrei -- PHP Internals - PHP Runtime D

[PHP-DEV] Reserved namespaces

Forgive me if I've missed this in the heat of all the namespaces discussions. Did we consider having reserved namespaces, like 'PHP' or 'SPL', so that if a user tries to declare a namespace with that name an error is raised? -Andrei -- PHP Internals - PHP Runtime Development Mailing List To un

Re: [PHP-DEV] GSoC 2009

Scott MacVicar wrote: Hi Everybody, It's almost that time again where we rush at the last minute to organise something for the Google Summer of Code, so in the interest of being prepared I'm thinking it's time to start collecting ideas for potential students. I've updated a few of the Wiki pa

Re: [PHP-DEV] Private member/method access inconsistency

Robin Fernandes wrote: Cool, looks like this has gone in already. A couple of comments: 1. I think the change has not been made for callbacks (so callbacks now behave differently from normal method invocations). 2. Perhaps on 5_3 and HEAD, the equivalent change should be made for __callStatic()?

[PHP-DEV] Private member/method access inconsistency

A colleague at Digg pointed me to this blog entry: http://atomized.org/2008/11/more-tough-love-from-php/ To me it looks like a large inconsistency in the way we invoke overloaded handlers for members vs. methods. I am not sure how it came to be this way, but it's probably something we shoul

Re: [PHP-DEV] CVS Account Request: magicaltux

Lukas Kahwe Smith wrote: I also intend later (and after some discussions, if anyone has any interest in WDDX) to add a feature to WDDX to provide the ability to stream a packet (create a packet ressource while providing a stream descriptor, send the XML code for the variables when added, then c

Re: [PHP-DEV] array_key_exists BC break

I meant '&' actually. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] array_key_exists BC break

Felipe Pena wrote: So as suggested and wished, here is a patch that add a modifier '%' to 'a' in parameter parsing API, where it allows object that implements ArrayAccess to be accept. Although it doesn't invoke any their methods, i.e. just how it works nowdays. A list of functions that allow ob

Re: [PHP-DEV] alpha2 scheduled

marius popa wrote: yes is true that i like to have strong opinions and yes i could be wrong in most of them but when all the comunity screems at the namespace issue i think core developers should be more diplomatic and offer the good solution not close the eyes and wash the hands and go forward

Re: [PHP-DEV]

You're welcome. Benjamin Schulz wrote: Thanks for another great argument to move away from PHP asap. On 25.10.2008, at 20:07, Lukas Kahwe Smith wrote: that we have decided to go with backslash as new separator for namespaces. -- PHP Internals - PHP Runtime Development Mailing List To unsu

Re: [PHP-DEV] array_key_exists BC break

Sean Coates wrote: I was hoping someone would revive this thread (-: In Habari, we have/had an ArrayObject that we passed to the view (theme). As far as the theme knows, this is an array (but it has extra methods if the theme is particularly smart). Unfortunately, this breaks in 5.3, because

Re: [PHP-DEV] array_key_exists BC break

Johannes Schlüter wrote: btw. this also affects quite a few other functions: next/current/key/... at least ... and maybe more after using the "new" parameter parsing API. I would say "no" for 5.3. But for 6 it would be fantastic to have all array-related operations supporting ArrayAccess inter

Re: [PHP-DEV] my last attempt at sanity with namespaces

Thank you for the voice of sanity, Greg. I agree with your approach. -Andrei Greg Beaver wrote: Hi, http://wiki.php.net/rfc/namespaceissues Read it and discuss. Let's be clear people: the technical problems in namespaces are limited and solvable. The problems in the political environment su

[PHP-DEV] Subversion migration

Whatever happened to the Subversion migration effort? -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] socket_select() problem

Ian Eure wrote: I wrote a simple testcase that submits a single job to Gearman. If I run it under Apache2, I get the socket_select() warning. If I run it from the CLI, I don't. I'm also pointing the CLI at the Apache2 php.ini file. At this point, I don't know how to track this any further. If I

Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP

Yes, I would rather put it in 5.4 (or whatever the next version) is and make sure that along with lambdas/closures we have a way of referring to functions/methods as first-class objects. -Andrei Marcus Boerger wrote: Hello Stanislav, nicely put but not in agreement with the PHP world. Firs

Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]

That's why there is TextIterator. And it's also much faster (in PHP 6) than iterating through string using indexes. -Andrei Stefan Walk wrote: On Tuesday 17 June 2008 08:27:37 Arvids Godjuks wrote: 2008/6/16 Edward Z. Yang <[EMAIL PROTECTED]>: PHP userland code may not treat strings as first

Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]

Yes, and we can have TextIterator work on binary strings as well (perhaps by adding TextIterator::BYTE constant). -Andrei Edward Z. Yang wrote: Andrei Zmievski wrote: Maybe TextIterator can be backported from HEAD, because it allows for just that. foreach (new TextIterator($str) as $c

Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]

Maybe TextIterator can be backported from HEAD, because it allows for just that. foreach (new TextIterator($str) as $c) { ... } Arvids Godjuks wrote: 2008/6/16 Edward Z. Yang <[EMAIL PROTECTED]>: PHP userland code may not treat strings as first class arrays, but that's certainly how they a

Re: [PHP-DEV] Re: Focus on HEAD

Yes, good idea. PRE-BFUC (PRE-BigFreakingUnicodeCleanup) -Andrei Stanislav Malyshev wrote: Hi! Oh, and third - if nobody gets back to us by Friday over these patches we'll just commit :) Don't know about Felipe's larger corner, but I tested mine to death already. I think it would also be n

Re: [PHP-DEV] Re: Focus on HEAD

Sure. Steph Fox wrote: Is there a patch that does that? I'm fine with removing these checks. If there isn't already, there soon will be :) Did you want to review it prior to commit? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.ne

[PHP-DEV] Re: Focus on HEAD

Is there a patch that does that? I'm fine with removing these checks. -Andrei Steph Fox wrote: Hi Andrei, all, Can we please have a clear, on-list explanation of the reason(s) the non-Unicode mode blocks can't be cleared out of core in CVS HEAD today? As in, if (!UG(unicode)) Thanks

Re: [PHP-DEV] Re: Short syntax for array literals [...]

I'm +1. -Andrei Sebastian Deutsch wrote: fyi - i added a RFC http://wiki.php.net/rfc/shortsyntaxforarrays please add your votes cheers Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]

Steph Fox wrote: OK, so there are some things that should maybe 'just happen' here, and also when 'S' is used: PHP_NAMED_FUNCTION(php_if_crc32) { char *p; int len, nr; php_uint32 crcinit = 0; register php_uint32 crc; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "S", &p, &nr) == FAILUR

Re: [PHP-DEV] BC an' all that

That would be a major WTF factor for me: strings are unicode but (string) is binary. -Andrei Steph Fox wrote: Because the majority of use cases involving strings do not involve binary strings. Or, as Rasmus said, "logic". Not strings, *casts* to string. Or is there no way to differentiate b

Re: [PHP-DEV] BC an' all that

Because the majority of use cases involving strings do not involve binary strings. Or, as Rasmus said, "logic". -Andrei Steph Fox wrote: Hi all, Tony's not alone, I'm also playing with PHP 6 today. As Edward mentioned when I started talking about the upgrade path, we don't have a way to cop

Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]

UG(ascii_conv) is for the format string, not the arguments. The warning is thrown by this code: convert_to_string_ex(argv[currentarg]); It should check the arg type and return with a warning if it's Unicode. -Andrei Steph Fox wrote: It does - 'UG(ascii_conv)' - but sometimes there's a u

Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]

Nothing premature about it. It was time. UG(unicode) checks are still secondary I think - they don't prevent us from doing tests and moving forward, although cleaning them up would be nice. pack() should take binary strings only, methinks. -Andrei Steph Fox wrote: I would've hoped that PHP

Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]

Yes, but we should run some sort of test suite and see what exactly breaks with unicode strings as the default ones. On Mon, May 19, 2008 at 2:42 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > > On 19.05.2008, at 23:34, Cristian Rodríguez wrote: > > Andrei Zmievski esc

[PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]

Done. See latest commit: switch is removed and mode is defaulted to On. -Andrei On Wed, May 14, 2008 at 5:59 AM, Steph Fox <[EMAIL PROTECTED]> wrote: > Hi all, > > Is there any chance of getting the unicode.semantics issue sorted soon? > > > >

Re: [PHP-DEV] Removal of unicode_semantics

The easiest thing would be just to default unicode_semantics to On internally and hide it from users. Don't remove all the UG(unicode) checks yet, because we can test migration/compatibility with those in place. -Andrei Derick Rethans wrote: On Wed, 7 May 2008, Andi Gutmans wrote: Yep, we sa

Re: [PHP-DEV] Removal of unicode_semantics

Precisely. Stefan Walk wrote: Lester Caine schrieb: That sounds like just the sort of edge case that Derick is suggesting needs logging for fixing up. unicode_semantics=on is just another bodge to to make it happen rather than a solution. I think I understand your description, and to my eyes

Re: [PHP-DEV] Removal of unicode_semantics

it strings. Just curious, do these decoding/encoding functions do something that Unicode support won't do? In slides by Andrei Zmievski Unicode symbols are written with \u. Why are they written with \x(hex) and \(octal) in current PHP6? \x and \(octal) inside Unicode strings are assumed to

Re: [PHP-DEV] Removal of unicode_semantics

As far as I remember, the latest point was to remove the unicode_semantics switch and presume that its value is always On. At the same time we said that binary strings should probably be the default string type (which I don't agree with), and that we need to have a test suite to see what exactl

Re: [PHP-DEV] What is the current state of PHP6?

Lester Caine wrote: I KEEP asking what is holding up making a beta release of PHP6, and I see nothing in the 2005 meeting that is anything more than a restructure and recompile using unicode as the base. MOST of the other things are just removing things that are now normally switched off anyway

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

Precisely. It was never a "secret", despite someone's paranoidal proclaiments.. -Andrei Stanislav Malyshev wrote: Those 'few people' were actually in the majority when it was put to the vote. Yes development could and should've been made public all along, but the fact remains that intl offers

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

Dammit, I sat on this record and I broke it.. :) -Andrei Pierre Joye wrote: By the way, when was this list created? Why discussions about the development of this upcoming core extension are not public and under php.net? I don't think it is a good thing and I dislike this way of working. --

Re: [PHP-DEV] [PATCH] Bug 43477 - Unicode error mode ignored

Where is the patch? Geoffrey Sneddon wrote: On 21 Mar 2008, at 12:09, Antony Dovgal wrote: On 03/18/2008 06:51 AM, Stephen Bach wrote: Attached is a simple proposed patch that fixes Bug 43477. Basically, the code that set the error mode of the ICU converter was giving it an instruction (the

Re: [PHP-DEV] [PATCH] Bug 43477 - Unicode error mode ignored

Okay. I'm fine with the patch. Stephen Bach wrote: Sorry for the ambiguity. Allow me to clarify: I meant that U_CONV_ERROR_SKIP and U_CONV_ERROR_SUBST should work the same as the other error modes. Otherwise, what's the point of having them? -Stephen On Tuesday 18 March 2008 06:02:36 pm Geof

Re: [PHP-DEV] [PATCH] Bug 43477 - Unicode error mode ignored

Why would we not want to stop on illegal sequences? -Andrei Stephen Bach wrote: Attached is a simple proposed patch that fixes Bug 43477. Basically, the code that set the error mode of the ICU converter was giving it an instruction (the context parameter) to only skip or substitute if the code

Re: [PHP-DEV] [RFC] Anonymous functions

Whichever one the newly developed features are going into these days. Seems to be 5.3 or 5.4. -Andrei On Feb 24, 2008, at 4:03 PM, Stanislav Malyshev wrote: Hi! To be clear, my statement was about the closures and not sexier anonymous functions. I agree that we need to do an RFC on this

Re: [PHP-DEV] [RFC] Anonymous functions

To be clear, my statement was about the closures and not sexier anonymous functions. I agree that we need to do an RFC on this matter. -Andrei On Feb 23, 2008, at 8:36 PM, Andi Gutmans wrote: I think we have to be very clear whether we are going to provide just a sexier notation for anonym

Re: [PHP-DEV] [RFC] Anonymous functions

Do we have a working patch somewhere then? -Andrei On Feb 23, 2008, at 12:43 PM, Marcus Boerger wrote: Hello Andrei, +1 Friday, February 22, 2008, 7:00:11 PM, you wrote: Yes, let's re-open, I'd like to get a closure on that issue (pun intended). -Andrei -- PHP Internals - PHP Runt

Re: [PHP-DEV] [RFC] Anonymous functions

Yes, let's re-open, I'd like to get a closure on that issue (pun intended). -Andrei On Feb 18, 2008, at 8:26 AM, Matvey Arye wrote: Hi All, I second this. Can we please re-open the discussion on anonymous functions as well as closures. That would be an awesome feature. create_function i

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

ntly using mbstring, is that correct? - Steph - Original Message ----- From: "Andrei Zmievski" <[EMAIL PROTECTED]> To: "Steph Fox" <[EMAIL PROTECTED]> Cc: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Chris Stockton" <[EMAIL PROTECTED]&g

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

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: "Rasmu

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

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,

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

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

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

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

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

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

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

As for PHP 6 generally: there needs to be a solid migration path, such as forwards-compatible syntax introduced to PHP 5. MediaWiki has extensive support for unicode in PHP 5, including a pure PHP implementation of NFC, cross-script and confusable character checks, extensive parsing of UTF-

Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP

On Jan 21, 2008, at 7:14 PM, Andi Gutmans wrote: I see I may not have been clear in my previous email. Indeed as Stas mentioned I agree we should not have a php.ini switch, i.e. unicode.semantics goes away. At the same time I propose: a) We invest considerable energy in figuring out and doc

  1   2   3   4   5   6   7   >