Re: [PHP-DEV] PHP 4.5.x-dev

2003-03-03 Thread Sascha Schumann
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

2003-03-03 Thread Sebastian Bergmann
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

2003-03-03 Thread Derick Rethans
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

2003-03-03 Thread Alexey Borzov
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

2003-03-03 Thread Marcus Börger
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

2003-03-03 Thread Sascha Schumann
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

2003-03-03 Thread Edin Kadribasic
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

2003-03-03 Thread Peter Kmet
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

2003-03-03 Thread Edin Kadribasic
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)

2003-03-03 Thread Michael Mauch
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

2003-03-03 Thread Jani Taskinen

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

2003-03-03 Thread Rasmus Lerdorf
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