http://bugs.php.net/search.php?cmd=display&status=Open&bug_type%5B%5D=PDO+related
http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name%5B%5D=PDO&package_name%5B%5D=PDO_FIREBIRD&package_name%5B%5D=PDO_MYSQL&package_name%5B%5D=PDO_OCI&package_name%5B%5D=PDO_ODBC&package_name%5B%5D
This one time, at band camp, Peter Brodersen <[EMAIL PROTECTED]> wrote:
> >$arr = array('jpg', 'gif', 'tif', 'pdf', 'bmp', 'raw');
> >foreach(glob($arr as $file)){ echo $file; }
>
> glob is currently extremely flexible in its input with the right flags
> and can expand a list. Eg:
>
> print_r(gl
On 8/30/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> in 15 you see that all parameters are bork!
If that is true, then 10, 15, and 24 (all call_user_function_ex) are
borked. 24 would be the earliest. Maybe something is being cleaned up
at the start of shutdown but before the user shutdown funct
This was with:
/usr/bin/valgrind --tool=memcheck --leak-check=yes -v --trace-children=yes
And it didn't seem to add anything while the errorlog was being written.
# more log.pid17870
==17870== Memcheck, a memory error detector for x86-linux.
==17870== Copyright (C) 2002-2004, and GNU GPL'd, by
Yea, I noticed that too...
#!/bin/bash
export PHPRC
export PHP_FCGI_CHILDREN
exec /usr/bin/valgrind --tool=memcheck --trace-children=yes \
--log-file=/usr/local/apache2/fastcgi-bin/log
/usr/local/apache2/fastcgi-bin/php505.fcgi $@
This one works. :)
However... it didn't seem to find much.
--
PH
On Tue, 30 Aug 2005 23:54:53 +1000, in php.internals [EMAIL PROTECTED]
(Kevin Waterson) wrote:
>I would like to make this
>
>array glob ( array patterns [, int flags] )
>
>This would tidy up much code where a series of OR's are used to match
>different patterns.
>
>$arr = array('jpg', 'gif', 'tif'
Rasmus Lerdorf wrote:
> -Bug #31142 test #2 (imap_mail_compose() generates incorrect output)
> [ext/imap/tests/bug31142_2.phpt]
This bug was just fixed.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello steve,
Tuesday, August 30, 2005, 11:32:33 PM, you wrote:
> :)
> Can valgrind attach to a process like gdb? I somehow doubt it... In
> that case, I must admit, I've never used valgrind before. How can I
> set up valgrind to check a fast-cgi process?
> I tried changing the php5.fcgi file to
:)
Can valgrind attach to a process like gdb? I somehow doubt it... In
that case, I must admit, I've never used valgrind before. How can I
set up valgrind to check a fast-cgi process?
I tried changing the php5.fcgi file to php505.fcgi and created this as
php5.fcgi:
#/bin/bash
/usr/bin/valgrind -
Hello Andrei,
Tuesday, August 30, 2005, 10:16:43 PM, you wrote:
> On Aug 30, 2005, at 10:30 AM, Rasmus Lerdorf wrote:
>> Also, I see the following 6 failed test cases on my Linux box:
>>
>> -Bug #16069 [ext/iconv/tests/bug16069.phpt]
> According to the last two comments in that bug report, glibc
On Tue, 30 Aug 2005, Rasmus Lerdorf wrote:
> Would probably help if I included the diffs:
>
> > -Bug #33414 [2] (Comprehensive list of incorrect days returned after
> > strotime() / date() tests) [ext/date/tests/bug33414-2.phpt]
>
> 033+ result=Wednesday 1970-01-07 00:00:00 PST 0
> 033- result=W
On Aug 30, 2005, at 10:30 AM, Rasmus Lerdorf wrote:
Also, I see the following 6 failed test cases on my Linux box:
-Bug #16069 [ext/iconv/tests/bug16069.phpt]
According to the last two comments in that bug report, glibc iconv()
does not support CP932 and this test should be skipped instead of
Hello steve,
#15 0x081ccec4 in call_user_function_ex (function_table=0x1,
object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1,
params=0x1, no_separation=1, symbol_table=0x1)
at
/root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:559
#16 0x081e53eb
Thats what I was looking for, thanks. I used that and no exception was
thrown in 5.0.4, but there is one in 5.0.5RC2. It is in a shutdown
function, which is why I couldn't figure out where it was happening.
Not to mention, it was in an AJAX call. The shutdown function is
defined in JPSpan (http://s
To maintain the documentation for the PEAR package ScriptReorganizer I'm the
maintainer (lead developer) of, see
http://pear.php.net/package/ScriptReorganizer/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Okay so if we're going RC2, then I think we can also MFH instanceof
(which is a tiny patch).
Andi
At 11:51 AM 8/30/2005, Zeev Suraski wrote:
I think the patch is fine. We should probably have RC2 for PHP 5.1
anyway, so I don't see a problem putting it into the 5.1 tree (it
does fix a bug and
I think the patch is fine. We should probably have RC2 for PHP 5.1 anyway,
so I don't see a problem putting it into the 5.1 tree (it does fix a bug
and it does break binary compatibility).
Zeev
At 16:37 30/08/2005, Dmitry Stogov wrote:
OK. Let me know if you will find any problems with patch
Hello Dmitry, Andi, Zeev,
i'd love to see this in 5.1. so that i could drop all defines in SPL
and make them class constants, thus cleaning up global namespace a bit.
best regards
marcus
Tuesday, August 30, 2005, 3:37:34 PM, you wrote:
> OK. Let me know if you will find any problems with pa
At 11:58 PM 8/29/2005, Michael Wallner wrote:
Additionally I didn't see the instanceof change comitted to 5.1 as Andi
suggested, so is this gonna happen?
That was commited. Did you check HEAD?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
Would probably help if I included the diffs:
> -Bug #33414 [2] (Comprehensive list of incorrect days returned after
> strotime() / date() tests) [ext/date/tests/bug33414-2.phpt]
033+ result=Wednesday 1970-01-07 00:00:00 PST 0
033- result=Wednesday 1970-01-06 00:00:00 PST 0
> -Bug #16069 [ext/ico
Wez Furlong wrote:
> There's a bunch of open PDO bugs that need to be fixed before we go
> with 5.1 final.
Do you have some sort of plan/timeline for these getting fixed? Do you
need some help? We can't wait indefinitely on PDO. If you have a list
of outstanding issues I can throw some resource
Hi,
> -Original Message-
> From: Michael Wallner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 7:34 PM
> To: internals@lists.php.net
> Cc: Dmitry Stogov
> Subject: Re: [PHP-DEV] Re: Constants and static methods for
> internal classes
>
>
> Hi Dmitry Stogov, you wrote:
>
>
Some people have mentioned having problems where idle PHP processes hang
around without freeing their memory (in a FastCGI or Apache module modes).
As I have found, it's not really a memory fragmentation problem.
The core of the problem is the fact, that free() doesn't return memory
to the OS i
Hi Dmitry Stogov, you wrote:
> OK. Let me know if you will find any problems with patch.
There's a typo in zend_update_class_constants():
ALLOC_HASHTABLE() refers to class_type instead of
class_type->static_members
There's also a problem which I didn't track down yet:
static_mem
This one time, at band camp, Kevin Waterson <[EMAIL PROTECTED]> wrote:
> array glob ( array patterns [, int flags] )
Should be
array glob ( mixed pattern [, int flags] )
Kevin
--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the
Currently glob takes a string such as
array glob ( string pattern [, int flags] )
I would like to make this
array glob ( array patterns [, int flags] )
This would tidy up much code where a series of OR's are used to match
different patterns.
$arr = array('jpg', 'gif', 'tif', 'pdf', 'bmp', 'raw'
There's a bunch of open PDO bugs that need to be fixed before we go
with 5.1 final.
--Wez.
On 8/29/05, Zeev Suraski <[EMAIL PROTECTED]> wrote:
> For those of you who submitted patches to 5.1 since RC1 - do you believe
> that we need another RC or can we go ahead and roll 5.1 final and run a
> san
OK. Let me know if you will find any problems with patch.
I am not sure that we will aplly this patch to 5.1.
Andi? Zeev?
zend_update_static_property_...() make sense and I'll add it.
Thanks. Dmitry.
> -Original Message-
> From: Michael Wallner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday
Hi Dmitry Stogov, you wrote:
> As I understand the whole patch is OK for you.
Yep, I still need to test it because your patch is against HEAD
and I need to port it to PHP_5_1 because my extension is not
unicode aware. My main concern is that it works (of course)
and that it's not to hard for the
Hi Michael,
As I understand the whole patch is OK for you.
This function make sense and I can add it then I'll commit the patch.
I am not sure about refcount/reference magic and I haven't time to look into
it right now.
I'll check it before committing.
Thanks. Dmitry.
> -Original Message---
I wrote:
> In case of zend_update_static_property(), because one would need
> to replicate the body of that function at each writing access?
Please note that the code I'm currently using has changed from the original
patch:
int zend_update_static_property(zend_class_entry *scope, char *name, si
Hi Dmitry Stogov, you wrote:
> Static members works with this patch (except array and constant properties)
> without any additional requirements for extension. See test extension in
> first email. Developer should just call zend_declare_property_...() or
> zend_declare_class_constant_...() in MINI
> I think we could avoid this by stretching
> the minimalistic approach a bit and provide at least a
> zend_init_static_properties().
We don't need zend_init_static_properties() at all.
The initialization performs automatic before any access to static member in
zend_update_class_constants().
Dm
Hi,
> -Original Message-
> From: Michael Wallner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 1:56 PM
> To: internals@lists.php.net; Dmitry Stogov
> Cc: internals@lists.php.net; Andi Gutmans
> Subject: [PHP-DEV] Re: Constants and static methods for
> internal classes
>
>
I wrote:
> So why burden the weigh of allocation, initialization, destruction
> and freeing on the extension developer? This will force every extension
> writer to implement a kind of my dup_zval() function, wouldn't it?
> And as there's not much reference devs will spam the list on how
> to use
Hi Dmitry Stogov, you wrote:
> The patch is maden for "easiest" usage and it doesn't support internal
> array/constants properties (they weren't supported before).
So why burden the weigh of allocation, initialization, destruction
and freeing on the extension developer? This will force every ext
> -Original Message-
> From: Michael Wallner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 12:24 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Re: Constants and static methods for
> internal classes
>
>
> Hi Dmitry Stogov, you wrote:
>
> > You can look into propo
Hi Dmitry Stogov, you wrote:
> You can look into proposal patch that implements support for constants and
> static methods for internal classes. The original patch was written by
> Michael and improved by me.
Is it my (mailers) fault or didn't the patch make it through?
Thanks,
--
Michael - <
Hi,
You can look into proposal patch that implements support for constants and
static methods for internal classes. The original patch was written by
Michael and improved by me.
The patch is maden for "easiest" usage and it doesn't support internal
array/constants properties (they weren't support
On Fri, 26 Aug 2005, John LeSueur wrote:
> Of course, if the engine is unstable, it's unstable. But if at all
> possible, I'd like to catch this particular error.
As I already said, in this case it's not possible.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Tue, 30 Aug 2005 05:06:07 +0300
[EMAIL PROTECTED] (Zeev Suraski) wrote:
> For those of you who submitted patches to 5.1 since RC1 - do you
> believe that we need another RC or can we go ahead and roll 5.1
> final and run a sanity test for 24 hours? I went over the
> patches, none of them appea
Hi Zeev Suraski, you wrote:
> For those of you who submitted patches to 5.1 since RC1 - do you believe
> that we need another RC or can we go ahead and roll 5.1 final and run a
> sanity test for 24 hours? I went over the patches, none of them appears
> to be too dangerous, but if any of you think
42 matches
Mail list logo