Re: [PHP-DEV] php_gettext.dll
On Tuesday, Mar 11, 2003, at 03:35 Europe/Copenhagen, Nathan Fredrickson wrote: Hi, Is the CVS source out of date for gettext extension? The distributed php_gettext.dll dynamically loads libintl-1.dll. The php_gettext.dll I built from the CVS source is linked to gnu_gettext.lib. How can I build a php_gettext.dll that works like the one in the win32 binary distribution? (dynamiclly loads libintl.dll) It could be that I compiled libintl differently. You can find all libraries and includes for the snapshot/release building machine at: http://ftp.proventum.net/pub/php/win32/misc/dev/php_build/(include|lib)/ Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_xslt: xslt_set_encoding
You can download latest stable snapshot from snaps.php.net or wait for 4.3.2 release. Edin - Original Message - From: Michel Sahyoun [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 1:02 AM Subject: [PHP-DEV] php_xslt: xslt_set_encoding I have downloaded the 4.3.1 windows binaries zip package and it doesn't seem to have xslt_set_encoding() enabled. Can anyone confirm this? And short of getting the sources and recompiling PHP, is there another binary distribution that would have xslt_set_encoding() enabled? Thanks, Michel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 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
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
Re: [PHP-DEV] disable_classes
On Sunday, Mar 2, 2003, at 23:42 Europe/Copenhagen, Harald Radi wrote: i reclassified http://bugs.php.net/bug.php?id=22481 to a feature request for adding disable_classes . if there are no objections i'm going to implement it that way. +1 It is actually necessary to have such an ini option as I suppose we'll have more extensions exposing their functionality in an OO way. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new Date extenstion
Does the extension take into acount calendar changes like: $ cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Edin - Original Message - From: Pierre-Alain Joye [EMAIL PROTECTED] To: phpdev [EMAIL PROTECTED] Sent: Sunday, February 16, 2003 4:38 PM Subject: [PHP-DEV] new Date extenstion Hello, I made a new extension to work with dates, you may find infossources here: Docs: http://www.pearfr.org/php_date/docs/ Sources: http://www.pearfr.org/php_date/sources/ This is a alpha release, a first shot. I still have to create a full set of tests script. The idea is to provide a fullfeatured date/time standart extension with php5. A non documented function is get_isoweek() which returns the ISO week number. But the weeknumber is a thing we have to discuss, because there are tons of way to represent it. Actually the week #1 is the week where fit 4th of january. For all date_new_xxx functions, an optionnal arg can be set to define the 1st day week, default is monday. Todo: - strftime() - add/clean warnings (overflow, invalid dates,...) - add times functions This part is real pain if we want to DST times, localtime and so on. - add time_span datatype, which represents a time interval in days, hours, seconds, and related functions - add a true crossplatform localisations, which does not depend of the target platform. That will make our life easier to provide date localisations in any cases. Usefull but not really needed: - add additionnals functions for specials days and official hollydays any comments, ideas, feedback ? pierre -- 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] new Date extenstion
On Mon, 17 Feb 2003, Pierre-Alain Joye wrote: On Mon, 17 Feb 2003 12:58:21 +0100 Edin Kadribasic [EMAIL PROTECTED] wrote: Does the extension take into acount calendar changes like: $ cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 oops, wrong shortcut :) Actually no, date corrections will be part of the date functions as soon as the locale part is done. The changes of calendar was not the same in each country, not in the same time, and even not in the same country (I like scottland, switzerland or others proud people ;-), there are ambiguous common days offset, some use it, some not. That is one of the things we should discuss, and document our choice as well. What do you think ? It would probably be easier to take one cutoff point like the unix cal command. From its manpage: The Gregorian Reformation is assumed to have occurred in 1752 on the 3rd of September. By this time, most countries had recognized the reforma- tion (although a few did not recognize it until the early 1900's.) Ten days following that date were eliminated by the reformation, so the cal- endar for that month is a bit unusual. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new Date extenstion
On Mon, 17 Feb 2003, Pierre-Alain Joye wrote: On Mon, 17 Feb 2003 15:40:08 +0100 Hartmut Holzgraefe [EMAIL PROTECTED] wrote: ext/calendar has support for all this ... it even knows about the french revolution calendar ;) rofl :) Well, I'm talking about a good and usefull date/time extension. I do not say calendar is not good, but it does not cover what we need for a good, crossplatform date/time modules :) Well, isn't it better/easier to fix ext/calendar and add missing functionality than to introduce a whole new extension? Having two extensions doing essentialy the same thing would IMHO be very confusing. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Weird PHP5 APXS libtools errors
On Thu, 13 Feb 2003, John Coggeshall wrote: upgrade your libtool to 1.4.3, it is required now. [user@localhost php5]# ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) And just to be sure.. [user@localhost php5]# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) Any other thoughts? If there's anything else you need to know, let me know. Does a snapshot from snaps.php.net compile without running ./buildconf? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mysqli mysqli_api.c
On Thu, 13 Feb 2003, Sebastian Bergmann wrote: Edin Kadribasic wrote: edink Thu Feb 13 12:15:22 2003 EDT Modified files: /php4/ext/mysqlimysqli_api.c Log: Use my_ulonglong instead of unsigned long long to make msvc++ happy. Did you somehow manage to build MySQL 4.1 on Windows? If so, how? If not, how are you building ext/mysqli since it requires libmysql 4.1? I have indeed. Lots of tweaking of project files, but I'm able to compile and load php_mysqli.dll extension and to make it show up in phpinfo(). I didn't test it beyond that. The compiled lib and header files are available at: http://snaps.php.net/~edink/libmysql-4.1.zip and the compiled extension is at http://snaps.php.net/~edink/php_mysqli.dll. Please note that I exported only symbols needed for ext/mysqli at this point so I might need to recompile it if the extension gets extended and starts using some more of the mysqli API. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New CLI switches (was [PHP-DEV] Using CLI as a shell)
First simply use php -h but i am also thinking about adding a man
page.
That is a bit too much text for 'php -h'. It should be moved to the
online manual. Adding a man page would be great too.
[snip]
find . -name '*.c' -o -name '*.h' | php -B '$l=0;' -R
'$f=count(file($argn)); echo $argn($n)\n;$l+=$f;' -E 'echo
Files: $argi,
Lines: $l\n;'
This appears to be equivelant of:
find . -name '*.c' -o -name '*.h' | php -r 'while (!feof(STDIN)) {
$q=count(file($n=trim(fgets(STDIN; echo $n($q)\n; $l+=$q;
$f++; } echo Files $f, Lines: $l\n;'
Am I correct in this assumption? If yes, could please try to point
out what are the advantages of -B -R -E and -F over using just -r?
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: New CLI switches (was [PHP-DEV] Using CLI as a shell)
On Tuesday 04 February 2003 20:25, Marcus Börger wrote: [snip] That is a bit too much text for 'php -h'. It should be moved to the online manual. Adding a man page would be great too. I wrote already i will do so...but haven't yet the time. Could you please then remove the explanation from the php -h output? [snip] Yes it is the same result. I never said you cannot do it otherwise. The reason i implemented the switches is that it makes thinks easier. And sometimes making things easier for users is better than knowing as a developer that there is a solution. After having played a bit with the new switches I begun to see the idea. I actually kind of like the ease of use that they give for providing search replace sort of capability and using extensive array of PHP string functions. For example its quite easy to strip tags from an html file/output: php -d html_errors=1 -i | php -R 'echo strip_tags($argn).\n;' So provided that you remove large (and imho confusing) output on the bottom of -h I'm +1 on keeping these changes. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute_API.c
That makes PEAR installer coredump with the following core:
Core was generated by `/data/src/php5/sapi/cli/php -n -dsafe_mode 0
/data/src/php5/pear/install-pear.php'.
#0 0x08142d78 in _efree (ptr=0x400b396c,
__zend_filename=0x81a89e0
/data/src/php5/Zend/zend_execute_API.c,
__zend_lineno=332,
__zend_orig_filename=0x81a95e0
/data/src/php5/Zend/zend_variables.c,
__zend_orig_lineno=44) at /data/src/php5/Zend/zend_alloc.c:242
242 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x08142d78 in _efree (ptr=0x400b396c,
__zend_filename=0x81a89e0
/data/src/php5/Zend/zend_execute_API.c,
__zend_lineno=332,
__zend_orig_filename=0x81a95e0
/data/src/php5/Zend/zend_variables.c,
__zend_orig_lineno=44) at /data/src/php5/Zend/zend_alloc.c:242
#1 0x08154de0 in _zval_dtor (zvalue=0x400b39a8,
__zend_filename=0x81a89e0
/data/src/php5/Zend/zend_execute_API.c,
__zend_lineno=332) at /data/src/php5/Zend/zend_variables.c:44
#2 0x0814c1f8 in _zval_ptr_dtor (zval_ptr=0x400b39f8,
__zend_filename=0x81a95e0
/data/src/php5/Zend/zend_variables.c,
__zend_lineno=164) at /data/src/php5/Zend/zend_execute_API.c:332
#3 0x08155077 in _zval_ptr_dtor_wrapper (zval_ptr=0x400b39f8)
at /data/src/php5/Zend/zend_variables.c:164
#4 0x0815c18d in zend_hash_destroy (ht=0x400b33d4)
at /data/src/php5/Zend/zend_hash.c:541
#5 0x0814ecef in destroy_zend_class (pce=0x81efa84)
at /data/src/php5/Zend/zend_opcode.c:120
#6 0x0815c18d in zend_hash_destroy (ht=0x81c0984)
at /data/src/php5/Zend/zend_hash.c:541
#7 0x0815613a in zend_shutdown () at /data/src/php5/Zend/zend.c:674
#8 0x081229eb in php_module_shutdown () at
/data/src/php5/main/main.c:1346
#9 0x08172b97 in main (argc=7, argv=0xb9c4)
at /data/src/php5/sapi/cli/php_cli.c:813
#10 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
Edin
- Original Message -
From: Stanislav Malyshev [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 3:33 PM
Subject: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute_API.c
stas Wed Jan 29 09:33:18 2003 EDT
Modified files:
/ZendEngine2 zend_execute_API.c
Log:
Fix object destructors:
zend_objects_store_call_destructors is not used anymore, we rely
on
symbol tables cleaners to destroy all objects.
Index: ZendEngine2/zend_execute_API.c
diff -u ZendEngine2/zend_execute_API.c:1.189
ZendEngine2/zend_execute_API.c:1.190
--- ZendEngine2/zend_execute_API.c:1.189 Thu Jan 23 00:15:42 2003
+++ ZendEngine2/zend_execute_API.c Wed Jan 29 09:33:18 2003
@@ -189,15 +189,23 @@
void shutdown_executor(TSRMLS_D)
{
zend_try {
- zend_objects_store_call_destructors(EG(objects_store)
TSRMLS_CC);
-
zend_ptr_stack_destroy(EG(arg_types_stack));
-
- while (EG(symtable_cache_ptr)=EG(symtable_cache)) {
+
+/* Removed because this can not be safely done, e.g. in this
situation:
+ Object 1 creates object 2
+ Object 3 holds reference to object 2.
+ Now when 1 and 2 are destroyed, 3 can still access 2 in its
destructor, with
+ very problematic results */
+/* zend_objects_store_call_destructors(EG(objects_store)
TSRMLS_CC); */
+
+/* Moved after symbol table cleaners, because some of the
cleaners can call
+ destructors, which would use EG(symtable_cache_ptr) and thus
leave leaks */
+/* while (EG(symtable_cache_ptr)=EG(symtable_cache)) {
zend_hash_destroy(*EG(symtable_cache_ptr));
efree(*EG(symtable_cache_ptr));
EG(symtable_cache_ptr)--;
}
+*/
zend_llist_apply(zend_extensions, (llist_apply_func_t)
zend_extension_deactivator TSRMLS_CC);
zend_hash_destroy(EG(symbol_table));
@@ -217,6 +225,12 @@
} else {
zend_hash_reverse_apply(EG(function_table), (apply_func_t)
is_not_internal_function TSRMLS_CC);
zend_hash_reverse_apply(EG(class_table), (apply_func_t)
is_not_internal_class TSRMLS_CC);
+ }
+
+ while (EG(symtable_cache_ptr)=EG(symtable_cache)) {
+ zend_hash_destroy(*EG(symtable_cache_ptr));
+ efree(*EG(symtable_cache_ptr));
+ EG(symtable_cache_ptr)--;
}
} zend_end_try();
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute_API.c
EK That makes PEAR installer coredump with the following core: Doesn't happen to me. What were the arguments? You need to remove $PREFIX/lib/php to reproduce on my RedHat 7.3 box. ./configure --enable-debug make make install-pear Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()
I don't even see the speed difference as an issue as much as (A) simplicity for the user who hasn't figured out regex yet, (B) consistency (we have 'i' versions of most other string functions, why not this one?) +1 for the reasons stated above. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Another segfault running pear installer
$ gdb sapi/cli/php GNU gdb Red Hat Linux (5.1.90CVS-5) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) r -n -dsafe_mode=0 /data/src/php5/pear/install-pear.php /data/src/php5/pear/package-*.xml Starting program: /data/src/php5/sapi/cli/php -n -dsafe_mode=0 /data/src/php5/pear/install-pear.php /data/src/php5/pear/package-*.xml Warning: Invalid argument supplied for foreach() in /data/src/php5/pear/PEAR/Registry.php on line 489 /data/src/php5/pear/PEAR/Registry.php(489) : Warning - Invalid argument supplied for foreach() Warning: Cannot use a scalar value as an array in /data/src/php5/pear/PEAR/Installer.php on line 682 /data/src/php5/pear/PEAR/Installer.php(682) : Warning - Cannot use a scalar value as an array Warning: Invalid argument supplied for foreach() in /data/src/php5/pear/PEAR/Installer.php on line 682 /data/src/php5/pear/PEAR/Installer.php(682) : Warning - Invalid argument supplied for foreach() Program received signal SIGSEGV, Segmentation fault. 0x080817b9 in compile_branch (optionsptr=0x402be350, brackets=0x0, codeptr=0x1, ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc, reqcharptr=0x402c73bc, bcptr=0x1, cd=0x402b1ce4) at /data/src/php5/ext/pcre/pcrelib/pcre.c:2708 2708previous[1] = length; (gdb) bt #0 0x080817b9 in compile_branch (optionsptr=0x402be350, brackets=0x0, codeptr=0x1, ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc, reqcharptr=0x402c73bc, bcptr=0x1, cd=0x402b1ce4) at /data/src/php5/ext/pcre/pcrelib/pcre.c:2708 #1 0x0816c0fc in zend_do_fcall_common_helper (execute_data=0xbfffb0b0, op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2630 #2 0x0816c43c in zend_do_fcall_by_name_handler (execute_data=0xbfffb0b0, op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2694 #3 0x081677e2 in execute (op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:1217 #4 0x0816c0fc in zend_do_fcall_common_helper (execute_data=0xbfffd630, op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2630 #5 0x0816c43c in zend_do_fcall_by_name_handler (execute_data=0xbfffd630, op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2694 #6 0x081677e2 in execute (op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:1217 #7 0x081569f6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/src/php5/Zend/zend.c:996 #8 0x08123479 in php_execute_script (primary_file=0xb960) at /data/src/php5/main/main.c:1691 #9 0x081727bc in main (argc=7, argv=0xba04) at /data/src/php5/sapi/cli/php_cli.c:753 #10 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory allocation problems
I have a script that allocates a lot of memory (huge associative arrays). The problem is that this scripts bails out with fatal error (emalloc unable to allocate 44 bytes) when I hit the limit of physical ram in the machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of swap space. Has anyone seen something like this before? Are there any limitations in the PHP memory allocation code that would prevent it from being able to use more memory. Are you sure you are hitting the exact physical memory limit? What is your ulimit -d (data segment size limit)? I have checked all the limits and the problem wasn't there. It turns out that PHP + glibc-2.1.3 (RedHat 6.2 standard) + Kernel 2.2.22 is a bad combination when allocating large number of small memory chunks. Installing glibc-2.2.5 (scarry stuff to have to go through) solved the problem for me. Now building PHP with an alternative glibc on the system is not something I would recommend for light entertainment :) Anyway thanks to all who offered advice and have helped me track down and resolve this issue. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sapi/embed ?
On Fri, 17 Jan 2003, Brian Moon wrote: I just noticed sapi/embed. Where can I find out more about what this is? I am hoping it is a sapi that will create a generic library that can be used from any C application. Is this true? Yes it is true. Writing some documentation on how to do it is my TODO list. If you need it right away I can send you some example code. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory allocation problems
I have a script that allocates a lot of memory (huge associative arrays). The problem is that this scripts bails out with fatal error (emalloc unable to allocate 44 bytes) when I hit the limit of physical ram in the machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of swap space. I suppose you use some windows machine. I remember that all application have only 1GB of RAM for their own until you have a windows server version and that has an appropriate HAL and is configured to have more than 1gig. Nope it's a RedHat Linux box. Just to make sure I've tried another one, and there as well program quit after hitting the limit of physical ram. I also tried writing small C test program to verify that I wasn't reaching some ulimit or kernel limitations, but it had no problems mallocing 1.2 GB on the same box. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Memory allocation problems
I have a script that allocates a lot of memory (huge associative arrays). The problem is that this scripts bails out with fatal error (emalloc unable to allocate 44 bytes) when I hit the limit of physical ram in the machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of swap space. Has anyone seen something like this before? Are there any limitations in the PHP memory allocation code that would prevent it from being able to use more memory. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
Maybe I misunderstood when Edin said that there will be no new release for some time due to the move on PHP 5. Yes, you misunderstood what I said which was that there is not going to be a release from the HEAD branch for some time to come -- until PHP 5 is released. As a matter of fact I think it would be good idea to go for 4.3.1 in February because number of bugfixes in PHP_4_3 branch is already significant and since no major new features have been added there the QA process shouldn't take that long either. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] Re: Thank's for the announce about PEAR and a little precision
Pear is not included in Win32 distribution of php-4.3.0. The pear
installer is broken on windows and since there is no easy way to
install PEAR without it it was not bundled with the distro.
You could try to install pear on windows from the command line. Go
into the directory where you have installed php (c:\php4 is
recommended if you want to use PEAR in its current state) and type:
cli\php -n -r include ('http://go-pear.org/');
This might work, and then again it might be broken :)
Edin
- Original Message -
From: Dirkjan Ochtman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, January 13, 2003 3:48 PM
Subject: [PHP-DEV] Re: [PEAR-DEV] Re: Thank's for the announce about
PEAR and a little precision
I guess the mirror I'm using didn't update...
I'll try the main site now.
Regards,
Dirkjan
Pierre-Alain Joye [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Mon, 13 Jan 2003 15:14:55 +0100
Dirkjan Ochtman [EMAIL PROTECTED] wrote:
Hello,
I'm running PHP (4.3.0) on Windows, and I haven't seen
*anything*
relating to PEAR in my (.zip) binary distribution. Am I just
looking
in the wrong place?
Early release of binary php 4.3.0 for win32 did not contain
PEAR, please
try to download it again, you may find pear inside.
hth
pierre
--
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] Apache2Filter SAPI segfaults
What bison version are you using. I saw similar segfaults with 1.875. Downgrading to 1.75 or even to 1.28 fixes it for me. Edin - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 10:07 AM Subject: Re: [PHP-DEV] Apache2Filter SAPI segfaults Sebastian Bergmann wrote: [...] I get a segfault with the same backtrace for Apache 1.3. -- 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZE2 dev snaps
If you checkout php4-ze2 all this will be done automagically for you by the CVS server. Edin - Original Message - From: Christian Stocker [EMAIL PROTECTED] To: Stephan Seidt [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 10:00 AM Subject: Re: [PHP-DEV] ZE2 dev snaps On Mon, 6 Jan 2003, Stephan Seidt wrote: At least ./buildconf with --ZendEngine2 did never work for me. ;) I also did cvs co ZendEngine2 in php4 cvstree root. Did you rename ZendEngine2 to Zend? (Or make a symbolic link, after renaming the old Zend directory to something else) chregu Mark J. Hershenson wrote: Hi all, I know there are Win32+ZE2 Package snapshots on snaps.php.net, but I don't believe I've read why there isn't a ZE2 source code snapshot for everyone else. Checking out the source with CVS may not be the world's most difficult practice, but automating that process likely isn't either. ;) Is there a timeline for this, or is this being intentionally kept off the radar? -- mjh -- nam...christian stockeradr...pflanzschulstr. 31, ch-8004 zurich pho...+41 43 317 9984 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Building a HTTP server using PHP - PHP and Windows question (please don't delete)
Very impressive work! As for writing to the php-cgi.exe I suggest you look into proc_open() function in PHP 4.3.0 (http://www.php.net/manual/en/function.proc-open.php). Edin - Original Message - From: Dominik Wittenbeck [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 10:28 PM Subject: Building a HTTP server using PHP - PHP and Windows question (please don't delete) Hi, I am not trying to spam you guys, I just don't know where else to turn to to get help. Maybe you know somebody to help me on the following Win2K/PHP problem. Task: I am trying to implement the CGI interface on a PHP based webserver I have built using the new CLI, that comes with PHP 4.3.0. So far I have no problems with the server sending and recieving data as well as static document. However I am experiencing difficulties, trying to implement the CGI interface. In order stabalize the server I have the server process PHP files via the php.exe (the CGI not the CLI one that comes with the 4.3.0). I use shell_exec(php\php-cgi.exe -c php\php.ini PathToPhpScript.php); to call the binary and have a custom script processed. Before this I set environmental variables using putenv(). All this works fine. I get my html output, the headers and stuff and send it back to the browser. I am however experiencing problems, when trying to get the php-cgi.exe to read POST data, that supposedly has to be submitted via the standard input if no other mechanism is available. Now unlike GET, which basically comes from the QUERY_STRING env-var, I appearently cannot abuse another env-var such as HTTP_RAW_POST_DATA for POST payload. Trying to pipe information either directly or via a file like shell_exec(type fileWithPostData | php\php-cgi.exe -c php\php.ini PathToPhpScript.php); or shell_exec(echo postData | php\php-cgi.exe -c php\php.ini PathToPhpScript.php); doesn't work. How do I get the php-cgi.exe to understand and process my POST data? There has to be a way, as other webserver have to use the same interface. I just cannot figure out how. As this is the last step to complete the implementation of the CGI on my server, I desperately need help! I am currently using a bugfix that populates the HTTP_RAW_POST_DATA var and append a PHP script before each script to be processed, that analyses the variables from it and fills it into $_POST... which still does not help me with uploaded files :-( ... I know, this workaround sucks pretty bad too! If you are interested in the source: http://developaz.no-ip.com/index.php?action=download(9) Thanks very much in advance! Dominik Wittenbeck System Architect Developaz Network Holderbaum Str. 31 67549 Worms Telefon:06241/209474 Mobil: 0179/7710426 E-Mail: [EMAIL PROTECTED] URL:http://www.developaz.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?
Yes, Steph is right, the set of libraries used on the snaps machine is ~70MB (uncompressed) and I don't think it's practical to update win32build.zip to include them all. And this 70 MB does not include files needed for building ext/infromix, ext/interbase and sapi/pi3web. Edin - Original Message - From: Steph [EMAIL PROTECTED] To: Christoph Grottolo [EMAIL PROTECTED]; Michael Sisolak [EMAIL PROTECTED] Cc: PHP DEV [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 8:44 PM Subject: Re: [PHP-DEV] What headers/libs does Win32 Snaps build use? There are a lot of them - that's likely to be the biggest issue. Nearly 20 megs of libraries (and this from some months ago). This is really Edin's territory... - Original Message - From: Christoph Grottolo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 7:31 PM Subject: Re: [PHP-DEV] What headers/libs does Win32 Snaps build use? Basically what I'm talking about is updating win32build.zip so that it has all the current libraries that are really used to do a PHP build on Win32. Is there a practical or licensing reason why that couldn't be done? Would it be a lot more work than just packaging up a few directories on the snaps machine? Michael Sisolak +1 on this - if my vote counts Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] branch compile problem - win32
Maybe this is know but on snaps there is an error : Next STABLE Win32 snapshot in: Win32 build failed. Consult compile.log for failure reason. Cvs build is ok. It should be fixed now (or on the next stable build to be precise). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?
Hello, Read-only GIF support has now been enabled in the windows version of the bundled GDLIB. Fixed version of php_gd2.dll compatible with PHP 4.3.0 will be available from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip in approx. 8 hours. Edin - Original Message - From: Brian Weil [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 05, 2003 6:31 PM Subject: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support? So... WIll gif support ever be available on win32? Can a patched gd.dll be found somewhere with readonly gif support or will we have to re-install php when the binary is updated? I've been (patiently) waiting for this since GD1.6. Thanks, Brian Rasmus Lerdorf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hrm.. Whoever built the Windows binary didn't define HAVE_GD_GIF_READ I guess. Or perhaps it should go into main/config.w32.h.in assuming we are always going to build the windows binary against the bundled gd library. -Rasmus On Fri, 3 Jan 2003, Zac Barton wrote: hi all, i thought php 4.3 was ment to have read-only access to gif images? all i get via phpinfo(); is: GD Support enabled GD Version bundled (2.0 compatible) FreeType Support enabled FreeType Linkage with freetype JPG Support enabled PNG Support enabled WBMP Support enabled wheres the gif read support? php 4.3 d/loaded via www.php.net so its the correct version.. what am i missing? does gif read support mean i can load a gif image then output it as a PNG? many thanks in advance zac barton -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
Could you please add a section for the branch (4.3.1?) in the news file. Isn't it already there? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
There is one for 4.4 (possibly to be renamed 5), but I don't see a 4.3.X section. Oh, that is in HEAD. We usually add all the branch changes into the brach version of the NEWS and merge them into HEAD once a new release has been made from the branch. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 binaries, CLI and PEAR
CLI was missing in the win32 distro by mistake. I have just updated the bin, but the problem is that the webserver at www.php.net still spits out the old binary. Since the file has correctly been rsynced I have to assume that this has to do with squid caching. Could someone from [EMAIL PROTECTED] have a look? Edin - Original Message - From: Pierre-Alain Joye [EMAIL PROTECTED] To: phpdev [EMAIL PROTECTED] Cc: peardev [EMAIL PROTECTED] Sent: Friday, December 27, 2002 8:14 PM Subject: [PHP-DEV] Win32 binaries, CLI and PEAR Hello, While checking the win32 binaries, I did not find any CLI, neither PEAR files. Any reason ? pierre -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 4.3.0 released
On Saturday 28 December 2002 00:16, Andi Gutmans wrote: I think you're right. I also see some weird language :) It was a mistake commit by one of the translators. It was corrected and the page will be shown in English again in a few hours (documentation build takes a lng time). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure
On Tuesday 24 December 2002 04:51, Moriyoshi Koizumi wrote: Edin Kadribasic [EMAIL PROTECTED] wrote: Isn't the solution as simple as changing the #ifdef to include COMPILE_DL_ZLIB in the checks, or is this another situation where the zlib extension should be compiled into the distribution itself? Is there a problem with doing that in the win32 build Edin? (it seems that the unix build will also have the same problems if zlib is built as a shared extension - there was even a bug report today about related issues). One of the solutions for the windows build is to compile zlib module into php4ts.dll statically. In that way all the problems go away and its a nice module to have built-in anyway. I have a patch ready and a test build of php4ts.dll at http://snaps.php.net/~edink/php4ts.dll-zlib.zip I've checked your test build, and it works fine as for Apache-1.3.27. But it still fails with Apache2... this seems another apache2filter problem. Anyway this solution sounds like a quickest and most reasonable way. Any objections to making zlib built-in extension on windows? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure
On Thursday 26 December 2002 21:14, Frank M. Kromann wrote: I think this is a good idea too, but on my system zlib.dll is required to run php.exe. If this is the case with the official build we might have a support issue. This could be a local problem with the way I compile the Zlib library ? Yes, you probably chose Win32 dynamic link library over Win32 static library when compiling zlib. Let me know if you want me to send you the libs I use on the snapshot/relese build machine. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure
Isn't the solution as simple as changing the #ifdef to include COMPILE_DL_ZLIB in the checks, or is this another situation where the zlib extension should be compiled into the distribution itself? Is there a problem with doing that in the win32 build Edin? (it seems that the unix build will also have the same problems if zlib is built as a shared extension - there was even a bug report today about related issues). One of the solutions for the windows build is to compile zlib module into php4ts.dll statically. In that way all the problems go away and its a nice module to have built-in anyway. I have a patch ready and a test build of php4ts.dll at http://snaps.php.net/~edink/php4ts.dll-zlib.zip Edin P.S. Make sure to remove extension=php_zlib.dll from your php.ini -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC4: ground rules
Should I commit a small fix to the Windows projects to avoid having the CGI and CLI produce php.exe to the same directory ? Andrei I think that we should include this small change in 4.3.0. It cannot possibly affect anything in the negative way and I will make sure that the files are correctly placed in the distribution. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ground rules
I have changed bundled php.ini-dist and php.ini-recommended to reflect these changes. Thanks for compilinng the list. Edin - Original Message - From: Christoph Grottolo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 21, 2002 10:40 PM Subject: [PHP-DEV] Re: ground rules Hi Andrei Zmievski wrote: Everyone, I have just released 4.3.0RC4. Despite the quote in my signature, I am determined to keep this one the very last final RC of the interminable 4.3.0 development cycle. Towards that end, I will closely monitor the CVS commits and revert any that do not satisfactorily explain what critical or showstopper bug they are fixing. There are inconsistencies in php.ini on windows: The following extensions are listed in the [extensions] part of php.ini, but are not dlivered with the distribution: - ctype (now built in) - cybercash (?) - dotnet (build failure since months) - ingres (build failure since months) - tokenizer (now built in) The following extensions are part of the distribution but not listed in php.ini - gd2 - mime_magic - msql - xmlrpc - zip Maybe you can correct this before 4.3.0. At least the missing GD2 is bad. Christoph -- 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] RC4 + windows
On Sunday 22 December 2002 00:51, Marcus Börger wrote: Hi, i can no longer load mhash and domxml dll's under windows RC4. marcus Rememberd to copy .dlls from dlls folder to a folder in PATH like c:\winnt\system32? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -+ [01]
On Thu, 19 Dec 2002, Zeev Suraski wrote: I disagree. For instance, if I helped writing the combined module, and someone separated it without thoroughly making sure that everyone is ok with this separation, I believe it's upto him to be responsible to merge it back in. What you suggest is that PHP will really be f(t), as people's resources change with time. I do not agree. I don't know if you're referring to cgi/cli separation, but in case you are let me just remind you that no one objected at the time. You were strongly in favor as well iirc. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CGI and CLI (compromise proposal)
After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Here is the patch against PHP_4_3 that implements the Unix side of changes. Edin On Thu, 19 Dec 2002, Andrei Zmievski wrote: This gets my complete support. Let's go ahead with the changes. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -Andrei http://www.gravitonic.com/ * The great thing about standards is that there are so many to choose from. * Index: configure.in === RCS file: /repository/php4/configure.in,v retrieving revision 1.396.2.15 diff -u -3 -p -r1.396.2.15 configure.in --- configure.in13 Dec 2002 13:34:37 - 1.396.2.15 +++ configure.in19 Dec 2002 16:45:38 - @@ -1081,7 +1081,11 @@ INLINE_CFLAGS=$INLINE_CFLAGS $standard_ CXXFLAGS=$CXXFLAGS $standard_libtool_flag all_targets='$(OVERALL_TARGET) $(PHP_MODULES) $(PHP_CLI_TARGET)' -install_targets=install-sapi install-modules $PHP_INSTALL_CLI_TARGET $install_pear +install_targets=install-sapi install-modules $install_pear +if test $PHP_SAPI != cgi; then + install_targets=$PHP_INSTALL_CLI_TARGET $install_targets +fi + PHP_SUBST(all_targets) PHP_SUBST(install_targets) Index: sapi/cgi/config9.m4 === RCS file: /repository/php4/sapi/cgi/config9.m4,v retrieving revision 1.1.2.2 diff -u -3 -p -r1.1.2.2 config9.m4 --- sapi/cgi/config9.m4 9 Dec 2002 17:25:01 - 1.1.2.2 +++ sapi/cgi/config9.m4 19 Dec 2002 16:45:38 - @@ -88,10 +88,10 @@ if test $PHP_SAPI = default; then PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/sapi/cgi/Makefile.frag) case $host_alias in *cygwin* ) -SAPI_CGI_PATH=sapi/cgi/php-cgi.exe +SAPI_CGI_PATH=sapi/cgi/php.exe ;; * ) -SAPI_CGI_PATH=sapi/cgi/php-cgi +SAPI_CGI_PATH=sapi/cgi/php ;; esac PHP_SUBST(SAPI_CGI_PATH) @@ -147,7 +147,7 @@ if test $PHP_SAPI = default; then AC_DEFINE_UNQUOTED(PHP_FCGI_STATIC, $PHP_FCGI_STATIC, [ ]) AC_MSG_RESULT($PHP_ENABLE_FASTCGI) -INSTALL_IT=\$(INSTALL) -m 0755 \$(SAPI_CGI_PATH) \$(INSTALL_ROOT)\$(bindir)/php-cgi +INSTALL_IT=\$(INSTALL) -m 0755 \$(SAPI_CGI_PATH) \$(INSTALL_ROOT)\$(bindir)/php PHP_SELECT_SAPI(cgi, program, $PHP_FCGI_FILES cgi_main.c getopt.c, -I$PHP_FCGI_INCLUDE,'$(SAPI_CGI_PATH)') case $host_alias in -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Just testing the patch... will be commiting shortly. Thanks anyway, Edin - Original Message - From: Frank M. Kromann [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Andrei Zmievski [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 6:44 PM Subject: Re: [PHP-DEV] CGI and CLI (compromise proposal) Edin, Are you doing the changes on Win32 also _ If not I'll make the changes. - Frank Here is the patch against PHP_4_3 that implements the Unix side of changes. Edin On Thu, 19 Dec 2002, Andrei Zmievski wrote: This gets my complete support. Let's go ahead with the changes. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -Andrei http://www.gravitonic.com/ * The great thing about standards is that there are so many to choose from. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
The merging of CLI and CGI will still happen, but in 4.3.1. I was not under the impression that this decision has been reached. In fact there were several people strongly opposed to the idea and I'm one of them. I have several reasons one of them being that having an interpreter which radically changes behavior depending on environmental variables is a bad idea IMHO. In practice this would mean that one would be unable to run php command line scripts from within webserver environment, through system() call from other cgi/php scripts etc. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Andi Gutmans wrote:
I doubt this will happen fast enough. We should just release the way we
released 4.2.x, which as far as I know was php for CGI and php-cli for
CLI
or am I a bit behind things? :)
Derick and I hashed it out on IRC and we have a proposal:
We should keep 4.2.x behavior with some modifications. CLI and CGI
should always be built unless disabled, and the executables should go
into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install'
target should be modified to detect whether the user is trying to
install either one of these SAPIs, output a warning message regarding
the potential naming problem, and stop. Let the user install CLI and CGI
manually, basically.
I really hope we can come to an agreement on this.
I can agree to, and live with, this to some extent. The changes I would
want on this would be...
* On win32, cli remains php-cli.exe. Windows users can rename the
executable if they feel it's necessary.
I think that this is acceptable to everyone since in this way week keep
status quo to 4.2.x releases.
* On other platforms, the cgi *is* installed by 'make install' by
default. To install cli something like, 'make install-cli', or
'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the
second option would be more usefull for installing both, using both
without [DIR] on one results in a configure error). A note regarding
what was installed and where should be added to the output resulting
from an install.
I really don't understand why insist on cgi being installed on make
install to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.
* Binaries are combined into a single binary in a later release. I'd be
happy to do this in January.
-1 for reasons i stated in my reply to Andrei.
* Documentation is added in regards to this issue.
Shane
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] PHP_AUTH_USER
I had discussed the issue with Rasmus and Jani some time ago and the concensus reached was only to disable PHP_AUTH_USER when safe mode is active. Nobody got around to do anything about it though. Is this still an acceptable solution? Edin - Original Message - From: Phil Driscoll [EMAIL PROTECTED] To: PHP QA [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 11:14 PM Subject: [PHP-QA] PHP_AUTH_USER I thought I'd better draw attention to the issues described at http://bugs.php.net/20441 I'm sure that the changes made to PHP in this respect are correct, but there is a BC issue which might affect lots of users, if my experience is typical. Cheers -- Phil Driscoll -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c
Sorry, I'm still unsure if my patch is the correct one, as I said in the first mail. As far as I've looked into it, the streams seem to be destructed and freed twice, once in deactivation and once in shutdown. If you think my patch is bogus, feel free to revert it unless I can give more reasonable explanation. I comitted tha patch and I'll revert it. Just to clarify one thing: constanst throuout PHP should be created as CONST_PERSISTENT? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Shane Caraveo wrote:
Edin Kadribasic wrote:
[snip]
I really don't understand why insist on cgi being installed on make
install to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.
It's realy very logical. It leaves the default installation the way
most people will expect it to behave, which is as it has been for years
now. Having the options allow people to modify that behaviour to the
way they want it to work. It's very flexable for all interests.
This seems to be matter of personal opinion.
I happen to belive that having cli in /usr/bin/php is a real improvement
over having cgi there. For command line scripts cli is
(nearly) a drop-in replacement for cgi. I am not aware of webserver
installs that use cgi in that location.
My great wish was to have the same freedom perl programmers have in
distributing scripts with #!/usr/bin/perl shebang line. Scripts that you
could nearly count on being executable on the target host. And scripts
that would always work, no matter from which context they were called.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring/exif/win32
Both 4.3 and Head still have a problem with mbstring not being default under win32. Exif module can be compiled but not loaded because it uses a function from mbstring. Exif tests for HAVE_MBSTRING and COMPILE_DL_MBSTRING. The question is why HAVE_MBSTRING is defined but COMPILE_DL_MBSTRING is undefined. I cannot see where HAVE_MBSTRING could be defined on win32. Several places use this line to check for its presence: #if HAVE_MBSTRING !defined(COMPILE_DL_MBSTRING) This works fine for say main/rfc1867.c. Does it work for you? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] distributing windows binaries (dll's) of PECL's
Hi, We already bundle several pecl extensions in the win32 distro (printer, iisfunc, etc.) I could add radius to the list. Edin - Original Message - From: Michael Bretterklieber [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 13, 2002 12:29 PM Subject: [PHP-DEV] distributing windows binaries (dll's) of PECL's Hi, I would like to distribute also binaries of my (our) radius PECL for windows, because Windows users usualy don't have visualstudio to compile the PECL. I would like to make a bin subdirectory and then for each php-version also a subdirectory: PECL/radius/bin PECL/radius/bin/php4.2.3/php_radius.dll My question is this allowed? Are there any other ideas howto distribute binaries of PECL's? bye, -- --- -- Michael Bretterklieber- [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 -- 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] distributing windows binaries (dll's) of PECL's
We already bundle several pecl extensions in the win32 distro (printer, iisfunc, etc.) I could add radius to the list. that would be great! But how can I provide upgrades of the PECL? then the user has to wait until a new php-version is released. That is a larger question. I'm afraid that there are no satisfactory aswers to it yet. PECL infrastructure is still pretty much non-existent. But you're welcome to help defining and implementing it :) Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
You are right. I verified Apache changes the cwd to / unless it's been launched in single process mode. And I found results could be different by cases, using DSO or using CGI executable. When you run your script with CGI executable and php.ini is also present in that directory, the PHP binary tries to read that one as mod_cgi tries to chdir to where the script is put. I'm not sure, but this appears to imply some security issues? At the time CLI was introduced I argued to remove . from php.ini search path, but that was not accepted because some people apparently use this feature for having different configurations for different virtual hosts. Therefore . was removed only from CLI's php.ini search path. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
No because it was preciselly because of cgi that CWD wasn't removed
from the php.ini search path. Have a look at the following thread:
http://www.zend.com/lists/php-dev/200202/msg01325.html
Edin
- Original Message -
From: Moriyoshi Koizumi [EMAIL PROTECTED]
To: Edin Kadribasic [EMAIL PROTECTED]
Cc: Derick Rethans [EMAIL PROTECTED]; Jani Taskinen
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, December 12, 2002 12:44 PM
Subject: Re: [PHP-DEV] Critical Bug #20887
At the time CLI was introduced I argued to remove . from php.ini
search path, but that was not accepted because some people
apparently use this feature for having different configurations
for
different virtual hosts.
Therefore . was removed only from CLI's php.ini search path.
This feature looks somewhat evil since it enables users to bypass
the safe
mode restrictions enforced by the administrator, or am I missing
something?
Anyway, the following patch should make sense for #20887?
Moriyoshi
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 11:22:17 -
@@ -272,7 +272,8 @@
/* Add cwd */
#ifdef INI_CHECK_CWD
- if (strcmp(sapi_module.name, cli)!=0) {
+ if (strcmp(sapi_module.name, cgi)==0
+ || strcmp(sapi_module.name,
cgi-fcgi)==0) {
if (*php_ini_search_path) {
strcat(php_ini_search_path,
paths_separator);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] BC issues in cgi
Since version 1.197 of the cgi_main.c, cgi sapi will identify itself as cgi-fcgi when compiled with fast cgi support (default on windows). This breaks some PHP scripts and some C code, like PHP's dl() function. IMHO this should be reverted to the old behavior regardless of the presence of fcgi code. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Placebo for bug #20539
Hi, Your patch seems to resolve the issue. I've applied it. Thanks, Edin - Original Message - From: Moriyoshi Koizumi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 5:56 AM Subject: [PHP-DEV] Placebo for bug #20539 Hi, Attached is a patch against the PHP_4_3 branch which appears to fix the bug #20539, while I haven't expected for this to be a cure at all. I guess destruction order of constants and resources have something to do with this issue. Moriyoshi -- 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.exe - php-cgi.exe
[snip]
Look, IMHO, it all boils down to the same simple points:
- No drawbacks to naming the PHP CLI as something different than
PHP (well,
unless you count the gut feeling of people who 'feel make install
should
install CLI in ${PREFIX}/bin/php', without really being able to
say why).
- Considerable drawbacks to changing the PHP CGI name. You may
argue that
the confusion this would cause is not as bad as I may think, but
you cannot
argue that it won't cause confusion. I'm a fairly competent user,
and it
still took me a few minutes to understand what was going on and
why. Suffice to say I came across less competent users.
The big drawback for me is the BC issue of changing all the command
line scripts that contain #!/usr/bin/php in them. I still see no
sense in putting a CGI binary there. Configuring a web server for
running CGI involves manual copy of the PHP binary anyway.
P.S. I wish people were following this list more closely so that
we don't
have to discuss same issues over and over again.
Unfortunately this is not an option for all of us at any given
time.
I, for one, do wish that the developers here employed a more
user-oriented
approach and less 'this should be changed cause it'll be
cool/neat/Right'
approach. This would do a lot of good for PHP.
I don't claim to hold a monopoly on what is a user-oriented
approach. I'd sure like to think that the changes implemented are
for the good of the user. Not because they're cool/neat/Right.
I agree that most of development done in PHP is geared towards the
web. That's what I do for living as well. But in the past 3 years
and about a dozen or so rather large PHP solutions later, I see that
the command line scripting mustn't be neglected either. Why write
backend processes in language other than PHP? Once we have developed
all the classes/libraries for the web solution it is obvious that
the easiest way to implemet the rest of the system is to re-use
those in command line (often run from cron) PHP scripts. And from
what I hear from other development houses, my experiences are far
from unique.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Tue, 10 Dec 2002, Zeev Suraski wrote:
I think that's a bit like inventing problems and then trying to fix them.
Let's keep it down to things we can determine relatively easily:
- Nothing bad will happen if we name the new CLI with whatever kind of name
- php-cli, phpsh, whatever
- There WILL be some level of confusion if we rename the CGI binary
If we use this KISS approach, why the heck are we even considering this rename?
The CGI sapi was first renamed to php-cgi on Feb 28, and the change was
temporarily reverted for the 4.2.x release because CLI sapi was
considered experimental.
The reason for the name change was discussed on php-dev back then and it
had to do with the fact that most people felt that make install should
install CLI in ${PREFIX}/bin/php. The goal was to make the php interpreter
installed on as many machines as possible. And for the reasons of keeping
BC CLI sapi was named php so that existing scripts that have
#!/usr/bin/php shebang line would not have to be modified. For the same
reason CLI silently ignores some command line options (like -q and -C).
The next logical questions was what to do with the CGI sapi. It made very
little sense to make install it under the same name in some different
folder, so a decision was reached to rename it to php-cgi. make install
and cgi make very little sense anyway since the installer has no way of
knowing what's the correct location for the binary. Configuring a server
for execution of php as a cgi requires manual configuration anyway.
Windows file rename merely mirrored that of the unix build.
I'm still of the oppinion that we should leave things as they are in PHP
4.3.0-dev for the reasons stated.
Edin
P.S. I wish people were following this list more closely so that we don't
have to discuss same issues over and over again.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fgetcsv problems was: register_shutdown_function = register_offline_function
Well, this goes back to my original problem with fgetcsv then. I can not find another application that will accept a CSV file that will allow mutliline quoted fields. They stop at the newline regardless. Now that's not true. Excel and other spreadsheet programs happily accept them. They also create multi-line quoted fields when exporting data that has newlines in them. And having PHP parse those correctly is one of the few ways getting data out of those apps. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Java Extension Build Method
Under the heading Build java module with -ljava you mention that there were crashing problems because libjava.so was linked agains pthread and apache wasn't. This is not uncommon problem for other libraries such as oci8. You can link apache with pthread which will prevent the segfaults. See oci8 manual page for instructions. Edin - Original Message - From: Tony J. White [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 7:35 PM Subject: [PHP-DEV] Java Extension Build Method The /ext/java module is an odd duck compared to other php extentions in that it uses DL_LOAD() to load libjava instead of being linked and that it is always built as a module (.so) instead of being built static into php. I've spent some time over the past couple weeks investigating why this is done and experimenting with different build methods. Although, i haven't come up with any breakthroughs in makeing the java extension build any other way, I've compiled some notes on the subject: http://tjw.org/php_java/build_notes.php I think I have a pretty good handle on why things are the way they are, but am I missing something? -Tony -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Multiple MSSQL Crashes in 4.3.0RC2
On Tue, 3 Dec 2002, Michael Sisolak wrote: Frank Kromann has investigated these issues and has made fixes in the CVS version of ext/mssql. Are these fixes merged into the branch? Just did that. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for bug #20539
Hi Sascha,
The attached patch fixes a crash in CLI when php.ini contains:
session.auto_start=1
magic_quotes_gpc=1
Could you please review it?
Edin
Index: session.c
===
RCS file: /repository/php4/ext/session/session.c,v
retrieving revision 1.336.2.1
diff -u -3 -p -r1.336.2.1 session.c
--- session.c 20 Nov 2002 17:49:57 - 1.336.2.1
+++ session.c 28 Nov 2002 13:06:46 -
@@ -1031,7 +1031,8 @@ PHPAPI void php_session_start(TSRMLS_D)
smart_str_appendc(var, '=');
smart_str_appends(var, PS(id));
smart_str_0(var);
- REGISTER_STRINGL_CONSTANT(SID, var.c, var.len, 0);
+ REGISTER_STRINGL_CONSTANT(SID, var.c, var.len, CONST_PERSISTENT |
+CONST_CS);
+ smart_str_free(var);
} else {
REGISTER_STRINGL_CONSTANT(SID, empty_string, 0, 0);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for bug #20539
Forget the patch, its not working well. The problem is that with session autostart SID constant gets defined in rinit and gets destroyed twice. Edin - Original Message - From: Edin Kadribasic [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 2:11 PM Subject: [PHP-DEV] Patch for bug #20539 Hi Sascha, The attached patch fixes a crash in CLI when php.ini contains: session.auto_start=1 magic_quotes_gpc=1 Could you please review it? Edin -- 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] [PATCH] Redirect on Error
And, most importantly, what the hell doi I care of losing 0.12 secs for a Fatal Error dysplay? I don't like the whole idea of having localized error messages. People have to use English when programming PHP anyway, and nobody is insane enough (yet) to suggest to translate function names. I don't think Parse error is any more difficult to understand than register_shutdown_function(). People use manual for understanding things like this. And I do care about unnecessary performance loss. But most of all I care about maintenance nightmare that this localization would put us in. If some of the pro-localization ever bother to read the php-bugs you would know that even a simple matter of using the correct .ini or .dll file can be too much for your target audience. Adding some CDB file to it is not going to help. The other side is maintaining the translation in the PHP code itself. This is just too large a task for the current team. I think it would be far more useful that some energy is spent on keeping PHP manual up to date so say our Italian users would have some clue about streams once PHP 4.3.0 hits the street. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
I've seen a big poster in my local Fullbright foundation represantive. It says something like : One of every four people on the earth knows some English. Why does Billy localize M$ windows then? And, most importantly, what would he sell without doing it? Remember, his users know basic IT english too. Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On Tue, 26 Nov 2002, Sascha Schumann wrote: Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. The language won't chance. Stop the FUD. This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On Tue, 26 Nov 2002, Sascha Schumann wrote: This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? You need to learn a bit about writing good compilers. It is easy to write a compiler; it is hard to write a compiler with good diagnostic output. You missed my point: you cannot write PHP code without using English. Function names, reserved words, etc. are all in English. So does this mean that non-English speaking people are unable to write PHP code? Of course not. With a good manual this is perfectly possible. IMHO error messages are no different. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20638 [Opn-Fbk]: Apache cannot start
On Tue, 26 Nov 2002, Jan Maska wrote: I'm experiencing the same problem. OS: Windows XP Apache 1.3.27 for Windows MySQL 3.23.53-win PHP 4.2.3 for Windows (php-4.2.3-Win32.zip) After I successfully installed Apache and MySQL, I tried to install PHP as module. Following the instructions of install.txt I got this result: Cannot load [path]/psp/sapi/php4apache.dll into server: module not found. The problem lies somewhere within the line 'LoadModule php4_module c:/[path]' - but if I look into the .dll the module is there.. Regards, Jan 'Mac' Maska P.S. No 'RTFMs', please.. this error was generated using your installation notes. M. The exact same setup works for me, so you probably missed something. Probably the part about putting php4ts.dll and the rest of files in the dlls folder into some directory in path (c:\windows\system32 for example). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] 4.30rc1 on Win32(2k) w/ Apache 1.3.27
Could you plase try the latest snapshot from snaps.php.net and report back on the result? Edin - Original Message - From: Lucas Nealan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 11:42 PM Subject: [PHP-QA] 4.30rc1 on Win32(2k) w/ Apache 1.3.27 Daily build 10-10-2002 of 4.30-dev was working for the most part fine for me. I've upgraded to rc1 and get the following error trying to execute a simple phpinfo() script named info.php: *** Warning: Unknown(/u\sr\local\www\v2\info.php): failed to create stream: No such file or directory in Unknown on line 0 ** My apache docroot is /usr/local/www/v2 which is working fine for non-php apache requests. I've rolled back to my 10-10-2002 cvs binary and it executes just fine. The questions seems to be where is the \ coming from after the /u\sr/ for the path to the php script? -screen http://brainkrash.com/ -- PHP Quality Assurance 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] Redirect on Error (not localisation)
On November 26, 2002 03:09 pm, John Coggeshall wrote: Unless told otherwise, I'm already planning on making a few changes and committing. -1 Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] 4.30rc1 on Win32(2k) w/ Apache 1.3.27
Daily stable build, php4-win32-STABLE-200211261730.zip, seems to work fine. Even looks like some other annoying bugs have finally been fixed. thanks for the quick response. Seeing a rc fail like that is kinda scary! Thanks for testing it. Timing of the RC1 was a bit unfortinate for the windows apache users, but the most important thing is that the problem is fixed :) Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move
+1
Anything that impoves stability of isapi at this point is more than welcome.
Hopefully bugs.php.net quickfix isapi instability will not have to be used
as often :)
Edin
- Original Message -
From: Michael Sisolak [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 25, 2002 7:32 PM
Subject: [PHP-DEV] [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move
While stess testing the recent threading fixes under the ISAPI module I
was seeing a lot of instability in IIS after the testing finished.
While the PHP pages would continue to load, no ASP pages would anymore.
I have tracked this down to the placement of the Win32 CoInitialize()
and CoUninitialize() calls. In the current 4.3.0 release candidate
CoInitialize() and CoUninitialize() are only called once per thread
(from the basic_globals_ctor/_dtor in basic_functions.c). According to
Microsoft, however, at
http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/devs0hm5.asp:
COM initialization, from CoInitialize or CoInitializeEx, affects the
thread in which it's called. For this reason, you cannot initialize COM
unless you uninitialize it before returning from your callback
function. [ . . .] CoInitialize and CoUninitialize need to be called in
order. If one is called twice in a row, by different ISAPIs on the same
thread, your users may see error 270.
This is exactly the error I am seeing: if I load an ASP page in a
thread that has processed PHP pages I get the 270 error (reported as
Error -2147417842 (0x8001010e)). I moved the CoInitilize call to
PHP_RINIT_FUNCTION(basic) and CoUninitialize to
PHP_RSHUTDOWN_FUNCTION(basic) and reran my stress testing. After
100,000 PHP page loads IIS now remains stable and able to process both
ASP and PHP pages.
I ran this by Zeev and he suggested that some kind of just-in-time COM
initialization, but I'm not going to have the time to get to this full
solution until later. In the meantime for 4.3.0 I request that the
attached patch is applied that moves the CoInitialize or CoInitializeEx
calls to be per-request. This is the last little fix that all the
multi-threading bug fixing to make the ISAPI rock solid in 4.3.0
requires. I've done a lot of testing and feel very confident about
including this patch.
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- basic_functions.c.orig Fri Nov 08 10:49:32 2002
+++ basic_functions.c Mon Nov 25 13:25:09 2002
@@ -959,10 +959,6 @@
memset(BG(url_adapt_state), 0, sizeof(BG(url_adapt_state)));
memset(BG(url_adapt_state_ex), 0, sizeof(BG(url_adapt_state_ex)));
-#ifdef PHP_WIN32
- CoInitialize(NULL);
-#endif
-
BG(incomplete_class) = php_create_incomplete_class(TSRMLS_C);
}
@@ -973,9 +969,6 @@
if (BG(sm_allowed_env_vars)) {
free(BG(sm_allowed_env_vars));
}
-#ifdef PHP_WIN32
- CoUninitialize();
-#endif
}
@@ -1102,6 +1095,10 @@
PHP_RINIT_FUNCTION(basic)
{
+#ifdef PHP_WIN32
+ CoInitialize(NULL);
+#endif
+
memset(BG(strtok_table), 0, 256);
BG(strtok_string) = NULL;
BG(strtok_zval) = NULL;
@@ -1182,6 +1179,10 @@
if (BG(mmap_file)) {
munmap(BG(mmap_file), BG(mmap_len));
}
+#endif
+
+#ifdef PHP_WIN32
+ CoUninitialize();
#endif
return SUCCESS;
--
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] Oracle 8.1.7
Does anyone have an access to any lower versions of Oracle Servers and Oracle Clients to compile and test from CVS? Especially Client. If so, please let me know. I've got access to Oracle 8.0.5 on Linux. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Oracle 8.1.7
That sounds very good. What version is your oracle client? The client is on the same Linux box, so the version is still 8.0.5. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Oracle 8.1.7
No go. OCIServerRelease seems not to be supported in Oracle 8.0:
ext/oci8/oci8.o: In function `zif_ociserverrelease':
ext/oci8/oci8.c:4551: undefined reference to `OCIServerRelease'
Edin
- Original Message -
From: Maxim Maletsky [EMAIL PROTECTED]
To: Edin Kadribasic [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, November 26, 2002 12:46 AM
Subject: Re: [PHP-DEV] Oracle 8.1.7
ok.
here is the patch as txt. It applies to the latest CVS of the file. But,
in any case - there is only that very function that is not documented
anywhere, and I wonder whether it works.
to test it, just run this:
?php
$conn = OCILogon('user', 'pass', 'listener');
echo \nServer version: . OCIServerVersion($conn);
echo \nServer release: . OCIServerRelease($conn);
/*
you should expect something like that. Important part is the last line -
release code
Server version: Oracle9i Enterprise Edition Release 9.0.1.1.0 - Production
With the Partitioning option
JServer Release 9.0.1.0.0 - Production
Server release: 150999296
*/
?
let me know.
---
Maxim Maletsky
[EMAIL PROTECTED]
On Tue, 26 Nov 2002 00:18:17 +0100 Edin Kadribasic [EMAIL PROTECTED]
wrote:
That sounds very good. What version is your oracle client?
The client is on the same Linux box, so the version is still 8.0.5.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP 4.3.0)
On Friday 22 November 2002 04:18, Jani Taskinen wrote: I can't remember that discussion..but why do we need yet another ini option? If the current behaviour is incorrect, and you can fix it..why do you even ask here? :) FYI: http://www.phpbuilder.com/mail/php-developer-list/2002092/0238.php http://bugs.php.net/bug.php?id=19207 Edin P.S. I don't like adding ini setting either, but I see no other way of solving the issue. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP 4.3.0)
Attached is a patch that fixes bug #19207 in accordance with previous
discussion on php-dev. It add cgi.rfc2616_headers ini option which is by
default set to off and mimics current 4.3.0 behaviour. If its set to on the
HTTP status line is sent in accordance to RFC2616 which was default for PHP
4.2.3 and earlier.
Any objections to commiting this fix?
Edin
diff -u -3 -p -r1.190.2.2 cgi_main.c
--- cgi_main.c 15 Nov 2002 00:33:18 - 1.190.2.2
+++ cgi_main.c 22 Nov 2002 00:12:20 -
@@ -241,8 +241,23 @@ static int sapi_cgi_send_headers(sapi_he
int len;
sapi_header_struct *h;
zend_llist_position pos;
-
- len = sprintf(buf, Status: %d\r\n, SG(sapi_headers).http_response_code);
+ long rfc2616_headers = 0;
+
+ /* Check wheater to send RFC2616 style headers compatible with
+* PHP versions 4.2.3 and earlier compatible with web servers
+* such as IIS. Default is informal CGI RFC header compatible
+* with Apache.
+*/
+ if (cfg_get_long(cgi.rfc2616_headers, rfc2616_headers) == FAILURE) {
+rfc2616_headers = 0;
+ }
+
+ if (rfc2616_headers SG(sapi_headers).http_status_line) {
+ len = sprintf(buf, %s\r\n, SG(sapi_headers).http_status_line);
+ } else {
+ len = sprintf(buf, Status: %d\r\n,
+SG(sapi_headers).http_response_code);
+ }
+
PHPWRITE_H(buf, len);
if (SG(sapi_headers).send_default_content_type) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: But why do you assume that the documentation was right and the code was wrong and not the other way around? Because it was working like documented before. (When the documentation was written). Anyway, not sure what to do with this one... I don't have the energy to do a cvs check, but I remember adding this restriction years ago (php2 days) and then removing it (by commenting out the check) ages ago as well. I'm not sure PHP4 ever had this check turned on (the commented out check was ported to php4), so the documentation has not reflected reality in a very long time. I agree that this change is going to break a lot of code. Some of it is my own :) I suggest that we always populate $PHP_AUTH_USER since that one has no security consequences and the information is awailable elsewhere ($_SERVER['REMOTE_USER']). $PHP_AUTH_PW should be set when there are no safe_mode/open_basedir restrctions in effects. Would this solution be satisfactory to everyone? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Bradford wrote: On a similar note, I posted a patch a few days ago which was intended for development environments - it makes error messages appear in a clear 'window' in the middle of the browser window, so that you don't have to hunt around in the output of the program to find it. I've attached it again, in case you're insterested. You were also told that this functionality can be achieved with error_prepend_string and error_append_string ini settings, so there is no real need for additional functionality. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Apache hooks link problem
I'm trying to make project files to make apache_hooks available on windows. However, I cannot get it to link properly. I'm getting 'php_request_startup_for_hook' undefined symbol error. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On Mon, 18 Nov 2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Marcus Börger wrote: Brian could you create a short test for the segfault? It would help us finding out the problems. For now I think it's very wise to remove all the e*() memory functions from the branch, it's not strictly needed and we need to be very careful not to emalloc data that should be preserved accross requests. That's why I've a patch read to remove the e*() stuff for the branch so that we have a lot of time for the 4.4/5.0 version to check all these things out. +1 I think it's the safest thing to do ATM. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 / configure.in /main php_version.h
I would love to see that happen. But in this special case it's not just a number. Maybe we should create a new CVS module, php5, to which we copy php4/* and let cvs co php5 automatically checkout TSRM and ZendEngine2 (as Zend, of course). You can do that without copying the repository. Currently the cvs alias for checking out ZE2 is php4-ze2 but I guess that can be changed to php5. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #20441 [Opn-Bgs]: PHP_AUTH_USER isn't set
Well actually you could. From the beginning of time up to 4.3.0. I
expect to see a lot of bug reports similar to this one.
Edin
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 15, 2002 10:10 AM
Subject: #20441 [Opn-Bgs]: PHP_AUTH_USER isn't set
ID: 20441
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: Redhat Linux 7.1 kernel 2.4.2-2
PHP Version: 4.3.0-pre2
New Comment:
You need to decide if you are using an external auth mechanism or
http
auth from php. You can't do both.
Previous Comments:
--
--
[2002-11-15 02:58:24] [EMAIL PROTECTED]
I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set
register
globals on in php.ini.
My Apache version is 1.3.24.
PHP configure:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-ftp --with-openssl
The script is using this .htaccess-file
AuthType Basic
AuthName 'Urenregistratie'
AuthUserFile /htpasswd/urenreg
require valid-user
I am sure that Apache is setting the PHP_AUTH_USER because the
following script gives the correct output:
// begin dirty hack
$headers = apache_request_headers();
foreach ($headers as $header = $value) {
if ($header == Authorization)
{
$value = str_replace( , , $value);
$value = str_replace(Basic, , $value);
$userArray = explode(:, base64_decode($value));
$PHP_AUTH_USER = $userArray[0];
}
}
echo $PHP_AUTH_USER;
// end dirty hack
If I echo $PHP_AUTH_USER or $_SERVER[PHP_AUTH_USER] above this
script
I am getting a empty result.
Note: the script was functioning 100% properly with php 4.2.3
--
--
--
Edit this bug report at http://bugs.php.net/?id=20441edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] snaps.php.net
Unfortunatelly we don't save the logs for each win32 build. Only for the latest one. It sort of make sense since there are situations where we need compile log even if the build failed. Edin - Original Message - From: Marcus Börger [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: PHP developer list [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 11:43 AM Subject: Re: [PHP-DEV] snaps.php.net Nice :-) Could we have the log files to each build (download) as an extra link? marcus At 02:09 14.11.2002, Edin Kadribasic wrote: Because of the creation of PHP_4_3 branch snaps.php.net was updated so that STABLE snapshots are made off that branch. Thanks to Ilia Alshanetsky we have a new pretty face on the snaps which can be seen at http://snaps.php.net/snaps.php My plan is to make this default look of the snaps.php.net in the next couple of days. Edin -- 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] mbstring and 4.3.0
For me it was the wide stream of bugreports coming in; can't speak for the others though. If the stream of bug reports was the criteria the whole of PHP should be considered highly experimental :) Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DBA and Win
Dba on windows now builds with db3, cdb, cdb_make and flatfile support. I didn't test it beyond building and loading. phpinfo shows that those handlers are active. I should probably run some test, but I don't know which? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows build and mbstrig
It seems the changes to make mbstring no longer a default module were a little bit unsophisticated ... mbstring is not included in default build but HAVE_MBSTING is defined. Therefor exif does not compile any longer. And there are problems in mbstring itself. See: http://snaps.php.net/win32/compile.log I've disabled it properly now. Also there is aproblem with the time display in the win32 directory of the snaps server. You should look at the file name. Time stamp there is in UTC timezone (MMDDHHmm). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php4apache on win32 regex problem?
..\..\regex needs to be included in the include path in php4apache.dsp. Edin - Original Message - From: Dave Viner [EMAIL PROTECTED] To: Php-Dev@lists. php. net [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 12:35 AM Subject: RE: [PHP-DEV] php4apache on win32 regex problem? after struggling some more, i've discovered that for some reason, in my php4apache compilation, the value of REGEX is set to 0. Therefore vc++ is trying to do: #if REGEX .. snip .. #elif REGEX == 0 #include regex.h #ifndef _REGEX_H_ #define _REGEX_H_ 1 #endif #endif i have updated my php cvs tree. i realize that the standard snap build doesn't have this problem, but i can't see why I have this problem. Can anyone offer advice on this? Or is there a win32 buildmeister that I could talk to off the list for help ? dave -Original Message- From: Dave Viner [mailto:dviner;yahoo-inc.com] Sent: Tuesday, November 12, 2002 2:35 PM To: Php-Dev@lists. php. net Subject: [PHP-DEV] php4apache on win32 regex problem? has anyone seen this error on win32 php4apache? Configuration: php4apache - Win32 Release_TS Compiling... mod_php4.c ..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file: 'regex.h': No such file or directory php_apache.c ..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file: 'regex.h': No such file or directory sapi_apache.c ..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file: 'regex.h': No such file or directory Error executing cl.exe. is there some cygwin package that I need to install in order to obtain the regex.h header file ? thanks dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build fails on bison: update
I hate to say it, but it works fine here (tm). Using bison 1.75 from cygwin.
Edin
- Original Message -
From: Maxim Maletsky [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 12:54 AM
Subject: Re: [PHP-DEV] build fails on bison: update
That does not happen, however, on PHP_4_3 tag.
So just FYI.
--
Maxim Maletsky
[EMAIL PROTECTED]
On Thu, 14 Nov 2002 00:40:00 +0100 Maxim Maletsky [EMAIL PROTECTED] wrote:
guys,
current W32 build has failed on bison for me with the parse error:
Configuration: TSRM - Win32
Release_TS
Compiling...
TSRM.c
tsrm_strtok_r.c
tsrm_virtual_cwd.c
tsrm_win32.c
Creating library...
Configuration: ZendTS - Win32
Release_TS
Performing Custom Build Step on .\zend_language_scanner.l
Compiling...
zend.c
zend_alloc.c
zend_API.c
zend_builtin_functions.c
zend_compile.c
Generating Code...
Compiling...
zend_constants.c
zend_dynamic_array.c
zend_execute.c
zend_execute_API.c
F:\CVS\PHP.NET\php4\Zend\zend_execute_API.c(366) : warning C4018: '==' :
signed/unsigned mismatch
zend_extensions.c
Generating Code...
Compiling...
zend_hash.c
zend_highlight.c
zend_indent.c
zend_ini.c
zend_ini_parser.c
Generating Code...
Compiling...
zend_ini_scanner.c
zend_language_parser.c
bison.simple(81) : error C2059: syntax error : '/'
bison.simple(83) : warning C4138: '*/' found outside of comment
bison.simple(189) : error C2449: found '{' at file scope (missing
function header?)
bison.simple(196) : error C2059: syntax error : '}'
bison.simple(248) : error C2449: found '{' at file scope (missing
function header?)
zend_language_parser.y(177) : error C2130: #line expected a string
containing the filename, found ''
zend_language_parser.y(358) : error C2005: #line expected a line number,
found 'identifier'
bison.simple(760) : error C2059: syntax error : '}'
zend_language_scanner.c
zend_language_scanner.c(5726) : warning C4273: 'isatty' : inconsistent
dll linkage. dllexport assumed.
zend_list.c
zend_llist.c
Generating Code...
Compiling...
zend_multibyte.c
zend_opcode.c
zend_operators.c
zend_ptr_stack.c
zend_qsort.c
Generating Code...
Compiling...
zend_sprintf.c
zend_stack.c
zend_variables.c
Generating Code...
Error executing cl.exe.
php.exe - 7 error(s), 3 warning(s)
--
Maxim Maletsky
[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
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] snaps.php.net
Because of the creation of PHP_4_3 branch snaps.php.net was updated so that STABLE snapshots are made off that branch. Thanks to Ilia Alshanetsky we have a new pretty face on the snaps which can be seen at http://snaps.php.net/snaps.php My plan is to make this default look of the snaps.php.net in the next couple of days. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Snaps
On Tuesday 12 November 2002 07:41, Derick Rethans wrote: On Tue, 12 Nov 2002, Edin Kadribasic wrote: Any objections to changing timestamp timezone on source snaps to UTC? Windows snapshots are already using it. Would be nice to have... Ok. From now on snapshot filename should contain timestamp with UTC timezone. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cvs: php4 /ext/standard flock_compat.c
correct the last patch: make flock() a function again when it is missing #function name should be flock and not php_flock of cause Nice. Now both PHP and ext/dba build correctly. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DBA and Win
On Tuesday 12 November 2002 13:36, Marcus Börger wrote: Could someone with windows please add bundled flatfile and cdb support for ext/dba to the windows build? Could you tell me which files need to be compiled and and which defines to be set? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] w32api extesion
On Tuesday 12 November 2002 15:31, James Moore wrote: jmooreTue Nov 12 09:31:35 2002 EDT Added files: /php4/ext/w32api w32api_function_definition_parser.y w32api_function_definition_scanner.l w32api_type_definition_parser.y w32api_type_definition_scanner.l This does not compile on the snapshot machine. Please have a look at http://snaps.php.net/win32/compile.log for details. Could it be it's because I'm using very recent bison version (1.75)? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: apache_hooks
Hrm.. That's not a bad idea. An ApacheHooks SAPI module sounds like the right approach to me. Would it be possible to load them both (ApacheHooks and mod_php) at the same time? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Openssl / DBA extensions broken on windows
Could the maintainers have a look? Details available at http://snaps.php.net/win32/compile.log Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] php-cli: option to ignore php.ini
On Mon, 11 Nov 2002, Wez Furlong wrote: What are your opinions for having some option to prevent the loading/parsing of php.ini for the CLI version of PHP? -n No Ini File - skips parsing php.ini on startup At the moment, I'm using -c DOESNOTEXIST to achieve the same result, but this is a bit hacky. +1 Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Snaps
On Monday 11 November 2002 23:07, James Cox wrote: I can certainly set this up. any preference for timeformat? (bearing in mind we use unix date) I use date -u +%Y%m%d%H00 for windows snapshots. It will show date in UTC. Is it possible to increase build time from 4 hours to 2 hours and use a time format that displays the timezone? Increase from 4 to 2 heh? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Snaps
On Monday 11 November 2002 23:14, Ilia A. wrote: On November 11, 2002 05:07 pm, James Cox wrote: I can certainly set this up. any preference for timeformat? (bearing in mind we use unix date) date -R | sed -e 's/ /_/g' Would be the best format IMHO. Nice format but it doesn't sort well in directory listings :) Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
