RE: [PHP-DEV] I hope this is the last email about this :)
-Original Message- From: Zeev Suraski [mailto:zeev;zend.com] Sent: 28 October 2002 02:06 Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. +1 Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: At 15:29 25/10/2002, Yasuo Ohgaki wrote: Are you going to set output_buffering=Off by default, too? Since the obscurity still exists with output buffers. It's even worse with broken output buffer function. Huh? It IS off by default. Of course I know it is off by default in php.ini-dist and code, but it is on by default in php.ini-recommended. If users have php.ini based on php.ini-recommended, there will be a default buffer. It does not make sense at all. I really don't understand why people are having problems to understand such intuitive issue. BTW, I don't object to have output_buffering=Off by default for CLI, since it's default of php.ini-dist and it does not make much sense for CLI. Its default in php.ini-dist is OFF. You might be mixing it with php.ini-recommended, which also comes with an explanation of what it would do, but either way, php.ini-recommended has much less exposure when compraed to php.ini-dist. Don't you want usable behavior with CLI? Even if users are using their web server php.ini? Use php.ini-recommended as your default, then you'll see. BTW, we should better to have a little different ini selection for CLI. For instance, /etc/phprc or php.ini ~/.phprc or php.ini which are standard locations of rc files under UNIX like systems. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Of course :) I vote -1 for it. It does not make sense to have it on by default which should be turn off almost always. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Implicit_flush=On by default
Zeev Suraski wrote: (B Thank you for the detailed explanation, I'm sure everybody (B understands it now. (B (BYou're welcome. (B (B Let's go for the voting phase. I vote we keep PHP-CLI (B with implicit_flush on by default. You vote against. (B (BOf course :) (BI vote -1 for it. (B (BIt does not make sense to have it on by default (Bwhich should be turn off almost always. (B (B-- (BYasuo Ohgaki (B (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
+1 FLUSH -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // PHP for Beginners www.maxim.cx // my Home // my Wish List: ( Get me something! ) http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3 Zeev Suraski [EMAIL PROTECTED] wrote... : Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- 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: [PHP-QA] php 4.3.0 pre2
At 05:47 28-10-2002, Tomki wrote: There is no getopt.h installed in any system directories, and my paths don't have anything other. The applications that have their own getopt.h in their source trees: mysql, apache, mod_ssl, openssh. Could you check main/php_config.h, to see if HAVE_GETOPT_LONG is set? And if so, the context of config.log to see where this is done? I think there's a conflict with one of those external apps, that defines HAVE_GETOPT_LONG. If there's no trace of HAVE_GETOPT_LONG being set in main/php_config.h, then that's the problem and we should probably use something like PHP_HAVE_GETOPT_LONG instead. There's also 1 other user, on a Mac system, with the same problem (#20131). At 03:46 10/28/2002 +0100, Melvyn Sopacua wrote: Tom, BSDi doesn't come with getopt.h, so you probably installed that afterwards, but you need to compile a shared libgetopt from getopt.c, and provide that to EXTRA_LIBS, to make it work. [1] OR if you have a source licence, recompile the kernel from source, with some careful hacks :) But - to make it work for now, please rename getopt.h. [1] Did that once with another package, but haven't tested this with php. At 02:29 28-10-2002, Tomki wrote: On BSDI i386, egcs 1.1.2 configure line: ./configure --enable-yp --enable-sockets --enable-memory-limit --with-mysql=/usr/local/mysql/ --with-imap=../imap-2002.RC8 --with-imap-ssl --with-ttf --with-gd --enable-ftp --with-gdbm --with-bz2=/usr --with-zlib --with-openssl --with-apxs=/usr/local/web/apache/bin/apxs --with-freetype-dir=/usr/local --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png-dir=/usr --enable-ftp --enable-db --enable-mbregex 'make' fails with: /bin/sh libtool --silent --mode=compile gcc -Iext/standard/ -I/usr/var/tmp/php-4.3.0pre2/ext/standard/ -DPHP_ATOM_INC -I/usr/var/tmp/php-4.3.0pre2/include -I/usr/var/tmp/php-4.3.0pre2/main -I/usr/var/tmp/php-4.3.0pre2 -I/usr/var/tmp/php-4.3.0pre2/Zend -I/usr/local/ssl/include -I/usr/local/include/freetype2 -I/usr/var/tmp/imap-2002.RC8/c-client -I/usr/local/mysql//include/mysql -I/usr/var/tmp/php-4.3.0pre2/ext/xml/expat -DMOD_SSL=208110 -DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT -DFD_SETSIZE=4096 -I/usr/var/tmp/php-4.3.0pre2/TSRM -g -O2 -prefer-pic -c /usr/var/tmp/php-4.3.0pre2/ext/standard/basic_functions.c -o ext/standard/basic_functions.lo /usr/var/tmp/php-4.3.0pre2/ext/standard/basic_functions.c:1377: warning: `struct option' declared inside parameter list Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
+1 to keep PHP-CLI with implicit_flush. Ilia On October 27, 2002 09:05 pm, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] hebrew patch for jewish calendar
i patched the jdtojewish() function to return the symbolic hebrew data (i.e.
ëá çùåï äúùñâ)
by second optional parameter.
could some1 commit that please?
thnxs
moshe.
begin 666 1.txt
M26YD97Z(5X=]C86QE;F1AB]C86QE;F1ABYC#0H]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]#0I20U,9FEL93H+W)E]S:71OGDOAP-]E'0O8V%L
M96YD87(O8V%L96YD87(N8RQV#0IR971R:65V:6YG(')E=FES:6]N(#$N,C8-
MF1I9F8+74+7(Q+C(V(-A;5N9%R+F,-BTM+2!E'0O8V%L96YD87(O
M8V%L96YD87(N8PDQ.2!397 ,C P,B R,3HU,3HS- M,# P, DQ+C(V#0HK
M*RL97AT+V-A;5N9%R+V-A;5N9%R+F,),C3V-T(#(P,#(,3,Z,#8Z
M,S,+3 P,# -D! (TS,RPV(LS,RPX($! #0H(VEN8VQU94(G!H%]C
M86QE;F1ABYH(T*(-I;F-L=61E()S9YC86PN:(-B -BLC:6YC;'5D
M92 \W1D:6\N:#X-BL#0H9G5N8W1I;VY?96YTGD8V%L96YD87)?9G5N
M8W1I;VYS6UT/2![#0H5!(4%]12AJ9'1O9W)E9V]R:6%N+!.54Q,*0T*
M( E02%!?1D4H9W)E9V]R:6%N=]J9P3E5,3D-D! (TQ,#L-B K,3$P
M+#D0$ -B!E;G5M7L0T%,7TU/3E1(7T=214=/4DE!3E]32$]25P0T%,
M7TU/3E1(7T=214=/4DE!3E],3TY'+ T*( E#04Q?34].5$A?2E5,24%.7U-(
M3U)4+!#04Q?34].5$A?2E5,24%.7TQ/3DL($-!3%]-3TY42%]*15=)4TL
M#0H4-!3%]-3TY42%]4D5.0T?3L-BL-BLO*B!F;W(:5B7VYU;6)E
ME]T;U]C:%RR J+PT**V-H87(86QE9E]B971;,C5=(#T(C#X+CY.7F
MY^CIZ^SN\/'R]/;W^/GZ(CL-B )#0H4$A07TU)3DE47T953D-424].*-A
M;5N9%R*0T*('L-D! (TS-S$L,C0*S,W-BPQ,3$0$ -B!]#0H+RH
M?7U](HO#0H#0HK+RH)#0HK6-A=71I;VXZ('1H92!H96)R979F]R;6%T
M('!R;V1U8W0;F]N('5N:7%U92!R97-U;'0N#0HK69OB!E%MQE()O
M=Z('EE87()S4G(%N9!Y96%R(U,# P)R!PF]D=6-T(?D)RX-BL)
M=7-E('1H92!N=6UEFEC(]N92!F;W(8V%L8W5L871I;VYS+B -BL*B\-
MBMC:%R(H:5B7VYU;6)EE]T;U]C:%RRAI;G0;BDPT**PD)8VAA
MB JP*F]L9P*G)E=#L-BL)0T**PD) ](5M86QL;V,H,3 I.PT*
M*PD);VQD(#T#L-BL-BL)2\J( T**PD)( ')E=F5N=',=AE(]P
M=EO;B!BF5A:VEN9R!T:4:F5W:7-H()E;EE9G,L(%N9!S;VUE(]T
M:5R( T**PD)( 8W)I=EC86PF5S;W5R8V5S(#LI#0HK0DJ+PT**PD)
M:68H;CXY.3DY?'QN/#$I(')E='5R;B!.54Q,.PT**PT**PD)+RH86QA9FEM
M(-AV4*B\-BL)6EF(AN(\,3 P,DPT**R ( ( ( (IP
M(#T86QE9E]B971;;B O(#$P,#!=.PT**PD)7 K*SL-BL)0EN(#T;B E
M(#$P,# [#0HK0E]#0HK#0HK0DO*B!T868M=%F(-AV4*B\-BL(
M( ('=H:6QE(AN(#X](#0P,DPT**R ( ( ( (IP(#T86QE
M9E]B971;,C)=.PT**PD)7 K*SL-BL)0EN+3TT,# [#0HK( ( (!]
M#0HK0D-BL)2\J(UE;W08V%S92 J+PT**R ( ( :68*X/CT
M,3 P*2![( T**R ( ( ( (IP(#T86QE9E]B971;,3K;B\Q,#!=
M.PT**PD)7 K*SL-BL( ( ( (!N(#T;B E(#$P,#L-BL(
M( ('T-BL)0T**PD)+RH=5T+79A=B!T970MF%I;B!C87-E(HO#0HK
M0EI9B H;CT],34?'P;CT],38I('L-BL)0DJ ](%L969?8F5T6SE=
M.PT**PD)7 K*SL-BL)0DJ ](%L969?8F5T6VXM.5T[#0HK0D)LK
M.PT**PD)?2!E;'-E('L-BL)0DO*B!AV%R;W08V%S92 J+PT**PD)6EF
M(AN(#X](#$P*27 K*SL-BL)0D);B ](X)2 Q,#L-BL( ( (
M(!]#0HK0D)#0HK0D)+RH65I:]T(-AV4*B\-BL)0EI9B H;B ^
M(# I('L-BL)0D)*G /2!A;5F7V)E=%MN73L-BL)0D)LK.PT**PD)
M7T-BL( ( ('T-BL( ( ( T**PD)*G /2 G7# G.PT**PD)
MF5T(#T96UA;QO8RH:6YT*2AP+6]L9DK,2D[#0HK0ES=')N8W!Y*')E
M=QO;0L*EN=DHUO;0I*S$I.PT**R ( ( F5T=7)N(')E=#L-
MBM]#0HK#0H+RHWM[('!R;W1O('-TFEN9R!J9'1O:F5W:7-H*EN=!J
M=6QI86YD87EC;W5N=D-B (!#;VYV97)TR!A(IU;EA;B!D87D8V]U
M;G0=\82!J97=IV8V%L96YD87(9%T92 J+PT*(!02%!?1E5.0U1)
M3TXH:F1T;VIE=VES:D#0HPT*+0EP=F%L(HJ:G5L9%Y.PT**PEL;VYG
M(IU;1A2P9FP[#0H6EN=!Y96%R+!M;VYT:P9%Y.PT*+0EC:%R
M(1A=5;,3!=.PT*+0T*+0EI9B HF5N9%]G971?%R86UE=5RU]EQ
M+ F:G5L9%Y*2 A/2!354-#15-3*2![#0HK6-H87(9%T95LQ,%TL(AE
M8F1A=5;,C5=.PT**PD-BL):68*%I%3D1?3E5-7T%21U,H*2 ]/2 Q*2![
M#0HK0EI9B HF5N9%]P87)S95]P87)A;65T97)S*#$5%-234Q37T-#+)L
M(BP)FIU;1A2D(3T4U5#0T534RDPT**PD)5)%5%523E]04Q313L-
MBL)7T-BL)69L/3 [#0HK7T96QS92!I9B H6D5.1%].54U?05)'4RI
M(#T](#(I('L-BL)6EF(AZ96YD7W!AG-E7W!AF%M971EG,H,B!44U)-
M3%-?0T,L(FQL(BP)FIU;1A2P)F9L*2 A/2!354-#15-3*25U)/3D=?4$%2
M04U?0T]53E0[#0H7T-B )#0HM6-O;G9EG1?=]?;]N9U]EAJ=6QD
M87DI.PT*( D-BT)4V1N5]*97=IVH6E],5D%,7U!0*IU;1A2DL(9Y
M96%R+ F;6]N=L(9D87DI.PT*+0ES')I;G1F*1A=4L((E:2\E:2\E
M:2(L(UO;G1H+!D87DL('EE87(I.PT*+0T*+0E215154DY?4U1224Y'*1A
M=4L(#$I.PT**PE39Y4;TIE=VES:AJ=6QD87DL(9Y96%R+ F;6]N=L
M(9D87DI.PT**PEI9BA9FPI('L-BL)7-PFEN=8H9%T92P(B5I+R5I
M+R5I(BP;6]N=L(1A2P65ABD[#0HK0E215154DY?4U1224Y'*1A
M=4L(#$I.PT**PE](5LV4PT**PD):68H65ACP],'Q\65ACXY.3DY
M*2![#0HK0D)AP7V5RF]R7V1O8W)E9BA.54Q,(%134DU,4U]#0RP15]7
M05).24Y'+ B3W5T(]F(')A;F=E('EE87(N(BD[#0HK0D)4D5455).7T9!
M3%-%.PT**PD)?0T**PD)#0HK0ES')I;G1F*AE8F1A=4L((ER ER E
MR(L(%P-BL)0D):5B7VYU;6)EE]T;U]C:%RRAD87DI+!#0HK0D)
M4IE=VES:$UO;G1H25B3F%M95MM;VYT:%TL(%P-BL)0D):5B7VYU;6)E
ME]T;U]C:%RRAY96%R*2D[#0HK0D-BL)5)%5%523E]35%))3DH:5B
M9%T92P,2D[#0HK0D-BL)?0T*('T-B O*B!]?7T*B\-B -DEN95X
M.B!E'0O8V%L96YD87(O:F5W:7-H+F,-CT]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T-E)#4R!F:6QE.B OF5P;W-I=]R2]P:' T+V5X=]C86QE;F1AB]J
M97=IVN8RQV#0IR971R:65V:6YG(')E=FES:6]N(#$N- T*9EF9B M=2 M
MC$N-!J97=IVN8PT*+2TM(5X=]C86QE;F1AB]J97=IVN8PDR($9E
M8B R,# R(#$Y.C(W.C,S(TP,# P3$N- T**RLK(5X=]C86QE;F1AB]J
M97=IVN8PDR.!/8W0,C P,B Q,SHP-CHS-B M,# P, T*0$ +3,Q,2PV
M(LS,3$L,C00$ -B )(D5L=6PB#0H?3L-B -BMC:%R(I*97=IVA-
M;VYT:$AE8DYA;65;,31=(#T-BM[#0HK2(B+ T**PDB^OGXZ2(L#0HK2+G
M^7O(BP-BL)(NOQ[.4B+ T**PDBZ.'Z(BP-BL)(OGAZ(L#0HK2+X_B
M+ T**PDB)^#C^#A(BP-BL)(O#I\\B+
Re: [PHP-DEV] hebrew patch for jewish calendar
Hello,
Can you please send the patch as attachment?
Derick
On Mon, 28 Oct 2002, moshe doron wrote:
i patched the jdtojewish() function to return the symbolic hebrew data (i.e.
ëá çùåï äúùñâ)
by second optional parameter.
could some1 commit that please?
thnxs
moshe.
begin 666 1.txt
M26YD97Z(5X=]C86QE;F1AB]C86QE;F1ABYC#0H]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]#0I20U,9FEL93H+W)E]S:71OGDOAP-]E'0O8V%L
M96YD87(O8V%L96YD87(N8RQV#0IR971R:65V:6YG(')E=FES:6]N(#$N,C8-
MF1I9F8+74+7(Q+C(V(-A;5N9%R+F,-BTM+2!E'0O8V%L96YD87(O
M8V%L96YD87(N8PDQ.2!397 ,C P,B R,3HU,3HS- M,# P, DQ+C(V#0HK
M*RL97AT+V-A;5N9%R+V-A;5N9%R+F,),C3V-T(#(P,#(,3,Z,#8Z
M,S,+3 P,# -D! (TS,RPV(LS,RPX($! #0H(VEN8VQU94(G!H%]C
M86QE;F1ABYH(T*(-I;F-L=61E()S9YC86PN:(-B -BLC:6YC;'5D
M92 \W1D:6\N:#X-BL#0H9G5N8W1I;VY?96YTGD8V%L96YD87)?9G5N
M8W1I;VYS6UT/2![#0H5!(4%]12AJ9'1O9W)E9V]R:6%N+!.54Q,*0T*
M( E02%!?1D4H9W)E9V]R:6%N=]J9P3E5,3D-D! (TQ,#L-B K,3$P
M+#D0$ -B!E;G5M7L0T%,7TU/3E1(7T=214=/4DE!3E]32$]25P0T%,
M7TU/3E1(7T=214=/4DE!3E],3TY'+ T*( E#04Q?34].5$A?2E5,24%.7U-(
M3U)4+!#04Q?34].5$A?2E5,24%.7TQ/3DL($-!3%]-3TY42%]*15=)4TL
M#0H4-!3%]-3TY42%]4D5.0T?3L-BL-BLO*B!F;W(:5B7VYU;6)E
ME]T;U]C:%RR J+PT**V-H87(86QE9E]B971;,C5=(#T(C#X+CY.7F
MY^CIZ^SN\/'R]/;W^/GZ(CL-B )#0H4$A07TU)3DE47T953D-424].*-A
M;5N9%R*0T*('L-D! (TS-S$L,C0*S,W-BPQ,3$0$ -B!]#0H+RH
M?7U](HO#0H#0HK+RH)#0HK6-A=71I;VXZ('1H92!H96)R979F]R;6%T
M('!R;V1U8W0;F]N('5N:7%U92!R97-U;'0N#0HK69OB!E%MQE()O
M=Z('EE87()S4G(%N9!Y96%R(U,# P)R!PF]D=6-T(?D)RX-BL)
M=7-E('1H92!N=6UEFEC(]N92!F;W(8V%L8W5L871I;VYS+B -BL*B\-
MBMC:%R(H:5B7VYU;6)EE]T;U]C:%RRAI;G0;BDPT**PD)8VAA
MB JP*F]L9P*G)E=#L-BL)0T**PD) ](5M86QL;V,H,3 I.PT*
M*PD);VQD(#T#L-BL-BL)2\J( T**PD)( ')E=F5N=',=AE(]P
M=EO;B!BF5A:VEN9R!T:4:F5W:7-H()E;EE9G,L(%N9!S;VUE(]T
M:5R( T**PD)( 8W)I=EC86PF5S;W5R8V5S(#LI#0HK0DJ+PT**PD)
M:68H;CXY.3DY?'QN/#$I(')E='5R;B!.54Q,.PT**PT**PD)+RH86QA9FEM
M(-AV4*B\-BL)6EF(AN(\,3 P,DPT**R ( ( ( (IP
M(#T86QE9E]B971;;B O(#$P,#!=.PT**PD)7 K*SL-BL)0EN(#T;B E
M(#$P,# [#0HK0E]#0HK#0HK0DO*B!T868M=%F(-AV4*B\-BL(
M( ('=H:6QE(AN(#X](#0P,DPT**R ( ( ( (IP(#T86QE
M9E]B971;,C)=.PT**PD)7 K*SL-BL)0EN+3TT,# [#0HK( ( (!]
M#0HK0D-BL)2\J(UE;W08V%S92 J+PT**R ( ( :68*X/CT
M,3 P*2![( T**R ( ( ( (IP(#T86QE9E]B971;,3K;B\Q,#!=
M.PT**PD)7 K*SL-BL( ( ( (!N(#T;B E(#$P,#L-BL(
M( ('T-BL)0T**PD)+RH=5T+79A=B!T970MF%I;B!C87-E(HO#0HK
M0EI9B H;CT],34?'P;CT],38I('L-BL)0DJ ](%L969?8F5T6SE=
M.PT**PD)7 K*SL-BL)0DJ ](%L969?8F5T6VXM.5T[#0HK0D)LK
M.PT**PD)?2!E;'-E('L-BL)0DO*B!AV%R;W08V%S92 J+PT**PD)6EF
M(AN(#X](#$P*27 K*SL-BL)0D);B ](X)2 Q,#L-BL( ( (
M(!]#0HK0D)#0HK0D)+RH65I:]T(-AV4*B\-BL)0EI9B H;B ^
M(# I('L-BL)0D)*G /2!A;5F7V)E=%MN73L-BL)0D)LK.PT**PD)
M7T-BL( ( ('T-BL( ( ( T**PD)*G /2 G7# G.PT**PD)
MF5T(#T96UA;QO8RH:6YT*2AP+6]L9DK,2D[#0HK0ES=')N8W!Y*')E
M=QO;0L*EN=DHUO;0I*S$I.PT**R ( ( F5T=7)N(')E=#L-
MBM]#0HK#0H+RHWM[('!R;W1O('-TFEN9R!J9'1O:F5W:7-H*EN=!J
M=6QI86YD87EC;W5N=D-B (!#;VYV97)TR!A(IU;EA;B!D87D8V]U
M;G0=\82!J97=IV8V%L96YD87(9%T92 J+PT*(!02%!?1E5.0U1)
M3TXH:F1T;VIE=VES:D#0HPT*+0EP=F%L(HJ:G5L9%Y.PT**PEL;VYG
M(IU;1A2P9FP[#0H6EN=!Y96%R+!M;VYT:P9%Y.PT*+0EC:%R
M(1A=5;,3!=.PT*+0T*+0EI9B HF5N9%]G971?%R86UE=5RU]EQ
M+ F:G5L9%Y*2 A/2!354-#15-3*2![#0HK6-H87(9%T95LQ,%TL(AE
M8F1A=5;,C5=.PT**PD-BL):68*%I%3D1?3E5-7T%21U,H*2 ]/2 Q*2![
M#0HK0EI9B HF5N9%]P87)S95]P87)A;65T97)S*#$5%-234Q37T-#+)L
M(BP)FIU;1A2D(3T4U5#0T534RDPT**PD)5)%5%523E]04Q313L-
MBL)7T-BL)69L/3 [#0HK7T96QS92!I9B H6D5.1%].54U?05)'4RI
M(#T](#(I('L-BL)6EF(AZ96YD7W!AG-E7W!AF%M971EG,H,B!44U)-
M3%-?0T,L(FQL(BP)FIU;1A2P)F9L*2 A/2!354-#15-3*25U)/3D=?4$%2
M04U?0T]53E0[#0H7T-B )#0HM6-O;G9EG1?=]?;]N9U]EAJ=6QD
M87DI.PT*( D-BT)4V1N5]*97=IVH6E],5D%,7U!0*IU;1A2DL(9Y
M96%R+ F;6]N=L(9D87DI.PT*+0ES')I;G1F*1A=4L((E:2\E:2\E
M:2(L(UO;G1H+!D87DL('EE87(I.PT*+0T*+0E215154DY?4U1224Y'*1A
M=4L(#$I.PT**PE39Y4;TIE=VES:AJ=6QD87DL(9Y96%R+ F;6]N=L
M(9D87DI.PT**PEI9BA9FPI('L-BL)7-PFEN=8H9%T92P(B5I+R5I
M+R5I(BP;6]N=L(1A2P65ABD[#0HK0E215154DY?4U1224Y'*1A
M=4L(#$I.PT**PE](5LV4PT**PD):68H65ACP],'Q\65ACXY.3DY
M*2![#0HK0D)AP7V5RF]R7V1O8W)E9BA.54Q,(%134DU,4U]#0RP15]7
M05).24Y'+ B3W5T(]F(')A;F=E('EE87(N(BD[#0HK0D)4D5455).7T9!
M3%-%.PT**PD)?0T**PD)#0HK0ES')I;G1F*AE8F1A=4L((ER ER E
MR(L(%P-BL)0D):5B7VYU;6)EE]T;U]C:%RRAD87DI+!#0HK0D)
M4IE=VES:$UO;G1H25B3F%M95MM;VYT:%TL(%P-BL)0D):5B7VYU;6)E
ME]T;U]C:%RRAY96%R*2D[#0HK0D-BL)5)%5%523E]35%))3DH:5B
M9%T92P,2D[#0HK0D-BL)?0T*('T-B O*B!]?7T*B\-B -DEN95X
M.B!E'0O8V%L96YD87(O:F5W:7-H+F,-CT]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T-E)#4R!F:6QE.B OF5P;W-I=]R2]P:' T+V5X=]C86QE;F1AB]J
M97=IVN8RQV#0IR971R:65V:6YG(')E=FES:6]N(#$N- T*9EF9B M=2 M
MC$N-!J97=IVN8PT*+2TM(5X=]C86QE;F1AB]J97=IVN8PDR($9E
M8B R,# R(#$Y.C(W.C,S(TP,# P3$N- T**RLK(5X=]C86QE;F1AB]J
M97=IVN8PDR.!/8W0,C P,B Q,SHP-CHS-B M,# P, T*0$ +3,Q,2PV
M(LS,3$L,C00$ -B
Re: [PHP-DEV] hebrew patch for jewish calendar
i did it (1.txt)
lets try again
moshe
Derick Rethans [EMAIL PROTECTED] wrote in message
news:Pine.LNX.4.44.0210281426290.30026-10;jdi.jdimedia.nl...
Hello,
Can you please send the patch as attachment?
Derick
On Mon, 28 Oct 2002, moshe doron wrote:
i patched the jdtojewish() function to return the symbolic hebrew data
(i.e.
ëá çùåï äúùñâ)
by second optional parameter.
could some1 commit that please?
thnxs
moshe.
begin 666 1.txt
M26YD97@Z(5X=]C86QE;F1AB]C86QE;F1ABYC#0H]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]#0I20U,@9FEL93H@+W)E]S:71OGDOAP-]E'0O8V%L
M96YD87(O8V%L96YD87(N8RQV#0IR971R:65V:6YG(')E=FES:6]N(#$N,C8-
MF1I9F8@+74@+7(Q+C(V(-A;5N9%R+F,-BTM+2!E'0O8V%L96YD87(O
M8V%L96YD87(N8PDQ.2!397 @,C P,B R,3HU,3HS- M,# P, DQ+C(V#0HK
M*RL@97AT+V-A;5N9%R+V-A;5N9%R+F,),C@@3V-T(#(P,#(@,3,Z,#8Z
M,S,@+3 P,# -D! (TS,RPV(LS,RPX($! #0H@(VEN8VQU94@(G!H%]C
M86QE;F1ABYH(@T*(-I;F-L=61E()S9YC86PN:(-B -BLC:6YC;'5D
M92 \W1D:6\N:#X-BL@#0H@9G5N8W1I;VY?96YTGD@8V%L96YD87)?9G5N
M8W1I;VYS6UT@/2![#0H@5!(4%]12AJ9'1O9W)E9V]R:6%N+!.54Q,*0T*
M( E02%!?1D4H9W)E9V]R:6%N=]J9P@3E5,3D-D! (TQ,#@L-B K,3$P
M+#D@0$ -B!E;G5M7L@0T%,7TU/3E1(7T=214=/4DE!3E]32$]25P@0T%,
M7TU/3E1(7T=214=/4DE!3E],3TY'+ T*( E#04Q?34].5$A?2E5,24%.7U-(
M3U)4+!#04Q?34].5$A?2E5,24%.7TQ/3DL($-!3%]-3TY42%]*15=)4T@L
M#0H@4-!3%]-3TY42%]4D5.0T@@?3L-BL-BLO*B!F;W(@:5B7VYU;6)E
ME]T;U]C:%RR J+PT**V-H87(@86QE9E]B971;,C5=(#T@(C#@X+CY.7F
MY^CIZ^SN\/'R]/;W^/GZ(CL-B )#0H@4$A07TU)3DE47T953D-424].*-A
M;5N9%R*0T*('L-D! (TS-S$L,C0@*S,W-BPQ,3$@0$ -B!]#0H@+RH@
M?7U](HO#0H@#0HK+RH)#0HK6-A=71I;VXZ('1H92!H96)R97@9F]R;6%T
M('!R;V1U8W0@;F]N('5N:7%U92!R97-U;'0N#0HK69OB!E%MQE()O
M=@Z('EE87(@)S4G(%N9!Y96%R(U,# P)R!PF]D=6-T(?D)RX-BL)
M=7-E('1H92!N=6UEFEC(]N92!F;W(@8V%L8W5L871I;VYS+B -BL@*B\-
MBMC:%R(H@:5B7VYU;6)EE]T;U]C:%RRAI;G0@;BD@PT**PD)8VAA
MB JP@*F]L9P@*G)E=#L-BL)0T**PD) ](5M86QL;V,H,3 I.PT*
M*PD);VQD(#T@#L-BL-BL)2\J( T**PD)( @')E=F5N=',@=AE(]P
M=EO;B!BF5A:VEN9R!T:4@:F5W:7-H()E;EE9G,L(%N9!S;VUE(]T
M:5R( T**PD)( @8W)I=EC86P@F5S;W5R8V5S(#LI#0HK0DJ+PT**PD)
M:68H;CXY.3DY?'QN/#$I(')E='5R;B!.54Q,.PT**PT**PD)+RH@86QA9FEM
M(-AV4@*B\-BL)6EF(AN(\@,3 P,D@PT**R @( @( @( @(IP
M(#T@86QE9E]B971;;B O(#$P,#!=.PT**PD)7 K*SL-BL)0EN(#T@;B E
M(#$P,# [#0HK0E]#0HK#0HK0DO*B!T868M=%F(-AV4@*B\-BL@( @
M( @('=H:6QE(AN(#X](#0P,D@PT**R @( @( @( @(IP(#T@86QE
M9E]B971;,C)=.PT**PD)7 K*SL-BL)0EN+3TT,# [#0HK( @( @(!]
M#0HK0D-BL)2\J(UE;W0@8V%S92 J+PT**R @( @( @:68@*X@/CT@
M,3 P*2![( T**R @( @( @( @(IP(#T@86QE9E]B971;,3@K;B\Q,#!=
M.PT**PD)7 K*SL-BL@( @( @( @(!N(#T@;B E(#$P,#L-BL@( @
M( @('T-BL)0T**PD)+RH@=5T+79A=B!T970MF%I;B!C87-E(HO#0HK
M0EI9B H;CT],34@?'P@;CT],38I('L-BL)0DJ ](%L969?8F5T6SE=
M.PT**PD)7 K*SL-BL)0DJ ](%L969?8F5T6VXM.5T[#0HK0D)LK
M.PT**PD)?2!E;'-E('L-BL)0DO*B!AV%R;W0@8V%S92 J+PT**PD)6EF
M(AN(#X](#$P*27 K*SL-BL)0D);B ](X@)2 Q,#L-BL@( @( @( @
M(!]#0HK0D)#0HK0D)+RH@65I:]T(-AV4@*B\-BL)0EI9B H;B ^
M(# I('L-BL)0D)*G @/2!A;5F7V)E=%MN73L-BL)0D)LK.PT**PD)
M7T-BL@( @( @('T-BL@( @( @( T**PD)*G @/2 G7# G.PT**PD)
MF5T(#T@96UA;QO8R@H:6YT*2AP+6]L9DK,2D[#0HK0ES=')N8W!Y*')E
M=QO;0L*EN=DHUO;0I*S$I.PT**R @( @( @F5T=7)N(')E=#L-
MBM]#0HK#0H@+RH@WM[('!R;W1O('-TFEN9R!J9'1O:F5W:7-H*EN=!J
M=6QI86YD87EC;W5N=D-B @(!#;VYV97)TR!A(IU;EA;B!D87D@8V]U
M;G0@=\@82!J97=IV@@8V%L96YD87(@9%T92 J+PT*(!02%!?1E5.0U1)
M3TXH:F1T;VIE=VES:D@#0H@PT*+0EP=F%L(HJ:G5L9%Y.PT**PEL;VYG
M(IU;1A2P@9FP[#0H@6EN=!Y96%R+!M;VYT:P@9%Y.PT*+0EC:%R
M(1A=5;,3!=.PT*+0T*+0EI9B HF5N9%]G971?%R86UE=5RU]E@Q
M+ F:G5L9%Y*2 A/2!354-#15-3*2![#0HK6-H87(@9%T95LQ,%TL(AE
M8F1A=5;,C5=.PT**PD-BL):68@*%I%3D1?3E5-7T%21U,H*2 ]/2 Q*2![
M#0HK0EI9B HF5N9%]P87)S95]P87)A;65T97)S*#$@5%-234Q37T-#+)L
M(BP@)FIU;1A2D@(3T@4U5#0T534RD@PT**PD)5)%5%523E]04Q313L-
MBL)7T-BL)69L/3 [#0HK7T@96QS92!I9B H6D5.1%].54U?05)'4R@I
M(#T](#(I('L-BL)6EF(AZ96YD7W!AG-E7W!AF%M971EG,H,B!44U)-
M3%-?0T,L(FQL(BP@)FIU;1A2P@)F9L*2 A/2!354-#15-3*25U)/3D=?4$%2
M04U?0T]53E0[#0H@7T-B )#0HM6-O;G9EG1?=]?;]N9U]EAJ=6QD
M87DI.PT*( D-BT)4V1N5]*97=IV@H6E],5D%,7U!0*IU;1A2DL(9Y
M96%R+ F;6]N=@L(9D87DI.PT*+0ES')I;G1F*1A=4L((E:2\E:2\E
M:2(L(UO;G1H+!D87DL('EE87(I.PT*+0T*+0E215154DY?4U1224Y'*1A
M=4L(#$I.PT**PE39Y4;TIE=VES:AJ=6QD87DL(9Y96%R+ F;6]N=@L
M(9D87DI.PT**PEI9B@A9FPI('L-BL)7-PFEN=8H9%T92P@(B5I+R5I
M+R5I(BP@;6]N=@L(1A2P@65ABD[#0HK0E215154DY?4U1224Y'*1A
M=4L(#$I.PT**PE](5LV4@PT**PD):68H65ACP],'Q\65ACXY.3DY
M*2![#0HK0D)AP7V5RF]R7V1O8W)E9BA.54Q,(%134DU,4U]#0RP@15]7
M05).24Y'+ B3W5T(]F(')A;F=E('EE87(N(BD[#0HK0D)4D5455).7T9!
M3%-%.PT**PD)?0T**PD)#0HK0ES')I;G1F*AE8F1A=4L((ER ER E
MR(L(%P-BL)0D):5B7VYU;6)EE]T;U]C:%RRAD87DI+!#0HK0D)
M4IE=VES:$UO;G1H25B3F%M95MM;VYT:%TL(%P-BL)0D):5B7VYU;6)E
ME]T;U]C:%RRAY96%R*2D[#0HK0D-BL)5)%5%523E]35%))3DH:5B
M9%T92P@,2D[#0HK0D-BL)?0T*('T-B O*B!]?7T@*B\-B -DEN95X
Re: [PHP-DEV] hebrew patch for jewish calendar
On Mon, 28 Oct 2002, moshe doron wrote: i did it (1.txt) Still no attachment but everything inline. Your mailer is apparently so braindead to include it inline. I want to bet it's Outlook... Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hebrew patch for jewish calendar
I received the attachment... you sure it's his mailer playing up? ;-) Mike --- Original Message --- From:Derick Rethans [EMAIL PROTECTED] To: moshe doron [EMAIL PROTECTED] Date:Mon, 28 Oct 2002 14:37:05 +0100 (CET) Subject: Re: [PHP-DEV] hebrew patch for jewish calendar On Mon, 28 Oct 2002, moshe doron wrote: i did it (1.txt) Still no attachment but everything inline. Your mailer is apparently so braindead to include it inline. I want to bet it's Outlook... Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 07:38 PM 10/28/02 +0900, Yasuo Ohgaki wrote: BTW, we should better to have a little different ini selection for CLI. For instance, /etc/phprc or php.ini ~/.phprc or php.ini which are standard locations of rc files under UNIX like systems. This I can agree with. I would prefer /etc/php.ini which I am already using. Rick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hebrew patch for jewish calendar
well...
u prob like more that format...
moshe
--
Derick Rethans [EMAIL PROTECTED] wrote in message
news:Pine.LNX.4.44.0210281435180.30026-10;jdi.jdimedia.nl...
On Mon, 28 Oct 2002, moshe doron wrote:
i did it (1.txt)
Still no attachment but everything inline.
Your mailer is apparently so braindead to include it inline. I want to
bet it's Outlook...
Derick
--
--
-
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the
c? ]-
begin 666 heb-calendar-patch.tar.gz
M'XL( 8^O3T``VAE8BUC86QE;F1ABUP871C:YT87(`[1AK;]MTE]IP/]A
MJD-C/4B+E7)EJ,@ABH_`ELV)/F:QH0%+6RF*-('A]V7%O_-;G6;8PO9P
MN$ORZ69W28JR) ?M!;DO'$CBG=V7CLS.Z,AZ4FZ9A*KK[F2H_GZ.FS@ZS(
MJ57I(1JA7VQ!F%O-3*9?D);FZL5$MK9K%1PKY:I26@+Y\XLRX'G:R[
MTDY_9%BY[N:;[MS\%JV1;Z$/%\8#JP^5D#\M(O1FX0#];TE7Z_PXKR^U
M!P:26I0=(ECP::^++H#)UR0%C\7QEV26^:Y!SPSH#%Q^85N@K)4J*\M]
M8S `*0#)I^0E%2I$7*,H6=(@#)5DN04FI;2BU]3)(U %3K=0*S7-J$
M8]WGFY7UFERIK:_SS2O+CQ^#M+XN5J OYOP^/'*,OS)L'0SZ!/(H)YJ3B8
MF5KS^A8N\5GD'R\\]/R^8:\-'^$D+L @L'0?#: 2RWO8XW5:-Y[]ASJ(68
MPLG^B;K;S+[H^_:92\YLU] L$5JGAXYQ'*\Y-LO^O$R5421-ZDFBB*+6UP5
M8@4CX0H:.X?JT7KNZ_NM9M[Q^V#G9;:V3]N=\6Y2X?'K3V1IPL/CD]G+LI
MG[DM/-IP=_3LT=MO-5F,?QMMH?P4\SP71B2GHI2]HBK^K:J#S77@WP1
MU^D0T%H#M4?\9Z4-:J:,_.KUWW_X\:GG]__O+VU]__?-?__[/^P\?,]N4
M%7ZIC8X.6@===?TU@'+RD6I#:_$Z\J8JF,9UZMB(JB%N-\8LRC=C
MQA^8B$BS(.A:0$^J!OZ04'E=D%%'VD^.*[=#]Y+/3PP#+^%A#T\P_36Z
MDI'7FHCQR30L_UA#2X)*K6ZL0J:U8]T!%78T*K/ZZRK8%'#LT#7$-'3'
M,7.A-GI@:LQSUJB,6/EYQDS:U@H7HZJ7A $CN(D+=-=)X\1NHV6V _#IJ8
MC#33M/6L(N?XB+BM!.FB@C=@3`(4FY^C6'I/4=JA0@-;1_DHCG\Z](!
M-X0,0TR\$2FM6/$!E7W9B.[AJ^@9I1V]F!JQ,/MG-LD2DG,8@:SW:0KB^
MMAXJ.3S`]=BOI^42S.U@3%Z'QXIV0M: (W)W B0@#S5./:Q.\Y5UQP
MH5P9:!5^S53XU3K#UM8$WP3?B/[%$',G%!1'J?%J!4FL-:JIYTVC/
M')@R'Q$;'\.9ZXWLE486[B7K[)9L(K*C.+)#0D++);%)[YTKIVSY_:8V
M1+VN;,#U-=!!)7)*85J:K5DCW#DG:19E#,1$7B%!Z@NYDY91HB@1F%VH0#
M7[HK`S-(Q4A2(5[IJ(VT*();@DQG!!#'NM_5;0[/\1V#0U)RMGWU.WF5
M(V-D)(*8!G\NZT@8P[F$@8T5DJ6[EQF$56D66 .4L0AC+,P2W?ITGRZNJ*
M9BS?!B1@YW63S86;YY$9AX0?6U2]T.D#AN0FC8UCEQ,5MHX3H@`C ,0$I:
MEVBA(W+/KL+P9_0)LQSPIX)SCFFCWP2-1IJ=I4[G8NP@#D]T05#::
M=448V98_%($C2SPO4G[/^*E+=)(UOHBGI?-717U$?.)Z*GF9541XPGG
MX*LZ=$X;C6:G$Q[J%#1)F7V@E8$XQ^*EOFZUOU-;ID;K3WNMDU!'OXS
M(F:-;#V28)Y5H-MI'QUVU$9#S)B9^^00A':S]INJ;L[AYWF)\)PLL\SP6
MALT4J?%JT)4Y'AP,S-\CU201MKB4$]VVCM':N/XM-5EQS?FMSP
M%WELG18Z8G$EIA.T+I]*VN_82[Y+?JX9^Q##DYB;!0..X#T(_!#NE03/
M08?V!UEZ9)DOC:*[)-)NHS(G@7^4FH4*?;/FCMA1O#8$M*$=ME/FOJ%-FO
MJ,VXG7Z?( 7A/CFLB.RH;LUN7K:SI@%VM\.K3F):YKNVK?UETRR-)+-G'(
MT%2?[K1;![3@RQP'/M@##7KC#!1UC*A, M=;TJW,#2HAZP#ZKW79@`YQ4S
M_/ B#[8(VJ.?=)KH4\^8[9Y?C\19K-HNZ9MEPLE)+ ^M$.?U8#PS??$.
M+*[N/\J3[=?99A(.M-[14M79)+^R=MFJE:MP[8S@3-\UV3C;=56FNBY%
M86V7PDIQ5H$+F:89F+2AHCTQ7MG-6RM@.( )SVDQ9(^/'][?AL.?/]S\
M(QS^\N[M33A\\_IC./KP^DTXO7#^WTBD-X';[\=OLN(O#J]C97;D_WX
MZ\U/$4*TZ=7;F[9E%N1S?E9P)Z!9AS\!JF]75K'.X,/RAP=^Q/V93F)1M
M[L%_5+'NI-6VW35-VC%/ ;=F2;6I\3RUK8Q8QLUL#K%+U(=!_4U@IKT5W
M))+WP+6Q^'FX\(PS;C[P%*AM$X/P:BYO@+QT#$]I[_(.[\!0$326=B(%K
M'@2F-2392BMU\KHR9N3/Q_FQ,!DXR=BH+I%0P!_JSP`SFVC#\DK@]4PMA!
MDB(;Y)V_L+/AXR-^$_7;\+K+][$B71MI)B=5#YT-)KLBRY-U(!@J335X
M49=A).(2AZX-$WNNL1M\(#WHF]FHK..7M\[6)9()WKS37]([__W_W$I
AI)!BFDD$(**:200@HII)!BFD\#GAOXO(][`* ``
`
end
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Removing of PHP_INI_PERDIR proposed (Was: setting PHP_INI_SYSTEM config. variables in VHost sections (bug 20009))
Me wrote: - I found out that it is not possible with current php stable version (4.2.3) - to define some configuration variables per virtual host - e.g. - upload_tmp_dir. - The upload_tmp_dir is masked ad PHP_INI_SYSTEM which allows changing - php_upload_dir in php.ini or in httpd's main config - not in VHost config, - which makes me unable to use different directories for each virtual web. - I think that is very bad. - The definition of PHP_INI_PERDIR allows changing variables in VHost sections - or in .htaccess files. I don't understand this - users are usually able to - configure .htaccess, which would allow them to overwrite settings in VHost - section of httpd's config. - I work with Apache, and with other http servers the situation can be - different (any way I would wonder as long this is a policy-problem, not - implementation problem). - Therefore I propose a change: - PHP_INI_SYSTEM variables should be allowed to change by admin - in - system-wide php.ini or httpd.conf, no matter if it's VHost or not. - PHP_INI_PERDIR would be then made useless and .htaccess things can be - checked with PHP_INI_USER. Either nobody read it, ot nobody has any comments. Could then PHP_INI_PERDIR be removed and all settings moved to PHP_INI_SYSTEM or PHP_INI_USER ? -- Matus fantomas Uhlar, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I don't wish to receive spam to this address. Varovanie: Nezelam si na tuto adresu dostavat akukolvek reklamnu postu. 42.7 percent of all statistics are made up on the spot. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing of PHP_INI_PERDIR proposed (Was: settingPHP_INI_SYSTEM config. variables in VHost sections (bug 20009))
On 28 Oct 2002, Matus fantomas Uhlar wrote: Either nobody read it, ot nobody has any comments. Could then PHP_INI_PERDIR be removed and all settings moved to PHP_INI_SYSTEM or PHP_INI_USER ? Removed? /me bangs head against wall Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing of PHP_INI_PERDIR proposed
Derick Rethans [EMAIL PROTECTED] wrote: - On 28 Oct 2002, Matus fantomas Uhlar wrote: - Either nobody read it, ot nobody has any comments. Could then PHP_INI_PERDIR - be removed and all settings moved to PHP_INI_SYSTEM or PHP_INI_USER ? - Removed? - /me bangs head against wall You probably haven't read my first post (This one was follow-up). If you have any reason not to remove that one, please send your objections. However I look at it, I found it useless. -- Matus fantomas Uhlar, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I don't wish to receive spam to this address. Varovanie: Nezelam si na tuto adresu dostavat akukolvek reklamnu postu. I feel like I'm diagonally parked in a parallel universe. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CLI ini selection
Let's put this in the right thread. At 14:34 28-10-2002, Rick Widmer wrote: At 07:38 PM 10/28/02 +0900, Yasuo Ohgaki wrote: BTW, we should better to have a little different ini selection for CLI. For instance, /etc/phprc or php.ini ~/.phprc or php.ini which are standard locations of rc files under UNIX like systems. This I can agree with. I would prefer /etc/php.ini which I am already using. +1 on /etc/php.ini being the equivalent of php_admin_value +1 on ~/.php.ini being the equavalent of php_value On windows this may clash bigtime though. The equivalent of /etc/php.ini would be WINNT\ini\php.ini or maybe %ALLUSERPROFILE\Application Data\Php Group\php.ini and ~/.php.ini would be %USERPROFILE%\Application Data\Php Group\php.ini. Yuk :) With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Yasuo, I think the picture is pretty clear now. There were no votes in favour of keeping it off, and at least half a dozen votes to keep it on. While I don't particularly like these ad-hoc votes, it appeared to be the only way to demonstrate to you that in this discussion, people are simply not buying into your reasoning, as reasonable as it may sound to you personally. Please revert. Zeev At 04:21 28/10/2002, Ilia A. wrote: +1 to keep PHP-CLI with implicit_flush. Ilia On October 27, 2002 09:05 pm, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On Mon, 28 Oct 2002, Zeev Suraski wrote: Yasuo, I think the picture is pretty clear now. There were no votes in favour of keeping it off, and at least half a dozen votes to keep it on. While I don't particularly like these ad-hoc votes, it appeared to be the only way to demonstrate to you that in this discussion, people are simply not buying into your reasoning, as reasonable as it may sound to you personally. full list: [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] -0 [EMAIL PROTECTED] +1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] -1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED]+1 total: +10.5 Please revert. Already done myself a few days ago. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI ini selection
We already have sapi specific ini files. If php finds
php-{$SAPI}.ini (e.g. php-cli.ini, php-apache.ini, etc) it will use
it instead of php.ini. IMHO this should cover most of the needs for
differentiated ini settings.
Edin
- Original Message -
From: Melvyn Sopacua [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 28, 2002 3:41 PM
Subject: [PHP-DEV] CLI ini selection
Let's put this in the right thread.
At 14:34 28-10-2002, Rick Widmer wrote:
At 07:38 PM 10/28/02 +0900, Yasuo Ohgaki wrote:
BTW, we should better to have a little different ini
selection for CLI.
For instance,
/etc/phprc or php.ini
~/.phprc or php.ini
which are standard locations of rc files under UNIX
like systems.
This I can agree with. I would prefer /etc/php.ini which I am
already using.
+1 on /etc/php.ini being the equivalent of php_admin_value
+1 on ~/.php.ini being the equavalent of php_value
On windows this may clash bigtime though. The equivalent of
/etc/php.ini
would be
WINNT\ini\php.ini or maybe %ALLUSERPROFILE\Application Data\Php
Group\php.ini and
~/.php.ini would be %USERPROFILE%\Application Data\Php
Group\php.ini.
Yuk :)
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
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] problem with EG(uninitialized_zval_ptr)
zee, andi - in threded mode we access (atleast) EG(uninitialized_zval_ptr) before it's initialized - BadIdea(tm) what happens is that (see assert.c as an example) OnChangeCallback gets called by the ini-mechanism before the executor is initialized. but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor anytime before init_executor will cause an UMR. i know that the startup-order is a very delicate thing so i'd like to check with you guys first if you have any ideas.. re, tc -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI ini selection
At 16:02 28-10-2002, Edin Kadribasic wrote:
We already have sapi specific ini files. If php finds
php-{$SAPI}.ini (e.g. php-cli.ini, php-apache.ini, etc) it will use
it instead of php.ini. IMHO this should cover most of the needs for
differentiated ini settings.
Except for the 'admin-override', which I kinda like and is consistent
with sapi/apache.
I couldn't care less about names and paths, but choosing a schema that
is already integrated into the environment seems logical to me.
Edin
- Original Message -
From: Melvyn Sopacua [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 28, 2002 3:41 PM
Subject: [PHP-DEV] CLI ini selection
Let's put this in the right thread.
At 14:34 28-10-2002, Rick Widmer wrote:
At 07:38 PM 10/28/02 +0900, Yasuo Ohgaki wrote:
BTW, we should better to have a little different ini
selection for CLI.
For instance,
/etc/phprc or php.ini
~/.phprc or php.ini
which are standard locations of rc files under UNIX
like systems.
This I can agree with. I would prefer /etc/php.ini which I am
already using.
+1 on /etc/php.ini being the equivalent of php_admin_value
+1 on ~/.php.ini being the equavalent of php_value
On windows this may clash bigtime though. The equivalent of
/etc/php.ini
would be
WINNT\ini\php.ini or maybe %ALLUSERPROFILE\Application Data\Php
Group\php.ini and
~/.php.ini would be %USERPROFILE%\Application Data\Php
Group\php.ini.
Yuk :)
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
TCA but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks TCA against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor TCA anytime before init_executor will cause an UMR. Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...) games than just EG(uninitialized_zval_ptr). So I guess calling zval_ptr_dtor before init_executor is unwise indeed... -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI ini selection
On Mon, Oct 28, 2002 at 04:02:42PM +0100, Edin Kadribasic wrote:
We already have sapi specific ini files. If php finds
php-{$SAPI}.ini (e.g. php-cli.ini, php-apache.ini, etc) it will use
it instead of php.ini. IMHO this should cover most of the needs for
differentiated ini settings.
I agree, this is probably enough.
But... doesn't this deserve a NEWS entry? I can't find one...
Sander
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote: TCA but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks TCA against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor TCA anytime before init_executor will cause an UMR. Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...) games than just EG(uninitialized_zval_ptr). So I guess calling zval_ptr_dtor before init_executor is unwise indeed... yep - but can we simply move init_executor a bit up? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
TCA yep - but can we simply move init_executor a bit up? I fear it's as up as it can be - just the start of zend_activate(). The problem, as it seems, is that some code can be called before zend_activate() - like INI handlers. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- 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 / run-tests.php
I guess we should add a --enable-mime-magic warning as well:
PHP Warning: mime_magic: can't read magic file in Unknown on line 0
FAIL ctype on integers [ext/ctype/tests/001.phpt]
PHP Warning: mime_magic: can't read magic file in Unknown on line 0
FAIL ctype on strings [ext/ctype/tests/002.phpt]
PHP Warning: mime_magic: can't read magic file in Unknown on line 0
And I also tested --enable-safe-mode (actually my co-worker André did :)
and it doesn't make any sence to warn. I think we should just bail out
if safe-mode is on or at least if putenv() fails, cause the results are
useless.
At 07:58 28-10-2002, Derick Rethans wrote:
On Mon, 28 Oct 2002, Jani Taskinen wrote:
+1 for removing both bogus settings. (html_errors log_errors)
Another one here then: +1 for reverting the changes.
Derick
On Sun, 27 Oct 2002, Ilia A. wrote:
I am curios as to your reasoning behind turning on html_errors by
default, why
would the tests need HTML data?
Logging of errors occurred during the tests seems pointless to me. As
I've
mentioned before if a test needs to check if a certain type of error is
generated the track_errors $php_errormsg facility can be used to
capture
this error reliably. Logging of errors is unreliable since the actual
error
message can go anywhere, stderr,syslog, user specified file, etc... It is
highly likely that you may not even see the error message because it
is not
sent to stderr. Data sent to the error log is also 'variable', because it
contains fluid data which different from system to system due to file
paths,
so we must do all kinds of hackery if we are to use it when confirming
the
output of a test.
I for one, would like to see that setting go away.
Ilia
P.S. The recent change to ini settings broken 9 tests, which worked
fine prior
to your change.
EUC-JP to ISO-2022-JP [ext/iconv/tests/eucjp2iso2022jp.phpt]
EUC-JP to SJIS [ext/iconv/tests/eucjp2sjis.phpt]
EUC-JP to UTF8 [ext/iconv/tests/eucjp2utf8.phpt]
iconv test [ext/iconv/tests/iconv001.phpt]
UCS4BE to ASCII [ext/iconv/tests/iconv002.phpt]
ob_output_handler [ext/iconv/tests/ob_iconv_handler.phpt]
HTML input/output [ext/mbstring/tests/htmlent.phpt]
rewriter handles form and fieldset correctly
[ext/session/tests/021.phpt]
Memoryleak in error printing [ext/xslt/tests/xslt-001.phpt]
On October 27, 2002 07:14 pm, Marcus Börger wrote:
First the tests take the nomal ini settings from any file found by
php...
Second there are some settings overwritten by run-test.php..
Third you can overwrite first and second by specifying an INI section in
the .phpt files.
Now to the setting log_errors i want this thing on because ANY
MESSAGE is either wanted or a REAL ERROR. The only test being
an exception to this rule is ext/session/tests/008-php4.2.3.phpt.
This test requires log_error to be set 0.
BEFORE REMOVING log_errors=1 again i want this beeing
discussed!
marcus
At 01:07 28.10.2002, Marcus Börger wrote:
helly Sun Oct 27 19:07:11 2002 EDT
Modified files:
/php4 run-tests.php
Log:
allow default ini overwrites to be overwritten themselves in --INI--
#see followup on dev list
Index: php4/run-tests.php
diff -u php4/run-tests.php:1.91 php4/run-tests.php:1.92
--- php4/run-tests.php:1.91 Sat Oct 26 12:54:30 2002
+++ php4/run-tests.php Sun Oct 27 19:07:11 2002
-480,28 +480,50
// Default ini settings
$settings = array (
- -d 'open_basedir=',
- -d 'disable_functions=',
- -d 'error_reporting=2047',
- -d 'display_errors=0',
- -d 'log_errors=0',
- -d 'html_errors=0',
- -d 'docref_root=/phpmanual/',
- -d 'docref_ext=.html',
- -d 'error_prepend_string=',
- -d 'error_append_string=',
- -d 'auto_append_file=',
- -d 'auto_prepend_file=',
+ open_basedir=,
+ disable_functions=,
+ error_reporting=2047,
+ display_errors=0,
+ log_errors=1,
+ html_errors=1,
+ track_errors=1,
+ docref_root=/phpmanual/,
+ docref_ext=.html,
+ error_prepend_string=,
+ error_append_string=,
+ auto_append_file=,
+ auto_prepend_file=,
);
- $ini_settings = ' '. join (' ', $settings);
+ $ini_settings = array();
+ foreach($settings as $setting) {
+ if (strpos($setting, '=')!==false) {
+ $setting = explode(=, $setting);
+ $name = trim(strtolower($setting[0]));
+ $value = trim($setting[1]);
+ $ini_settings[$name] = $value;
+ }
+ }
- // Any special ini
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
At 07:35 28/10/2002, Thies C. Arntzen wrote: On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote: TCA but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks TCA against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor TCA anytime before init_executor will cause an UMR. Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...) games than just EG(uninitialized_zval_ptr). So I guess calling zval_ptr_dtor before init_executor is unwise indeed... yep - but can we simply move init_executor a bit up? Probably not. Can you simply fix the OnChange callback? :) NULL up the ASSERTG(callback) on time? Zeev -- 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 /main streams.c
On Mon, 28 Oct 2002, Derick Rethans wrote: Hey Ilia, Does this prevent opening of things like block and character special files? If yes, then let's change it to explicitly check for directories instead, as there are bound to be people out there that want to open things like /dev/hda1 (for example). You want to open that for writing? :) That's what Real Programmers [TM] do. -Andrei http://www.gravitonic.com/ * If Bill Gates had a nickel for every time Windows crashed.. Oh, wait.. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
On Mon, Oct 28, 2002 at 05:49:44PM -0800, Zeev Suraski wrote: At 07:35 28/10/2002, Thies C. Arntzen wrote: On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote: TCA but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks TCA against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor TCA anytime before init_executor will cause an UMR. Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...) games than just EG(uninitialized_zval_ptr). So I guess calling zval_ptr_dtor before init_executor is unwise indeed... yep - but can we simply move init_executor a bit up? Probably not. Can you simply fix the OnChange callback? :) NULL up the ASSERTG(callback) on time? it is(!) nulled in the globals_ctor. the problem is that the OnChange gets called quite a few times (tested in cli-mode). and the 2nd call will dtor the empty value set by the 1st call. also i don't really think that assert.c is the deal here, the real problem is that we might use parts of the engine too early in many places in the code that i haven't spotted so far. (and it's a _very_ hard to find thing - i found it using valgrind) re, tc Zeev -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- 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 / run-tests.php
First of all only some tests in ext/xslt were designed to present a warning.
I suggest this can be fixed by adding a --INI-- section disabling the error
messages.
Second i did another commit to direct logs to stderr so the errors are shown
in the output. So i do not see any problem here.
Third i guess we have two options:
a) Set error_log and such Off, track_errors=On and 'magically'
prepend echo $php_errormsg at each --FILE-- section. But as you can see
above there are tests that expect such messages so this would be a bit
complicated.
b) Leave it as it is now (of cause my favorite). Since now every warning/error
and not wanted message results in a test failure! According to iconv tests
i do not know by now if disabling the notices in the tests was a good idea.
regards
marcus
At 07:58 28.10.2002, Derick Rethans wrote:
On Mon, 28 Oct 2002, Jani Taskinen wrote:
+1 for removing both bogus settings. (html_errors log_errors)
Another one here then: +1 for reverting the changes.
Derick
On Sun, 27 Oct 2002, Ilia A. wrote:
I am curios as to your reasoning behind turning on html_errors by
default, why
would the tests need HTML data?
Logging of errors occurred during the tests seems pointless to me. As
I've
mentioned before if a test needs to check if a certain type of error is
generated the track_errors $php_errormsg facility can be used to
capture
this error reliably. Logging of errors is unreliable since the actual
error
message can go anywhere, stderr,syslog, user specified file, etc... It is
highly likely that you may not even see the error message because it
is not
sent to stderr. Data sent to the error log is also 'variable', because it
contains fluid data which different from system to system due to file
paths,
so we must do all kinds of hackery if we are to use it when confirming
the
output of a test.
I for one, would like to see that setting go away.
Ilia
P.S. The recent change to ini settings broken 9 tests, which worked
fine prior
to your change.
EUC-JP to ISO-2022-JP [ext/iconv/tests/eucjp2iso2022jp.phpt]
EUC-JP to SJIS [ext/iconv/tests/eucjp2sjis.phpt]
EUC-JP to UTF8 [ext/iconv/tests/eucjp2utf8.phpt]
iconv test [ext/iconv/tests/iconv001.phpt]
UCS4BE to ASCII [ext/iconv/tests/iconv002.phpt]
ob_output_handler [ext/iconv/tests/ob_iconv_handler.phpt]
HTML input/output [ext/mbstring/tests/htmlent.phpt]
rewriter handles form and fieldset correctly
[ext/session/tests/021.phpt]
Memoryleak in error printing [ext/xslt/tests/xslt-001.phpt]
On October 27, 2002 07:14 pm, Marcus Börger wrote:
First the tests take the nomal ini settings from any file found by
php...
Second there are some settings overwritten by run-test.php..
Third you can overwrite first and second by specifying an INI section in
the .phpt files.
Now to the setting log_errors i want this thing on because ANY
MESSAGE is either wanted or a REAL ERROR. The only test being
an exception to this rule is ext/session/tests/008-php4.2.3.phpt.
This test requires log_error to be set 0.
BEFORE REMOVING log_errors=1 again i want this beeing
discussed!
marcus
At 01:07 28.10.2002, Marcus Börger wrote:
helly Sun Oct 27 19:07:11 2002 EDT
Modified files:
/php4 run-tests.php
Log:
allow default ini overwrites to be overwritten themselves in --INI--
#see followup on dev list
Index: php4/run-tests.php
diff -u php4/run-tests.php:1.91 php4/run-tests.php:1.92
--- php4/run-tests.php:1.91 Sat Oct 26 12:54:30 2002
+++ php4/run-tests.php Sun Oct 27 19:07:11 2002
-480,28 +480,50
// Default ini settings
$settings = array (
- -d 'open_basedir=',
- -d 'disable_functions=',
- -d 'error_reporting=2047',
- -d 'display_errors=0',
- -d 'log_errors=0',
- -d 'html_errors=0',
- -d 'docref_root=/phpmanual/',
- -d 'docref_ext=.html',
- -d 'error_prepend_string=',
- -d 'error_append_string=',
- -d 'auto_append_file=',
- -d 'auto_prepend_file=',
+ open_basedir=,
+ disable_functions=,
+ error_reporting=2047,
+ display_errors=0,
+ log_errors=1,
+ html_errors=1,
+ track_errors=1,
+ docref_root=/phpmanual/,
+ docref_ext=.html,
+ error_prepend_string=,
+ error_append_string=,
+ auto_append_file=,
+ auto_prepend_file=,
);
- $ini_settings = ' '. join (' ', $settings);
+ $ini_settings = array();
+ foreach($settings as $setting) {
+ if (strpos($setting, '=')!==false) {
+ $setting = explode(=, $setting);
+ $name =
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php
On Mon, 28 Oct 2002, Marcus Börger wrote: Second i did another commit to direct logs to stderr so the errors are shown in the output. So i do not see any problem here. Not necessarily..for me stderr goes to /var/log/messages, iirc. :) b) Leave it as it is now (of cause my favorite). Since now every warning/error and not wanted message results in a test failure! According to iconv tests i do not know by now if disabling the notices in the tests was a good idea. Any warning/error in a test is supposed to fail the damn test! That's the whole point of regression tests. Or did I misunderstand the point of these tests?? Can we please stop modifying this one script..and have ONE person doing that? Otherwise this mess will get worse. --Jani -- 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 / run-tests.php
At 18:24 28-10-2002, Marcus Börger wrote:
Second i did another commit to direct logs to stderr so the errors are shown
in the output. So i do not see any problem here.
I don't get it - display_errors=on works independantly from log_errors.
Why do we need logs?
[EMAIL PROTECTED] ~
$ /phpcvs/bin/php -f test.php
=== Log errors on
[28-Oct-2002 18:48:21] PHP Notice: Undefined variable: foo in
/home/msopacua/test.php on line 7
Notice: Undefined variable: foo in /home/msopacua/test.php on line 7
/home/msopacua/test.php(7) : Notice - Undefined variable: foo
=== Log errors off
Notice: Undefined variable: foo in /home/msopacua/test.php on line 10
/home/msopacua/test.php(10) : Notice - Undefined variable: foo
[EMAIL PROTECTED] ~
$ cat test.php
?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('error_log', '/dev/stderr');
echo === Log errors on\n\n;
ini_set('log_errors', TRUE);
echo $foo;
ini_set('log_errors', FALSE);
echo === Log errors off\n\n;
echo $foo;
?
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
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 / run-tests.php
Hmm since it seems i am the only one wanting to take only the log version
of the messages i think we can leave it like it is now (with log_errors=0).
The reason i wanted log_errors=1 was that i simply wanted one single
additional line in the .diff files whatever is configured elsewhere.
marcus
At 18:50 28.10.2002, Melvyn Sopacua wrote:
At 18:24 28-10-2002, Marcus Börger wrote:
Second i did another commit to direct logs to stderr so the errors are shown
in the output. So i do not see any problem here.
I don't get it - display_errors=on works independantly from log_errors.
Why do we need logs?
[EMAIL PROTECTED] ~
$ /phpcvs/bin/php -f test.php
=== Log errors on
[28-Oct-2002 18:48:21] PHP Notice: Undefined variable: foo in
/home/msopacua/test.php on line 7
Notice: Undefined variable: foo in /home/msopacua/test.php on line 7
/home/msopacua/test.php(7) : Notice - Undefined variable: foo
=== Log errors off
Notice: Undefined variable: foo in /home/msopacua/test.php on line 10
/home/msopacua/test.php(10) : Notice - Undefined variable: foo
[EMAIL PROTECTED] ~
$ cat test.php
?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('error_log', '/dev/stderr');
echo === Log errors on\n\n;
ini_set('log_errors', TRUE);
echo $foo;
ini_set('log_errors', FALSE);
echo === Log errors off\n\n;
echo $foo;
?
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
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] berkeley db and dba
Hi, I noticed that the ext/dba extension allows me to use Berkeley DB. I'm interested in using some of the newer features in Berkeley DB v4 (sleepycat's latest release). In particular, there are a set of features regarding a db environment. See http://www.sleepycat.com/docs/ref/env/intro.html for more information if you're interested. Basically the things that really attract me to this are the memory pools that might allow multiple apache processes to use shared memory (file-backed or system memory) for caching data. But the dba extension doesn't seem to provide any hooks for these calls, or other db-specific functions. What is the best way for me to get access to these functions? thanks dave viner -- 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 /build buildcheck.sh
At 07:07 AM 10/28/2002 +0100, Sebastian Bergmann wrote:
Andi Gutmans wrote:
Engine 2 doesn't seem to work with 1.28.
How does this show?
?
function getFrontendObject()
{
$a = new $GLOBALS['_PEAR_Command_uiclass'];
}
?
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] berkeley db and dba
You can either provide patches and check back with the current maintainer (if any or apply for an account yourself) or open a bug report (feature reqest) about it at bugs.php.net On Mon, Oct 28, 2002 at 11:37:37AM -0800, David Viner wrote : Hi, I noticed that the ext/dba extension allows me to use Berkeley DB. I'm interested in using some of the newer features in Berkeley DB v4 (sleepycat's latest release). In particular, there are a set of features regarding a db environment. See http://www.sleepycat.com/docs/ref/env/intro.html for more information if you're interested. Basically the things that really attract me to this are the memory pools that might allow multiple apache processes to use shared memory (file-backed or system memory) for caching data. But the dba extension doesn't seem to provide any hooks for these calls, or other db-specific functions. What is the best way for me to get access to these functions? thanks dave viner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc $ grep docref_root php.ini docref_root = http://landonize.it/?how=urltheme=classicfilter=RichyHuser=imajesurl=http%3A%2F%2Fphp.net%2F/; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
At 05:40 PM 10/28/2002 +0200, Stanislav Malyshev wrote: TCA yep - but can we simply move init_executor a bit up? I fear it's as up as it can be - just the start of zend_activate(). The problem, as it seems, is that some code can be called before zend_activate() - like INI handlers. Right and actually one shouldn't be emalloc()'ing not calling zval_ptr_dtor() when not in a request. Maybe the problem is the extension itself. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] php 4.3.0 pre2
Yes, it is set.. #define HAVE_GETOPT_LONG 1 as well as #define HAVE_GETOPT 1 #define HAVE_GETOPT_LONG_ONLY 1 I have a feeling that the compile tests are succeeding because of the getopt.h linked in from mysql.. configure:66328: checking for getopt_long configure:66356: gcc -o conftest -g -O2 -DMOD_SSL=208110 -DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT -DFD_SETSIZE=4096 -Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib -Wl,-rpath,/usr/var/tmp/imap-2002.RC8/c-client -L/usr/var/tmp/imap-2002.RC8/c-client -Wl,-rpath,/usr/local/mysql//lib -L/usr/local/mysql//lib conftest.c -lmysqlclient -lfreetype -lpng -lz -ljpeg -lgdbm -lbz2 -lz -lssl -lcrypto -lm -ldl 15 configure:66328: checking for getopt_long_only configure:66356: gcc -o conftest -g -O2 -DMOD_SSL=208110 -DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT -DFD_SETSIZE=4096 -Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib -Wl,-rpath,/usr/var/tmp/imap-2002.RC8/c-client -L/usr/var/tmp/imap-2002.RC8/c-client -Wl,-rpath,/usr/local/mysql//lib -L/usr/local/mysql//lib conftest.c -lmysqlclient -lfreetype -lpng -lz -ljpeg -lgdbm -lbz2 -lz -lssl -lcrypto -lm -ldl 15 At 12:04 10/28/2002 +0100, Melvyn Sopacua wrote: At 05:47 28-10-2002, Tomki wrote: There is no getopt.h installed in any system directories, and my paths don't have anything other. The applications that have their own getopt.h in their source trees: mysql, apache, mod_ssl, openssh. Could you check main/php_config.h, to see if HAVE_GETOPT_LONG is set? And if so, the context of config.log to see where this is done? I think there's a conflict with one of those external apps, that defines HAVE_GETOPT_LONG. If there's no trace of HAVE_GETOPT_LONG being set in main/php_config.h, then that's the problem and we should probably use something like PHP_HAVE_GETOPT_LONG instead. There's also 1 other user, on a Mac system, with the same problem (#20131). At 03:46 10/28/2002 +0100, Melvyn Sopacua wrote: Tom, BSDi doesn't come with getopt.h, so you probably installed that afterwards, but you need to compile a shared libgetopt from getopt.c, and provide that to EXTRA_LIBS, to make it work. [1] OR if you have a source licence, recompile the kernel from source, with some careful hacks :) But - to make it work for now, please rename getopt.h. [1] Did that once with another package, but haven't tested this with php. At 02:29 28-10-2002, Tomki wrote: On BSDI i386, egcs 1.1.2 configure line: ./configure --enable-yp --enable-sockets --enable-memory-limit --with-mysql=/usr/local/mysql/ --with-imap=../imap-2002.RC8 --with-imap-ssl --with-ttf --with-gd --enable-ftp --with-gdbm --with-bz2=/usr --with-zlib --with-openssl --with-apxs=/usr/local/web/apache/bin/apxs --with-freetype-dir=/usr/local --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png-dir=/usr --enable-ftp --enable-db --enable-mbregex 'make' fails with: /bin/sh libtool --silent --mode=compile gcc -Iext/standard/ -I/usr/var/tmp/php-4.3.0pre2/ext/standard/ -DPHP_ATOM_INC -I/usr/var/tmp/php-4.3.0pre2/include -I/usr/var/tmp/php-4.3.0pre2/main -I/usr/var/tmp/php-4.3.0pre2 -I/usr/var/tmp/php-4.3.0pre2/Zend -I/usr/local/ssl/include -I/usr/local/include/freetype2 -I/usr/var/tmp/imap-2002.RC8/c-client -I/usr/local/mysql//include/mysql -I/usr/var/tmp/php-4.3.0pre2/ext/xml/expat -DMOD_SSL=208110 -DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT -DFD_SETSIZE=4096 -I/usr/var/tmp/php-4.3.0pre2/TSRM -g -O2 -prefer-pic -c /usr/var/tmp/php-4.3.0pre2/ext/standard/basic_functions.c -o ext/standard/basic_functions.lo /usr/var/tmp/php-4.3.0pre2/ext/standard/basic_functions.c:1377: warning: `struct option' declared inside parameter list Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hebrew patch for jewish calendar
it's just that your mailer is smart enough to decode uu-encoded attachments. Not everybody's is. Vlad Mike Hall wrote: I received the attachment... you sure it's his mailer playing up? ;-) Mike --- Original Message --- From:Derick Rethans [EMAIL PROTECTED] To: moshe doron [EMAIL PROTECTED] Date:Mon, 28 Oct 2002 14:37:05 +0100 (CET) Subject: Re: [PHP-DEV] hebrew patch for jewish calendar On Mon, 28 Oct 2002, moshe doron wrote: i did it (1.txt) Still no attachment but everything inline. Your mailer is apparently so braindead to include it inline. I want to bet it's Outlook... Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #19848 [Ctl-Csd]: Wrong $_REQUEST values ($_FILESappearance is wacky)
is import_request_variables() affected? as for import_request_variables, I haven't modified that, simply because i'm not sure whether it should be modified... For now I'll leave it, if someone feels strongly about it either way, they can change it... I think they should be the same, if $_REQUEST does not have FILES, import_request_variables() shouldn't either. I lack the skills to implement this change but vote for it nonetheless ;) Mainly for consistency sake. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: john
I'm going to be working with Shane Caraveo on Thread Saftey and trying to get Threading (from a script) support implemented. I also am going to be working with the PHP manual a little bit cleaning things up (as I'm going to be using it really frequently in the next few months -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions
Hi! We receive many complaints at [EMAIL PROTECTED] about failures in setting up PHP with Apache 2. Can somebody please update the documentation with details on Apache 2 on Linux and Windows, or provide information for the documentation team to add to the documentation. It would definitely help users. Hmm, there is nothing magic :-) Win32: Module-Version for Apache2: added in 4.2.0 : experimental/apache2filter.dll 4.2.1 : sapi: php4apache2.dll for windows. Info lacking, but I am sure the dev's can give them, which apache-version does work with which php-version. I can't remember exactly but I think php4.2.3 on win works at least with 2.039 or 2.040) For Linux in general 2 solutions: pre-build rpms from the vendor (e.g. Redhat) or ./configure --with apxs2 and so on.and also only specific apache2-versions work with an specific php-version. For the newest apache 2.0.43 you need a snap build form snaps.php.net (for windows and Linux or php4.3pre build). Nothing special for the CGI-Version ? Correct me if I am wrong ;-) BUT: I agree in updating the docs for the installation of apache2 in general. This means telling the people which dll to use, where to find and on Linux which configure settings to use (--with-apxs2). I disagree to put the apache and php version specific thingies into the docs, its really confusing more than it helps imho. Beside my opinion the apache2 support isn't stable yet?! Will it be in 4.3.0? For me it seems to be a better solution to put the version specific thingies on the download page or a seperate page on the web and the general instructions for installation in the docs. Your thoughts about? Friedhelm -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions
| We receive many complaints at [EMAIL PROTECTED] about failures in | setting up PHP with Apache 2. Can somebody please update the | documentation with details on Apache 2 on Linux and Windows, or | provide information for the documentation team to add to the | documentation. It would definitely help users. There are some issues I believe with Apache 2.0 in general and PHP... I can't tell you exactly where the problems are because I haven't setup the testing yet, but from what I gathered at PHPCon there is an issue with Thread Saftey and some of the PHP extensions. Since I have no idea the nature of these failures I can't give much more info... As for the documentation, When I do my install of Apache 2.0 / PHP, I'll be sure to make sure the docs reflect the necessary steps and correct / add anything I found necessary. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions
| We receive many complaints at [EMAIL PROTECTED] about failures in | setting up PHP with Apache 2. Can somebody please update the | documentation with details on Apache 2 on Linux and Windows, or | provide information for the documentation team to add to the | documentation. It would definitely help users. There are some issues I believe with Apache 2.0 in general and PHP... I can't tell you exactly where the problems are because I haven't setup the testing yet, but from what I gathered at PHPCon there is an issue with Thread Saftey and some of the PHP extensions. Since I have no idea the nature of these failures I can't give much more info... As for the documentation, When I do my install of Apache 2.0 / PHP, I'll be sure to make sure the docs reflect the necessary steps and correct / add anything I found necessary. On win I tried out the latest 2.043 Apache and a snap-build from snaps.php.net. As I can say, the installation is as usuall for the module and cgi version. The only thing to mention for the Windows-guys is to use sapi/php4apache2.dll and php-cgi.exe for the CGI Version. So far the install with a snap and the latest Apache, nothing about the functionality/technical aspects. It should be clearly mentioned, that the support for apache2 isn't production stable ;-) The aspect people complaining about is more a version thingie, e.g. they try to set up php 4.2.3 with apache 2.0.43 and this could not succeed. Is it really necessary to document that apache 2.03x works only with php 4.2.x1, php4.2.x2 and apache 2.04x only with php4.2y1 or php4.2.y2? For their own sanity people should try the latest php-builds with apache2 to test, IMHO it doesn't make sense to me to setup 4.2.0 with apache2filter.dll :-) Also a point to consider is the name of the correct cgi executable for win: in 4.2.3 it's php.exe the cli-build names php-cli.exe. In the 4.3.0-dev the cli names php.exe and the cgi-version php-cgi.exe. I don't know why the names changed, maybe to confuse the people once more and to give some work for the doc-folks ;-) Anyway: will this be the final names? Friedhelm -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php4.3.0-pre2 - win32 binaries
anyone can download for testing php-4.3.0-pre2 from: http://chat.italma.ru/php/ (compiled with vc++.net) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php4.3.0-pre2 - win32 binaries
Please do NOT use non-offical binaries for testing! Windows binaries will be posted soon. Derick On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: anyone can download for testing php-4.3.0-pre2 from: http://chat.italma.ru/php/ (compiled with vc++.net) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php4.3.0-pre2 - win32 binaries
Could you tell something about compiling php under vc++.net? I tried this but wasn't able to (but did not tried it hard). regards marcus At 16:13 28.10.2002, [EMAIL PROTECTED] wrote: anyone can download for testing php-4.3.0-pre2 from: http://chat.italma.ru/php/ (compiled with vc++.net) -- 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[2]: [PHP-DEV] php4.3.0-pre2 - win32 binaries
Hello Marcus, Monday, October 28, 2002, 6:40:52 PM, you wrote: MB Could you tell something about compiling php under vc++.net? MB I tried this but wasn't able to (but did not tried it hard). MB regards MB marcus in fact - nothing special about it. haven't seen any terrible bugs. working under my own tests - excellent (despite of last-week snaps). i have Optimizing Compiler Version 12.00.8168 for 80x86 -- Best regards, Vendigo2000mailto:Vendigo2000;Mail.Ru -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: Please revert. There is no need. Derick has been changed it w/o discussion. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
hello, I just remember the subject :- [PHP-DEV] I hope this is the last email about this :) sorry, cannot resist to do it :-) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI ini selection
Edin Kadribasic wrote:
We already have sapi specific ini files. If php finds
php-{$SAPI}.ini (e.g. php-cli.ini, php-apache.ini, etc) it will use
it instead of php.ini. IMHO this should cover most of the needs for
differentiated ini settings.
I knew it, too :)
As I mentioned in several mails, use of web server ini files
could be confusing and annoying.
Good idea for Windows is needed, though.
--
Yasuo Ohgaki
Edin
- Original Message -
From: Melvyn Sopacua [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 28, 2002 3:41 PM
Subject: [PHP-DEV] CLI ini selection
Let's put this in the right thread.
At 14:34 28-10-2002, Rick Widmer wrote:
At 07:38 PM 10/28/02 +0900, Yasuo Ohgaki wrote:
BTW, we should better to have a little different ini
selection for CLI.
For instance,
/etc/phprc or php.ini
~/.phprc or php.ini
which are standard locations of rc files under UNIX
like systems.
This I can agree with. I would prefer /etc/php.ini which I am
already using.
+1 on /etc/php.ini being the equivalent of php_admin_value
+1 on ~/.php.ini being the equavalent of php_value
On windows this may clash bigtime though. The equivalent of
/etc/php.ini
would be
WINNT\ini\php.ini or maybe %ALLUSERPROFILE\Application Data\Php
Group\php.ini and
~/.php.ini would be %USERPROFILE%\Application Data\Php
Group\php.ini.
Yuk :)
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
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] Patch adding imagerotate to bundle gd ready
Hello, The patch to add rotate functions to bundled is ready, great thx to ilia to clean up the code and apply the CS :-) Available at: http://www.pearfr.org/phpgd/source/gd.txt May ilia can directly commit it ? as we said, it may be usefull to get it in 4.3.0 :-) hth pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main streams.c
Wez Furlong wrote:
Hey Ilia,
Does this prevent opening of things like block and character special files?
If yes, then let's change it to explicitly check for directories instead,
as there are bound to be people out there that want to open things like
/dev/hda1 (for example).
And named pipes, too?
--
Yasuo Ohgaki
--Wez.
On 28/10/02, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
Fixed bug #20110.
+ if (fstat(fileno(fp), st) == -1 || !S_ISREG(st.st_mode)) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On Tue, 29 Oct 2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: Please revert. There is no need. Derick has been changed it w/o discussion. Nice joke :) Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions
The aspect people complaining about is more a version thingie, e.g. they try to set up php 4.2.3 with apache 2.0.43 and this could not succeed. Is it really necessary to document that apache 2.03x works only with php 4.2.x1, php4.2.x2 and apache 2.04x only with php4.2y1 or php4.2.y2? It should be clearly mentioned, that the support for apache2 isn't production stable ;-) I think, it would be nice to add information to one place, the documentation about Apache 2 support. 1. It's not production ready 2. If someone want to set it up, how to do it (Linux, Windows) 3. What PHP versions work with what Apache 2 versions 4. It should be noted, that Apache 1 support is continued ;) Also a point to consider is the name of the correct cgi executable for win: in 4.2.3 it's php.exe the cli-build names php-cli.exe. In the 4.3.0-dev the cli names php.exe and the cgi-version php-cgi.exe. I don't know why the names changed, maybe to confuse the people once more and to give some work for the doc-folks ;-) Doh, it would be nice to stick to some final names ;) NOTE: cca. 80% of the user notes on the Apache setup page deals with Apache 2 installation. We should add verified info to the docs, and delete those notes. There are many sites offering a php4apache2.dll to download. These can harm our users, as they can contain any vulnerable code, which our users download, just because there is no official support/documentation for Apache... http://www.php.net/manual/en/install.apache.php Please keep this in mind, Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
