Re: [PHP-DEV] Moderate PHP-DEV
Shane Caraveo wrote: Then another item that might be considered if it is not already done, allowing posts only from those that have cvs access. A second conditional list of allowed posters can be added that are people who do not have cvs access, but we want to allow to post. Otherwise, the list can be readable by all. A post rejected message could tell them to try a different email list, but if they really feel the email is for the dev list, send it to [EMAIL PROTECTED] and it will be reviewed by someone when they get the time. I think there are a lot of members like myself who watch this list and on some occasions post a new note or followup to one of the main members comments. But without any CVS access. Having us ask for special permission or send posts through a special moderator seems a little heavy handed to me. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
I would be very interested. And not just for PHP, tho I would like to see a PHP function for it. We have several apps that are currently obtaining the GMT offset the old-fashion way. 1. Set the TZ=GMT, perform a mktime call. 2. Set TZ to local timezone, perform the same mktime call. 3. Subtract the 2 timestamps. 4. Reset TZ back to its standard value. If you properly set the dst param, the result will be the time difference between the two timezones for whatever date/time you want. As ugly as this seems (and I do agree its ugly), it actually works very well, stable, and performs pretty fast. Our apps perform this sequence tens of thousands times per day at least. I always felt if I had the time I'd try and re-write it to do something along the same you describe, but never got there. Brian David Gillies wrote: In a similar itch-scratching moment I whipped up a trivial PHP module that groks tzfile timezone files to give you the offset from GMT at any time in the Unix epoch. I needed this to preflight a bunch of data which had been gathered with a lot of disparate time zones into a single UTC version, but I thought it might merit further dissemination. Anyone interested? Best Wishes David Gillies San Jose Costa Rica sunrise() - sunset() functions __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sybase_ct and tli lib
I have a little more info to add. Our DBA opened a question to Sybase Tech support and received the following reply: The tli library was the Sybase network driver on Solaris. Since we had customers facing CR 186487, which arose from Sun Bug 1218173, a request for an interrupt-safe malloc() that Sun had decided not to fix, Sybase switched to the socket based driver, libinsck, on Solaris with OC 12.0 and EBF #4. It is possible that some component in your environment uses this tli library or a libtcl from a version of 12.0 netlib (libtcl) that used to look for libtli.so. When you start as 'root' maybe it picks up a different version and/or uses different environment variables that control the load library path. Nevertheless, from what this sounds there is definitely some sort of mismatch between the version used to build the webserver and the version currently in the load library path. I agree with his assessment that somehow, our root user is getting a different run path, but frankly I can't find it. Anyway, it seems that there is a sizeable amount of evidense that libtli should be linked on all Solaris builds if its present. Which agrees with most of my experience. Hope this helps. Brian Brian Foddy wrote: Timm Friebe wrote: On Wed, 2002-11-13 at 18:03, Brian Foddy wrote: Timm, I've seen it used for 10 years on Solaris, and I spent about a year working on Irix and Informix, and there were some references to it there also. strings libtli.so | grep ^Sybase Sybase TCP/IP TLI Library/12.0/P/SPARC/Solaris 2.5.1/1/OPT/Sat Sep 25 21:07:40 1999 Sybase, Inc. All rights reserved. Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608, USA OK, so it should probably be added for those systems. A line like this should be added to config.m4 (wrapped for readability), could you provide the second parameter here: PHP_CHECK_LIBRARY( tli, ---???---, [PHP_ADD_LIBRARY(tli,,SYBASE_CT_SHARED_LIBADD)], [], [-L$SYBASE_CT_LIBDIR] ) or is maybe the pure existance of this file enough: I'm not familiar with what the second arg of this macro does. In our environment, which I've work on Solaris/Sybase for 10 yrs, we always include it by default. thekidfriebes:~/devel/php/php4 cvs diff ext/sybase_ct/config.m4 Index: ext/sybase_ct/config.m4 === RCS file: /repository/php4/ext/sybase_ct/config.m4,v retrieving revision 1.11 diff -u -r1.11 config.m4 --- ext/sybase_ct/config.m4 12 Mar 2002 16:36:30 - 1.11 +++ ext/sybase_ct/config.m4 14 Nov 2002 12:07:33 - -44,7 +44,11 ],[ $SYBASE_CT_LIBS ]) - + +if test -f $SYBASE_CT_LIBDIR/libtli.so ; then + PHP_ADD_LIBRARY(tli,, SYBASE_CT_SHARED_LIBADD) + SYBASE_CT_LIBS=$SYBASE_CT_LIBS -ltli +fi This looks fine. I still wish I knew why it seems to work with root permissions, and not with sudo; and in general knew more about this bugger. Maybe I'll just ask our Sybase DBA to open a case with Sybase and get the official answer. If I hear more, I'll pass it along. Thanks, Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sybase_ct and tli lib
Timm Friebe wrote: On Wed, 2002-11-13 at 18:03, Brian Foddy wrote: Timm, I've seen it used for 10 years on Solaris, and I spent about a year working on Irix and Informix, and there were some references to it there also. strings libtli.so | grep ^Sybase Sybase TCP/IP TLI Library/12.0/P/SPARC/Solaris 2.5.1/1/OPT/Sat Sep 25 21:07:40 1999 Sybase, Inc. All rights reserved. Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608, USA OK, so it should probably be added for those systems. A line like this should be added to config.m4 (wrapped for readability), could you provide the second parameter here: PHP_CHECK_LIBRARY( tli, ---???---, [PHP_ADD_LIBRARY(tli,,SYBASE_CT_SHARED_LIBADD)], [], [-L$SYBASE_CT_LIBDIR] ) or is maybe the pure existance of this file enough: I'm not familiar with what the second arg of this macro does. In our environment, which I've work on Solaris/Sybase for 10 yrs, we always include it by default. thekidfriebes:~/devel/php/php4 cvs diff ext/sybase_ct/config.m4 Index: ext/sybase_ct/config.m4 === RCS file: /repository/php4/ext/sybase_ct/config.m4,v retrieving revision 1.11 diff -u -r1.11 config.m4 --- ext/sybase_ct/config.m4 12 Mar 2002 16:36:30 - 1.11 +++ ext/sybase_ct/config.m4 14 Nov 2002 12:07:33 - -44,7 +44,11 ],[ $SYBASE_CT_LIBS ]) - + +if test -f $SYBASE_CT_LIBDIR/libtli.so ; then + PHP_ADD_LIBRARY(tli,, SYBASE_CT_SHARED_LIBADD) + SYBASE_CT_LIBS=$SYBASE_CT_LIBS -ltli +fi This looks fine. I still wish I knew why it seems to work with root permissions, and not with sudo; and in general knew more about this bugger. Maybe I'll just ask our Sybase DBA to open a case with Sybase and get the official answer. If I hear more, I'll pass it along. Thanks, Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sybase_ct and tli lib
Timm, I've seen it used for 10 years on Solaris, and I spent about a year working on Irix and Informix, and there were some references to it there also. strings libtli.so | grep ^Sybase Sybase TCP/IP TLI Library/12.0/P/SPARC/Solaris 2.5.1/1/OPT/Sat Sep 25 21:07:40 1999 Sybase, Inc. All rights reserved. Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608, USA [EMAIL PROTECTED]:/apps/soc/sybase/OCS-12_0/lib - ll total 36696 drwxrwxr-x 2 a26811 socdev 1024 Mar 18 2001 ./ drwxrwxr-x 12 a26811 socdev 1024 Jul 31 2001 ../ -rw-r--r-- 1 a26811 socdev170568 May 11 2000 libblk.a -rw-r--r-- 1 a26811 socdev173848 May 11 2000 libblk_r.a -rw-r--r-- 1 a26811 socdev 76124 May 11 2000 libcobct.a -rw-r--r-- 1 a26811 socdev 76668 May 11 2000 libcobct_r.a -rw-r--r-- 1 a26811 socdev767616 May 11 2000 libcomn.a -rwxr-xr-x 1 a26811 socdev635092 May 11 2000 libcomn.so* -rw-r--r-- 1 a26811 socdev793024 May 11 2000 libcomn_r.a -rwxr-xr-x 1 a26811 socdev657152 May 11 2000 libcomn_r.so* -rw-r--r-- 1 a26811 socdev125888 May 11 2000 libcs.a -rwxr-xr-x 1 a26811 socdev102180 May 11 2000 libcs.so* -rw-r--r-- 1 a26811 socdev133676 May 11 2000 libcs_r.a -rwxr-xr-x 1 a26811 socdev108564 May 11 2000 libcs_r.so* -rw-r--r-- 1 a26811 socdev 1057028 May 11 2000 libct.a -rwxr-xr-x 1 a26811 socdev826260 May 11 2000 libct.so* -rw-r--r-- 1 a26811 socdev 1086080 May 11 2000 libct_r.a -rwxr-xr-x 1 a26811 socdev853104 May 11 2000 libct_r.so* -rwxr-xr-x 1 a26811 socdev 46496 May 11 2000 libddce.so* -rw-r--r-- 1 a26811 socdev 84572 May 11 2000 libintl.a -rwxr-xr-x 1 a26811 socdev 65468 May 11 2000 libintl.so* -rw-r--r-- 1 a26811 socdev 88360 May 11 2000 libintl_r.a -rwxr-xr-x 1 a26811 socdev 69144 May 11 2000 libintl_r.so* -rwxr-xr-x 1 a26811 socdev 23016 May 11 2000 libsdce.so* -rwxr-xr-x 1 a26811 socdev 23612 May 11 2000 libskrb.so* -rw-r--r-- 1 a26811 socdev 3072280 May 11 2000 libsmapp.a -rwxr-xr-x 1 a26811 socdev881656 May 11 2000 libsrv.so* -rwxr-xr-x 1 a26811 socdev917412 May 11 2000 libsrv_r.so* -rw-r--r-- 1 a26811 socdev 1852908 May 11 2000 libsybdb.a -rwxr-xr-x 1 a26811 socdev 1409796 May 11 2000 libsybdb.so* -rw-r--r-- 1 a26811 socdev550128 May 11 2000 libtcl.a -rwxr-xr-x 1 a26811 socdev428108 May 11 2000 libtcl.so* -rw-r--r-- 1 a26811 socdev561080 May 11 2000 libtcl_r.a -rwxr-xr-x 1 a26811 socdev440548 May 11 2000 libtcl_r.so* -rwxr-xr-x 1 a26811 socdev 28032 May 11 2000 libtli.so* -rwxr-xr-x 1 a26811 socdev 22080 May 11 2000 libtli_r.so* -rw-r--r-- 1 a26811 socdev317032 May 11 2000 libxadtm.a -rwxr-xr-x 1 a26811 socdev244392 May 11 2000 libxadtm.so* [EMAIL PROTECTED]:/apps/soc/apache/libexec - ldd libphp4.so libdl.so.1 =/usr/lib/libdl.so.1 libpam.so.1 = /usr/dt/lib/libpam.so.1 libtcl.so = /apps/soc/sybase/OCS-12_0/lib/libtcl.so libtli.so = /apps/soc/sybase/OCS-12_0/lib/libtli.so libintl.so =/apps/soc/sybase/OCS-12_0/lib/libintl.so libcomn.so =/apps/soc/sybase/OCS-12_0/lib/libcomn.so libct.so = /apps/soc/sybase/OCS-12_0/lib/libct.so libcs.so = /apps/soc/sybase/OCS-12_0/lib/libcs.so libldap.so.4 = /usr/lib/libldap.so.4 libcrypt_i.so.1 = /usr/lib/libcrypt_i.so.1 libresolv.so.2 =/usr/lib/libresolv.so.2 libm.so.1 = /usr/lib/libm.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libc.so.1 = /usr/lib/libc.so.1 libucb.so.1 = /usr/ucblib/libucb.so.1 libelf.so.1 = /usr/lib/libelf.so.1 libgen.so.1 = /usr/lib/libgen.so.1 libmp.so.2 =/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 All the Sybase libs are coming from the same version/directory. I'm doing a system search for other possible locations of these libs, but I don't think there are any. Brian Timm Friebe wrote: Make sure you don't have any old libraries that are you used when compiling PHP. For instance, run ldd /path/to/where/php/is/php or ldd /path/to/where/phpmodule/is/libphp4.so and check which libct.so is linked. Locate all libct.so files on your hard drive and check which is one is in your LD_LIBRARY_PATH. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Sybase_ct and tli lib
The following is not really worthy of reporting an official bug, but still worthy of at least comment and notice. On Solaris 2.8 using Sybase OCS-12, the default build scripts for PHP 4.2.3 will not link in the tli library. Those familiar with Sybase have probably stubbed their toes on this library several times before; I've certainly have. When PHP is built and run using Apache 1.3.2x. When the web server is started as a real root user, everything works fine. However in our environment we don't have production root access, so we have to use sudo or the SUID bit to start the web server as root. I found that without this library linked in, the web server would start (with sudo/suid) but the following error would be reported in the apache error log: Open Client Message: Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131) Message String: ct_init(): network packet layer: internal net library error: Attempt to load protocol driver failed And of course no Sybase connections would work. When I linked in the tli library, everything thing ok. I've attached a simple diff of the sybase_ct/config.m4 that I used to get the tli library included. I will be the first to admit, I really don't know why this library (or its absense) causes this behavior, nor do I really fully understand what the lib is supposed to do. If someone can explain it to me, please try. Otherwise, I just try to remember this error message is usually related to the presents/absense of the tli library. Anyway I thought I would post this info in hopes it might lead to a better solution in the future. Thanks, Brian PS: my configure line is: ./configure --with-apxs=/apps/soc/apache/bin/apxs \ --prefix=/apps/soc/apache/php4 --with-sybase-ct=/apps/soc/sybase/OCS-12_0 \ --enable-track-vars --with-config-file-path=/apps/soc/apache/php4 \ --enable-trans-sid --with-ldap *** ext/sybase_ct/config.m4 Fri Nov 30 22:12:31 2001 *** *** 34,41 PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) ! SYBASE_CT_LIBS=-L$SYBASE_CT_LIBDIR -lcs -lct -lcomn -lintl PHP_CHECK_LIBRARY(tcl, netg_errstr, [ PHP_ADD_LIBRARY(tcl,,SYBASE_CT_SHARED_LIBADD) --- 34,42 PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) + PHP_ADD_LIBRARY(tli,, SYBASE_CT_SHARED_LIBADD) ! SYBASE_CT_LIBS=-L$SYBASE_CT_LIBDIR -lcs -lct -lcomn -lintl -ltli PHP_CHECK_LIBRARY(tcl, netg_errstr, [ PHP_ADD_LIBRARY(tcl,,SYBASE_CT_SHARED_LIBADD) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[Fwd: Re: [PHP-DEV] PHP's vision]
I admit I haven't been following this thread closely, but I agree and don't think PHP should be trying to write a transaction system itself. I do think it should try to interface with existing systems tho so PHP can become the front-end for them. I have a good start on a Tuxedo interface (php-tuxedo.sourceforge.net) if you are interested. Brian Andi Gutmans wrote: At 03:27 PM 6/3/2002 +0300, Jani Taskinen wrote: On Mon, 3 Jun 2002, Andi Gutmans wrote: the web but more for Enterprise transaction based applications such as billing systems. Twisting your words a bit: You don't think PHP should be used for such tasks ?? No I definitely don't. And in most cases I wouldn't use J2EE either but I'd use a C++ App server. There are also performance problems with J2EE App servers but often company's clients require J2EE. Would you write that C++ App server yourself or use some existing one? (just wondering whether there is some open source c++ app server around..) Most people I know who are working in these kind of demanding environments (soft real-time requirements) have written these themselves. I don't know of any open source ones except for ACE which isn't a complete app server but gives you a framework to start on. BEA's Tuxedo is a commercial example. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.0 Release Announcement
Aaron Bannert wrote: It didn't coredump for me on startup. Nor for I, and I've done quite a lot of testing on this thing. The startup error has been identified (even though not reproduceable by me for some reason) and I will supply a patch for that later today. There is still another bug (also nonreproduceable by me) that we have already spent much time on and hope to have solved soon. Brian, I suggest you join the volunteer effort by providing detailed bug reports or even patches to fix problems that you come across. Only then can you ensure that your issues are properly addressed. -aaron If you look at the bug report (16475), you will see I did post a detailed followup to the original, stating both RC3 and RC4 had the same behavior. As for sumitting patches, I've done that too. Bug 9878 submitted in March 2001, but the included patch submitted with the bug report was only included in the last 4.1.2 (1 year turn around...) As for more detailed involvement, I could but any extra time I have I need to work towards php-tuxedo, which is a pretty large contribution to some users. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.0 Release Announcement
Have you people lost it??? One of the MAJOR features is working with Apache2. But bug 16475 is still open and unresolved. Its been reported by several different people, all having the same effect. Why would you release this version until after this bug is closed and gone through at least one RC cycle. You will have lost a lot of credability from potential users if it core dumps the minute Apache 2 is started. PHP has usually always been very careful about major bugs in releases; until now. Brian On Mon, 22 Apr 2002 22:55:14 +0200 (CEST), Derick Rethans wrote: The PHP Group is happy to announce the immediate availability of PHP 4.2.0, the latest version of the widely-used, general-purpose scripting language that is especially well-suited for Web development. This latest release contains over one hundred changes, bug fixes and improvements over the previous release, PHP 4.1.2. Among the highlights are experimental support for Apache 2, cleanups in variable handling and overhauls of various PHP components, including the domxml, posix, sockets and iconv extensions. For more information, see below: - External variables The biggest change in PHP 4.2.0 concerns variable handling. External variables (from the environment, the HTTP request, cookies or the web server) are no longer registered in the global scope by default. The preferred method of accessing these external variables is by using the new Superglobal arrays, introduced in PHP 4.1.0. More information about this change: * PHP Manual: Predefined variables http://www.php.net/manual/en/html/language.variables.predefined.html * The PHP 4.1.0 release announcement http://www.php.net/release_4_1_0.php * Thomas Oertli's article on secure programming in PHP http://www.zend.com/zend/art/art-oertli.php Compatibility The Apache Software Foundation recently released their first General Availability version of Apache 2. PHP 4.2.0 will have EXPERIMENTAL support for this version. You can build a DSO module for Apache 2 with --with-apxs2. We do not recommend that you use this in a production environment. PHP 4.2.0 still lacks certain key features on Mac OS X and Darwin, and isn't officially supported by the PHP Group on these platforms. Specifically, building PHP as a dynamically loaded Apache module isn't supported at this time. PHP 4.3.0, due to be released in August, 2002, will be the first PHP release to officially support Mac OS X. It, along with future Mac OS X and Apache releases, will enable full feature parity with other PHP platforms. Improvements PHP 4.2.0 includes several improvements: * External variables (from the environment, the HTTP request, cookies or the web server) are no longer registered as global variables * Overhaul of the sockets extension * Highly improved performance with file uploads * The satellite and mailparse extensions were moved to PECL and are no longer bundled with the official PHP release * The posix extension has been cleaned up * iconv handling has been improved * Output buffering support, which was introduced in PHP 4.1.0 has been stabilized * Improved performance and stability of the domxml extension * New multibyte regular expression support * LOTS of fixes and new functions For a full list of changes in PHP 4.2.0, see the NEWS file (http://www.php.net/ChangeLog-4.php). regards, Derick Rethans [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.0 Release Announcement
That is exactly my point. I no more than read the encouraging report that its been identified and is close to a fix, and the next message says 4.2 has been released. It couldn't have waited just another week to get this fix in and tested? Looking at the 4.2 announcement on the web page states... The Apache Software Foundation recently released their first General Availability version of Apache 2. PHP 4.2.0 will have EXPERIMENTAL support for this version. You can build a DSO module for Apache 2 with --with-apxs2. We do not recommend that you use this in a production environment Experimental kinda implies that its at least usuable and might be fun to play with. Not recommending for production is a long ways from saying ohh, I guess it will coredump on startup... Believe me, I'm a developer too, and I know the pressure (internal and external) to get a new release out. But this looks to me that with the much touted Apache 2 compatibility in this version, it could have waited just a little longer. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.0 Release Announcement
Personally, I completely understand that is all new code and bugs will occur. I won't be going to Apache 2 for some time to come. The only reason I even tried it at all is I already was already getting requests on php-tuxedo for that combo so I thought I should give it a try. But I hope the Bugus link works well on the bug mailing list cuz you will probably be getting quite a few. And from the public perception it just looks bad. And that is my main point. It just looks bad. As for Apache being at fault too, they very well could be. But the fact remains that PHP runs INSIDE Apache, and Apache starts fine without PHP, hence PHP must be at fault. Simply stating the obvious facts from the public point of view. Brian On Mon, 22 Apr 2002, Rasmus Lerdorf wrote: That is exactly my point. I no more than read the encouraging report that its been identified and is close to a fix, and the next message says 4.2 has been released. It couldn't have waited just another week to get this fix in and tested? No, because it wouldn't make much of a difference. There will be other bugs. This is brand new code. Like I said, it will take a couple of months to stabilize. People should not be running Apache2+PHP in production yet. Any why exactly are you focusing on PHP here? Why not complain to the Apache folks about releasing Apache 2 before this was cleared up? This is not likely to be a PHP-specific bug and will require changes on both sides. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.0 Release Announcement
On Mon, 22 Apr 2002 18:56:28 -0700 (PDT), Rasmus Lerdorf wrote: As for Apache being at fault too, they very well could be. But the fact remains that PHP runs INSIDE Apache, and Apache starts fine without PHP, hence PHP must be at fault. Simply stating the obvious facts from the public point of view. Well, with that sort of logic we are completely screwed and might as well just give up. Public perception ranks very low on the priority list. 99.8% of users couldn't care less about Apache2 at this point. PHP 4.2 has been slow enough in coming. Holding it up longer for the .2% of users it might affect makes no sense. Those users can experiment with the snapshot releases. -Rasmus Ultimately, I'm just trying to look out for other PHP users, not me. People who don't follow these mailing lists. They see on the net that a new improved Apache is released. They check the PHP web site/freshmeat and see a new version that claims support for Apache, experimental tho it may be. So they download both and start building. What do they get? Core dump. Usually before people will start opening trouble records or searching bug databases people will spend several hours re-rebuilding, double checking proceedures, etc, etc, etc. They've done everything correct. Its supposed to work, says right on the web page. Why does this core dump? They finally open a bug report only to have it immediately reply with... Yes, we know. What we really meant by 'Experimental' was it will core dump. That doesn't sound very good. That's a very frustrating scenario that will be occuring countless times probably right now. Why does PHP want to intentionally frustrate and turn off its own user community? What does that say about the PHP testing process and commitment to users? Now that 4.2 has been released and announced, the horse has left the barn. The only thing we can really do now is at least put a new note clearly on the web page stating that there is this problem with these two latest releases. Experimental, not for production just doesn't cut it. Not when we KNOW there is a definate problem, not some potential bug you might encounter. I've said my peace, Good night. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Config.m4 help
I'm finally trying to tackle an improvement in the config.m4 for my tuxedo module.
Previously, I've just hacked my way from other config.m4 scripts until it did what I
wanted. But now I need it to get fancy.
The problem comes because the raw Tuxedo libraries and the linking required
to use them seems to vary with each Tux version. However, they provide
a utility they expect people to use to link a client program (buildclient) which
has a verbose option that prints the details of its compile/link command.
(I can't just use it solely because it assumes its to build a executable program,
not a dynamic library).
So if I can get the config.m4 script to execute a sequence like:
buildclient -v -w -f simple_sample.c
The first line it outputs would look like:
cc -I $TUXDIR/include -o a.out -L{$TUXDIR}/lib simple_sample.c -lwsc -lbuft -lwsc
-lgpnet -lfml -lfml32 -lengine -ldl -lpthread /usr/lib/libcrypt.a
(plus some other lines)...
But this output will vary with at least 2 or 3 different versions of Tuxedo, hence
I can't just hardcode the m4 file.
I need to capture all the -l lines, and take those to create my
PHP_ADD_LIBRARY and TUXEDO_LIBS lines for the config.m4.
This is how, given the Tuxedo version provided, I should link a program.
From there, the rest of the buldconf process will take over just fine.
My experience with m4, very little. My knowledge of exactly what those m4 macros
like PHP_ADD_LIBRARY do ... very little also.
Does anyone have any ideas or places I can start to work this out?
Much appreciated.
Brian
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Linking pthread in a module
Related to my previous note, I remembered another question I've pondered. If you noticed in my last note, the link statement included -lpthread (I've tried without it, it won't link without pthread). Which implies to me that the Tuxedo libraries I'm bringing in, are themselves multi-threaded; even tho the whole of PHP is not (assume I'm doing a standard Apache 1.3 module build). Does anyone have any thoughts on this? Raise any red flags, etc? Assume Solaris or Linux, systems that obviously support the threading libraries in some fashion. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote on New Build System
Sascha Schumann wrote: Extension developers: Makefile.ins are abandoned. The files which are to be compiled are specified in the config.m4 now using the following macro: PHP_NEW_EXTENSION(foo, foo.c bar.c baz.cpp, $ext_shared) E.g. this enables the extension foo which consists of three source-code modules, two in C and one in C++. And dependending on the user's wishes, the extension will even be built as a dynamic module. The full syntax: PHP_NEW_EXTENSION(extname, sources [, shared [,sapi_class[, extra-cflags]]]) Please have a look at acinclude.m4 for the gory details and meanings of the other parameters. And that's basically it for the extension side. If you previously built sub-libraries for this module, add the source-code files here as well. If you need to specify separate include directories, do it this way: PHP_NEW_EXTENSION(foo, foo.c mylib/bar.c mylib/gregor.c,,,-I@ext_srcdir/lib) E.g. this builds the three files which are located relative to the extension source directory and compiles all three files with the special include directive (ext_srcdir is automatically replaced). Now, you need to tell the build system that you want to build files in a directory called $ext_builddir/lib: PHP_ADD_BUILD_DIR($ext_builddir/lib) Make sure to call this after PHP_NEW_EXTENSION, because $ext_builddir is only set by the latter. If you have a complex extension, you might to need add special Make rules. You can do this by calling PHP_ADD_MAKEFILE_FRAGMENT in your config.m4 after PHP_NEW_EXTENSION. This will read a file in the source-dir of your extension called Makefile.frag. In this file, $(builddir) and $(srcdir) will be replaced by the values which are correct for your extension and which are again determined by the PHP_NEW_EXTENSION macro. Make sure to prefix *all* relative paths correctly with either $(builddir) or $(subdir). Because the build system does not change the working directory anymore, we must use either absolute paths or relative ones to the top build-directory. Correct prefixing ensures that. I think I'm following this, but let me stress as the developer of php-tuxedo (http://php-tuxedo.sourceforge.net) that its getting more and more likely that PHP will be linking in complex libraries (includes and libs) perhaps not in the original PHP distribution. Another thing I've seen in my project is that the exact libraries Tuxedo requires vary from Tuxedo version to version. So capabilities to have the make process perform some dynamic adjustments would be nice. I think its just I need to get better at m4, but I haven't invested the time yet. Overall, I like the goals you outlined and your results look promising. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP module creation
This is a good place to start http://wwwzendcom/apidoc/ Brian On Sun, 3 Mar 2002 19:30:09 -0600, topside wrote: st want to use some C functions with -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
[PHP-DEV] Advice wanted on function arguments
In an external php module project (php-tuxedo), we have a group of about 7 php functions that, depending on how we design them, could take two different types of arguments. 1. A integer argument 2. A string argument. If the string argument is given, there is another routine that can convert it to the corresponding integer argument, but its not guarenteed to match. Using the integer argument is guarenteed to work; hence we really need to support the integer args. However, the majority of users will want to use the string argument because its more intuitive and they should provide the translation tables to allow strings to work. I'd like to come up with a solution flexible enough for both. And I have come up with three different solutions... 1. Create two different function names/entry points, one set for ints, one set for strings. 2. Overload the function arguments and check which type of arg is being passed. 3. Screw it and just accept the ints, and let the users nest a function (in their PHP code) to convert to strings if they want. Questions... 1. Any slick way to do solution 1, say with aliases or something? 2. How difficult / successful is it to test the arg type for solution 2. Let me re-stress, I'm talking about a PHP C code module, not PHP code. I can provide more detailed description if you need. Thoughts? Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14030: sybase ct_init fails
This can be a common, but very bothersome error message with Sybase (and some other databases) (not just using PHP). I've seen it before using Solaris 2.6 and Sybase 12 also. You need to be very careful about your $SYBASE and related variables, to make sure the web server has them all set right. Also, there may be issues in the exact libs that were built into PHP at compile time, especially the tli library (which could be a true PHP compile bug) It may also help looking at: http://manuals.sybase.com:80/onlinebooks/group-cn/cng1110e/ocerrors/@Generic__BookTextView/6454;nh=1;pt=6454;uf=0? DwebQuery=protocol+driver+failed#X for more hints. Reply if you still have problems and I'll look at my detailed build script tomorrow to see what minor tweaks I made to the build scripts for PHP. Brian On 12 Nov 2001 13:58:15 -, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.0.6 PHP Bug Type: Sybase-ct (ctlib) related Bug description: sybase ct_init fails I build apache 1.3.20, Sybase ASE 12 and php 4.0.6 with this configuration: ./configure --with-apache=/usr/local/sorgenti/apache_1.3.14 --with-sybase-ct=/database/sybase/OCS-12_0 when the webserver start this is the error: Open Client Message: Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131) Message String: ct_init(): network packet layer: internal net library error: Attempt to load protocol driver failed Open Client Message: Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131) Message String: ct_init(): network packet layer: internal net library error: Attempt to load protocol driver failed [Mon Nov 12 13:49:33 2001] [notice] Apache/1.3.20 (Unix) PHP/4.0.6 configured -- resuming normal operations [Mon Nov 12 13:49:33 2001] [info] Server built: Nov 12 2001 12:56:15 The sybase ct_init function don't work. -- Edit bug report at: http://bugs.php.net/?id=14030edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Sybase Stored Procedures
Carefull, you can only retrieve one result set, so most advanced sp's I think would be out. For instance, you can't use sp_help because it returns multiple result sets. At least that has been my experience with Sybase and PHP. There was a patch posted here in Aug by Luis Carlos Brenes Alvarez that claims to provide multiple result set capability, but I haven't tried it and to my knowledge its not been added to the CVS code yet. If it works, it would probably allow much more complex sp's. Brian Daniel Andersson wrote: we are using sybase stored procedures with no problems what so ever. just basic procedures but can't see any problem with advanced sp's. / d Thomas Janke [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... hello, I would like to use sybase stored procedures and need to know, in what way they are supportet in PHP. In the manual, one can read that stored procedures are not yet fully supported. Does anybody have any newer information on what Sybase features can be used with PHP4? Thank you very much for your help. Yours Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Sybase and Sybase-CT and MSSQL, oh my?]
Frank M. Kromann wrote: I dont know muct about Subase and Sybase-ct but I agrre that these extension should be combined into one, with aliases and functionality from the mssql extension to allow access to MSSQL Server 4.x and 6.x from Win32 and *nix clients. - Frank Actually these are the two most dis-simmilar API sets. The original Sybase (DB-LIB) has a completely different API set than SYbase_CT (CT-LIB). Trying to merge these would probably be more work than its worth. Also, some people have the low level CT libs, others have the DB Libs. Which one would you link against? Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Zeev Suraski wrote: Because it's a matter of taste, and different people see things different ways. Personally I find $_GET[foo] much clearer than $foo. It tells me, beyond a reasonable doubt, where this thing is coming from. The one and only drawback I see for this method is that it's a few more keystrokes, but that's by far less important than what it gives you. As a matter of fact, if I make $_GET and its friends be implicitly global, it'd actually safe you keystrokes in many situations, and is definitely easier than teaching users about the notion of the global scope, the global statement or $GLOBALS. If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand just how did this variable get its value?. Having the $_GET[ post_user_name] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11789: Apache can't start
I see this a lot when the LD_LIBRARY_PATH is not set correctly to load the Sybase libraries. Double check that type of stuff. [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Linux 2.4.5 PHP version: 4.0.6 PHP Bug Type: Sybase-ct (ctlib) related Bug description: Apache can't start When I launch apache with sybase_ct, I've got following messages : DRK01:/soft/apache/bin# ./apachectl start ./apachectl: line 184: 15557 Segmentation fault $HTTPD ./apachectl start: httpd could not be started Sybase Version : 11.9.2 $SYBASE environment variable is correctly set There's nothing in apache's logs There's nothing in dmesg's output Do you have any idea ? Thanks for your answer @++ JC -- Edit Bug report at: http://bugs.php.net/?id=11789edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] File Handle Resource
Now that the list is back up, I have a question... In my module I'm writing, I need to have some functions that will take as an argument a FILE resource id. So the question begs asking is there any function I can call to obtain the FILE resource structure (that contains the FILE*) from the standard file module? In my module, I don't want to have to modify the File code, or make some variable global or anything. I just want the user to give me the File resource, let me call a function that will give me the structure to the open FILE *. Does that exist? Any other suggestions? Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
Zeev Suraski wrote: At 18:21 11/5/2001, Brian Foddy wrote: [EMAIL PROTECTED] wrote: On 11 May 2001, Stig Sæther Bakken wrote: Why not have both numerical and descriptive indices? Backwards compatible, slightly bloatish, but not really a problem. it's already implemented this way now (it was added last night) AFAIK Derick Rethans You are creating the same array indexed both by a integer and a string? I'm curious how this is done. I might have a good use for this trick. No special tricks needed; PHP's arrays support both numeric and string indices ever since PHP 3.0 (at least). You can simply add both types of indices to the same array without having to do anything special. Thanks everyone, I knew arrays could be one or the other, but never considered the same value with multiple indexes. I have a perfect use for this, where an array I build, the values have a int index value, and a string an equiv string name. I'm already doing the zend_hash_update and index_update functions anyway, so this should be pretty easy. Question, what will zend_hash_get_current_key return if it gets input like this? Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #9878 Updated: gmmktime is 1 hour off during standard time
On 5 May 2001 19:40:27 -, Bug Database wrote: ID: 9878 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Analyzed Bug Type: Date/time related PHP Version: 4.0.4pl1 Assigned To: Comments: Are you sure that bit of code applies in your case? ie. is HAVE_TM_GMTOFF undefined in your main/php_config.h file? I am unable to recreate this problem here, but on my Linux box my gmadjust value comes straight from the libc system call ie. I have HAVE_TM_GMTOFF defined. Previous Comments: Yes, Solaris 2.6 does not have the tm_gmtoff value in the tm structure in time.h, and correspondingly the php_config.h does not define the HAVE_TM_GMTOFF value. I don't know if newer versions of Solaris have this value. My linux has the value. I suppose you can rebuild your Linux and override this define to try and duplicate the problem. Also remember it only happens during the standard timezone which ended in early April in the US. If its any help, I'm using the exact patch I suggested on our production Solaris environment and it worked fine before and after the time shift. Until your note, I didn't know how common this value even is in the structure, I'll have to make note of it for later use. Thanks, Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Zend API changes
A small point I'd like to raise here. I noticed 4.0.5 made a change to the arguments of zend_hash_get_current_key by adding a dupe argument to the define and underlying function. This of course broke any external custom modules that are not changed appropriately. In this case the change was very simple, but it raises a good question... Are there some guidelines independent external modules can follow to remain more compatible between releases? I'm not questioning the right or need for underlying Zend API changes, obviously when such changes are made all functions inside the PHP collection are change accordingly. But are there suggestions to minimize these in the future and get better notified when they do occur? Thanks, Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Troubles with DL'ed module
Andi Gutmans wrote: Did you compile with debug on or off? Please try without debug in both PHP and your module and let us know if something changes. Also can you try and load it via php.ini (extension=module.so) and not with dl(). I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off, and switched from using DL to the extension load in the php.ini. Unfortunately I still get the same coredump at the same line, just a different constant. As before I can step though it with the debugger and the address it cores in is viewable and has data. My gut is telling me its a build problem. Some address not aligned right or something. For example shouldn't the -KPIC have been used in the build argument list to libtool? But yet, in a seperate install without my new module the same version of php on the same machine is running in production very stable. Any ideas? Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Troubles with DL'ed module
One more strange behavior I just saw. Take this little script: ? phpinfo (); $tux = tux_tpalloc (TUX_FML32, , 5000); print $tux; tux_tpfree ($tux); print $tux; ? The tux_tpalloc and tux_free are new functions in my module. If I comment out everything but the phpinfo () and hit a fresh start of the web server, it will not core. My module is loaded because I see it in the phpinfo output. After that I can uncomment the rest of the script and it will NOT core. However if I just run this script right away from a fresh restart, it will coredump. Very strange... Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Troubles with DL'ed module
I'm going to try and build it statically first. I don't have any problem posting the code (its already avail on sourceforge but you will need some proprietary libraries to build it). The MINIT and/or RINIT is the constants are initialized. You've given me some to go on, I'll work with it for a day or so first. Thanks, Brian Andi Gutmans wrote: Sounds like some kind of memory corruption. With these kind of problems even the order of statements can make a difference. Do you want to post those two functions and we can take a look at them? Also are your RINIT() MINIT() functions doing anything? Maybe they are causing problems? Andi At 11:17 AM 4/30/2001 -0500, Brian Foddy wrote: One more strange behavior I just saw. Take this little script: ? phpinfo (); $tux = tux_tpalloc (TUX_FML32, , 5000); print $tux; tux_tpfree ($tux); print $tux; ? The tux_tpalloc and tux_free are new functions in my module. If I comment out everything but the phpinfo () and hit a fresh start of the web server, it will not core. My module is loaded because I see it in the phpinfo output. After that I can uncomment the rest of the script and it will NOT core. However if I just run this script right away from a fresh restart, it will coredump. Very strange... Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
Perhaps another possible solution is this... For those 1 in 300 web hits that the developer knows is going to use gobs of memory and assuming they can't be re-engineered to use less (through temp files, etc), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: I too have experienced this problem and can reproduce, I just changed to the cgi version instead to eliminate the problem, which I would agree, it is. I have one page on a site of hundreds of pages that produces the large process, 30MB+ and this is on a heavily used server with more than 300 processes. So if I don't run the cgi-version the server will crash in a matter of time as the memory is not freed and eventually will swap itself to death. So while the cgi-version is slightly slower, I have reliability. John Hamlik -Original Message- From: Brian Moon [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 3:20 PM To: [EMAIL PROTECTED]; Andi Gutmans Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. But the reverse side of this is that I might have one script out of 1000 that needs that much memory. But since 20 of my httpd processes have run that script, they all have that much memory and are not going to let it go no matter what. I basically sounds like a flaw that memory can not be freed. Reuse in the same process is not free memory, it is reused memory. And it sounds like there is nothing that the PHP team can do about it. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. Caching Dynamic Web Content to Increase Dependability and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 5:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
That sounds like it would work also. People would have to build PHP for both modules and CGI, but if they are willing to do that... Works for me. Brian On Mon, 30 Apr 2001 23:53:16 -0400, Rod K wrote: Couldn't one just run a cgi and module version simultaneously? Set an add type directive to pass an extension, say .cphp, to the cgi instead of the module. Then those scripts that use extensive memory could be extended with .cphp??? -Original Message- From: Brian Foddy [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 11:56 PM To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. Perhaps another possible solution is this... For those 1 in 300 web hits that the developer knows is going to use gobs of memory and assuming they can't be re-engineered to use less (through temp files, etc), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: I too have experienced this problem and can reproduce, I just changed to the cgi version instead to eliminate the problem, which I would agree, it is. I have one page on a site of hundreds of pages that produces the large process, 30MB+ and this is on a heavily used server with more than 300 processes. So if I don't run the cgi-version the server will crash in a matter of time as the memory is not freed and eventually will swap itself to death. So while the cgi-version is slightly slower, I have reliability. John Hamlik -Original Message- From: Brian Moon [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 3:20 PM To: [EMAIL PROTECTED]; Andi Gutmans Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. But the reverse side of this is that I might have one script out of 1000 that needs that much memory. But since 20 of my httpd processes have run that script, they all have that much memory and are not going to let it go no matter what. I basically sounds like a flaw that memory can not be freed. Reuse in the same process is not free memory, it is reused memory. And it sounds like there is nothing that the PHP team can do about it. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. Caching Dynamic Web Content to Increase Dependability and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 5:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
[PHP-DEV] Troubles with DL'ed module
I'm having strange problems with a new DL module I'm trying to write. The most common problem is PHP will coredump after my module has executed in the module cleanup routines (the Zend routines, not my module routines). For instance it will coredump on cleaning up the 10th constant defined by my module. It cores at line 643 of zend_hash.c (the pefree line). Looking in the debugger, the address looks valid, but free doesn't like it. NOTE: The constants are defined with CONST_CS | CONST_PERSISTENT, but taking the Persistent out has no effect (the persistent flag is still set in the struct). If I remove all my constants, or make other alterations it may core in other but related places inside the cleanup. I'm doing most of this on Solaris 2.6 (sparc) with the Workshop compiler (Forte 6.1), but it seems to work ok on Linux and gcc. I'm not to the point of calling this a Zend bug and opening a bug report, but I'm hoping to get a few more pointers of how to proceed. I haven't tried compiling the module yet directly into PHP. I'm rechecking my compile flags, for example I added -KPIC to the compile but that didn't help. BTW, the base PHP I'm building against is 4.0.4p2. Any help would be greatly appreciated... Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Troubles with DL'ed module
Both were compiled with debug ON. I'll try them off. I'm away for the weekend but will try it Sunday night or Monday. Thanks, Brian Andi Gutmans wrote: Did you compile with debug on or off? Please try without debug in both PHP and your module and let us know if something changes. Also can you try and load it via php.ini (extension=module.so) and not with dl(). Andi At 01:41 PM 4/27/2001 -0500, Brian Foddy wrote: I'm having strange problems with a new DL module I'm trying to write. The most common problem is PHP will coredump after my module has executed in the module cleanup routines (the Zend routines, not my module routines). For instance it will coredump on cleaning up the 10th constant defined by my module. It cores at line 643 of zend_hash.c (the pefree line). Looking in the debugger, the address looks valid, but free doesn't like it. NOTE: The constants are defined with CONST_CS | CONST_PERSISTENT, but taking the Persistent out has no effect (the persistent flag is still set in the struct). If I remove all my constants, or make other alterations it may core in other but related places inside the cleanup. I'm doing most of this on Solaris 2.6 (sparc) with the Workshop compiler (Forte 6.1), but it seems to work ok on Linux and gcc. I'm not to the point of calling this a Zend bug and opening a bug report, but I'm hoping to get a few more pointers of how to proceed. I haven't tried compiling the module yet directly into PHP. I'm rechecking my compile flags, for example I added -KPIC to the compile but that didn't help. BTW, the base PHP I'm building against is 4.0.4p2. Any help would be greatly appreciated... Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] sybase-ct and datetime results
On Wed, 25 Apr 2001 22:59:15 +0200, Bj,rn Dolkemeier wrote: (I posted this also to php.db, but the more I think php.dev would be a better place) Hello, If I do a sybase_query(select getdate(),$Conn) this will return the current date in the format Nov 3 1998 8:06PM (so I don't have seconds). I think this leads to the usage of CS_SHORT_DATE in ext/sybase_ct/php_sybase_ct.c (Line 275). Does somebody know, if there is a solution for getting another datetime-format beyond doing something like sybase_query(select convert(varchar,getdate(),108). Wouldn't it be better to return the datetime-results of queries as a timestamp? Or have a php.ini-setting / global parameter how to return datetime-results? Thanks for anwers, Bjoern WHen you send the select getdate () PHP doesn't parse that, it just sends it on to Sybase exactly as is. If you issue that query in ISQL, you should get the same result. PHP can't start parsing SQL requests. There are some ways in Sybase to change some of the defaults for date/times. Check the Sybase manuals, they may help. The only other thing that could even possibly be done (and I'm not advocating it) is the creation of a new function that would return the Sybase timestamp with greater precision. Don't get me wrong, I think Sybase should have better time formatting also. For example to format 12/31/2001 23:59:59 it takes two datetimes formatted string catted together, that's pretty sad. But still that is a Sybase issue. Not much PHP can do. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Hash Functions API
I've been looking everywhere for a good reference of how to read and update arrays. The Zend documentation (www.zend.com/apidoc) has descriptions of how to create an array, and how to add elements to it, but I can't find anything on how to simply read the values of an array. Mostly I want to write two functions: 1. Accept a provided 2 dimensional array and loop through every element, by primary index then an inner loop by the second index, sequentially. I need to extract from the array the two keys and the value. The keys will not be sequential, at least the primary. 2. Build a 2-d array, basically the reverse of 1 above. Build an array with specific primary and secondary indexes. Again keys will not be sequential. To make matters worse, I'd like the keys to be either integer or strings. I've looked through the zend_hash.h header, and a few functions look likely (zend_hash_move_forward, zend_hash_get_current_key). But its hard knowing if these are the best to use and exactly how to use them. One more question, very simple. What is the difference between zend_hash_find and quick_find? I assume index_find lets me specify an integer (ie: array[3] in C notation). Have I missed the docs on these functions somewhere? Thanks for help. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP-Tuxedo Open Source Project
Open Source Project Announcement... I have started an open source project to build a module for PHP4 that will allow direct calls to Tuxedo services from the PHP script, the project name is php-tuxedo. Think about it for a second... The ability from inside a PHP web page to directly call already existing Tuxedo services anywhere in your environment. Just like PHP can open a database connection to Oracle or Sybase, it would open a Tuxedo connection as a Tux client to a Tuxedo middleware environment. For those who have used PHP, you know how easy it is to build dynamic web pages. But those pages are mostly limited to database queries or flat file access for data. With this project you could call all your existing enterprise Tuxedo services directly. I believe this would be a very powerful enhancement to PHP's capabilities. To those familiar with Tuxedo, you know about how powerful an implementation of Tux middleware services can be for departmental and enterprise solutions. I want to bring these two pieces together. Project status. The project is in its early infancy, but some parts are functional. I have successfully built a client page that uses a STRING buffer to call a service with tpcall and returns a STRING buffer back. Primitive? Sure, but this is only the start. I have ideas of how to implement many other functions and buffer types including FMLs. There is much work to do, but if you are interested please check out http://php-tuxedo.sourceforge.net. There you can download my first cut and more importantly follow the project as it progresses. For the really ambitious I would welcome any testing or development help on the project. Please note I'm posting this note to several lists I don't normally monitor, so I may not see a reply on the list. Hope to hear from you. Brian Foddy [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #8834 Updated: crypt() starts from not random salt
I too have seen this, but I assumed it you had to put a random salt key in. I picked the system mseconds and put that in a random seed to get a random salt key. I was also on Solaris 2.6. Simple work around if its not supposed to work that way. On 5 Apr 2001 18:57:45 -, [EMAIL PROTECTED] wrote: ID: 8834 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Strings related Assigned To: Comments: This is most likely a Solaris specific issue as I can't reproduce this on Linux. Can you please include the output of this command in both Solaris 2.4 and 2.6 (in php4): # grep RAND main/php_config.h It might be that in both of those system the seed generator found is srand() which isn't so good as srandom() is. But I also found (with google :) that srandom() might not be that good either (in Solaris) so that leaves us with a problem. One solution might be that we run php_srand() in RINIT instead of MINIT when Solaris is used. --Jani Previous Comments: --- [2001-01-22 06:05:34] [EMAIL PROTECTED] PHP compiled as Apache module. Look like crypt() starts from not random salt. In case of my Solaris 2.4, first crypt() call always generates string starting from "IH". In case of Solaris 2.6 it always starts from "C.". Looks like in every instantiation of new Apache process PHP starts crypt from the same salt value. In the same process next crypt() calls look like they generate random strings, though. But next process restarts with the same value. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8834edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Sybase_ct on linux core and LANG variable
I just thought I would pass this along, it might be the cause of some bug reports. Using Linux Mandrake 7.2 and Sybase Open client 11.1.1, php4.0.4p1. I was getting a core (illegal instruction) on apache startup when I had the sybase modules installed in PHP. However, I knew it worked fine on Solaris 2.6 at work, so I was puzzled. looking at the backtrace, I discovered it was dumping in cs_ctx_alloc which tries to read the locales.dat files. Then it hit me, Sybase is very picky about the LANG variable being set correctly for a matching record in locales.dat. Mine was set to "en" The fix... Either 1. set LANG=C in apachectl or 2. add "locale = en, us_english, iso_1" to the locales.dat in the linux section. This can be very frustrating, I've been working with Sybase for years and it still took me a long time to find this. I don't know if this is documented anywhere, but if not it would be nice to have it so. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Fwd: [PHP-DEV] Sybase_ct on linux core and LANG variable
That's is the sybase_ct libraries, just for clarification. ==BEGIN FORWARDED MESSAGE== I just thought I would pass this along, it might be the cause of some bug reports. Using Linux Mandrake 7.2 and Sybase Open client 11.1.1, php4.0.4p1. I was getting a core (illegal instruction) on apache startup when I had the sybase modules installed in PHP. However, I knew it worked fine on Solaris 2.6 at work, so I was puzzled. looking at the backtrace, I discovered it was dumping in cs_ctx_alloc which tries to read the locales.dat files. Then it hit me, Sybase is very picky about the LANG variable being set correctly for a matching record in locales.dat. Mine was set to "en" The fix... Either 1. set LANG=C in apachectl or 2. add "locale = en, us_english, iso_1" to the locales.dat in the linux section. This can be very frustrating, I've been working with Sybase for years and it still took me a long time to find this. I don't know if this is documented anywhere, but if not it would be nice to have it so. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] ===END FORWARDED MESSAGE=== -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Getting Started with new module
Some months back I inquired about writing a BEA Tuxedo module for PHP. I got side-tracked for a while, but now I'd like to resume exploring this possibility. Primarily, because I'd like to use this module myself, but also feel it would be a natural match to an environment like PHP on a web server. First obvious question is is anyone working on a Tuxedo hook? If not, I'd like to volunteer. For those not familiar with Tuxedo, its a high-end transaction middleware Client/Server environment used in many larger corporate environments. Reference http://www.beasys.com/products/tuxedo/index.shtml for a good starting point. My thoughts are that PHP should have the ability to be a Tuxedo client, so it can call Tux services elsewhere in a Tux environment. These services can be located on the same machine, one other machine, numerous other machines, even mainframes. Ideally, all seemlessly called. It would call services in much the same way PHP calls a service from a database. I would only propose a web/PHP server be a client to Tuxedo. I can't imagine how a Tux server would even technically be incorporated into PHP. So, where to start??? I've looked through some of the code for other external modules. Sybase_ct for instance which is another environment I'm familiar with. Tuxedo has numerous API calls, but most of them aren't used for clients, so I don't think there would be many new functions. A basic Tux client can be written with as few as 6 API functions. It does require some similar connection concepts as databases, and also has its own memory allocation / free functions (tpalloc, tpfree). My personal resume includes 8+ years of UNIX, C, and database development mostly on Solaris, Linux, Sybase, and Informix. I feel I should be technically able to complete this type of project. I've read the apidoc.txt and apidoc-zend.txt files, but seems there are still some holes. Can anyone suggest the best way to get started? Much appreciated, Brian Foddy [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
