Re: [PHP-DEV] serialize and cache handling
On Mon, 7 May 2007, Lukas Kahwe Smith wrote: Stanislav Malyshev wrote: can write this data to disk. So, you needs 20MB. If serialize (and of course unserialize) would be able to write directly to disk (or read directly from disk), you only needs 10MB. Actually having serialize/unserialize be able to write directly to a stream and read directly from a stream might be interesting, would probably improve working with things like large sessions or caching large data substantially. Indeed, especially since this is the most common use case. Maybe it should optionally also return an md5 of the written data. If we're to add this, make sure writes to the files are atomic. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: yanbin
I'm a PHP Programmer from China, I'd like to help translate phpdoc_zh. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Stanislav Malyshev wrote: We will need it: - by the time of PHP 6 I think this problem should be fixed not by killing PEAR and converting it to PHP extensions but by fixing PHP 6 and enabling PEAR to work. Let me agree with Greg here. We can not go back to the PHP 4.x way of bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 uses the phar, which works brilliantly. So the fix here is to make something *like* phar work with PHP 6 as well. If it was to be based on streams (which I think it can only be), then we *need* some way of marking this new user stream as being local in order for require and include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Stanislav Malyshev wrote: PHP_Archive-based phar archives will no longer work once allow_url_include is off and user streams wrappers are marked as remote. So, it won't work with 100% of new installations in future PHP versions. I guess we are solving the wrong problem. We have: 1. phar needs script-defined named streams 2. Named streams are prohibited by some config option 3. Let's pretend this stream is not actually what it is 4. Let's create whole new extension for that and put it into main PHP I think this process is wrong. If we have problem with names streams usage in apps, we should seek solutions there, not invent modules just to work around the problem we ourselves create. So why don't you come up with a different better solution then? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/8/07, Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 7 May 2007, Stanislav Malyshev wrote: We will need it: - by the time of PHP 6 I think this problem should be fixed not by killing PEAR and converting it to PHP extensions but by fixing PHP 6 and enabling PEAR to work. Let me agree with Greg here. We can not go back to the PHP 4.x way of bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 uses the phar, which works brilliantly. So the fix here is to make something *like* phar work with PHP 6 as well. If it was to be based on streams (which I think it can only be), then we *need* some way of marking this new user stream as being local in order for require and include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
On 05/08/2007 05:36 AM, Oliver Block wrote:
Hello,
I am getting a SIGSEGV when compiling php-5.2.2.
gdb breaks up at the if statement of the following function
static void php_apache_add_version(apr_pool_t *p)
{
TSRMLS_FETCH();
if (PG(expose_php)) {
ap_add_version_component(p, PHP/ PHP_VERSION);
}
}
It only occurs when --enable-maintainer-zts is used.
main/php_globals.h:
# define PG(v) TSRMG(core_globals_id, php_core_globals *, v)
extern PHPAPI int core_globals_id;
#else
# define PG(v) (core_globals.v)
extern ZEND_API struct _php_core_globals core_globals;
#endif
TSRM/TSRM.h
#define TSRM_UNSHUFFLE_RSRC_ID(rsrc_id) ((rsrc_id)-1)
#define TSRMG(id, type, element)(((type) (*((void ***) tsrm_ls))
[TSRM_UNSHUFFLE_RSRC_ID(id)])-element)
GDB tells me that core_globals_id == 0 which leads to an index of -1 -- if I
interpret the results correctly.
Either GDB is wrong or your build is badly broken.
core_globals_id is initialized in main/main.c, line 1491
*rsrc_id = TSRM_SHUFFLE_RSRC_ID(id_count++);
#define TSRM_SHUFFLE_RSRC_ID(rsrc_id) ((rsrc_id)+1)
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello internals, Tuesday, May 8, 2007, 10:13:15 AM, Pierre wrote: On 5/8/07, Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 7 May 2007, Stanislav Malyshev wrote: We will need it: - by the time of PHP 6 I think this problem should be fixed not by killing PEAR and converting it to PHP extensions but by fixing PHP 6 and enabling PEAR to work. Let me agree with Greg here. We can not go back to the PHP 4.x way of bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 uses the phar, which works brilliantly. So the fix here is to make something *like* phar work with PHP 6 as well. If it was to be based on streams (which I think it can only be), then we *need* some way of marking this new user stream as being local in order for require and include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. Right Pierre, as you said, this is a different thing that might have to be addressed anyway. However phar is a real life thing that needs to be working. Besides, Phar is neither a custom extension - at least i do not see either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? In the past we have bundeled even stuff that has not been stable or in a mature state. And I have not seen a single reason against it. The only one close so far was that PHARs cannot be handled with your favorite Winzip or whatever you are using. Guess what, I have PHP installed and last time I checked PHP worked nearly perfectly. And last time I had to deal with JARs I did not have the slightest advantage of having it be a ZIP file. Just because in all those Java formats you have to provide specific files in a very specific format with very specific content. And this is the absolute opposite of the flexibility we aim for with Phar. Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem and b) we should not eventhink of turning it into a JAR and hack around PHP all over. Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/8/07, Marcus Boerger [EMAIL PROTECTED] wrote: Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem And to read zip files (upload, ftp, remote data). I think each of us has had to deal with zip data (read or write) more than once. It is a mainstream need. Or if you mean that phar is not a mainstream problem then I agree. But I don't really see the point to compare both, they are too completely different extension (general purpose and developer/packager extension). I'm in general in favour of phar but I don't think we should start 5.3 for it. I don't think either that it is stable enough to be bundled. I doubt it is possible to have a stable package in only three public releases (even the first public release was already marked stable). However once this package got a wider audience and users base, I don't have real objections to do not bundle it even if I still think that phar is a packager tool and have little to do with the mainstream needs. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/08/2007 12:36 PM, Marcus Boerger wrote: The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. Right Pierre, as you said, this is a different thing that might have to be addressed anyway. However phar is a real life thing that needs to be working. Besides, Phar is neither a custom extension - at least i do not see either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? And I have not seen a single reason against it. I have not seen a single reason FOR it either. The only half-valid reason is that phars will stop working in PHP6 because of the streams breakage. But that's definitely the reason to fix streams, otherwise we'll have to include each every extension using custom streams. Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem and b) we should not eventhink of turning it into a JAR and hack around PHP all over. Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/08/2007 12:36 PM, Marcus Boerger wrote: Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem and b) we should not eventhink of turning it into a JAR and hack around PHP all over. Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? Please, Marcus don't mix your personal feelings and the question we're discussing here. PECL/zip has nothing to do with PEAR/phar and it does not matter how mainstream is it. *Unfortunately* it's already there, so it's too late to discuss whether it was good or bad decision. And referring to other extensions (they did it, why can't I do it) is just childish. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Pierre, Tuesday, May 8, 2007, 10:58:19 AM, you wrote: On 5/8/07, Marcus Boerger [EMAIL PROTECTED] wrote: Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem And to read zip files (upload, ftp, remote data). I think each of us has had to deal with zip data (read or write) more than once. It is a mainstream need. Or if you mean that phar is not a mainstream problem then I agree. But I don't really see the point to compare both, they are too completely different extension (general purpose and developer/packager extension). I hoped to make clear that even all of them are package extensions at least to me they severe a different purpose. Especially I wanted to point out that we should not make any of them executeable like JARs. I'm in general in favour of phar but I don't think we should start 5.3 for it. I don't think either that it is stable enough to be bundled. I doubt it is possible to have a stable package in only three public releases (even the first public release was already marked stable). We do not need to create 5.3 to bundle it. And well if you design something and test it thoroully you can mark even the first public release as stable. We've even put phar to gcov.php.net prior to releasing it to prevent memleaks and ensure a pretty high quality. After that we waited ffor another half year and only then after still being sure it works (by checking that it worked for us) we released it. However once this package got a wider audience and users base, I don't have real objections to do not bundle it even if I still think that phar is a packager tool and have little to do with the mainstream needs. In this case the audience is the PHP_Archive audience as well. It is one of the things PECL was designed for. Develop something in PHP and the turn it into a PHP extension. --Pierre Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Antony, Tuesday, May 8, 2007, 10:59:28 AM, you wrote: On 05/08/2007 12:36 PM, Marcus Boerger wrote: The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. Right Pierre, as you said, this is a different thing that might have to be addressed anyway. However phar is a real life thing that needs to be working. Besides, Phar is neither a custom extension - at least i do not see either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. It is not my main argument - not at all. My argument is that it is something that serves a need perfectly and makes the PHP_Archive stuff turned into a fast C extension. Including it would allow to make it a suggested sound and save deployment solution with a bunch of nice additional pros. Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. We have no means at all to support that. And even after years of having PECL I cannot see the slightest aim to solve the issue. All we have right now is to provide stuff that works for experienced admins. Experienced in compiling and automake tools. Before we can go in a all to PECL way of doing things we would need to reduce the number of completely incompatible builds (ZTS, debug, ZTS-debug, normal). Andwewould have to decide on a sane pugable API. One that does not change from version to version. Not even additions would be allowed. All would have to be done via callbacks. And eventually with struct versioning. But we do not even allow a TODO discussion board on php.net somewhere nor did we ever respect our own TODOs. So how is this ever going to happen? So infact if we like something we can either bundle it or have it die. In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? Phar is stable. All I said is that we won't do the same mistake again. Meaning that none of those arguemts speaks against Phar. If feel the need to misinterpret these arguments than i am sorry. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/wddx wddx.c /ext/wddx/tests bug41283.phpt
Hi Ilia, all,
I've attached patches for what I think is a better fix here, and it
simplifies the code. Looking at the CVS log, the is_numeric_string() usage
was added in version 1.120 to fix the first numeric key bug. The simple,
better thing would've been to just change zend_hash... to zend_symtable...,
as I've done now. Ilia, this is basically the same fix as Bug #38464 for
array_count_values().
Again, the symtable function will handle numeric string keys as elsewhere
in PHP. The only thing that changes from the current code is that strings
with leading whitespace, + sign, or 0s won't be considered numeric again
(e.g. back to behavior before the symtable functions were created), which
should be correct if you don't want more future bug reports. ;-)
Matt
- Original Message -
From: Ilia Alshanetsky
Sent: Saturday, May 05, 2007
iliaa Sat May 5 15:14:56 2007 UTC
Added files: (Branch: PHP_5_2)
/php-src/ext/wddx/tests bug41283.phpt
Modified files:
/php-src NEWS
/php-src/ext/wddx wddx.c
Log:
Fixed bug #41283 (Bug with serializing array key that are doubles or
floats).
http://cvs.php.net/viewvc.cgi/php-src/ext/wddx/wddx.c?r1=1.119.2.10.2.15r2=1.119.2.10.2.16diff_format=u
Index: php-src/ext/wddx/wddx.c
diff -u php-src/ext/wddx/wddx.c:1.119.2.10.2.15
php-src/ext/wddx/wddx.c:1.119.2.10.2.16
--- php-src/ext/wddx/wddx.c:1.119.2.10.2.15 Sun Mar 4 04:38:43 2007
+++ php-src/ext/wddx/wddx.c Sat May 5 15:14:56 2007
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: wddx.c,v 1.119.2.10.2.15 2007/03/04 04:38:43 stas Exp $ */
+/* $Id: wddx.c,v 1.119.2.10.2.16 2007/05/05 15:14:56 iliaa Exp $ */
#ifdef HAVE_CONFIG_H
#include config.h
@@ -984,6 +984,9 @@
goto bigint;
}
l = (long) d;
+ if (l != d) {
+ goto bigint;
+ }
case IS_LONG:
zend_hash_index_update(target_hash, l, ent1-data, sizeof(zval *),
NULL);
break;
Index: ext/wddx/wddx.c
===
RCS file: /repository/php-src/ext/wddx/wddx.c,v
retrieving revision 1.144
diff -u -r1.144 wddx.c
--- ext/wddx/wddx.c 24 Feb 2007 16:25:55 - 1.144
+++ ext/wddx/wddx.c 8 May 2007 09:07:59 -
@@ -975,22 +975,7 @@
add_property_zval(ent2-data,
ent1-varname, ent1-data);
EG(scope) = old_scope;
} else {
- long l;
- double d;
-
- switch
(is_numeric_string(ent1-varname, strlen(ent1-varname), l, d, 0)) {
- case IS_DOUBLE:
- if (d
INT_MAX) {
- goto
bigint;
- }
- l = (long) d;
- case IS_LONG:
-
zend_hash_index_update(target_hash, l, ent1-data, sizeof(zval *), NULL);
- break;
- default:
-bigint:
-
zend_hash_update(target_hash,ent1-varname, strlen(ent1-varname)+1,
ent1-data, sizeof(zval *), NULL);
- }
+
zend_symtable_update(target_hash, ent1-varname, strlen(ent1-varname)+1,
ent1-data, sizeof(zval *), NULL);
}
efree(ent1-varname);
} else {
Index: ext/wddx/wddx.c
===
RCS file: /repository/php-src/ext/wddx/wddx.c,v
retrieving revision 1.119.2.10.2.16
diff -u -r1.119.2.10.2.16 wddx.c
--- ext/wddx/wddx.c 5 May 2007 15:14:56 - 1.119.2.10.2.16
+++ ext/wddx/wddx.c 8 May 2007 09:08:34 -
@@ -974,26 +974,7 @@
add_property_zval(ent2-data,
ent1-varname, ent1-data);
EG(scope) = old_scope;
} else {
- long l;
- double d;
- int varname_len =
strlen(ent1-varname);
-
- switch
(is_numeric_string(ent1-varname, varname_len, l, d, 0)) {
-
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/08/2007 01:17 PM, Marcus Boerger wrote: But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. It is not my main argument - not at all. My argument is that it is something that serves a need perfectly and makes the PHP_Archive stuff turned into a fast C extension. Including it would allow to make it a suggested sound and save deployment solution with a bunch of nice additional pros. Please correct me if I'm wrong: phars do work without PECL/phar, don't they? Then why in hell do we need PECL/phar in the core? (except for that streams problem) Because it's faster than PHP_Archive? I don't really care if PEAR install takes 5 seconds or 4 seconds, I can wait one more second once in a month. If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. We have no means at all to support that. And even after years of having PECL I cannot see the slightest aim to solve the issue. All we have right now is to provide stuff that works for experienced admins. Experienced in compiling and automake tools. The only tool required is autoconf (2.13 is recommended, other versions are supported too). All the other tools are required by PHP itself. You don't need to be an experienced admin to install autoconf, this is typical anti-PECL FUD and I'm a bit tired to fight it.. (Btw, Ilia recently proposed to create packages with pre-built configure, so even the autoconf requirement would go). Before we can go in a all to PECL way of doing things we would need to reduce the number of completely incompatible builds (ZTS, debug, ZTS-debug, normal). I'm not sure I understand what you're talking about. We never provided debug binary builds and I see no reasons to do it. Andwewould have to decide on a sane pugable API. Okay, let's do it. We have a nice chance to break everything we can - it's PHP6 anyway =) I'd really like to hear your thoughts on improving the API. Want to make a separate thread? One that does not change from version to version. Not even additions would be allowed. All would have to be done via callbacks. And eventually with struct versioning. But we do not even allow a TODO discussion board on php.net somewhere nor did we ever respect our own TODOs. This IS the discussion board. So how is this ever going to happen? So infact if we like something we can either bundle it or have it die. Ok, so let me summarize it: to leave PECL/phar in PECL you need a new pluggable API, and to create the API you need a discussion board, but even having it you would not discuss the API because nobody respects TODOs. Did I miss something? In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? Phar is stable. All I said is that we won't do the same mistake again. PECL/json, PECL/zip and the others were/are stable too. That doesn't mean there are no bugs we don't know of. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
Hello Tony,
according to my backtrace, this line (main/main.c:1491) is not processed.
366 if (PG(expose_php)) {
(gdb) p core_globals_id
$4 = 0
The backtrace follows:
Program received signal SIGSEGV, Segmentation fault.
0x40bb4449 in php_apache_add_version (p=0x80a40a8)
at /usr/local/src/php-5.2.2/sapi/apache2handler/sapi_apache2.c:366
366 if (PG(expose_php)) {
(gdb) bt full
#0 0x40bb4449 in php_apache_add_version (p=0x80a40a8)
at /usr/local/src/php-5.2.2/sapi/apache2handler/sapi_apache2.c:366
tsrm_ls = (void ***) 0x83a19b0
#1 0x40bb4537 in php_apache_server_startup (pconf=0x80a40a8, plog=0x80ce150,
ptemp=0x80d0158, s=0x80be308)
at /usr/local/src/php-5.2.2/sapi/apache2handler/sapi_apache2.c:417
data = (void *) 0x1
userdata_key = 0x40c704e7 apache2hook_post_config
#2 0x080691fd in ap_run_post_config ()
No symbol table info available.
#3 0x0806f622 in main ()
No symbol table info available.
Regards,
Oliver
Am Dienstag, 8. Mai 2007 10:21 schrieben Sie:
On 05/08/2007 05:36 AM, Oliver Block wrote:
Hello,
I am getting a SIGSEGV when compiling php-5.2.2.
gdb breaks up at the if statement of the following function
static void php_apache_add_version(apr_pool_t *p)
{
TSRMLS_FETCH();
if (PG(expose_php)) {
ap_add_version_component(p, PHP/ PHP_VERSION);
}
}
It only occurs when --enable-maintainer-zts is used.
main/php_globals.h:
# define PG(v) TSRMG(core_globals_id, php_core_globals *, v)
extern PHPAPI int core_globals_id;
#else
# define PG(v) (core_globals.v)
extern ZEND_API struct _php_core_globals core_globals;
#endif
TSRM/TSRM.h
#define TSRM_UNSHUFFLE_RSRC_ID(rsrc_id) ((rsrc_id)-1)
#define TSRMG(id, type, element)(((type) (*((void ***) tsrm_ls))
[TSRM_UNSHUFFLE_RSRC_ID(id)])-element)
GDB tells me that core_globals_id == 0 which leads to an index of -1 --
if I interpret the results correctly.
Either GDB is wrong or your build is badly broken.
core_globals_id is initialized in main/main.c, line 1491
*rsrc_id = TSRM_SHUFFLE_RSRC_ID(id_count++);
#define TSRM_SHUFFLE_RSRC_ID(rsrc_id) ((rsrc_id)+1)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
On 05/08/2007 01:51 PM, Oliver Block wrote:
Hello Tony,
according to my backtrace, this line (main/main.c:1491) is not processed.
How to reproduce it?
366 if (PG(expose_php)) {
(gdb) p core_globals_id
$4 = 0
The backtrace follows:
Program received signal SIGSEGV, Segmentation fault.
0x40bb4449 in php_apache_add_version (p=0x80a40a8)
at /usr/local/src/php-5.2.2/sapi/apache2handler/sapi_apache2.c:366
366 if (PG(expose_php)) {
(gdb) bt full
#0 0x40bb4449 in php_apache_add_version (p=0x80a40a8)
at /usr/local/src/php-5.2.2/sapi/apache2handler/sapi_apache2.c:366
tsrm_ls = (void ***) 0x83a19b0
#1 0x40bb4537 in php_apache_server_startup (pconf=0x80a40a8, plog=0x80ce150,
ptemp=0x80d0158, s=0x80be308)
at /usr/local/src/php-5.2.2/sapi/apache2handler/sapi_apache2.c:417
data = (void *) 0x1
userdata_key = 0x40c704e7 apache2hook_post_config
#2 0x080691fd in ap_run_post_config ()
No symbol table info available.
#3 0x0806f622 in main ()
No symbol table info available.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 06/05/07, Tijnema ! [EMAIL PROTECTED] wrote: On 5/6/07, David Coallier [EMAIL PROTECTED] wrote: On 5/5/07, Jan Reininghaus [EMAIL PROTECTED] wrote: I am currently working on my second draw for the page, but I have a question. For my first draw I assumed that all of the new features will be available for all three branches, but is this actually true? By the way, I don't know whether you are aware that all build processes of the win32 snapshots have failed for one day now. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Perhaps something like this could be cool: http://dev.agoraproduction.com/php/snaps/ The css might be a bit off as I just wanted to do it quick, but you see the idea :) David Yes, it is quick, as it doesn't work good in IE6, which is the most common browser (http://www.w3schools.com/browsers/browsers_stats.asp) Might be a good alternative for the snaps site, as it is never too larg :) But it should work on IE6 too of course. Tijnema -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php In FF with no JS it looked awful too. I use NoScript which blocks scripts unless I want them to run (whitelist). The Sliding Doors tutorial at http://alistapart.com/articles/slidingdoors/ is all CSS. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
Am Dienstag, 8. Mai 2007 11:55 schrieben Sie: On 05/08/2007 01:51 PM, Oliver Block wrote: Hello Tony, according to my backtrace, this line (main/main.c:1491) is not processed. How to reproduce it? I just compiled the latest php 5 release with zts. I am working on a V-Server with Plesk running SuSE 9.3 (apache 2.0.53. I will search the swsoft website for additional information on compiling php5. Maybe I need to do some additional changes. Regards, Oliver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
On 05/08/2007 03:27 PM, Oliver Block wrote: Am Dienstag, 8. Mai 2007 11:55 schrieben Sie: On 05/08/2007 01:51 PM, Oliver Block wrote: Hello Tony, according to my backtrace, this line (main/main.c:1491) is not processed. How to reproduce it? I just compiled the latest php 5 release with zts. I am working on a V-Server with Plesk running SuSE 9.3 (apache 2.0.53. What was your configure line? I will search the swsoft website for additional information on compiling php5. Maybe I need to do some additional changes. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
Am Dienstag, 8. Mai 2007 13:45 schrieben Sie: What was your configure line? ./configure --with-apxs2=/usr/sbin/apxs2 --prefix=/usr/local/php5 --enable-debug --enable-maintainer-zts --with-mysql --with-imap --with-imap-ssl There was a php4 rpm which was installed by the SuSE setup tool (YaST). After removing it, the server started without problems. So this segmentation fault seems to occur, when there are both versions, php4 and php5, installed. Regards, Oliver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
On 05/08/2007 04:02 PM, Oliver Block wrote: Am Dienstag, 8. Mai 2007 13:45 schrieben Sie: What was your configure line? ./configure --with-apxs2=/usr/sbin/apxs2 --prefix=/usr/local/php5 --enable-debug --enable-maintainer-zts --with-mysql --with-imap --with-imap-ssl There was a php4 rpm which was installed by the SuSE setup tool (YaST). After removing it, the server started without problems. So this segmentation fault seems to occur, when there are both versions, php4 and php5, installed. Ah, so you're compiling a threadsafe PHP to use with a non-threadsafe Apache and loading both PHP4 and PHP5 in the same time. This looks like a total misconfiguration. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
Am Dienstag, 8. Mai 2007 14:12 schrieben Sie: Ah, so you're compiling a threadsafe PHP to use with a non-threadsafe Apache and loading both PHP4 and PHP5 in the same time. This looks like a total misconfiguration. That's right. It was obviously misconfigured! I see no connection to threadsafety php vs. non-threadsafety apache though. Regards, Oliver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
So why don't you come up with a different better solution then? Not breaking streams in php 6? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. So from now on, every time we would want to user stream we'd have to do C extension and all user stream functionality in PHP is just useless? And all that for some weird reincarnation on safe mode again? I don't know how it sounds for you, but form be it sounds really broken way to do things - throwing perfectly good and working userspace streams because of pseudo-security configurations. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. That's fine, the question is why exactly we need fast implementation of PHP_Archive that can be bundled into PHP as a C extension. I see only one reason - to run php code in production out of phar, and I don't think it's a good idea. Any other reasons? Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? In the Maybe if you actually tried to read the arguments instead of dismissing them as bickering you'd actually see why. I brought forward a number of reasons and neither of them was it's of no private use for me. You can do better than this, really. past we have bundeled even stuff that has not been stable or in a mature state. So we should do that more and more, right? More unstable stuff with potential for abuse is great for PHP, isn't it? And I have not seen a single reason against it. The only one close Maybe you should actually read my emails? last time I checked PHP worked nearly perfectly. And last time I had to deal with JARs I did not have the slightest advantage of having it be a ZIP file. Just because in all those Java formats you have to You didn't doesn't mean nobody did. You aren't the only programmer in the universe, you know, and people behind most of the packaging formats seem strangely united in *not* inventing new package formats but reusing old ones with existing tools. I wonder why would that be? the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? Because it's a bad idea. And nobody disallowing that - we just refrain from promoting it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ddb
maintaining the pdo_sqlrelay package -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serialize and cache handling
on every fwrite. And you can not first cache it in memory as you then lose the whole advantage of this idea. IIRC sessions are locked by php anyway, and for other uses if locking is important it is already implemented anyway, so we shouldn't really try to solve all the world's problems with this one. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serialize and cache handling
? Nobody is talking about sessions here, just about the serialize() You mean you are not talking about sessions. I, however, do. Sessions are one of the obvious examples where such functionality could improve performance. function that is also used for a myriad of other things... Oh really? I guess that's why we talk about _adding_ stuff to it in order to make it more efficient *in certain scenarios* and not replacing it with the new one. Precisely the scenarios where external locking would be happening anyway - when either using sessions or caching. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serialize and cache handling
Stanislav Malyshev wrote: ? Nobody is talking about sessions here, just about the serialize() You mean you are not talking about sessions. I, however, do. Sessions are one of the obvious examples where such functionality could improve performance. Well as the topic implies I am quite sure that the user request was about caching into a custom file and not inside the session. Both are frequent use cases. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Passthrough MD5/SHA1 calculation of uploaded files
On Mon, May 07, 2007 at 04:30:28PM -0500, Richard Lynch wrote: Can you PLEASE make 100% certain that this is specifically documented to NOT be a Security Feature and it is NOT intended to indicate secure transmission of the file? It is not meant to be a security feature. Not in the least. Instead, my intent was to make hash computation easier and faster for those (rather common) cases in which signatures are used for duplicate file detection etc.. Cheers, David -- David Santinoli Tieffe Sistemi S.r.l. viale Piceno 21, Milano www.tieffesistemi.com tel. +39 02 45490882 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Passthrough MD5/SHA1 calculation of uploaded files
On Mon, May 07, 2007 at 06:37:29PM -0700, Sara Golemon wrote:
Ditto Richard's comments about false-implications of security, but I'd
also like to add that *IF* folks decide on the whole that this is
worth adding, it should be done more generically than a setting for
md5 and a setting for sha1.
I appreciate your suggestion.
If someone (for some reason) has ext/hash disabled (it's
enabled-by-default since 5.1.2), then they just won't get a hash.
Or, we could resort to ext/standard/{md5|sha1} to make these two hashes
always available, like the Session extension does. But this double
strategy would complicate the code in rfc1867.c and yield very marginal
gain.
If there's enough interest in this, I will rework the patch according to
Sara's hint.
Cheers,
David
--
David Santinoli
Tieffe Sistemi S.r.l. viale Piceno 21, Milano
www.tieffesistemi.com tel. +39 02 45490882
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serialize and cache handling
Well as the topic implies I am quite sure that the user request was about caching into a custom file and not inside the session. Both are frequent use cases. If his cache had no locking before, what changed? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: I think it is a good reason. There are plenty of tool-like PHP applications. Not having to install these, but just be able to I know one - PEAR. And it's kinds special because it's library installer. What others are there? Documentation and other code analyis tools. Database management tools. Code generation tools. Well I think the first two are more likely, code generation tools tend to be very tightly coupled with your actual application. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/8/07, Richard Quadling [EMAIL PROTECTED] wrote: On 06/05/07, Tijnema ! [EMAIL PROTECTED] wrote: On 5/6/07, David Coallier [EMAIL PROTECTED] wrote: On 5/5/07, Jan Reininghaus [EMAIL PROTECTED] wrote: I am currently working on my second draw for the page, but I have a question. For my first draw I assumed that all of the new features will be available for all three branches, but is this actually true? By the way, I don't know whether you are aware that all build processes of the win32 snapshots have failed for one day now. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Perhaps something like this could be cool: http://dev.agoraproduction.com/php/snaps/ The css might be a bit off as I just wanted to do it quick, but you see the idea :) David Yes, it is quick, as it doesn't work good in IE6, which is the most common browser (http://www.w3schools.com/browsers/browsers_stats.asp) Might be a good alternative for the snaps site, as it is never too larg :) But it should work on IE6 too of course. Tijnema -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php In FF with no JS it looked awful too. I use NoScript which blocks scripts unless I want them to run (whitelist). The Sliding Doors tutorial at http://alistapart.com/articles/slidingdoors/ is all CSS. Oh that looks ugly with nocss extension.. also looks bad in lynx/links.. oh yeah, also looks ugly in netscape navigator 1.0B1... but hey.. isn't that 21st century ? so looks good in firefox css/js enabled :) Seriously, what have I misexplained up there ? Was I not clear that the idea was simply to show that we could use tabs IN GENERAL to make the browsing of snaps easier ? We don't need to use javascript, we don't have to use that exact case, the only reason for using it was that it was fast for most people to see what tabs browsing could look like. Here is an optimized version for early browsers: http://dev.agoraproduction.com/php/snaps/snaps2.php Of course this is a joke.. But again to make sure no one misinterprets this, the idea of the tabs using javascript was SIMPLY to show everyone (using firefox of course) that we could make the use of tabs within the snaps site. And NO we do not have to use javascript, and yes we will mostly be using the ?v=44 ?v52 ?v6dev (Note that those names are not relevant, we can use whatever the person that implements it want..) using static tabs. Clear ? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
Antony Dovgal wrote: On 05/08/2007 04:02 PM, Oliver Block wrote: Am Dienstag, 8. Mai 2007 13:45 schrieben Sie: What was your configure line? ./configure --with-apxs2=/usr/sbin/apxs2 --prefix=/usr/local/php5 --enable-debug --enable-maintainer-zts --with-mysql --with-imap --with-imap-ssl There was a php4 rpm which was installed by the SuSE setup tool (YaST). After removing it, the server started without problems. So this segmentation fault seems to occur, when there are both versions, php4 and php5, installed. Ah, so you're compiling a threadsafe PHP to use with a non-threadsafe Apache and loading both PHP4 and PHP5 in the same time. This looks like a total misconfiguration. What non-threadsafe Apache? There are few such Apache 2 beasts. If apr was installed separately it's almost always going to pick up threads by default, and since these are YaST packages I'm betting dollars to donuts that apr comes from it's own rpm. Apache2 itself would therefore be threadsafe compiled against that apr. I'm gambling that PHP4 was non-zts and PHP5 was zts, resulting in mass confusion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On Tue, May 8, 2007 10:30 am, David Coallier wrote: Here is an optimized version for early browsers: http://dev.agoraproduction.com/php/snaps/snaps2.php Works for me. [not a joke] I'd rather have a simple site that works in Mozaic 1.0 than something that only mostly kinda sorta works in current browsers, for somebody's defintion of current jmho -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serialize and cache handling
On Tue, May 8, 2007 1:17 am, Derick Rethans wrote: On Mon, 7 May 2007, Lukas Kahwe Smith wrote: Stanislav Malyshev wrote: can write this data to disk. So, you needs 20MB. If serialize (and of course unserialize) would be able to write directly to disk (or read directly from disk), you only needs 10MB. Actually having serialize/unserialize be able to write directly to a stream and read directly from a stream might be interesting, would probably improve working with things like large sessions or caching large data substantially. Indeed, especially since this is the most common use case. Maybe it should optionally also return an md5 of the written data. If we're to add this, make sure writes to the files are atomic. Is this suggesting that the entire 80M upload has to be done in a single operation?... Or is the md5/sha1 computed chunk by chunk, in parallel, with writing buffered data to the disk? Cuz if it's the former, I don't see that working out too well for ginormous uploaded files... Which people probably shouldn't be doing over HTTP anyway, but they do, and that's the reality one has to deal with... Apologies if I'm being alarmist and totally mis-reading this through my ignorance. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serialize and cache handling
On Tue, 8 May 2007, Richard Lynch wrote: On Tue, May 8, 2007 1:17 am, Derick Rethans wrote: On Mon, 7 May 2007, Lukas Kahwe Smith wrote: Stanislav Malyshev wrote: can write this data to disk. So, you needs 20MB. If serialize (and of course unserialize) would be able to write directly to disk (or read directly from disk), you only needs 10MB. Actually having serialize/unserialize be able to write directly to a stream and read directly from a stream might be interesting, would probably improve working with things like large sessions or caching large data substantially. Indeed, especially since this is the most common use case. Maybe it should optionally also return an md5 of the written data. If we're to add this, make sure writes to the files are atomic. s this suggesting that the entire 80M upload has to be done in a single operation?... Wrong thread ;-) This is on serialize, not on hashes. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Documenting the Zend2 extension API
On May 5, 2007, at 6:47 PM, Gwynne Raskind wrote: On Apr 25, 2007, at 6:51 PM, Antony Dovgal wrote: I've been plugging around writing extensions long enough to have some idea of the internals; more than once I've answered a question by digging through the Zend sources for the internals of some API. Great! I'm willing to at least take a crack at this project; the worst I can do is fail :). Would it make sense to ask for CVS karma on the docs now or wait a bit? I believe the best way to get karma is to start sending patches. I would also recommend to establish the build environment for the docs (if you don't have one already), it's good idea to test patches before committing. This document should give you a good start: http://doc.php.net/php/ dochowto/index.php Hi all, just wanted to give you a heads-up that I'm still working on this project; it took me awhile to get the tools properly set up, but I'm plugging away at DocBook XML now, and I'll have a few patches to send in soon, I think. Thanks for all the advice so far! Hello Gwynne, This is excellent news, and feel free to write the doc list if you have any questions and/or the IRC channels on efnet (#php.pecl and #php.doc). As far as information on the topic goes, let's start a list of the current landscape (with ideas to steal from): - The official docs: http://php.net/manual/internals - CodeGen_PECL: http://pear.php.net/package/codegen_pecl - A few tutorials: http://devzone.zend.com/public/view/tag/extension - The book: Extending and Embedding PHP by Sara Golemon - Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/ - A few talks: http://talks.php.net/index.php/Internals - A nice talk: http://netevil.org/talks/furlong-golemon-extending- php.pdf - More talks: http://talks.somabo.de/ - A nice talk: http://talks.somabo.de/ 200610_zend_conf_php_extension_development.pdf - A few examples: http://people.apache.org/~nabeel/php/examples/ Also, let's create a FAQ section dedicated to the topic of extension writing. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
When I first wrote PHP_Archive the entire point of the stub script was to handle incoming requests, just like the multitude of applications that have everything go through index.php (S9Y for an example). Using Phar with MultiViews and mod_rewrite is just same as funnelling everything through a single regular PHP script, this was one of the design goals and is a very common practice. The main difference here, is with web applications you have non-HTML resources you must also handle - this WILL incur a performance hit over serving them as a static page. But applications like S9Y, FUDForum, phpMyAdmin where the *typical* usage is not to serve a large number of users, this is usually not an issue. These techniques work just fine. - Davey Marcus Boerger wrote: Hello Andi, Friday, May 4, 2007, 9:55:23 PM, you wrote: I think phar is a nice idea but honestly haven't had enough bandwidth to check it out in more detail. Has there been some thorough analysis on the performance impact of it and whether this is the optimal recommended way for our users to distribute apps? The idea is actually very interesting but we should be pretty certain we're doing the right thing before we distribute it. We can spend some time looking at it in more detail. You guys spent a good effort in such analysis in the past. Would be very nice to hear something in that direction from you. Btw, it seems to me that because of the way Apache works for most of our users it actually won't be that useful and just act like a .tar archieve which needs to be extracted. This is unless the user implements some kind of front controller. It would really be nice if we have the 99% common Apache application use-case figured out and docuemnted before we put our PHP dev team weight behind it. Or am I completely missing some magic here? not at all. It perfectly works for includes. But i have no idea how to use it from a url directly...well you can provide some tricks. But i wouldn't recommend those. Andi -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Friday, May 04, 2007 12:44 PM To: Stas Malyshev Cc: Edin Kadribasic; internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Starting 5.3 Hello Stanislav, - you don't need a tool - well php - but hey you probbaly have that tool - you can run phar archives out of the box - untouched - you can extract phar archives and run them - still untouched - you can provide phar archives that do not require a phar extension To your question is phar so important that everybody needs it in the main source. I think the above means it should. best regards marcus Friday, May 4, 2007, 9:36:22 PM, you wrote: obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. I'm personally not sure phar is that great way of distributing apps - it's yet another format not supported by standard tools and I don't really see much of an advantage to using it versus just making a package with any of the existing package formats and I see a number of disadvantages - non-standard format, hard to work with packed scripts with available filesystem tools, etc. But that's my opinion and I fully expect some people to hold exactly the opposite opinion. The question is however is phar so important that everybody needs it in the main source? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: serving them as a static page. But applications like S9Y, FUDForum, phpMyAdmin where the *typical* usage is not to serve a large number of users, this is usually not an issue. In other words, it is not meant to deploy production applications, only local-user applications. Then the question raises again - why exactly we need the module? Low-traffic occasional-use apps do not need top performance, and PHP module should be just enough for them. No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see php.net or yahoo! using phar any time soon, but any site not currently leveraging a bytecode cache would certainly be included. This is the MAJORITY of PHP deployment. Something akin in traffic and use as bugs.php.net could use phar without any detriment (though not knowing what else that particular machine is used for, I wouldn't say to move bugs.php.net itself over, just giving an idea of size and scale :) - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. Because sometimes you like to not waste resources unnecessarily? Maybe because their host only allows default PHP config and doesn't provide PEAR or PECL? - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/8/07, Davey Shafik [EMAIL PROTECTED] wrote: Stanislav Malyshev wrote: No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. Because sometimes you like to not waste resources unnecessarily? Maybe because their host only allows default PHP config and doesn't provide PEAR or PECL? Given that either PHP_Archive or pecl/phar are not required to execute a phar, I really don't see the point here. Now, from a performence point of view, how faster (or less slow) is the extension in comparison to the user land stream implementation? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: I think it is a good reason. There are plenty of tool-like PHP applications. Not having to install these, but just be able to I know one - PEAR. And it's kinds special because it's library installer. What others are there? phpdocumentor, phpunit, phpcodesniffer, peclgen, php_parsergenerator, php_lexergenerator should I continue? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Pierre wrote: I'm in general in favour of phar but I don't think we should start 5.3 for it. I don't think either that it is stable enough to be bundled. I doubt it is possible to have a stable package in only three public releases (even the first public release was already marked stable). FYI, there were two beta releases prior to 1.0.0 stable, with months in between the releases for testing, plus the test coverage at gcov is quite good. Not that these are fantastic indicators of stability as we all know but it is something :) Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Gregory Beaver wrote: Stanislav Malyshev wrote: I think it is a good reason. There are plenty of tool-like PHP applications. Not having to install these, but just be able to I know one - PEAR. And it's kinds special because it's library installer. What others are there? phpdocumentor, phpunit, phpcodesniffer, peclgen, php_parsergenerator, php_lexergenerator should I continue? I also just realized, these are also all tools where you probably do not want APC to store the bytecode in memory. Furthermore it is however still quite useful to have your unit test executing quickly. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Antony, it make it much harder as you would need to load PHP_Archive before you can do anything else with them. It would mean you cannot easily execute them unless they contain PHP_Archive themselves best regards marcus Tuesday, May 8, 2007, 11:39:32 AM, you wrote: On 05/08/2007 01:17 PM, Marcus Boerger wrote: But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. It is not my main argument - not at all. My argument is that it is something that serves a need perfectly and makes the PHP_Archive stuff turned into a fast C extension. Including it would allow to make it a suggested sound and save deployment solution with a bunch of nice additional pros. Please correct me if I'm wrong: phars do work without PECL/phar, don't they? Then why in hell do we need PECL/phar in the core? (except for that streams problem) Because it's faster than PHP_Archive? I don't really care if PEAR install takes 5 seconds or 4 seconds, I can wait one more second once in a month. If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. We have no means at all to support that. And even after years of having PECL I cannot see the slightest aim to solve the issue. All we have right now is to provide stuff that works for experienced admins. Experienced in compiling and automake tools. The only tool required is autoconf (2.13 is recommended, other versions are supported too). All the other tools are required by PHP itself. You don't need to be an experienced admin to install autoconf, this is typical anti-PECL FUD and I'm a bit tired to fight it.. (Btw, Ilia recently proposed to create packages with pre-built configure, so even the autoconf requirement would go). Before we can go in a all to PECL way of doing things we would need to reduce the number of completely incompatible builds (ZTS, debug, ZTS-debug, normal). I'm not sure I understand what you're talking about. We never provided debug binary builds and I see no reasons to do it. Andwewould have to decide on a sane pugable API. Okay, let's do it. We have a nice chance to break everything we can - it's PHP6 anyway =) I'd really like to hear your thoughts on improving the API. Want to make a separate thread? One that does not change from version to version. Not even additions would be allowed. All would have to be done via callbacks. And eventually with struct versioning. But we do not even allow a TODO discussion board on php.net somewhere nor did we ever respect our own TODOs. This IS the discussion board. So how is this ever going to happen? So infact if we like something we can either bundle it or have it die. Ok, so let me summarize it: to leave PECL/phar in PECL you need a new pluggable API, and to create the API you need a discussion board, but even having it you would not discuss the API because nobody respects TODOs. Did I miss something? In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? Phar is stable. All I said is that we won't do the same mistake again. PECL/json, PECL/zip and the others were/are stable too. That doesn't mean there are no bugs we don't know of. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
I also just realized, these are also all tools where you probably do not want APC to store the bytecode in memory. Furthermore it is however still quite useful to have your unit test executing quickly. How speed of the tests would depend on speed of the loading phpunit runner? I don't believe reading a couple of files phpunit runner needs with PHP would do much difference compared to reading same files with C. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: I also just realized, these are also all tools where you probably do not want APC to store the bytecode in memory. Furthermore it is however still quite useful to have your unit test executing quickly. How speed of the tests would depend on speed of the loading phpunit runner? I don't believe reading a couple of files phpunit runner needs with PHP would do much difference compared to reading same files with C. Yes, of course if you are looking to run 1 hour worth of unit tests, the initial load up time is not relevant. But if you just want to quickly run the tests that you feel are most likely affected, the start up time is relevant. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/09/2007 02:00 AM, Marcus Boerger wrote: Hello Antony, it make it much harder as you would need to load PHP_Archive before you can do anything else with them. It would mean you cannot easily execute them unless they contain PHP_Archive themselves It's harder for those who create phars, but there is no difference for those who use phars. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Pierre, Tuesday, May 8, 2007, 10:59:08 PM, you wrote: On 5/8/07, Davey Shafik [EMAIL PROTECTED] wrote: Stanislav Malyshev wrote: No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. Because sometimes you like to not waste resources unnecessarily? Maybe because their host only allows default PHP config and doesn't provide PEAR or PECL? Given that either PHP_Archive or pecl/phar are not required to execute a phar, I really don't see the point here. There is no reason to have PHP_Archive in a phar. No need whatsoever... it would be a waste of space! Not having the extension would lead to a situation where practically every phar would have to include the PHP_Archive.Which would be suboptimal. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. So from now on, every time we would want to user stream we'd have to do C extension and all user stream functionality in PHP is just useless? And all that for some weird reincarnation on safe mode again? I don't know how it sounds for you, but form be it sounds really broken way to do things - throwing perfectly good and working userspace streams because of pseudo-security configurations. Hi, I'd like to remind everyone that I brought up this issue when it was originally proposed to make userspace streams always remote and to disable allow_url_fopen/allow_url_include. This was in the days when Esser was still around, to put it in context. The only solution that would allow userspace streams to function *and* allow security would be to implement safe_mode 2.0: disable all remote access functions when inside a streams handler. The implementation is actually quite simple on the surface, but immensely complex in reality, as it would require combing through every internal PHP function or class that can possibly access the outside world, and disabling it. Otherwise users will be able to circumvent all_url_fopen by writing a simple stream wrapper that just downloads the crap and returns it as an $fp. However, could we take another look at the purpose of allow_url_include/fopen? Isn't it to prevent stupid users from shooting themselves in the foot with code like: ?php $a = fopen($_GET['dumbidea']); include $_GET['waystupididea']; ? allow_url_include/allow_url_fopen do not prevent users from downloading code and executing it intentionally, this is the job of a firewall. I know the idea of a taint mode was sort of discarded (I think it was, that was one lng thread), but realistically, this is probably the better way to a more secure fopen and include without a more difficult safe mode-esque solution. All security experts say security is a tradeoff between convenience and safety, and the convenience of userspace stream wrappers will simply disappear in the name of the safety of preventing remote code execution vulnerabilities. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
There is no reason to have PHP_Archive in a phar. No need whatsoever... it would be a waste of space! Not having the extension would lead to Yes, the whole whopping 20K of space uncompressed and with comments, so could be probably 10K or less without comments, whitespace and minimized for extraction. Serious waste of bandwidth worth discussing. a situation where practically every phar would have to include the PHP_Archive.Which would be suboptimal. That would be suboptimal if we suppose everybody uses phar archives. Since it is not the case and most apps would neither run in phars nor require to be run from phars without extraction, optimizing PHP for use in these use cases in not necessary. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
The only solution that would allow userspace streams to function *and* allow security would be to implement safe_mode 2.0: disable all remote No, that's not the only solution. Other solution would be stop trying to do what should be done on entirely other level and do it on the OS level, not try to make PHP what it is not - PHP is not built to securely limit the programmer and all attempts to do that eventually lead to the same problems safe_mode had. Or worse, if they break perfectly good code on the way. that can possibly access the outside world, and disabling it. Otherwise users will be able to circumvent all_url_fopen by writing a simple stream wrapper that just downloads the crap and returns it as an $fp. I say if you don't want your users to contact outside world, buy a firewall. allow_url_include was intended to serve very specific purpose, to plug hole created by often-written stupid code. It's not a comprehensive security solution and was not intended to restrict the programmer. I know the idea of a taint mode was sort of discarded (I think it was, Actually, AFAIK it wasn't :) disappear in the name of the safety of preventing remote code execution vulnerabilities. There would be no safety and no prevention, just plugging one way of thousands. IMHO it is pointless. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: There is no reason to have PHP_Archive in a phar. No need whatsoever... it would be a waste of space! Not having the extension would lead to Yes, the whole whopping 20K of space uncompressed and with comments, so could be probably 10K or less without comments, whitespace and minimized for extraction. Serious waste of bandwidth worth discussing. Yeah, I do not think that the size is really that big of an issue in this case. It would just be a code management inconvenience (having to update the same thing in all your applications, which requires downloading an new version of the application in its entirety etc.). @Greg: Do you have any benchmark result ready to compare the difference in start up cost? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
