Re: [PHP-DEV] [PATCH] OCI8 link failure (Tru64/AIX) (#22324)
I still think that the best solution would be to check if linking with -lcntsh alone is enough to get OCILobIsTemporary, and if not, check if it works with -locijdbc8. i think that makes sense. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
On Thu, Feb 20, 2003 at 05:11:55PM +0100, Wojtek Meler wrote: On Thu, Feb 20, 2003 at 05:48:29PM +0200, Zeev Suraski wrote: At 17:38 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - I looked into the bug report, and it is true that BLOCK_INTERRUPTIONS should indeed block SIGPROF. I'll fix this in the weekend. I'm not sure if after unblocking interruptions PHP will get SIGPROF ... it could cause long scripts. I'd rather use EG(timeout). I'm using it now and it's working. EG(timeout) is a horrible option (I wrote both, SIGPROF is by far superior). I'll try to implement a solution that won't lose the SIGPROF. It's possible to call zend_bailout if EG(timeout) is set in UNBLOCK_INTERRUPTIONS macro. But it doesn't solve main problem - it is not safe to just skip the stack - even PHP use locks (TSRM) and its memory allocator also use malloc/realloc/free which use locks, so it isn't safe. External libraries uses memory structures which can't be freed if paritialy modified (because SIGPROF stops modification in the middle). Trying to free them by PHP resource mechanism can cause SIGSEGV, busy loops etc. Not freeing them we loose memory ... I strongly recommend to stop using zend_bailout on timeouts (it's better to exit - it will not hang ;) zeev, remember we discussed the very same thing last year (or the one before) at linuxtag in frankfurt? i also think that exit() would be the clearest thing. but it won't help in any threaded environment - so it's not an option. thing is - no matter how clever it is implemented - calling longjump from a signal handler is calling for trouble unless everybody involved beeing very careful about their critical regions. especiqal non-threadsafe libs are very likely to not even have a concept what a critical section is... re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 4.3.0 ext/oci8 -- OCI_SHARED patch
On Tue, Jan 07, 2003 at 11:46:16AM -0500, Levi Dixon wrote: I have tested it and it works for me. As far as thread safety, all of OCI could suffer from thread safety problems, not just this feature. If we want ext/oci8 to be thread safe, we should really pass the OCI_THREADED flag into OCIInitialize(). At first glance it seems that thread safety should be accounted for #ifdef ZTS. Is this correct? I can add it if required. yes - but you only need to use OCI_THREADED if you want oci to mutex around the use of statements and connections. as we don't share statements or connections between threads (yet) we don't need to do that (yet). plus i think it will be slightly slower. (as you know threads are always slow;-) re, tc -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 4.3.0 ext/oci8 -- OCI_SHARED patch
On Mon, Jan 06, 2003 at 01:42:15PM -0500, Levi Dixon wrote: For review: I've modified the following files to allow for use of OCI_SHARED in ext/oci8 module if OCI8_VERSION = 8.1, which will provide memory savings by sharing connection and statement data (refer to http://www.csee.umbc.edu/help/oracle8/server.815/a67846/basics.htm; search for Shared Data Mode) between connections and statments respectively. I only have access to ext/oci8, so I can't check this in: configure main/php_config.h.in ext/oci8/config.m4 ext/oci8/oci8.ca there should be no nned to change anything outside ext/oci8/ to make this work. configure is auto-generated. just go ahead and commit the stuff to ext/oci8 Note: I'm not familiar enough with the windows distribution to add the mod there. neither am i. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI patch
On Thu, Dec 05, 2002 at 11:26:28AM +0100, Abdul-Kareem Abo-Namous wrote: ahem...yes i'd agree on that...i changed it to something more meaningful and attached a new patch..ah the switching between c and php programming..;) the patch is already being used for 2,5 months on an extremly big, extremly heavy-load 24x7 platform here at hp europe. basically all european hp sites rely on it. so i guess it's being tested :) cool, so: why not go-ahead and commit it yourself? if you don't already have a CVS-Acoout it's now time to apply for one;-) re, tc cheers, Abdul - Original Message - From: Thies C. Arntzen [EMAIL PROTECTED] To: Abdul-Kareem Abo-Namous [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 9:10 AM Subject: Re: [PHP-DEV] OCI patch On Mon, Dec 02, 2002 at 02:27:12PM +0100, Abdul-Kareem Abo-Namous wrote: sure, here's thecode, diff'd against the latest cvs (from today). hope it's ok! sorry for beeing late. the line if (charset != \0) looks bogus to me... you probably meant if (*charset) or if (charset[ 0 ] != '\0')? besides that it looks OK to me. how well tested is that patch? if it really works for you i think we are save to commit it to HEAD onece the if thingie is fixed. re, tc oci8_charsets_oci8c.diff is for oci8.c oci8_charsets_configm4.diff for config.m4 and guess what oci8_charsets_phpoci8h.diff is for ;-))) cheers, Abdul - Original Message - From: Maxim Maletsky [EMAIL PROTECTED] To: Abdul-Kareem Abo-Namous [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 1:27 PM Subject: Re: [PHP-DEV] OCI patch Thies was on it. But, I think he is pretty busy right now. Resubmit it to me and I will look instead of him. Meanwhile, if Thies has time he will spare the light on the issue. -- Maxim Maletsky [EMAIL PROTECTED] Abdul-Kareem Abo-Namous [EMAIL PROTECTED] wrote... : hi everyone what happened to the patch i submitted? is it of such bad quality? ;-) maybe someone can tell me more..? :-) thanks, Abdul - Original Message - From: [EMAIL PROTECTED] To: MaximMaletsky [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 12:55 PM Subject: Re: Re: [PHP-DEV] OCI patch Ok, I've attached a pretty ok version. I had to update the config.m4 to inculde a HAVE_OCI9 define, but since I'm not really good in this kind of thing, buildconf now reports a warning autoheader: No template for symbol `HAVE_OCI9' don't know what to do about it. otherwise everything compiles and runs smoothly, so I hope you'll enjoy :-). Abdul Maxim Maletsky [EMAIL PROTECTED] schrieb am 17.10.02 12:45:57: OK, then. -- Maxim Maletsky [EMAIL PROTECTED] [EMAIL PROTECTED] wrote... : Thies, Maxim, if you could hang on for a few hours I'll be back with a few ideas and a cleaned up version of the patches + a switch for oracle 9+ to enable the new nls functions. Abdul -- -- --- oci8.c Wed Oct 9 16:55:16 2002 +++ oci8.c Thu Oct 17 13:32:09 2002 @@ -20,7 +20,7 @@ +--+ */ -/* $Id: oci8.c,v 1.176 2002/09/12 09:48:02 thies Exp $ */ +/* $Id: oci8.c,v 1.175 2002/08/20 07:26:50 edink Exp $ */ /* TODO list: * @@ -199,7 +199,7 @@ static oci_server *_oci_open_server(char *dbname,int persistent); static void _oci_close_server(oci_server *server); -static oci_session *_oci_open_session(oci_server* server,char *username,char *password,int persistent,int exclusive); +static oci_session *_oci_open_session(oci_server* server,char *username,char *password,int persistent,int exclusive,char *charset); static void _oci_close_session(oci_session *session); static sb4 oci_bind_in_callback(dvoid *, OCIBind *, ub4, ub4, dvoid **, ub4 *, ub1 *, dvoid **); @@ -451,7 +451,7 @@ OCI_DEFAULT, 0, NULL)); - + CALL_OCI(OCIHandleAlloc( OCI(pEnv), (dvoid **)OCI(pError), @@ -631,7 +631,7 @@ php_info_print_table_start(); php_info_print_table_row(2, OCI8 Support, enabled); - php_info_print_table_row(2, Revision, $Revision: 1.176 $); + php_info_print_table_row(2, Revision, $Revision: 1.175
Re: [PHP-DEV] OCISaveLob, OCILoadLob, OCISaveFile?
On Thu, Oct 31, 2002 at 08:18:12PM +0100, Jean Tardy wrote: Hello, Who know haw to use those functions:OCISaveLob, OCILoadLob, OCISaveFile? Where can I find documentation and sample about this general purpose: 'lob object manipulation with oracle Thanks. http://conf.php.net/slides/oci/paper.txt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] problem with EG(uninitialized_zval_ptr)
zee, andi - in threded mode we access (atleast) EG(uninitialized_zval_ptr) before it's initialized - BadIdea(tm) what happens is that (see assert.c as an example) OnChangeCallback gets called by the ini-mechanism before the executor is initialized. but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor anytime before init_executor will cause an UMR. i know that the startup-order is a very delicate thing so i'd like to check with you guys first if you have any ideas.. re, tc -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote: TCA but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks TCA against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor TCA anytime before init_executor will cause an UMR. Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...) games than just EG(uninitialized_zval_ptr). So I guess calling zval_ptr_dtor before init_executor is unwise indeed... yep - but can we simply move init_executor a bit up? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)
On Mon, Oct 28, 2002 at 05:49:44PM -0800, Zeev Suraski wrote: At 07:35 28/10/2002, Thies C. Arntzen wrote: On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote: TCA but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks TCA against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor TCA anytime before init_executor will cause an UMR. Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...) games than just EG(uninitialized_zval_ptr). So I guess calling zval_ptr_dtor before init_executor is unwise indeed... yep - but can we simply move init_executor a bit up? Probably not. Can you simply fix the OnChange callback? :) NULL up the ASSERTG(callback) on time? it is(!) nulled in the globals_ctor. the problem is that the OnChange gets called quite a few times (tested in cli-mode). and the 2nd call will dtor the empty value set by the 1st call. also i don't really think that assert.c is the deal here, the real problem is that we might use parts of the engine too early in many places in the code that i haven't spotted so far. (and it's a _very_ hard to find thing - i found it using valgrind) re, tc Zeev -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP and OCI8
On Wed, Oct 23, 2002 at 06:15:19PM +0200, Roderick Groesbeek wrote: Howdy People, Info: === I am witnessing problems with PHP, Apache and OCI8. We have profiles on our Oracle databases, so sessions get sniped if they hang on to long. what do you mean by hang on to long? you can always fiddle with your apache config to make sure you don't have too many inactive oracle-session (when using plogon). else simply don't use plogon. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] parse_url is not BC to 4.2.
HEAD doesnt do parse_url(file:/tmp/bla) any more. (you need to have 2 slahes after file: to make it work). i really think we should allow the single-slash syntax again! re, tc -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: OCI extension - OCIQuery() ?
On Thu, Oct 17, 2002 at 01:36:26PM +0200, Maxim Maletsky wrote: Thies C. Arntzen [EMAIL PROTECTED] wrote... : Hope to see someone to anser, commenting my thoughts on this. I am very much willing contributing to the PHP's Oracle support development. that always appreciated. wher do you want to start? tc Thies, what do you thik of adding an OCIQuery function? e.g: ?php $query = SELECT to_char(sysdate) FROM dual; // this: $stmt= OCIParse($conn, $query); $result = OCIExecute($stmt, OCI_DEFAULT); // can be this: $result = OCIQuery($conn, $query, OCI_DEFAULT); ? It could be a nice shortcut for those who use this combo always together and, plus, it would be a very elementary thing to implement. What do you think of it? I could start from this one, to warm up :) It's been I while I thought OCIQuery() could have been implemented. i don't really think it's a needed function as it won't support binding of variables and setting the execute mode. also writing: $s = ociparse($d, ...); ociexecute($s); is short enough for most things. also, cause you loose the statement handle you cannot reuse it. so adding ociquery will make things less optimal. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] parse_url still broken!
url:
file:/bla/test
4.2.x output:
array(2) {
[scheme]=
string(4) file
[path]=
string(9) /bla/test
}
HEAD:
array(3) {
[scheme]=
string(4) file
[host]=
string(3) bla
[path]=
string(5) /test
}
re,
tc
--
Thies C. Arntzen - Looking for all sorts of freelance work - just ask..
http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
On Tue, Oct 15, 2002 at 05:41:59PM +0200, [EMAIL PROTECTED] wrote: Thanks, Andi. yeah, I will wait for Thies to reply to me. We have sort of a started this discussion with him before, so hopefully he will join into this one. My main concerns about OCI8 are the followings ones. Some of them are related to the opverall idea of PHP-DB usage, some to the actual performance and some to the missing functionalities. Some, might be bogus or hardly accomplisheble. Here's what I think: 1. Datatype support. Right now, OCI8 only supports string and integer datatypes binded via PLSQL. It would be great being able to use all the remaining ones like booleans and dates, the other, incompatible onces might need to be translated into PHP's way so they can be used within PHP. Main problem of this is that, tipically, DBAs would grant the access via PLSQL (stored procedures) to a various number of clients, applications and langueages. Since, PHP does not funny support PLSQL, interfacing Oracle via PHP not having to change stored procedures is very limited. cool. how do you want to do this? php only has support for strings and numbers. so we would have to add PHP resources for all the other types. 2. XMLTYPE. This is new since Oracle 9.2. Will all the XML fever of today, wouldn't it be possible to add some extra compatibility for it to stipulate Oracle users using PHP? Always if this is dopable and logical. haven't really read the oracle-docs on that one. could you give me a doc-link for this? 3. Record type from Stored Procedures. (similar to #1) This is a VERY BIG limitation. It is, probably, the 50% of the reason why PHP is not used much with Oracle. Most programming languages can retrieve RECORD type from stored procs. and use it as arrays of data (like plain SQL records return). PHP fails on it, it only allows you to return the cursor, and for that you need to modify (descresing so performance) the stored procedures directly. At my work, (Italian Government) a datadase had over 500 stored procedures used via other programming languages. To migrate onto PHP, these all had to be changed and the backwards compatibility to the previous programming language was completely lost. It's a big issue. yep, agreed. even though i don't use it myself i think it would be great if we could support them. have you had a look at the collections stuff in oci8.c? 4. OCI8 module naming conventions. How come OCI module is named OCI8 (specifically)? I think this makes it hard for many to believe that it can fully be compatible with upcoming releases of Oracle. Lots of businesses count a lot on application life-times and, seeing '8' (or so would be with '9') makes management feel that they might not be able to upgrade their expensive Oracle licences till PHP comes up with some newer number on the extension name. Which, in our case means changing the whole extension and, I really don't think we would be doing that too often. I personaly would see Oracle extension better with one only generic name like OCI, ora, oracle or whatever but not version-labeled. This could also help us keeping the OCI8 intact while adding newer changes. the functions are all called oci_*(). the name of the extension is not really visible (unless you configure php). i don't see this as an issue at all,, but -sure- we could rename the extension. 5. Functions are called OCI .* I do well know what it refers to, but this is only because I learned the original oci.h API. Wouldn't itbe more standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions ect? OCI make it a bit confusing, I always heard from my co-workers. Besides, this can also be a great input for newer Oracle's updates. see #4. Here's one of the sample bugs that can be occuring while continuing the current OCI8 extension with Oracle 9 and so on... http://bugs.php.net/bug.php?id=18758 that one should be easy to fix - looking at it right now. Hope, Thies and the rest of Dev Group can comment on my thought, and try to think of a way improving PHP's Oracle support so we can start working on it. Btw, I do not have a karma for php4, so keep that in mind :) you have karma now. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: OCI extension help offer
On Wed, Oct 16, 2002 at 09:40:01AM +0900, Maxim Maletsky wrote: Sebastian Nohn [EMAIL PROTECTED] writes: 5. Functions are called OCI .* I do well know what it refers to, but this is only because I learned the original oci.h API. Wouldn't itbe more standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions ect? OCI make it a bit confusing, I always heard from my co-workers. Besides, this can also be a great input for newer Oracle's updates. This is mainly because there are Oracle-funktions and OCI-functions (there is a difference), and i like the OCI-thing very much, it's much easier and faster to type than oracle ;) Well, yes, OCI* functions look pretty geek, indeed, they are very similar (if not identic, in some its parts) to the actual OCI API. But, this naming convention is way not optimal, is limited functionality-wise and, last but not least, it is far not PHP's standard naming convention for the database extensions. In fact, if you'll look into PHP standards specifications (look in CVS: http://cvs.php.net/co.php/php4/CODING_STANDARDS?login=2r=1.23) you are encoraged using a certain style for calling your functions, especially those of databases since these mostly do the same things. What I meant was, while to access a mySQL database you use mysql_connect(), for PostgreSQL pg_connect() and for Sybase sybase_connect() question stays: why function to connect to Oracle be called OCILogon()? Wouldn't it be better called oracle_connect()? that is how som other programming languages call it. It is not an exaggeration to say that, some programmers are actually making their own functions named this very way so they can easier interact with the Oracle database using their mySQL's (or whatever) habbits because OCI gets them confused. I kind of followed this question within the PHP-Oracle developers I met. For now, we have ora_* and OCI* functions. These are, as long as I understand, used for Oracle v6.* and Oracle v8 (the last one is also 90% compatible with v9). Yet, this shouldn't mean that there is no need for a standarized set of functions like oracle_* with mapped/intuitive functionalities like most of the DBs PHP that supports AND as compatible between Oracle versions as possible. the ora_ extension uses the pre oracle8 api. if you need to compile with oracle7 libraries you have to use the ora_*() functions. if you have libs = oracle8 installed use the oci*() functions. they will allow you to connect to oracle servers running from version 7 till 9 (currently). the oci8 extension is btw 100% compatible with oracle9 - what do you mean by saying 90%? Only this way, one could firmly admit that PHP fully supports Oracle database. hmm, i really don't know what you are talking about. the PHP project (like all OpenSource projects i know of) does not formally certify itself for certyin 3rd party libraries and systems.. Those are my ideas for the Oracle extension. At this point, some new questions arised in my head: 1. Is ora_* extension (ext/oracle) still maintained and ported compatibility-wise to the versions Oracle newer v6 or, for these are OCI8 extensions? If so, then this should mean that ora_* functions are limited to version 6 only, if not deprecated at all. Am I correct, or missed the point? If I guessed, then what was the need for OCI8 extyension at all? Why ora_* could not be continued? I still haven't found it out. read above. 2. What costs merging the two extensions (ora_* and OCI8) in one (oracle_* ?) that fully supports both 6*, 8* and 9* versions of Oracle and remains the only one to be used (as well as maintained, debugged) in the feature? that would make no sense whatsoever, oci* has all that ora* has, we could drop he oracle extension, but then we'd make all the ppls unhappy that use it. (and may depend on it: see above) 3. Still, related to question 2: Wouldn't it be safe enough, if not rather strategically clever to introuduce the oracle_* new functions as a new unified extension for Oracle in all its versions within PHP 5? Considering, that we are still at the planning stage of its development release? you mean renaming the oci8 extension - could be done... but i personally see no pressing reason for doing so. Hope to see someone to anser, commenting my thoughts on this. I am very much willing contributing to the PHP's Oracle support development. that always appreciated. wher do you want to start? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] OCI extension help offer
On Wed, Oct 16, 2002 at 10:22:04AM +0200, [EMAIL PROTECTED] wrote: I'm sure glad this in the headlines again ;-) As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session environment (- as a global one). Oracle 9i offers some functions which help out from this dilemma, and I have changed the existing oci ext to support them. The most important change (from a user's viewpoint) is that OCILogon has an optional forth parameter, the character set, so an connection looks like this: OCILogon($user,$pass,$tnsname,WE8ISO8859P1); Ok, I know this isn't ideal, since OCILogon already has an optional parameter, but maybe people can set $tnsname to false if they want to use the default one (ORACLE_SID) and use a specific character set? Anyway, my code works, and is already being used in a relativly big production environment. From a developers viewpoint what I mainly did was follow Thies' proposal and put the environment struct in the session struct, and use the global env only for init work. Then I decode the character set parameter (if it is omitted, the NLS_LANG setting or Oracle default will be used) and use it in open_session. Voila, Oracle takes care of the rest. Works better than I thought :-). The only thing I need to do now is to add a compile-time decision on whether Ora9i libraries are found or not, and then to make this functionality available depending on the version. If anyone's interested I can send a patch.. As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and 2. there is absolutely zero effectiveness in merging the ora_ and OCI extensions, which differ greatly, into one. I think that would result in a mess or a big rewrite.. i'd love to see that patch integrated! can you send it to me? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
On Wed, Oct 16, 2002 at 11:24:24AM +0200, Maxim Maletsky wrote: any OCIParse and set the charset. This would be: 1. more flexible 2. would exclude non-authentication functionality with OCILogon 3. easier to find for a user adding the charset to the logon call is how the others do it. we could make the oracle env-handle visible to userspace, but that would make using the beast more complex. adding it to the parse state makes little sense. as this is not where it's done inside oracle. Wouldn't it be better, though? Yes, perhaps it would be a big rewrite, but it would definitely create an actual Oracle extension, not two version-specific ones. Really, it is confusing. Try imagine a similar situation: Whoever pays Oracle license is planning something big and costly. A such user would have no much trouble paying also for Java or ASP, that support Oracle pretty well, but, should the corp. prefer PHP, they'd consider this more than once. This is because they would be soon confused about how things are working between PHP and Oracle, what Oracle versions are supported and for how long... Then, automatically (in some heads) answer arises: Yeah, PHP is Open Source, it won't support well commercial third parties That is why I think that unifying Oracle into something that looks and works just as other Open Source DBs can help PHP (5?) gain better trust and confidence from middle-large projects worldwide. we are talking about a legacy, more-or-less unsupported version of oracle here (Oracle7 is no longer supported IIRC). wasting any brain cyles for that will not bring us forward. i'd love to see ext/oracle in PECL and slowly fade out. everything else is not really an option INHO. oci8 is the way to go - re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
On Wed, Oct 16, 2002 at 03:15:36PM +0200, Maxim Maletsky wrote: [EMAIL PROTECTED] wrote... : [EMAIL PROTECTED] schrieb am 16.10.02 14:27:35: I think, at this point, it is up to Thies to review the patch. I hope he's not too harsh on it ;-), since this code is certainly *not* ready for merging into the cvs tree. Meaning: it merges perfectly, but doesn't compile correctly on Oracle 8i systems, only on 9i - as I said, this is still on my TODO list. Then, it should remain a patch and not a part of the distribution. Unless, it can compile safely with Oracle 8. Still, up to Thies. lets review it first - i'm sure we can find a way of adding it to CVS. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: Re: [PHP-DEV] OCI extension help offer
On Wed, Oct 16, 2002 at 10:26:46AM +0200, [EMAIL PROTECTED] wrote: Oh, and just to be clear about it: I am absolutely positive on a completely new (perhaps unified) extension for PHP 5, and would gladly participate. hmm, sure - why not. we could start to brainstoorm about that and decide if we need to rewrite or just add to what's there. what are your plans, what features do you want to see? i have things like failover and connection pooling (for threaded servers) that i'd like to see in the future. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
On Tue, Oct 15, 2002 at 01:51:29PM +0200, Maxim Maletsky wrote: Guys, a few month ago, I have been trying to offer some of my help for developing Oracle 9i extension, or in anyway, to improve the existing PHP/Oracle functionality. original posts are here: http://groups.google.com/groups?hl=enlr=ie=UTF-8threadm=aiquvp%2412e7%241%40FreeBSD.csie.NCTU.edu.twrnum=120prev=/groups%3Fq%3DOCI8%2Bgroup:mailing.www.php-dev%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd%26start%3D110%26sa%3DN) Having put onto the real-life test OCI8 extensions for the Italian Government framework, I noticed many serious imperfections with the current OCI8 extension. I personally think that Oracle is very important for PHP's future, and that current extension is not very perfect and up to date. Please let me know if you are interested in my contributions regarding it. very cool, what do you want to contribute? re, tc -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature ./ correction to design flaw request
On Thu, Oct 10, 2002 at 09:52:50PM +0100, Nick Lindridge wrote: Hello, Although most globals are correctly handled in PHP for thread safety, the zend_execute and zend_compile_file hooks are not given slots in any TS memory. It would be beneficial to correctly give these globals TS slots. why would one want to have different executors/compilers in different threads? i can see that there might be a race if an extension sets/changes zend_execute and/or zend_compile_file while another thread is serving pages. is that your problem? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php/embed (build system changes)
On Tue, Oct 01, 2002 at 10:38:54PM +0200, Sascha Schumann wrote: On Tue, 1 Oct 2002, Andrei Zmievski wrote: On Tue, 01 Oct 2002, Sascha Schumann wrote: Fortunately, I have some spare time and look forward to purge some of the cruft which has assembled since the CLI support was added. By extending the problem domain, we can simplify and abstract a number of cases in the build system. That will be a lot of fun. Does this mean that you want to delay 4.3.0? Nope, this is 4.3.1 material. you mean 4.4? our new rules says to merge only fixes into a release branch. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PREAD yet again
On Thu, Sep 19, 2002 at 08:30:06AM -0400, Dan Kalowsky wrote: Hello list, In PHP 4.2.3 I removed the PREAD functionality from the session module due to a bug in the glibc libraries on non-x86 machines. In CVS HEAD Sascha has re-added it using some tests. Unfortunately it seems that these tests don't seem to work well, and still cause the session module not to work. what arch? i'm all for fixing this as using the p*() functions is slighly faster. which is a GoodThing(tm) tc If this isn't fixed before the 4.3 RC process I'd like to ask that this be removed once again until it can be further tested. --- Dan KalowskyTonight I think I'll walk alone, http://www.deadmime.org/~dankI'll find myself as I go home [EMAIL PROTECTED]- Temptation, [EMAIL PROTECTED] New Order -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. Whishlist: http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] #18640: compilation with Oracle fails on Tru64
On Mon, Sep 09, 2002 at 07:46:00PM +0200, Sebastian Nohn wrote: -Original Message- From: Michael Mauch [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 6:52 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] [PATCH] #18640: compilation with Oracle fails on Tru64 Can somebody please add this? If this is not the right way to send a patch, please tell me. +1 on adding this to cvs. Thies, what's your opinion on this one? go ahead - if you have the karma, else ask again and i'll commit. tc -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. Whishlist: http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 11:48:03PM +0300, Andi Gutmans wrote: At 07:50 PM 8/18/2002 +0200, Thies C. Arntzen wrote: On Sun, Aug 18, 2002 at 10:29:47AM -0700, Rasmus Lerdorf wrote: I don't think we should stop people from tweaking ZE1. ZE2 is probably more than a year away from realistically being available to a lot of people. It takes a while for people to upgrade, and many will skip the .0 release. If a few tweaks to ZE1 can eliminate peoples' motivation to move to ZE2, then why are you writing ZE2? I obviously don't think that is the case as ZE2 has a number of features people have been asking for. i (of course) agree with derick and rasmus. i'm all for applying the patch as is. if zeev and andi don't want to comment on it for their own reasons i cannot help them. if the patch has a problem it'll be found very soon and it'll be fixed. This isn't a conspiracy but I just completely forgot about your Email. Obviously if it is decided that this patch goes into Engine 1 I will look it over. The last thing I'd do was to allow a buggy patch to enter the Engine. andi, i'd love if you could comment on the commenting out line 1626 in the unpatched zend_execute which is needed to have a correct backtrace in some situations. EX(object).ptr will always be correctly reinitialized around line 1662 in the unpatched zend_execute so i believe line 1626 in unneded. if there is any *technical* reason why this patch is not as good as the debug_backtrace that is in ZE2 - let me know. otherwise i'll commit on monday. I don't think that there are any big technical reasons not to include the patch although it might be a bit buggy though as it hasn't been tested very extensively. i fully agree. I do think you guys should consider the psychological aspects of starting to back port my patches from Engine 2. as said in am the course of discussion, debug_backtrace is (so far) the only thing really worth backporting from ZE2 as it's a small piece of code that really makes live easier for script-developers. I personally think that the ZE2 is essential for PHP to prosper in the next few years. The only way it can be pushed is if not only Zeev and I but other people in the community help push it too. It was mentioned that there are a couple of things still missing. I can sum it up that the two main features which are missing are some inheritence problems with nested classes, private methods and a delegation mechanism which was discussed on engine2 for which came up with a pretty decent way of doing which stays with the PHP spirit. These things will be implemented and there is no reason to wait until they are fully implemented in order to start pushing things a bit more. I started with a couple of alpha's and I definitely want to go for another one soon as I fixed some bugs. In the same way we didn't back port some ideas from PHP 4 to PHP 3 I think it's best not to do it now. Because in the end, once we (php-dev) transitions to ZE2 our support will naturally start shifting more and more towards the latest versions (the same as it did in the PHP 3 - PHP 4 transition). After sometime people on php-dev just won't feel like working on old stuff anymore. Therefore, I think we should make the benefit of transition to ZE2 as great as possible so that people migrate. As to the comparison to Apache 2 I think you're far off. The PHP 3 - PHP 4 transition was much smoother than that and the ZE1 - ZE2 transition isn't even between rewrites but just improvements over the old stable version. Once a significant amount of people use it I think it'll take 2-3 months to iron out the bugs. remember, we are not talking about a backport of real new functionality, nor a new language feature. we're talking about adding a very useful feature for developers. my apache 2.0 thing got misinterpreted a bit - let me clearify: apache2.0 is ready, it works and it's even better than 1.3 (the httpd itself). but ppls don't upgrade all threir servers immediatly. as rasmus mentioned, the same thing will happen once PHP5 comes out. it won't be widely used and available to everybody the day it comes out. as for debug_backtrace() (an _only_ debug_backtrace()) i think this is such a cool thing to have and i whished i had it when there was PHP3. i do write large applications, and it's sometimes very hard to find out, what's going on. c'mon how often do you type bt in gdb? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Mon, Aug 19, 2002 at 11:45:30AM +0300, Zeev Suraski wrote: How often do you call a function that gives you your current backtrace in C? In my many years of C experience, I would have to say that the accurate answer is -0- times. You really should compare apples with apples... you often said in the past that you don't write php-apps, you write php. i do write php-apps, and debug_backtrace() is one of the most useful features if your app reaches an unexpected failure (= likely a bug). right now i load some zend-extension on my devel boxes - but (as you know), the unexpected often only happens on productions systems. my production systems are soo loaded that i cannot afford to load the zend-extension on there. so post-mortem analysis is much harder there, and you know how hard it sometimes is to reporduce bugs (remember how often i spend hours just to sent you guys the shortest-possible testcase for bugs?) but - in a way you are right, i'm comparing apples and pies. the debug_backtrace() for me is like calling abort() in my c-code to be able to inspect the core-file and see where things went wrong. anyway, i don't thing we are discussing the usefullness of debug_backtrace() here. i think andi will look over the one critical line of the patch - if he agrees that this change is ok, i will go ahead and commit. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
there is one tiny change that might destabelize the ZE1 - i
asked if you could take a look and see if you agree with
me that this change is actually *not* harmful.
i don't really see your point that having debug_backtrace
only available in ZE2 will bring more momentum to the ZE2
development. and not wanting a new (and btw very useful
feature) in ZE1 for that very reason is not good IMHO.
zeev, andi - have you had a *look* at the patch and do you see
any good reason not to have it in 4.3? i do not buy you lets
only bring ZE2 forward argument at all.
i'd love to hear more opinions on this.
tc
On Sun, Aug 18, 2002 at 06:40:35PM +0300, Andi Gutmans wrote:
I also think we should make sure enough people have motivation to move to
ZE2. If not it'll be hard to push it out and we all know that it's a very
important step for PHP. As it is, there is still not enough momentum behind
it.
Andi
At 05:38 PM 8/18/2002 +0300, Zeev Suraski wrote:
I said before - I prefer not having any changes in ZE1, for both stability
reasons and also as a motivation to get ZE2 out the door more quickly.
Zeev
At 17:21 18/08/2002, Thies C. Arntzen wrote:
if noone objects i'm going to commit this to -HEAD (and we
can start discussing it then;-)
re,
tc
On Fri, Aug 16, 2002 at 07:39:59PM +0200, Thies C. Arntzen wrote:
hi,
this patch adds the extremely useful debug_backtrace()
function to ZE1. as it's more-or-less the same
implementation as in ZE2 so it should be fast and efficient
enough for inclusion in 4.3 IMHO.
it has one extra feature over the ZE2 implementation by
giving some extra information if a method was called
using :: or - (see the 'type' attribute in the array
returned by debug_backtrace).
zeev, andi one question: i had to comment line 1628 (just
apply the patch and see for yourself) to make the following
code work correctly (= show the class in the backtrace):
?php
class a {
function dump() {
var_dump(debug_backtrace());
}
}
$a = new a;
$a-dump();
?
(just uncomment line 1628 in the patched sources and see how
the output of debug_backtrace doesn't show the class-name for
this script any more)
i don't think that commenting this line will have any
side-effect as EG(object).ptr will be re-initialized in 1665
and i don't see any references to it in between.
i'd love to have this included in 4.3.0 and i think a lot of
people would be happy as well.
implementation:
to make this whole thing work i simply added the class_entry
to the execute_data and am pushing and popping it together
with (object).ptr.
if this patch gets accepted i'll add an php.ini seting so
that errors and warnings will optionally have the full
call-stack.
comments are welcome - especially from andi zeev.
tc
PS: patch is against -HEAD
--
Thies C. Arnzten - Looking for all sorts of freelance
work - just ask..
Whishlist:
http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ/ref=wl_em_to
? ext/tca_prof
Index: Zend/zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.118
diff -u -r1.118 zend_builtin_functions.c
--- Zend/zend_builtin_functions.c 12 Jun 2002 17:02:22
- 1.118
+++ Zend/zend_builtin_functions.c 16 Aug 2002 17:22:01 -
-65,6 +65,7
static ZEND_FUNCTION(extension_loaded);
static ZEND_FUNCTION(get_extension_funcs);
static ZEND_FUNCTION(get_defined_constants);
+static ZEND_FUNCTION(debug_backtrace);
#if ZEND_DEBUG
static ZEND_FUNCTION(zend_test_func);
#endif
-116,6 +117,7
ZEND_FE(extension_loaded, NULL)
ZEND_FE(get_extension_funcs,NULL)
ZEND_FE(get_defined_constants, NULL)
+ ZEND_FE(debug_backtrace,NULL)
#if ZEND_DEBUG
ZEND_FE(zend_test_func, NULL)
#endif
-1133,6 +1135,69
array_init(return_value);
zend_hash_apply_with_argument(EG(zend_constants),
(apply_func_arg_t) add_constant_info, return_value TSRMLS_CC);
}
+
+/* {{{ proto void debug_backtrace(void)
+ Prints out a backtrace */
+ZEND_FUNCTION(debug_backtrace)
+{
+ zend_execute_data *ptr;
+ int lineno;
+ char *function_name;
+ char *filename;
+ char *class_name;
+ zend_uint class_name_length;
+ zval *stack_frame;
+
+ ptr = EG(execute_data_ptr);
+
+ /* Skip debug_backtrace() itself */
+ ptr = ptr-prev_execute_data;
+
+ array_init(return_value);
+
+ while (ptr) {
+ MAKE_STD_ZVAL(stack_frame);
+ array_init
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 08:19:52PM +0300, Zeev Suraski wrote: I haven't, because of the two reasons I mentioned. There's nothing about the specifics of the patch that can make me change my personal mind about it... I understand you disagree with me about the momentum issue, so let's agree to disagree. so you're saying we effectifly stop working on improvements for ZE1? not sure if too many ppls will be happy to hear that whitout even having a clear roadmap for ZE2.. please reconsider... tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 10:29:47AM -0700, Rasmus Lerdorf wrote: I don't think we should stop people from tweaking ZE1. ZE2 is probably more than a year away from realistically being available to a lot of people. It takes a while for people to upgrade, and many will skip the .0 release. If a few tweaks to ZE1 can eliminate peoples' motivation to move to ZE2, then why are you writing ZE2? I obviously don't think that is the case as ZE2 has a number of features people have been asking for. i (of course) agree with derick and rasmus. i'm all for applying the patch as is. if zeev and andi don't want to comment on it for their own reasons i cannot help them. if the patch has a problem it'll be found very soon and it'll be fixed. if there is any *technical* reason why this patch is not as good as the debug_backtrace that is in ZE2 - let me know. otherwise i'll commit on monday. re, tc -Rasmus On Sun, 18 Aug 2002, Zeev Suraski wrote: I haven't, because of the two reasons I mentioned. There's nothing about the specifics of the patch that can make me change my personal mind about it... I understand you disagree with me about the momentum issue, so let's agree to disagree. Zeev At 20:12 18/08/2002, Thies C. Arntzen wrote: there is one tiny change that might destabelize the ZE1 - i asked if you could take a look and see if you agree with me that this change is actually *not* harmful. i don't really see your point that having debug_backtrace only available in ZE2 will bring more momentum to the ZE2 development. and not wanting a new (and btw very useful feature) in ZE1 for that very reason is not good IMHO. zeev, andi - have you had a *look* at the patch and do you see any good reason not to have it in 4.3? i do not buy you lets only bring ZE2 forward argument at all. i'd love to hear more opinions on this. tc On Sun, Aug 18, 2002 at 06:40:35PM +0300, Andi Gutmans wrote: I also think we should make sure enough people have motivation to move to ZE2. If not it'll be hard to push it out and we all know that it's a very important step for PHP. As it is, there is still not enough momentum behind it. Andi At 05:38 PM 8/18/2002 +0300, Zeev Suraski wrote: I said before - I prefer not having any changes in ZE1, for both stability reasons and also as a motivation to get ZE2 out the door more quickly. Zeev At 17:21 18/08/2002, Thies C. Arntzen wrote: if noone objects i'm going to commit this to -HEAD (and we can start discussing it then;-) re, tc snip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 08:49:30PM +0300, Zeev Suraski wrote: At 20:40 18/08/2002, [EMAIL PROTECTED] wrote: I'm not happy with that indeed. ZE1 is still the current version, and I wouldn't see any reason to not extend it (or even backport things from ZE2 as this patch is largely about). Why not backport all the changes then? I'm -1 on introducing any new features in ZE1. I think Andi is too. If everyone votes against us, you know, there are other people with commit access, but it's a bit of a slap in the face, especially considering this is Andi's code in the first place. we _want_ to work together, right? atleast i want that. i have pulled my hair many times for having a real-backtrace on a production-site _without_ having to load an extension that makes the whole site ~10% slower (sorry, derick) you are slapping into the users face by saying, wait another 6 month for something that could be available as soon as 4.3. BTW: the code we're talking about is neither magic nor very complex. andi, sorry i you felt me stepping on your feet;-) zeev, this discussion should be pure technical, any political or personal things should be left off! tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 08:50:04PM +0300, Zeev Suraski wrote: At 20:24 18/08/2002, Thies C. Arntzen wrote: On Sun, Aug 18, 2002 at 08:19:52PM +0300, Zeev Suraski wrote: I haven't, because of the two reasons I mentioned. There's nothing about the specifics of the patch that can make me change my personal mind about it... I understand you disagree with me about the momentum issue, so let's agree to disagree. so you're saying we effectifly stop working on improvements for ZE1? Yep. so - cool, you (za) stopped working on it. does that mean it's now written in stone and nobody is allowed to touch it? i have asked very nicely if you could review a patch i've written. i have cc'ed you and andi as you are the authors of the engine. - no reply - the reply i got after pinging again had _no_ technical background whatsoever. i have asked on php-dev and not php-tellmeyoufeelingsaboutthefuture. this is more than a little frustrating for me and i'm sure not too many ppls will be happy about your desupport notice for ZE1. not sure if too many ppls will be happy to hear that whitout even having a clear roadmap for ZE2.. We have a pretty clear roadmap for ZE2 AFAIK. We're currently lingering for no good reason. apache 2.0 - does that ring a bell? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 09:00:25PM +0300, Zeev Suraski wrote: At 20:54 18/08/2002, Thies C. Arntzen wrote: BTW: the code we're talking about is neither magic nor very complex. andi, sorry i you felt me stepping on your feet;-) And yet you took it from ZE2 a couple of months after it was written, as opposed to two years ago when ZE1 was already out? Come on, Thies, sometimes knowing which algorithm to use and where to put the two lines of code is the complexity, as it is in this case. i am working on a zend-extension that needs to know the real current backtrace. you wrote the ze-extension interface, and you should know that it's *very*, *very* hard to find the real callstack from within an extension (all extensions i'm aware of have do it wrong). after fiddling with it for a while i looked at the stuff andi did and found that it can be apllied mostly (there _is_ one difference) to ZE1, what's wrong with that? do i want credits for it? NO. do i think this feature will help me and others? YES. zeev, this discussion should be pure technical, any political or personal things should be left off! I have two reasons, one technical (stability) and one which you may call political (ZE2). I don't see anything wrong with taking 'political' reasons into account. PHP is a big thing today, we can't treat it in the same way that we treated it five years ago. you told me that you didn't even look into the patch. so -no- you have no technical reason except if you think i'm stupid. your political reason has no standing in my opinion. Replying to Rasmus' concern - of course we're not afraid that this tiny patch will 'eliminate' the motivation of people to move. It's the state of mind of php-dev that I'm afraid of. Much like your perception is that we're more than a year away from a usable version, and Thies's perception that we have no roadmap for ZE2 - you can only imagine what other, less core developers have in mind. We need to get going with ZE2, and yes, holding on and keeping goodies for the new version are a way of doing ^^ you can do that in closed-source, commercial software. trying to do that in opensource will drive people away from you... it. I did that in lots of features in PHP 4, and frankly, I think it's very lucky that I did, as the transition from PHP 3 to 4 was VERY successful. Imagine if we still had to fix PHP 3 bugs on a daily basis. i do remember countless hours that i put into the transition from PHP 3 to PHP 4 during that time i became a member of the PHP Group - but what has that to do with debug_backtrace()? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 08:18:40PM +0200, [EMAIL PROTECTED] wrote: On Sun, 18 Aug 2002, Thies C. Arntzen wrote: we _want_ to work together, right? atleast i want that. i have pulled my hair many times for having a real-backtrace on a production-site _without_ having to load an extension that makes the whole site ~10% slower (sorry, derick) It was not written with speed in mind, so I think it's pretty good that it's only 10% slower :) it can't be much faster - i've beed down that path. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 01:06:47PM -0500, Richard Thomas wrote: Zeev makes a very very good point here.. What is the point of backporting everything into 4.3, There is no real point. PHP needs to move forward with new and improved.. Not spending its time going no where, and trying to improve on going no where. richard, you are missing the point here, the time is already spent. it has been backported. why not accept the patch? With ZE2 being the current goal the only thing that should go into ZE1 would be security/bug's that require fixing.. The only goal for ZE1 should be keeping it stable/safe.. Not making it better. i disagree. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
On Sun, Aug 18, 2002 at 09:26:45PM +0300, Zeev Suraski wrote:
At 21:15 18/08/2002, Thies C. Arntzen wrote:
On Sun, Aug 18, 2002 at 09:00:25PM +0300, Zeev Suraski wrote:
At 20:54 18/08/2002, Thies C. Arntzen wrote:
BTW: the code we're talking about is neither magic nor very
complex. andi, sorry i you felt me stepping on your feet;-)
And yet you took it from ZE2 a couple of months after it was written, as
opposed to two years ago when ZE1 was already out? Come on, Thies,
sometimes knowing which algorithm to use and where to put the two lines
of
code is the complexity, as it is in this case.
i am working on a zend-extension that needs to know the real
current backtrace. you wrote the ze-extension interface, and
you should know that it's *very*, *very* hard to find the
real callstack from within an extension (all extensions i'm
aware of have do it wrong).
It may sound like a product pitch but it really isn't - did you take a look
at the way the Zend Studio displays stack traces? AFAIK, it's absolutely
accurate, and it doesn't do any magic. I'm not aware of any problems
getting the stack trace right with the extension interface. I can even
help you with that.
look at the opcodes for:
a(b(c()));
function a() {}
function b() {}
function c() {}
and tell me which function is called from which scope. unless
you know something i dont youll see
a()
b()
c()
which is wrong as the correct call-order is
c()
b()
a()
after fiddling with it for a while i looked at the stuff andi
did and found that it can be apllied mostly (there _is_ one
difference) to ZE1, what's wrong with that? do i want credits
for it? NO. do i think this feature will help me and others?
YES.
I didn't think you wanted credit for it, that's obviously not the
issue. The two issues I did mention, coupled with the fact that Andi is
the one who wrote the code in the first place, are the issue, IMHO.
you told me that you didn't even look into the patch. so -no-
you have no technical reason except if you think i'm stupid.
Uhm no. Touching a delicate portion of execute() is dangerous no matter
what. If it's for adding a new feature, then in my humble opinion, it is
not worth it at this point.
we have soo many ppls currently working again on -HEAD and
we'll have a full QA cycle before 4.3. i don't think this
feature will cost us anything that can't be paid for with a
single dime.
your political reason has no standing in my opinion.
To each his own.
^^ you can do that in
closed-source, commercial software. trying to do that in
opensource will drive people away from you...
As it did with PHP 4? Commercial software and opensource software have
lots of things in common, and encouraging people to migrate to the newest
version is one of those things. If you don't, you get into a support
nightmare. It's as simple as that.
it. I did that in lots of features in PHP 4, and frankly, I think it's
very lucky that I did, as the transition from PHP 3 to 4 was VERY
successful. Imagine if we still had to fix PHP 3 bugs on a daily basis.
i do remember countless hours that i put into the transition
from PHP 3 to PHP 4 during that time i became a member of the
PHP Group - but what has that to do with debug_backtrace()?
Nothing specific, it has to do with new features. I added lots of new
features that could be backported to PHP 3, when PHP 3 was a hell of a lot
more popular than 4, when 4 was really just a beta. Forget my code. The
session module could be ported back to PHP 3 with almost no changes, why
wasn't it done? And you know, session functionality is something useful to
literally everyone, and is much more important than a backtrace.
you're comparing bytes and apples here. PHP4 and PHP3 were
sooo different. and i recall that you have backported the new
memory zend memory-manager to php3, didn't you?
If you want it so much and need it so much and are so furious about it,
then whatever, backport it. Let it be noted that I firmly object, and that
Andi objected as well (not sure how firmly :) Let it be also noted that I
will firmly object to further backports of new features in the future.
i think this might be the only feature that justifies
backporting as:
a) the backport is minimal (and already done)
b) the feature is very useful for anyone that develops with
php (which is our primary audience)
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] make test broken?
if i do make test i get: = CWD : /home/thies/devel/cgi PHP : /home/thies/devel/cgi/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.0-dev PHP_OS : Linux INI actual : INI wanted : = TIME START 2002-08-03 13:51:15 = No tests were run. and no tests are run - ist that intended? how do i run the testsuite now? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] oci8 extension
On Thu, Aug 01, 2002 at 12:59:31PM +0200, Abdul-Kareem Abo-Namous wrote: hi everyone i'm new to this list so please be patient with me (but not too patient ;-)). i am currently a contractor for a pretty big it company that is migrating all its php sites to oracle 9i. since we ran into some large problems related to character sets and the way the oci library handles enviroment setup in a shared environment, we have agreed to write new functions that expose new functionality in oracle's oci in php. we're talking about a mere 2 new functions that can't be used in oracle 8's oci. now my questions are: -should i fork the oci8 extension into a new one (oci9 or so) that includes these functions and all other (older) functions with modified names, and submit it as a new extension, or no. -just submit a patch for ext/oci8 that adds these two functions and add a switch that turns them on or off depending on what oci lib version was found during a build process? yes. furtheron, is there anyone out there already working on an oci9 extension? anyway, thanks for reading. if there's any interest, i can shed some light on a few details of the problems forcing us to do this. there is no oci9 AFAIK the interface is called OCI and was introduced with oracle8. as were just talking about adding some calls (is it that easy?) there is no reason to fork. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] oci8 extension
On Fri, Aug 02, 2002 at 11:21:10AM +0200, Abdul-Kareem Abo-Namous wrote: thanks thies i was expecting this answer and i'm glad you see it this way, too. there is no oci9 AFAIK the interface is called OCI and was introduced with oracle8. as were just talking about adding some calls (is it that easy?) there is no reason to fork. i *hope* it's easy. i am just going to add the two needed calls and submit a patch, pretty straight forward. btw i only called it oci9 to emphasize that we are using oci functions that are only available in the oci that ships with oracle 9. just send the patch once it's ready! re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HANDLE_BLOCK_INTERRUPTIONS
On Thu, Aug 01, 2002 at 10:10:10AM -0700, Brad LaFountain wrote: HANDLE_BLOCK_INTERRUPTIONS(); HANDLE_UNBLOCK_INTERRUPTIONS(); what exactly does these do? this is an apache thingie. you can tell apache that you don't want to be killed during certain operations. i doubt very mucht that it really helps;-) look in the apache sapi module. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File Descriptors
On Tue, Jul 02, 2002 at 02:17:38PM -0600, B i g D o g wrote: Does PHP only use file descriptors when opening files or does it use it for other things that are underlining? no - excep for file bases sessions. B i g D o g Thies C. Arntzen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Tue, Jul 02, 2002 at 01:04:03PM -0600, B i g D o g wrote: I have searched the archives and all over google and php.net; however, i can not find an answer to this question: When running a php script that opens a file descriptor (implicit and not) does the file descriptor get closed automatically when the script terminates? if you use php functions like fopen() - yes. (unless you found a bug). tc -- 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 /ext/session session.c
On Fri, May 03, 2002 at 10:21:44AM +0200, Sebastian Bergmann wrote: Sebastian Bergmann wrote: sebastian Fri May 3 04:10:49 2002 EDT Modified files: /php4/ext/session session.c Log: Fix ZTS build. This fixes the ZTS build not completely, I get some errors in the .re file(s) as well, but I don't dare touching there, so ... :-) checking... -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new patch to session.c some new API
hi,
here's the new version of the patch that exposes the
URL-Rewriter (what a cool piece of software) script and
C-Space via an api:
from PHP:
output_add_rewrite_var($varname, $value);
output_remove_rewrite_var($varname);
add/remove a var from an internal list of all vars that
should be transparently rewritten in the HTML output.
from C:
int php_url_scanner_add_var(char *name, int name_len, char *value, int value_len
TSRMLS_DC);
int php_url_scanner_remove_var(char *name, int name_len TSRMLS_DC);
the value will be automatically ULR-Encoded for you!
the session module has been adjusted to use the new API,
which simplyfies it a bit (no longer need to fiddle with the
output-system)
so the guts of this patch is to make the URL-Rewriter
usable by more than just the session-module! (which i really
need)
comments?
tc
sample-code:
?php
output_add_rewrite_var(a, pallo);
output_add_rewrite_var(b, ichdu und der \rest\);
session_start();
?
a href=/hallo.phphallo/a
forminput type=text/form
?php
ob_flush();
session_destroy();
output_remove_rewrite_var(a);
?
a href=/hallo.phphallo/a
forminput type=text/form
output: (reformatted for readablity)
a
href=/hallo.php?a=pallob=ich%26du+und+der+%3E+%22rest%22PHPSESSID=b55ee1d3161a5cb966d89ef336415ffchallo/a
form
input type=hidden name=a value=pallo /
input type=hidden name=b value=ich%26du+und+der+%3E+%22rest%22 /
input type=hidden name=PHPSESSID value=b55ee1d3161a5cb966d89ef336415ffc /
input type=texti
/form
a href=/hallo.php?b=ich%26du+und+der+%3E+%22rest%22hallo/a
form
input type=hidden name=b value=ich%26du+und+der+%3E+%22rest%22 /
input type=text
/form
Index: ext/session/php_session.h
===
RCS file: /repository/php4/ext/session/php_session.h,v
retrieving revision 1.77
diff -u -r1.77 php_session.h
--- ext/session/php_session.h 28 Apr 2002 11:45:45 - 1.77
+++ ext/session/php_session.h 1 May 2002 17:15:20 -
-115,7 +115,6
zend_bool use_cookies;
zend_bool use_trans_sid;/* contains the INI value of whether to use
trans-sid */
zend_bool apply_trans_sid; /* whether or not to enable trans-sid for the
current request */
- zend_bool output_handler_registered;
} php_ps_globals;
typedef php_ps_globals zend_ps_globals;
-171,8 +170,6
#define PS_SERIALIZER_ENTRY(x) \
{ #x, PS_SERIALIZER_ENCODE_NAME(x), PS_SERIALIZER_DECODE_NAME(x) }
-
-PHPAPI void session_adapt_url(const char *, size_t, char **, size_t * TSRMLS_DC);
void php_set_session_var(char *name, size_t namelen, zval *state_val,
php_unserialize_data_t *var_hash TSRMLS_DC);
int php_get_session_var(char *name, size_t namelen, zval ***state_var TSRMLS_DC);
Index: ext/session/session.c
===
RCS file: /repository/php4/ext/session/session.c,v
retrieving revision 1.299
diff -u -r1.299 session.c
--- ext/session/session.c 28 Apr 2002 11:45:45 - 1.299
+++ ext/session/session.c 1 May 2002 17:15:20 -
-79,34 +79,6
static ps_module *_php_find_ps_module(char *name TSRMLS_DC);
static const ps_serializer *_php_find_ps_serializer(char *name TSRMLS_DC);
-static void php_session_end_output_handler(TSRMLS_D);
-
-static void php_session_output_handler(char *output, uint output_len, char
**handled_output, uint *handled_output_len, int mode TSRMLS_DC)
-{
- if ((PS(session_status) == php_session_active)) {
- *handled_output = url_adapt_ext_ex(output, output_len,
PS(session_name), PS(id), handled_output_len, (zend_bool) (modePHP_OUTPUT_HANDLER_END
? 1 : 0) TSRMLS_CC);
- } else {
- *handled_output = NULL;
- }
-}
-
-
-static void php_session_start_output_handler(uint chunk_size TSRMLS_DC)
-{
- php_url_scanner_activate(TSRMLS_C);
- php_url_scanner_ex_activate(TSRMLS_C);
- php_start_ob_buffer(NULL, chunk_size, 1 TSRMLS_CC);
- php_ob_set_internal_handler(php_session_output_handler, chunk_size, trans sid
session, 1 TSRMLS_CC);
- PS(output_handler_registered) = 1;
-}
-
-
-static void php_session_end_output_handler(TSRMLS_D)
-{
- php_url_scanner_ex_deactivate(TSRMLS_C);
- php_url_scanner_deactivate(TSRMLS_C);
-}
-
static PHP_INI_MH(OnUpdateSaveHandler)
{
-956,7 +928,7
PS(session_status) = php_session_active;
if (PS(apply_trans_sid)) {
- php_session_start_output_handler(4096 TSRMLS_CC);
+ php_url_scanner_add_var(PS(session_name), strlen(PS(session_name)),
+PS(id), strlen(PS(id)));
}
php_session_cache_limiter(TSRMLS_C);
-1404,21 +1376,13
/* }}} */
-PHPAPI void session_adapt_url(const char *url, size_t urllen, char **new, size_t
*newlen TSRMLS_DC)
-{
- if (PS(apply_trans_sid) (PS(session_status) == php_session_active)) {
[PHP-DEV] Re: Removal of php_fopen_wrapper in HEAD will break binary modules between 4.2 and HEAD (4.3)
On Mon, Apr 29, 2002 at 01:50:01AM +0100, Wez Furlong wrote: Hi Thies, I did raise this issue a while back, but got no response (happens quite a lot on php-dev). I think bumping the API number would be the best course of action; a lot of things have changed (binary wise) as a result of streams, and I don't think it is possible to emulate the old things without a lot of mess - the whole point of streams was to eliminate the issock mess we had in the first place. got you. sorry, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Removal of php_fopen_wrapper in HEAD will break binary modules between 4.2 and HEAD (4.3)
hi, is there any way we could avoid this? i think we should aim for keeping binary compatiblity as long as it makes sense. so, question is, would it make sense to have a function called php_fopen_wrapper in HEAD that behaves _exactly_ like it did in 4.2. elsewise we need to bump the API number - whereby that wouldn't buy us anything real as a 4.2 (binary) module woundn't even load up to that point where PHP could give a decent error-message as the shared-linker refuses to load it (atleast if the module uses php_fopen_wrapper). thoughts? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: Zend / zend_execute_API.c
On Sat, Apr 27, 2002 at 06:55:46PM +0200, Sebastian Bergmann wrote: Rasmus Lerdorf wrote: rasmus Sat Apr 27 12:21:00 2002 EDT Modified files: /Zend zend_execute_API.c Log: # How do I get at a php core_global from here? Isn't the Zend Engine supposed to be independent from PHP? ups. so we somehow need to tell zend that the connection broke. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Addition to session-module (patch included)
On Thu, Apr 25, 2002 at 06:59:21PM +0200, Harald Radi wrote:
On Thu, Apr 25, 2002 at 03:04:36PM +0200, Harald Radi wrote:
sounds very useful, go ahead ;)
would you mind extending it that
session_set_userdata(array(thies =
1, harald = 2, knorp = 100)) would be possible ?
nope - that would make the url_scanner slower.
but you can always ancode as much data as you want into the
one userdata var.
can you explain me why this affects the url_scanner ?
i'm a liar;-)
no, if architected smart it would make no real difference.
but - do we really want it? session-data belongs into the
session. this new function just allows you to identify
different browser-windows within the same session (if used
right). i really see no point in extending it -but- wait
we could of course add a real API to the trans-sid module
that allows for
url_rewriter_add('bal' , 'hallo');
url_rewriter_add('SID' , session_id());
etc etc.. so you could run you session in hidden vars on the
page - and the security nightmare starts again (ppls will use
that to store stuff in hidden vars that _belong_ in the
sesseon).
on the other hand i think it might be useful to run the
session using a cookie and still be able to add things (like
comments?
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Addition to session-module (patch included)
hi,
i have made a small patch to the session-module which allows
the script to inject some user-defined data into the
url_rewriter.
why do i need this?
- i want to be able to open a 2nd browserwindow
- this window will use the same session as the 1st one
- i need to be able to differentiate the two windows on the
PHP side
right now the session module can only store one cookie (or
one info in trans-sid) my patch extends that to one
user-defined variable so that:
?php
session_start();
session_set_userdata(thies, 1);
?
a href=test.phptest/a
form
input type=text
input type=submit
/form
will generate:
a href=test.php?MOFL=34b91e4e3d0974c3722c1298172dfb08thies=1test/a
forminput type=hidden name=MOFL
value=34b91e4e3d0974c3722c1298172dfb08 /input type=hidden
name=thies value=1 /
input type=text
input type=submit
/form
as you can see thies = 1 will now be kept on the page.
so to open a new window _and_ have a unique identifier for
each openend window you would do something like:
?php
session_start();
if (! isset($_SESSION[ 'mydata' ])) {
$_SESSION[ 'mydata' ] = array();
}
if (isset($_REQUEST[ 'newwindow' ])) {
$windowid = time();
} elseif (isset($_REQUEST[ 'windowid' ])) {
$windowid = $_REQUEST[ 'windowid' ];
} else {
$windowid = 0;
}
session_set_userdata(windowid, (string) $windowid);
if (! isset($_SESSION[ 'mydata' ][ $windowid ])) {
$_SESSION[ 'mydata' ][ $windowid ] = 0;
}
echo clicks in this window . ++$_SESSION[ 'mydata' ][ $windowid ].br;
?
a href=test.php?newwindow=1 target=0New Window/a
testform:
form
input type=text
input type=submit
/form
is it OK to commit?
tc
Index: session/php_session.h
===
RCS file: /repository/php4/ext/session/php_session.h,v
retrieving revision 1.75
diff -u -r1.75 php_session.h
--- session/php_session.h 30 Mar 2002 16:29:15 - 1.75
+++ session/php_session.h 25 Apr 2002 11:30:36 -
-93,6 +93,8
char *save_path;
char *session_name;
char *id;
+ char *udata_name;
+ char *udata_value;
char *extern_referer_chk;
char *entropy_file;
char *cache_limiter;
-141,6 +143,7
PHP_FUNCTION(session_set_cookie_params);
PHP_FUNCTION(session_get_cookie_params);
PHP_FUNCTION(session_write_close);
+PHP_FUNCTION(session_set_userdata);
#ifdef ZTS
#define PS(v) TSRMG(ps_globals_id, php_ps_globals *, v)
Index: session/session.c
===
RCS file: /repository/php4/ext/session/session.c,v
retrieving revision 1.296
diff -u -r1.296 session.c
--- session/session.c 30 Mar 2002 16:29:15 - 1.296
+++ session/session.c 25 Apr 2002 11:30:37 -
-71,10 +71,13
PHP_FE(session_set_cookie_params, NULL)
PHP_FE(session_get_cookie_params, NULL)
PHP_FE(session_write_close, NULL)
+ PHP_FE(session_set_userdata, NULL)
{NULL, NULL, NULL}
};
/* }}} */
+#define SAFE_STRING(s) ((s)?(s):)
+
ZEND_DECLARE_MODULE_GLOBALS(ps);
static ps_module *_php_find_ps_module(char *name TSRMLS_DC);
-84,7 +87,7
static void php_session_output_handler(char *output, uint output_len, char
**handled_output, uint *handled_output_len, int mode TSRMLS_DC)
{
if ((PS(session_status) == php_session_active)) {
- *handled_output = url_adapt_ext_ex(output, output_len,
PS(session_name), PS(id), handled_output_len, (zend_bool) (modePHP_OUTPUT_HANDLER_END
? 1 : 0) TSRMLS_CC);
+ *handled_output = url_adapt_ext_ex(output, output_len,
+PS(session_name), PS(id), SAFE_STRING(PS(udata_name)), SAFE_STRING(PS(udata_value)),
+handled_output_len, (zend_bool) (modePHP_OUTPUT_HANDLER_END ? 1 : 0) TSRMLS_CC);
} else {
*handled_output = NULL;
}
-1403,11 +1406,32
}
/* }}} */
+/* {{{ proto bool session_set_userdata(string var, string value)
+ sets one additional variable that will be added by in trans-SID mode */
+PHP_FUNCTION(session_set_userdata)
+{
+ zval **str;
+ zval **val;
+
+ if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, str, val) == FAILURE)
+ WRONG_PARAM_COUNT;
+
+ if ((Z_TYPE_PP(str) != IS_STRING) || (Z_TYPE_PP(val) != IS_STRING)) {
+ php_error(E_ERROR,session_set_userdata expects both parameters to be
+strings);
+ RETURN_FALSE;
+ }
+
+ PS(udata_name) = estrndup(Z_STRVAL_PP(str), Z_STRLEN_PP(str));
+ PS(udata_value) = estrndup(Z_STRVAL_PP(val), Z_STRLEN_PP(val));
+
+ RETURN_TRUE;
+}
+/* }}} */
PHPAPI void session_adapt_url(const char *url, size_t urllen, char **new, size_t
*newlen TSRMLS_DC)
{
if (PS(apply_trans_sid)
Re: [PHP-DEV] Addition to session-module (patch included)
On Thu, Apr 25, 2002 at 02:41:56PM +0200, Daniel Lorch wrote: Hi, right now the session module can only store one cookie (or one info in trans-sid) my patch extends that to one user-defined variable so that: I am not quite sure whether I understood what you are trying to do, but assumingly you have 2 frames: i'm talking about 2 or more windows! please reread. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Addition to session-module (patch included)
On Thu, Apr 25, 2002 at 03:14:19PM +0200, Daniel Lorch wrote: Hi, I am not quite sure whether I understood what you are trying to do, but assumingly you have 2 frames: i'm talking about 2 or more windows! please reread. tc Ups, sorry. I am having the same problem, but I'm solving it by giving every window a 'key' (like a secondary session ID). But your patch sounds like a good idea :) yep, this patch will make it work using trans-sid without any additional headace. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Addition to session-module (patch included)
On Thu, Apr 25, 2002 at 03:04:36PM +0200, Harald Radi wrote:
sounds very useful, go ahead ;)
would you mind extending it that session_set_userdata(array(thies =
1, harald = 2, knorp = 100)) would be possible ?
nope - that would make the url_scanner slower.
but you can always ancode as much data as you want into the
one userdata var.
tc
harald.
Thies C. Arntzen [EMAIL PROTECTED] schrieb im Newsbeitrag
news:[EMAIL PROTECTED]...
hi,
i have made a small patch to the session-module which allows
the script to inject some user-defined data into the
url_rewriter.
why do i need this?
- i want to be able to open a 2nd browserwindow
- this window will use the same session as the 1st one
- i need to be able to differentiate the two windows on the
PHP side
right now the session module can only store one cookie (or
one info in trans-sid) my patch extends that to one
user-defined variable so that:
?php
session_start();
session_set_userdata(thies, 1);
?
a href=test.phptest/a
form
input type=text
input type=submit
/form
will generate:
a
href=test.php?MOFL=34b91e4e3d0974c3722c1298172dfb08thies=1test/a
forminput type=hidden name=MOFL
value=34b91e4e3d0974c3722c1298172dfb08 /input type=hidden
name=thies value=1 /
input type=text
input type=submit
/form
as you can see thies = 1 will now be kept on the page.
so to open a new window _and_ have a unique identifier for
each openend window you would do something like:
?php
session_start();
if (! isset($_SESSION[ 'mydata' ])) {
$_SESSION[ 'mydata' ] = array();
}
if (isset($_REQUEST[ 'newwindow' ])) {
$windowid = time();
} elseif (isset($_REQUEST[ 'windowid' ])) {
$windowid = $_REQUEST[ 'windowid' ];
} else {
$windowid = 0;
}
session_set_userdata(windowid, (string) $windowid);
if (! isset($_SESSION[ 'mydata' ][ $windowid ])) {
$_SESSION[ 'mydata' ][ $windowid ] = 0;
}
echo clicks in this window . ++$_SESSION[ 'mydata' ][ $windowid
].br; ? a href=test.php?newwindow=1 target=0New Window/a
testform:
form
input type=text
input type=submit
/form
is it OK to commit?
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: Zend / zend_hash.c zend_hash.h zend_list.c
On Thu, Apr 18, 2002 at 05:37:30PM -, Thies C. Arntzen wrote:
thies Thu Apr 18 13:37:30 2002 EDT
Modified files:
/Zend zend_hash.c zend_hash.h zend_list.c
Log:
make sure the resource-list is always consistent during shutdown. this fixes
#15499 (which seems unrelated, but it isn't;-)
derick,
i'll MFH this one once 4.2 is out (and it's proven to be
stabe in -HEAD)
re,
tc
Index: Zend/zend_hash.c
diff -u Zend/zend_hash.c:1.83 Zend/zend_hash.c:1.84
--- Zend/zend_hash.c:1.83 Sun Jan 6 10:21:09 2002
+++ Zend/zend_hash.c Thu Apr 18 13:37:28 2002
-651,6 +651,23
SET_INCONSISTENT(HT_DESTROYED);
}
+ZEND_API void zend_hash_graceful_reverse_destroy(HashTable *ht)
+{
+ Bucket *p;
+
+ IS_CONSISTENT(ht);
+
+ p = ht-pListTail;
+ while (p != NULL) {
+ zend_hash_apply_deleter(ht, p);
+ p = ht-pListTail;
+ }
+
+ pefree(ht-arBuckets, ht-persistent);
+
+ SET_INCONSISTENT(HT_DESTROYED);
+}
+
/* This is used to selectively delete certain entries from a hashtable.
* destruct() receives the data and decides if the entry should be deleted
* or not
Index: Zend/zend_hash.h
diff -u Zend/zend_hash.h:1.55 Zend/zend_hash.h:1.56
--- Zend/zend_hash.h:1.55 Sun Jan 6 10:21:09 2002
+++ Zend/zend_hash.h Thu Apr 18 13:37:29 2002
-119,6 +119,7
typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args,
zend_hash_key *hash_key);
ZEND_API void zend_hash_graceful_destroy(HashTable *ht);
+ZEND_API void zend_hash_graceful_reverse_destroy(HashTable *ht);
ZEND_API void zend_hash_apply(HashTable *ht, apply_func_t apply_func TSRMLS_DC);
ZEND_API void zend_hash_apply_with_argument(HashTable *ht, apply_func_arg_t
apply_func, void * TSRMLS_DC);
ZEND_API void zend_hash_apply_with_arguments(HashTable *ht, apply_func_args_t
apply_func, int, ...);
Index: Zend/zend_list.c
diff -u Zend/zend_list.c:1.52 Zend/zend_list.c:1.53
--- Zend/zend_list.c:1.52 Sun Jan 6 10:21:09 2002
+++ Zend/zend_list.c Thu Apr 18 13:37:29 2002
-230,32 +230,8
void zend_destroy_rsrc_list(HashTable *ht TSRMLS_DC)
{
- Bucket *p, *q;
-
- while (1) {
- p = ht-pListTail;
- if (!p) {
- break;
- }
- q = p-pListLast;
- if (q) {
- q-pListNext = NULL;
- }
- ht-pListTail = q;
-
- if (ht-pDestructor) {
- zend_try {
- ht-pDestructor(p-pData);
- } zend_end_try();
- }
- if (!p-pDataPtr p-pData) {
- pefree(p-pData, ht-persistent);
- }
- pefree(p, ht-persistent);
- }
- pefree(ht-arBuckets, ht-persistent);
+ zend_hash_graceful_reverse_destroy(ht);
}
-
static int clean_module_resource(zend_rsrc_list_entry *le, int *resource_id
TSRMLS_DC)
{
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PATCH to zend_list.c
zeev, andi
i have to following problem:
while the zend_destroy_rsrc_list() is running a _dtor
function for one of my resources it (the dtor of the resource)
does a zend_list_delete, which does a hash_find on the
resource-list again. the problem is that
zend_destroy_rsrc_list takes out the bucked it will dtor from
the hash's mail linked list but it leaves the bucket in
ht-arBuckets. so my zend_list_delete might find an already
dealloced entry (cause the resource_list is inconsistent) -
boom!
the attached patch fixes this by removing the bucket not only
from the hashes global linked list but by also removing all
traces of it from the ht-arBuckets.
i have stolen some code from zend_hash_del_key_or_index.
so - we could either apply this patch as it is
as zend_destroy_rsrc_list() already fiddles with
hash-internals -or- i create a macro in zend_hash.h
called DISCONNECT_BUCKET_FROM_ARLIST(ht, bucket).
a patch along these lines is needed to have a consistent
resource_list while the _dtors are called. i don't think
we'll see a measuarable speed impact once this patch is in.
comments?
tc
? .zend_hash.c.swp
Index: zend_list.c
===
RCS file: /repository/Zend/zend_list.c,v
retrieving revision 1.52
diff -u -r1.52 zend_list.c
--- zend_list.c 6 Jan 2002 15:21:09 - 1.52
+++ zend_list.c 16 Apr 2002 15:17:12 -
-231,8 +231,10
void zend_destroy_rsrc_list(HashTable *ht TSRMLS_DC)
{
Bucket *p, *q;
+ uint nIndex;
while (1) {
+ /* remove bucket from main linked-list */
p = ht-pListTail;
if (!p) {
break;
-242,6 +244,34
q-pListNext = NULL;
}
ht-pListTail = q;
+
+ /* stolen from zend_hash_del_key_or_index - should be moved back into
+zend_hash */
+ nIndex = p-h ht-nTableMask;
+
+ if (p == ht-arBuckets[nIndex]) {
+ ht-arBuckets[nIndex] = p-pNext;
+ } else {
+ p-pLast-pNext = p-pNext;
+ }
+ if (p-pNext) {
+ p-pNext-pLast = p-pLast;
+ }
+ if (p-pListLast != NULL) {
+ p-pListLast-pListNext = p-pListNext;
+ } else {
+ /* Deleting the head of the list */
+ ht-pListHead = p-pListNext;
+ }
+ if (p-pListNext != NULL) {
+ p-pListNext-pListLast = p-pListLast;
+ } else {
+ ht-pListTail = p-pListLast;
+ }
+ if (ht-pInternalPointer == p) {
+ ht-pInternalPointer = p-pListNext;
+ }
+ ht-nNumOfElements--;
+ /* now the hashtable is consistent again */
if (ht-pDestructor) {
zend_try {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2filter efficiency
On Fri, Apr 05, 2002 at 11:10:13PM -0800, Aaron Bannert wrote: After working with this filter for the last few days I came to realize that it really isn't taking advantage of the newer features of Apache 2. In addition it seems to have a flaw that would prevent it from working downstream from any other content-generation filter (imagine, for example, a mod_include page that embedded PHP script). I think a good way to take advantage of the filter system would be to break the input stream into buckets of two types: constant strings and PHP script code. As flex/bison needs to be fed more data (from the yyinput function I think it's called) it could just read data out of buckets on the brigade. As it generates data, it could spit out buckets that are fed back into the brigade and passed downstream. The same would happen to the constant string data buckets: they could just be quickly passed down the filter chain. Is this feasible in the SAPI domain? I know very little about the SAPI, but will it allow me to override the equivalent of the yyinput function? php (in this case the engine) _needs_ the whole script in order to compile it (before it can start executing). therefore the apache2 sapi has to read all input from the filter that's generating data for it. then the script gest compiled, exeuted and the outpout will be send bucket-by-bucket to the next filter. client | (some stuff left out) | mod_php | mod_include | file.shtml so php has to read everything from mod_include before it starts passing data on. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] your patch to session.c broke it (testcase included)
zeev,
your patch
http://cvs.php.net/diff.php/php4/ext/session/session.c?r1=1.277r2=1.278ty=u
broke the session module:
testcase (run multiple times using php-cgi from the command-line)
?php
session_id(thies);
session_start();
if (! session_is_registered(hallo)) {
$hallo = hi ;
session_register('hallo');
} else {
$hallo = $_SESSION[ 'hallo' ];
}
echo $hallo\n;
$hallo .= '!';
?
after your patch the changed value of $hallo is no longer remembered.
hmm, as i don't know wich crash bug your patch fixes i
don't want to simply revert it - could you give me some
insights?
re,
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] your patch to session.c broke it (testcase included)
On Mon, Mar 04, 2002 at 10:42:42PM +0200, Zeev Suraski wrote:
At 13:18 04/03/2002, Thies C. Arntzen wrote:
zeev,
your patch
http://cvs.php.net/diff.php/php4/ext/session/session.c?r1=1.277r2=1.278ty=u
broke the session module:
testcase (run multiple times using php-cgi from the command-line)
?php
session_id(thies);
session_start();
if (! session_is_registered(hallo)) {
$hallo = hi ;
session_register('hallo');
} else {
$hallo = $_SESSION[ 'hallo' ];
}
echo $hallo\n;
$hallo .= '!';
?
after your patch the changed value of $hallo is no longer remembered.
hmm, as i don't know wich crash bug your patch fixes i
don't want to simply revert it - could you give me some
insights?
Well, I didn't find any crashes, but it is a potential crash, because the
zval is put into the hash with a wrong refcount. Did you try rolling back
this particular patch and it works again?
yep.
You said I should run this using php-cgi from the command line, how exactly
is this supposed to work with sessions (which rely on HTTP cookies, or am I
missing something? :)
session_init('hallo'); set's the session ID. running this from
the commandline works - you could also run in apache.
tc
Zeev
--
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: Bug #15653 Updated: use_trans_sid creates invalid HTML
On Fri, Feb 22, 2002 at 10:36:14AM +0900, Yasuo Ohgaki wrote: [EMAIL PROTECTED] wrote: ID: 15653 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Debian GNU Linux PHP Version: 4.1.1 New Comment: But then the *default* (just '') is wrong surely? http://www.php.net/manual/en/function.ini-set.php#AEN56526 grep arg_sep php.ini ;arg_separator.output = amp; ;arg_separator.input = ; IIRC even XHTML need to escape the I'm going to change the default value for these legacy compatibility options to confrim latest standards. Any objections? yes. using as the arg_seperator has been in there forever. changing this might break with certain browsers. so ppls are free to set it to whatever they want *on their systems* - but the default should not change IMHO. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] one script to handle them all
On Wed, Feb 13, 2002 at 12:36:49PM +0100, Lukas Schroeder wrote:
On Wed, Feb 13, 2002 at 08:13:42AM +0100, Markus Fischer wrote:
Patches should always be against latest CVS.
here it is. against latest CVS.
how does this compare the the work rasmnus has done some time
ago - see attached mail?
re,
tc
regards,
-lukas
Index: sapi/apache/mod_php4.c
===
RCS file: /repository/php4/sapi/apache/mod_php4.c,v
retrieving revision 1.127
diff -u -r1.127 mod_php4.c
--- sapi/apache/mod_php4.c11 Dec 2001 15:31:53 - 1.127
+++ sapi/apache/mod_php4.c13 Feb 2002 11:20:58 -
@@ -483,6 +483,39 @@
}
/* }}} */
+/* {{{ php_get_request_handler
+ */
+static int php_get_request_handler(request_rec *r, char **target)
+{
+ HashTable *per_dir_conf;
+ php_per_dir_entry *per_dir_entry;
+ char *filename;
+
+ if (!(per_dir_conf = get_module_config(r-per_dir_config, php4_module)))
+ return 0;
+
+ if (zend_hash_find(per_dir_conf, request_handler,
sizeof(request_handler)-1,
+ (void **)per_dir_entry) == SUCCESS) {
+
+ if (!ap_os_is_path_absolute(per_dir_entry-value)) {
+ char *dirnam = ap_pstrdup(r-pool, r-filename);
+ char *x = strrchr(dirnam, '/');
+
+ if (x != NULL)
+ *x = 0;
+ filename = ap_make_full_path(r-pool, dirnam,
per_dir_entry-value);
+ }
+ else
+ filename = ap_pstrdup(r-pool, per_dir_entry-value);
+
+ *target = filename;
+ return 1;
+ }
+
+ return 0;
+}
+/* }}} */
+
/* {{{ send_php
*/
static int send_php(request_rec *r, int display_source_mode, char *filename)
@@ -502,6 +535,9 @@
return OK;
}
+ if (php_get_request_handler(r, filename))
+ r-filename = filename;
+
zend_first_try {
/* We don't accept OPTIONS requests, but take everything else */
if (r-method_number == M_OPTIONS) {
@@ -846,6 +882,26 @@
}
/* }}} */
+/* {{{ php_type_checker
+ */
+static int php_type_checker(request_rec *r)
+{
+ char *filename;
+
+ /* if a request_handler has been registered, the type checker tells
+ * apache to invoke our send_php handler; otherwise we deny responsibility
+ * for this request
+ */
+
+ if (php_get_request_handler(r, filename)) {
+ r-handler = application/x-httpd-php;
+ return OK;
+ }
+
+ return DECLINED;
+}
+/* }}} */
+
/* {{{ handler_rec php_handlers[]
*/
handler_rec php_handlers[] =
@@ -885,7 +941,7 @@
NULL, /* check_user_id */
NULL, /* check auth */
NULL, /* check access */
- NULL, /* type_checker */
+ php_type_checker, /* type_checker */
NULL, /* fixups */
NULL/* logger */
#if MODULE_MAGIC_NUMBER = 19970103
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
---BeginMessage---
rasmus Thu Sep 6 05:53:34 2001 EDT
Modified files: (Branch: apache_hooks)
/php4/main main.c php_main.h
/php4/sapi/apache mod_php4.c mod_php4.h php_apache.c
Log:
Apache request handler hook framework. So far only the uri hook is
implemented, but the others will be easy once I finish the uri translation
example. The big things left to do is to create a proper $r request
object to be manipulated in user-space and also to verify that the hooks
don't steal the POST data such that it isn't available to the content
handler once it is finally called. Or if we do steal it, make sure it
is somehow available to the content handler later on.
Comments and help with this stuff is more than welcome. Check out these
files from the 'apache_hooks' branch to play along.
Index: php4/main/main.c
diff -u php4/main/main.c:1.407 php4/main/main.c:1.407.2.1
--- php4/main/main.c:1.407 Fri Aug 31 10:34:40 2001
+++ php4/main/main.cThu Sep 6 05:53:33 2001
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: main.c,v 1.407 2001/08/31 14:34:40 zeev Exp $ */
+/* $Id: main.c,v 1.407.2.1 2001/09/06 09:53:33 rasmus Exp $ */
/* {{{ includes
*/
@@ -692,6 +692,35 @@
}
/* }}} */
+/* {{{ php_request_startup_for_hook
+ */
+int php_request_startup_for_hook(TSRMLS_D)
+{
+ int retval = SUCCESS;
+
+#if PHP_SIGCHILD
+ signal(SIGCHLD, sigchld_handler);
+#endif
Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
On Sat, Feb 09, 2002 at 01:41:21AM +0200, Zeev Suraski wrote:
I think that's a nightmare, WTF-factor wise... Just my 0.02NIS
how much is that in euro?
Zeev
At 12:14 AM 2/9/2002, Jason Greene wrote:
If you are already thinking about storing the case sensitive name for
the class/function why not follow Rasmus's suggestion for calling the
exact case function first, then look for a case insens match.
search case preserved function_table
if not found {
search lowercase function_table
if not found die with Unknown function
}
There is no performance penalty unless you mix case. There is of course
the extra memory needed for 2 tables.
--
Jason T. Greene
Internet Software Engineer
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Use PHP: http://www.php.net
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #15390: Persistent OCI8 Connections Get Poisoned
On Tue, Feb 05, 2002 at 09:10:57PM -0500, George Schlossnagle wrote: Isn't there handling for this in current cvs code? I remember submitting a patch for this (and assoicated problems) to Thies, and it being accepted. there is - but there seem to be some error-codes missing. george, you run a big PHP-oracle site if i recall right - ist it working to your satisfaction? tc George On Tuesday, February 5, 2002, at 04:23 PM, Hans Zaunere wrote: Good idea (for the situation anyway). It works. I have all custom error handlers anyway, so when I detect a ORA-03313 error, I kill the current process with a SIGTERM. Since I use header() to redirect to the error page, sometimes I get a blank page, but atleast when the database comes back, the whole system is back. Although PHP should handle this better in some manner. :) Thank you, Hans [EMAIL PROTECTED] wrote: We are seeing this problem too. I am thinking of having a standard error page which executes posix_kill ( pos_getpid()) ; On Oracle errors. From: [EMAIL PROTECTED] Operating system: RedHat 6.2 PHP version: 4.0.6 PHP Bug Type: OCI8 related Bug description: Persistent OCI8 Connections Get Poisoned I have PHP 4.0.6 compiled as an Apache 1.3.20 module with OCI8 and MySQL on RedHat 6.2. I use persistent connections with OCI8 to avoid the costly connection construction for Oracle for each request. However, I notice that these persistent connections get poisoned under certain circumstances. What I mean by this is this: Since each persistent connection stays with it's corresponding Apache process, if the database happens to be down when a request comes in, the persistent connection that is used throws an ORA-03113. However, even when the database comes back, the persistent connection still thinks the database is down somehow, and will continue to throw the ORA-03113 error. As a result, if a request happens to hit the poisoned Apache process, it appears the database is down. If a request hits another Apache process, all is OK. So far, the only way I've seen to deal this is to restart Apache, and have the persistent connections build up again. Obviously, this is not a good thing, and if database connectivity is lost in any form, the persistent connections get poisoned again, and the cycle begins. Now as this might not be a bug per se, I would think that persistent connections should at least check that they aren't corrupted in some way; or 'freshen' themselves. Although I haven't tested it fully, I have never seen this behavior with persistent MySQL connections. Please contact me for any further details or clarification if needed. Thank you, Hans -- Edit bug report at http://bugs.php.net/?id=15390edit=1 -- Fixed in CVS: http://bugs.php.net/fix.php?id=15390r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=15390r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15390r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15390r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15390r=support Expected behavior: http://bugs.php.net/fix.php?id=15390r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15390r=notenoughinfo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php // George Schlossnagle // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- 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 msession.c
On Tue, Feb 05, 2002 at 09:42:12AM -0500, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Removing backward compatibility for aesthetic reasons is bogus. To be perfectly honest, I think the whole PHP extension API is truly ugly. The removal of a few #ifdefs will not a Mona Lisa make. to me readability is a maintainance issue, not an aestheic one ... Perhaps for you it is, but not everyone agrees with you. Open source is about freedom, is it not? if you don't care about others to understand your code, or even don't want anyone to touch it anyway (as you already have made clear), I have made no such declaration. I just do not think well placed #ifdefs affect readability or maintainability. That is your opinion, not mine. I welcome anyone to add features to the msession code as they see fit. All I ask is that they do not remove backward compatibility. This is not an earth shattering request. I am really tired of this argument. Why do you care? Why does anyone care? The code is fairly readable, it doesn't do anything hard to understand. It is a simple thunk/trasport layer for another library all together. If anyone has trouble reading or understanding it, I would suggest that they need to take a basic C class. More over, I think msession, while still a bit experimental, is a worthwhile addition to PHP. I already have a few people using it and it has helped them deploy their web farm. People are using it, and in doing so people are using PHP for big things. As I understand it, this is what we all want, right? I think very highly of PHP. It is a great project. I submited my extension to add value to the project. I think it can add value and help moderately large installations. All I am asking is that, as one developer, that backward compatibiliy remains so I do not have to maintain two branches and duplicate work. My time is valuable, why should I waste it? This is not a lot to ask and I simply do not understand what the problem is. In any professional environment, this would be a no-brainer. You do not remove backward compatibility if you do not need to do so. the problem as i see it is that everything in the php4/ CVS is worked on by several ppls. we invent a new API and somebody goes and implements that in some modules (and mybe not in some other). the new parameter-parsing API was introduced by andrei some month ago and we decided to switch to this api. even thogh i haven't been very active lately i did a big chink of work porting modules from php3 to php4 and -no- i did not ask the official maintainer if they want to port it. there was an itch and i scrachted it. having a new/better API certainly is an itch and having both the old and the new one in one file is something we've never done in the past. i agree with hartmut that we don't care for backward compatiblity in modules that are in the php4/ cvs. so if you need to have support for anything but php4-HEAD in your module it probably doesn't belong to php4-HEAD. PECL on the other hand is a completely different story, and if i was you i would move places. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] free_zval not working?
On Tue, Jan 22, 2002 at 09:27:53AM +0100, Robin Ericsson wrote: I'm using this on php 4.0.6, it know it's old, but things will break if I upgrade :) This is the code: zval *z_return; MAKE_STD_ZVAL(z_return); php_char_to_str(retval, strlen(retval), '\n', br\n, 5, z_return); FREE_ZVAL(z_return); This code gives me: string.c(2122) : Freeing 0x08257CEC (134 bytes), script=nn.php which is the new string allocated inside php_char_to_str(), howcome this memory isn't freed with FREE_ZVAL? FREE_ZVAL only frees the zval and does not destroy (read =free) the attached data-structures. use zval_dtor for that. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14922: OCIBindByName forcing length to 1, even though 0 is a valid length
On Mon, Jan 07, 2002 at 11:37:16PM -, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Solaris PHP version: 4.1.0 PHP Bug Type: OCI8 related Bug description: OCIBindByName forcing length to 1, even though 0 is a valid length It seems that the when oci8.c forces value_sz to 1 if it's 0 is bypassing a perfectly valid use of a length of 0: To signify a null. See: http://download-west.oracle.com/otndoc/oracle9i/901_doc/appdev.901/a89857/oci03typ.htm to pass a null thru a bound variable simply assign the special value NULL to the bound php-variable. the size supplied to ocibindbyname is simple the max-length of the inbound variable. ocibindbyname($stmt,NAME,$name,32); $name = NULL; ociexecute($stmt); - :NAME will have the value null in the query please verify and close the report. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14802: --with-oci8 doesnt grok 64-bit Oracle 9i
plz replace all OCI8_DIR/lib against OCI8_DIR/lib32 in configure and try again. don't forget to report back! tc On Wed, Jan 02, 2002 at 03:46:58PM -, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.1.1 PHP Bug Type: Compile Failure Bug description: --with-oci8 doesnt grok 64-bit Oracle 9i less debug.log CONFIGURE: './configure' '--with-fastcgi' '--without-mysql' '--with-oci8=/home/oracle/OraHome1' '- -enable-mbstr-enc-trans' CC: cc CFLAGS: -g CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS CXX: CXXFLAGS: INCLUDES: -I/usr/local/include -I$(top_builddir)/Zend -I/home/oracle/OraHome1/rdbms/public -I/h ome/oracle/OraHome1/rdbms/demo -I/home/oracle/OraHome1/plsql/public LDFLAGS: -R/usr/ucblib -L/usr/ucblib -R/home/oracle/OraHome1/lib -L/home/oracle/OraHome1/lib LIBS: -ldl -lgen -lsocket -lnsl -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lnsl -lsocket -l socket -lcrypt -lclntsh DLIBS: SAPI: fastcgi PHP_RPATHS: /usr/ucblib /home/oracle/OraHome1/lib uname -a: SunOS double-eric 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-2 cc -o conftest -g -D_POSIX_PTHREAD_SEMANTICS -R/usr/ucblib -L/usr/ucblib -R/home/oracle/OraHome1/l ib -L/home/oracle/OraHome1/lib conftest.c -ldl -lgen -lsocket -lnsl -lcrypt -lresolv -lresolv -lreso lv -lm -ldl -lnsl -lsocket -lsocket -lcrypt -lclntsh 15 ld: fatal: file /home/oracle/OraHome1/lib/libclntsh.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to conftest --- the 32bit libraries are in $ORACLE_HOME/lib32 however, looking at the configure file, I am unable to figure out what in the oci8 detection system needs to be changed as all the paths are coded as ???/lib -- Edit bug report at: http://bugs.php.net/?id=14802edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14497 Updated: PHP causes segfault when session handler=user
On Thu, Dec 20, 2001 at 04:00:15AM -, [EMAIL PROTECTED] wrote: ID: 14497 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Old Status: Open Status: Analyzed Bug Type: Session related Operating System: FreeBSD 4.4-Stable PHP Version: 4.1.0, 4-200112131200 New Comment: Is this fixed? Anyone mind if I fix this and commit? no - go ahead. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] sockets problems patch
On Sun, Dec 09, 2001 at 04:17:57PM -0500, benjamin yates wrote: The problem with the zip file he sent is also that a: ]$ diff -uN orig new produces a unified diff with almost all of it being whitespace related, so its near impossible to view the changes... that's what i did;-) hmmm i think it's more a cr/lf thing... my diff -uN output seems okay to me. i'll convert it back to lf... try the same url... http://www.newnetwork.com/benjamin_sockets.zip now that i changed it. will look at it as soon as i find some time. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] sockets problems patch
please send a unified diff. i'll look at integrating your changes then! tc On Sat, Dec 08, 2001 at 08:20:56PM -0500, benjamin yates wrote: hey all... i've been using the sockets extension pretty extensively for the past couple months, and it has some real problems. obviously the best reason for it is the ability to use non-blocking sockets in php, which is great for writing simple tcpip clients and services. i've done this with a set of state-machines and it works very well. i had to change the code alot though before i could make it all work, because of two issues. first, the library tracks socket errors with 'errno' which isn't proper on win32, where you must use WSAGetLastError() instead. that's a simple fix... the second has more changes. currently, the library stores the last error only when socket calls return error-ish values. which is a problem because the return value of the sockets calls is not what is returned to the php script. this doesn't provide enough data for writing an app that uses non-blocking sockets. example... socket_read() returns false if it didn't read anything. recv() returns the number of bytes read OR zero of the connection was closed OR -1 if another error is in errno/WSAGetLastError. since socket_read only returns good or bad, you can't tell the specific error without the socket_last_error being correct... i hope this makes sense to someone. the last time i built this and patched it, i sent my changes from (at the time) the current CVS to the authors in the sockets.c but never got any response - so now i'm posting it here. i repatched the latest cvs snapshot, and i just tested it out on one of my scripts and it's working fine for me. i don't know if it might break some unix implementations - i think it will be fine. the code isn't the best, because there are places where socket function calls are inside of if()'s, and the last error must be stored, so instead of reorganize everything, i just put multiple calls to my error storage macro where it was needed. i don't know all the coding standards you go by so i didnt' want to spend time making a bunch of changes that wouldn't be wanted. i zipped my sockets.c and the original, taken from the latest cvs snapshot - it's available at http://www.newnetwork.com/benjamin_sockets.zip thanks for looking at it... oh and i don't know why someone decided that the socket_last_error() should clear the error when calling it, i can't think of any reason why... and it means that i have to store it before i use it in a script, if i must make multiple references to it. not a big deal but i just can't come up with why it should be cleared. well perhaps someone thought it should be cleared before i decided that it should be set after every call :) -benjamin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] sockets problems patch
On Sun, Dec 09, 2001 at 07:42:46PM +0100, Sterling Hughes wrote: please send a unified diff. i'll look at integrating your changes then! The problem with the zip file he sent is also that a: ]$ diff -uN orig new produces a unified diff with almost all of it being whitespace related, so its near impossible to view the changes... that's what i did;-) -Sterling tc On Sat, Dec 08, 2001 at 08:20:56PM -0500, benjamin yates wrote: hey all... i've been using the sockets extension pretty extensively for the past couple months, and it has some real problems. obviously the best reason for it is the ability to use non-blocking sockets in php, which is great for writing simple tcpip clients and services. i've done this with a set of state-machines and it works very well. i had to change the code alot though before i could make it all work, because of two issues. first, the library tracks socket errors with 'errno' which isn't proper on win32, where you must use WSAGetLastError() instead. that's a simple fix... the second has more changes. currently, the library stores the last error only when socket calls return error-ish values. which is a problem because the return value of the sockets calls is not what is returned to the php script. this doesn't provide enough data for writing an app that uses non-blocking sockets. example... socket_read() returns false if it didn't read anything. recv() returns the number of bytes read OR zero of the connection was closed OR -1 if another error is in errno/WSAGetLastError. since socket_read only returns good or bad, you can't tell the specific error without the socket_last_error being correct... i hope this makes sense to someone. the last time i built this and patched it, i sent my changes from (at the time) the current CVS to the authors in the sockets.c but never got any response - so now i'm posting it here. i repatched the latest cvs snapshot, and i just tested it out on one of my scripts and it's working fine for me. i don't know if it might break some unix implementations - i think it will be fine. the code isn't the best, because there are places where socket function calls are inside of if()'s, and the last error must be stored, so instead of reorganize everything, i just put multiple calls to my error storage macro where it was needed. i don't know all the coding standards you go by so i didnt' want to spend time making a bunch of changes that wouldn't be wanted. i zipped my sockets.c and the original, taken from the latest cvs snapshot - it's available at http://www.newnetwork.com/benjamin_sockets.zip thanks for looking at it... oh and i don't know why someone decided that the socket_last_error() should clear the error when calling it, i can't think of any reason why... and it means that i have to store it before i use it in a script, if i must make multiple references to it. not a big deal but i just can't come up with why it should be cleared. well perhaps someone thought it should be cleared before i decided that it should be set after every call :) -benjamin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1.0RC5
On Thu, Dec 06, 2001 at 02:10:46PM +0100, Petr Cech wrote: On Mon, Dec 03, 2001 at 03:53:05PM +0200 , Zeev Suraski wrote: You know the drill, but practice makes perfect! In a divine effort to prevent both Derick and Zak from winning their bets (Derick bet we'll go up to RC8, Zak bet that we'll go as far as RC7), please folks, FIND NO BUGS! It's a 'final release' darn it :) ?php $val = philip steeman [EMAIL PROTECTED]; $rij = imap_rfc822_parse_adrlist($val, xx.khbo.be); print $val; ? note the change of the -space before into NUL byte. do we need to SEPARATE_ZVAL here? when did it break? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1.0RC5
On Fri, Dec 07, 2001 at 02:56:39PM +0100, Thies C. Arntzen wrote: On Thu, Dec 06, 2001 at 02:10:46PM +0100, Petr Cech wrote: On Mon, Dec 03, 2001 at 03:53:05PM +0200 , Zeev Suraski wrote: You know the drill, but practice makes perfect! In a divine effort to prevent both Derick and Zak from winning their bets (Derick bet we'll go up to RC8, Zak bet that we'll go as far as RC7), please folks, FIND NO BUGS! It's a 'final release' darn it :) ?php $val = philip steeman [EMAIL PROTECTED]; $rij = imap_rfc822_parse_adrlist($val, xx.khbo.be); print $val; ? note the change of the -space before into NUL byte. do we need to SEPARATE_ZVAL here? when did it break? fixed in 4.1 branch and HEAD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] php-patches@lists.php.net?
On Tue, Dec 04, 2001 at 09:04:29PM +0900, Yasuo Ohgaki wrote: How about to have *new* list for sending patch for PHP? PostgreSQL has list for that. It seems the list is working great for them. php-dev is perfect for sending patches! tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] php-patches@lists.php.net?
On Tue, Dec 04, 2001 at 02:48:40PM -0600, Andrei Zmievski wrote: On Tue, 04 Dec 2001, Thies C. Arntzen wrote: On Tue, Dec 04, 2001 at 09:04:29PM +0900, Yasuo Ohgaki wrote: How about to have *new* list for sending patch for PHP? PostgreSQL has list for that. It seems the list is working great for them. php-dev is perfect for sending patches! tc No, no. I suggest we split the list into extension specific lists. I claim [EMAIL PROTECTED] and [EMAIL PROTECTED] Then we can have *really* focused discussion. This php-dev deal just waters everything down. i'm going to be on all lists anyhow;-) - so it doesn't make any difference for me. personally i think it would make sense to keep all CVS, bugdb and -dev talk on one single list. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RC5 hexdec not compatible
hi,
the current behavious is more connect than the old one.
we automagiacally propagate from in to float in the conversion
routines once we gent an overflow. to get the old bahaviour
in your case you need to case the result of hexdec() to int:
$dec = (int) hexdec($hex);
and you'll get the old behaviour back. i do think that
normally you don't want negative results from hexdec() so the
new behaviour is more correct.
re,
tc
On Tue, Dec 04, 2001 at 09:01:02AM -0500, chrism wrote:
?php /* hexdec.php */
/* 4.1.0 branch hexdec not compatible
* with earlier PHP releases.
*/
/*
% php4.0.0 -f hexdec.php
lemon = 5d08374e = 1560819534
pineapple = a7e9b7d0 = -1477855280
fruit = c10d50e3 = -1056091933
sausage = 42d08254 = 1120961108
breakfast = f7d7b86e = -136857490
coconut = 1138ca81 = 288934529
% php4.0.6 -f hexdec.php
lemon = 5d08374e = 1560819534
pineapple = a7e9b7d0 = -1477855280
fruit = c10d50e3 = -1056091933
sausage = 42d08254 = 1120961108
breakfast = f7d7b86e = -136857490
coconut = 1138ca81 = 288934529
% php4.1.0RC5 -f hexdec.php
lemon = 5d08374e = 1560819534
pineapple = a7e9b7d0 = 2817112016
fruit = c10d50e3 = 3238875363
sausage = 42d08254 = 1120961108
breakfast = f7d7b86e = 4158109806
coconut = 1138ca81 = 288934529
*/
$wordlist = array(lemon, pineapple, fruit, sausage,
breakfast,coconut);
foreach($wordlist as $word) {
$crc = mhash(MHASH_CRC32, $word);
$hex = bin2hex($crc);
$dec = hexdec($hex);
echo $word . = . $hex . = . $dec . \n;
}
?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14294 Updated: is_dir() causes stat failed warning
On Fri, Nov 30, 2001 at 07:23:39PM +0200, Jani Taskinen wrote: Ask sterling about this. IMO, it's good as it is now. if it's now different from how 4.0.6 behaved than it's wrong _and_ should be changed back before 4.1! i'm compiling right now. tc --Jani On Fri, 30 Nov 2001, Markus Fischer wrote: This has something .. Jani, don't you think this should be investigated ..? I thought this was made consistent or so or maybe it is and I just don't get the picture. - Markus On Fri, Nov 30, 2001 at 08:13:59AM -, [EMAIL PROTECTED] wrote : ID: 14294 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Filesystem function related Operating System: FreeBSD 4.3 PHP Version: 4.1.0 New Comment: You don't think it's odd that the function that checks to see if a directory exists returns a warning on what it's supposed to be doing?? Earlier versions of PHP did not do this, and to me that makes it a 'bug'. While yes, it can be suppressed, it should be functional in the same way previous versions of PHP worked. This in no way is a 'feature' of the function. Previous Comments: [2001-11-30 02:43:04] [EMAIL PROTECTED] (or using @ in front of the function) [2001-11-30 02:42:49] [EMAIL PROTECTED] Warnings can be supressed by setting error_reporting correctly. Not a bug. [2001-11-29 21:28:20] [EMAIL PROTECTED] In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says stat failed on /your/path if the path does not exist. This was causing havok with scripts of mine that relied on no output for errors.. Of course I just suppressed the message, but it really shouldnt be there. The function is designed to check for an existing dir, it should work without warnings! Hopefully this can be fixed in the next release. On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However the version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work! Thanks guys. Edit this bug report at http://bugs.php.net/?id=14294edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14294 Updated: is_dir() causes stat failed warning
On Sun, Dec 02, 2001 at 10:31:58AM +0100, Thies C. Arntzen wrote: On Fri, Nov 30, 2001 at 07:23:39PM +0200, Jani Taskinen wrote: Ask sterling about this. IMO, it's good as it is now. if it's now different from how 4.0.6 behaved than it's wrong _and_ should be changed back before 4.1! i'm compiling right now. 4.0.6 and 4.1 give a warning - HEAD doesn't. that means that 4.1 bahaves like the last release. so no need to act right now. tc tc --Jani On Fri, 30 Nov 2001, Markus Fischer wrote: This has something .. Jani, don't you think this should be investigated ..? I thought this was made consistent or so or maybe it is and I just don't get the picture. - Markus On Fri, Nov 30, 2001 at 08:13:59AM -, [EMAIL PROTECTED] wrote : ID: 14294 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Filesystem function related Operating System: FreeBSD 4.3 PHP Version: 4.1.0 New Comment: You don't think it's odd that the function that checks to see if a directory exists returns a warning on what it's supposed to be doing?? Earlier versions of PHP did not do this, and to me that makes it a 'bug'. While yes, it can be suppressed, it should be functional in the same way previous versions of PHP worked. This in no way is a 'feature' of the function. Previous Comments: [2001-11-30 02:43:04] [EMAIL PROTECTED] (or using @ in front of the function) [2001-11-30 02:42:49] [EMAIL PROTECTED] Warnings can be supressed by setting error_reporting correctly. Not a bug. [2001-11-29 21:28:20] [EMAIL PROTECTED] In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says stat failed on /your/path if the path does not exist. This was causing havok with scripts of mine that relied on no output for errors.. Of course I just suppressed the message, but it really shouldnt be there. The function is designed to check for an existing dir, it should work without warnings! Hopefully this can be fixed in the next release. On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However the version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work! Thanks guys. Edit this bug report at http://bugs.php.net/?id=14294edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 10% speedup patch in zend_hash_copy
hi -
this litte patch makes zend_hash_copy around 10% faster by
taking a shortcut
zeev, andi -
is this commitable or do you have any objections?
tc
Index: zend_hash.c
===
RCS file: /repository/Zend/zend_hash.c,v
retrieving revision 1.81
diff -u -r1.81 zend_hash.c
--- zend_hash.c 2001/10/04 12:47:59 1.81
+++ zend_hash.c 2001/11/25 16:22:22
@@ -754,23 +754,77 @@
ZEND_API void zend_hash_copy(HashTable *target, HashTable *source, copy_ctor_func_t
pCopyConstructor, void *tmp, uint size)
{
Bucket *p;
+ Bucket *np;
void *new_entry;
+ uint nIndex;
IS_CONSISTENT(source);
IS_CONSISTENT(target);
- p = source-pListHead;
- while (p) {
- if (p-nKeyLength) {
- zend_hash_update(target, p-arKey, p-nKeyLength, p-pData,
size, new_entry);
- } else {
- zend_hash_index_update(target, p-h, p-pData, size,
new_entry);
+ if (target-nNumOfElements == 0) {
+ target-nTableSize = source-nTableSize;
+ target-nTableMask = source-nTableMask;
+ target-nNumOfElements = source-nNumOfElements;
+ target-nNextFreeElement = source-nNextFreeElement;
+
+ pefree(target-arBuckets, target-persistent);
+ target-arBuckets = (Bucket **) pecalloc(target-nTableSize,
+sizeof(Bucket *), target-persistent);
+
+ p = source-pListHead;
+ while (p) {
+ if (p-nKeyLength) {
+ np = (Bucket *)
+pemalloc(sizeof(Bucket)-1+p-nKeyLength, target-persistent);
+ memcpy(np-arKey, p-arKey, p-nKeyLength);
+ np-nKeyLength = p-nKeyLength;
+ } else {
+ np = (Bucket *)
+pemalloc(sizeof(Bucket)-1+p-nKeyLength, target-persistent);
+ np-nKeyLength = 0;
+ }
+
+ np-h = p-h;
+
+ if (size == sizeof(void*)) {
+ memcpy((np)-pDataPtr, p-pData, sizeof(void *));
+ np-pData = np-pDataPtr;
+ } else {
+ np-pData = (void *) pemalloc(size,
+target-persistent);
+ /* XXX exit?
+ if (!(p)-pData) {
+ pefree(p, (ht)-persistent);
+ return FAILURE;
+ }
+ */
+ memcpy(np-pData, p-pData, size);
+ np-pDataPtr=NULL;
+ }
+
+ nIndex = p-h target-nTableMask;
+ CONNECT_TO_BUCKET_DLLIST(np, target-arBuckets[nIndex]);
+ target-arBuckets[nIndex] = np;
+
+ CONNECT_TO_GLOBAL_DLLIST(np, target);
+
+ if (pCopyConstructor) {
+ pCopyConstructor(np-pData);
+ }
+
+ p = p-pListNext;
}
-if (pCopyConstructor) {
-pCopyConstructor(new_entry);
-}
- p = p-pListNext;
+ } else {
+ p = source-pListHead;
+ while (p) {
+ if (p-nKeyLength) {
+ zend_hash_update(target, p-arKey, p-nKeyLength,
+p-pData, size, new_entry);
+ } else {
+ zend_hash_index_update(target, p-h, p-pData, size,
+new_entry);
+ }
+ if (pCopyConstructor) {
+ pCopyConstructor(new_entry);
+ }
+ p = p-pListNext;
+ }
}
+
target-pInternalPointer = target-pListHead;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Removing ext/sablot from 4.1?
On Sat, Nov 17, 2001 at 09:11:19AM -0500, Sterling Hughes wrote: Hey, Just sending out a feeler message, while I still have some motivation to argue about the future of XSLT (ie, I have other work I should be doing ;) -- I'd like to move ext/sablot from the standard PHP distribution, and update the PHP documentation to the new XSLT API for PHP 4.1 for four reasons: 1) Its a bit confusing with two extensions doing the same thing 2) ext/xslt has become almost stable :) No really... At least it is much more stable than ext/sablot. 3) A bit of an encouragement for users to switch to the new xslt extension which is not only cleaner, but its also signifigantly improved with regards to features and speed. 4) 4.1 is a bit of a compatibility breaking release, I don't know when I'll get the chance again (PHP 5?) i think we should remove it (also from CVS) as it is non maintained and superceeded by a newer, better thingie. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] md5sum() patch
On Fri, Nov 16, 2001 at 11:00:02AM -, James Moore wrote: shouldnt it be file_md5 if we are sticking with out namespace convention. i think james is right: +1 on file_md5 -1 on overloading tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] To Merge, Or Not To Merge?
On Tue, Nov 13, 2001 at 06:51:41AM +0100, Sebastian Bergmann wrote: Should we merge the recent changes to sapi/servlet to the 4_0_7 branch, or not? The changes are required in order to use the Servlet SAPI module with current versions of Tomcat and Cocoon2. It is not stable, though, as I discussed with Zeev at the Conference... i would be +0 if the changes were local to sapi/servlet. but i really don't think it matters all that much as i don't think anybody is using the servlet stuff seriously - and the ppls that might run it will be on HEAD anyway. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1.0
On Sat, Nov 10, 2001 at 04:26:57PM +0200, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. There are basically two options: (a) Go with 4.1.0 based on 4.0.7 the way we originally intended. Pros: It's pretty stable, tested, and pretty much ready to go out the door with minimum extra work. Cons: We get a release out there that is based on code from several months ago, which doesn't contain some bug fixes and changes. (b) Drop the current release branch. Rebranch from HEAD, and release 4.1.0 based on the current CVS. Pros: All of the bug fixes/features go into 4.1.0, we don't release a version based on old code. Cons: Requires a complete new cycle of QA, as lots of key issues changed since we branched. Two major examples that come to mind are the sessions code (trans_sid) and file uploads, which were very significantly changed. My personal opinion is that we should go on with (a), and start the release process for 4.2.0, based on the latest CVS, immediately afterwards. I fear instability in the new sessions/file upload code too much, and don't want to delay 4.1.0 for much longer. Thies, on the other hand, supports option (b), because he's afraid of having a new release based on several months old CVS is going to be a headache. i haven't really changed my mind - but i want a fast decision. as there isn't any clear consens here i think we should release 4.1 as-it-is-with-the-last-showstoppers-fixed and go from there. we should also learn from this and assign a RM for the next release! i mean a real release-master... re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 2x speedup of unserializer
On Sat, Nov 10, 2001 at 05:55:26PM +0100, Sascha Schumann wrote: There is a patch available which boosts the speed of the unserializer significantly. http://pair1.php.net/~sas/unserializer-speedup A large percentage of the speedup was achieved by eliminating the use of a hash for the reference implementation. Credits go to Thies for noticing this. The other part aims at making this code more maintainable for future extensions. To apply the patch, do this: cd php4/ext patch -p0 -N /path/to/patch Please let me know what results you are seeing. And don't forget to Cc me as I haven't been subscribed to the PHP lists for some time. if it passes the make test - just commit to HEAD. we'll find the remaining problems then. and if we decide to rebranch from HEAD for 4.1 we can still back it out! great work sascha, tc PS: i'm going to quantify this stuff one of the next days! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Benjamin Kromann
On Thu, Nov 01, 2001 at 02:56:57AM -0800, Frank M. Kromann wrote: Hi, It is getting late now in CA, but I have to tell you all about Benjamin Kromann, our new son :-) He was born last night at 11:23pm and he is a healthy boy 50 cm long and he weighs 3550 g. Mis mom is doing very well allthough we all need some sleep now. Happy hacking to all of you and I'll be back in a couple of weeks. congrats and have fun with the new lifestyle! tc - Frank -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] expat and Namespaces
On Wed, Oct 24, 2001 at 05:53:23PM -0400, l0t3k wrote: Does the bundled expat handle namespaces ? yes. AFAIK -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #13700: Database Abstraction API
On Wed, Oct 17, 2001 at 12:03:44PM -0400, lo-tek wrote: A new OOP database abstraction layer (in C) is in the works. Should be ready in 2 or so months... how is that going to be different from PEARs or the dbx one? tc [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... From: [EMAIL PROTECTED] Operating system: All PHP version: 4.0.6 PHP Bug Type: Feature/Change Request Bug description: Database Abstraction API There doesn't appear to be a standard database access API in PHP. Instead there's a separate API for each database supported. This is insanity for anyone that wants to be able to support multiple databases. I know there are a number of database abstraction APIs available for PHP but I don't know which one is the best or which one will be continue to be supported in the future. Are there plans to address these issues in a future release of PHP by adopting one of these abstraction APIs into PHP or creating a new one? -- Edit bug report at: http://bugs.php.net/?id=13700edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Forcing trans_sid on?
On Thu, Oct 18, 2001 at 11:04:22AM +0200, Sterling Hughes wrote:
On Wed, 17 Oct 2001, Rasmus Lerdorf wrote:
This code in session.c looks odd to me:
if (!PS(use_cookies) send_cookie) {
PS(apply_trans_sid) = 1;
send_cookie = 0;
}
Basically what this says is that if session.use_cookies is off, trans_sid
will be automatically used regardless of the session.use_trans_sid
setting. This doesn't make sense to me. If I specially turn off
use_cookies and trans_sid in my php.ini file because I want to control
things using my own ?=SID? tags trans_sid getting forced on screws me
over because it will add a second PHPSESSION=. to every link. It
won't break my app, since multiply-defining the session id is ok, but it
sure makes my urls ugly.
What was the logic behind forcing trans_sid on in that case instead of
using the current trans_sid setting?
This was not how it was originally, I'm assuming this happened when
Zeev introduced the session rewrite... I've commited a fix to cvs,
i'll MTB, if no one objects...
sounds right to me.
tc
-Sterling
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [patch] avoiding TSRMLS_FETCH (custom sorting functions)
On Mon, Sep 17, 2001 at 10:18:29AM -0400, Sterling Hughes wrote: Hey, Attached is a patch which replaces the use of libc's quicksort and uses our own custom quicksort for quicksort sorting, giving the immediate benefit of allowing us to pass TSRMLS_CC to the callbacks, and avoid a TSRMLS_FETCH(). The patch also applies the changes to our mergesort implementation. I've put the function in a seperate file in Zend, zend_qsort.c (instead of as a file in php4/main) for two reasons: 1) qsort() is used by Zend 2) its a fairly common function, and re-implemented in order to play nice with Zend's TS mechanism, this should be made available to all programs using Zend. Comments are appreciated and welcome... I'll commit after an appropriate mourning period if no one speaks up. cool - i'm all for it! tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] problems with ob_gzhandler
hi, i have output_handler=ob_gzhandler in my php.ini and just found those messages in my apache error_log: [Fri Aug 31 13:20:47 2001] Script: '/home/thies/shop/login.php' --- /home/thies/devel/php4/main/output.c(240) : Block 0x0821D270 status: Beginning: Overrun (magic=0x402640D8, expected=0x7312F8DC) End: Unknown which is a BadThing(tm). i'm running HEAD - haven't tried PHP_4_0_7. 'cause i don't have the time right now to dig myself i though that reporting it is nearly half as good as fixing it;-) re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: problems with ob_gzhandler
On 31 Aug 2001 15:27:11 +0300, Zeev Suraski wrote: BTW, any chance you're using trans_sid? (can you check if php_session_start_output_handler() ends up being called for some reason?) it does get called. but the session is already there (cookie based) so there's no reason to start the trans-sid thingie. somehow the logic in session.c:917 seems wrong. re, tc At 15:16 31-08-01, Thies C. Arntzen wrote: hi, i have output_handler=ob_gzhandler in my php.ini and just found those messages in my apache error_log: [Fri Aug 31 13:20:47 2001] Script: '/home/thies/shop/login.php' --- /home/thies/devel/php4/main/output.c(240) : Block 0x0821D270 status: Beginning: Overrun (magic=0x402640D8, expected=0x7312F8DC) End: Unknown which is a BadThing(tm). i'm running HEAD - haven't tried PHP_4_0_7. 'cause i don't have the time right now to dig myself i though that reporting it is nearly half as good as fixing it;-) re, tc -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] A couple of session issues
On 27 Aug 2001 01:33:46 +0300, Zeev Suraski wrote: The other issue is a suggestion I want to pitch - right now, if sessions are started after the headers are already sent, we'll get a nice headers-already-sent error. If we have trans_sid enabled (which we will most probably, from now on) - we can check whether the headers are already sent, and if they are, move to use trans_sid instead. Any comments? i tend not to do that. trans-sid is a very different thing from cookies (session id's are populated to foreign-sites via HTTP_REFERRER). i don't think we should default to it. developers should decide themself if they want trans-sid or not. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] A couple of session issues
On 27 Aug 2001 15:25:09 +0300, Zeev Suraski wrote: At 13:40 27-08-01, Thies C. Arntzen wrote: On 27 Aug 2001 01:33:46 +0300, Zeev Suraski wrote: The other issue is a suggestion I want to pitch - right now, if sessions are started after the headers are already sent, we'll get a nice headers-already-sent error. If we have trans_sid enabled (which we will most probably, from now on) - we can check whether the headers are already sent, and if they are, move to use trans_sid instead. Any comments? i tend not to do that. trans-sid is a very different thing from cookies (session id's are populated to foreign-sites via HTTP_REFERRER). i don't think we should default to it. developers should decide themself if they want trans-sid or not. You lost your caps too? :) some time ago already;-) didn't you notice? I'm not sure what you meant in the HTTP_REFERRER issue - can you explain it? At any rate, developers still can decide whether or not they want if you are on a site that uses trans-sid for sessions the HTTP_REFERER on the next visited site will contain your session-id. trans_sid, by using the existing php.ini setting. makes sense - i just don't want a new changed default behaviour of PHP. if i run a cookie based session and for some weird reason i have a stray character in one of my pages i do not want PHP to switch to trans-sid - i want to get notified (Headers already sent) and fix my bug. tc Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #12898: Memory Leaks when using LOB Fields
these's no known mem-leak in that code.. please send a short testcase that demonstrates you problem (20 lines) also - could you please update to 4.0.6 and try again? re, tc On 22 Aug 2001 14:05:33 +, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Linux, Debian, Woody PHP version: 4.0.5 PHP Bug Type: OCI8 related Bug description: Memory Leaks when using LOB Fields I use PHP 4.0.5-2, compiled under Debian/Woody wit OCI8 support. Used with Apache as Module (libphp4.so) When using OciFetchStatement or OciFetchInto there is a memory leak, (on my page 30MB per Pageview) i have tried not to use oci_return_lobs, and use $lob-free() bot no changes. -- Edit bug report at: http://bugs.php.net/?id=12898edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Output Compression Issues
On 16 Aug 2001 15:26:09 +0300, Zeev Suraski wrote: - Output compression should probably check that the content type is text/*, and not perform compression otherwise that means adding another sapi call - but i think it would make sense. - We can look into sending the content length header from the output compression callback if ithe output is not send as chunks we should do so - the original code for that (10 lines) was added by me and taken out by you a few days later when you added the chunking support. Can anybody think of good reasons not to send the content-length header in case we're performing output buffering? if we flush the output-buffer at the end of the request (= no chunking) we should set the content-length as it greatly decreases latency on slow network-connection to be able to us keep-alives! tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Output Compression Issues
On 16 Aug 2001 21:37:11 +0300, Zeev Suraski wrote: At 21:27 16-08-01, Thies C. Arntzen wrote: On 16 Aug 2001 15:26:09 +0300, Zeev Suraski wrote: - Output compression should probably check that the content type is text/*, and not perform compression otherwise that means adding another sapi call - but i think it would make sense. Yep. - We can look into sending the content length header from the output compression callback if ithe output is not send as chunks we should do so - the original code for that (10 lines) was added by me and taken out by you a few days later when you added the chunking support. Ah, good point. That's exactly what I meant if somebody can think about good reasons not to do it :) Chunking is quite important, and there's no way we can know in advance how many bytes we're going to end up having. Unless we add in another output buffer. as i said, if we know that we didn't chunk any output before we can set the cl-header - and we should. if we have chunked output we cannot set the header and so we shouln't set the header;-) tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
On Wed, Aug 08, 2001 at 09:20:55PM +0300, Zeev Suraski wrote: My top of the list is: $_REQUEST $_REQ would be even nicer - and less to type without hiding the meaning. $_EVIL (Andi and I think it's really pretty good, but we both figured we'll end up going with a different alternative :) evil might cause some moral/religious problems for some ppls, i don't think anything in PHP should be called like that. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: To deprecate dl() or not.. (Was: something messy.. :)
On Tue, Aug 07, 2001 at 09:13:16AM +0200, Jani Taskinen wrote: First, I'm 100% with Zeev here, kill dl()! It's evil. Second, I had an idea related to this discussion. I have been compiling PHP with almost every extension in the CVS (excluding the win32 specific) plus couple of 'renegade' extensions and all of them as 'static' extensions. Before I start to wonder into the land of Zend Magic, I wanted to ask first before I (again) waste my time creating something nobody likes/needs.. :) Would it be stupid to have a possibility to disable a static extension on startup? (for CGI) Either as php.ini directive or as command line option or both. It takes couple of seconds now to run some short script like this: ?php echo 'Foo\n'; ? on the command line.. :) i bet this is the pure load-time of your php-executable (loading a lot of shared libs). tc --Jani On Tue, 7 Aug 2001, Zeev Suraski wrote: I disagree in two levels. First, I think that saying We can't protect people from their stupidity, so let's lift all bars is just plain wrong and a bad approach in a real world situation. Sure, it's true, but we can definitely reduce the risks involved in common mistakes that people make. Not bulletproof, but sometimes simply hinting people not to go around places where shots are fired is good enough. On the second level, there are several other reasons not to keep dl() which aren't related to security or preventing people from doing the wrong things. These are: - Slow performance, encourages slow app writing - Complicates the development of extensions and the engine - Will not work in thread safe mode All in all, dl() is simply bad, in just about every level. Zeev At 00:03 07-08-01, George Schlossnagle wrote: In a few words: For a webserver: ban dl() For generic scripting: keep dl() What's really the point of protecting people from their stupidity. If you're going to keep it in the generic scripting engine (which I think has lots of value), why not keep it in the webserver engine as well. There are plenty of php extensions which, imho, operate way to slow to called on a busy production site. Does that mean they should be eliminated? No, it means they should just be used with a 'buyer-beware' mentality. George -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
thies Mon Aug 6 09:36:09 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c incomplete_class.c
php_incomplete_class.h var.c
/php4/ext/wddx wddx.c
Log:
we can no longer register internal-classes once the script is started.
therefore the incomplete class is now registered at MINIT time.
How it's not possible all of a sudden?
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, Aug 06, 2001 at 10:34:34AM -0500, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. don't think there's an API for that. we would have to add the MODULE_NUMBER to the class-entry and then (when unloading the module) also destroy the classes that that module defined. i think constants and functions already do this. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] incomplete class broken?
hi,
the following code breaks php:
?php
class tubu { }
$thies = unserialize('O:1:a:0:{}');
?
X-Powered-By: PHP/4.0.7-dev
Content-type: text/html
../../php4/Zend/zend_hash.c(176) : Freeing 0x084B3A54 (64 bytes), script=../ser2.php
Last leak repeated 1 time
../../php4/Zend/zend_compile.c(1532) : Freeing 0x084B39AC (4 bytes),
script=../ser2.php
../../php4/Zend/zend_language_scanner.l(1144) : Freeing 0x084B390C (5 bytes),
script=../ser2.php
[Sun Aug 5 13:44:17 2001] Script: '../ser2.php'
---
../../php4/Zend/zend_opcode.c(117) : Block 0x084B3988 status:
Beginning: Overrun (magic=0x08450298, expected=0x7312F8DC)
End: Unknown
---
[Sun Aug 5 13:44:17 2001] Script: '../ser2.php'
---
../../php4/Zend/zend_hash.c(548) : Block 0x084B39C0 status:
Beginning: Overrun (magic=0x40B49080, expected=0x7312F8DC)
End: Unknown
---
[Sun Aug 5 13:44:17 2001] Script: '../ser2.php'
---
../../php4/Zend/zend_hash.c(548) : Block 0x084B3A30 status:
Beginning: Overrun (magic=0x40B49040, expected=0x7312F8DC)
End: Unknown
---
if you comment out the tubu class everything works. i'm not
too sure if this is due to saschas work in var.c or some
changes in the engine.
does anybody have a clue what might be wrong?
re,
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] incomplete class broken?
On Sun, Aug 05, 2001 at 01:46:35PM +0200, Thies C. Arntzen wrote:
hi,
the following code breaks php:
after some more testing:
it seems that one can no longer call
zend_register_internal_class when the script is already
executing.
my testscript unserializes an object from a class that has
no definition loaded, so we call
php_create_incomplete_class() to setup our incomplete
class. this used to work just fine...
...
zend_class_entry *php_create_incomplete_class(TSRMLS_D)
{
zend_class_entry incomplete_class;
INIT_OVERLOADED_CLASS_ENTRY(incomplete_class, INCOMPLETE_CLASS, NULL,
incomplete_class_call_func,
incomplete_class_get_property,
incomplete_class_set_property);
BG(incomplete_class) = zend_register_internal_class(incomplete_class TSRMLS_CC);
return (BG(incomplete_class));
}
...
this together with (atleast) one user-level class will cause
the mentioned crash. i tend to think that something in zend
is causing this. zeev, andi?
BTW: if i call php_create_incomplete_class() from
MINIT(basic_functions) the problem goes away.
tc
?php
class tubu { }
$thies = unserialize('O:1:a:0:{}');
?
X-Powered-By: PHP/4.0.7-dev
Content-type: text/html
../../php4/Zend/zend_hash.c(176) : Freeing 0x084B3A54 (64 bytes), script=../ser2.php
Last leak repeated 1 time
../../php4/Zend/zend_compile.c(1532) : Freeing 0x084B39AC (4 bytes),
script=../ser2.php
../../php4/Zend/zend_language_scanner.l(1144) : Freeing 0x084B390C (5 bytes),
script=../ser2.php
[Sun Aug 5 13:44:17 2001] Script: '../ser2.php'
---
../../php4/Zend/zend_opcode.c(117) : Block 0x084B3988 status:
Beginning:Overrun (magic=0x08450298, expected=0x7312F8DC)
End:Unknown
---
[Sun Aug 5 13:44:17 2001] Script: '../ser2.php'
---
../../php4/Zend/zend_hash.c(548) : Block 0x084B39C0 status:
Beginning:Overrun (magic=0x40B49080, expected=0x7312F8DC)
End:Unknown
---
[Sun Aug 5 13:44:17 2001] Script: '../ser2.php'
---
../../php4/Zend/zend_hash.c(548) : Block 0x084B3A30 status:
Beginning:Overrun (magic=0x40B49040, expected=0x7312F8DC)
End:Unknown
---
if you comment out the tubu class everything works. i'm not
too sure if this is due to saschas work in var.c or some
changes in the engine.
does anybody have a clue what might be wrong?
re,
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
