RE: [PHP-DEV] mbstring
Derick pretty much said it for me... but more explicitly, mbstring isn't stable enough to be default. -- james -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 6:41 AM To: Masaki Fujimoto Cc: James Cox; Wez Furlong; Php-Dev Subject: Re: [PHP-DEV] mbstring On Mon, 2 Sep 2002, Masaki Fujimoto wrote: Hi, let me vote not to remove mbstring (as a default one). I'd vote for setting it off by default _for now_, and enable it after 4.3. has branched, so we have a kick ass i18n solution in PHP5 replacing all code it duplicates. yes, I can understand the thought that singlebyte users seem mbstirng module is somehow 'extra' one. but please understand that this module is indispensable for multibyte users (at least), and AFAIK there are growing numbers of multibyte users of PHP. we japanese, korean and chinese have to handle 3 (or more) types of encoding (+ UNICODE), and we cannot even count number characters (not bytes) w/out mbstring. besides, I (we?) always make best effort that multibyte features do not harm any other ones, and if it causes bugs, we (Yasuo, Rui or I) will fix it ASAP (maybe:). Too bad that you can't predict anything. of course we can --enable-mbstring even if msbstirg is disabled by default, but please remember that not all the users can always exec 'configure' and edit php.ini. (use dl() ? hmm...) Every respectable sysadm in eastern countries installing PHP should be aware fo this and enable mbstring for his users. finally, it is true that mbstring is not the 'golden bullet':), but it would be far better if we have some kind of bullets, isn't it ? Derick -- - Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.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: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, Marcus Börger wrote: AND exif is disliked by the developers on this list so why do we care now? Markus, that makes no sense. Just because some ppl don't want it exif enabled by default doesn't make us 'dislike' exif, it doesn't make us (atleast not me) like you less. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On 09/01/02, James Cox [EMAIL PROTECTED] wrote: mbstring isn't a gold module which should be enabled by default. But there was a discussion and it was agreed to enable it by default! That is, it's still -- as i see it -- just a bit more than experimental. mbstring work is being done on sourceforge! Actually, thats incorrect. mbstring in PHP CVS is based on work that has matured since PHP 3. A new, rewritten version is being developed outside of our CVS so as not to screw things up for the mainstream. So I want to 'disable' it by default. If you want encoding, just enable it. But you're right, i've never needed to create a truely globalized/localized app. (and from general principles, if you feel you need to localize any more than your ui/strings.) But the issue is not with mbstring encoding, it's with people who turn on an advanced feature without reading the docs. --enable-mbstring is on by default and works just fine. --enable-mbstr-enc-trans is the advanced option (that was causing problems for RedHat because people were enabling it without configuring it correctly for their system) - this option is DISABLED by default. Why can't we just keep it at that? Lets make a comparison: the session module has an little option called --enable-trans-sid. This option is similar to the mbstring option in question, in that it transparently converts stuff. Now, should we disable the session module by default because someone didn't read the docs and just enabled it and then complained that it was rewriting stuff?? Or how about another comparison: apache has a -DBIG_SECURITY_HOLE (or similar define) that allows it to run as root. Should they remove that option just because some idiot out there adds it to their compile options without understanding what it does? (And there *are* production systems that require this in order to function - Cobalt Raqs for example). Why can't we have the configure print a warning that the enc-trans may cause problems if it is not configured correctly for your system/application? Enabling mbstring by default was a milestone that meant that people could start writing some real-world applications because the PHP infrastructure for them was guaranteed to be there by default; don't just drop it out now because people don't read the docs. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 05:15 02/09/2002, Yasuo Ohgaki wrote: Marcus Börger wrote: At 01:24 02.09.2002, you wrote: Brian France wrote: I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if mbstring is loaded (or built in) and if not print a warning that some of its functionality may not work correctly unless mbstring is loaded (or built in)? It's not a good idea. What we need is smart ini parser and module loader that understand module dependecy and proper loading order. We already had some discussion on some IF statements in ini files already. I guess we might call to another mail thread here and hope we find a volunteer. I will not invent any work here since that would be totally useless. I think having a IF in php.ini is good idea. -1 on that. php.ini should not be scriptable, it opens a whole new set of problems. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 03:41 02/09/2002, Brian France wrote: I know this is ugly, but what about making the extensions handle it themselves? It's actually not ugly at all. Letting the modules handle it themselves is the Right Way, because only they know what they need. The only question is whether we need to give them some extra infrastructure to make the process easier. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with http://php.net
Hi, maybe offtopic but I cannot access php.net . I thought that it is maybe problem with my connection so tried http://network-tools.com to fetch the headers and teh result is timeout. Best regards Andrey Hristov -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with http://php.net
Too much downloads Best regards Andrey Hristov - Original Message - From: Andrey Hristov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 02, 2002 11:35 AM Subject: [PHP-DEV] Problem with http://php.net Hi, maybe offtopic but I cannot access php.net . I thought that it is maybe problem with my connection so tried http://network-tools.com to fetch the headers and teh result is timeout. Best regards Andrey Hristov -- 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] Problem with http://php.net
some of the httpd processes went defunct (also, because rotatelogs did) . http://www.php.net/server-status -- works now. :) -- james -Original Message- From: Andrey Hristov [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:39 AM To: Andrey Hristov; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Problem with http://php.net Too much downloads Best regards Andrey Hristov - Original Message - From: Andrey Hristov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 02, 2002 11:35 AM Subject: [PHP-DEV] Problem with http://php.net Hi, maybe offtopic but I cannot access php.net . I thought that it is maybe problem with my connection so tried http://network-tools.com to fetch the headers and teh result is timeout. Best regards Andrey Hristov -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problem with http://php.net
also, if you have any issues with php.net servers/services, send mail to [EMAIL PROTECTED] This goes to everyone who has root or sudo on the boxes.. for example i'll get paged if something gets broken. This should guarentee a faster response time (although, php-dev works too :)) -- james -Original Message- From: James Cox [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:53 AM To: Andrey Hristov; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Problem with http://php.net some of the httpd processes went defunct (also, because rotatelogs did) . http://www.php.net/server-status -- works now. :) -- james -Original Message- From: Andrey Hristov [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:39 AM To: Andrey Hristov; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Problem with http://php.net Too much downloads Best regards Andrey Hristov - Original Message - From: Andrey Hristov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 02, 2002 11:35 AM Subject: [PHP-DEV] Problem with http://php.net Hi, maybe offtopic but I cannot access php.net . I thought that it is maybe problem with my connection so tried http://network-tools.com to fetch the headers and teh result is timeout. Best regards Andrey Hristov -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with http://php.net
Yup, I saw /server-status - thus i wrote too much downloads Best regards Andrey Hristov - Original Message - From: James Cox [EMAIL PROTECTED] To: Andrey Hristov [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, September 02, 2002 11:53 AM Subject: RE: [PHP-DEV] Problem with http://php.net some of the httpd processes went defunct (also, because rotatelogs did) . http://www.php.net/server-status -- works now. :) -- james -Original Message- From: Andrey Hristov [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:39 AM To: Andrey Hristov; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Problem with http://php.net Too much downloads Best regards Andrey Hristov - Original Message - From: Andrey Hristov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 02, 2002 11:35 AM Subject: [PHP-DEV] Problem with http://php.net Hi, maybe offtopic but I cannot access php.net . I thought that it is maybe problem with my connection so tried http://network-tools.com to fetch the headers and teh result is timeout. Best regards Andrey Hristov -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HAVE_GD_STRINGFTEX
On Mon, 2 Sep 2002, Melvyn Sopacua wrote:
MS Looking at the name of the function, I guess this is used for the __optional__
'extra' array, so why is this extension:
MS 1) Claiming to support freetype
MS 2) and subsequently disabeling all relevant functions
MS 3) for an optional argument?
MS
MS This applies to both 4.2.2 and 4.2.3.
Attached a patch, which works for me, with 4.2.2.
Please look it over, or explain why this is not a good idea.
Thanx,
Melvyn
Index: gd.c
===
RCS file: /repository/php4/ext/gd/gd.c,v
retrieving revision 1.179.2.2
diff -u -r1.179.2.2 gd.c
--- gd.c4 Jun 2002 02:35:00 - 1.179.2.2
+++ gd.c2 Sep 2002 01:33:23 -
-2655,8 +2655,12
Give the bounding box of a text using fonts via freetype2 */
PHP_FUNCTION(imageftbbox)
{
-#if HAVE_LIBGD20 HAVE_LIBFREETYPE HAVE_GD_STRINGFTEX
+#if HAVE_LIBGD20 HAVE_LIBFREETYPE
+# if HAVE_GD_STRINGFTEX
php_imagettftext_common(INTERNAL_FUNCTION_PARAM_PASSTHRU, TTFTEXT_BBOX, 1);
+# else
+ php_imagettftext_common(INTERNAL_FUNCTION_PARAM_PASSTHRU, TTFTEXT_BBOX, 0);
+# endif
#else
php_error(E_WARNING, %s(): No FreeType 2 support in this PHP build,
get_active_function_name(TSRMLS_C));
RETURN_FALSE;
-2668,8 +2672,12
Write text to the image using fonts via freetype2 */
PHP_FUNCTION(imagefttext)
{
-#if HAVE_LIBGD20 HAVE_LIBFREETYPE HAVE_GD_STRINGFTEX
+#if HAVE_LIBGD20 HAVE_LIBFREETYPE
+# if HAVE_GD_STRINGFTEX
php_imagettftext_common(INTERNAL_FUNCTION_PARAM_PASSTHRU, TTFTEXT_DRAW, 1);
+# else
+ php_imagettftext_common(INTERNAL_FUNCTION_PARAM_PASSTHRU, TTFTEXT_DRAW, 0);
+# endif
#else
php_error(E_WARNING, %s(): No FreeType 2 support in this PHP build,
get_active_function_name(TSRMLS_C));
RETURN_FALSE;
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
Having been using it to handle more than 105,000 email messages over the last 18 months *in production*, I have to disagree. I have to say that I'm appalled that most of the people making these I completely agree comments have probably never even tried to use mbstring; most certainly haven't even read the bugzilla report and therefore don't even realize what the problem is. rant to=php-dev If you're going vote on something, *PLEASE* make yourselves aware of the real issues. PHP needs some forward thinkers, and brainlessly agreeing to disable a module, based on the valid principle of PECL removing cruft, is not forward thinking. The noise has only helped to obscure the issue even more, because people are all jumping on the PECL is great bandwagon, when that is *not* the issue here. It's nice to see that people want to keep PHP clean, but *please* let's understand what we are voting for before we actually vote. /rant Now, the mbstr-enc-trans might have had some stability issues, but as I've been saying, it is NOT enabled by default, and lets print a warning about it when it is turned on. Don't penalize serious developers because of this (already resolved) issue. --Wez. On 09/02/02, James Cox [EMAIL PROTECTED] wrote: Derick pretty much said it for me... but more explicitly, mbstring isn't stable enough to be default. Derick wrote: Every respectable sysadm in eastern countries installing PHP should be aware fo this and enable mbstring for his users. No, PHP should include encoding support by default - this was already discussed and decided here on php-dev. (That's why it's enabled by default in 4.2). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HAVE_GD_STRINGFTEX
Hey, this was already discussed a while ago on php-dev. Your fix is correct, but I wonder why it never made it into the code? --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
I do agree with Wez (not 'completely agree', though ;) FWIW, mbstring was/is indeed enabled by default under Windows, and I think that at this stage this is not a good idea. There was at least one serious crash in the code that was introduced by the changes, into both the mbstring version and the non mbstring version of the input handling routines, but I don't really attribute it to mbstring. happens. I do think that the large amount of duplicate code in there is not a good idea at all, and it should be refactored into a more generic solution - fixing the same bug twice, once under Windows (because it was in the mbstring code) and once under UNIX (becasue it was also in the non-mbstring code) was not fun at all. I also think that the large amount of mbstring-related MFH's were not a good idea either. Good i18n support is a strategic goal for PHP, and mbstring should be a big step in that direction. But I think that the people here who said that it's something for v5.0 and not v4.x made a good point. Zeev At 11:52 02/09/2002, Wez Furlong wrote: Having been using it to handle more than 105,000 email messages over the last 18 months *in production*, I have to disagree. I have to say that I'm appalled that most of the people making these I completely agree comments have probably never even tried to use mbstring; most certainly haven't even read the bugzilla report and therefore don't even realize what the problem is. rant to=php-dev If you're going vote on something, *PLEASE* make yourselves aware of the real issues. PHP needs some forward thinkers, and brainlessly agreeing to disable a module, based on the valid principle of PECL removing cruft, is not forward thinking. The noise has only helped to obscure the issue even more, because people are all jumping on the PECL is great bandwagon, when that is *not* the issue here. It's nice to see that people want to keep PHP clean, but *please* let's understand what we are voting for before we actually vote. /rant Now, the mbstr-enc-trans might have had some stability issues, but as I've been saying, it is NOT enabled by default, and lets print a warning about it when it is turned on. Don't penalize serious developers because of this (already resolved) issue. --Wez. On 09/02/02, James Cox [EMAIL PROTECTED] wrote: Derick pretty much said it for me... but more explicitly, mbstring isn't stable enough to be default. Derick wrote: Every respectable sysadm in eastern countries installing PHP should be aware fo this and enable mbstring for his users. No, PHP should include encoding support by default - this was already discussed and decided here on php-dev. (That's why it's enabled by default in 4.2). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
Wez, lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when I needed multibyte support. But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. if we want to do some kind of auto-compile thing, then perhaps a script which detects-and-compiles every extension could get stuck in /php4 for those who were really lazy. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Compiling modules by default which are buggy just compounds the problem. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 13:19 02/09/2002, James Cox wrote: As I see it, PHP was designed with speed and simplicity in mind. It was indeed.. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Not really. Speed-wise, adding modules has a negligible effect. As far as simplicity goes, we're talking about simplicity for the developer. Bundling features does make things simpler for the majority of the target audience. Compiling modules by default which are buggy just compounds the problem. I obviously agree with that. I do want to see mbstring become an integrated part of PHP, but not a moment sooner than when it is stable. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 13:19 02/09/2002, James Cox wrote: As I see it, PHP was designed with speed and simplicity in mind. It was indeed.. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Not really. Speed-wise, adding modules has a negligible effect. As far as simplicity goes, we're talking about simplicity for the developer. Bundling features does make things simpler for the majority of the target audience. Compiling modules by default which are buggy just compounds the problem. I obviously agree with that. I do want to see mbstring become an integrated part of PHP, but not a moment sooner than when it is stable. exactly.. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On 09/02/02, James Cox [EMAIL PROTECTED] wrote: But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). But it *is* VERY stable in the default configuration. All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. The transparent encoding style options - including that of the sessions should *never* be enabled by default precisely because they are transparent and cause unexpected behaviour for people that haven't read the docs. I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. Umm, but the behaviour was only unexpected because he enabled an option without reading the docs to find out what it does. (regardless of the fact that there was a slight bug: the very next bug report would be along the lines of PHP is changing encodings automatically). if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. But in that situation, you would be paying close attention to what you were building anyway. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. No, you can always disable those extensions. The default extensions were *voted* in for a reason. Compiling modules by default which are buggy just compounds the problem. Yes, but the bug was only present in an advanced optional feature that would cause unexpected behaviour for non-mbstring aware people anyway. *and it has already been fixed a number of weeks ago* As I've said, mbstring is very stable in it's default configuration - the codebase has been around for years and tested to death by a very dedicated i18n team *in production*. The development you keep referring to is part of a streamable filter *add-on* that does not change the existing code that people rely on. Why don't you test the current CVS to see if it still has a problem, if it does, lets fix it. Please don't take a step backwards by disabling this extension by default just because you are afraid that people can abuse advanced options. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
But it *is* VERY stable in the default configuration. All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. The transparent encoding style options - including that of the sessions should *never* be enabled by default precisely because they are transparent and cause unexpected behaviour for people that haven't read the docs. Exactly. Most unexpected behaviour cases were in regards to transparent encoding. I have discovered this myself after spending couple of hours trying to hunt down a bug. This is why, we have agreed back then that transparent encoding option should be turned off by default, which Yasuo did. We have also agreed to leave mbstring module itself on by default because there seemed to be no stability issues with it. Therefore I think that the things should be left as they are in the cvs, mbstring enabled by default and transparent encoding disabled by default. The windows version should have the same defaults as well. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with filedownload + session_start() in combination with SSL and IE
I have a problem with file downloads using SSL in combination with PHP's
sessionmanagement.
Sample:
?php
if( !session_is_registered('idtest') ) {
session_register('idtest');
} // if
header(Content-type: application/octet-stream);
header(Content-Disposition: attachment; filename=ergebnis.xml);
fpassthru( fopen(test3.dat,r) );
?
This won't work .. if the sessionlines are commented out it works fine ... I
also disabled cookies but that didn't help.
The same bug has been described by a different source at
http://www.phpbuilder.com/board/showthread.php?s=4f0de3f2a83a0ef83205e6c5009
ef543threadid=10208295highlight=download+SSL
This might be a bug in IE but maybe there is a way to work around ...
Hope somebody could help me out,
./regards
Florian
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with filedownload + session_start() in combination with SSL and IE
I have a problem with file downloads using SSL in combination with PHP's
sessionmanagement.
Sample:
?php
if( !session_is_registered('idtest') ) {
session_register('idtest');
} // if
header(Content-type: application/octet-stream);
header(Content-Disposition: attachment; filename=ergebnis.xml);
fpassthru( fopen(test3.dat,r) );
?
This won't work .. if the sessionlines are commented out it works fine ... I
also disabled cookies but that didn't help.
The same bug has been described by a different source at
http://www.phpbuilder.com/board/showthread.php?s=4f0de3f2a83a0ef83205e6c5009
ef543threadid=10208295highlight=download+SSL
This might be a bug in IE but maybe there is a way to work around ...
Hope somebody could help me out,
./regards
Florian
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
Wez, lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when I needed multibyte support. James, Let's stay consistent here. Your opinion changes more than Microsoft's .NET strategy... In your original message you stated that you wanted to remove mbstring. If you've changed your opinion fine, but don't chide Wez for responding to the opinion so forcefully expressed in your original message. Furthermore, you've said that you've never used mbstring extension and that mbstring is certainly not a gold extension in prior messages, what do you think Wez is going to respond too? But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. _Every_ extension needs more work, a redesign, etc. The mbstring extension minus perhaps some of the newer features is quite solid, much more so than many of the other standard php extension (for example, xml and domxml), its being redesigned and reworked -- that's true, but that is imho just a matter of evolution and improvement. I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. Yes, unexpected behaviour does suck, but this is not unexpected... if you explicitly _enable_ a configuration option, and then it yields a certain documented behaviour, I would hardly call that unexpected... if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. if we want to do some kind of auto-compile thing, then perhaps a script which detects-and-compiles every extension could get stuck in /php4 for those who were really lazy. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Compiling modules by default which are buggy just compounds the problem. As Zeev stated this doesn't really hurt speed, actually what you're suggesting would provide a larger speed hit (although not signifigant) than the current situation. As far as compiling in buggy modules -- yes, of course, that's stating the obvious. However mbstring is certainly not that buggy, unless you enable a further option, and that's debatable. From reading Wez's message, I really don't see a reason to unbundle/unenable it -- as long as new development doesn't cause a new api (backwards compat), i wasn't aware before that it didn't cause any bc issues. I don't know how many people remember the bundling of XML with PHP4, but there were _quite_ a few kinks with that integration, causing segfaults and unexpected behaviour (especially when dealing with objects). When bundling a new extension, you should always expect a few kinks, with mbstring it seems that there are less than usual (we also had major problems with MySQL integration by the way...) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE:
-Original Message- From: Sent: None Subject: Date: Mon, 2 Sep 2002 06:42:15 -0500 (EST) From: Sterling Hughes [EMAIL PROTECTED] To: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-Mailer: SquirrelMail (version 1.2.4) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: RE: [PHP-DEV] mbstring Wez, lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when I needed multibyte support. James, Let's stay consistent here. Your opinion changes more than Microsoft's .NET strategy... In your original message you stated that you wanted to remove mbstring. no, i've never wanted to remove mbstring, i just would like to see it not enabled by default. If you've changed your opinion fine, but don't chide Wez for responding to the opinion so forcefully expressed in your original message. Furthermore, you've said that you've never used mbstring extension and that mbstring is certainly not a gold extension in prior messages, what do you think Wez is going to respond too? no i have used it, and yes, it's a useful extension, my point is that it's not a gold extension, and thus shouldn't be enabled by default. But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. _Every_ extension needs more work, a redesign, etc. The mbstring extension minus perhaps some of the newer features is quite solid, much more so than many of the other standard php extension (for example, xml and domxml), its being redesigned and reworked -- that's true, but that is imho just a matter of evolution and improvement. xml/domxml aren't enabled by default. I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. Yes, unexpected behaviour does suck, but this is not unexpected... if you explicitly _enable_ a configuration option, and then it yields a certain documented behaviour, I would hardly call that unexpected... actually, Phil removed the --enable-mbstring configure option too -- _expecting_ mbstring not to be enabled anymore, hence my issue. if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. if we want to do some kind of auto-compile thing, then perhaps a script which detects-and-compiles every extension could get stuck in /php4 for those who were really lazy. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Compiling modules by default which are buggy just compounds the problem. As Zeev stated this doesn't really hurt speed, actually what you're suggesting would provide a larger speed hit (although not signifigant) than the current situation. As far as compiling in buggy modules -- yes, of course, that's stating the obvious. However mbstring is certainly not that buggy, unless you enable a further option, and that's debatable. From reading Wez's message, I really don't see a reason to unbundle/unenable it -- as long as new development doesn't cause a new api (backwards compat), i wasn't aware before that it didn't cause any bc issues. I don't know how many people remember the bundling of XML with PHP4, but there were _quite_ a few kinks with that integration, causing segfaults and unexpected behaviour (especially when dealing with objects). When bundling a new extension, you should always expect a few kinks, with mbstring it seems that there are less than usual (we also had major problems with MySQL integration by the way...) -Sterling -- sure, which is why it should be tested fully before enabled by default. PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. No, you can always disable those extensions. The default extensions were *voted* in for a reason. Still, I think it makes more sense to enable, not disable. What extensions are enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd errors when working with php, because there are extensions i didn't expect built in. Compiling modules by default which are buggy just compounds the problem. Yes, but the bug was only present in an advanced optional feature that would cause unexpected behaviour for non-mbstring aware people anyway. *and it has already been fixed a number of weeks ago* As I've said, mbstring is very stable in it's default configuration - the codebase has been around for years and tested to death by a very dedicated i18n team *in production*. The development you keep referring to is part of a streamable filter *add-on* that does not change the existing code that people rely on. maybe i'm jaded against mbstring here, but i experienced two unexpected crashes which i traced back to mbstring, but with no real cause that i could find, as well as watching the cvs commits -- and also wondering why on earth they feel they want to work on mbstring sf.jp. CVS is quite capable of maintaining code (hence branches). Why don't you test the current CVS to see if it still has a problem, if it does, lets fix it. I will do that. Please don't take a step backwards by disabling this extension by default just because you are afraid that people can abuse advanced options. I'm not taking a step backwards, just trying to remove the potential for confusion. If people think that register_globals is confusing, and causes issues, then we should also not build stuff by default. I *HATE* it when I don't know what's being built. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE:
-Original Message- From: Sent: None Subject: Date: Mon, 2 Sep 2002 06:42:15 -0500 (EST) From: Sterling Hughes [EMAIL PROTECTED] To: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-Mailer: SquirrelMail (version 1.2.4) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: RE: [PHP-DEV] mbstring Wez, lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when I needed multibyte support. James, Let's stay consistent here. Your opinion changes more than Microsoft's .NET strategy... In your original message you stated that you wanted to remove mbstring. no, i've never wanted to remove mbstring, i just would like to see it not enabled by default. If you've changed your opinion fine, but don't chide Wez for responding to the opinion so forcefully expressed in your original message. Furthermore, you've said that you've never used mbstring extension and that mbstring is certainly not a gold extension in prior messages, what do you think Wez is going to respond too? no i have used it, and yes, it's a useful extension, my point is that it's not a gold extension, and thus shouldn't be enabled by default. But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. _Every_ extension needs more work, a redesign, etc. The mbstring extension minus perhaps some of the newer features is quite solid, much more so than many of the other standard php extension (for example, xml and domxml), its being redesigned and reworked -- that's true, but that is imho just a matter of evolution and improvement. xml/domxml aren't enabled by default. xml is, it has been since the PHP 4.0 betas I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. Yes, unexpected behaviour does suck, but this is not unexpected... if you explicitly _enable_ a configuration option, and then it yields a certain documented behaviour, I would hardly call that unexpected... actually, Phil removed the --enable-mbstring configure option too -- _expecting_ mbstring not to be enabled anymore, hence my issue. I'm going to make a generalization, and say that most php users are not illiterate like Phil, and can in fact, should the need arise, read the documentation. Perhaps if Phil has further problems he can get a text-voice software that will read him the documentation outloud. These programs won't properly pronounce my sarcasm, but it should be a good start. if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. if we want to do some kind of auto-compile thing, then perhaps a script which detects-and-compiles every extension could get stuck in /php4 for those who were really lazy. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Compiling modules by default which are buggy just compounds the problem. As Zeev stated this doesn't really hurt speed, actually what you're suggesting would provide a larger speed hit (although not signifigant) than the current situation. As far as compiling in buggy modules -- yes, of course, that's stating the obvious. However mbstring is certainly not that buggy, unless you enable a further option, and that's debatable. From reading Wez's message, I really don't see a reason to unbundle/unenable it -- as long as new development doesn't cause a new api (backwards compat), i wasn't aware before that it didn't cause any bc issues. I don't know how many people remember the bundling of XML with PHP4, but there were _quite_ a few kinks with that integration, causing segfaults and unexpected behaviour (especially when dealing with objects). When
RE: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, James Cox wrote: JC Still, I think it makes more sense to enable, not disable. What extensions are enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd errors when working with php, because there are extensions i didn't expect built in. ./configure --help | egrep -- '--(without|disable)' exception to the rule being mysql. -- Melvyn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, James Cox wrote: JC Still, I think it makes more sense to enable, not disable. What extensions are enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd errors when working with php, because there are extensions i didn't expect built in. ./configure --help | egrep -- '--(without|disable)' exception to the rule being mysql. Yes. It was a rhetorical question -- i wonder if this is worth another page in the manual? james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, James Cox wrote: JC On Mon, 2 Sep 2002, James Cox wrote: JC JC JC Still, I think it makes more sense to enable, not disable. JC What extensions are enabled by default anyhow? I am not aware of JC a list. Perhaps that's why i get odd errors when working with JC php, because there are extensions i didn't expect built in. JC JC ./configure --help | egrep -- '--(without|disable)' JC JC exception to the rule being mysql. JC JC Yes. It was a rhetorical question -- I believe you :-) JC i wonder if this is worth another page JC in the manual? Definetely. Remember register_globals? You just can't mention it often enough. Further more if people can count on this behaviour, they can more easily create buildscripts. But then mysql shouldn't be the exception and a new module, can never be enabled by default in a new release (don't recall this ever happening, but still). -- Melvyn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with http://php.net
This goes to everyone who has root or sudo on the boxes.. for example i'll get paged if something gets broken. This should guarentee a faster response time (although, php-dev works too :)) Wow. I guess your pager does not stand still a second then... :) Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problem with http://php.net
This goes to everyone who has root or sudo on the boxes.. for example i'll get paged if something gets broken. This should guarentee a faster response time (although, php-dev works too :)) Wow. I guess your pager does not stand still a second then... :) Well, it works as a good vibrator.. no, systems stuff isn't that busy... -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with http://php.net
my GSM too, all IM messages go there when i am not at the comp. it's 2am and someone wanted to say hi :))) or anything else . Best regards Andrey Hristov P.S. Offtopic sorry - Original Message - From: James Cox [EMAIL PROTECTED] To: Stefan Esser [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, September 02, 2002 4:01 PM Subject: RE: [PHP-DEV] Problem with http://php.net This goes to everyone who has root or sudo on the boxes.. for example i'll get paged if something gets broken. This should guarentee a faster response time (although, php-dev works too :)) Wow. I guess your pager does not stand still a second then... :) Well, it works as a good vibrator.. no, systems stuff isn't that busy... -- james -- 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] Problem with http://php.net
On Mon, 2 Sep 2002, Andrey Hristov wrote: P.S. Offtopic sorry funny things are allowed as off topic posts :) Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with http://php.net
Back to the topic... When will the MX be up again? Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with http://php.net
P.S. Offtopic sorry funny things are allowed as off topic posts :) Derick Such as Derick's cross dressing tendancies? heh :P [sorry, couldnt resist] -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problem with http://php.net
Back to the topic... When will the MX be up again? The box actually hasn't died yet. SSH and SMTP are open, and seem to be listening -- it is possible to make a connection to them. For some reason however... ssh doesn't auth, and then times out... so there are probably a bunch of defunct processes hanging about. Syancor should be at work in about 2 hours or so.. (i believe they are west coast). We should see the box start again then. I am in the understanding that there is a plan to ditch this box ASAP, and so we'll move the mx/master capabilities to pair2.php.net, and move the various sites to rack1.php.net with it's bandwidth limitations. -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with http://php.net
On Mon, 2 Sep 2002, Dan Hardiker wrote: Such as Derick's cross dressing tendancies? heh :P [sorry, couldnt resist] h! Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problem with http://php.net
P.S. Offtopic sorry funny things are allowed as off topic posts :) Derick Such as Derick's cross dressing tendancies? heh :P [sorry, couldnt resist] Where the hell did that come from? :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problem with http://php.net
Cross-dressing. Vibrators. Oh my. Breadsticks in the nose anyone? .mike -Original Message- From: Dan Hardiker [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:22 AM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Problem with http://php.net P.S. Offtopic sorry funny things are allowed as off topic posts :) Derick Such as Derick's cross dressing tendancies? heh :P [sorry, couldnt resist] -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd -- 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] Structures and PHP
Knowing that I can't create actual structures in PHP, I recently realized I could do
something like this.
?php
function create_Struct($struct_array)
{
$struct_array=array(
conn = 0,
host = ,
u_name = ,
pass = ,
db =
);
return $struct_array;
}
$db_struct = create_Struct($db_struct);
$db_pointer = $db_struct;
print_r($db_pointer);
?
What I'm curious about is the possibility of making
something like this built in, for lack of a better term. I've heard a number of C
guys asking about this on some message boards and came up with this as a result.
Is there a better way? What do you guys think?
Later on,
TRC
--
___
Get your free email from http://mymail.operamail.com
Powered by Outblaze
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Structures and PHP
On Mon, Sep 02, 2002 at 10:06:50PM +0800, Terrence Cox wrote :
Knowing that I can't create actual structures in PHP, I recently realized I could do
something like this.
?php
function create_Struct($struct_array)
{
$struct_array=array(
conn = 0,
host = ,
u_name = ,
pass = ,
db =
);
return $struct_array;
}
$db_struct = create_Struct($db_struct);
$db_pointer = $db_struct;
print_r($db_pointer);
?
What I'm curious about is the possibility of making
something like this built in, for lack of a better term. I've heard a number of C
guys asking about this on some message boards and came up with this as a result.
Is there a better way? What do you guys think?
Not really. Some also missuse objects for that purpose. heck,
I remember asking this question first when I came to PHP
years ago :) I got stuck to use arrays at first. Later and
never needed this anymore (stopped coding PHP like C) and
mainly used real objects etc.
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Finally, if someone actually flying a plane is relying on
a freakin' webcam to land, we're all in trouble.
- A /. poster.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Structures and PHP
Terrence Cox wrote: Is there a better way? Why not declare a class for this? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
SV: [PHP-DEV] Structures and PHP
I agree with Markus. PHP isn't C (although it resembles on some points), and
likewise you shouldn't use it, as you would C.
Play PHP by its own rules and use the language contructs made available to
you.
You could argue, that C only has structs because a) it is strongly typed and
therefore need a tool for complex datatypes and/or b) it doesn't implement
hashes in its core.
- Carsten
-Oprindelig meddelelse-
Fra: Markus Fischer [mailto:[EMAIL PROTECTED]]
Sendt: 2. september 2002 15:16
Til: Terrence Cox
Cc: [EMAIL PROTECTED]
Emne: Re: [PHP-DEV] Structures and PHP
On Mon, Sep 02, 2002 at 10:06:50PM +0800, Terrence Cox wrote :
Knowing that I can't create actual structures in PHP, I
recently realized I could do something like this.
?php
function create_Struct($struct_array)
{
$struct_array=array(
conn = 0,
host = ,
u_name = ,
pass = ,
db =
);
return $struct_array;
}
$db_struct = create_Struct($db_struct);
$db_pointer = $db_struct;
print_r($db_pointer);
?
What I'm curious about is the possibility of making
something like this built in, for lack of a better term. I've
heard a number of C guys asking about this on some message boards
and came up with this as a result.
Is there a better way? What do you guys think?
Not really. Some also missuse objects for that purpose. heck,
I remember asking this question first when I came to PHP
years ago :) I got stuck to use arrays at first. Later and
never needed this anymore (stopped coding PHP like C) and
mainly used real objects etc.
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Finally, if someone actually flying a plane is relying on
a freakin' webcam to land, we're all in trouble.
- A /. poster.
--
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] Structures and PHP
Terrence Cox wrote: Is there a better way? Why not declare a class for this? Speed! I wrote a load balancer for a pool of replicated db's (using PHP) and I presently use small connection objects to, you guessed it, maintain the connections to the individual machines. However, wouldn't encapsulating that data (information about the db) in arrays (that are like structures) be faster? Then just offload the methods to plain old functions. I want the data encapsulation without the performance hit. Cheers, T.. -- ___ Get your free email from http://mymail.operamail.com Powered by Outblaze -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows
Sebastian Bergmann wrote: http://www.sebastian-bergmann.de/stuff/build-423rc2.txt Don't know, why it can't find tsrm.lib. Mystery solved: As you can see in the log, I tried to build Release_inline instead of Release_TS_inline. However, Release_inline seems to be configured to link against the Release_TS version of TSRM, which cannot work... Which raises the question of whether or not it makes sense to build PHP without thread-safety on Win32 and maintain two versions of the .dsp/.dsw files. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows
Which raises the question of whether or not it makes sense to build PHP without thread-safety on Win32 and maintain two versions of the .dsp/.dsw files. What gave you idea that non-ts files are maintained :) They're hopelessly obsolete. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows
Edin Kadribasic wrote: What gave you idea that non-ts files are maintained :) They're hopelessly obsolete. So why not nuke them? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows
I still object because I use them every once in a while to check/debug the non TS build under Windows. I do maintain them every other year :) At 18:11 02/09/2002, Edin Kadribasic wrote: So why not nuke them? No objections here to nuking non-ts project files and workspaces on windows. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
On Mon, 2 Sep 2002, Wez Furlong wrote: On 09/01/02, [EMAIL PROTECTED] wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: Are you out of mind? No, not really. It was noted by more than one person that it breaks some simple things in PHP, affecting the bahavior of scripts that are already out there. Umm, how many of those me too's have actually tried using PHP with mbstring? I did use it. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows
hear, hear.. my Linux box is perpetually broken, and the Visual Studio debugger is very nice... Zeev Suraski [EMAIL PROTECTED] wrote in message 5.1.0.14.2.20020902182321.0387b4b0@localhost">news:5.1.0.14.2.20020902182321.0387b4b0@localhost... I still object because I use them every once in a while to check/debug the non TS build under Windows. I do maintain them every other year :) At 18:11 02/09/2002, Edin Kadribasic wrote: So why not nuke them? No objections here to nuking non-ts project files and workspaces on windows. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows
Hmm, not sure what that was, but my Linux boxes are working fine, but yes, VC's debugger is very nice :) At 20:08 02/09/2002, l0t3k wrote: hear, hear.. my Linux box is perpetually broken, and the Visual Studio debugger is very nice... Zeev Suraski [EMAIL PROTECTED] wrote in message 5.1.0.14.2.20020902182321.0387b4b0@localhost">news:5.1.0.14.2.20020902182321.0387b4b0@localhost... I still object because I use them every once in a while to check/debug the non TS build under Windows. I do maintain them every other year :) At 18:11 02/09/2002, Edin Kadribasic wrote: So why not nuke them? No objections here to nuking non-ts project files and workspaces on windows. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] wassup with master.php
Hi, is someone working on master.php.net or what? -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] wassup with master.php
if you'd been paying attention, you would have noticed that the machine it's on is down right now. -- james Hi, is someone working on master.php.net or what? -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. Is --disable-something is too hard to get used to? Yes it is. Why? Because PHP has so many options at this point, finding which modules are automatically enabled isn't terribly easy. More to the point, it's a PITA to find out during the build you forgot to explicitly disable a feature. In general it is easier to enable a feature than to disable a feature (witness Clippy). --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] wassup with master.php
I assumed, I asked if someone where working on it to set it up back... -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet James Cox [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] if you'd been paying attention, you would have noticed that the machine it's on is down right now. -- james Hi, is someone working on master.php.net or what? -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet -- 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] wassup with master.php
yes, we're working on it.. -- james I assumed, I asked if someone where working on it to set it up back... -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet James Cox [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] if you'd been paying attention, you would have noticed that the machine it's on is down right now. -- james Hi, is someone working on master.php.net or what? -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] wassup with master.php
Nice news, nice you're back too. -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet James Cox [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] yes, we're working on it.. -- james I assumed, I asked if someone where working on it to set it up back... -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet James Cox [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] if you'd been paying attention, you would have noticed that the machine it's on is down right now. -- james Hi, is someone working on master.php.net or what? -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
On Mon, Sep 02, 2002 at 03:52:50PM -0400, Dan Kalowsky wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. After some thought, I think I agree with this (disable by default) approach, as well. For instance, if you want just PostgreSQL support, you not only have to --with-pgsql but also --disable-mysql[*]. I don't think there's any harm in asking MySQL users to --enable-mysql support if that's why they want, even if it is purportedly the most popular RDBMS with PHP. Chances are that those same users will likely need to set at least one other ./configure option, anyway. It's much easier, conceptually, to tell PHP users that everything is off by default than look at the './configure --help' output to figure out if you need to explicitly enable (or disable) something. Of course, I'm making general claims without providing any kind of reliable figures here. Perhaps it would be interesting to conduct some kind of anonymous PHP extension survey to see how many people configure / use which modules. [*] Not that MySQL support harms anything, but why compile something you're not going to use? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 22:52 02/09/2002, Dan Kalowsky wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 22:52 02/09/2002, Dan Kalowsky wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 Nice to see you argue that one so eloquently... -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.2.3RC2
4.2.3 RC2 is out - http://www.php.net/~zeev/php-4.2.3RC2.tar.gz Windows binaries will be available soon... (note - if you took the package from there or checked out the CVS tag before it was announced, you may have not gotten the real RC2). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 23:21 02/09/2002, James Cox wrote: Nice to see you argue that one so eloquently... I have in the past, numerous times. I don't think I or anybody else should have to repeat themselves like broken records, you can look it up in the archives. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 02 September 2002 04:16 pm, Zeev Suraski wrote: At 22:52 02/09/2002, Dan Kalowsky wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 - -1!! Are you crazy?! remove --with-mysql as default?! I must be seeing things.mysql is a major reason ppl use php and some(not all!!) dumb sysadmins don't enable anything but the defaults and forget about asking them to enable som'in for you - -- ~Paul Nicholson It said uses Windows 98 or better, so I loaded Linux! Registered Linux User #183202 using Register Linux System # 81891 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9c85KDyXNIUN3+UQRAj6MAJ9Dbu0T4pCN9h/d0vtgsbJp+dIV1gCbB+Z6 Xva9XSblcuCZzGDeLW8D2RQ= =FHIi -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] 4.2.3RC2
Can someone add RC2 to the buildtest-submit page. Ta -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] 4.2.3RC2
On Mon, 2 Sep 2002, Phil Driscoll wrote: Can someone add RC2 to the buildtest-submit page. done Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] 4.2.3RC2
On Monday 02 September 2002 9:06 pm, [EMAIL PROTECTED] wrote: On Mon, 2 Sep 2002, Phil Driscoll wrote: Can someone add RC2 to the buildtest-submit page. Thanks Derick - any chance of adding bison version 1.33 as well :) -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.2.3RC2
On Mon, 2 Sep 2002, Phil Driscoll wrote: On Monday 02 September 2002 9:06 pm, [EMAIL PROTECTED] wrote: On Mon, 2 Sep 2002, Phil Driscoll wrote: Can someone add RC2 to the buildtest-submit page. Thanks Derick - any chance of adding bison version 1.33 as well :) done 2 :) Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
Unfortunately we don't live in a perfect world where sysadmins know how to read and listen to their users requests. That's why mysql for example is enabled by default. (or that's the main reasoning behind it at least) And we can't educate people or force them to anything either. Maybe we should add a general '--disable-all' option? --Jani p.s. I'm +1 for making everything not enabled by default.. -- On Mon, 2 Sep 2002, Jon Parise wrote: On Mon, Sep 02, 2002 at 03:52:50PM -0400, Dan Kalowsky wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. After some thought, I think I agree with this (disable by default) approach, as well. For instance, if you want just PostgreSQL support, you not only have to --with-pgsql but also --disable-mysql[*]. I don't think there's any harm in asking MySQL users to --enable-mysql support if that's why they want, even if it is purportedly the most popular RDBMS with PHP. Chances are that those same users will likely need to set at least one other ./configure option, anyway. It's much easier, conceptually, to tell PHP users that everything is off by default than look at the './configure --help' output to figure out if you need to explicitly enable (or disable) something. Of course, I'm making general claims without providing any kind of reliable figures here. Perhaps it would be interesting to conduct some kind of anonymous PHP extension survey to see how many people configure / use which modules. [*] Not that MySQL support harms anything, but why compile something you're not going to use? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DOM-XML memory leak?
Hi, I want to use the dom-xml extension in a production environment, is the dom-xml memory leak significant, ie will the whole machine run out of available memory or ? Please advice if there's a fix or version that does not leak. Thanks -- This email was sent with Ximian Evolution. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Default extensions (was: mbstring)
Unfortunately we don't live in a perfect world where sysadmins know how to read and listen to their users requests. That's why mysql for example is enabled by default. (or that's the main reasoning behind it at least) And we can't educate people or force them to anything either. Maybe we should add a general '--disable-all' option? i'm +1 for that if it means that first it disables everything, and then you enable stuff bit by bit... i still don't see why we shouldn't just disable everything by default and write a 'default configure' script... -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOM-XML memory leak?
On Mon, Sep 02, 2002 at 04:42:38PM -0400, Al Baker wrote : I want to use the dom-xml extension in a production environment, is the dom-xml memory leak significant, ie will the whole machine run out of available memory or ? You mean this built in feature that domxml leaks a few bytes every hour? Err, really, what are you talking about? Do you have a bug report ID or something concrete you're talking about but missed to mentioned ? ;) cheers -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Finally, if someone actually flying a plane is relying on a freakin' webcam to land, we're all in trouble. - A /. poster. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOM-XML memory leak?
On Mon, 2 Sep 2002, Markus Fischer wrote: On Mon, Sep 02, 2002 at 04:42:38PM -0400, Al Baker wrote : I want to use the dom-xml extension in a production environment, is the dom-xml memory leak significant, ie will the whole machine run out of available memory or ? You mean this built in feature that domxml leaks a few bytes every hour? Err, really, what are you talking about? Do you have a bug report ID or something concrete you're talking about but missed to mentioned ? ;) Al talks presumably about the mentioning of a leak in the PHP Weekly Newsletter, which I reported last week on php-dev. It's not really serious in my opinion, a few bytes per request. But I had no time to investigate further. Maybe I shouldn't publicly announce such stuff in the future, it only scares the hell out of people :) Al, if you really concerned about it, set MaxRequestsPerChild in httpd.conf (if you're using apache) to something reasonabe and you won't even notice anything. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
i still don't see why we shouldn't just disable everything by default and write a 'default configure' script... I don't see why you're so upset that some extensions are enabled by default. The main rule so far was if the extension is stable and if it does not depend on external libraries it was enabled. This was done so people who get PHP through hosted services have the most PHP functionality available to them. This IMHO outweighs the slight inconvenience of adding a few configure options for people who compile PHP themselves. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.2.3RC2
4.2.3 RC2 is out - http://www.php.net/~zeev/php-4.2.3RC2.tar.gz Windows binaries will be available soon... http://ftp.proventum.net/pub/php/win32/php-4.2.3RC2-Win32.zip Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
[EMAIL PROTECTED] wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: [EMAIL PROTECTED] wrote: No, not really. It was noted by more than one person that it breaks some simple things in PHP, affecting the bahavior of scripts that are already out there. Until it is totally stable (which you yourself it is not yet) it should not be enabled by default. How, after 4.3 is branched What problem? For example the bug with the request variables, which might be fixed in CVS now, but it isn't fixed in any release. It was working just like original treat data. The bug was introduced someone changed original treat data, but forgot to update multibyte version. I think this is one of the reason why we should enable it by default so that everyone aware how it supposed to work. I might forget to merge the fix. I'll check it later. As far as I know, there is no serious problem that is not addressed yet. If there is problem, it should be easy one to fix. Let me know we'll fix it. The main thing has been changed in development version is how mbfilter works. New filter is streamable and easier to extend, while current one is not. Current behavior will not be changed at all. You mean the thing on sourceforge here as development version ? Until we stablize and finish testing the code. We would like to mess things up a lot, that's why we're using sourceforge. We will merge changes to php.net CVS step by step. New filter will be merged after 4.3.0 branch is made. Then we'll sync source and start messing it again. (break build, functions, engine, etc) I guess most of us do not appreciate breaking build, functions and engine. In addition, there are few modules depends on mbstring already and mbstring does not depend on external lib at all. There is no reason to wait. AFAIK only exif does, and as that one is not enabled by default it should be no problem. It's easy to check in the config.m4 file of exif if mbstring is enabled too. mailparse is anothor one. My point is: Are we going to encourage users to write I18N modules/libs/applications or not. Single byte char users do not have to care about existence of mbstring if one is not interested. Why bother? Just let us know if there is bug so that bugs are getting fixed. BTW, Derick, could you add mbstring category to bug db? (AFAIK, there is no category for it) It's already there, under Languages/Translation. It's not intuitive to me :) Could you change the name like usual extension? - Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Default extensions (extensions in general)
Personally I don't care what is the default extensions are as long as I can change them. (I have written this email several times, but never sent it or I may have, but don't remember if so sorry if repeating). Here are my problems with extensions: A) Extensions that change the core code when built statically. I think this should not be possible! 4.3 takes care of this problem with mbstring and I don't know of any others, but that doesn't mean it can't happen again. B) Extensions that can only be built statically or while PHP is building. 4.3 version of sessions fixes this (I think), but you can't build session shared with out mm in version 4.2.x (via phpize) Any/All extension should have to pass a test of: 1) Can it be built and work statically into PHP 2) Can it be built shared while building PHP 3) Can it be built shared by phpize, configure, make method. Also can I do steps 1-3 with any of its options enabled or disabled If it includes extra sources (xml - expat, xmlrpc - libxmlrpc) 1) Can it be built statically into PHP with included library 2) Can it be built statically into PHP with a shared library 3) Can it be built with PHP shared with included library 4) Can it be built with PHP shared with a shared library 5) Can it be built shared by phpize, configure, make method with included library. 6) Can it be built shared by phpize, configure, make method a shared library. Also can I do steps 1-6 with any of its options enabled or disabled Also, just because they configure and build a .so files doesn't mean they work and have the right dependences. That should be tested as well. If all these things are meet then somebody can build a bare bones PHP and build extensions as needed. Currently not all extension can do this. It would be nice to make the above a requirement to get into the ext directory and recommended for things in pear/pecl. That's just my opinion, I could be wrong. Brian BTW, Thanks to Jani Taskinen for putting up with me while fixing a few extensions. At 10:19 PM +0100 9/2/02, James Cox wrote: Unfortunately we don't live in a perfect world where sysadmins know how to read and listen to their users requests. That's why mysql for example is enabled by default. (or that's the main reasoning behind it at least) And we can't educate people or force them to anything either. Maybe we should add a general '--disable-all' option? i'm +1 for that if it means that first it disables everything, and then you enable stuff bit by bit... i still don't see why we shouldn't just disable everything by default and write a 'default configure' script... -- james -- 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] Default extensions (was: mbstring)
On Mon, 2 Sep 2002, Jon Parise wrote: JP On Mon, Sep 02, 2002 at 03:52:50PM -0400, Dan Kalowsky wrote: JP JP If we should reduce number of modules built by default, 1st JP module should be MySQL. Removing MySQL does not cause any JP technical problems at all. JP JP I'll agree to that as well. +1 on removing --with-mysql as a default. JP Although realize I'm also +1 on removing any default modules that are not JP essential to PHP's running. JP JP After some thought, I think I agree with this (disable by default) JP approach, as well. For instance, if you want just PostgreSQL support, JP you not only have to --with-pgsql but also --disable-mysql[*]. Principally you may be correct - however doing this is more BC-breaking than the register global switch. Just imagine all the 'call to undefined function mysql_connect' bug reports. -- Melvyn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
-Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:53 PM To: Yasuo Ohgaki Cc: PHP Development Mailing list Subject: Re: [PHP-DEV] mbstring On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 on changing this with PHP 4.x - with PHP 5.x people realize that something big has changed. The register_golabls thing should have also been changed in PHP 5 and not in 4.x, but anyway it's too late for that now ;) Ah. I'm against changing this. But IF it's changed change it with 5. Is --disable-something is too hard to get used to? Yes it is. Why? Because PHP has so many options at this point, finding which modules are automatically enabled isn't terribly easy. More to the point, it's a PITA to find out during the build you forgot to explicitly disable a feature. Well... What about an _optional_ curses based, linux-kernel-like make menuconfig? +--+ | - Extensions | | [x] mySQL| | [x] GD | | .| | .| | .| | [ ] HyperWave | | .| | .| | [x] zlib | || | - Options | | [ ] enable transparent session id | +--+ | Here some description of the option or the | | Extension for examle | || +--+ Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ISAPI Crash Debugging Notes
Andi,
After spending some more time looking at the Zend2 code it appears that
it does still have the same issue that I'm seeing in Zend1 (first ISAPI
thread gets the global compiler_globals as it's own personal copy). I
can't get the same debug output as I was able to for Zend1, but I am
seeing similar error messages (mostly about classes being already
defined that aren't).
I've continued to dig around in the Zend1 code and still believe that
the first thread is using the globals as it's own copy. In one of the
earlier messages you said that this shouldn't be happening. In
zend_startup() the startup thread's copy of compiler_global is set to
be the GLOBAL_*_TABLES version:
compiler_globals = ts_resource(compiler_globals_id);
executor_globals = ts_resource(executor_globals_id);
tsrm_ls = ts_resource_ex(0, NULL);
compiler_globals_dtor(compiler_globals, tsrm_ls);
compiler_globals-function_table = GLOBAL_FUNCTION_TABLE;
compiler_globals-class_table = GLOBAL_CLASS_TABLE;
compiler_globals-auto_globals = GLOBAL_AUTO_GLOBALS_TABLE;
I can't find anything in the code that runs after this that would reset
this thread's compiler_globals to be it's own local copy again. Can
you explain where you think this should be happening so I can try to
track it in my setup? Maybe this is somehow ISAPI specific.
As a follow-up test I created a version of 4.2.3RC1 with a new external
function in zend.c:
void zend_startup_done()
{
#ifdef ZTS
zend_compiler_globals *compiler_globals;
zend_executor_globals *executor_globals;
TSRMLS_FETCH();
compiler_globals = ts_resource(compiler_globals_id);
compiler_globals_ctor(compiler_globals, tsrm_ls);
executor_globals = ts_resource(executor_globals_id);
executor_globals_ctor(executor_globals, tsrm_ls);
#endif
}
This function will create a new compiler_globals and executor_globals
for the current thread and reinitilize them with the constructors. I
then added a call to this function as the last step of the ISAPI's
DLL_PROCESS_ATTACH code. I've tested and it appears to fix the
problems I was having with using the ISAPI module just as my version
that spun off a new thread for the initialization did.
Michael
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Any chance you can setup and Engine 2 build and see if this problem
persists?
Andi
At 06:42 AM 8/27/2002 -0700, Michael Sisolak wrote:
--- Zeev Suraski [EMAIL PROTECTED] wrote:
At 09:53 27/08/2002, Michael Sisolak wrote:
i've been doing some debugging of the crashes when running
php
under
the isapi sapi. is anybody else currently looking at this?
if
you
are let's talk - here are my notes so far.
first off, can you try using
http://www.php.net/~zeev/php-4.2.3rc1.tar.gz
and see if you experience the same problems? i've made some
thread-safety related fixes there, even though none should
lead
to a hard crash...
zeev,
i believe that i may have tracked down a major isapi filter
thread-safety hole. if i understand what zend_startup() is
doing
correctly, it assumes that the thread that it runs under will
not
also
be used to serve http requests.
No, the startup thread can be used as a regular HTTP thread,
nothing
in the
code should prevent that.
The globals code in the startup sequence is very tricky, but it
should work.
This is a sample of the debug output that I'm seeing (this is PHP
4.2.1
running under Windows 2000 Professional, single CPU):
[1948] the startup thread is 1956
[1948] GLOBAL_FUNCTION_TABLE is 4226120
[1948] in HttpExtensionProc thread 1956, CG(function_table) is
4226120
[1948] in HttpExtensionProc thread 1520, CG(function_table) is
18834536
[1948] in HttpExtensionProc thread 920, CG(function_table) is
18838912
[1948] in HttpExtensionProc thread 1956, CG(function_table) is
4226120
[1948] in HttpExtensionProc thread 1256, CG(function_table) is
19250808
[1948] in HttpExtensionProc thread 920, CG(function_table) is
18838912
[1948] in HttpExtensionProc thread 1956, CG(function_table) is
4226120
Notice that the initial thread (1956) appears to continue to use
GLOBAL_FUNCTION_TABLE as it's own CG(function_table). I'm reporting
the GLOBAL_FUNCTION_TABLE value from within zend_startup() - is
there
some point later in the code that makes it okay that this is the
same
value that I get for a CG(function_table) later?
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: [EMAIL PROTECTED] wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: [EMAIL PROTECTED] wrote: No, not really. It was noted by more than one person that it breaks some simple things in PHP, affecting the bahavior of scripts that are already out there. Until it is totally stable (which you yourself it is not yet) it should not be enabled by default. How, after 4.3 is branched What problem? For example the bug with the request variables, which might be fixed in CVS now, but it isn't fixed in any release. It was working just like original treat data. The bug was introduced someone changed original treat data, but forgot to update multibyte version. This is the reason why I think there should be just one version of every piece of code, in this case using the mbstring stuff always would have made sense IMO. I think this is one of the reason why we should enable it by default so that everyone aware how it supposed to work. I might forget to merge the fix. I'll check it later. [snip] You mean the thing on sourceforge here as development version ? Until we stablize and finish testing the code. We would like to mess things up a lot, that's why we're using sourceforge. We will merge changes to php.net CVS step by step. New filter will be merged after 4.3.0 branch is made. Then we'll sync source and start messing it again. (break build, functions, engine, etc) I guess most of us do not appreciate breaking build, functions and engine. I don't like that indeed, but IMO it's ok in a development version for a restricted amount of time. [snip] BTW, Derick, could you add mbstring category to bug db? (AFAIK, there is no category for it) It's already there, under Languages/Translation. It's not intuitive to me :) Could you change the name like usual extension? I'll do that as soon as bugs.php.net is up again, which I fear that it will take some time *sigh* regards, Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Tue, Sep 03, 2002 at 06:06:29AM +0200, Sebastian Nohn wrote : Well... What about an _optional_ curses based, linux-kernel-like make menuconfig? +--+ | - Extensions | | [x] mySQL | | [x] GD | | . | | . | | . | | [ ] HyperWave | | . | | . | | [x] zlib | | | | - Options| | [ ] enable transparent session id | +--+ | Here some description of the option or the | | Extension for examle | | | +--+ That would be an uebercool thing. Nice overview, load and save different configurations, etc. Just don't forget the text boxes for the extra parameters (GD could need a path to the library). I just think this will remain in our dreams. -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Finally, if someone actually flying a plane is relying on a freakin' webcam to land, we're all in trouble. - A /. poster. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOM-XML memory leak?
On Tue, Sep 03, 2002 at 12:07:25AM +0200, Christian Stocker wrote : On Mon, 2 Sep 2002, Markus Fischer wrote: On Mon, Sep 02, 2002 at 04:42:38PM -0400, Al Baker wrote : I want to use the dom-xml extension in a production environment, is the dom-xml memory leak significant, ie will the whole machine run out of available memory or ? You mean this built in feature that domxml leaks a few bytes every hour? Err, really, what are you talking about? Do you have a bug report ID or something concrete you're talking about but missed to mentioned ? ;) Al talks presumably about the mentioning of a leak in the PHP Weekly Newsletter, which I reported last week on php-dev. Doh. This makes me looking a complete moron, doesn't it? Sorry Al, I missed Christians post. Aplogies, - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: mbstring
I think that the problem is caused by --enable-mbstr-enc-trans option and is not caused by mbstring itself. If --enable-mbstr-enc-trans is enabled, php_treat_data, the original handler of user input (POST/GET/Cookie), is overrided by mbstr_treat_data in ext/mbstring , the multibyte enabled version. mbstr_treat_data had a GET handling bug in PHP 4.2.x/PHP 4.1.x. Although the bug was already fixed in CVS, but mbstr_treat_data is not used by non multibyte user. So, I abolished --enable-mbstr-enc-trans option in CVS, and made a new php.ini option 'mbstring.encoding_translation', which is the equivalent of --enable-mbstr-enc-trans, and which is 'Off' by default. I think the user input (POST/GET/Cookie) related problem for non-multibyte user will completely disappeer with this change. And, the mbstring should be 'enabled' by default. I18N of PHP is very important for especially multibyte PHP users. The core part of mbstring is stable and is widely used. In Japan, PHP has already large user community. More than 20 PHP related books were published in japanese, and there are more than 5,000 subscibers in japanese php-user mailing-list. And PHP 4.3.0 will introduce Chinese, Korean (and Russian) support in mbstring. mbstring will more widely used by non singlebyte PHP users in near future. I agree with Zeev, the simplicity of development work is important. So, the duplicate code of the user input handler should be merged with the original handler in PHP 5.0. Rui On Sun, 1 Sep 2002 10:49:59 +0100 [EMAIL PROTECTED] (James Cox) wrote: Phil Copeland @ redhat pointed me at this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72752 Seems that there are a number of issues (i'm going to verify patch his fixes right now). The other he mentions is mbstring seems to cause problems. I have experienced this too. Guys, i don't want to be mean or sound racist or anything else you throw at me. But mbstring really isn't a core module, and very few people will require kr/zh/ru style encoding. I vote to remove mbstring as a default module. And for those who say that i could just disable it -- well, the converse is true. Let us STOP burdening default builds with crap that is unlikely to be used. -- james -- - Rui Hirokawa [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: mbstring
I think that the problem is caused by --enable-mbstr-enc-trans option and is not caused by mbstring itself. If --enable-mbstr-enc-trans is enabled, php_treat_data, the original handler of user input (POST/GET/Cookie), is overrided by mbstr_treat_data in ext/mbstring , the multibyte enabled version. mbstr_treat_data had a GET handling bug in PHP 4.2.x/PHP 4.1.x. Although the bug was already fixed in CVS, but mbstr_treat_data is not used by non multibyte user. So, I abolished --enable-mbstr-enc-trans option in CVS, and made a new php.ini option 'mbstring.encoding_translation', which is the equivalent of --enable-mbstr-enc-trans, and which is 'Off' by default. so this is now always on, but controlled by an ini variable? that doesn't sound very good. maybe i'm being paranoid, but it seems to me that you've just enabled it by default (at build time). I think the user input (POST/GET/Cookie) related problem for non-multibyte user will completely disappeer with this change. And, the mbstring should be 'enabled' by default. I18N of PHP is very important for especially multibyte PHP users. [snip] I agree with Zeev, the simplicity of development work is important. So, the duplicate code of the user input handler should be merged with the original handler in PHP 5.0. I agree -- it's very useful.. but i don't think it should exist as an extension, but built in.. the extension just now seems a really messy way of doing it. -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
