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
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
@@ -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_
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
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
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
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
Services_DynDNS
Martin Jansen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
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
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
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
> 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
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
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
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
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
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
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
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
Learning
--
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
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
> > 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, 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
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
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 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
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
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
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
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 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
==
34 matches
Mail list logo
