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
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:
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
|
+ | 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
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
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
33 matches
Mail list logo
