Re: [PHP-DEV] Tokyo/Kyoto Cabinet in 5.4
On 08/04/12 16:03, Geoffrey Sneddon wrote: Is it actually dead? [1] still states: I'll maintain the both of Tokyo Cabinet and Kyoto Cabinet because their values are different, as well as noting that Tokyo Cabinet is quicker in the single-threaded case. Given that both are maintained, as far as I can tell, as Tokyo Cabinet is quicker in the single-threaded case, as most PHP applications are, there is no reason to remove it. I don't believe Tokyo is dead, either. I've got half a patch for Kyoto support too, so I'll send that along when it's working. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tokyo/Kyoto Cabinet in 5.4
On 30/09/11 12:37, Hannes Magnusson wrote: Preferably replace it with Kyoto Cabinet support I suppose. I added the TC support initially, so I can look at replacing it over the weekend. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Improvements to HTTP stream metadata
Hi, Currently, if you open an HTTP stream using fopen(), and then call stream_get_meta_data() on it, you obtain an associative array within which as another with the key 'wrapper_data'. Inside that, there is a list of the HTTP headers from the server response. I'd like to make this a little more useful as currently I don't believe there's a way to get the response code from the remote end without parsing those headers yourself. While this isn't hard, I'd like to make the following changes: * move the current contents of the wrapper_data array to a key called 'headers' within wrapper_data; * Add a 'response_code' key, with the server response code as an integer * Optionally, add things like the mime type of the response. Anyone got any thoughts on this? I appreciate it'd be a BC break, but I think it might be useful. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improvements to HTTP stream metadata
On 30/06/11 22:29, Stas Malyshev wrote: Hi! On 6/30/11 1:44 PM, Michael Maclean wrote: * move the current contents of the wrapper_data array to a key called 'headers' within wrapper_data; This means breaking every script in existence that uses this data now. Probably not a good idea. Maybe we should think about a BC way to do the same. Yeah; I'm open to suggestions on that front. I couldn't really think of another way to do it. The same data also ends up in the bizarre $http_response_headers var that gets spontaneously created in local scope - I've wondered about how good that is to do. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Zend Signal Handling
On 02/06/11 18:20, Gustavo Lopes wrote: Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org escreveu: Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. Is there any advantage in killing it as opposed to simply not use it? I think he meant just replacing it in this patch. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On 31/05/11 19:42, Brian Moon wrote: https://wiki.php.net/rfc/shortsyntaxforarrays Since this was brought again recently by Rasmus snip I'm all for this, though I would confess to having a preference for the second syntax: $arr = [ 'foo' = 'bar', 'baz' = 'foo' ] seems to fit better with PHP than the other one, JSON-compatibility aside. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Bug #49852 Bug #53065 - Adding spl_autoload_case_sensitivity()
On 09/03/11 13:34, Mike Willbanks wrote: It seems like the only potential BC break is on linux if people were using all lowercase paths. To me it would seem like this is really not the case or would happen only sometimes. I'd have trouble finding a single one of my apps that had a path with any uppercase characters at all. They all run on Linux. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] LXR
Hi, I've seen quite a few reports that some people are seeing a CentOS test page when going to http://lxr.php.net. I, however, don't. If anyone reading this sees this, can you reply and let me know what your DNS resolves lxr.php.net as? Ideally, the output from dig or dnstracer would be handy. It *should* be resolving as a CNAME to sp2.php.net. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LXR
On 31/12/10 20:00, Reindl Harald wrote: What poor setup to display software-information on a non-configured hostname even calling ip-address directly instead mod_security blocking such calls The IP of the machine displaying the CentOS page is no longer mine, nor does it have anything to do with PHP, so there's nothing we can do. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mt_rand deprecated in trunk?
Hi, The comment on this commit: http://svn.php.net/viewvc?view=revisionrevision=303912 suggest getrandmax() and mt_getrandmax() were to be deprecated, but it seems Kalle might have typoed and deprecated mt_rand() instead - is that the case? -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allowing an array as a parameter for snmpget()/snmpgetnext()
On 20/09/10 20:46, Jorrit Kronjee wrote: Dear list, To better reflect the behavior of the snmpget command that comes with the Net-SNMP package the patch attached makes an array of OIDs as a parameter for the snmpget()/snmpgetnext() function possible. snip Looks good to me, for what it's worth. Anyone got objections? -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: kriscraig
On 10/08/10 20:28, Kris Craig wrote: Sorry, I guess it would help if I actually attached the patch. Here it is. The list strips attachments with filenames ending in something other than .txt - resend or perhaps put it online somewhere? -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ereg deprecation?
Hi, I think I asked this before on IRC, but I've forgotten the answer. I was just remembering that the ereg extension was due to be deprecated in PHP6 - does this still apply to trunk? -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
Michael Maclean wrote: Hi, I think I asked this before on IRC, but I've forgotten the answer. I was just remembering that the ereg extension was due to be deprecated in PHP6 - does this still apply to trunk? ...and by deprecated I of course mean removed. *Ahem*. (Thanks Philip!) -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Repetitive calling of Z_STRLEN_P(value) in ext/filter/logical_filter.c
Justin Dearing wrote: Hey, Sorry for pestering with excessive questions, but I've not done a lot of C programming. In filter.c, specificalyl in php_filter_validate_ip(), Z_STRLEN_P(value) gets called a lot. I know compilers tend to inline short functions, but are they smart enough to assign a variable to a repetive macro expansion? Z_STRLEN_P is just a macro that expands to a variant of Z_STRLEN, which in turn is just (zval).value.str.len. These macros will be expanded by the preprocessor before the code is actually compiled. http://php-og.mgdm.net/opengrok/xref/PHP_5_3/Zend/zend_operators.h#Z_STRLEN_P Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 44383 in ext/soap
David Zülke wrote: On 25.03.2010, at 22:05, Michael Maclean wrote: Did you also succeed in compiling it as a standalone extension? Could you try? There were some dependencies on ext/date symbols that gave me a hard time when trying that back then... and I lack(ed) the C-fu to fix that. Oh, I hadn't tried that, I'll give it a go. The updated version of David's patch is available here: http://mgdm.net/~michael/patches/bug44383.txt (I noticed a couple of problems with the schema tests, 089 and 091 - it seemed that the test originally expected the timezone offsets to be applied in the wrong direction - I could do with a second opinion on this.) Yes, I think I remember something in that direction. Some timezone offsets behaved weird; back then I think I concluded that the tests must have been wrong as a bug related to that in ext/date was unlikely. Could you list the tested values with expected and actual results? It's only a few IIRC, and it'd make it easier to discuss. Sure, there were only two, as I recall. I'll dig them out and mail back. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug 44383 in ext/soap
Currently, DateTime objects aren't properly mapped to and from xsd:datetime objects when sending them via ext/soap. David Zülke wrote a patch to fix this, and filed it under bug 44383, and mailed the list with it - http://article.gmane.org/gmane.comp.php.devel/57369 - but it seems not to have been applied. I tried it earlier on current trunk and noticed it had a couple of problems compiling on a ZTS PHP, which led me to my anti-TSRMLS_FETCH() rampage earlier on today. I've now updated the patch and applied it to my trunk, and it appears to work and pass the tests - does anyone have a problem with me applying it to trunk? The updated version of David's patch is available here: http://mgdm.net/~michael/patches/bug44383.txt (I noticed a couple of problems with the schema tests, 089 and 091 - it seemed that the test originally expected the timezone offsets to be applied in the wrong direction - I could do with a second opinion on this.) -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Support for Tokyo Cabinet in ext/dba
Hi, I'm intending on doing some things to ext/dba as I've noticed there's a few user notes about insert and update not working properly in some cases, but as a starter, I have a patch to add the basics of Tokyo Cabinet[1] support to ext/dba. It lets you use TC's abstract DB API, so it can open more or less anything TC can create. Anyone object to me committing this to trunk? Patch is at http://mgdm.net/~michael/patches/dba-tokyocabinet-adb.txt. [1] http://1978th.net/tokyocabinet/ -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] FNV-1 support for ext/hash
Hi, A while back I wrote a patch for ext/hash to add support for the 32- and 64-bit variants of the FNV-1 hash algorithm. Since we now have a new trunk, I thought I'd clean it up a bit, and thanks to some suggestions from Pierre and Johannes on IRC it's a bit better now. Would anyone object to applying this to trunk (and could someone do it for me, as I have no karma for that)? Description of the algorithm: http://www.isthe.com/chongo/tech/comp/fnv/index.html http://en.wikipedia.org/wiki/Fowler-Noll-Vo_hash_function The patch: http://mgdm.net/~michael/patches/php-fnv.txt -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] FNV-1 support for ext/hash
sean finney wrote: On Tue, Mar 23, 2010 at 10:01:20PM +, Michael Maclean wrote: The patch: http://mgdm.net/~michael/patches/php-fnv.txt just to throw something out there, shouldn't the various inputLen parameters be of type size_t instead of unsigned int? The function signature in php_hash.g says unsigned int, so that's what I used (though I note some of the other algorithms appear not to). We don't support files 2^32 on 64-bit, so as I understand it, it's not going to cause issues right now, but if a large file support patch lands it's something that I might revisit. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] FNV-1 support for ext/hash
Michael Maclean wrote: The function signature in php_hash.g says unsigned int, so that's what I used (though I note some of the other algorithms appear not to). We don't support files 2^32 on 64-bit, so as I understand it, it's not going to cause issues right now, but if a large file support patch lands it's something that I might revisit. And of course, when I say file here, I mean string. Ahem. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Commits to PHP_5_3
Antony Dovgal wrote: Here I'm talking about adding support for tokyo cabinets as a dba handler, not a complete interface to the multiple tokyo cabinet APIs. Are you sure you want to add it to ext/dba? dba is .. well.. dead, and it sound like a complete waste of time. There is an item on the wishlist for PHP 6.0 about refactoring ext/dba to use PDO-style drivers. I intend to investigate this, unless someone else wants to. In addition, I wrote a patch for Tokyo Cabinet support for ext/dba a while back, which Scott applied to PHP6 - I was rather hoping it'd end up in 5.3.x at some point, but he's been too busy. I'll dig out the patch if anyone here wants it, I haven't karma to apply it. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli PHPTs call my_mysqli_connect() which does not exist
Jess Portnoy wrote: In the 5_3 branch and also in 5.3.1, some MySQLi PHPTs call my_mysqli_connect() which is not defined. Is this a mistakingly committed change? Seems like they should call mysqli_connect(). It's defined in connect.inc as a wrapper. See http://php-og.mgdm.net/opengrok/xref/PHP_5_3/ext/mysqli/tests/connect.inc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)
Pierre Joye wrote: First suggestion, would it be possible to have *.c/h first in the results instead of the phpt? I'm not sure, but I'll have a look. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)
Philip Olson wrote: Looks great, and much nicer. If you feel pb11[1] could handle it, then we could dedicate this box to OpenGrok (as grok.php.net?). it'd be worth a shot, I think. Though could we get the OS on there upgraded to something a little newer? I'm not sure if Java 1.6 will run on that version of FreeBSD? Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test OpenGrok installation (LXR replacement?)
Hi, Since LXR hasn't been updating since the shift to SVN, I've been investigating bringing it back. Today, though, I came across OpenGrok which appears to be a far more modern implementation of the same thing, using Lucene as the back end. I've set up a test installation of it at http://php-og.mgdm.net if anyone is interested in playing with it. Advantages seem to be: * It's really quite fast * It has a nicer UI, in my opinion * It's not too hard to set up * It handles multiple branches *relatively* well * It does incremental indexing, which I don't think LXR does It has the potential disadvantage that it requires Tomcat, which means running another web server somewhere, but I'm quite willing to volunteer to look after it if we can find a php.net machine to put it on at some point. For now, the test install is updating each branch from SVN and reindexing once every two hours. Any comments? Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hi, Jess Portnoy wrote: clang is indeed a great tool but since it does a lot more than just static analysis. Yeah, it looked like an interesting thing and so I decided to play with it. Incidentally, I discovered later that clang appears to compile PHP 5.3 pretty much flawlessly just now (at least for my particular set of configure options). The scan-build analyser thing I used ran the code through clang before forwarding it on to gcc for the actual compilation. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. I'll have a look. Thanks for the tip. I ran it against the PHP 5.2.11 sources and am now sorting through results, patching suggestions may follow :) Heh. If anyone wants to see the output from scan-build that I got, it's at http://mgdm.net/~michael/php-5.3-clang/ along with the notes.txt that I'm filling in as I go along. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Jess Portnoy wrote: The thing I like a lot about clang is that it can be used as a drop-in substitute for GCC so you can actual call clang or clang++ instead of executing gcc/g++, see here: Sure, that's how I compiled PHP with it. CC=clang ./configure --enable-all --my-usual=stuff make make test :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hi,
Gwynne pointed me at the clang static analyser earlier on today, and so
I've run it against current PHP_5_3. In the course of messing with it,
it noticed a potential null dereference in ext/ftp - I've attached a
one-liner to fix it.
Michael
Index: ext/ftp/ftp.c
===
--- ext/ftp/ftp.c (revision 291261)
+++ ext/ftp/ftp.c (working copy)
@@ -1699,7 +1699,7 @@
chararg[11];
if (ftp == NULL) {
- goto bail;
+ return PHP_FTP_FAILED;
}
if (!ftp_type(ftp, type)) {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: FNV-1 support for ext/hash
Michael Maclean wrote: Hi, Earlier on someone on IRC mentioned that ext/hash had no support for the FNV-1 hash function (http://en.wikipedia.org/wiki/Fowler-Noll-Vo_hash_function), so I decided to have a go at adding it. I've since updated the patch with some tests based on the ones in the original code: http://mgdm.net/~michael/patches/php-fnv.txt -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch: FNV-1 support for ext/hash
Hi,
Earlier on someone on IRC mentioned that ext/hash had no support for the
FNV-1 hash function
(http://en.wikipedia.org/wiki/Fowler-Noll-Vo_hash_function), so I
decided to have a go at adding it. The result of this is the attached
patch. Currently it only supports 32-bit and 64-bit versions. I've
written it against PHP 5.3 SVN, I presume it'll apply to HEAD but I
haven't checked yet. Any comments?
Cheers,
Michael
diff -x run-tests.php -x 'Make*' -x ltmain.sh -x '*.svn*' -x '*config*' -x
'*.m4' -x '*auto*' -x 'build*' -N -u -r php-src-5.3/ext/hash/hash.c hash/hash.c
--- php-src-5.3/ext/hash/hash.c 2009-09-04 14:22:19.0 +0100
+++ hash/hash.c 2009-09-04 11:59:53.0 +0100
@@ -74,7 +74,11 @@
{RIPEMD320, ripemd320, 25},
{NULL, NULL, 26}, /* support needs to be added for snefru 128 */
{SNEFRU256, snefru256, 27},
- {MD2, md2, 28}
+ {MD2, md2, 28},
+ {FNV132, fnv132, 29},
+ {FNV1a32, fnv1a32, 30},
+ {FNV164, fnv164, 31},
+ {FNV1a64, fnv1a64, 32},
};
#endif
@@ -841,6 +845,8 @@
php_hash_register_algo(crc32b,php_hash_crc32b_ops);
php_hash_register_algo(salsa10, php_hash_salsa10_ops);
php_hash_register_algo(salsa20, php_hash_salsa20_ops);
+ php_hash_register_algo(fnv132,php_hash_fnv132_ops);
+ php_hash_register_algo(fnv164,php_hash_fnv164_ops);
PHP_HASH_HAVAL_REGISTER(3,128);
PHP_HASH_HAVAL_REGISTER(3,160);
diff -x run-tests.php -x 'Make*' -x ltmain.sh -x '*.svn*' -x '*config*' -x
'*.m4' -x '*auto*' -x 'build*' -N -u -r php-src-5.3/ext/hash/hash_fnv.c
hash/hash_fnv.c
--- php-src-5.3/ext/hash/hash_fnv.c 1970-01-01 01:00:00.0 +0100
+++ hash/hash_fnv.c 2009-09-04 15:14:33.0 +0100
@@ -0,0 +1,221 @@
+/*
+ +--+
+ | PHP Version 5|
+ +--+
+ | Copyright (c) 1997-2009 The PHP Group|
+ +--+
+ | This source file is subject to version 3.01 of the PHP license, |
+ | that is bundled with this package in the file LICENSE, and is|
+ | available through the world-wide-web at the following url: |
+ | http://www.php.net/license/3_01.txt |
+ | If you did not receive a copy of the PHP license and are unable to |
+ | obtain it through the world-wide-web, please send a note to |
+ | lice...@php.net so we can mail you a copy immediately. |
+ +--+
+ | Authors: Michael Wallner m...@php.net |
+ | Sara Golemon poll...@php.net |
+ | Michael Maclean m...@php.net |
+ +--+
+*/
+
+/* $Id: hash_salsa.c 272370 2008-12-31 11:15:49Z sebastian $ */
+
+#include php_hash.h
+#include php_hash_fnv.h
+
+const php_hash_ops php_hash_fnv132_ops = {
+ (php_hash_init_func_t) PHP_FNV132Init,
+ (php_hash_update_func_t) PHP_FNV132Update,
+ (php_hash_final_func_t) PHP_FNV132Final,
+ (php_hash_copy_func_t) php_hash_copy,
+ 4,
+ 4,
+ sizeof(PHP_FNV132_CTX)
+};
+
+const php_hash_ops php_hash_fnv1a32_ops = {
+ (php_hash_init_func_t) PHP_FNV132Init,
+ (php_hash_update_func_t) PHP_FNV1a32Update,
+ (php_hash_final_func_t) PHP_FNV132Final,
+ (php_hash_copy_func_t) php_hash_copy,
+ 4,
+ 4,
+ sizeof(PHP_FNV132_CTX)
+};
+
+const php_hash_ops php_hash_fnv164_ops = {
+ (php_hash_init_func_t) PHP_FNV164Init,
+ (php_hash_update_func_t) PHP_FNV164Update,
+ (php_hash_final_func_t) PHP_FNV164Final,
+ (php_hash_copy_func_t) php_hash_copy,
+ 8,
+ 4,
+ sizeof(PHP_FNV164_CTX)
+};
+
+const php_hash_ops php_hash_fnv1a64_ops = {
+ (php_hash_init_func_t) PHP_FNV164Init,
+ (php_hash_update_func_t) PHP_FNV1a64Update,
+ (php_hash_final_func_t) PHP_FNV164Final,
+ (php_hash_copy_func_t) php_hash_copy,
+ 8,
+ 4,
+ sizeof(PHP_FNV164_CTX)
+};
+
+/* {{{ PHP_FNV132Init
+ * 32-bit FNV-1 hash initialisation
+ */
+PHP_HASH_API void PHP_FNV132Init(PHP_FNV132_CTX *context)
+{
+context-state = PHP_FNV1_32_INIT;
+}
+/* }}} */
+
+PHP_HASH_API void PHP_FNV132Update(PHP_FNV132_CTX *context, const unsigned
char *input,
+unsigned int inputLen)
+{
+context-state = fnv_32_buf((void *)input, inputLen, context-state, 0);
+}
+
+PHP_HASH_API void PHP_FNV1a32Update(PHP_FNV132_CTX *context, const unsigned
char *input,
+unsigned int inputLen)
+{
+context-state
Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky 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 tally of the votes and based on the result we can determine how to proceed further. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Borked tests
Kalle Sommer Nielsen wrote: If you have a list and/or diff's of those tests that fails then let me know and I'll fix them. I have a pair of patches at http://mgdm.net/~michael/deprecation-Zend.patch.txt and http://mgdm.net/~michael/deprecation-php.patch.txt which fix the issues for me (on Ubuntu Hardy). Zoe however reports failures on Ubuntu Intrepid after applying the patches. Could some other folk give it a go? Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
