Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
On Wed, 9 Oct 2002, Yasuo Ohgaki wrote: Colin Viebrock wrote: This is getting a little more complicated than I think is necessary. There are two issues here, I think: a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. This will simply break output under some browser. It's more important to show info, but show a little nicely on some systems while printing garages on some systems. If anyone prefer any specific font, they should use their own CSS. For once I agree with yasuo here :) phpinfo() doesn't need to look pretty, it's for _debug_ output. 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] default properties (in c)
On 8 Oct 2002, Tim Daly, Jr. wrote: Brad LaFountain [EMAIL PROTECTED] writes: What engine are you working with 1 or 2? -brad I imagine PHP3 == engine 1, and PHP4 == engine 2? PHP 3 is engine 0.5, PHP 4 is engine 1 and PHP 5 will be engine 2 :) So you're most likely using engine 1. 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
[PHP-DEV] session.save_path = N;/path
I thought that I'd try this out with HEAD, but I found that PHP would go into an infinite loop. I didn't have time to debug it, so I reverted to using a regular path instead. Could a session guru take a look and double check this? session.save_path=2;/var/tmp-- infinite loop session.save_path=/var/tmp -- works just fine If there isn't an obvious problem, I'll try to get a backtrace later tonight. --Wez. Colin Viebrock wrote: cmv Mon Oct 7 13:58:27 2002 EDT Modified files: /php4 php.ini-dist Log: Document session.save_path option in php.ini Index: php4/php.ini-dist diff -u php4/php.ini-dist:1.161 php4/php.ini-dist:1.162 --- php4/php.ini-dist:1.161 Thu Oct 3 02:52:23 2002 +++ php4/php.ini-dist Mon Oct 7 13:58:27 2002 -766,6 +766,15 +; As of PHP 4.2.3, you can define the path as: +; session.save_path = N;/path +; where N is an integer. Instead of storing all the session files in +; /path, what this will do is create subdirectories N-levels deep, and +; store the session data in those directories. This is useful if you +; or your OS have problems with lots of files in one directory, and is +; a more efficient layout for servers that handle lots of sessions. +; (Note: see the section on garbage collection below if you choose to +; use subdirectories for session storage) -- 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/standard css.c
On 10/09/02, Yasuo Ohgaki [EMAIL PROTECTED] wrote: AFAIK, there is no Arial that includes CJK. Arial Unicode MS (that 22MB TTF you'll find in \windows\fonts) seems to do a good job of including virtually all characters known to man. BTW: Colin - there is a bug report about phpinfo() - you are not efree()ing your htmlentities()-ed strings and that causes a load avg. of 2 when PHP shuts down and cleans up and warns about it 380+ times :-) The bug report is titled something like php causes a load avg of 2. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: session.save_path = N;/path
On Wed, 9 Oct 2002, Wez Furlong wrote: I thought that I'd try this out with HEAD, but I found that PHP would go into an infinite loop. I didn't have time to debug it, so I reverted to using a regular path instead. Could a session guru take a look and double check this? session.save_path=2;/var/tmp-- infinite loop session.save_path=/var/tmp -- works just fine If there isn't an obvious problem, I'll try to get a backtrace later tonight. And you did create the necessary directory structure? - Sascha -- 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/standard css.c
At 08:34 9-10-2002, Derick Rethans wrote: For once I agree with yasuo here :) phpinfo() doesn't need to look pretty, it's for _debug_ output. Which means it needs to be as clear as possible. Formatting it for readibility is a plus - you don't want output that's hard to read, as you're already debugging. But if this breaks stuff for a certain charset/encoding/fontspec combination, than it should be removed, for the very same reason, as it's not readable. [ I just wish, W3C and browser vendors would get on the same page for once, sigh ] 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] ext/sysvmsg
At 06:02 9-10-2002, Sascha Schumann wrote: Good point - but also raises, whether to look for this struct in the first place. Why not skip it all, and define it ISO C compliant, in php_ namespace? That would be a possibility, although you never know how engineers at some random company interpreted the standard text (if they had access to it at all) and how they might have simply copied things from another OS in their own broken way. So I'm for removing detection and provide the struct in php_sysvmsg.h. If 'some random company' turns out to be a major OS vendor, we (hopefully) pick it up in QA cycle. Patch for that is attached, compiled and tested on FreeBSD 4.6. Opinions? 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-DEV] fopencookie detection
Before we branch, I would be grateful if someone could verify that we are detecting fopencookie correctly. It seems that older glibcs use an off_t parameter for the seeker function, while newer versions pass an fpos_t * instead. I've (previously) expanded the PHP_FOPENCOOKIE test in acinclude.m4 to define COOKIE_SEEKER_USES_FPOS_T based on it's findings. However, since I don't have developer access to a box with a newer glibc right now, I can't really verify if this detection is working correctly in all cases. Could a build guru check it out? (There might be a more sensible way to perform the check). Thanks, --Wez. smime.p7s Description: application/pkcs7-signature
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
Wez Furlong wrote: On 10/09/02, Yasuo Ohgaki [EMAIL PROTECTED] wrote: AFAIK, there is no Arial that includes CJK. Arial Unicode MS (that 22MB TTF you'll find in \windows\fonts) seems to do a good job of including virtually all characters known to man. Hmm... I don't have it under my W2k. MS Japan should provide it :) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: session.save_path = N;/path
Doh! I somehow misread that line, despite reading it several times. I think it would be useful to emit a warning in this situation. (if I misread it, I'm sure others will do so also). --Wez. On 10/09/02, Sascha Schumann [EMAIL PROTECTED] wrote: On Wed, 9 Oct 2002, Wez Furlong wrote: session.save_path=2;/var/tmp-- infinite loop And you did create the necessary directory structure? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] creating files??
Hi NG. I'm having problems creating files at a certain location. If I attemt to create a file it gets created in the rootdir (htdocs) even though I add a path infront of the file name. I've tried severel ways of adding a path (with / and \\) but nothing works. eksample: /nef/articles/54.txt File 54.txt gets created but not at the intented location, instead it gets created in htdocs. Can anyone help me by telling me how I'm suppose to do this? I'm running PHP on Win98 with Apache. ~ Aidal -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bundled exapt and Cygwin
Hi, cygwin 1.3.12 (everything upgraded yesterday): CYGWIN_NT-5.0 WEBMASTER 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown Small patch needed, for the bundled expat. Otherwise, __imp_ is prepended, to the symbols and linking fails. Objections? Index: ext/xml/expat/expat.h === RCS file: /repository/php4/ext/xml/expat/expat.h,v retrieving revision 1.3 diff -u -r1.3 expat.h --- ext/xml/expat/expat.h 27 Sep 2001 00:29:34 - 1.3 +++ ext/xml/expat/expat.h 9 Oct 2002 10:51:20 - -10,7 +10,7 #include php_compat.h #ifndef XMLPARSEAPI -# if defined(__declspec) !defined(__BEOS__) +# if defined(__declspec) !defined(__BEOS__) !defined(__CYGWIN__) #define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl # else #define XMLPARSEAPI(type) type 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] CODING_STANDARDS addition re: emalloc
A new CODING_STANDARDS patch is attached, based on feedback from Andi and Dan (thanks!). Please review and comment. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) Index: CODING_STANDARDS === RCS file: /repository/php4/CODING_STANDARDS,v retrieving revision 1.22 diff -u -r1.22 CODING_STANDARDS --- CODING_STANDARDS9 Sep 2002 07:54:11 - 1.22 +++ CODING_STANDARDS9 Oct 2002 13:41:35 - @@ -122,6 +122,20 @@ existing. End users should use function_exists() to test for the existence of a function +[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library + counterparts. These functions implement an internal safety-net + mechanism that ensures the deallocation of any unfreed memory at the + end of a request. They also provide useful allocation and overflow + information while running in debug mode. + + In almost all cases, memory returned to the engine must be allocated + using emalloc(). + + malloc() should only be used in instances where you need to allocate + memory that will be freed (via free()) inside of a third-party library. + It should also be used in instances where allocated memory has to + survive between multiple requests. + Naming Conventions -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc
On Wed, Oct 09, 2002 at 09:47:10AM -0400, Jon Parise wrote : +[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library + counterparts. These functions implement an internal safety-net + mechanism that ensures the deallocation of any unfreed memory at the + end of a request. They also provide useful allocation and overflow + information while running in debug mode. + + In almost all cases, memory returned to the engine must be allocated + using emalloc(). + + malloc() should only be used in instances where you need to allocate + memory that will be freed (via free()) inside of a third-party library. + It should also be used in instances where allocated memory has to + survive between multiple requests. + +1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: ICONV test
On Wed, 9 Oct 2002, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2002-10-09 15:12:57 +0200: Ah, great. Only 4 failed test left :) looks like 4.3 will be the best release test harness-wise. For that to happen we need MUCH more tests. It would be a very nice thing if there would be a test for every bug fix made. 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] CODING_STANDARDS addition re: emalloc
Le Mercredi 9 Octobre 2002 16:01, Markus Fischer a écrit : On Wed, Oct 09, 2002 at 09:47:10AM -0400, Jon Parise wrote : +[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library + counterparts. These functions implement an internal safety-net + mechanism that ensures the deallocation of any unfreed memory at the + end of a request. They also provide useful allocation and overflow + information while running in debug mode. + + In almost all cases, memory returned to the engine must be allocated + using emalloc(). + + malloc() should only be used in instances where you need to allocate + memory that will be freed (via free()) inside of a third-party library. + It should also be used in instances where allocated memory has to + survive between multiple requests. + +1 +1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default properties (in c)
Ok,
I don't think default_properties is what you are looking for.
default_properties store the information about defined variables and their
default value. Like this:
class MyClass {
var $test = mytest;
}
at compile time MyClass class_entry will have test = mytest in its default
properties. Where as:
$t = new MyClass();
$t-other_test = my other test;
at runtime other_test = my other test will be stored in
zend_object.properties. So from your example I beleieve you are just trying to
do the second case. So if this is true then.
void define_a_class()
{
/* make a class with two properties, one of which is an array */
zval *obj_inst;
zval *array;
INIT_CLASS_ENTRY(tmp_class_entry, class_name, class_name_functions);
class_name_class_entry = zend_register_internal_class(tmp_class_entry);
MAKE_STD_ZVAL(obj_inst);
object_init_ex(obj_inst, tmp_class_entry);
add_property_null(obj_inst, prop_name); // defined in zend_API.h
MAKE_STD_ZVAL(array);
array_init(array);
add_next_index_string(array, foo, 1);
add_property_zval(obj_inst, prop_name1, array); // defined in
zend_API.h
}
- brad
--- Derick Rethans [EMAIL PROTECTED] wrote:
On 8 Oct 2002, Tim Daly, Jr. wrote:
Brad LaFountain [EMAIL PROTECTED] writes:
What engine are you working with 1 or 2?
-brad
I imagine PHP3 == engine 1, and PHP4 == engine 2?
PHP 3 is engine 0.5, PHP 4 is engine 1 and PHP 5 will be engine 2 :)
So you're most likely using engine 1.
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
__
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos More
http://faith.yahoo.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug handling survey - Tree based models
Hello PHP contributors, I am conducting a survey about the way bugs are handled in open source software projects. The survey includes questions that can be answered by developers,testers, bug fixers, project managers, and owners of defect databases. It is only and only for research purposes and it is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. Please fill it out if you haven't done yet. You will find the questions interesting since there is a reason behind each one one of them. They will make you think about how things work (or could work)in your project. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html The data in the bug databases can be used to identify the high risk areas in the software development. One of the ways of doing it is constructing tree-based models, which could be very useful in open source projects. If you would like to read about it, I prepared a web page for you: http://www.seas.smu.edu/~gkoru/surveys/tbdm1.html Please accept my apologies if you receive duplicates of this e-mail. This is a survey, which will give useful results for all of us. I will try to prepare and make some preliminary results on-line within the next two weeks. Since this is a survey, covering many important open source projects, it will be interesting for everybody to see what kind of quality assurance work is going on in the other projects. As always, we are very dedicated to this research. Please contact me for any question you might have. Thank you, A. Gunes Koru http://www.engr.smu.edu/~gkoru -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug handling survey - Tree based models
Hi, On Wed, Oct 09, 2002 at 09:38:46AM -0500, Gunes Koru wrote: Hello PHP contributors, didn't we agree not to do that again? Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. Key7BCC EB86 8313 DDA9 25DF Fingerprint1805 ECA5 BCB7 BB96 56B0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default properties (in c)
Brad LaFountain [EMAIL PROTECTED] writes:
Ok,
I don't think default_properties is what you are looking for.
default_properties store the information about defined variables and their
default value. Like this:
class MyClass {
var $test = mytest;
}
at compile time MyClass class_entry will have test = mytest in its default
properties. Where as:
$t = new MyClass();
$t-other_test = my other test;
at runtime other_test = my other test will be stored in
zend_object.properties. So from your example I beleieve you are just trying to
do the second case. So if this is true then.
Brad,
Thanks for your response!
I _am_ actually trying to add a default property (the first case). I
want to create a class with defined properties that have a default
value, so that it works just as it would had I defined the class in
PHP.
-Tim
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug handling survey - Tree based models
Can you please stop spamming this list? Derick On Wed, 9 Oct 2002, Gunes Koru wrote: Hello PHP contributors, I am conducting a survey about the way bugs are handled in open source software projects. The survey includes questions that can be answered by developers,testers, bug fixers, project managers, and owners of defect databases. It is only and only for research purposes and it is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. Please fill it out if you haven't done yet. You will find the questions interesting since there is a reason behind each one one of them. They will make you think about how things work (or could work)in your project. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html The data in the bug databases can be used to identify the high risk areas in the software development. One of the ways of doing it is constructing tree-based models, which could be very useful in open source projects. If you would like to read about it, I prepared a web page for you: http://www.seas.smu.edu/~gkoru/surveys/tbdm1.html Please accept my apologies if you receive duplicates of this e-mail. This is a survey, which will give useful results for all of us. I will try to prepare and make some preliminary results on-line within the next two weeks. Since this is a survey, covering many important open source projects, it will be interesting for everybody to see what kind of quality assurance work is going on in the other projects. As always, we are very dedicated to this research. Please contact me for any question you might have. Thank you, A. Gunes Koru http://www.engr.smu.edu/~gkoru -- 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] Bug handling survey - Tree based models
Jan Lehnardt wrote: Hi, On Wed, Oct 09, 2002 at 09:38:46AM -0500, Gunes Koru wrote: Hello PHP contributors, didn't we agree not to do that again? Well he did shorten his signature - so we are getting somewhere - slowly :) Jan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] session_register warnings
Sascha, could we revisit these session changes? I stuck current head on a
server that runs all sorts of PHP code written by a bunch of different
people. These warnings were everywhere:
Warning: Your script possibly relies on a session side-effect which
existed until PHP 4.2.3. Please be advised that the session extension
does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and
this warning by setting session.bug_compat_42 or session.bug_compat_warn.
in Unknown on line 0
I'd like to do a collective rethink of this. The simple description of
the session_register() function in the manual is:
session_register() accepts a variable number of arguments, any of which
can be either a string holding the name of a variable or an array
consisting of variable names or other arrays. For each name,
session_register() registers the global variable with that name in the
current session.
Now, there are further caveats about register_globals further on, but I
would like to propose that we kill any and all such caveats and simply
make the function behave exactly as described in the short description.
Don't make its behaviour change based on register_globals or anything
else.
I don't see why calling session_register('a') should not register the
global variable named $a in the session if that is what this function has
always been documented to do, and in fact has always done regardless of
the register_globals setting. What is the drawback here? I think the
analogy to this is changing PHP such that you cannot do $a=1 to set a
normal global variable when register_globals is off. This obviously
doesn't make any sense. register_globals determines which things are
injected into the global namespace, it does not determine whether we have
a global namespace or how normal function interact with this global
namespace.
Basically my points are:
1. session_register('a') registering a global variable makes sense
2. changing this breaks BC
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: dahlia.dasmoped.net daily run output
these are still being sent to [EMAIL PROTECTED] (perhaps the mail configuration needs to get updated?) jim On Wed, Oct 09, 2002 at 03:06:27AM +0200, Charlie Root wrote: Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: Backing up mail aliases: Disk status: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 102785471318 874308 8%/ /dev/ad1s4 56047780 50020263 154369597%/mnt/data /dev/ad0s4e 56462940 51615248 33065899%/mnt/data/movies /dev/ad0s2e 20638150 11335860 765123860%/usr /dev/ad0s3e51393426538 446282 6%/var /dev/ad1s2 15240936 13806733 21492998%/mnt/data/movies/eps procfs 44 0 100%/proc Last dump(s) done (Dump '' file systems): UUCP status: Network interface status: Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll sis0 1500 Link#100:07:95:03:e5:f8 1553 0 2987 0 0 sis0 1500 192.168.1 192.168.1.5 1551 - 2981 - - sis0 1500 fe80:1::207 fe80:1::207:95ff:0 -0 - - rl0 1500 Link#200:50:bf:05:7e:a2 5541003 0 5521626 0 61854 rl0 1500 192.168.2 192.168.2.50 - 107 - - rl0 1500 fe80:2::250 fe80:2::250:bfff:0 -0 - - lp0* 1500 Link#3 0 00 0 0 faith 1500 Link#4 0 00 0 0 lo0 16384 Link#5207191 0 207191 0 0 lo0 16384 localhost ::1922 - 922 - - lo0 16384 fe80:5::1 fe80:5::10 -0 - - lo0 16384 your-net localhost 206249 - 206249 - - ppp0* 1500 Link#6 0 00 0 0 sl0* 552 Link#7 0 00 0 0 tun0 1492 Link#8 5541086 0 5521115 0 0 tun0 1492 fe80:8::207 fe80:8::207:95ff:0 -0 - - tun0 1492 217.82.221pD952DDA0.dip.t 193059 - 252377 - - vmnet 1500 Link#900:bd:40:60:00:010 0 51 0 0 vmnet 1500 192.168.0 192.168.0.1 20 - 87 - - vmnet 1500 fe80:9::2bd fe80:9::2bd:40ff:0 -0 - - Local system status: 3:01AM up 1 day, 9:49, 8 users, load averages: 0.06, 0.05, 0.01 Mail in local queue: Mail queue is empty Mail in submit queue: mailq: illegal option -- A mailq: fatal: usage: mailq [options] Security check: (output mailed separately) Checking for rejected mail hosts: Checking for denied zone transfers (AXFR and IXFR): -- End of daily output -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP and Smarty Templates
I have a variable in a smarty template: $product.url ...
Within the smarty template I have: {include file=getTable.tpl} ...
In the included template I have a function called: getTable($url) ...
From the original template where the $product.url resides, I would like to
pass that value into the php function but can't seem to figure out the
syntax to do that. Please help. I have tried things like
{php}getTable{{/php}{$product.url}{php});{/php} ... but obviously this
doesn't work.
Thank you for any assistance with this.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: session_register warnings
I'd like to do a collective rethink of this. The simple description of the session_register() function in the manual is: This description was correct initially (I wrote it), but has not been updated as the session module was extended. I've noticed this documentation issue in the earlier thread, but have not come around to fix it yet. If I may refer you to the session index page again, that one clearly stated since the beginning that the behaviour changes, depending on register_globals. Now, if your application(s) rely on this feature and you don't want to change them, you can always disable the warning. make the function behave exactly as described in the short description. I suggest we fix the documentation. 2. changing this breaks BC I'm not aware of any BC issues. If you have a test case, I'll be happy to look at it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session_register warnings
FWIW, I didn't manage to understand what the problem was with the codebase
before the patch. Sascha - can you explain it?
I tend to agree with Rasmus about this change being a not-so-good idea, but
maybe we're just not aware of the problems that existed before the patch.
Zeev
At 19:09 09/10/2002, Rasmus Lerdorf wrote:
Sascha, could we revisit these session changes? I stuck current head on a
server that runs all sorts of PHP code written by a bunch of different
people. These warnings were everywhere:
Warning: Your script possibly relies on a session side-effect which
existed until PHP 4.2.3. Please be advised that the session extension
does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and
this warning by setting session.bug_compat_42 or session.bug_compat_warn.
in Unknown on line 0
I'd like to do a collective rethink of this. The simple description of
the session_register() function in the manual is:
session_register() accepts a variable number of arguments, any of which
can be either a string holding the name of a variable or an array
consisting of variable names or other arrays. For each name,
session_register() registers the global variable with that name in the
current session.
Now, there are further caveats about register_globals further on, but I
would like to propose that we kill any and all such caveats and simply
make the function behave exactly as described in the short description.
Don't make its behaviour change based on register_globals or anything
else.
I don't see why calling session_register('a') should not register the
global variable named $a in the session if that is what this function has
always been documented to do, and in fact has always done regardless of
the register_globals setting. What is the drawback here? I think the
analogy to this is changing PHP such that you cannot do $a=1 to set a
normal global variable when register_globals is off. This obviously
doesn't make any sense. register_globals determines which things are
injected into the global namespace, it does not determine whether we have
a global namespace or how normal function interact with this global
namespace.
Basically my points are:
1. session_register('a') registering a global variable makes sense
2. changing this breaks BC
-Rasmus
--
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] CODING_STANDARDS addition re: emalloc
Looks good! Andi At 09:47 AM 10/9/2002 -0400, Jon Parise wrote: A new CODING_STANDARDS patch is attached, based on feedback from Andi and Dan (thanks!). Please review and comment. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist
Hey, If the fopen() fails why not create the directory? It shouldn't be too hard to do and it'd really improve usability. Andi At 09:03 AM 10/9/2002 +, Sascha Schumann wrote: sas Wed Oct 9 05:03:04 2002 EDT Modified files: /php4 php.ini-dist Log: Emphasize a couple of points Index: php4/php.ini-dist diff -u php4/php.ini-dist:1.164 php4/php.ini-dist:1.165 --- php4/php.ini-dist:1.164 Tue Oct 8 03:47:45 2002 +++ php4/php.ini-dist Wed Oct 9 05:03:04 2002 -766,15 +766,17 ; Argument passed to save_handler. In the case of files, this is the path ; where data files are stored. Note: Windows users have to change this ; variable in order to use PHP's session functions. -; As of PHP 4.2.3, you can define the path as: +; As of PHP 4.0.1, you can define the path as: ; session.save_path = N;/path ; where N is an integer. Instead of storing all the session files in -; /path, what this will do is create subdirectories N-levels deep, and +; /path, what this will do is use subdirectories N-levels deep, and ; store the session data in those directories. This is useful if you ; or your OS have problems with lots of files in one directory, and is ; a more efficient layout for servers that handle lots of sessions. -; (Note: see the section on garbage collection below if you choose to -; use subdirectories for session storage) +; NOTE 1: PHP will not create this directory structure automatically. +; You can use the script in the ext/session dir for that purpose. +; NOTE 2: See the section on garbage collection below if you choose to +; use subdirectories for session storage session.save_path = /tmp ; Whether to use cookies. -- PHP CVS 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: session_register warnings
On Wed, 9 Oct 2002, Sascha Schumann wrote: I'd like to do a collective rethink of this. The simple description of the session_register() function in the manual is: This description was correct initially (I wrote it), but has not been updated as the session module was extended. I've noticed this documentation issue in the earlier thread, but have not come around to fix it yet. If I may refer you to the session index page again, that one clearly stated since the beginning that the behaviour changes, depending on register_globals. Now, if your application(s) rely on this feature and you don't want to change them, you can always disable the warning. I am not talking about just mine. I am talking about a sizeable subset of all PHP apps that use sessions. My problem here is that I do not understand the reasoning for not continuing to allow session_register to work on global variables regardless of the register_globals setting. I do not see the benefit of changing this. make the function behave exactly as described in the short description. I suggest we fix the documentation. 2. changing this breaks BC I'm not aware of any BC issues. If you have a test case, I'll be happy to look at it. The fact that we spew a warning is a pre-cursor to breaking BC. If the plan is not to break BC on this issue then there is absolutely no reason for adding this warning and it should be removed. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: session_register warnings
Unless we're missing some problem I agree with Rasmus here. I don't see much advantage in changing this. Of course, there might be a reason Andi At 10:40 AM 10/9/2002 -0700, Rasmus Lerdorf wrote: On Wed, 9 Oct 2002, Sascha Schumann wrote: I'd like to do a collective rethink of this. The simple description of the session_register() function in the manual is: This description was correct initially (I wrote it), but has not been updated as the session module was extended. I've noticed this documentation issue in the earlier thread, but have not come around to fix it yet. If I may refer you to the session index page again, that one clearly stated since the beginning that the behaviour changes, depending on register_globals. Now, if your application(s) rely on this feature and you don't want to change them, you can always disable the warning. I am not talking about just mine. I am talking about a sizeable subset of all PHP apps that use sessions. My problem here is that I do not understand the reasoning for not continuing to allow session_register to work on global variables regardless of the register_globals setting. I do not see the benefit of changing this. make the function behave exactly as described in the short description. I suggest we fix the documentation. 2. changing this breaks BC I'm not aware of any BC issues. If you have a test case, I'll be happy to look at it. The fact that we spew a warning is a pre-cursor to breaking BC. If the plan is not to break BC on this issue then there is absolutely no reason for adding this warning and it should be removed. -Rasmus -- 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: session_register warnings
At 10:40 09/10/2002 -0700, you wrote: I am not talking about just mine. I am talking about a sizeable subset of all PHP apps that use sessions. My problem here is that I do not understand the reasoning for not continuing to allow session_register to work on global variables regardless of the register_globals setting. I do not see the benefit of changing this. Agreed, I don't fancy spending a few days going through a shedload of scripts changing all the session stuff. All it'll end up doing is annoying users no end, and what you don't want to do is get rid of users -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: session_register warnings
On Wed, 9 Oct 2002, Gareth Ardron wrote: At 10:40 09/10/2002 -0700, you wrote: I am not talking about just mine. I am talking about a sizeable subset of all PHP apps that use sessions. My problem here is that I do not understand the reasoning for not continuing to allow session_register to work on global variables regardless of the register_globals setting. I do not see the benefit of changing this. Agreed, I don't fancy spending a few days going through a shedload of scripts changing all the session stuff. All it'll end up doing is annoying users no end, and what you don't want to do is get rid of users well... some would be nice :) 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
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c
At 10:47 PM 10/9/2002 +0200, Sterling Hughes wrote: On Wed, 2002-10-09 at 22:45, Derick Rethans wrote: On 9 Oct 2002, Sterling Hughes wrote: On Wed, 2002-10-09 at 22:21, Thies C. Arntzen wrote: On Wed, Oct 09, 2002 at 06:29:45PM -, Sterling Hughes wrote: sterlingWed Oct 9 14:29:45 2002 EDT Modified files: /php4/ext/standard array.c Log: clean these functions up using zend_parse_parameters and nuke the use of HASH_OF() which is inappropriate in these cases... will prev still work on objects after your patch? none of them do - none of them should either - why would you want to access an object like you would an _indexed_ array? It breaks BC, s... revert? (Not that I see any use either :) If you're at it, please add some tests for the test framework too. Well, it breaks it in a not-really-breaking-bc-manner. To my knowledge this was never documented to work. I don't think anyone will miss this feature - if someone will, and is/has used it, please write in and let me know, the patch can be modified to work on objects. But then again, it really wouldn't work well on objects anyhow (even before my patch), so i really don't see the point. Why wouldn't it work well? HASH_OF() was always used when the intention was for it to work for both arrays and objects. Also, I doubt the php-cvs nor the php-dev forums can let you know if this feature is being used. You'd have to ask all of the PHP users out there. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: mb_convert_case (Was: Re: #19257 [Bgs]: strtolower strtoupper does not work for UTF-8 strings)
On Thu, Sep 26, 2002 at 02:10:04AM +0100, Wez Furlong wrote: All: I've just committed a php-style version of the ucdata package that Stig directed me to. Great! Stig: Rather than generate binary data files at configure time, based on a bundled UnicodeData.txt file which is quite large, causes problems for win32 builds, and has run-time thread safety and data file location issues (for freshly built but not installed php binaries), I settled on having ucgendat generate a header file with the ctype and case data tables declared within it. All that is needed is to add these files to the build and voila! it works :-) Yes, I think that's a good solution. The tables are very stable. Could you also commit the source for your modified ucgendat? Or is it there somewhere? There are some interesting functions available in the ucdata package; some of them might benefit mbstring, so perhaps it is worth a look? I think Unicode normalization should be useful to people. If you want to do matching (looking for equal Unicode strings), you really need this. But I haven't really seen anyone ask for this yet. So far I have avoided this problem since I've been using OpenLDAP to store data, and it does the necessary normalization and matching for me, if I stored Unicode in another database... If for instance you use some SQL database, you should normalize all data before storing it, and also normalize strings in queries. Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c
At 11:03 PM 10/9/2002 +0200, Sterling Hughes wrote: On Wed, 2002-10-09 at 22:56, Derick Rethans wrote: On Wed, 9 Oct 2002, Andi Gutmans wrote: At 10:35 PM 10/9/2002 +0200, Sterling Hughes wrote: On Wed, 2002-10-09 at 22:21, Thies C. Arntzen wrote: On Wed, Oct 09, 2002 at 06:29:45PM -, Sterling Hughes wrote: sterlingWed Oct 9 14:29:45 2002 EDT Modified files: /php4/ext/standard array.c Log: clean these functions up using zend_parse_parameters and nuke the use of HASH_OF() which is inappropriate in these cases... will prev still work on objects after your patch? none of them do - none of them should either - why would you want to access an object like you would an _indexed_ array? -Sterling You might want to traverse all of the members of an object. I find it worrying that people break BC whenever they feel like it and without consulting php-dev first. I think we should make a rule that BC should not be broken unless discussed on php-dev. I have to agree about that... I take that back, you could use key(), I guess, but there are certainly better ways to do that. Its not exactly breaking bc if its undocumented and widely unused. Php-dev and Php-cvs are not all users, but it does give a good experience base of people who have programmed php regularly and in-depth. Look at the proto of the function, its been that way for awhile, its been made clear that reset(), next() and prev() are meant for arrays. My guess is that this is legacy code (from what i can tell most php3 code was written using the HASH_OF macro), but it was not intended to be this way. I wasn't wantonly breaking bc, as you can see even the function prototypes show that it was meant to be used with an array, so i kept it consistent with the documentation and prototypes, and what I considered to be reasonable leeway, i'll gladly change it back if that's the general concensus here though (I would like to hear that at least one person has actually used this though.) I haven't :) Anyway, I understand your reasoning. I just felt that lately too many things have been breaking around us. I'm cc'ing php-dev as that is a bigger forum. Have any of you guys used these functions on objects? Do you think people use them? Personally I agree that they shouldn't work but I'm just worried about breaking BC. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
