[PHP-DEV] Re: [PEAR-DEV] pear package broken
pear package in the XML_Transformer directory creates a broken tgz archive. The archive seems to have right filesize, but when I try to tar xvfz it, I only get a package.xml file from it. Could this be related to current streams issues? It should not. I get the following error when trying to build it. pear package package.xml XML error: no element found at line 275 Arnaud. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] pear package broken
Arnaud Limbourg wrote: pear package package.xml XML error: no element found at line 275 Same here. But the XML is valid, AFAICS. Maybe the XML parser reads incorrect due to streams? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] output buffering
I requested that Yasuo reverts his patches, repeatedly, but as he hasn't, I was forced to do it manually myself. If I screwed up while reverting the patches myself, I apologize. I'll take a look. Zeev At 08:30 07/10/2002, Derick Rethans wrote: On Sun, 6 Oct 2002, Rasmus Lerdorf wrote: I thought those changes were reverted? Not all as it seems... Christian Stocker also reported some problems IIRC. Derick On Mon, 7 Oct 2002, Sascha Schumann wrote: Hi, the recent changes in the output buf layer are causing PHP to buffer data too aggressively. The test case outputs two lines of HTML a few times and expects these lines to be immediately forwarded to the url scanner. Regardless of the output_buffering/implicit_flush ini settings, the HTML is buffered and does not get to the scanner until the script finishes. During the script, we change the behaviour of the URL scanner by modifying the tags its matching on. Only the last INI setting is applied to the HTML output. Sprinkling the code with flush()es and enabling implicit_flush does not help. http://lxr.php.net/source/php4/ext/session/tests/021.phpt - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scratching the 4.3 branch
I differ with you regarding whether we can or cannot tell people to pause development for a few weeks. Regardless, if we want to allow people to develop, I suggested using development branches (or branch), instead of using a release branch, for most of the duration of this release cycle. Given the fact that bug fixing is going to be much more popular than adding new features, it's the logical thing to do, IMHO. Zeev At 19:18 06/10/2002, Rasmus Lerdorf wrote: I don't think we can just not provide some place for people to work on new code. We have way too many extensions in various states of development to just arbitrarily tell everyone to stop what they are doing. The ext/xslt work going on right now is a good example along with the image rotation functions for GD that are waiting in the wings. Whether the 4.3 branch was created too early or not is debatable, but a date was set to give people a kick in the ass and in that respect it worked pretty well. A lot of problems were fixed, or at least looked at in the last week. The answer may be to re-branch when we are ready for RC1. When the implicit_flush mess is resolved and Melvyn gives the thumbs up for the Sablotron stuff then I think we are ready for RC1. -Rasmus On Sun, 6 Oct 2002, Zeev Suraski wrote: I think we'd be better off waiting a bit with the php5 move. In general I just don't think we can push a successful release while we continue developing. If we concentrate on getting 4.3 out the door within a month, we can then concentrate on php5. Zeev At 13:33 06/10/2002, Derick Rethans wrote: On Sun, 6 Oct 2002, Sander Roobol wrote: On Sun, Oct 06, 2002 at 11:01:02AM +0200, Derick Rethans wrote: On Sun, 6 Oct 2002, Zeev Suraski wrote: I think that given the circumstances, we should scratch the 4.3 branch and stick to the main branch for this particular release, at least until we're very close to the release itself. The vast majority of CVS traffic going on these days is bug fixes anyway, so creating the branch only makes it more difficult to keep up - you have to keep the two branches in sync. Issuing a request for people not to develop new features for a couple of months (or telling them to develop in some -dev branch), will, in my opinion, work better than our conventional release process. I'm very worried about sync problems with 4.3. Maybe it's time to opening up the php5 module then... people would be able to work on experimental stuff there without messing up the stable module. It might be a psychological thing but I think it's appropriate here. +1 on removing the branch - to avoid problems with staying in sync with head -1 on the php5 module - it'll move the sync problems to another place I think it does solve things. When there is the php5 module for 'happy hacking', but without touching that's great for new functions, rewritten extensions etc.. while you can fix bugs on the stable, supported, php4 module. Synching when we start actively on php4 would be only needed for not-modified extensions in the php5 module. And perhaps once a month for the PHP core. THis will be much more maintainable than the little merges evry hour. regards, Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
It's been a while since I touched that piece of code, so I don't remember how exactly it's supposed to work. However, right now, the URL rewriting code uses output buffering, so it's not too odd that the output is being buffered. Back when I made this change, I used a 4096-byte chunk size (and that's how it works in 4.2), but right now, miraculously, it appears to be using an unlimited buffer size for some reason. Yasuo? A couple of questions for clarity: (a) Does this work properly with PHP 4.2? (b) Other than the buffering issue, does it perform what it's supposed to do (i.e., yields the right output)? Zeev At 06:02 07/10/2002, Sascha Schumann wrote: Hi, the recent changes in the output buf layer are causing PHP to buffer data too aggressively. The test case outputs two lines of HTML a few times and expects these lines to be immediately forwarded to the url scanner. Regardless of the output_buffering/implicit_flush ini settings, the HTML is buffered and does not get to the scanner until the script finishes. During the script, we change the behaviour of the URL scanner by modifying the tags its matching on. Only the last INI setting is applied to the HTML output. Sprinkling the code with flush()es and enabling implicit_flush does not help. http://lxr.php.net/source/php4/ext/session/tests/021.phpt - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
Zeev Suraski wrote: It's been a while since I touched that piece of code, so I don't remember how exactly it's supposed to work. However, right now, the URL rewriting code uses output buffering, so it's not too odd that the output is being buffered. Back when I made this change, I used a 4096-byte chunk size (and that's how it works in 4.2), but right now, miraculously, it appears to be using an unlimited buffer size for some reason. Yasuo? A couple of questions for clarity: (a) Does this work properly with PHP 4.2? (b) Other than the buffering issue, does it perform what it's supposed to do (i.e., yields the right output)? Zeev, As I said before, I don't touch any of chunk size related code. You've removed all applicable lines regarding to implicit flush thing. Anyway, using unlimited size of buffer makes sense to me. Unless it buffers whole contents, URL rewriter may fail to modify HTML correctly. I don't read code, so I cannot make comment on this. But, I guess it is working as before w/o adding output control functions. BTW, don't forget adding my address. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
Anyway, using unlimited size of buffer makes sense to me. Unless it buffers whole contents, URL rewriter may fail to modify HTML correctly. I don't read code, so I cannot make comment on this. Right, you did not read the URL rewriter code and so you should not comment on it. The URL rewriter has been written to support handling of data chunks, and thus your above statement [the] URL rewriter may fail to modify HTML correctly is simply false. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
At 10:55 07/10/2002, Yasuo Ohgaki wrote: As I said before, I don't touch any of chunk size related code. You've removed all applicable lines regarding to implicit flush thing. No implicit flush please. Enough. It's over. Seriously, please, it's really getting on my nerves already :) [*] Anyway, using unlimited size of buffer makes sense to me. Unless it buffers whole contents, URL rewriter may fail to modify HTML correctly. I don't read code, so I cannot make comment on this. But, I guess it is working as before w/o adding output control functions. Well, you should have at least assumed that considering it's been working with chunked buffering for months and months, maybe, just possibly, it's supposed to work that way. The least you should do is ask either Sascha or me how come it uses chunked buffering, and whether it's not a bug. You would have gotten a pretty clear response saying that it fully supports chunked buffering. Zeev [*] The reason I'm edgy is that on top of the public discussion about implicit flush, there was also a fairly long email exchange between Yasuo and me regarding that subject... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
Sascha Schumann wrote: The URL rewriter has been written to support handling of data chunks, and thus your above statement [the] URL rewriter may fail to modify HTML correctly is simply false. Just looked at the handler, the handler is storing intermediate result to global as it's supposed ;) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] is_executable (was: RE: DBX tests failing)
Hello, why is this function commented out for Windows? Shouldn't it just always return TRUE on WIndows? Derick -- Forwarded message -- Date: Mon, 7 Oct 2002 11:17:08 +0200 From: Marc Boeren [EMAIL PROTECTED] To: 'Derick Rethans' [EMAIL PROTECTED] Subject: RE: DBX tests failing Hi, While we're on the subject: run-tests.php will not work on Windows: PHP Fatal error: Call to undefined function: is_executable() in D:\home\php-dev\php4\run-tests.php on line 79 and in ext/standard/php_filestat.h:39..41 #ifndef PHP_WIN32 PHP_FUNCTION(is_executable); #endif Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
A couple of questions for clarity:
(a) Does this work properly with PHP 4.2?
There is an even weirder bug, at least in the 4.2.3/CGI case
(the session output handler gets called after the request
shutdown which already disabled the session, so that the
rewriter is not invoked).
This bug can be circumvented by using ob_flush() which causes
the output buffer to be emptied immediately.
In HEAD, this yields:
if (!OG(ob_nesting_level)) {
php_error_docref(ref.outcontrol TSRMLS_CC, E_NOTICE, failed to flush
buffer. No buffer to flush.);
(b) Other than the buffering issue, does it perform what it's supposed to
do (i.e., yields the right output)?
The test case would not fail, if the output was correct. :-)
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_executable (was: RE: DBX tests failing)
On Mon, 7 Oct 2002, Tit Black Petric wrote: Hello, why is this function commented out for Windows? Shouldn't it just always return TRUE on WIndows? Derick shouldnt it only return true on *exe, com, pif, bat, ..? and i guess on directories if its used that way.. No, as for windows everything is executable... see the .scr virusses for example :) Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/ccvs
Hey, to my knowledge ccvs was dropped by RedHat and I can't seem to find a recent library to build PHP against. In conclusion, I propose the removal of ext/ccvs. If a kind soul can point me to a library, I am willing to do the necessary changes to integrate it into PECL. Comments are highly welcome. Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. Key7BCC EB86 8313 DDA9 25DF Fingerprint1805 ECA5 BCB7 BB96 56B0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
At 12:24 07/10/2002, Sascha Schumann wrote:
A couple of questions for clarity:
(a) Does this work properly with PHP 4.2?
There is an even weirder bug, at least in the 4.2.3/CGI case
(the session output handler gets called after the request
shutdown which already disabled the session, so that the
rewriter is not invoked).
This bug can be circumvented by using ob_flush() which causes
the output buffer to be emptied immediately.
In HEAD, this yields:
if (!OG(ob_nesting_level)) {
php_error_docref(ref.outcontrol TSRMLS_CC, E_NOTICE, failed to
flush buffer. No buffer to flush.);
Aha, ok, that actually makes quite a bit of sense. If there's a bit of
output that remains inside the buffers, and the session module gets
deactivated before this output is flushed, we're in trouble... I'll take a
look at it.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_executable (was: RE: DBX tests failing)
At 12:00 10/7/2002 +0200, Derick Rethans wrote: On Mon, 7 Oct 2002, Tit Black Petric wrote: Hello, why is this function commented out for Windows? Shouldn't it just always return TRUE on WIndows? Derick shouldnt it only return true on *exe, com, pif, bat, ..? and i guess on directories if its used that way.. No, as for windows everything is executable... see the .scr virusses for example :) Yes - and that's why it is a good idea, to either not implement it, or return true. For instance - in a CMS you tipically allow uploads, to a specific location. is_executable, is one of the checks you could implement, to make sure it doesn't overwrite something nasty. On windows this would either fail every file upload or - if you return false - it would allow overwriting of true executables. Of course - since NTSEC has more security layers than standard unix filepermissions, one could argue, that a good server administrator knows how to propogate per- missions in a webtree. In that case, you need to detect NTSEC. Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua Logan I spent a minute looking at my own code by accident. Logan I was thinking What the hell is this guy doing? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scratching the 4.3 branch
On Sun, Oct 06, 2002 at 10:00:57AM -0400, Dan Kalowsky wrote : Here is an option though. Release RC1. We know it's buggy, we know it's got a lot of problems, and we know that we don't know them all. The stigma that snapshots are unstable isn't going to be changed in the next few days, so lets work with that. By releasing RC1 we can have (potentially) a larger test audience working on making the RC2 better as there seems to be less of a stigma against RCs. There is no real reason why we can't go through multiple RCs this time around... other than time. So lets take advantage of that. Given that we should not forget to add something to the BTS so we can clearly identify what bug is for RC1 and which not. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Layout issues
Guys,
Please make sure you're all well familiar with CODING_STANDARDS, most
notably [2] and [3] in the syntax and indentation section.
Thanks,
Zeev
[2] Use KR-style. Of course, we can't and don't want to
force anybody to use a style he or she is not used to, but,
at the very least, when you write code that goes into the core
of PHP or one of its standard modules, please maintain the KR
style. This applies to just about everything, starting with
indentation and comment styles and up to function declaration
syntax.
(see also http://www.tuxedo.org/~esr/jargon/html/entry/indent-style.html)
[3] Be generous with whitespace and braces. Always prefer:
if (foo) {
bar;
}
to:
if(foo)bar;
Keep one empty line between the variable declaration section and
the statements in a block, as well as between logical statement
groups in a block. Maintain at least one empty line between
two functions, preferably two.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/aspell
Hey there hard working folks, aspell was replaced by pspell long ago, hence I like to remove aspell from the main source tree to either PECL or /dev/null. Any objections? Comments are highly welcome. Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. Key7BCC EB86 8313 DDA9 25DF Fingerprint1805 ECA5 BCB7 BB96 56B0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Layout issues
Hi, I have written a book about PHP, which has become some sort of de facto book for PHP-programmers i Sweden. It will probably be translated to English soon. I just started writing a new edition and have some problems. What version of PHP should the book be based on? Whould it be wise to use Apache 2? /Viktor Jonsson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit : Hey there hard working folks, aspell was replaced by pspell long ago, hence I like to remove aspell from the main source tree to either PECL or /dev/null. Any objections? Comments are highly welcome. Hi, You're right. aspell is a survival of an antiquated tradition. pspell is much better. So /dev/null sounds a great place for antiques ;-) DJ Anubis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
Zeev Suraski wrote:
The least you should do is
ask either Sascha or me how come it uses chunked buffering, and whether
it's not a bug. You would have gotten a pretty clear response saying
that it fully supports chunked buffering.
No. I don't think I need to ask.
It may be able to be called fully supports chunked buffering, but
the code is still missing some.
pseudo code
while($html = read($fp, 100)) {
print($html);
ob_flush();
}
You see?
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: is_executable (was: RE: DBX tests failing)
Nice idea. -- Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com - Hébergement de sites Internet Derick Rethans [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Hello, why is this function commented out for Windows? Shouldn't it just always return TRUE on WIndows? Derick -- Forwarded message -- Date: Mon, 7 Oct 2002 11:17:08 +0200 From: Marc Boeren [EMAIL PROTECTED] To: 'Derick Rethans' [EMAIL PROTECTED] Subject: RE: DBX tests failing Hi, While we're on the subject: run-tests.php will not work on Windows: PHP Fatal error: Call to undefined function: is_executable() in D:\home\php-dev\php4\run-tests.php on line 79 and in ext/standard/php_filestat.h:39..41 #ifndef PHP_WIN32 PHP_FUNCTION(is_executable); #endif Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Layout issues
It should be PHP4.3.0 and Apache1.3.27. -- Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com - Hébergement de sites Internet Viktor Jonsson [EMAIL PROTECTED] a écrit dans le message de news: 002801c26df7$4a092c20$[EMAIL PROTECTED] Hi, I have written a book about PHP, which has become some sort of de facto book for PHP-programmers i Sweden. It will probably be translated to English soon. I just started writing a new edition and have some problems. What version of PHP should the book be based on? Whould it be wise to use Apache 2? /Viktor Jonsson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
Agreed, but there's one problem: The pspell as you know and love it, is now named GNU Aspell 0.52. The pspell extension must be used, to build with GNU Aspell - the API has been kept as an 'alias' for this purpose. So I vote for: --with-aspell - /dev/null --with-gnu-aspell - AC_ARG_WITH alias for --with-pspell - nothing more. No seperate directory, nor renaming or aliasing of functions. At 13:51 10/7/2002 +0200, DJ Anubis wrote: Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit : Hey there hard working folks, aspell was replaced by pspell long ago, hence I like to remove aspell from the main source tree to either PECL or /dev/null. Any objections? Comments are highly welcome. Hi, You're right. aspell is a survival of an antiquated tradition. pspell is much better. So /dev/null sounds a great place for antiques ;-) DJ Anubis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua Logan I spent a minute looking at my own code by accident. Logan I was thinking What the hell is this guy doing? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
At 14:51 07/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: The least you should do is ask either Sascha or me how come it uses chunked buffering, and whether it's not a bug. You would have gotten a pretty clear response saying that it fully supports chunked buffering. No. I don't think I need to ask. Really? Yasuo, people have been requesting that we disable your write access to the full php4 tree, and uptil now I was against it. But this attitude is making me reconsider my stand on this. This is the 2nd time in the last couple of days that I notice that your unverified assumptions introduced inconsistencies/bugs/misbehaviors, and if you don't realize that it needs to be fixed, we have a bit of a problem here. Please reconsider. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Anyone confirm this?
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: Mon Oct 7, 2002 8:24:14 AM US/Eastern
To: [EMAIL PROTECTED]
Subject: #19798 [NEW]: mistype in source
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.2.3
PHP Bug Type: Unknown/Other Function
Bug description: mistype in source
php-4.2.3/ext/standard/quot_print.c
---
while ( str_in[i] )
{
switch (str_in[i])
{
case '=':
if (str_in[i+1] str_in[i+2]
isxdigit((int)str_in[i+1])
isxdigit((int)str_in[i+1]) )
{
str_out[j++] = (php_hex2int((int)str_in[i+1]) 4 )
+ php_hex2int((int)str_in[i+2]);
i += 3;
}
---
may be lines above must looking like:
---
if (str_in[i+1] str_in[i+2]
isxdigit((int)str_in[i+1])
isxdigit((int)str_in[i+2]) )
---
???
--
Edit bug report at http://bugs.php.net/?id=19798edit=1
--
Try a CVS snapshot:
http://bugs.php.net/fix.php?id=19798r=trysnapshot
Fixed in CVS:
http://bugs.php.net/fix.php?id=19798r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=19798r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=19798r=needtrace
Try newer version:
http://bugs.php.net/fix.php?id=19798r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=19798r=support
Expected behavior:
http://bugs.php.net/fix.php?id=19798r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=19798r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=19798r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=19798r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19798r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19798r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=19798r=isapi
---
Dan KalowskyI'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin.
[EMAIL PROTECTED]- Streets of Philadelphia,
[EMAIL PROTECTED]Bruce Springsteen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Layout issues
Whould it be wise to use Apache 2? Nope -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
Zeev Suraski wrote: The least you should do is ask either Sascha or me how come it uses chunked buffering, and whether it's not a bug. You would have gotten a pretty clear response saying that it fully supports chunked buffering. No. I don't think I need to ask. Sometimes you do. If you are touching other peoples' code, and especially if that code is rather critical you need to make really damn sure you know what you are doing before you change it. A quick summary of what you have in mind sent to php-dev and/or the author(s) of the code in question is all it takes. It doesn't take very long and it is common courtesy if nothing else. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3 plans
I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
Sounds good to me. At 17:09 07/10/2002, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
Ok On Mon, 7 Oct 2002, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
Good. Now, people, let's try to get the tree at least somewhat stable before Thursday. On Mon, 07 Oct 2002, Rasmus Lerdorf wrote: Ok On Mon, 7 Oct 2002, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -Andrei http://www.gravitonic.com/ Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
Agreed, it's only common courtesy. david Zeev Suraski wrote: The least you should do is ask either Sascha or me how come it uses chunked buffering, and whether it's not a bug. You would have gotten a pretty clear response saying that it fully supports chunked buffering. No. I don't think I need to ask. Sometimes you do. If you are touching other peoples' code, and especially if that code is rather critical you need to make really damn sure you know what you are doing before you change it. A quick summary of what you have in mind sent to php-dev and/or the author(s) of the code in question is all it takes. It doesn't take very long and it is common courtesy if nothing else. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
At 17:53 07/10/2002, David Reid wrote: Agreed, it's only common courtesy. At minimum. When we're dealing with the core of an application as popular as PHP, it's also an issue of responsibility. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] using run-tests.php on windows
On Mon, Oct 07, 2002 at 04:37:49AM +0200, Melvyn Sopacua wrote: Whether the function should make an effort and emit a warning for these systems is open to debate. IMO it's good that this function isn't available on Windows - it makes no sense there anyway. I'll fix run-tests.php in a moment. It does have security implications... Does it? Windows isn't secure in that way anyway... Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segafults...
FWIW, I'm still seeing the segfaults on beos for session code. I'm away until Thursday evening now, but if someone can give some ideas then I'll try to trace it further when I get back... The segafults occur in _object_and_properties_init. _object_and_properties_init _object_init_ex php_var_unserialize ps_srlzr_decode_php php_session_decode php_session_initialize ext/session/tests/003.phpt is the first test to trigger this :( david -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
Can you see if calling php_end_ob_buffers() in the session deactivate
function, in case BG(url_adapt_state_ex).active is true, solves this problems?
Zeev
At 12:24 07/10/2002, Sascha Schumann wrote:
A couple of questions for clarity:
(a) Does this work properly with PHP 4.2?
There is an even weirder bug, at least in the 4.2.3/CGI case
(the session output handler gets called after the request
shutdown which already disabled the session, so that the
rewriter is not invoked).
This bug can be circumvented by using ob_flush() which causes
the output buffer to be emptied immediately.
In HEAD, this yields:
if (!OG(ob_nesting_level)) {
php_error_docref(ref.outcontrol TSRMLS_CC, E_NOTICE, failed to
flush buffer. No buffer to flush.);
(b) Other than the buffering issue, does it perform what it's supposed to
do (i.e., yields the right output)?
The test case would not fail, if the output was correct. :-)
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the
Lance, I just noticed this post, and PWEE sounds pretty interesting. One thing that would definitly make me consider using it in a production environment would be the ability to change configuration based on the name of the vhost being accessed. For example, we've got several sites all running the same code on the same IP. I use an auto_prepended file to check the hostname being accessed, and then include() some site-specific variables to change the look and feel of the site. Take a look at: http://domains.dslreports.com/ http://bell.easydns.ca/ http://domains.canadacomputes.com/ If I could set up PWEE with something like this: ?xml version=1.0? Environments Application name=DNS_PARTNERS namespace= Server vhost=domains.dslreports.com Constants Constant name=DATABASE_HOSTNAME value=dsl / /Constants /Server Server vhost=bell.easydns.ca Constants Constant name=DATABASE_HOSTNAME value=bell / /Constants /Server ... etc ... /Application /Environments Is this possible in PWEE right now? If not, would you consider adding support for it? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone confirm this?
It appears to be a typo. See
http://cvs.php.net/diff.php/php4/ext/standard/quot_print.c?r1=1.10r2=1.11
The old code checked [i+1] and [i+2], while the new (rev. 1.11) code
checks [i+1] twice...
Sander
On Mon, Oct 07, 2002 at 09:35:53AM -0400, Dan Kalowsky wrote:
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: Mon Oct 7, 2002 8:24:14 AM US/Eastern
To: [EMAIL PROTECTED]
Subject: #19798 [NEW]: mistype in source
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.2.3
PHP Bug Type: Unknown/Other Function
Bug description: mistype in source
php-4.2.3/ext/standard/quot_print.c
---
while ( str_in[i] )
{
switch (str_in[i])
{
case '=':
if (str_in[i+1] str_in[i+2]
isxdigit((int)str_in[i+1])
isxdigit((int)str_in[i+1]) )
{
str_out[j++] = (php_hex2int((int)str_in[i+1]) 4 )
+ php_hex2int((int)str_in[i+2]);
i += 3;
}
---
may be lines above must looking like:
---
if (str_in[i+1] str_in[i+2]
isxdigit((int)str_in[i+1])
isxdigit((int)str_in[i+2]) )
---
???
--
Edit bug report at http://bugs.php.net/?id=19798edit=1
--
Try a CVS snapshot:
http://bugs.php.net/fix.php?id=19798r=trysnapshot
Fixed in CVS:
http://bugs.php.net/fix.php?id=19798r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=19798r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=19798r=needtrace
Try newer version:
http://bugs.php.net/fix.php?id=19798r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=19798r=support
Expected behavior:
http://bugs.php.net/fix.php?id=19798r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=19798r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=19798r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=19798r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19798r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19798r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=19798r=isapi
---
Dan KalowskyI'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin.
[EMAIL PROTECTED]- Streets of Philadelphia,
[EMAIL PROTECTED]Bruce Springsteen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_executable (was: RE: DBX tests failing)
On Mon, Oct 07, 2002 at 12:11:37PM +0200, Melvyn Sopacua wrote: At 12:00 10/7/2002 +0200, Derick Rethans wrote: No, as for windows everything is executable... see the .scr virusses for example :) Yes - and that's why it is a good idea, to either not implement it, or return true. For instance - in a CMS you tipically allow uploads, to a specific location. is_executable, is one of the checks you could implement, to make sure it doesn't overwrite something nasty. On windows this would either fail every file upload or - if you return false - it would allow overwriting of true executables. Of course - since NTSEC has more security layers than standard unix filepermissions, one could argue, that a good server administrator knows how to propogate permissions in a webtree. In that case, you need to detect NTSEC. Well, I'm not really sure about this anymore. There is no real way to see if a file can be executed - in command prompt for example, AFIAK only .com, .bat and .exe files are considered executable, but explorer uses some registry settings (at least, on FAT filesystems). Don't know what NTSEC exactly is, but I assume it's similar too (or maybe the same as) NTFS. That means we need some filesystem dependant code too Unless someone implements it all, I'd rather see the function missing than returning a (possibly bogus) true. Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfaults in Zend
Hi, I currently get following segfaults: httpd logs: [Mon Oct 7 17:17:45 2002] [notice] child pid 19460 exit signal Segmentation fault (11) FATAL: emalloc(): Unable to allocate 1515870812 bytes I can understand him well ;-) BT: Program received signal SIGSEGV, Segmentation fault. 0x400d1ab1 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x400d1ab1 in __kill () from /lib/libc.so.6 #1 0x4049945c in _emalloc () at /root/cvs/cvsphp/Zend/zend_alloc.c:560 #2 0x404aad27 in concat_function () at /root/cvs/cvsphp/Zend/zend_operators.c:507 #3 0x404bfda5 in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #4 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #5 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #6 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #7 0x404c4fb6 in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #8 0x404af654 in zend_execute_scripts () at /root/cvs/cvsphp/Zend/zend.c:377 #9 0x40473ce5 in php_execute_script () at /root/cvs/cvsphp/main/main.c:1455 #10 0x404c8110 in apache_php_module_main () at /root/cvs/cvsphp/sapi/apache/sapi_apache.c:65 #11 0x404c9138 in send_php (r=0x816f7a8, display_source_mode=0, filename=0x81715a8 /usr/local/httpd/htdocs/headhorde/imp/folders.php) at /root/cvs/cvsphp/sapi/apache/mod_php4.c:564 #12 0x404c91c3 in send_parsed_php (r=0x816f7a8) at /root/cvs/cvsphp/sapi/apache/mod_php4.c:579 #13 0x8055250 in ap_invoke_handler () #14 0x806791c in ap_some_auth_required () #15 0x8067993 in ap_process_request () #16 0x805fde7 in ap_child_terminate () #17 0x805ff95 in ap_child_terminate () #18 0x80600d6 in ap_child_terminate () #19 0x80606e8 in ap_child_terminate () #20 0x8060f55 in main () #21 0x400cba8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
What are you doing in order to get it to crash? At 18:20 07/10/2002, Jan Schneider wrote: Hi, I currently get following segfaults: httpd logs: [Mon Oct 7 17:17:45 2002] [notice] child pid 19460 exit signal Segmentation fault (11) FATAL: emalloc(): Unable to allocate 1515870812 bytes I can understand him well ;-) BT: Program received signal SIGSEGV, Segmentation fault. 0x400d1ab1 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x400d1ab1 in __kill () from /lib/libc.so.6 #1 0x4049945c in _emalloc () at /root/cvs/cvsphp/Zend/zend_alloc.c:560 #2 0x404aad27 in concat_function () at /root/cvs/cvsphp/Zend/zend_operators.c:507 #3 0x404bfda5 in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #4 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #5 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #6 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #7 0x404c4fb6 in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #8 0x404af654 in zend_execute_scripts () at /root/cvs/cvsphp/Zend/zend.c:377 #9 0x40473ce5 in php_execute_script () at /root/cvs/cvsphp/main/main.c:1455 #10 0x404c8110 in apache_php_module_main () at /root/cvs/cvsphp/sapi/apache/sapi_apache.c:65 #11 0x404c9138 in send_php (r=0x816f7a8, display_source_mode=0, filename=0x81715a8 /usr/local/httpd/htdocs/headhorde/imp/folders.php) at /root/cvs/cvsphp/sapi/apache/mod_php4.c:564 #12 0x404c91c3 in send_parsed_php (r=0x816f7a8) at /root/cvs/cvsphp/sapi/apache/mod_php4.c:579 #13 0x8055250 in ap_invoke_handler () #14 0x806791c in ap_some_auth_required () #15 0x8067993 in ap_process_request () #16 0x805fde7 in ap_child_terminate () #17 0x805ff95 in ap_child_terminate () #18 0x80600d6 in ap_child_terminate () #19 0x80606e8 in ap_child_terminate () #20 0x8060f55 in main () #21 0x400cba8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
+1 On October 7, 2002 08:07 am, Melvyn Sopacua wrote: Agreed, but there's one problem: The pspell as you know and love it, is now named GNU Aspell 0.52. The pspell extension must be used, to build with GNU Aspell - the API has been kept as an 'alias' for this purpose. So I vote for: --with-aspell - /dev/null --with-gnu-aspell - AC_ARG_WITH alias for --with-pspell - nothing more. No seperate directory, nor renaming or aliasing of functions. At 13:51 10/7/2002 +0200, DJ Anubis wrote: Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit : Hey there hard working folks, aspell was replaced by pspell long ago, hence I like to remove aspell from the main source tree to either PECL or /dev/null. Any objections? Comments are highly welcome. Hi, You're right. aspell is a survival of an antiquated tradition. pspell is much better. So /dev/null sounds a great place for antiques ;-) DJ Anubis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua Logan I spent a minute looking at my own code by accident. Logan I was thinking What the hell is this guy doing? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
Zeev Suraski wrote: What are you doing in order to get it to crash? Calling any page in IMP. This is why I don't know exactly _where_ it segfaults. I don't have an apache version with debug information at hand, so I can't give you more bt details, sorry. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
Try reducing IMP to the smallest possible script that still reproduces the problem (crashes). That will give us something to go on. Chances are it's not a crash in the engine. At 18:37 07/10/2002, Jan Schneider wrote: Zeev Suraski wrote: What are you doing in order to get it to crash? Calling any page in IMP. This is why I don't know exactly _where_ it segfaults. I don't have an apache version with debug information at hand, so I can't give you more bt details, sorry. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
hmmm yeah, that is the question ! - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Jan Schneider [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 07, 2002 5:29 PM Subject: Re: [PHP-DEV] Segfaults in Zend What are you doing in order to get it to crash? At 18:20 07/10/2002, Jan Schneider wrote: Hi, I currently get following segfaults: httpd logs: [Mon Oct 7 17:17:45 2002] [notice] child pid 19460 exit signal Segmentation fault (11) FATAL: emalloc(): Unable to allocate 1515870812 bytes I can understand him well ;-) BT: Program received signal SIGSEGV, Segmentation fault. 0x400d1ab1 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x400d1ab1 in __kill () from /lib/libc.so.6 #1 0x4049945c in _emalloc () at /root/cvs/cvsphp/Zend/zend_alloc.c:560 #2 0x404aad27 in concat_function () at /root/cvs/cvsphp/Zend/zend_operators.c:507 #3 0x404bfda5 in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #4 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #5 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #6 0x404c2e5c in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #7 0x404c4fb6 in execute () at /root/cvs/cvsphp/Zend/zend_execute.c:963 #8 0x404af654 in zend_execute_scripts () at /root/cvs/cvsphp/Zend/zend.c:377 #9 0x40473ce5 in php_execute_script () at /root/cvs/cvsphp/main/main.c:1455 #10 0x404c8110 in apache_php_module_main () at /root/cvs/cvsphp/sapi/apache/sapi_apache.c:65 #11 0x404c9138 in send_php (r=0x816f7a8, display_source_mode=0, filename=0x81715a8 /usr/local/httpd/htdocs/headhorde/imp/folders.php) at /root/cvs/cvsphp/sapi/apache/mod_php4.c:564 #12 0x404c91c3 in send_parsed_php (r=0x816f7a8) at /root/cvs/cvsphp/sapi/apache/mod_php4.c:579 #13 0x8055250 in ap_invoke_handler () #14 0x806791c in ap_some_auth_required () #15 0x8067993 in ap_process_request () #16 0x805fde7 in ap_child_terminate () #17 0x805ff95 in ap_child_terminate () #18 0x80600d6 in ap_child_terminate () #19 0x80606e8 in ap_child_terminate () #20 0x8060f55 in main () #21 0x400cba8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
Zeev Suraski wrote: Try reducing IMP to the smallest possible script that still reproduces the problem (crashes). That will give us something to go on. Chances are it's not a crash in the engine. This one's really strange and I'm afraid not very helpful. PHP segfaults while returning from a function call. If I exit the script before that call all is well. After the call I get the segfault. If I exit the script inside the function call directly _before_ the function returns all is well again. This not a very complicated function (a static method to be exact) and just returns a not very long string by value. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
hmm, I think that this functionS is not free before the exit, and it take a segfault. Or perhaps the returned value are not free, and now it can be dengerous !?@#! ? Michael - Original Message - From: Jan Schneider [EMAIL PROTECTED] To: Zeev Suraski [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 07, 2002 6:28 PM Subject: Re: [PHP-DEV] Segfaults in Zend Zeev Suraski wrote: Try reducing IMP to the smallest possible script that still reproduces the problem (crashes). That will give us something to go on. Chances are it's not a crash in the engine. This one's really strange and I'm afraid not very helpful. PHP segfaults while returning from a function call. If I exit the script before that call all is well. After the call I get the segfault. If I exit the script inside the function call directly _before_ the function returns all is well again. This not a very complicated function (a static method to be exact) and just returns a not very long string by value. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: output buffering
On Mon, 7 Oct 2002, Zeev Suraski wrote:
Can you see if calling php_end_ob_buffers() in the session deactivate
function, in case BG(url_adapt_state_ex).active is true, solves this problems?
Note the condition here:
There is an even weirder bug, at least in the 4.2.3/CGI case
^
I got the other error:
In HEAD, this yields:
if (!OG(ob_nesting_level)) {
php_error_docref(ref.outcontrol TSRMLS_CC, E_NOTICE, failed to
flush buffer. No buffer to flush.);
..only because I had wiped out my php.ini for the 4.2.3 test
and did not reinstantiate it properly for the HEAD test.
ob_flush together with session.use_trans_sid enabled works in
the latest CVS.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
Jan Schneider wrote: Zeev Suraski wrote: Try reducing IMP to the smallest possible script that still reproduces the problem (crashes). That will give us something to go on. Chances are it's not a crash in the engine. This one's really strange and I'm afraid not very helpful. PHP segfaults while returning from a function call. If I exit the script before that call all is well. After the call I get the segfault. If I exit the script inside the function call directly _before_ the function returns all is well again. This not a very complicated function (a static method to be exact) and just returns a not very long string by value. In another script the segfaults occur in another place. It's hard to trap it down cause it happens during inside a foreach loop. It doesn't happen after the first loop but at any of the subsequent loops. Inside this loop happens - beside a call to imap_utf7_decode() that wasn't called in the the first script - only some assignments and string and array functions. So I guess this actually has something to do with the engine. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: ext/xslt
On Sun, 2002-10-06 at 20:28, Melvyn Sopacua wrote: Sterling, At 22:20 2-10-2002, Sterling Hughes wrote: http://www.bumblebury.com/phptodo/xmsl.html my thoughts on the matter... If you really want to handle XML, XSLT and the like in PHP, the solution is to build a standardized, documented, DOM, SAX, XPath, XInclude, XPointer interface, and then have functions which wrap around these to apply XSLT transformations. I've given this some thought. And while you're right that it would be the best option, I don't see it happen any time soon, because: -- this would then make it core, same as mbstring yes, and? :)) While XML/XSLT is a relatively unimportant technology from a usefulness perspective (imho), it is a very important technology when it comes with interacting with external data sources, ie, sources that you don't have control of/cannot better design. It is essential for PHP, in order to keep up from an enterprise perspective (again, imho), to have a _very_ solid XML extension/XML scheme bundled in. -- domxml module already has an audience and is well maintained so does the xml module. but both modules are (again, imho) inadequate at this point. The domxml module is quite a bit closer, but it started out at a disadvantage because the xml module was bundled by default, and it only aimed to be a dom module. -- the libxml/libxslt libraries are quite a moving target. so is xml... To my knowledge they haven't broken bc in a while. Furthermore, they are the most actively developed, _stable_ libraries that I know of. -- not enough people/knowledge to handle it. This i find hard to believe. I've used libxml/libxslt in other projects and it took me around 2 hours to figure out most of the library and start being productive with it. The project I was doing with XML/XSLT was rather large scale and libxml/libxslt intensive, for other smaller projects it shouldn't be more than 15 minutes to figure it out. Its _certainly_ 100 x easier than figuring out sablotron, SXP, XSLT and expat interfaces. LibXML, libxslt and friends are more feature rich and DOM compliant. Further more - this would make the implementation for another backend quite difficult and possibly slow - would you then drop the libxml/libxlt interaction, or does - despite the other backend - libxml/libxslt still handle the abstraction. Libxml and libxslt are the most feature rich, fastest and most stable libraries out there. Don't take my word for it, try an internet search, studies consistently rank them better than the opensource alternatives... Another point, as a sidebar, libxml/libxslt are C projects and have a more loose license (MIT, I believe) than sablotron. C projects are generally better as PHP tries to be pure C (thus bundling sablotron would be out of the question), and also it lowers the bar for contribution. I personally prefer contributing to C projects, even though I know C++ (in fact, its _because_ I know C++ that I prefer C projects :). Such an abstraction should be easily handled, as far as I see 2 things need to be considered: 1) Adherence to current standards. At this point libxml/libxslt are fully standards compliant, as well as supporting the additions to those standards (including docbook xml/xslt transformations and certain other essential hacks). 2) Expansion. We need to find a way for providing backwards compatibility and forwards compatibility to support the old standards, and to support the new standards without having to change our interface. Also, these libraries would add up to the download size (minor). err... :) So does expat... The fact is _we need a bundled XML solution_. Currently expat only gives us SAX - we need SAX2, DOM, Xpath, Xpointer, Xinclude, XSLT, bundled together, working together flawlessly. I think the approach you've made so far, is the right one, which I'd like to extend further, with the following outlines in mind: -- Abstract x* standards and provide a default backend, which is a lightweight, straight forward approach. These modules should by default be procedural. cvs -d:pserver:[EMAIL PROTECTED]:/repository co adt take a look at the adt abstraction, we should be aiming to provide both interfaces at the same time, DOM (and therefore, XSLT and Xpath, lend themselves to OO approaches, especially when dealing with scripting languages). -- Leave domxml where it is - it is a feature-rich alternative, for people who want an object oriented interface and want to be in sync with the latest standards. -- Add DOM support on ext/xml using the Sablotron SXP interfaces. This extension is now based on expat (which will continue to be so, for existing functions), but it lacks the document creation functions. It only allows for parsing. We could also move ext/xml to ext/xml-parser but I don't think it's a good idea. IMO it will not compete with DomXML, simply because it's procedural and will
Re: [PHP-DEV] Segfaults in Zend
On Mon, 7 Oct 2002, Jan Schneider wrote: In another script the segfaults occur in another place. It's hard to trap it down cause it happens during inside a foreach loop. It doesn't happen after the first loop but at any of the subsequent loops. Inside this loop happens - beside a call to imap_utf7_decode() that wasn't called in the the first script - only some assignments and string and array functions. So I guess this actually has something to do with the engine. If you are on linux, you can try valgrind (http://developer.kde.org/~sewardj/) like this: (first stop httpd) valgrind --gdb-attach /path/to/httpd -X then request your script and check the valgrind console window. It asks to attach when something goes wrong, press Y and then bt from gdb. This should give a good understanding where it goes wrong. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
At 18:43 07/10/2002, Sascha Schumann wrote:
On Mon, 7 Oct 2002, Zeev Suraski wrote:
Can you see if calling php_end_ob_buffers() in the session deactivate
function, in case BG(url_adapt_state_ex).active is true, solves this
problems?
Note the condition here:
There is an even weirder bug, at least in the 4.2.3/CGI case
^
Yeah I know, I thought it also existed in the 4.3 tree. I think that the
solution would be similar in the 4.2 branch - call php_end_ob_buffers() in
case the session module started an output buffering layer...
I got the other error:
In HEAD, this yields:
if (!OG(ob_nesting_level)) {
php_error_docref(ref.outcontrol TSRMLS_CC, E_NOTICE, failed to
flush buffer. No buffer to flush.);
..only because I had wiped out my php.ini for the 4.2.3 test
and did not reinstantiate it properly for the HEAD test.
ob_flush together with session.use_trans_sid enabled works in
the latest CVS.
I understand, but what if you don't call ob_flush()? Does it work properly?
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
I understand, but what if you don't call ob_flush()? Does it work properly? The bug from 4.2.3 does not reappear here. The rewriter kicks in using the final combination of ini settings. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
The new and improved GNU aspell happpens to be almost 100% source-compatible with pspell, in fact, no changes to php source are necessary to use it. I am against creating a yet-another config option. We've got a few of those already. I have no problem with nuking aspell and placing a dummy entry in the docs (akin to www.php.net/delete) telling people to use pspell, because, as far as PHP is concerned, it's the same thing, if that's ok with everyone else. But I don't see a good reason for an alias where you don't need one. just my 2 kopecks :) Vlad Melvyn Sopacua wrote: Agreed, but there's one problem: The pspell as you know and love it, is now named GNU Aspell 0.52. The pspell extension must be used, to build with GNU Aspell - the API has been kept as an 'alias' for this purpose. So I vote for: --with-aspell - /dev/null --with-gnu-aspell - AC_ARG_WITH alias for --with-pspell - nothing more. No seperate directory, nor renaming or aliasing of functions. At 13:51 10/7/2002 +0200, DJ Anubis wrote: Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit : Hey there hard working folks, aspell was replaced by pspell long ago, hence I like to remove aspell from the main source tree to either PECL or /dev/null. Any objections? Comments are highly welcome. Hi, You're right. aspell is a survival of an antiquated tradition. pspell is much better. So /dev/null sounds a great place for antiques ;-) DJ Anubis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua Logan I spent a minute looking at my own code by accident. Logan I was thinking What the hell is this guy doing? -- Vlad Krupin Software Engineer echospace.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
The config option just makes it easier to find, especially when you delete
aspell from the tree.
You would basically try to accomplish, that:
./configure --help | grep aspell
yields something and possibly hint to pspell.
How that is done is insignificant. But adding --with-gnu-aspell would allow
to move it to that name
at some point in time, since GNU packages generally don't change names :-)
my 2.20173 eurocents :)
At 10:20 10/7/2002 -0700, Vlad Krupin wrote:
The new and improved GNU aspell happpens to be almost 100%
source-compatible with pspell, in fact, no changes to php source are
necessary to use it. I am against creating a yet-another config option.
We've got a few of those already.
I have no problem with nuking aspell and placing a dummy entry in the docs
(akin to www.php.net/delete) telling people to use pspell, because, as far
as PHP is concerned, it's the same thing, if that's ok with everyone else.
But I don't see a good reason for an alias where you don't need one.
just my 2 kopecks :)
Vlad
Melvyn Sopacua wrote:
Agreed, but there's one problem:
The pspell as you know and love it, is now named GNU Aspell 0.52.
The pspell extension must be used, to build with GNU Aspell - the API has
been
kept as an 'alias' for this purpose.
So I vote for:
--with-aspell - /dev/null
--with-gnu-aspell - AC_ARG_WITH alias for --with-pspell - nothing more.
No seperate directory, nor renaming or aliasing of functions.
At 13:51 10/7/2002 +0200, DJ Anubis wrote:
Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit :
Hey there hard working folks,
aspell was replaced by pspell long ago, hence I like to remove aspell
from the main source tree to either PECL or /dev/null. Any objections?
Comments are highly welcome.
Hi,
You're right. aspell is a survival of an antiquated tradition. pspell is
much
better. So /dev/null sounds a great place for antiques ;-)
DJ Anubis
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
Logan I spent a minute looking at my own code by accident.
Logan I was thinking What the hell is this guy doing?
--
Vlad Krupin
Software Engineer
echospace.com
/MELVYN
void wakeup() {
for(unsigned int cuppajava;drink();cuppajava++);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] preg_replace eats my backslashes REF BUG#12668
Hi, i recently upgraded from 4.0.4pl1 to 4.2.3 and noticed a different behavior with preg_replace when the substitution string is a variable containing backslashes. at this point 4.2.3 eats every second slash as 4.0.4pl1 don't . here's my example: ? $TPL = foosel#label#lesoof; $DIFF= this one comes from database and contains everything between the quotes: \\sth\\\foo\foobar3 $TPL = preg_replace(/\#([^\#]+)\#/,'\\1 '.$DIFF.' /\\1',$TPL); print $TPL; // returns foosellabel \\sth\\\foo\foobar3 /labellesoof as expected in 4.0.4pl1 // misleadingly returns foosellabel \sth\\foo\foobar\\3 /labellesoof in 4.2.3 ? i found bug#12668 about this issue. but it is flagged Analyzed for over one year with the hint to use preg_replace_callback as workaround. imho the substitution string should be treated as is with the option to turn on addslashes, stripslashes or die($hard) as needed. hardly believable everybody is parsing potentially malicious content whereas addslashes would be useful. i try to parse sourcecode and this new feature is my personal pain in the ass as you certainly can imagine ;) is it possible to regain the old (expected) functionality maybe by an additional argument to preg_replace ??? thanks in advance Christian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
Hi, On Mon, Oct 07, 2002 at 07:50:00PM +0200, Melvyn Sopacua wrote: The config option just makes it easier to find, especially when you delete aspell from the tree. You would basically try to accomplish, that: ../configure --help | grep aspell we can easily add a note like: --with-pspell Include Gnu-aspell support (formerly known as pspell) everyone happy with that? :) Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. Key7BCC EB86 8313 DDA9 25DF Fingerprint1805 ECA5 BCB7 BB96 56B0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ext/aspell
I like the alias option as well.
The aspell/pspell packages seem to be the exception to the
gnu names don't change rule. These two packages have been
a bit of a moving target in terms of both naming and
[inter]dependencies and BC has been an issue a couple of
times.
I apologize in advance, because .02 CDN isn't worth much
these days.
Mike Robinson
-Original Message-
From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 1:50 PM
To: Vlad Krupin
Cc: DJ Anubis; PHP-DEV; Jan Lehnardt
Subject: Re: [PHP-DEV] ext/aspell
The config option just makes it easier to find, especially
when you delete
aspell from the tree.
You would basically try to accomplish, that:
./configure --help | grep aspell
yields something and possibly hint to pspell.
How that is done is insignificant. But adding
--with-gnu-aspell would allow
to move it to that name
at some point in time, since GNU packages generally don't
change names :-)
my 2.20173 eurocents :)
At 10:20 10/7/2002 -0700, Vlad Krupin wrote:
The new and improved GNU aspell happpens to be almost 100%
source-compatible with pspell, in fact, no changes to php source are
necessary to use it. I am against creating a yet-another
config option.
We've got a few of those already.
I have no problem with nuking aspell and placing a dummy
entry in the
docs
(akin to www.php.net/delete) telling people to use pspell,
because, as far
as PHP is concerned, it's the same thing, if that's ok with
everyone else.
But I don't see a good reason for an alias where you don't need one.
just my 2 kopecks :)
Vlad
Melvyn Sopacua wrote:
Agreed, but there's one problem:
The pspell as you know and love it, is now named GNU Aspell 0.52.
The pspell extension must be used, to build with GNU Aspell
- the API
has been kept as an 'alias' for this purpose.
So I vote for:
--with-aspell - /dev/null
--with-gnu-aspell - AC_ARG_WITH alias for --with-pspell - nothing
more.
No seperate directory, nor renaming or aliasing of functions.
At 13:51 10/7/2002 +0200, DJ Anubis wrote:
Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit :
Hey there hard working folks,
aspell was replaced by pspell long ago, hence I
like to remove
aspell from the main source tree to either PECL or
/dev/null. Any
objections?
Comments are highly welcome.
Hi,
You're right. aspell is a survival of an antiquated
tradition. pspell
is
much
better. So /dev/null sounds a great place for antiques ;-)
DJ Anubis
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
@Logan I spent a minute looking at my own code by
accident. @Logan
I was thinking What the hell is this guy doing?
--
Vlad Krupin
Software Engineer
echospace.com
/MELVYN
void wakeup() {
for(unsigned int cuppajava;drink();cuppajava++);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
On October 7, 2002 02:08 pm, Jan Lehnardt wrote: Hi, On Mon, Oct 07, 2002 at 07:50:00PM +0200, Melvyn Sopacua wrote: The config option just makes it easier to find, especially when you delete aspell from the tree. You would basically try to accomplish, that: ../configure --help | grep aspell we can easily add a note like: --with-pspell Include Gnu-aspell support (formerly known as pspell) everyone happy with that? :) Jan Yes, that would be better then having a configure alias option IMHO. If we have alias options that'll only lead to user confusion. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: ext/xslt
At 18:48 10/7/2002 +0200, Sterling Hughes wrote: On Sun, 2002-10-06 at 20:28, Melvyn Sopacua wrote: Sterling, At 22:20 2-10-2002, Sterling Hughes wrote: http://www.bumblebury.com/phptodo/xmsl.html my thoughts on the matter... If you really want to handle XML, XSLT and the like in PHP, the solution is to build a standardized, documented, DOM, SAX, XPath, XInclude, XPointer interface, and then have functions which wrap around these to apply XSLT transformations. I've given this some thought. And while you're right that it would be the best option, I don't see it happen any time soon, because: -- this would then make it core, same as mbstring yes, and? :)) Frankly? I'd rather acknowledge my limitations, than get in way over my head :) Programming a core module is just not something I'm enclined to do. Now if this would be a devoted team, with enough time to spare, I'd be willing to do my share. While XML/XSLT is a relatively unimportant technology from a usefulness perspective (imho), it is a very important technology when it comes with interacting with external data sources, ie, sources that you don't have control of/cannot better design. It is essential for PHP, in order to keep up from an enterprise perspective (again, imho), to have a _very_ solid XML extension/XML scheme bundled in. Agreed. -- domxml module already has an audience and is well maintained so does the xml module. but both modules are (again, imho) inadequate at this point. The domxml module is quite a bit closer, but it started out at a disadvantage because the xml module was bundled by default, and it only aimed to be a dom module. So this would mean, we invent yet another xml related 'extension'. Well - at least it gives users some options... -- the libxml/libxslt libraries are quite a moving target. so is xml... To my knowledge they haven't broken bc in a while. True. Furthermore, they are the most actively developed, _stable_ libraries that I know of. True also. -- not enough people/knowledge to handle it. This i find hard to believe. I've used libxml/libxslt in other projects and it took me around 2 hours to figure out most of the library and start being productive with it. Well - I haven't and I guess it's just a bit overwhelming API, when you count pages :-). The project I was doing with XML/XSLT was rather large scale and libxml/libxslt intensive, for other smaller projects it shouldn't be more than 15 minutes to figure it out. Its _certainly_ 100 x easier than figuring out sablotron, SXP, XSLT and expat interfaces. The basic transformations in Sablot we're pretty straight forward actually. And the SXP interfaces also, except for a starting point, other than a string doc. LibXML, libxslt and friends are more feature rich and DOM compliant. Yes - for the enterprise you would need it. For a basic website (a large portion of the PHP audience currently), which is for instance collecting news data from different content providers, or distributing to different sites from one source (my next larger project at work) this is not needed. The end user of course still has all the options to choose. Further more - this would make the implementation for another backend quite difficult and possibly slow - would you then drop the libxml/libxlt interaction, or does - despite the other backend - libxml/libxslt still handle the abstraction. Libxml and libxslt are the most feature rich, fastest and most stable libraries out there. Don't take my word for it, try an internet search, studies consistently rank them better than the opensource alternatives... Still leaves the question. Are you going to force the abstraction on any given module, wanting to use XML families, or is this going to be an extension, completely seperate from any other efforts. [...] Such an abstraction should be easily handled, as far as I see 2 things need to be considered: 1) Adherence to current standards. At this point libxml/libxslt are fully standards compliant, as well as supporting the additions to those standards (including docbook xml/xslt transformations and certain other essential hacks). 2) Expansion. We need to find a way for providing backwards compatibility and forwards compatibility to support the old standards, and to support the new standards without having to change our interface. [] cvs -d:pserver:[EMAIL PROTECTED]:/repository co adt take a look at the adt abstraction, we should be aiming to provide both interfaces at the same time, DOM (and therefore, XSLT and Xpath, lend themselves to OO approaches, especially when dealing with scripting languages). I'll do that. -- Add DOM support on ext/xml using the Sablotron SXP interfaces. This extension is now based on expat (which will continue to be so, for existing functions), but it lacks the document creation functions. It only allows for parsing. We could also move ext/xml to
Re: [PHP-DEV] ext/aspell
At 20:40 7-10-2002, Ilia A. wrote: On October 7, 2002 02:08 pm, Jan Lehnardt wrote: Hi, On Mon, Oct 07, 2002 at 07:50:00PM +0200, Melvyn Sopacua wrote: The config option just makes it easier to find, especially when you delete aspell from the tree. You would basically try to accomplish, that: ../configure --help | grep aspell we can easily add a note like: --with-pspell Include Gnu-aspell support (formerly known as pspell) everyone happy with that? :) Jan Yes, that would be better then having a configure alias option IMHO. If we have alias options that'll only lead to user confusion. I can see your point, but I'd rather look forward in this case. Looking back, does not make any sence here, as the past is disturbing enough as it is (aspell, pspell - new Aspell - GNU Aspell). There are two possible scenarios at present: 1) Kevin will grow tired of this product and drop it, leaving latest source in the GNU source repository, without any maintainer. 2) Another maintainer will come forth and the GNU package lives on as GNU aspell. So - it's not such a bad idea, to already introduce this, since in 6 months time, powered by GNU marketing(tm), 'nobody' will know 'pspell' anymore and --with-pspell will make as little sense as some of you think --with-gnu-aspell is now. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
On October 7, 2002 03:45 pm, Melvyn Sopacua wrote: At 20:40 7-10-2002, Ilia A. wrote: On October 7, 2002 02:08 pm, Jan Lehnardt wrote: Hi, On Mon, Oct 07, 2002 at 07:50:00PM +0200, Melvyn Sopacua wrote: The config option just makes it easier to find, especially when you delete aspell from the tree. You would basically try to accomplish, that: ../configure --help | grep aspell we can easily add a note like: --with-pspell Include Gnu-aspell support (formerly known as pspell) everyone happy with that? :) Jan Yes, that would be better then having a configure alias option IMHO. If we have alias options that'll only lead to user confusion. I can see your point, but I'd rather look forward in this case. Looking back, does not make any sence here, as the past is disturbing enough as it is (aspell, pspell - new Aspell - GNU Aspell). There are two possible scenarios at present: 1) Kevin will grow tired of this product and drop it, leaving latest source in the GNU source repository, without any maintainer. 2) Another maintainer will come forth and the GNU package lives on as GNU aspell. So - it's not such a bad idea, to already introduce this, since in 6 months time, powered by GNU marketing(tm), 'nobody' will know 'pspell' anymore and --with-pspell will make as little sense as some of you think --with-gnu-aspell is now. Well, the name currently assigned to the package may indeed be the name used for it in years to come. While new comers may not know of pspell, people who have compiled PHP before with it will, infact that is what they'll expect when configuring their PHP. Since we cannot remove the old pspell option like we seem to agree to do for --with-aspell it is cleaner IMHO to simply add that little bit of text that will tell people new to php that --with-pspell also applies to GNU Aspell. Perpaps, a year down the road when we feel confortable to say that GNU marketing(tm) has made pspell absolete we can make this change. Ilia Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
Derick Rethans wrote: On Mon, 7 Oct 2002, Jan Schneider wrote: In another script the segfaults occur in another place. It's hard to trap it down cause it happens during inside a foreach loop. It doesn't happen after the first loop but at any of the subsequent loops. Inside this loop happens - beside a call to imap_utf7_decode() that wasn't called in the the first script - only some assignments and string and array functions. So I guess this actually has something to do with the engine. If you are on linux, you can try valgrind (http://developer.kde.org/~sewardj/) like this: (first stop httpd) valgrind --gdb-attach /path/to/httpd -X then request your script and check the valgrind console window. It asks to attach when something goes wrong, press Y and then bt from gdb. This should give a good understanding where it goes wrong. I'd like to but I get an unhandled syscall: 197 though I don't even have such a call in unistd.h. :-( -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3 fastcgi
I'd like to make sure fastcgi is well supported in 4.3. I spent some time over the weekend working on this and have some patches that I'll try to get into the tree in the next day or so. I haven't commited them yet as I am having problems getting it to work with apache2-win32/mod_fastcgi (a mod_fastcgi configuration issue I'm trying to figure out). I don't have the time however to do any testing on linux with this, and linux also needs build changes (more on this below). Some months ago I integrated the fastcgi sapi module into the cgi module for a couple reasons. One was the lack of support for a bunch of stuff in the fastcgi module which the cgi module already had. I felt that rather than maintaining the same code/features in two different modules, that a single module would be better. Another reason was that I wanted one executable rather than multiple executables (I still see php-cli and php-cgi seperation as a downside). There is also a somewhat customized libfcgi under sapi/cgi directory. This primarily contains bug fixes for win32, and changes to make the library a better fit for PHP (ie. not calling exit on errors). The build system needs updating to support building this on Linux systems. I'm thinking that --with-cgi-fastcgi would build the cgi/fastcgi module, and --with-fastcgi would build the seperate fastcgi sapi module. --with-cgi-fastcgi should be default when building the php-cgi module, and a --without-cgi-fastcgi available to turn it off. Another option, --libfcgi=path to use a library different that the one included in the source tree. One of the items in my uncommited patch is to integrate the last changes that happened in the fastcgi sapi module, which is support for running PHP as a fastcgi socket server. One difference between the to is the way that is initated: php-fastcgi address:port php-cgi -b address:port If anyone sees any issue with getting this into 4.3 please let me know. A future feature (after 4.3) I want to implement for fastcgi is a multithreaded fastcgi socket server. This would allow for more configurability in how php is used (single process/request, single process/multiple requests), and provide a way to run out-of-process multithreaded php. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
Sounds good to me. Andi At 10:09 AM 10/7/2002 -0400, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
Wow. Zeev and I used the *exact* same sentence. Scary... Andi At 05:19 PM 10/7/2002 +0300, Zeev Suraski wrote: Sounds good to me. At 17:09 07/10/2002, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
On Mon, 7 Oct 2002, Andi Gutmans wrote: Wow. Zeev and I used the *exact* same sentence. Scary... It's just more evidence that you're the same person :) Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
Shush. They already think we're a single schizophrenic person, don't add more wood to the fire :) At 23:32 07/10/2002, Andi Gutmans wrote: Wow. Zeev and I used the *exact* same sentence. Scary... Andi At 05:19 PM 10/7/2002 +0300, Zeev Suraski wrote: Sounds good to me. At 17:09 07/10/2002, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
That mean you're not? :-o -- Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com - Hébergement de sites Internet Zeev Suraski [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Shush. They already think we're a single schizophrenic person, don't add more wood to the fire :) At 23:32 07/10/2002, Andi Gutmans wrote: Wow. Zeev and I used the *exact* same sentence. Scary... Andi At 05:19 PM 10/7/2002 +0300, Zeev Suraski wrote: Sounds good to me. At 17:09 07/10/2002, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 plans
Never mind him, he always talks to himself. On Mon, 07 Oct 2002, [EMAIL PROTECTED] wrote: That mean you're not? :-o -- Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com - Hébergement de sites Internet Zeev Suraski [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Shush. They already think we're a single schizophrenic person, don't add more wood to the fire :) At 23:32 07/10/2002, Andi Gutmans wrote: Wow. Zeev and I used the *exact* same sentence. Scary... Andi At 05:19 PM 10/7/2002 +0300, Zeev Suraski wrote: Sounds good to me. At 17:09 07/10/2002, Andrei Zmievski wrote: I think the general consensus is that PHP tree is not ready for branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from HEAD on Thursday, so that QA team (or what's left of it) and everyone else can test it. Subsequently, based on the results of that testing we can see if branching for RC1 will make sense or if we should roll RC's from HEAD and branch later. Agreed? -Andrei http://www.gravitonic.com/ Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -Andrei http://www.gravitonic.com/ Freedom comes when you learn to let go. Creation comes when you learn to say no. -madonna -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP_ADD_LIBPATH problem
The PHP_ADD_LIBPATH configure macro starts like this: AC_DEFUN(PHP_ADD_LIBPATH,[ if test $1 != /usr/lib; then And we also have a PHP_REMOVE_USR_LIB macro which is called on the generated LDPATH string, so even if I do manage to sneak in my /usr/lib directory somewhere it is removed. This is causing me problems in an environment where /usr/lib is not the default primary link directory and I need to explicitly add it to get stuff to compile right. Why is this check here? Just to pretty up the link line? Would it hurt to leave this check off so /usr/lib can be forced on weird systems? -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_ADD_LIBPATH problem
Hrm... Removing this does produce an amazingly ugly link line. After playing a bit and getting frustrated that pre-setting LDFLAGS and even PHP_LDFLAGS in my env resulted in /usr/lib getting stripped out of those again I figured out that setting EXTRA_LDFLAGS to -L/usr/lib in my env lets me compile. That should do it for now I guess, but I can see others perhaps getting confused by this. -Rasmus On Mon, 7 Oct 2002, Rasmus Lerdorf wrote: The PHP_ADD_LIBPATH configure macro starts like this: AC_DEFUN(PHP_ADD_LIBPATH,[ if test $1 != /usr/lib; then And we also have a PHP_REMOVE_USR_LIB macro which is called on the generated LDPATH string, so even if I do manage to sneak in my /usr/lib directory somewhere it is removed. This is causing me problems in an environment where /usr/lib is not the default primary link directory and I need to explicitly add it to get stuff to compile right. Why is this check here? Just to pretty up the link line? Would it hurt to leave this check off so /usr/lib can be forced on weird systems? -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
Zeev Suraski wrote: Really? Yasuo, people have been requesting that we disable your write access to the full php4 tree, and uptil now I was against it. But this attitude is making me reconsider my stand on this. This is the 2nd time in the last couple of days that I notice that your unverified assumptions introduced inconsistencies/bugs/misbehaviors, and if you don't realize that it needs to be fixed, we have a bit of a problem here. Please reconsider. Zeev, I think you know my attitude. I usually ask when it's not clear bug or simple bug. I'm write if I'm not sure which Sascha said people don't read code shouldn't comment. I agree and I usually follow this basic rule. There is misunderstanding that I thought you were willing to have flushing while you are not. This resulted that mess we had. I think it has been resolved, isn't it? No. I don't think I need to ask. This line should be read No. I don't think I need to ask if it is problem or not. It is problem which I'm not willing to be fixed. It does not work as it is supposed in limited case. We have options, leave code and document limitation, modify code to resolve small issue or just ignore it. Flushing is problematic and we know well :) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfaults in Zend
Zeev Suraski wrote: Try reducing IMP to the smallest possible script that still reproduces the problem (crashes). That will give us something to go on. Chances are it's not a crash in the engine. Optionally, see Locating which function call caused segfault section http://bugs.php.net/bugs-generating-backtrace.php BTW, I wrote this pages months ago. (We're better to move the back trace generating page more obvious place) -- Yasuo Ohgaki At 18:37 07/10/2002, Jan Schneider wrote: Zeev Suraski wrote: What are you doing in order to get it to crash? Calling any page in IMP. This is why I don't know exactly _where_ it segfaults. I don't have an apache version with debug information at hand, so I can't give you more bt details, sorry. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP_ADD_LIBPATH problem
This is causing me problems in an environment where /usr/lib is not the default primary link directory and I need to explicitly add it to get stuff to compile right. Why is this check here? Just to pretty up the link line? Would it hurt to leave this check off so /usr/lib can be forced on weird systems? There are various systems which host multiple compile environments on one machine (e.g. 32 and 64 bit data models). Libraries are stored in distinct directories, such as /usr/lib for 32 bit and /usr/lib64. In these cases, it is fatal to add /usr/lib to the link line and as such we prevent it in a central place. You can simply add a section in the case $host_alias section: *yoursystemname*) php_ldflags_add_usr_lib=yes;; - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] String function optimizations
On October 4, 2002 11:27 am, Jani Taskinen wrote:
On Fri, 4 Oct 2002, Andrei Zmievski wrote:
Please let me know if there are any objections, better suggestions, bug
reports (pertaining to this patch) that would need to be resolved before
this bug goes into the CVS.
I am not against merging this in before branching for 4.3.0, but we
would really need to make sure that these functions are rock solid.
Hopefully our QA team or what's left of it can come up with some tests.
Propably would be best to wait to get the tests before this
is committed? (sorry if this was obvious..just wanted to be sure..)
I've added 3 tests today that validate input of strstr, substr_count and
strpos functions. These three functions are the ones affected by the patch,
there is already a check for addslashes().
I've also made small revisions to the code that addresses at a searching
problem inside php_memnstr in the original patch. The final patch is
attached.
Index: string.c
===
RCS file: /repository/php4/ext/standard/string.c,v
retrieving revision 1.315
diff -u -3 -p -r1.315 string.c
--- string.c6 Oct 2002 18:39:03 - 1.315
+++ string.c7 Oct 2002 21:11:46 -
-2427,17 +2427,19 PHPAPI char *php_addslashes(char *str, i
char *new_str;
char *source, *target;
char *end;
- char c;
if (!str) {
*new_length = 0;
return str;
}
new_str = (char *) emalloc((length?length:(length=strlen(str)))*2+1);
+ source = str;
+ end = source + length;
+ target = new_str;
+
if (PG(magic_quotes_sybase)) {
- for (source = str, end = source+length, target = new_str; source
end; source++) {
- c = *source;
- switch (c) {
+ while (sourceend) {
+ switch (*source) {
case '\0':
*target++ = '\\';
*target++ = '0';
-2447,14 +2449,16 PHPAPI char *php_addslashes(char *str, i
*target++ = '\'';
break;
default:
- *target++ = c;
- break;
+ *target++ = *source;
+ break;
}
+ source++;
}
- } else {
- for (source = str, end = source+length, target = new_str; source
end; source++) {
- c = *source;
- switch (c) {
+ }
+ else {
+ while (sourceend) {
+ switch (*source)
+ {
case '\0':
*target++ = '\\';
*target++ = '0';
-2465,11 +2469,14 PHPAPI char *php_addslashes(char *str, i
*target++ = '\\';
/* break is missing *intentionally* */
default:
- *target++ = c;
- break;
+ *target++ = *source;
+ break;
}
+
+ source++;
}
}
+
*target = 0;
if (new_length) {
*new_length = target - new_str;
-3805,7 +3812,7 PHP_FUNCTION(strnatcasecmp)
PHP_FUNCTION(substr_count)
{
zval **haystack, **needle;
- int i, length, count = 0;
+ int count = 0;
char *p, *endp, cmp;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, haystack, needle) ==
FAILURE) {
-3818,25 +3825,23 PHP_FUNCTION(substr_count)
if (Z_STRLEN_PP(needle) == 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Empty substring.);
RETURN_FALSE;
- } else if (Z_STRLEN_PP(needle) == 1) {
- /* Special optimized case to avoid calls to php_memnstr(). */
- for (i = 0, p = Z_STRVAL_PP(haystack),
-length = Z_STRLEN_PP(haystack), cmp = Z_STRVAL_PP(needle)[0];
-i length; i++) {
- if (p[i] == cmp) {
- count++;
+ }
+
+ p = Z_STRVAL_PP(haystack);
+ endp = p + Z_STRLEN_PP(haystack);
+
+ if (Z_STRLEN_PP(needle) == 1) {
+ cmp = Z_STRVAL_PP(needle)[0];
+
+ while (p endp) {
+ if (*(p++) == cmp) {
+ count++;
}
RE: [PHP-DEV] auto_prepend/append: does the PHP engine cache the
Pwee does allow you to change the environment based on virtual host by setting a php_value for pwee.userconfpath in either the VirtualHost specification or .htaccess file. There's a brief section on the web site about this. It's not as elegant a solution as you'd like though. Being able to specify a vhost attribute to filter environments by virtual host the same way it currently does based on IP address is a good idea. I would have done this already but I don't know how to determine what virtual host is handling the current request. One solution would be to define a php_value that defines what the filter should be. When the virtual hosts change I would see that filter value change. That would still require you to edit your VirtualHost or .htaccess though. If there's another way to determine the active virtual host, maybe someone else can point me in a direction. Lance -Original Message- From: Colin Viebrock [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 11:12 AM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the Lance, I just noticed this post, and PWEE sounds pretty interesting. One thing that would definitly make me consider using it in a production environment would be the ability to change configuration based on the name of the vhost being accessed. For example, we've got several sites all running the same code on the same IP. I use an auto_prepended file to check the hostname being accessed, and then include() some site-specific variables to change the look and feel of the site. Take a look at: http://domains.dslreports.com/ http://bell.easydns.ca/ http://domains.canadacomputes.com/ If I could set up PWEE with something like this: ?xml version=1.0? Environments Application name=DNS_PARTNERS namespace= Server vhost=domains.dslreports.com Constants Constant name=DATABASE_HOSTNAME value=dsl / /Constants /Server Server vhost=bell.easydns.ca Constants Constant name=DATABASE_HOSTNAME value=bell / /Constants /Server ... etc ... /Application /Environments Is this possible in PWEE right now? If not, would you consider adding support for it? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h.in
Stig Bakken wrote: ssb Mon Oct 7 21:04:52 2002 EDT Modified files: /php4/main config.w32.h.in Log: * make these variables configurable from environment on Windows: PEAR_INSTALLDIR PHP_BINDIR PHP_CONFIG_FILE_PATH PHP_CONFIG_FILE_SCAN_DIR PHP_DATADIR PHP_EXTENSION_DIR PHP_INCLUDE_PATH PHP_LIBDIR PHP_LOCALSTATEDIR PHP_PREFIXPHP_SYSCONFDIR This broke the build for me (Win32, MSVC++ 6). I get Initialization is not a constant errors where constants like PHP_EXTENSION_DIR are accessed. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
