PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (647 total including feature requests)
===[Arrays related]===
31114 Assigned foreach modify array
34269 Open memory overwrite
==
I'm requesting a CVS account because I'm going to take part in the Catalan
translation project of the PHP documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PHP 5 Bug Database summary - http://bugs.php.net
Num Status Summary (383 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
34283 Feedback date("U") is not
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
GNU ld version 2.15.92.0.2 20040927
Error details follow:
ext/pdo_sqlite/sqlite/src/prepare.o(.text+0x647): In function
`sqlite3InitOne':
/home/rolland/Work/PHP-unicode/source/php-src/ext/pdo_sqlite/sqlite/src/prepare.c:299:
undefined reference to `sql
Ilia updated the bundled sqlite; I think you probably need to re-run
buildconf and then configure.
--Wez.
On 8/29/05, Rolland Santimano <[EMAIL PROTECTED]> wrote:
> gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
> GNU ld version 2.15.92.0.2 20040927
>
> Error details follow:
>
> ext/pdo_sqlite/sq
> On Sun, 2005-08-28 at 16:23 +0200, Steph wrote:
> > 'Replace'? Code written for ext/xmlrpc won't work with ext/xmlrpci.
Will
> > ext/xmlrpc be available in PECL, given that it doesn't appear to have an
> > active maintainer?
>
> Sure it'll be in PECL, just like dio, crack, yaz, and the other hal
What's the status with 5.1 release? Somehow I've got
the feeling that nobody's doing anything about it after
the unicode merge..? (nobody == Dmitry :)
And who is the RM for PHP_5_1 branch anyway?
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Mon, 2005-08-29 at 13:23 +0200, Steph wrote:
> It's the 'given that it doesn't appear to have an active maintainer' part
> that's important here. It takes a little TLC to make a PECL package
> available for download.
I'll roll the PECL package myself.
> > > I'm well aware of ext/xmlrpc's limi
On Mon, 29 Aug 2005 07:58:33 -0400
[EMAIL PROTECTED] (John Coggeshall) wrote:
> On Mon, 2005-08-29 at 13:23 +0200, Steph wrote:
> > It's the 'given that it doesn't appear to have an active
> > maintainer' part that's important here. It takes a little TLC
> > to make a PECL package available for d
> > That's fair enough, so long as the older version is readily available.
It
> > becomes a problem if it isn't. The word 'replace' kind of intimates
that
> > the original extension is effectively a goner - and if you meant
'replace in
> > the core', I'm unaware of a precedent for that.
>
> Yes.
On Mon, 2005-08-29 at 14:43 +0200, Steph wrote:
> >
> > Yes.
>
> Yes what? :)
'replace in core'
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(resending- I got the list address wrong.)
OK, here is how I think about these things.
I would try to keep the intent of the function in mind, not just the literal
definition, when extending them from the 1 byte/character model to the
Unicode UTF-8 m bytes/n characters/grapheme model.
The literal
Learning
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I don't see the reason for doing this except making life of people who
download the PECL package more difficult. I belive this should be reverted.
Edin
Jani Taskinen wrote:
> sniperMon Aug 29 10:46:01 2005 EDT
>
> Modified files:
> /php-src php.ini-dist php.i
and/or provide a mechanism for merging an ini fragment from a pecl
package into the php.ini file.
--Wez.
On 8/29/05, Edin Kadibasic <[EMAIL PROTECTED]> wrote:
> I don't see the reason for doing this except making life of people who
> download the PECL package more difficult. I belive this should
Hello Wez,
if we make dba/inifile a defaul component then a script to do the merge
would be pretty easy or in other words could easily become part of the
pecl/pear install/upgrade stuff.
regards
marcus
Monday, August 29, 2005, 6:00:04 PM, you wrote:
> and/or provide a mechanism for merging an
Hi,
I am searching for some evidence in the PHP source code that the
possibility of omitting the closing PHP tag is absolutely intentional,
and in fact part of the language syntax, and therefore it is going to be
supported indefinitely. Digging for T_CLOSE_TAG and similar stuff have
lead me to not
On Aug 29, 2005, at 2:38 PM, Gabor Hojtsy wrote:
Hi,
I am searching for some evidence in the PHP source code that the
possibility of omitting the closing PHP tag is absolutely intentional,
and in fact part of the language syntax, and therefore it is going
to be
supported indefinitely. Diggi
George Schlossnagle wrote:
>>
>> Also if you have any positive notes on not using the closing tag (or any
>> negative thereof :), please do let me know.
>
> Benefit: No unintentional leakage of whitespace (following a closing ? >).
Well, the intention of the basic syntax manual page is to point
I'm working on an Image_Color2 package. In an email on pear-dev Arnaud
Limbourg, told me to apply for a CVS account
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> I am searching for some evidence in the PHP source code that the
> possibility of omitting the closing PHP tag is absolutely intentional,
> and in fact part of the language syntax, and therefore it is going to be
> supported indefinitely. Digging for T_CLOSE_TAG and similar stuff have
> lead me t
Does this mean that if the padding string is base character + two
combining characters, we can trim just one of the combining ones or do
we trim all the way back to the base one?
-Andrei
On Aug 29, 2005, at 5:50 AM, Tex Texin wrote:
4) The string can be truncated to the user's requested char
One at a time.
Fundamentally, I am speculating that combining charaacters will not appear
in pad characters with any frequency, and therefore we shouldn't worry about
the distinction of combining and non-combining, in this SPECIAL instance.
Anyone that has that need, can write a specific function
I get this error in the error log, on every page view in this release:
PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
It seems to happen after the page is complete, since from the webpage
it renders fine. I found a bug reference about throwing exceptions in
__destr
Hello steve,
for a c backtrace set a breakpoint on function zend_throw_exception_internal.
regards
marcus
Monday, August 29, 2005, 11:24:16 PM, you wrote:
> I get this error in the error log, on every page view in this release:
> PHP Fatal error: Exception thrown without a stack frame in Unk
In looking into a series of leaks regarding tsrm interpreter contexts with
George and Wez, we came across a problem with how EG(zend_constants) is
created and destroyed.
Specifically it's only destroyed once, from zend_shutdown(). However it's
created by executor_globals_ctor(). In non-ZTS this
Services_DynDNS
Martin Jansen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
At 01:13 30/08/2005, Sara Golemon wrote:
In looking into a series of leaks regarding tsrm interpreter contexts with
George and Wez, we came across a problem with how EG(zend_constants) is
created and destroyed.
Specifically it's only destroyed once, from zend_shutdown(). However it's
created by
As far as I can tell it's a bug. By the way, we're not talking about a
leak that happens too often - unless you're spawning and killing threads
very often (in which case TSRM is very inefficient regardless of
anything). The leak would happen per-terminated thread.
Good call. The backstory i
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 thinks differently, let me know.
Zeev
At 04:03 30/08/2005, Sara Golemon wrote:
Are you sure it's not leaking the global constants table with the
zend_shutdown_constants() removed from zend_shutdown()?
valgrind says no. To be honest I havn't gone looking to see where the
global table is cleaned up...Just got back home...
If valgri
@@ -706,7 +707,6 @@
zend_shutdown_extensions(TSRMLS_C);
free(zend_version_info);
- zend_shutdown_constants(TSRMLS_C);
free(GLOBAL_FUNCTION_TABLE);
free(GLOBAL_CLASS_TABLE);
#ifdef ZTS
Are you sure it's not leaking the global constants table with the
zend_
It is quite intentional and will stick around forever :)
Andi
At 01:14 PM 8/29/2005, Sara Golemon wrote:
> I am searching for some evidence in the PHP source code that the
> possibility of omitting the closing PHP tag is absolutely intentional,
> and in fact part of the language syntax, and the
Hi Johannes,
I think this patch is useful and I see no reason not to include it.
Due to API breakage I suggest we only put this into HEAD.
Andi
At 05:34 AM 8/27/2005, Johannes Schlueter wrote:
Hi Andi et al.,
the attached patch adds the module registering an internal function to the
zend_in
34 matches
Mail list logo
