Re: [PHP-DEV] Language Auto Detection / www.php.net
On Wed, 2003-03-12 at 11:31, James Cox wrote: Gabor Hojtsy [EMAIL PROTECTED] wrote: is there any chance that we can revert this annoying feature? The translated documentation is always behind and partly lacks important information from the english version. I want to read the documentation in english (and I am not the only one). This is only possible if I change the url after all searches to /en/ The site should at least be so intelligent to search in the /en/ part of the manual if I search from an /en/ page. This is fixed now, and works again the way it was before the weekend (if you explicitly specify a language with being on a manual page in a language, or using the search page with a language parameter, that language is carried on). We do have language specification abilities in URL shortcuts, which is the short term solution, while I (or someone else) add the language cookie support. See http://php.net/urlhowto I remember adding a cookie before for something trivial (user-configurable css) and jimw pointing out that it tends to do silly things with caching... (ie, renders it useless) There's always Vary: Cookie, though I think the world is still lagging in implementing it. :-( A good way to fix the caching problem for language detection is to use non-caching headers on pages such as /manual/ and redirect to the language-specific page. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mono PHP
On Mon, 3 Feb 2003, Sebastian Bergmann wrote: Sterling Hughes wrote: I'll be adding it into PECL in a little bit Why PECL and not add it to ext/rpc? ext/rpc should be able to load rpc backend modules, or PECL is the only sensible place to put it (especially when it's experimental!). We really don't want to mix java, mono, xmlrpc, soap and whatnot into a single package. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reducing the number of system calls for includes
On Sat, 2003-01-25 at 00:17, Rasmus Lerdorf wrote:
Take this script:
? include '/home/rasmus/foo/u2.inc' ?
So, a simple include with an absolute pathname to avoid any include_path
searching and all safe_mode and open_basedir checking turned off. The
latter of course being an absolute killer. We still need a lot of system
calls to handle this include:
getcwd(/home/rasmus, 4096)= 13
lstat64(/home, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64(/home/rasmus, {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
lstat64(/home/rasmus/foo, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64(/home/rasmus/foo/u2.inc, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
open(/home/rasmus/foo/u2.inc, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4002c000
_llseek(3, 0, [0], SEEK_CUR)= 0
lseek(3, 0, SEEK_SET) = 0
The 4 lstat64() calls here are due to calling realpath() which causes
every dir leading up to the filename to be stat'ed to check if it is a
link so we can normalize the filename before adding it to the included
files list. It's handy and nice to normalize the path here, but it is
really really expensive! And this overhead doesn't go away with opcode
caches either as they still need to go through this step to determine if
the included file has been cached or not. I also don't see the point of
those three fstat64() calls that I guess are a result of the sanity
checking we do after the fopen.
Due to our current implementation, if you have a lot of includes, you
really should put all your include files in / and you will see some
impressive improvements. This is annoying, but I am not sure how to fix
it. A couple of things crossed my mind:
1. Don't normalize the path names, but instead do a single stat on the
file and record the device and inode of it and use that to match it
up later to check for multiple inclusion and the various opcode
caches would use that as a cache key.
2. Add a fast_include directive, or something equally lame-sounding,
which skips the getcwd(), realpath() and sanity checks and just
includes the file.
3. For absolute paths, don't call realpath() to normalize, just strip
out multiple /'s and any .'s or whatever we think is necessary to
try to normalize it short of having to stat every single dir leading
up to the file.
4. Do some sort of caching on this info so it doesn't happen on every
include on every request.
Zend Accellerator has a config setting for disabling getcwd(), I think
that would be a viable option for PHP too, rather than a separate
include statement.
Don't you have any FreeBSD kernel hackers in Y!? You could probably
convince/bully one of them to fix it, that's what we always do with ours
here ;-)
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php exception handling
On Thu, 2003-01-23 at 18:41, Alex Mendelev wrote: Hey, Are there any plans to implement proper exception handling in PHP? try / catch / finally throw throws Is anyone working on that? HEAD (in CVS) has try, catch and throw. No throws or finally. Throws has not been discussed (and IMHO makes little sense in a language that is not strictly typed), finally has been discussed before. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory allocation problems
On Thu, 2003-01-16 at 11:38, Edin Kadribasic wrote: I have a script that allocates a lot of memory (huge associative arrays). The problem is that this scripts bails out with fatal error (emalloc unable to allocate 44 bytes) when I hit the limit of physical ram in the machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of swap space. Has anyone seen something like this before? Are there any limitations in the PHP memory allocation code that would prevent it from being able to use more memory. Are you sure you are hitting the exact physical memory limit? What is your ulimit -d (data segment size limit)? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PEAR-DEV] 'php4' CVS module for PHP 5?
On Tue, 2003-01-14 at 07:48, Derick Rethans wrote: On Mon, 13 Jan 2003, James Cox wrote: Hello, What do you think about the idea of Martin that would use libphp.so and not libphp5.so ? it's called compatibility Nicos. having libphp4.so, libphp5.so, libphp6.so... and so on means that they can work together. Once libphp5.so gets building properly and we have moved onto that track completely, i intend to build a latest stable of php4 and leave it there: libphp4.so. make .php, .php4 etc use that hook, so my existing apps don't get broken, and migrate to .php5 There wouldn't be any need to have them both enabled, so why even go here? Wouldn't there? Personally, I'd like to have both on my development server. We did it with 3/4 so it is doable to 4/5. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 9 Dec 2002, Andi Gutmans wrote: At 05:34 PM 12/9/2002 +0100, Marcus Börger wrote: At 14:52 09.12.2002, Mike Robinson wrote: Wez Furlong writes: On Sun, 8 Dec 2002, Mike Robinson wrote: Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson What do you want then? For historical reasons you will allow us only to introduce total new functionality and bug fixes? No more improvements that will have any influence on some working systems out there? Then i'll answer stay where you are and do not do any version upgrade evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) Excellent idea, Andi. +1 on phpsh, -1 on renaming CGI. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-cgi vs php-cli naming issue
On Thu, 12 Dec 2002, Derick Rethans wrote: On Thu, 12 Dec 2002, Sterling Hughes wrote: How about we simply add a configure option to control this? --enable-simple-cli-name would build CGI as php-cgi and CLI as php That way we preserve BC and let those who like CLI named 'php' have that too. This will break the idea of having 'php' (the CLI) on as much systems as possible (for PEAR). It seems that integrating the two (CGI and CLI) _seems_ like the best solution, although I do not favor this due to technical reasons. For PEAR, it doesn't matter what the PHP binary name is, and since 1.0 will be co-released with PHP 4.3, PEAR will follow whatever PHP does. I agree with Zeev's stand on this. We (php-dev) are a bit too ego-centric if we think that it is reasonable to make lots of problems for existing CGI users just because we have some stubborn notion of what the CLI binary name should be. Ease up folks, and think about the users for a bit. IMHO some people are just a bit too eager breaking stuff around here. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php-cgi vs php-cli naming issue
On Sun, 15 Dec 2002, John Coggeshall wrote: I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? The CGI interface uses environment variables, so if some platform doesn't have them, CGI doesn't work on it. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reduce codebase
--enable-maintainer-mode? - Stig On Thu, 2002-12-05 at 17:16, Marcus Börger wrote: In a discussion about image.c code i was reminded that we do not need to bother with emalloc returning NULL or array_init returning FAILURE. Unforuately there are hundreds of such cases in PHP. When removing all these parts with all the necessary checks and error messages we could reduce the code base Indeed there is a simple way of doing so for array_init: change those functions to be of return type void. To make everybodys life easier i suggest we create a new configure option --enable-developer or such which simply creates a define that allows such changes. I would the like to have --enable-developer being a shortcut for --enable-debug also (zts would break some builds otherwise that also). When all developers would use this option i guess such changes could be done easily and they would not harm the normal users. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: bug of the day: $this
It won't be different in ZE2. This is not a bug though, but a tricky design issue. The problem is figuring out at runtime when to set $this or not in a method. What most people would probably find intuitive, is that $this was set only in methods called in the object, but this would require pretty expensive checks for every method call. Andi can shed more light on this if needed. - Stig On Wed, 2002-12-04 at 00:25, Markus Fischer wrote: I think issue is/will be adressed in ZendEngine2 but I could be wrong. I suggest inquiring at the engine2 list. On Tue, Dec 03, 2002 at 08:53:25PM +, Ivan Ristic wrote : Balazs Nagy wrote: Hi, $this stays defined when an instantatiated member function calls a non-instantiated member function. Correct. I actually find it quite interesting. :) It can be useful at times, I have used it in my libraries as a feature. There is an interesting article on the subject: http://www.advogato.org/article/470.html -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: bug of the day: $this
On Wed, 2002-12-04 at 01:32, Balazs Nagy wrote: On Tue, 2002-12-03 at 21:53, Ivan Ristic wrote: Balazs Nagy wrote: Hi, $this stays defined when an instantatiated member function calls a non-instantiated member function. Correct. I actually find it quite interesting. :) It can be useful at times, I have used it in my libraries as a feature. There is an interesting article on the subject: http://www.advogato.org/article/470.html Now, please tell me how can you decide whether the member function is called as an object element (eg. $obj-func()) or as a class element (eg. class::func()). Basic functionality is killed with this so-called feature. The right way should be a call stack, with for example a $_STACK array, or through stack functions (eg. this_object(), previous_object()). this_object()? LPC? :) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++
Isn't __cplusplus defined for all C++ compilers?
#ifdef __cplusplus
extern C {
#endif
#ifdef __cplusplus
}
#endif
This is pretty common in library header files at least.
- Stig
On Mon, 2002-12-02 at 16:18, J Smith wrote:
Taking a few comments into consideration, here's a new patch for adding C++
code-generating abilities to ext_skel. The new patch doesn't use a separate
skeleton.cpp file. Instead, it adds some lines like
/* __begin_extern_c__ */
/* __end_extern_c__ */
to skeleton.c and lets ext_skel either replace them with the proper C++
stuff or get rid of it altogether. I didn't want to make the extname.c
output any more complicated with #ifdef __cplusplus preprocessor nonsense,
'cause having extension first-timers asking why there's C++ stuff in their
C file would suck.
Another slight change to skeleton.c just gets rid of the string named
string and replaces it with str. This is just to get rid of any
conflict that might come up if someone #includes the C++ string library in
their extension, so they don't need to worry about C-string named string
being confused with the C++ data type string.
Comments?
J
__
--
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: Modules/Extensions not in 4.3
On Fri, 2002-11-29 at 18:20, Philip Olson wrote: On Fri, 29 Nov 2002, Wez Furlong wrote: IMO, the manual should include all of the maintstream PHP extensions. The reasoning is that if someone downloads the PHP manual, they expect to get the PHP manual and not have to hunt around for docs on extensions X, Y, Z. So mainstream is defined as which are bundled with the PHP4 source, whether it's in PECL or not? Does anyone know or have a list of what will go where and when? Is the install, configure, and use process different for PECL extensions? Why are any PECL extensions bundled in PHP4 source? That seems to defeat the purpose. Not quite. One purpose of separating the (cvs) source of PHP itself and extensions is to be able to pick the latest working version of extensions when releasing PHP, rather than waiting for extension maintainers to fix bugs during the PHP release process. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Thu, 2002-11-28 at 19:08, Marcus Börger wrote: At 18:59 28.11.2002, Ilia A. wrote: On November 28, 2002 12:56 pm, Maxim Maletsky wrote: Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. Do you have an effecient manner in which to implement the introduction of error codes? Ilia That's not the problem (see patch below). The problem is changing the whole source to use error-codes and having a scheme for the codes. There is no shortcut we can take here. Error codes need to be applied by humans based on their perception of what goes wrong. A team of volunteers putting in a day or two, and some tools to help them, should be enough. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Wed, 27 Nov 2002, Sascha Schumann wrote: On Wed, 27 Nov 2002, Stig S. Bakken wrote: On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
On Wed, 27 Nov 2002, Derick Rethans wrote: On Wed, 27 Nov 2002, Sara Pollita Golemon wrote: User complains that maximum length of a line used by fscanf is too short (he has lines 1600 chars). Looking at file.h I agree (it's only 512). The user requested two options: 1) Add an optional length field. No way to do that without breaking parameter list. :( We can't really do that, users will get pissed :) 2) Increase to a larger arbitrary number. This simply has the problem that it may prove too short eventually as well. Yeah, IMO it doesn't solve anything. Plus I came up with a third option: 3) Create an .ini entry to specify the maximum length used. I think this has the best overall return on it. I don't like us adding a new ini entry for this, I think we should try another option: 4) Make sure we can use fscanf on a dynamically sized buffer. This will definitely the hardest solution, but also the most beautiful one. [4] is definitely the best option. formatted_print.c already does something similar. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Sat, 30 Nov 2002, Sascha Schumann wrote: -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? In order to succeed over a long period of time, error tokens need to be versatile enough to satisfy this set of requirements. - the conflict potential should be low (can conflicts between independently released modules be avoided and if yes, how) - they should be easily recognizable by humans and automatons (so that e.g. bugs.php.net can easily insert the English error message for any given error code) - management overhead should be as low as possible (do we need a central registry and to what extent) Could you explain how you think that errno-style codes achieve these tasks? Sascha, I asked if you had any suggestions because I really wanted to hear if you had any suggestions, not because I wanted to dive into a verbal trench war. It doesn't have to be errno-style error codes, as long as the solution has the right balance between completeness and simplicity to make sure that all extension and PEAR package maintainers start using them. But assuming that our goals are fairly similar after all, I take the liberty of re-phrasing your mail as two suggestions: 1. make a naming scheme for error codes/symbols that is scalable, easily machine readable but also human readable 2. partition the error symbol space with a resolution to optimize management overhead Are we on wavelength yet? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Thu, 2002-11-21 at 23:42, Jani Taskinen wrote: What is so hard to understand in word 'FATAL'? If your script doesn't work, what use is it to make it show the cryptic 500 error?? I'm -10 for adding anything like this, even if and even more then if it's optional. Just forget this. How much Kossu does it take to have a -10 voting power? ;-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 02:03, Maxim Maletsky wrote: On Mon, 25 Nov 2002 22:18:32 +0100 (CET) Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 25 Nov 2002, Sascha Schumann wrote: Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. Thank god not; would you like to see your bugreports in french, or hebrew or finnish? If the error message is in a foreign language, people are going to report bugs in that language too, and I dont think QA is waiting for that. Even with an error number attached is going to be annoying; I myself would not even bother. If PHP is supposed to become easier to use, then native language error messages would be a big hit. Who says that PHP needs to be even easier then it already is? I think with the millions of users there are we're doing pretty okay I'd say. This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. If we go for errno-style error codes, they will be context-sensitive, that is they have a meaning only when you know what call caused the code. ODBC-style error messages are less context-sensitive, but again more complex. It is unrealistic to think that good, localized, error messages can be done through just a code abstraction. That being said, I don't buy into the localized error message argumentation. I realize that PHP is being, or has the potential of being, used by people with poor English skills, but the language itself, along with its close to 2000 bundled functions, is in English. Would Italian error messages really make PHP more accessible for Italians when the functionfor getting stream context options is called stream_context_get_options()? PHP-generated error messages are for developers after all. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes (for PHP 5) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On Tue, 2002-11-26 at 04:21, Shane Caraveo wrote: I am completely +1 to the concept of taking error codes out of the PHP core and replacing them with an XML document, period. I had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Amen to that. XML is not an altar where we go to sacrifice our CPU cycles every full moon. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
On Tue, 2002-11-26 at 05:04, John Coggeshall wrote: I had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Well, I'm not really concerned with the method be it XML, whatever... It's the concept that holds the real value IMHO. IMO the concept has no real value for PHP. Today, PHP's error messages are totally useless for machine consumption (I don't consider using regexps to figure out whether fopen failed due to a read-only filesystem or full disk as well-suited for machine consumption). This is the first problem we should focus on, and even introducing simple error codes is going to increase the maintenance. Separating error messages into XML files or whatnot adds three times as much maintenance, for what benefit? When it comes to error message translations, we should either do it right and all the way, or not at all. I simply don't think we are up to doing it right. Documentation translations are constantly lagging behind, and I have no reason to believe that error message translations will lag behind any less. If someone wants help on php-general and their error message is in Urdu, then too bad. Companies like IBM and Oracle has solved this problem by introducing more complex error codes (such as 0123-456 File not found), which is an absolute must if one does go in this direction, or the poor Urdu-speaking guy won't be able to find people who can help him. But the task of maintaining such a registry, and avoiding that it degenerates into a chaotic mess, requires an amount of collective self-discipline that I simply don't think a big project like PHP can muster. Let's try being realistic, and focus on the quick wins first, such as good error codes. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 02:15, Maxim Maletsky wrote: On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) So what, PHP and Oracle are different worlds: PHP humbly relies on volunteers spending their precious spare time. Oracle hire and fire people. I'm not saying that localized error messages are bad, I just don't think it's right for PHP to have them, at least not now, and at least not with the maintenance/support overhead it gives us. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 12:11, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. That sounds selfish of us, Derick. How on earth can you say that? Derick has received an _throphy_ for spending his spare time on the painful process of managing PHP releases, he knows what he is talking about, and it is not a selfish opinion. Maintenance overhead hurts PHP. And our maint.overhead curve is going up. We should strive to _reduce_ that overhead, not increase it. That way php-dev will be more productive and give even the our users what they really need: a (continously) solid product. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 13:31, Sascha Schumann wrote: I think starting with a concrete proposal before it's not clear if we even want this localized errors thing seems rather time-wasting. What you call bickering, I call discussing, and IMO we're not yet done discussing if we want this at all. Well, there won't be a consensus regarding i18n facilities any time soon on php-dev. I can post some hilarious quotes from your funny IRC channel to demonstrate that point. Hence, the only way to move this forward is to actually code something up and enable extension authors to provide i18n error messages. The first step consists of adding the necessary look-up code to PHP itself; the second step is building the infrastructure for maintaining and generating message catalogues; the third step consists of assigning error codes to extensions; and as the final step, translators can actually commence to build the message catalogues. What is the point of doing all this work if php-dev rejects it? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ZE2 and abstract
On Tue, 19 Nov 2002, Marcus Börger wrote:
The link below contain a patch that allows abstract functions in ZE2.
http://marcus-boerger.de/php/ext/ze2
abstract [static] function '(' parameters ')' ';'
it would be possible to make the ';' optional.
When an abstract method is called a fatal error is generated and
execution stops. Another way of handling abstract would be to
generate an E_WARNING or throw an exception. I experimented
with the second one already but do not like it. I favor the first
over the third but haven't tried that yet.
The thinks i did:
introduce T_ABSTRACT = abstract and modified the parser.
added is_abstract after is_static in zend_function (and such)
emit an E_ERROR when is_abstract is set in
zend_init_static_method_call_handler zend_init_method_call_handler
marcus
I like abstract, it provides a good alternative to interfaces. If we
make it interact right with aggregate and overloaded objects, we're
starting to have a very powerful OO platform, even for the Java buffs. :)
We need to figure out what happens with abstract methods if the object
aggregates a class that defines this method, and if/how __call should be
invoked if you try calling an abstract method (instead of just bailing out
with E_ERROR).
Andi and I agreed on how we wanted aggregate to work in Frankfurt, I'll
write another followup tomorrow describing our conclusions on that and
more in detail the problems we must solve related to abstract (too busy
tonight).
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Wed, 20 Nov 2002, Ivan Ristic wrote: Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is And how about that we change PHP so that it changes the status of the response to 500 on a fatal error? Then you would be able to use the Apache directive ErrorDocument 500 /handle-my-errors.php to deal with them. You would have to use output buffering, of course, but using output buffering is the only way to shield your users from errors anyway. +1 !! Why didn't anyone think of this before? :) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pear::db and odbc issue
On Wed, 20 Nov 2002, Chandler, Jacob R wrote: We are querying two different odbc databases using the Pear::DB library. When we try to print out the number of Rows ($result-numRows()), the output is 'Object'. We tried the same thing using odbc and we are getting '-1' as the number of rows. This appears to be an error because there are results in the database and if we attempt to get data, we can do this in a while loop with the fetchRow function and we get valid data. Can anyone give any suggestions? Try var_dump()ing the object you get from numRows(), it could be a PEAR error object. In general numRows is not something you can rely on, at least not if you want your code to be portable to other databases. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Wed, 20 Nov 2002, John Coggeshall wrote: |And how about that we change PHP so that it changes |the status of the response to 500 on a fatal error? Then |you would be able to use the Apache directive | |ErrorDocument 500 /handle-my-errors.php | |to deal with them. You would have to use output buffering, |of course, but using output buffering is the only way to |shield your users from errors anyway. | |+1 !! | |Why didn't anyone think of this before? :) A couple of problems with that: 1) No way for handle-my-errors.php to know the details of the error such as errorcode, file, etc) 2) Relies on the web server (not PHP) to re-direct the user to another script If we are willing to do this, think we're better off creating a directive error_url which requires output buffering enabled and re-directs the user to another URL with GET parameters containing the error messages. If ErrorDocument is implemented as a sub-request in Apache, it would be enough for PHP to set one or more Apache notes with the necessary information. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] Errors and exceptions?
On Tue, 2002-11-12 at 07:54, Derick Rethans wrote:
On 12 Nov 2002, Timm Friebe wrote:
On Mon, 2002-11-11 at 23:26, Stig S. Bakken wrote:
[...]
The problem here is that PHP's E_WARNING does not resemble an exception.
Some of the warnings raised are only of informational intent and do not
indicate the failure of a function.
[...]
Right. What this illustrates is that PHP errors as such as way too
random and unstructured to be of any other use than showing error
messages to developers.
Well, would it be wise then to either:
* Change informational warnings to E_NOTICE
(e.g. Notice: Called ... before fetching all rows ...)
or
* Introduce E_FAIL and use it for cases when a function fails
(say, fopen('/doesnotexist', 'r'))
In both cases, people doing string magic with $php_errormsg (if
ereg(not exist, $php_errormsg)) or having their own error handlers
consisting of constructs like
if (E_WARNING == $code)
would see their code break.
As for the first suggestion, the downside is that a lot of people will
miss the message(s) since they've disabled E_NOTICEs.
And that's why I would be -1 on the first one. However, the whole error
reporting is a pretty mess, with some extensions implementing other
'philosiphies' then others. Getting this all nice and clean is another
point we should address in PHP 5 (just like Stig mentioned).
I did not mention that here, but I would like to go through the PHP source and
introduce Unix-style (EPERM etc.) error codes in all calls to php_error(). But
that's not a topic for this mailing list.
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ereg to pcre conversion
On Fri, 2002-11-01 at 18:28, Jani Taskinen wrote: On Fri, 1 Nov 2002, Sander Roobol wrote: On Thu, Oct 31, 2002 at 02:47:27PM -0500, Ilia A. wrote: I would like to propose that we drop the old ereg library and use only a single regular expression library, PCRE. For BC purposes I've written a patch (see attached file), which emulates the old ereg_* functions for people who still rely on those, using PCRE. We probably have to make a bunch of tests to see if we don't break BC with this patch. If we don't break BC, and only then, I would give +1 on this patch. Too many people rely on the ereg_* functions, so IMO we really can't afford changing any behaviour. IMO if some behaviour of ereg_* is simply wrong, and this change fixes it, it's acceptable 'breaking of BC'. :) Such as? - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/iconv config.m4
On Fri, 2002-11-01 at 01:47, Yasuo Ohgaki wrote: Moriyoshi Koizumi wrote: moriyoshi Thu Oct 31 15:23:53 2002 EDT Modified files: /php4/ext/iconv config.m4 Log: Fixed library capability detection behaviour. # Whew! I've fixed all the known problems. # And should I become a maintainer of this module? Sounds good to me, but Ask Rui and Stig. It's not even listed in EXTENSIONS. Feel free :-) - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
On Wed, 2002-10-09 at 09:35, Yasuo Ohgaki wrote: Colin Viebrock wrote: I really think the best solution (not perfect, but best) is to specify some fonts so the pages look nice, and hard code in the ISO-8859-1 font hard code in the ISO-8859-1 font means assuming ISO 8859-1 and use ISO 8859-1 type face by converting chars to entities? Take a look at this page, for example. http://czyborra.com/charsets/iso8859.html Do you see converting text to entity assuming ISO 8859-1 breaks not only multibyte encoding but also other ISO 8859 encoding? I'm well aware of that I'm suggesting to make phpinfo() non XHTML, since it is more useful if it is not confirm XHTML perfectly. If use of HTML entities are preferred, only text that needs HTML entities should use entities. e.g. Names. Isn't using entities for names or like enough? Please no automatic entity conversion assuming ISO 8859-1. Thanks. A bit late, but I'd like to throw in my .02EUR. When dealing with multiple languages, the only reasonable charset to support internally is Unicode, encoded in utf-8. Now, while MSIE supports utf-8, it doesn't sent the Accept-Encoding header. NS4 is AFAIK the only browser that explicitly announces being able to handle utf-8 in the request, but it's not a big issue to figure out if the user agent is from a browser that can deal with utf-8. The real solution would be using iconv on the output buffer to change the utf-8 to whatever charset the browser prefers, or if iconv is not available, try converting to 8859-1 and replace characters that don't fit to ?. IMHO this is the only thing that will work for everyone. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Plan for PHP 5.0
On Sat, 2002-10-05 at 22:21, Sebastian Bergmann wrote: Andrei Zmievski wrote: I have made PHP_4_3 branch just now. Will HEAD become 4.4.0-dev, or 5.0.0-dev? Considering the long release cycle to be expected I prefer the latter. I think it's time to head for 5.0 after 4.3, but not without a plan. Below is an outline of what I think is necessary to make PHP 5 happen, without going into each extension/SAPI layer. I have not included extension-specific changes, but try to keep focus on the core, and how to improve PHP 5 development and release processes. PHP has doubled in size since 4.0.0. The release process is taking so long now that it's painful, if it goes much further, people will start burning out trying. This is not a situation we can live with, so this plan addresses both people and code issues that I think are necessary for PHP 5.0 to ever see daylight. Before I start, I want to mention that keeping the scope of 5.0 realistic is crucial. If we didn't think of a feature already, 5.0 shouldn't have it. This is not the time to dream up a feature only because we're doing a new major version. There's been plenty of opportunity for that. Step #1: Do 4.3.x releases from the 4.3 branch We must expect to maintain PHP 4 quite a while longer, and should figure out what the best approach is. I think that just keeping PHP 4 on the 4.3 branch will work, but it depends on how many changes there are in extensions. Moving very active extensions to PECL and using the step #5 approach in subsequent 4.x releases would work. Step #2: Turn HEAD into 5.0.0-dev Zend is replaced by ZE2, all the ZE2-specific branches are merged in. Directory layout should stay the same, to make merging patches between 4.3 and 5.0 easier. The naming will be weird, but it's more manageable this way until the 4.3 commit volume is very low. Step #3: Pickle all extensions! Move all extensions except ext/standard w/dependencies to PECL. Yes, everything. We can add CVS aliases to be able to check out like today easily, but this is the first step towards parallelizing the release process. When extensions are pickled, they are given version numbers (0.5 for experimental, 1.0 for the rest unless something suggests otherwise). Step #4: Getting pickles I will add a pear import-src utility to add pickled extensions to your PHP build, so they can be included in static builds. It'll work something like this: $ pear import-src mysql pgsql session xml Downloading mysql-1.0.tgz ... 174,080 bytes Downloading pgsql-1.1.tgz ... 40,960 bytes Downloading session-2.0.tgz ... 30,720 bytes Downloading xml-1.5.1.tgz ... 71,680 bytes Running buildconf... Successfully added these extensions to your build tree: blah blah $ ./configure There should be a command for doing the same from CVS too. Step #5: Release Process changes When doing PHP 5 releases, we import the sources of bundled extensions this way in the makedist script. This will leave only the PHP core in the php[45] CVS module, which I think is a great starting point for more manageable release cycles than we have now. Step #6: Fix API versioning! As soon as extensions are made available in binary packages, our versioning problems will show their true ugly rear. We should fold the current three API versions into one, and switch to a versioning mechanism that allows using older libraries. If we don't do this, people will have to re-install every separately-installed (through PEAR or otherwise) extension on every upgrade of PHP where the API version changes. If the API change was trivial and did not affect any of our modules, having to rebuild everything is meaningless, and just a waste of peoples' time. This is a problem today, if not on the same scale. This issue still needs a lot of thinking, this is just my reasoning. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Plan for PHP 5.0
On Mon, 2002-10-14 at 02:18, Dan Kalowsky wrote: On 14 Oct 2002, Stig S. Bakken wrote: Step #3: Pickle all extensions! Move all extensions except ext/standard w/dependencies to PECL. Yes, everything. We can add CVS aliases to be able to check out like today easily, but this is the first step towards parallelizing the release process. When extensions are pickled, they are given version numbers (0.5 for experimental, 1.0 for the rest unless something suggests otherwise). While I don't have the full time to answer everything, this gets both a +1 and a -1 from me. Great idea, but PECL doesn't work everywhere, for example I believe OSX does not yet support it (that being my main platform of concern). If someone gives me an account on an OSX box (or even better, puts an OSX box into my mailbox! ;-) I will make it work. More importantly there is no secure method of distribution for PECL, especially with binaries (Windows). There has been a lot of talk in the #php.bugs channel about this, and there were even a few emails with regards to this very issue on php-dev. A solution has been arrived at, but it has not been implmented yet due to various reasons (mostly time). Before anything at all can/should be pickled, a secure distribution method needs to be in place. See below. For more information on this see an email from Marko Karripinen from July 26th 2002 detailing the original idea/method for doing this. It has been since toned down a bit, but follows the same idea. You're missing the point :-) PHP distributions can still be built like today, including all 95 extensions for all I care (ok that's a lie), the point is to separate the development of the PHP core and each extension _first_. Right now, this is to fix our own internal project management problems. The 5.0 release will probably be around the same size as 4.2.3, with a couple of extensions removed, but other than that more or less the same. End users won't notice, except that we may choose to offer an additional stripped-down distribution without more than ext/standard and the extensions it depends on. When we have a cross-platform signature mechanism that works, we can start changing what's included in a distribution. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Congratulations.
On Thu, 1 Aug 2002, Daniel Lorch wrote: hi, Congratulations Derick. Most deserving recognition for a terrific job. I will add to that my humble thanks. No offense, but I think other developers should be mentioned as well. I very much like wez' work on innovative ideas - even though his results might not be suitable for the masses (such as having PHP client-sided embedded into redmond's browser etc.). But generally, I think honoring hard working developers is a good idea, as they only seldomly get positive feedback on their work (what they certainly deserve). Come on, it's an award, they pick individuals. I think Derick and Jani deserved that award with good margin, because the type of work they do often has limited reward compared to the amount of energy they put into it. There'll be a chance for everyone ;-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New build system (Re: [PHP-DEV] 4.3 release call to arms)
On Thu, 25 Jul 2002, Stig S. Bakken wrote: 1. New build system (Sascha) [done?] I'm forking this thread into one for each action item. The new build system seems to work, my main concern is source compatibility with 3rd-party extensions written for 4.2 or earlier. It seems to work, what we basically should do during RC is download a bunch of extensions and see how it works. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CLI SAPI (was Re: [PHP-DEV] 4.3 release call to arms)
On Thu, 25 Jul 2002, Stig S. Bakken wrote: 3. Command-line SAPI installed by default (Edin) * php.ini issues I think the only remaining issue here is to be able to have a separate config/ini file for cli. While we're at it we might as well support SAPI-specific config files, so PHP first looks for php-$SAPI.ini, then php.ini. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 release call to arms
Okay, I'm modifying brancing on sunday to branching when 4.2.3 is out, so we don't have two QA processes at the same time. Sorry Derick. - Stig On Thu, 25 Jul 2002, Stig S. Bakken wrote: Hi guys, I'd like to start the 4.3 release process now. Anyone with stuff they want to commit before the branch is created, please either commit it or let me know by sunday. I want to create the branch on sunday night GMT+2. Here is, again, the 4.3 TODO list. Most of these require only tweaking and lots of testing. 1. New build system (Sascha) [done?] 2. PHP Streams (Wez) 3. Command-line SAPI installed by default (Edin) * php.ini issues 4. PEAR integration including PECL builder (Stig) 5. MySQL changes (Zak) [in progress] 6. GD bundling (Rasmus) [done?] 7. DOMXML changes (Christian) 8. MacOS X support (Marko) 9. Sockets extension (Jason Greene) 10. Verify new LICENSE (Stig) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extensions problems
A quick way to diagnose if this is your problem is: nm module.so | grep get_module If the grep doesn't give any output, this is your problem. - Stig On Wed, 2002-07-03 at 16:36, Rafa Rodriguez Hernandez wrote: Hi everybody. I'm having a problem with php extensions. I have a module that I want to load dynamicly with php. In the php.ini file I have the next line extension=module.so The module compiles fine.. but when php try to load it, I get this response: PHP Warning: Invalid library (maybe not a PHP library) 'module.so' in Unknown on line 0 I have in the source code this: #if COMPILE_DL_module ZEND_GET_MODULE(module) #endif So the problem is no from it .. May I compile php with any special feature? .. in the php_info it tells me that I have Dynamic Library suppport enable.. This happens with any module I try to load with php. Sorry for my english .. I'm not well speaking it :P Thanks a lot! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] feature request
Is there a portable way to implement this on all/most OS'es? Please submit this feature request on bugs.php.net. - Stig On Wed, 2002-07-03 at 23:06, veins wrote: hi, I have a feature request for the exec() family. I was thinking of adding a fourth optionnal argument to be passed as the argv[0] so that the name that appears in a 'ps' can be changed. The reason is simple, as many people do, I usually have php call a shell script or a perl script on the system for some tasks, this is done after an authentication and having the command line passed to the shell is even worse than having no authentication at all. Is there a particular reason why it was not implemented ? -- veins a bofh said: I too can bore you with useless encrypted keys... ? ssa ruoy pu ti evohs dna yek pgp ruoy ekat uoy t'nod yhw -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recommended XML parser?
On Tue, 2002-06-18 at 02:18, Blake Barnett wrote: What is the recommended XML parser for use with PHP 4.2.1? (and also 4.1.0 if anyone is willing to answer that as well?) From reading the list archives I'm seeing a lot of people bash expat and lean toward libxml2, I just wanted to get the consensus before I commit a project to using one or the other. Depends a bit on what you want to do with it. If you are processing huge amounts of xml data, you can get away with much lower memory consuption with expat. But if you must have a tree representation of your XML, using the domxml extension is probably better. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small CGI Serve
On Tue, 2002-06-18 at 13:25, BB wrote: I am trying to write a small CGI webserver. Having finally found out how to pass the Environment vars onto PHP, I am stumpted to find that PHP wasn't reading them and putting them in their place (GET vars). I tried changing the exe from the php-cli to just php. This now brings up a security error and I cannot find a solution The CLI version of PHP is not designed to be run from a web server like this. If anything, you can write CGI scripts with it, where you have to import the environment variables yourself (sounds silly doesn't it? :). The security error you're getting is probably related to force-redirect, could you provide the error message? - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any chance of php_pear.dll?
On Mon, 2002-06-03 at 21:35, Michael Dransfield wrote: Is there any chance of including php_pear into the latest snap at snaps.php.net ?? I know it is very beta... but id at least like to experiment on my windows machine I notice you have included dotnet stuff, but not your own Pleea ;) php_pear.dll is outdated and unsupported. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch-tastic!
On Wed, 2002-06-05 at 10:44, Ilker Cetinkaya wrote: Sebastian Bergmann [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Andrei Zmievski wrote: The latest one changes some operators. Nice, but why not overload + for strings to do the concatenation? i totally agree, overloading + for string concat is really desireable. imho using - for member object access is ok. i see php more likely to be a c++ derivate than java or c#. just my .02c I guess you should have been here when PHP 3 came out and + suddenly no longer did string concatenation. There has been consensus on not overloading operators since then. Don't expect this to change. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Registering classes in PHP extension
On Fri, 2002-06-07 at 14:21, Eunsoo Seo wrote: Hi. Any manual about registering classes in PHP extension? I found that the function zend_register_internal_class can do that. And I read some code in ext/ that contaings that function, but I can hardly understand that code. Any manual or tutorial about that topic? There is some example code in pear/PEAR/pear.c. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL != Siberia
Okay, one problem seems to be solved: go-pear supports Windows now. Download http://pear.php.net/go-pear and do php -q go-pear. Next issue is prebuilt extensions. I really want to have package signatures (with pgp/gpg) before going there, but again I'm not sure what the most feasible approach would be on Windows. Anyway, here's what I have in mind: Today packages have a layout like this: package.xml pkg-version/file1 pkg-version/file2 pkg-version/file3 ... During pear package, the package.xml file is re-created including md5 checksums of all the files. By just adding a package.sig file during packaging that contains package.xml's signature, the entire package is in practice signed. By default, the pear installer should only install prebuilt extensions signed by a trusted key (we have to bootstrap this trust network somehow too). As an option, you may add trusted keys or disable the signing requirement for prebuild extensions and pre/post install/uninstall scripts. Some advice on how to verify pgp signatures on Windows would be appreciated though. :-) - Stig On Mon, 2002-06-10 at 22:05, Shane Caraveo wrote: It's a tough one :) Well, being able to build like on unix shouldn't be too hard to do, just have to call nmake on the dsp, but that wont work for the vast majority of users. Someone needs to provide prebuilt extensions that can be downloaded via pear, and unfortunately, I don't see any way other than having a build per version of PHP. So the built extensions would have to have a filename like: extname-phpversion-extversion.zip. Another idea would be to have the extensions built for windows on the server side, and cached if one was already built. Shane Stig S. Bakken wrote: You tell me :) We currently have no nice way of bootstrapping PEAR on Windows like we have on Unix (with make install-pear-installer and go-pear). What would be the most sensible way of giving Windows users something ala go-pear? - Stig On Sun, 2002-06-09 at 18:49, Shane Caraveo wrote: Hmm, what is happening for win32? Stig S. Bakken wrote: With the latest PEAR installer (version 0.90), PECL extensions are now built and installed during pear install/upgrade on Unix systems. First: upgrade PEAR to 0.9 with pear upgrade PEAR. If you have the xmms libraries and php_gtk installed, you can see it in action by doing simply pear install xmms. The output is like this: -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend 2 const class members private?
On Mon, 2002-06-10 at 22:37, Leendert Brouwer wrote: I have just started experimenting with the Zend 2 engine, and totally love the new OO features. I'm not sure whether this has been discussed or not (I couldn't find it in the archives, anyway), but I ran into a few things: Constant class members seem to be private by default. I cannot access them by doing $instance-CONSTNAME Is this expected behaviour? I'd expect constants to be public by default, just like regular variables, unless specified otherwise (when I try doing: private const FOO = bar; I get a parse error). Same for private static. Is this all going to change? It seems a bit illogical now. Thanks Constants belong to the class, not the instance. Try Class::CONSTNAME instead. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] html tokenizer to add to tokenizer?
Good idea. I assume you want this for WidgetHTML.php? ;-)
- Stig
On Wed, 2002-06-12 at 14:26, Alan Knowles wrote:
Attached hopefully is the re2c source for a html tokenizer - I added it
to tokenizer.c - any thoughts on inclusion?
regards
alan
enum {
STATE_PLAIN = 0,
STATE_TAG,
STATE_NEXT_ARG,
STATE_ARG,
STATE_BEFORE_VAL,
STATE_VAL
};
/*!re2c
any = [\000-\377];
N = (any\[]);
alpha = [a-zA-Z];
alphanumeric = [a-zA-Z0-9];
*/
#define YYFILL(n) goto stop
#define YYCTYPE unsigned char
#define YYCURSOR xp
#define YYLIMIT end
#define YYMARKER q
#define STATE state
PHP_FUNCTION(token_html)
{
char *source = NULL;
int argc = ZEND_NUM_ARGS();
int source_len;
int state;
char *end, *q;
char *xp;
char *start;
zval *tag, *attribute;
if (zend_parse_parameters(argc TSRMLS_CC, s, source, source_len) ==
FAILURE)
return;
YYCURSOR = source;
YYLIMIT = source + source_len;
STATE = STATE_PLAIN;
array_init(return_value);
switch (STATE) {
case STATE_PLAIN: goto state_plain;
case STATE_TAG: goto state_tag;
case STATE_NEXT_ARG:goto state_next_arg;
case STATE_ARG: goto state_arg;
case STATE_BEFORE_VAL: goto state_before_val;
case STATE_VAL: goto state_val;
}
/*
I need to split the stuff into:
array ( TAG, array(name=value,name=value))
or
string
add_next_index_zval(return_value, tag);handle_tag(STD_ARGS);
*/
state_plain_begin:
STATE = STATE_PLAIN;
state_plain:
start = YYCURSOR;
/*!re2c
{ STATE = STATE_TAG; goto state_tag; }
N+ { add_next_index_stringl(return_value, start , xp -
start , 1); goto state_plain; }
*/
state_tag:
start = YYCURSOR;
// start - xp contains currunt pos,
// needs to deal with comments !-- and ?xml or php etc.
/*!re2c
[/!]? alphanumeric+ { MAKE_STD_ZVAL(tag); array_init(tag);
add_next_index_stringl(tag, start, xp - start, 1); goto state_next_arg_begin; }
! - - { MAKE_STD_ZVAL(tag); array_init(tag);
add_next_index_stringl(tag, start, xp - start, 1); goto state_comment_begin; }
any{ add_next_index_stringl(return_value, ,1 , 1); --YYCURSOR;
goto state_plain_begin; }
*/
state_comment_begin:
start = YYCURSOR;
state_comment_next:
/*!re2c
- -{ add_next_index_stringl(tag, start, xp - start -3, 1);
add_next_index_zval(return_value, tag); goto state_plain_begin; }
any { goto state_comment_next; }
*/
state_next_arg_begin:
STATE = STATE_NEXT_ARG;
// at first bit after or just after a name or name=''
state_next_arg:
start = YYCURSOR;
/*!re2c
{ add_next_index_zval(return_value, tag); goto state_plain_begin; }
[ \v\t\n]+ { goto state_next_arg; }
alpha { --YYCURSOR; STATE = STATE_ARG; goto state_arg; }
/ { MAKE_STD_ZVAL(attribute); array_init(attribute);
add_next_index_stringl(attribute, start, xp - start, 1);add_next_index_zval(tag,
attribute); goto state_next_arg; }
[] (any\[])* [] { MAKE_STD_ZVAL(attribute); array_init(attribute);
add_next_index_stringl(attribute, start + 1, xp - start -2, 1);
add_next_index_stringl(attribute, \, 1, 1); add_next_index_zval(tag, attribute);
goto state_next_arg_begin; }
['] (any\['])* ['] { MAKE_STD_ZVAL(attribute); array_init(attribute);
add_next_index_stringl(attribute, start + 1, xp - start -2, 1);
add_next_index_stringl(attribute, ', 1, 1); add_next_index_zval(tag, attribute);
goto state_next_arg_begin; }
any { add_next_index_zval(return_value, tag); goto state_plain_begin; }
*/
state_arg:
start = YYCURSOR;
/*!re2c
alpha+ { MAKE_STD_ZVAL(attribute); array_init(attribute);
add_next_index_stringl(attribute, start, xp - start, 1); STATE = STATE_BEFORE_VAL;
goto state_before_val; }
any { --YYCURSOR; STATE = STATE_ARG; goto state_next_arg; }
*/
state_before_val:
start = YYCURSOR;
/*!re2c
[ ]* = [ ]* { STATE = STATE_VAL; goto state_val; }
any { add_next_index_zval(tag, attribute); --YYCURSOR; goto
state_next_arg_begin; }
*/
state_val:
start = YYCURSOR;
/*!re2c
[] (any\[])* [] { add_next_index_stringl(attribute, start + 1, xp - start -2,
1); add_next_index_stringl(attribute, \, 1, 1); add_next_index_zval(tag,
attribute); goto state_next_arg_begin; }
['] (any\['])* ['] { add_next_index_stringl(attribute, start + 1, xp - start -2,
1); add_next_index_stringl(attribute,
[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]
Why? Does the parser risk ending up in an invalid state if the PHP code
has errors?
- Stig
On Mon, 2002-06-10 at 22:35, Andi Gutmans wrote:
Or have a user-definable classpath. But I think it's better not to call
into PHP code.
Andi
At 11:32 PM 6/10/2002 +0300, Andi Gutmans wrote:
I'd prefer not having a handler for autoloader. I'd prefer having the
Engine look for ClassName.php in the default include_path and if it
doesn't exist die... (i.e. not call any user-definable PHP function).
Andi
At 11:33 AM 6/10/2002 +0200, phpsurf wrote:
this patch would be really great !
I can remember it has been discussed a lot on the ZE2 mailing list about the
'import' feature.
some people (and I was) would have apreciated another name because this name
was already used in many PHP frameworks to implement a function that loads
classes.
As far as I followed this thread, the agreement was that the import keyword
can be used fine for namespaces if a autoload statement was patched to the
engine ... so everyone would be happy ! :)
I guess your patch gives some function like this one :
set_classautoload_handler(myAutoLoader);
and then, one can implement a function like this:
myAutoLoader($className) {
if (!class_exists($className)) {
include(class/.str_replace(_, /, $className)..php);
}
}
I'm sure many programmers would apreciate such a feature.
Especially as it whould have no BC issue at all !
-Original Message-
From: Ivan Ristic [mailto:[EMAIL PROTECTED]]
Sent: dimanche 9 juin 2002 22:46
To: Zeev Suraski
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] REPOST: Class Autoloading [PATCH]
I believe this has been discussed in the past and not ack'd,
please read
the php-dev archives...
I tried and I tried but I couldn't find a discussion on anything
similar on the mailing list.
The code I sent is *already* in use, and has been in
use for some time now. Take a look at this message from
November 2001:
http://marc.theaimsgroup.com/?l=php-devm=100687224711738w=2
I didn't introduce anything new, so if it was OK then it should be
OK now. Also, the code cannot affect the people that are not using
the feature so I do not think that there will be any kind of impact
on the existing user base.
This feature makes it possible to have one class per file and not
to worry about inclusion at all. It becomes especially useful when
used together with products such as Zend Accelerator, where files
are cached (and you do not have to worry about a large number of
small files).
--
Ivan Ristic, [EMAIL PROTECTED]
[ Weblog on PHP, Software development, Intranets,
and Knowledge Management: http://www.webkreator.com ]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
__
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway
http://pear.php.net/wishlist.php/ssb
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL != Siberia
You tell me :) We currently have no nice way of bootstrapping PEAR on Windows like we have on Unix (with make install-pear-installer and go-pear). What would be the most sensible way of giving Windows users something ala go-pear? - Stig On Sun, 2002-06-09 at 18:49, Shane Caraveo wrote: Hmm, what is happening for win32? Stig S. Bakken wrote: With the latest PEAR installer (version 0.90), PECL extensions are now built and installed during pear install/upgrade on Unix systems. First: upgrade PEAR to 0.9 with pear upgrade PEAR. If you have the xmms libraries and php_gtk installed, you can see it in action by doing simply pear install xmms. The output is like this: -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
Hi,
I have promised myself to not get into this discussion for a week now,
but the smell of dead horse overwhelmed me, so here goes...
I am guilty of a lot of OO use in PHP related to PEAR, I think OO is a
good thing when used right, but if not.. well, as Ken said at LinuxTag,
here, have some rope. I welcome ZE2's improvements, many of which
came to be for PEAR and similar systems, and I'm even part guilty in
some of the ZE2 design.
Anyway. In Java, you use objects on a very deep level, even strings are
objects. This makes perfect sense, because in Java creating objects is
very cheap compared to PHP. In PHP objects are expensive, so they
should be used on a much higher level. I have seen PHP frameworks
(well, _a_ PHP framework) with a String class, and that tells me that
someone has a hammer and is trying to knock in screws with it.
But I should not generalize.
There are some OO features that only make sense in combination with
others. I'll list them one by one, and even offer some alternatives:
1. Interfaces / multiple inheritance
IMHO, interfaces make little sense in a language with loose typing,
without late bindings and where code is by default compiled on every
execution.
The loosely typed nature of PHP does IMHO not fit well into the
explicit paradigm that interfaces represent, because they introduce
conditions that have to be met during compilation for a class to be
valid.
Also, the definition of an interface is abstract, so you would be
loading the abstract definition on every single request when PHP is used
in its natural habitat.
The solution to this problem that was accepted a few months ago is
aggregates. They allow what is not too unlike runtime multiple
inheritance, but we also decided on a way to declare aggregates during
definition:
class foo aggregates bar {
}
The main difference between extends and aggregate here is that the
aggregation, created at runtime, may be removed. You may also add
additional aggregates later, as well as multiple in the class
definition. Please check the archives (there is one, right? :-) for
further details.
This does not match interfaces feature-wise because aggregates
implemented like this do not offer the explicitness. But that is a much
larger language design issue. Having a language that may both be loose
and explicit is a Bad Idea IM(NS)HO. Take a look at Perl, and see how
much fun you get when using strict CPAN packages (which is most) in
scripts where you don't want to bother. You end up writing only strict
code, which in practice will require the option. Doh.
2. Optional strong typing
When people say that being able to do
function Bar(MyClass $foo) { ... }
will not affect performance, is this based on pure wishful thinking or
real insight in the engine? I can't see how this would not have a
performance impact. I think type hints are a good idea, as long as they
are implemented with low impact.
3. Case sensitivity
This horse is already decomposing. When you can get the originally
cased name of a symbol from the engine, there are no technical reasons
for introducing case sensitivity to PHP, only aesthetic and
scratchmyitchic. But alas, we try keeping to technical reasons.
Poor horsie.
- Stig
On Sat, 2002-06-08 at 03:40, Dan Hardiker wrote:
There are two reasons we repeat the 'PHP is not Java mantra':
(a) Many of those requesting these changes actually DO want to see PHP
as a Java with PHPish syntax.
Anyone wanting PHP to be a simple or more flexable Java is barking up
the wrong tree... in fact all of the people I know who Im lobbying better
OO functionality in PHP for know Java and know PHP - and use both where
each is best. What we are requesting is that PHP expands its OO
capabilities - not change the way it does things, not do anything
outlandish or stolen from another language. Think about it - all it
would be is like adding an extra gear to a car. Wouldnt change the
concept, the design or the idea of the car... not the make nor model... it
would however give it added depth and use.
eg: simple db-based shopping cart web site? use PHP... complex internet
backing system? use Java. Easy!
(b) Java is (so far) the best implemented OO language out there that's
actually being used. It symbolizes the extreme OO world, if you will.
Agreed - but that doesnt mean that the people on this list are assosiating
more OO in PHP as being one step closer to PHP being PHP-Java. If I wanted
Java's OO implementation in PHP, Id use Java. I dont - I want OO
implementation (not even to the extremeness of Java) put in PHP. Im not
even sure where the issue lies of taking the step - other than where is
this heading in the long run.
Is this all that much of an issue to implement MI, Pub/Pri/Prot
methods/vars, possibly interfaces? Not to be Java, but to extend PHP...
all those would help PHP as a *web based language* (hell it would help any
language IMHO - given that its optional and not
[PHP-DEV] PECL != Siberia
With the latest PEAR installer (version 0.90), PECL extensions are now built and installed during pear install/upgrade on Unix systems. First: upgrade PEAR to 0.9 with pear upgrade PEAR. If you have the xmms libraries and php_gtk installed, you can see it in action by doing simply pear install xmms. The output is like this: downloading xmms-0.2.tgz ... ...done: 11,968 bytes 4 source files, building running: phpize PHP Api Version: 20020307 Zend Module Api No : 20010901 Zend Extension Api No : 20020429 Xmms library install dir? [autodetect] : building in /var/tmp/pear-build-ssb/xmms-0.2 running: /tmp/pear8AzLoo/xmms-0.2/configure --with-xmms running: make xmms.so copied to /tmp/pear8AzLoo/xmms-0.2/xmms.so install ok: xmms 0.2 Add one or more -v options to pear to see more details (pear -v ...) To make your own, use PECL/xmms/package.xml or PECL/mailparse/package.xml as examples. Mailparse is a good example of a simple, standalone PECL package that uses no external libraries. Xmms is more advanced, it requires an external library, as well as php-gtk, and it also does a few substitutions in installed scripts (gtkxmms). Remember to use pear pv (package-validate) to sanity-check package.xml files before committing. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
On Sun, 2002-06-02 at 23:13, Sebastian Bergmann wrote: Zeev Suraski wrote: PHP can become stronger, but it will NEVER make a shift and become Java. I don't want it to become Java. I want PHP to stay as simple as possible for beginners, simpler if possible as Shane pointed out. Regarding this I think once the PEAR/PECL infrastructure is in place and people get used to it I think installation and customization of PHP will become easier. But, as I said before, I don't understand why simplicity should mean in its consequence that software designs you find these days in the Java World cannot be done with PHP. The essence (in one sentence) of what I would like to see: I love PHP, but I would like to design and implement my application the same way I could do with Java. But that is what you'll never get with PHP. Just look at how fast creating objects is in Java. Java revolves aroun on objects, they are created and destructed implicitly during execution of overloaded operators and everything. PHP has a _much_ higher cost for using objects. This has design implications that rules out designing your PHP code as you would do for Java. But I guess you already knew that ;-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 2002-06-01 at 02:08, [EMAIL PROTECTED] wrote: On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. XML is a basic building block of the web these days. I really can't say that about ODBC. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. Such sysadmins have already learnt the usage of --without-xxx options. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 2002-05-30 at 02:04, Markus Fischer wrote: On Thu, May 30, 2002 at 08:12:27AM +0900, Yasuo Ohgaki wrote : Brad Lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. We bundle mysql for the very same reason Brad wants to bundle libxml2. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 2002-05-30 at 03:29, Yasuo Ohgaki wrote: I think we can remove expat bundle now.) Think again :-) Expat has been bundled for ages, and IMHO we should not drop it unless we have another bundled xml library and ext/xml can use that instead. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. Having a too old version installed doesn't help much in this case. :-) If Brad is able to trim down libxml2 to a reasonable size, I'm +1 - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RESENT] [PATCH] Allow constants / expressions to bepassed by reference]
If this patch doesn't break anything, and it doesn't give us any
difficulties with ZE2 or major design issues, I'm +1.
- Stig
On Tue, 2002-05-28 at 21:12, Jason T. Greene wrote:
Due to this patch being sent during the msession discussion, it has not
been noticed, so I am resending.
-Jason
From: Jason Greene [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [PHP-DEV] [PATCH] Allow constants / expressions to be passed by reference
Date: 25 May 2002 02:18:52 -0500
Problem
---
There are some scenarios where a function requires the ability to modify
parameters that may also be optional. Optional parameters work well,
except in the scenario where all of the pass by reference parameters can
be optional. ex the socket_select() function. Since select is
argument-result, all three arrays that are taken as input must be passed
by reference, yet any can be excluded. So for example if you were
calling socket_select with a read socket array, a write socket array,
yet no exception array (quite common), you are currently forced to do
something like the following:
$wfds = array($sock1, $sock2);
$rfds = array($sock3, $sock4);
$null = NULL;
socket_select($rfds, $wfds, $null);
I have ran into this problem before several times while developing in
user space. (Especially when passing around semi-complex data
structures)
Proposed Solution
--
Allow all expressions to be passed by reference. This will allow
something like the following
function normalize($element_tree, $node_mapping, $max_depth){
//Code
}
normalize($my_tree, NULL, 25000);
Patch
--
I have attached a patch against ZE2 that accomplishes this.
Thanks,
-Jason
Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.285
diff -u -r1.285 zend_compile.c
--- zend_compile.c23 Apr 2002 18:06:53 - 1.285
+++ zend_compile.c25 May 2002 06:45:21 -
@@ -1271,7 +1271,7 @@
op = ZEND_SEND_REF;
break;
default:
- zend_error(E_COMPILE_ERROR, Only variables can be
passed by reference);
+ op = ZEND_SEND_VAR;
break;
}
}
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.341
diff -u -r1.341 zend_execute.c
--- zend_execute.c8 May 2002 18:43:19 - 1.341
+++ zend_execute.c25 May 2002 06:45:25 -
@@ -2292,10 +2292,6 @@
NEXT_OPCODE();
}
case ZEND_SEND_VAL:
- if (EX(opline)-extended_value==ZEND_DO_FCALL_BY_NAME
-
ARG_SHOULD_BE_SENT_BY_REF(EX(opline)-op2.u.opline_num, EX(fbc),
EX(fbc)-common.arg_types)) {
- zend_error(E_ERROR, Cannot pass
parameter %d by reference, EX(opline)-op2.u.opline_num);
- }
{
zval *valptr;
zval *value;
@@ -2329,7 +2325,8 @@
zend_ptr_stack_push(EG(argument_stack), varptr);
NEXT_OPCODE();
}
- zend_error(E_ERROR, Only variables can be
passed by reference);
+ /* Should only occur with an uninitialized
variable */
+ goto send_by_var;
}
NEXT_OPCODE();
case ZEND_SEND_VAR:
--
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] Re: cvs: php4 /netware php-nw.bat
On Tue, 2002-05-28 at 15:32, Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Venkat Raghavan S wrote: rvenkatTue May 28 01:33:08 2002 EDT Added files: /php4/netwarephp-nw.bat Log: I suppose you are working to implement NetWare SAPI. Correct directory for these files should be sapi/netware Is there anything special about NetWare SAPI? (or am I missing something?) I guess I'm missing something, since Venkat is keep committing to php4/netware. I'm just curious. Why netware SAPI(?) has to be located php4/netware instead of php4/sapi/netware? What's the special thing about NetWare? To me this looks like a port to the Netware OS, not a SAPI implementation. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: I need your support: Reinstatement of msession
On Fri, 2002-05-24 at 23:31, Andrei Zmievski wrote: I would like reinstatement of msession into the main tree, and if you oppose I would like a serious discussion to take place on the developer list. If you support it, I need you to sound in on the discussion. I intend to re-add it back to CVS early next week. I have spent a good amount of time on the extension, I think, and many will agree, it is a good extension and deserves to be in the main tree, not PECL. The msession extension and daemon represents almost a years worth of work and over 40,000 lines. The primary purpose of this effort was PHP. The notion of removing it out of the main tree without it even being discussed on the develpers list is scary. I am left with the feeling I was ambushed by this group. The action was taken without proper discussion, and certainly much quicker than it should have, and definitely without ensuring that I was notified before the fact. Just remember, your extension may be next! I apologize for not notifying you before moving it. However, you should consider a few things. 1. The discussion about moving msession to PECL did take place on the list, albeit some time ago. 2. Having it in PECL does have its benefits. 3. As we've discussed in the past, *a lot* of extensions currently living in ext/ will be moved to PECL. PHP should come with a lean set of extensions and we should widely advertise where they can get the rest. So, indeed, someone else's extension may be next. I would like to point out that moving to PECL (pickling) is not the same as not having stuff bundled with PHP anymore. The main point is to separate CVS areas, so the main PHP distribution has more control on what versions of different extensions it bundles. As good as every extension (except ext/standard) could move to PECL, where they can live happily with their own release cycles, and PHP be released with the latest stable version of each it wants to bundle. In addition, since each PECL extension is also a PEAR package, extensions may be upgraded individually if the extension was build as a shared lib. How far we want to go one way or the other is still in the open. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL
On Sat, 2002-05-25 at 19:03, Andi Gutmans wrote: At 09:52 25/05/2002 -0700, Rasmus Lerdorf wrote: This stuff is in the works. The current pear tool only works with php-based pear packages, but it will soon get a wrapper that will phpize and build extensions for you with proper dependency checking. Great, but I'd still like to have a KISS mechanism for C extensions like I mentioned which would work without phpize but copy to ext/ and then do a buildconf. I see this as the mechanism which would allow us to move certain extensions out of ext/. I've mentioned this to Stig in the past so he might have it on his TODO. There are two KISS perspectives here, consider these two user stories: 1. The user is about to install PHP from source, and wants to include xyzzy support, which is in PECL only. He would then have to import the xyzzy sources into his source tree and re-run autoconf and autoheader: $ pear import-source xyzzy $ autoconf $ autoheader The rest is plain configure routine. 2. The user has already installed PHP, but needs to upgrade his xyzzy extension. However, the PHP version that bundles the xyzzy he needs introduces a non-BC feature in another bundled extension, so the user doesn't want to upgrade PHP itself. However, since he build PHP with xyzzy as a shared extension, he can upgrade it easily: $ pear upgrade xyzzy This downloads the source, runs phpize, runs configure (possibly prompting for options), and replaces the old xyzzy.so file. There's not much left in the infrastructure to get there. The package.xml format needs to be able to tell which configure options to check for, and the PEAR_Config class needs to be able to store this for each extension, and finally some code doing phpize/configure/make/make install. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL
On Sun, 2002-05-26 at 11:18, Stig S. Bakken wrote: On Sat, 2002-05-25 at 19:03, Andi Gutmans wrote: At 09:52 25/05/2002 -0700, Rasmus Lerdorf wrote: This stuff is in the works. The current pear tool only works with php-based pear packages, but it will soon get a wrapper that will phpize and build extensions for you with proper dependency checking. Great, but I'd still like to have a KISS mechanism for C extensions like I mentioned which would work without phpize but copy to ext/ and then do a buildconf. I see this as the mechanism which would allow us to move certain extensions out of ext/. I've mentioned this to Stig in the past so he might have it on his TODO. There are two KISS perspectives here, consider these two user stories: 1. The user is about to install PHP from source, and wants to include xyzzy support, which is in PECL only. He would then have to import the xyzzy sources into his source tree and re-run autoconf and autoheader: $ pear import-source xyzzy $ autoconf $ autoheader The rest is plain configure routine. 2. The user has already installed PHP, but needs to upgrade his xyzzy extension. However, the PHP version that bundles the xyzzy he needs introduces a non-BC feature in another bundled extension, so the user doesn't want to upgrade PHP itself. However, since he build PHP with xyzzy as a shared extension, he can upgrade it easily: $ pear upgrade xyzzy This downloads the source, runs phpize, runs configure (possibly prompting for options), and replaces the old xyzzy.so file. I meant to mention that these two examples are actually mutually exclusive, since you can't upgrade an extension if you built it statically into PHP. We could solve that by flipping the default extension build from static to shared, so you have to do --with-xyzzy=static,/usr instead to get the static version (in which case PEAR would lock that extension from upgrades). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/msession .cvsignoreCREDITS README config.m4 msession-test.php msession.c msession.phpphp_msession.h reqclient.h
On Fri, 2002-05-24 at 21:21, Sebastian Bergmann wrote: [EMAIL PROTECTED] wrote: I am looking at the bugs list on news.php.net, and I can't find any mention of msession. #php.bugs @ EFNet != php-bugs @ lists.php.net #php.bugs is a pretty closed forum compared to any php mailing list. Mailing lists are the right place for decisions if any need making, not an IRC channel (unless everyone involved hang around on that channel). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Full-duplex communication
I suggest you take a look at BEEP, which is meant for full-duplex communication. HTTP simply isn't. http://www.alltheweb.com/search?q=beep+protocol - Stig On Wed, 2002-05-22 at 12:16, Vinod Panicker wrote: Hi, I had a peculiar requirement. I need the ability to send asynchronous data from my web server to the client (COM component). I know that the first thing ppl will say is not to be using a web server, and to use a TCP solution. Thing is that the system is in a production environment and needs to be optimised. So i came up with the solution that if I could get hold of the socket on which the client is reading, and store it somewhere, other php scripts or a C++ binary can use the socket to write() to it, and the client on the other end will receive the data. Putting it in more detail - The client calls a script on the server - script_a.php using a keep-alive connection. The script gets the socket from the web server (this is the unknown), and stores it in a database. Script finishes execution, client reads response, but apache doesnt close the connection since its keep-alive. Client wants to call another script on the server, just writes to the same socket. Script returns response. Server wants to send data asynchronously to the client, so a PHP script (invoked from another server) gets the socket of the client from the database and writes to it. Client reads from the socket. So this is basically a full-duplex connection over HTTP :) Only thing to get is the socket :( Any ideas? I'm willing to do some coding in C to get this done, if someone can pls direct me where to start... can the PHP module get the socket details from apache? Or will i have to do a hack on apache itself? Tx, Vinod. _ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs -- 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: [PEAR-DEV] SOAP, XMLRPC and WSDL
PHP already has SOAP support bundled in the xmlrpc extension, which is built upon the xmlrpc-epi library that we bundle. Why can't people improve that instead of re-inventing more wheels in all shapes and sizes? When we bundle a library, we should use it. - Stig On Thu, 2002-05-23 at 17:52, Andi Gutmans wrote: I think it's important to have a main stream soap implementation bundled with PHP and not a zillion different implementations floating around. If there is enough interest we could setup a Soap mailing list where interested people could cooperate possibly basing the official PHP Soap implementation on existing work, for example, Brad's work. As I personally don't have the knowledge nor the time I'm just making the suggestion :) It's up to people who are interested in this topic to move it forward. I think it would be extremely beneficial to PHP. Andi At 17:52 23/05/2002 +0200, phpsurf wrote: hi brad lafountain is working on a Soap extension which is not far from being stable. he made a good use of WSDL ... you should have look to http://phpsoaptoolkit.sourceforge.net/phpsoap/ -Original Message- From: Markus Wolff [mailto:[EMAIL PROTECTED]] Sent: jeudi 23 mai 2002 15:29 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL Am Thu, 23 May 2002 14:57:45 +0200 schrieb Lukas Smith [EMAIL PROTECTED]: What is the current status in terms of SOAP, XMLRPC and WSDL in php? How mature are the solutions? When will they be ready for primetime? Does anyone already use them in production (that can be used to show off how great the support is) or are there any other prominent examples? (I know the pear installer uses XMLRPC and Sebastian did something with Googles Webservices) We´ve been trying to make a PEAR::SOAP webservice talk to a VB.NET SOAP client. It does work very well when you stick to passing most primitive datatypes around: Strings, Integers, Floats, Booleans ... It stops being fun when you´re trying more complex structures like resultsets from SQL-Queries. Those could be represented and passed via SOAP as two-dimensional arrays, and in theory you could either use a loosely typed two-dimensional array or an array of struct to represent that data in the VB.NET client - but we did not yet manage to make the client recognize and deserialize the SOAP data from the PHP script. I have not the slightest idea where to start looking. I´ve read tons of articles on SOAP and WSDL, but all in all, the quality of documentation on this topic sucks. PEAR::SOAP itself is as good as undocumented (at least the server part) and the documentation for .NET webservices mostly talks about connecting an ASP.NET webservice to a C# or VB.NET client. When it comes to making SOAP calls to a client/server on another software platform, or even if you just want to use SOAP-RPC encoding instead of the default Document/Literal encoding that .NET does, the documentation is very uncomplete. Thing is, you _have_ to use SOAP-RPC encoding because PEAR::SOAP does not yet support Document/Literal (in fact, Microsoft seem to be the only ones who use this encoding method by default or even fully support it). I guess when it comes to maturity, all available implementations in any language still have a long way to go. Regards, Markus -- *21st Media*| Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff| Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif -- 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] Full-duplex communication
On Thu, 2002-05-23 at 14:39, Vinod Panicker wrote: Hi Faisal, Tx for ur thoughts... On Thu, 23 May 2002 Faisal Nasim wrote : Hi, Why not simply use Apache to forward to the request to your PHP script or 'other program' and deploy threads for whatever process you want to run in the background? I dont want to run anything else in the background. All i want to do is to have the ability to send some data to the client when it is required by the system. Try making a size 0 frame with a php script inside that output complete chunks of javascript (script start/end tags). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
On Thu, 2002-05-23 at 23:28, brad lafountain wrote: One reason is xmlrpc doesn't have everything that goes along with soap. meaning WSDL UDDI WebServiceSecurity. WSDL can be implemented through the introspection stuff in ext/xmlrpc. It's just about describing/documenting the available interfaces, right? UDDI is just a catalog service AFAIK, so that would fit better on top of the SOAP stuff. and as far as i understand that xmlrpc doesn't work on windows. and with some benchmarks phpsoap so far was 3 times as fast as xmlrpc. Really? What XML parser are you using? - Brad --- Stig S. Bakken [EMAIL PROTECTED] wrote: PHP already has SOAP support bundled in the xmlrpc extension, which is built upon the xmlrpc-epi library that we bundle. Why can't people improve that instead of re-inventing more wheels in all shapes and sizes? When we bundle a library, we should use it. - Stig On Thu, 2002-05-23 at 17:52, Andi Gutmans wrote: I think it's important to have a main stream soap implementation bundled with PHP and not a zillion different implementations floating around. If there is enough interest we could setup a Soap mailing list where interested people could cooperate possibly basing the official PHP Soap implementation on existing work, for example, Brad's work. As I personally don't have the knowledge nor the time I'm just making the suggestion :) It's up to people who are interested in this topic to move it forward. I think it would be extremely beneficial to PHP. Andi At 17:52 23/05/2002 +0200, phpsurf wrote: hi brad lafountain is working on a Soap extension which is not far from being stable. he made a good use of WSDL ... you should have look to http://phpsoaptoolkit.sourceforge.net/phpsoap/ -Original Message- From: Markus Wolff [mailto:[EMAIL PROTECTED]] Sent: jeudi 23 mai 2002 15:29 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL Am Thu, 23 May 2002 14:57:45 +0200 schrieb Lukas Smith [EMAIL PROTECTED]: What is the current status in terms of SOAP, XMLRPC and WSDL in php? How mature are the solutions? When will they be ready for primetime? Does anyone already use them in production (that can be used to show off how great the support is) or are there any other prominent examples? (I know the pear installer uses XMLRPC and Sebastian did something with Googles Webservices) We´ve been trying to make a PEAR::SOAP webservice talk to a VB.NET SOAP client. It does work very well when you stick to passing most primitive datatypes around: Strings, Integers, Floats, Booleans ... It stops being fun when you´re trying more complex structures like resultsets from SQL-Queries. Those could be represented and passed via SOAP as two-dimensional arrays, and in theory you could either use a loosely typed two-dimensional array or an array of struct to represent that data in the VB.NET client - but we did not yet manage to make the client recognize and deserialize the SOAP data from the PHP script. I have not the slightest idea where to start looking. I´ve read tons of articles on SOAP and WSDL, but all in all, the quality of documentation on this topic sucks. PEAR::SOAP itself is as good as undocumented (at least the server part) and the documentation for .NET webservices mostly talks about connecting an ASP.NET webservice to a C# or VB.NET client. When it comes to making SOAP calls to a client/server on another software platform, or even if you just want to use SOAP-RPC encoding instead of the default Document/Literal encoding that .NET does, the documentation is very uncomplete. Thing is, you _have_ to use SOAP-RPC encoding because PEAR::SOAP does not yet support Document/Literal (in fact, Microsoft seem to be the only ones who use this encoding method by default or even fully support it). I guess when it comes to maturity, all available implementations in any language still have a long way to go. Regards, Markus -- *21st Media*| Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff| Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http
RE: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
On Thu, 2002-05-23 at 23:38, Markus Wolff wrote: Stig S. Bakken said: PHP already has SOAP support bundled in the xmlrpc extension, which is built upon the xmlrpc-epi library that we bundle. Why can't people improve that instead of re-inventing more wheels in all shapes and sizes? When we bundle a library, we should use it. - Stig Unfortunately, not all (in fact, very few) providers install that extension - as well as they don´t install many other useful but not-so- common extensions. They´ll keep it this way unless enough people ask for it. But as long as only few people know these extensions exist (in part because so few providers install them), not enough people will ask for them. The best thinkable solutions would be: a) Bundle a library like PEAR::SOAP with PHP that is modified in a way that it automatically detects if the xmlrpc-epi extension is installed. If so, PEAR::SOAP only acts as a wrapper class around the calls to the extension. Else, it uses its own, slower PHP routines. b) Integrate xmlrpc-epi support as a standard extension that is installed by default. I think this is a good approach. It's the same thing we did with PEAR DB: make a good API first. The only thing that worries me with the PEAR SOAP and PEAR XML_RPC APIs is that they use objects for everything, even a boolean is represented by a freaking object, both slow and very cumbersome. The beauty of xmlrpc-epi is that you deal with native PHP types (with some extra hacks for binary and date strings). This means exporting existing functions through xmlrpc is as easy as can be. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Tokenizer weirdness
On Thu, 2002-05-23 at 19:26, Sebastian Bergmann wrote: Andrei Zmievski wrote: That's not what I get. Did you try the latest CVS version? Yes. Windows issue? Does anyone else using Windows see this? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Full-duplex communication
On Thu, 2002-05-23 at 23:59, Stig S. Bakken wrote:
On Thu, 2002-05-23 at 14:39, Vinod Panicker wrote:
Hi Faisal,
Tx for ur thoughts...
On Thu, 23 May 2002 Faisal Nasim wrote :
Hi,
Why not simply use Apache to forward to the request to your PHP
script or 'other program' and deploy threads for whatever
process
you want to run in the background?
I dont want to run anything else in the background. All i want to
do is to have the ability to send some data to the client when it
is required by the system.
Try making a size 0 frame with a php script inside that output complete
chunks of javascript (script start/end tags).
I hit send a bit early :-)
The trick is something like this page A is a frameset rows=*,0 where
the 0-height frame is a php-driven request that does not stop, ala this:
headtitlecontrol page/title/head
?php
while (true) {
print script language=javascript\n;
print top.mainframe.document.write('tickbr');\n;
print /script\n;
flush();
sleep(1);
}
?
I've used this trick to implement progress bars and such for big
database operations, it works like a charm.
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP linux binary and Super global variables
On Tue, 2002-05-21 at 05:16, Ori Staub wrote: After compiling PHP 4.2.1 as a CGI binary and executing from the command promot (php -q) I noticed that the new Super Global variables dont work (in particular I need $_ENV and $_SERVER). I looked through the manual to find some answers but didnt. Is this a feature or bug? Ori Are you sure that it is in fact the CGI binary you are using? The CLI version of PHP will not register these variables. Try 'php -r var_dump(PHP_SAPI);' to see which one it is. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enabling ext/zlib by default
On Tue, 2002-05-21 at 08:13, Sebastian Bergmann wrote: I think we should make '--with-zlib' the default, and add '--disable-zlib', for the PHP 4.3.0 release, since the PEAR Installer relies on it. It's not supposed to, I've added nocompress options everywhere needed, so it should work just fine without zlib: * If you do pear install Foo without zlib, it will actually download http://pear.php.net/get/Foo?uncompress=1, which makes the server send the file with gzreadfile. * The packages bundled with PHP are plain .tar files. Even if you enable zlib by default, PHP does not bundle zlib, it would not be available on every system, and the installer would have to support uncompressed packages anyway. IMHO it would be better to have the zlib extension installable with pear install zlib :-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enabling ext/zlib by default
On Tue, 2002-05-21 at 08:57, Sebastian Bergmann wrote: Shane Caraveo wrote: Hmm, I couldn't make the pear command work on windows until I loaded the zlib extension. Same here on *NIX when I tried a 'pear package'. Try pear package -Z. I'll make the -Z option default when zlib is not available. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enabling ext/zlib by default
On Tue, 2002-05-21 at 08:54, Martin Jansen wrote: On 21 May 2002 08:46:54 +0200, Stig S. Bakken wrote: On Tue, 2002-05-21 at 08:13, Sebastian Bergmann wrote: I think we should make '--with-zlib' the default, and add '--disable-zlib', for the PHP 4.3.0 release, since the PEAR Installer relies on it. It's not supposed to, I've added nocompress options everywhere needed, so it should work just fine without zlib: I could have sworn that I got an error message some days ago when using PEAR on a pretty recent PHP version without zlib, but I may be wrong.. Even if you enable zlib by default, PHP does not bundle zlib, it would not be available on every system, and the installer would have to support uncompressed packages anyway. But it does not do any harm if we enable it by default, no? Additionally we would also save some bandwidth then. (Yes, I know that most PEAR packages are 20 KB :-). Oh, I don't mind enabling zlib by default, maybe I got too caught up in explaining why this wouldn't solve the problem completely. ;-) +1 on enabling zlib by default, but the disable option should be --without-zlib. Anyway, if we want to save bandwidth, there should be both bz2 files available too. Does the bzip2 extension work in Windows? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: segfault in version_compare
On Tue, 2002-05-21 at 07:45, Rasmus Lerdorf wrote:
Stig, I was going to fix this, but then I saw your code...
So here you go. pear install XML_RSS ends up causing this call:
version_compare('', '1.0', 'ge');
This tosses php_version_compare() into an infinite recursive loop
eventually ending in a segfault. Now, why exactly php_version_compare()
needs to be a recursive function is a bit beyond me and hence the handoff.
It's recursive because it uses the same algorithm to compare each
element in the version number. Implementing that as a loop is even
uglier IMHO. Will fix the bug.
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] ITX.php require_once error
On Tue, 2002-05-21 at 09:25, Dan Allen wrote: The require_once is wrong in both IT.php and ITX.php Yes, I had mentioned the other in an eariler e-mail. Okay, I am way confused. I thought that PEAR was using a flat directory structure, but everyone keeps saying how all the '_' should be '/' when you install it. What is it, flat or deep?...or is the flat just for the CVS tree? Dan p.s. If it is flat then the require_once should be 'HTML_Template_IT/IT.php' etc... It's flat in CVS, deep in the install root. See the FAQ. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for file.c
On Tue, 2002-05-21 at 17:28, Dean Richard Benson wrote: Hi all I have been working on a system recently that has been using the fgetcsv function. It works a treat except that the code assumes that the enclosure character will always be a double quote. This caused me a little bit of a problem as many of the csv files that I work with use the single quote character to achieve the same thing. I have never submitted a diff file to php before, but I have prepared once that adds a new optional parameter which is the enclosure character (defaults to double quote). Can you let me know whats the best thing to do from here to get the change reviewed by yourselves and possible included in the next php release. I wasn't sure if I could just attach my file.c.patch file to this email or not? That's fine, but make sure the MIME type for the attachment is text/plain or the mailing list software will remove it. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tip of the day: embedding php code in scripts
Did anyone come up with this one before or do I have a first post? :-) #!/bin/sh exec php -d output_buffering=1 $0 $ ?php ob_end_clean(); print Hello World!\n; ? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Tip of the day: embedding php code in scripts
On Mon, 2002-05-20 at 19:21, Preston L. Bannister wrote: From: Stig S. Bakken [mailto:[EMAIL PROTECTED]] Did anyone come up with this one before or do I have a first post? :-) #!/bin/sh exec php -d output_buffering=1 $0 $@ ?php ob_end_clean(); print Hello World!\n; ? Or the shorter (and faster) version: #!/usr/local/bin/php -d output_buffering=1 ?php ob_end_clean(); print Hello World!\n; ? Or perhaps you had something else in mind? Uhm, well, you could just drop the output buffering in this case. I had the specific embed in sh script case in mind. I believe most (all?) modern Unix implementations do #! handling in the kernel's exec() function, so you avoid the /bin/sh startup. Sure. The point is that you may not know the real path to the PHP executable, or you want to run PHP from a file that is processed with sh for some other reason. Another solution could be #!/usr/bin/env php, all of the systems I've tested with had env in /usr/bin, but it's still not as cool :-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Tip of the day: embedding php code in scripts
Without output buffering, the script would output: exec $0 $@ Hello World! The -q option could be added to make it work with cgi as well as cli, but the point of the output buffering is to kill the line of shell script that PHP would treat as plain text to display. - Stig On Mon, 2002-05-20 at 19:42, Dan Hardiker wrote: Im unsure of the need for output_buffering... if its to kill the headers, then php -q will suppress those. In any case, I believe the Stig is asking if anyone has thought of embedding php scripts inside typical /bin/sh shell scripts. EG: #!/bin/sh //- script stuff here -\\ exec /usr/local/bin/php -q ?php print Hello World!\n; ? //- script stuff here -\\ Unless Im mistaken ... for which I appologise. - Dan From: Stig S. Bakken [mailto:[EMAIL PROTECTED]] Did anyone come up with this one before or do I have a first post? :-) #!/bin/sh exec php -d output_buffering=1 $0 $@ ?php ob_end_clean(); print Hello World!\n; ? Or the shorter (and faster) version: #!/usr/local/bin/php -d output_buffering=1 ?php ob_end_clean(); print Hello World!\n; ? Or perhaps you had something else in mind? I believe most (all?) modern Unix implementations do #! handling in the kernel's exec() function, so you avoid the /bin/sh startup. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer -- 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] karma
Drop a mail to [EMAIL PROTECTED] - Stig On Thu, 2002-05-16 at 07:00, brad lafountain wrote: How would i go about getting karma for cvs commits? - Brad __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- 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] Profiling PHP
Okay that's more like it, emalloc on top. That's what I would expect in the first place. And I guess Zeev is right that it doesn't really tell you anything expect from that PHP does its share of alloc/free, and then some. - Stig On Mon, 2002-05-13 at 23:06, Rasmus Lerdorf wrote: Well, zend_parse() is actually not always on top. I have run this thing longer now and it currently looks like this: (reverse order) 001bdcd0 293 0.42199 init_op 00156c08 306 0.440713smart_str_appendl_ex 0019b484 334 0.481039php_strlcpy 001db788 337 0.48536 _get_zval_ptr_ptr 0015f2b4 341 0.491121parse_iv2 001db198 347 0.499762zend_pzval_unlock_func 001cbf00 364 0.524246zend_hash_clean 0015ee18 392 0.564573var_push 001dbb88 396 0.570334zend_assign_to_variable 001c45d0 398 0.573214_zval_copy_ctor 001c3dfc 416 0.599139zend_ptr_stack_n_push 001bdaf0 432 0.622183destroy_op_array 001c3560 459 0.661069zend_str_tolower 0015701c 465 0.66971 smart_str_print_unsigned 001b9970 465 0.66971 zendlex 001b2440 467 0.672591_erealloc 001d45e4 473 0.681232zend_fetch_property_address 001c4970 497 0.715798_zval_ptr_dtor_wrapper 0015ef14 516 0.743162process_nested_data 001946c8 526 0.757565xbuf_format_converter 001b27fc 629 0.905909_estrndup 001db1fc 647 0.931834zend_clean_garbage 001cb9b8 686 0.988003zend_hash_rehash 001cc6cc 711 1.02401 zend_hash_copy 001c45c0 764 1.10034 zval_add_ref 001d398c 953 1.37255 zend_fetch_var_address 001ca5f8 975 1.40423 _zend_is_inconsistent 001cbda8 1046 1.50649 zend_hash_destroy 001c443c 1235 1.77869 _zval_dtor 001baf6c 1302 1.87519 _zval_ptr_dtor 001db270 1419 2.0437 _get_zval_ptr 0015dcb4 1464 2.10851 php_var_unserialize 001ccae0 2460 3.54298 zend_hash_find 001b3028 2917 4.20117 _mem_block_check 001d4ca0 3931 5.66157 execute 001ca85c 4438 6.39177 zend_hash_add_or_update 001a56bc 4597 6.62077 zendparse 001b21b8 4692 6.75759 _efree 001cdaf8 5458 7.86082 zend_inline_hash_func 001a9f4c 5501 7.92275 lex_scan 001b1ea4 6321 9.10374 _emalloc On 13 May 2002, Stig S. Bakken wrote: On Mon, 2002-05-13 at 17:53, Zeev Suraski wrote: The link you specified doesn't work (it's .net)... Nice touch on their part on having a page that doesn't render under IE :) Anyway, the important question is whether you're using it under Linux or some other OS. Under Linux, unless it has some kernel module, it's going to be horribly inaccurate. After finding this page, it does appear as if it's using a kernel module. Congrats to Linux for finally having a usable profiler! It's pretty consistent with the results I got using NuMega's profiler about a year ago (I don't remember the exact numbers, but the functions are more or less the same). Seeing that the single most time-consuming function is zend_parse, it would be interesting to see where the bottleneck moves when using ZendAccelerator or another caching product. Did you try that setup with NuMega's profiler? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Important: make test/run-tests.php broken?
Btw, now (in HEAD) you can run pear run-tests in any directory with tests in it. No need for a makefile. - Stig On Tue, 2002-05-14 at 13:05, Markus Fischer wrote: Hi, seems nothing happened there yet. CVS HEAD has the same problem. Just deleting the CGI in ~/php4/php does the trick and runs the test suite properly. - Markus On Fri, Mar 15, 2002 at 04:58:36PM +, Wez Furlong wrote : Damn - sapi/cgi is being run and the http headers are confusing the test suite... --Wez. On 16/03/02, Wez Furlong [EMAIL PROTECTED] wrote: Hey, Am I the only one that has every single test fail when running make test?? (I've tried with 2 separate working checkouts). It appears that the expected output and the actual output differ by a newline at the end... Can someone else verify, because my first suspcicion was my streams code, but I can't see anything wrong, and my other tree has the same problem (but no streams code). --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc - I mean When in doubt, blame mcrypt is more often right than wrong :) Always right, never wrong :) - Two PHP developers who want to remain unnamed -- 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] Safe Mode
Not for every user, but you can at least chroot people away to the same dir where they can not do local server hacks. I was _not_ suggesting that you set up five million chroot environments. :-) But, you said yourself that you bailed out on safe mode and went for a cgi setup. So that means exec(2) is providing you with a solution. As an aside, how many people are aware of Linux's capabilities support, that lets you control stuff like which processes may create sockets on the kernel level. (No I'm not suggesting that people should all switch to Linux and build their own capabilities-based distribution, I mention this for curiosity and perspective.) - Stig On Mon, 2002-05-13 at 11:30, Chand wrote: On 12 May 2002 23:42:21 +0200 Stig S. Bakken [EMAIL PROTECTED] wrote: Well, as long as there is exec(2), there is a way. How many users do Lycos Europe provide sandboxed PHP for? heya, We provide php for roughly 5 000 000 users, and it's growing everyday by 5000 approximately. Chrooted environments (i guess this is what you call sandbox/prison) is not viable in these conditions. - Stig On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote: But for really large shared hosts, I don't think that is feasible. How are you going set up 100,000 prisons on a server? I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- 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 -- -- Chand 640K ought to be enough for anybody. Bill Gates, 1981 Et après qui c'est qui s'amuse avec Un vélo en pédalant ? Sky, 2002 C'est super la musique classique, mais ca fait chier XL, 2002 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
IMHO this is the path we should pursue for PHP 5.0. - Stig On Mon, 2002-05-13 at 00:53, Shane Caraveo wrote: FastCGI can provide the security needed in shared environments, without loosing all the performance. I don't beleive it is fast as direct server plugins, but there are other benefits...such as running PHP single threaded to avoid thread issues. It would be nice to see it become a standard compile option. One thing that does need to happen is a multithreaded fastcgi option for PHP. I've had that in the back of my head but haven't gotten around to it yet. Shane Rasmus Lerdorf wrote: Instead of just giving up on the problem, perhaps we should go into full attack mode. I see a couple of choices (and there are probably others): 1. Review and push open_basedir as the PHP-based jail mechanism 2. Pitch in and get Apache 2's perchild mpm up to snuff. There are all sorts of other issues associated with this option though, like needing to make sure all the stuff we link against is threadsafe. 3. Push FastCGI as the solution based on Shane's latest work on that front 4. Come up with step-by-step idiot-proof instructions for setting up Squid or other reverse proxies and running multiple instances of Apache listening on multiple ports and having requests directed appropriately by something like SquidGuard. I don't mean we should do just one of these, we should perhaps push forward on all fronts and come up with a document that describes the plusses and minuses of each as it applies to large shared hosting scenarios. -Rasmus On 12 May 2002, Stig S. Bakken wrote: I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- 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] Profiling PHP
On Mon, 2002-05-13 at 17:53, Zeev Suraski wrote: The link you specified doesn't work (it's .net)... Nice touch on their part on having a page that doesn't render under IE :) Anyway, the important question is whether you're using it under Linux or some other OS. Under Linux, unless it has some kernel module, it's going to be horribly inaccurate. After finding this page, it does appear as if it's using a kernel module. Congrats to Linux for finally having a usable profiler! It's pretty consistent with the results I got using NuMega's profiler about a year ago (I don't remember the exact numbers, but the functions are more or less the same). Seeing that the single most time-consuming function is zend_parse, it would be interesting to see where the bottleneck moves when using ZendAccelerator or another caching product. Did you try that setup with NuMega's profiler? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- 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] Safe Mode
Well, as long as there is exec(2), there is a way. How many users do Lycos Europe provide sandboxed PHP for? - Stig On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote: But for really large shared hosts, I don't think that is feasible. How are you going set up 100,000 prisons on a server? I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- 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] Re: [PHP-CVS] cvs: php4 /sapi/cgi cgi_main.c /sapi/cli php_cli.c
php-config is for displaying information like this without the need for further parsing. Why not just add --zend-module-api --php-module-api and --zend-ext-api flags to php-config outputting the number and nothing else? - Stig On Sat, 2002-05-11 at 04:00, Markus Fischer wrote: Hi, On Sat, May 11, 2002 at 10:45:12AM +0900, Yasuo Ohgaki wrote : Markus Fischer wrote: Hi, I've modified the out now to look something like $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies Derick suggested also to add some other internal version numbers like module about for both PHP and Zend. We just need to come up with a decent description of the various numbers: ZEND_EXTENSION_API_NO ZEND_MODULE_API_NO PHP_VERSION_API How about use the macro names? For example, programmers may try to find . -name *.[ch] | xargs grep -n PHP_VERSION_API to see how API version macros are used. Ok, that would mean getting the PHP version number is something like php -v |grep PHP |grep -v PHP_ | ... sounds ok to me. So a complete output can look like: $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies PHP_VERSION_API 20020510 ZEND_EXTENSION_API_NO 20020510 ZEND_MODULE_API_NO 20020510 ? Hmm, now looking again, this looks ugly :) Would it make sense to have $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies and $ php -vv PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies PHP_VERSION_API 20020510 ZEND_EXTENSION_API_NO 20020510 ZEND_MODULE_API_NO 20020510 Or is this just unnecessary bloat and let's fire all versions we have to standard output with -v ? - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc I'm not stupid, you know? :) - Jani Taskinen -- 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: Re[2]: [PHP-DEV] PHP 4.3 charter and release plan
On Mon, 2002-05-06 at 11:54, Jan Schneider wrote:
Zitat von Andrew Sitnikov [EMAIL PROTECTED]:
Hello Stig,
SSB Huh, are you saying PHP _is_ locale-dependant?
Yes.
Example:
1.php
?
setlocale(LC_ALL,'ru_RU.CP1251');
include('2.php');
?
2.php
?
$var = 1.3;
var_dump($var);
?
gap /home/local/sitnikov GET http://si.infonet.ee/1.php
float(1)
Locale ru_RU.CP1251 has decimal delimiter ',';
I understand why it occurs (thanks to Stanislav Malyshev), but this is
not correct behaviour IMHO, and must be fixed ASAP.
Perhaps Bug 16865 (http://bugs.php.net/bug.php?id=16865) falls into the
same category of locale dependent bugs:
To quote from the bug entry:
---snip---
It seems like some constants are getting
undefined if you set the locale to tr_TR. It happens randomly with
internally defined and user defined constants and is reproducable with
this little script:
?php
setlocale(LC_ALL, 'tr_TR');
echo extension_loaded('imap');
echo SORTARRIVAL;
?
---snip---
This happened so far only with this specific locale, 'tr' for example works.
Jan.
Does this have to do with what Andrew Sitnikov mentioned about locale
settings being used in the parser?
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.1
On Mon, 2002-05-06 at 17:59, Christian Stocker wrote: On Mon, 6 May 2002, brad lafountain wrote: Man... When is the next planned release? don't know. ask stig .) No date yet. The current major changes list for 4.3 is: 1. New build system (Sascha) 2. PHP Streams (Wez) 3. Command-line SAPI installed by default (Edin) 4. PEAR integration including PECL builder (Stig) 5. MySQL changes (Zak) 6. GD bundling (Rasmus) 7. DOMXML changes (Christian) 8. MacOS X support (Marko) 9. Sockets extension (Jason Greene) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 4.3 charter and release plan
On Fri, 2002-05-03 at 12:31, Yasuo Ohgaki wrote: Stig S. Bakken wrote: Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 6. PostgreSQL changes (Yasuo) Core code has not been changed much. I'm available any time. When someone has signed up for each major change, I want to get a feeling for how much work remains and make a rough internal release schedule. The PHP_4_3_0 branch will be created when everyone says their stuff is ready for full testing. pg_convert/metadata/insert/select/delete/update functions are added. If other database interfaces are going to have such functions, it would be nice to have the same API (both C and PHP). pg_last_notice works fine for non ZTS, but it does not with ZTS. This is better to be fixed before 4.3.0 at least. I have to design and implement user defined type support in pg_convert, since this may need API change. Okay, in that case I won't add pgsql as a major change in 4.3. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 4.3 charter and release plan
On Fri, 2002-05-03 at 13:25, Christian Stocker wrote: In [EMAIL PROTECTED], Stig S. Bakken wrote: Hi, I've volunteered to RM (release master, not /bin/rm) PHP 4.3. This release will be synchronized with the public release of the PEAR (including PECL) infrastructure. This time I'd like to try partitioning the work a bit by identifying the major changes and have one person sign up as responsible for each. I will do the overall coordination and handle stuff that don't belong to these major changes. Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 7. DOMXML changes? (Christian) if noone else really would like to do it, i can take over this part. I don't think, there's much new stuff in domxml since 4.2 (yes, there is some, but nothing really critical), but testing all this would be a good idea, maybe adding missing functions from the DOM-Specs as well (but this depends until when we want tp release php4.3). I'm already using domxml from 4.3 on my testing machine and didn't realize any problems with it till now. Ok, sounds like this one won't be a major change either then. You're off the hook ;-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Win32 testing and run-tests.php (was: PHP 4 BugSummary Report)
If you plan on doing something like that, it would be nice if you could share what you have in mind first. - Stig On Sun, 2002-05-05 at 17:15, James Cox wrote: Hi, My plan is to revamp the way that tests work, so it's more efficient. But, you are more than welcome to work on the current testing system, -- all the tests will be converted anyhow :) Thanks, james -Original Message- From: Preston L. Bannister [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 05, 2002 10:37 AM To: James Cox Cc: Php-Dev@Lists. Php. Net Subject: RE: [PHP-DEV] Win32 testing and run-tests.php (was: PHP 4 Bug Summary Report) I'm not asking you to do all the work, rather I'm trying to figure out who is working on what, so I don't duplicate someone's work. I take it you're testing on Unix? The current tests are checked in to CVS? -Original Message- From: James Cox [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 6:18 PM Yes, i'm working on getting tests working on all platforms... but not today, probably very soon. -Original Message- From: Preston L. Bannister [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 05, 2002 2:14 AM Is anyone working on getting the run-tests.php and tests/* running on Win32? Who is adding test cases as bugs are closed? Fixed run-tests.php and added a Win32 project to run the tests. During the test run PHP faults (bad pointer/index during mbstring tests). This is a good thing, as it looks like this found a real PHP bug. Configuration: tests - Win32 Debug set TEST_PHP_EXECUTABLE=Debug_TS\php-cgi.exe cd .. Debug_TS\php-cgi.exe -q -c php.ini-dist run-tests.php OK - TEST_PHP_EXECUTABLE = Debug_TS\\php-cgi.exe Running tests in C:/net.php/php4-current/ext/bz2/tests == [all 2 test(s) skipped] Running tests in C:/net.php/php4-current/ext/crack/tests [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/ctype/tests ctype on integers ... passed ctype on strings (002.phpt) ... failed Running tests in C:/net.php/php4-current/ext/cybermut/tests === [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/db/tests = [all 6 test(s) skipped] Running tests in C:/net.php/php4-current/ext/dbplus/tests = [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/dbx/tests == [all 8 test(s) skipped] Running tests in C:/net.php/php4-current/ext/dio/tests == [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/domxml/tests = [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/exif/tests === [all 3 test(s) skipped] Running tests in C:/net.php/php4-current/ext/gmp/tests == [all 3 test(s) skipped] Running tests in C:/net.php/php4-current/ext/iconv/tests [all 5 test(s) skipped] Running tests in C:/net.php/php4-current/ext/interbase/tests [all 6 test(s) skipped] Running tests in C:/net.php/php4-current/ext/mbstring/tests === Simple multi-byte print test (EUC-JP) ... passed mb_internal_encoding() test ... passed mb_http_input() (003.phpt) ... failed mb_http_output() ... passed mb_detect_order() (005.phpt) ... failed mb_substitute_character() ... passed mb_output_handler() (EUC-JP) ... passed mb_preferred_mime_name() ... passed mb_strlen() ... passed mb_strpos() ... passed mb_strrpos() ... passed mb_substr() ... passed mb_strcut() ... passed mb_strimwidth() ... passed mb_convert_variables() (015.phpt) ... failed mb_convert_encoding() ... passed mb_detect_encoding() ... passed mb_strwidth() ... passed mb_strlen() ... passed Running tests in C:/net.php/php4-current/ext/mcrypt/tests = [all 1 test(s) skipped] Running tests in
RE: [PHP-DEV] Win32 testing and run-tests.php (was: PHP 4 BugSummary Report)
On Sun, 2002-05-05 at 22:18, Preston L. Bannister wrote: From: James Cox [mailto:[EMAIL PROTECTED]] My plan is to revamp the way that tests work, so it's more efficient. But, you are more than welcome to work on the current testing system, -- all the tests will be converted anyhow :) First iteration - regularize the output to allow easy post-processing (to HTML or for generating summaries), and made to run on Win32. Added information on context of test run to log (when, where, version). Made fatal any errors within the test scripts (rather than PHP). Require an exactly specified version of PHP (no guessing!). I'd really like to commit this stuff. The patches are getting large... Please apply for a cvs account at http://php.net/cvs-php.php. :-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 charter and release plan
On Fri, 2002-05-03 at 13:17, Andrew Sitnikov wrote: Hello Stig, Why you lose Make everything on the language-level independent of your locale settings. from TODO list ? This is very critical i think. If used locale with decimal separator like `,`, many script will working wrongly. SSB 1. New build system (Sascha) SSB 2. PHP Streams (Wez) SSB 3. Command-line SAPI installed by default (Edin) SSB 4. PEAR integration including PECL builder (Stig) SSB 5. MySQL changes (Zak) SSB 6. PostgreSQL changes (Yasuo) SSB 7. DOMXML changes? (Christian) Huh, are you saying PHP _is_ locale-dependant? I was not aware of that (but then again I always use the C locale). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 charter and release plan
On Fri, 2002-05-03 at 11:40, Wez Furlong wrote: On 03/05/02, Stig S. Bakken [EMAIL PROTECTED] wrote: Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 2. PHP Streams (Wez) Sure, but I'm a bit limited for time over the next month. That's fine. Predictability is the key. When someone has signed up for each major change, I want to get a feeling for how much work remains and make a rough internal release schedule. The PHP_4_3_0 branch will be created when everyone says their stuff is ready for full testing. One of the remaining todos for streams is making sure that the persistent sockets stuff works (pfsockopen); if there are any persistent resources gurus out there, your advice would be appreciated because there appear to be a couple of different ways of making things persistent but none of those methods are clear or documented. I'd also like to have a general consensus on the interfaces idea/RFC that I brought up recently: if the opinion is in favour then I would like to get that infrastructure in place and have the streams code make use of it: that serves two purposes - it will demonstrate how to use the interface API, and will reduce binary compatibility issues if we do decide to introduce it later on. I have already written the code for the interface API, so it's really just a matter of getting a majority vote in favour of having it in PHP. +1 from me. I think it'd be nice to play with it for a while to collect experience that can be used to make interfaces perfect in PHP 5 :-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] feature proposal: string types (complete with apatch)
Those who pay attention to my occasional ramblings may remember that I
once suggested implementing type hints, which is a more generic
version of this. Type hints is like your string types, except that they
apply to any type.
I guess the core issue here is whether adding an int to zval or
zval.value.str is worth the cost. With all the zval copying going on,
there will be a cpu overhead as well as memory. Back when Andi moved
zval.value.strlen and zval.value.strval into the str struct, thus saving
4 bytes in the zval struct, PHP 3 was generally speeded up by 25%. Not
sure if the PHP 4 or PHP 5 overhead will be in the same ballpark, but
it's something to think about.
IMHO the syntax you suggest is a bit terse, what about this instead:
echo urlhttp://$host:$port/$path;;
As for the SQL string type, there needs to be at least two, some
databases quote ' as '', others quote it as \'.
But I would like to extend the idea beyond reformatting inserted
strings. For example, for easy soap/xmlrpc serialization, being able to
tag a value as a date or some other soap/xmlrpc-specific type is very
useful.
- Stig
On Thu, 2002-05-02 at 06:18, [EMAIL PROTECTED] wrote:
Dear PHP developers,
I propose a feature that I call string types. I have also already
coded a first version of it that you can try. There's a bug for it
here: http://bugs.php.net/?id=16480 and a homepage with a description
and a patch here: http://nebuchadnezzar.zion.cz/php_strings.php
Please be patient when downloading. The server is behind a 64k line.
:-(
About the feature: It introduces five types of strings: plain string,
SQL string, HTML string, URL (query) string and undefined (unknown
type) string. The difference is in escaping characters that have
special meaning in SQL (quotes, nul), HTML (ampersand, less-than,
greater-than, double-quote) and URL (nearly everything except plain
letters and digits). The conversion is done automatically when
requested. This language extension is fully backwards-compatible;
users who don't know about the new features (or don't want to know)
need not worry: their existing scripts should work the same without
any change. For users who do know about this and want to use it, I
believe this new feature should bring significant improvement of code
readability, reduction of code size and reduced probability of bugs.
I think that the best explanation is by example, so see this:
$data = pa string with 'apostrophes', \double-quotes\ etc.;
mysql_query(sINSERT INTO table VALUES ('$data'));
Because we include a plain string in an SQL string, the plain string
is automatically converted to an SQL string, i.e. AddSlashes is
applied to it. Strings from GET/POST/COOKIE have the right type,
which makes it possible to easily write scripts that do not depend on
the setting of magic_quotes_gpc. (An SQL string included in another
SQL string is not converted, of course.)
Another one:
$data = pa string with less-than, greater-than, ampersand;
echo hINPUT TYPE=HIDDEN NAME=parameter VALUE=\$data\;
Here, the $data string is automatically HtmlSpecialChars'ed when
included in a HTML string.
Read more about it on the above mentioned homepage. Try it, test it,
tell me what you think about it! Just remember that this is alpha
code, and it is very little tested. I make no guarantees whatsoever,
except that it has bugs. :-)
Please cc me in any replies. I am not subscribed to the list (so in
fact, I don't know if it will allow me to post this). I realize that
this is not a good practice, but I couldn't handle the loads of mail -
and according to http://www.php.net/mailing-lists.php this list
isn't available in digest form. :-(
Thanks for your attention.
Vaclav Dvorak ([EMAIL PROTECTED])
http://nebuchadnezzar.zion.cz/
--
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
