Re: [PHP-DEV] PHP 4.5.x-dev
On Mon, 3 Mar 2003, Harald Radi wrote: sorry for this naive question, i just realized that we have php 4.5.x snapshots on snaps.php.net, i assume this is the PHP_4 branch. does that mean that PHP_4_3 and PHP_4 should kept synchronized ? Yes, general fixes can be committed to the PHP_4 branch. is there also a PHP_4 branch in the Zend module or ist HEAD supposed to be PHP_4 ? There is also a PHP_4 branch in the Zend module, so a regular $ cd php4 $ cvs upd -r PHP_4 works. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.5.x-dev
Harald Radi wrote: PHP_4 But why is the version of the PHP_4 branch 4.5, and not 4.4? -- 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] PHP 4.5.x-dev
On Mon, 3 Mar 2003, Harald Radi wrote: sorry for this naive question, i just realized that we have php 4.5.x snapshots on snaps.php.net, i assume this is the PHP_4 branch. does that mean that PHP_4_3 and PHP_4 should kept synchronized ? is there also a PHP_4 branch in the Zend module or ist HEAD supposed to be PHP_4 ? There won't be a release done from this branch, so it's not needed to synchronise it. AFAIK it was only added because Sascha (and perhaps others, I forgot) wanted to continue some small development for the PHP 4.x series without screwing with the stable 4.3.x branch. Derick -- Stop mad cowboy disease! - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: avb
Working on PEAR and PEAR documentation. PEAR account already approved: http://pear.php.net/account-info.php?handle=avb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: INI defaults for CLI
At 02:45 03.03.2003, [EMAIL PROTECTED] wrote: Nothing attached... Try again... Index: main/SAPI.h === RCS file: /repository/php4/main/SAPI.h,v retrieving revision 1.100 diff -u -r1.100 SAPI.h --- main/SAPI.h 20 Feb 2003 22:21:48 - 1.100 +++ main/SAPI.h 3 Mar 2003 00:13:21 - @@ -241,6 +241,8 @@ int (*get_target_gid)(gid_t * TSRMLS_DC); unsigned int (*input_filter)(int arg, char *var, char **val, unsigned int val_len TSRMLS_DC); + + void (*ini_defaults)(HashTable *configuration_hash); }; Index: main/php_ini.c === RCS file: /repository/php4/main/php_ini.c,v retrieving revision 1.117 diff -u -r1.117 php_ini.c --- main/php_ini.c 28 Feb 2003 20:48:38 - 1.117 +++ main/php_ini.c 3 Mar 2003 00:13:21 - @@ -276,6 +276,10 @@ return FAILURE; } + if (sapi_module.ini_defaults) { + sapi_module.ini_defaults(configuration_hash); + } + zend_llist_init(extension_lists.engine, sizeof(char *), (llist_dtor_func_t) free_estring, 1); zend_llist_init(extension_lists.functions, sizeof(zval), (llist_dtor_func_t) ZVAL_DESTRUCTOR, 1); zend_llist_init(scanned_ini_list, sizeof(char *), (llist_dtor_func_t) free_estring, 1); Index: sapi/cli/php_cli.c === RCS file: /repository/php4/sapi/cli/php_cli.c,v retrieving revision 1.71 diff -u -r1.71 php_cli.c --- sapi/cli/php_cli.c 16 Feb 2003 01:23:11 - 1.71 +++ sapi/cli/php_cli.c 3 Mar 2003 00:13:21 - @@ -277,6 +277,29 @@ } +/* {{{ sapi_cli_ini_defaults */ + +#define INI_DEFAULT(name,name_len,value)\ + ZVAL_STRING(tmp, value, 0);\ + zend_hash_update(configuration_hash, name, name_len, tmp, sizeof(zval), (void**)entry);\ + Z_STRVAL_P(entry) = zend_strndup(Z_STRVAL_P(entry), Z_STRLEN_P(entry)) + +static void sapi_cli_ini_defaults(HashTable *configuration_hash) +{ + zval *tmp, *entry; + + MAKE_STD_ZVAL(tmp); + + INI_DEFAULT(register_argc_argv, 19, 1); +/* INI_DEFAULT(register_long_arrays, 21, 1);*/ + INI_DEFAULT(html_errors, 12, 1); + INI_DEFAULT(implicit_flush, 15, 1); + INI_DEFAULT(max_execution_time, 19, 0); + + FREE_ZVAL(tmp); +} +/* }}} */ + /* {{{ sapi_module_struct cli_sapi_module */ static sapi_module_struct cli_sapi_module = { @@ -526,6 +549,7 @@ tsrm_startup(1, 1, 0, NULL); #endif + cli_sapi_module.ini_defaults = sapi_cli_ini_defaults; sapi_startup(cli_sapi_module); #ifdef PHP_WIN32 @@ -576,10 +600,6 @@ /* Set some CLI defaults */ SG(options) |= SAPI_OPTION_NO_CHDIR; - zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); - zend_alter_ini_entry(html_errors, 12, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); - zend_alter_ini_entry(implicit_flush, 15, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); - zend_alter_ini_entry(max_execution_time, 19, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_uv.html_errors = 0; /* tell the engine we're in non-html mode */ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.5.x-dev
On Mon, 3 Mar 2003, Sebastian Bergmann wrote: Harald Radi wrote: PHP_4 But why is the version of the PHP_4 branch 4.5, and not 4.4? 4.4 was used already in HEAD for some time. So we skipped it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: INI defaults for CLI
Hi Marcus, This patch looks fine to me, but I have the same reservations as you in that I'm not sure if we really need to modify the current behavior. IIRC it was Markus who objected to the way CLI overrode some default ini settings in a way that php.ini entries were ignored. You could still change them with -d command line switch. I'm sort of +0.5 for applying this patch if no other objections surface. If it gets applied we're probably best of commenting out relevant php.ini-dist and php.ini-recommended entries and noting in the commend what are defaults. Edin On Monday, Mar 3, 2003, at 11:40 Europe/Copenhagen, Marcus Börger wrote: At 02:45 03.03.2003, [EMAIL PROTECTED] wrote: Nothing attached... Try again... 20030303-1.diff.txt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php_pgsql.dll problem
Hello, i'm trying to use php with postgres on win32 i have found some problems with php 4.3.1 (same for php 4.3.0) and php_pgsql.dll. When i try to load php_pgsql.dll extension in php.ini i get error notice PHP Warning: Unknown(): Unable to load dynamic library 'C:\Program Files\php\extensions\php_pgsql.dll' - The specified procedure could not be found. file php_pgsql.dll exists. I have found on internet that this problem can be caused by missing libpq.dll from postgres distribution so i downloaded postgresql-7.3.1 and compiled with VC5.0 interface libpq and copied libpq.dll and libpq.lib and copied it to winnt/system32 folder (i tried php dll extensions dir as well) but i still have same warning and pg_* functions are not avilable. Your help is very appreciated Peter Kmet -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_pgsql.dll problem
php_pgsql.dll does not depend on external libpq.dll (its built in statically). Your problem is most probably in the local install, ie. a stale php4ts.dll somewhere. Edin On Mon, 3 Mar 2003, Peter Kmet wrote: Hello, i'm trying to use php with postgres on win32 i have found some problems with php 4.3.1 (same for php 4.3.0) and php_pgsql.dll. When i try to load php_pgsql.dll extension in php.ini i get error notice PHP Warning: Unknown(): Unable to load dynamic library 'C:\Program Files\php\extensions\php_pgsql.dll' - The specified procedure could not be found. file php_pgsql.dll exists. I have found on internet that this problem can be caused by missing libpq.dll from postgres distribution so i downloaded postgresql-7.3.1 and compiled with VC5.0 interface libpq and copied libpq.dll and libpq.lib and copied it to winnt/system32 folder (i tried php dll extensions dir as well) but i still have same warning and pg_* functions are not avilable. Your help is very appreciated Peter Kmet -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for OCI8 link failure (Tru64/AIX) (#22324)
Hi, my older patch for the link problems with OCI8 on Tru64 broke the build on AIX and maybe other systems, so Jani commented it out. Here comes a better patch. Instead of just linking to libocijdbc8/9 if it is available, it tries to find the OCILobIsTemporary function in the normal libclntsh first, and does nothing if it's there. Only if OCILobIsTemporary is not in libclntsh, another check is done to search it in libocijdbc8/9. I tested it on Linux with Oracle 8.1.6, Tru64 with 8.1.6, 8.1.7 and 9.0.1, and made sure that libocijdb8/9 is linked only when necessary. The patch is not yet tested on AIX, though. I'll ask the two people who reported bug #22324 after the patch has been applied (or should I ask them before the patch is applied, and send them the new configure and main/php_config.h.in built here?). Just before posting this, I became aware that at least here (Linux, Oracle 8.1.6), the line AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) results in a core dump at startup, if I use --with-oci8=shared. This is a separate problem (#22521), it also happens without my patch. Setting OCI_USE_EMALLOC to 1 in oci8.c doesn't change it. Regards... Michael Index: ext/oci8/config.m4 === RCS file: /repository/php4/ext/oci8/config.m4,v retrieving revision 1.37.2.3 diff -u -B -b -r1.37.2.3 config.m4 --- ext/oci8/config.m4 25 Feb 2003 04:37:08 - 1.37.2.3 +++ ext/oci8/config.m4 3 Mar 2003 20:45:03 - @@ -89,14 +89,20 @@ 8.1) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least). -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + php_save=$LDFLAGS + LDFLAGS=-L$OCI8_DIR/lib $LDFLAGS + AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [ +AC_CHECK_LIB(ocijdbc8, OCILobIsTemporary, [ + PHP_ADD_LIBRARY_WITH_PATH(ocijdbc8, $OCI8_DIR/lib, OCI8_SHARED_LIBADD) +], [ ]) + ]) + LDFLAGS=$php_save + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) - AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) + + dnl AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) dnl dnl OCI_ATTR_STATEMENT is not available in all 8.1.x versions @@ -107,12 +113,17 @@ 9.0) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least) -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + php_save=$LDFLAGS + LDFLAGS=-L$OCI8_DIR/lib $LDFLAGS + AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [ +AC_CHECK_LIB(ocijdbc9, OCILobIsTemporary, [ + PHP_ADD_LIBRARY_WITH_PATH(ocijdbc9, $OCI8_DIR/lib, OCI8_SHARED_LIBADD) +], [ ]) + ]) + LDFLAGS=$php_save + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tie'ing variables
Can't those long names be gone in PHP 5 anyway..? Having YASIO is not fun. :) --Jani On Sun, 2 Mar 2003, Zeev Suraski wrote: I wanted to do this for some time, but until recently, it wasn't very feasible, because the order of registration could be designated by the user (gpc_order, variables_order, etc.). Now that register_globals is off by default, and that we have the auto-globals, it's much more feasible. I implemented this optimization in CVS, so far only for $_ENV and $_SERVER. This alone pushed nearly-empty-page req/sec pages from about 285 to about 400 on my Windows box. I'll look into fixing the other ones later. Pre-requisites for this optimization to kick in: 1. register_globals being off 2. register_long_arrays (HTTP_*_VARS) being off If you want to benchmark w/ vs. w/o, you can disable the optimization by initializing cb to 0 in php_startup_auto_globals() and jit_initialization to 0 in php_hash_environment(), both in main/php_variables.c. Zeev At 18:26 01/03/2003, Sterling Hughes wrote: Hi, Analyzing PHP's routines a bit, it seems that the slowest part of a generic request is populating the special arrays, $_ENV, $_GET, etc. I was wondering if it might be possible to tie these arrays to a function (if you don't understand that, look at Perl for a definition). One could populate them as an overloaded object, and then array accesses would work - I guess. But I would prefer a cleaner mechanism. This would prevent a costly overhead for elements that don't really need to be there, and yield only a slight performance cost when accessing overloaded elements in these arrays. -Sterling -- The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs. - Joseph Weizenbaum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #22527 [Opn-Bgs]: Modulus returned negative value
This is actually an interesting question. Should we be truncating towards zero? I'd say yes, but then I tested Perl, Python and Tcl, and they all say that -27 % 7 is 1 which means they truncate towards negative infinity. Too late to change at this point in the game, but perhaps it calls for a modulus() function which leans the other way? -Rasmus On Mon, 4 Mar 2003 [EMAIL PROTECTED] wrote: ID: 22527 Updated by: [EMAIL PROTECTED] Reported By: jaypedhskr at aol dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Unix PHP Version: 4.2.3 New Comment: Modulus has never been well-defined for negative values in computer languages. It all comes down to whether the language truncates towards zero or towards negative infinity. Computers have traditionally truncated towards zero, whereas mathematicians tend to truncate towards negative infinity. Some languages like Fortran and Ada actually have two different modulus operators for this reason. PHP just has one, and it truncates towards zero as has been the traditional and expected thing for programming languages to do. So, given that, let's look at your numbers. Modulus has to satisfy the relation: (a/b)*b + a%b = a where a/b is an integer division where our truncation direction comes in. (-27/7) * 7 + -27%7 = -27 ( -3 ) * 7 + -27%7 = -27 -21 + -27%7 = -27 -27%7 = -27+21 -27%7 = -6 In fact, the ISO standard for the C programming language, in which PHP is written, defines integer division and modulus operators to perform truncation towards 0 and not towards negative infinity. We don't really have a strict language definition for PHP, but if we did, we would most likely follow the lead of languages like Fortran, C and C++ and specify truncation towards zero to be as consistent as possible with other languages. Previous Comments: [2003-03-03 22:29:46] jaypedhskr at aol dot com Hi, I had the following result from a PHP script, as seen from printing output variables: -27 % 7 == -6 My understanding of the modulus function is that it returns the remainder from division, and that the remainder can never be negative. I believe that is the standard mathematical definition. So I think what should have been returned is 1 instead of -6. That is -27 = 7*(-4) + 1 instead of -27 = 7*(-3) -6 I got around this by adding the the modulus value if the result was less than zero. But I think a result of less than zero shouldn't occur. Code snippet that ran into this: $T5 = $D + $T1 + $Y + $T2 + $T3 - $T4; $weekday = $T5 % 7; Added code to handle this: if ($weekday 0) { $weekday += 7; // -27 % 7 = -6 case } Specific problem case: $T5 = 3 + 2 + 3 + 5 + 0 - 40; // -27 $weekday = %T5 % 7; // -27 % 7 = -6 Thanks! -Jay Pedersen -- Edit this bug report at http://bugs.php.net/?id=22527edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php