Re: [PHP-DEV] ODBC Prepare
This is really a support question and is being asked on the wrong list. But in light of that... PHP's odbc_prepare function should work with the '?' option. It really isn't the one deciding this though, as it's more your ODBC Driver. As far as PEAR is concerned, I have little insight into that aspect of PHP. Your best bet is to ask PEAR developers or read the source. On Monday, February 10, 2003, at 11:48 AM, Adam Voigt wrote: According to a manual I found on the web for call's to SQLPrepare (referenced in ext/odbc/php_odbc.c) you can implant ? in place of variables for statement execution. PearDB makes reference to this on: http://pear.php.net/manual/en/core.db.tut_execute.php So my question is, is PHP's ODBC programming just not setup to handle this (and is Pear doing this manually with PHP) or am I mis-understanding the way the library works in PHP? Thanks, Adam Voigt [EMAIL PROTECTED] --- Dan KalowskyI've learned to fake it, http://www.deadmime.org/~dankand just smile along. [EMAIL PROTECTED]- Candy, [EMAIL PROTECTED] Iggy Pop -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5 mailing list
To all concerned, I would like to request that yet again the PHP5 mailing list be made public and no longer kept private. Given that comments in the past few hours have centered around the existence of the mailing list, it seems rather absurd to continue the secrecy notion. To those who will say it is open for joining, I submit to you the following considerations. First there is no mention of said mailing list existing on the mailing-list tab of the PHP main web site. Second there is still no publicly viewable record of what has transpired on the mailing list (which means the 'read the archives' comment is futile). I for one find it really annoying to find changes to PHP being done without discussion. Only later to find through an IRC channel what was done and why. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature Request #5919 case-insensitive version ofstr_replace()
I'd tip my hat towards implementing it. Pollita has a good point on consistency and for those who don't know regex's. On Wed, 29 Jan 2003, Sara Golemon wrote: I may be wrong since I haven't profiled this, but my understanding is that str_replace is much faster than doing either of the regex replacements. For that reason alone, there is a use for it. Normally it would be quite faster, however once case sensitivity is added to the mix I believe the speed difference would be minimal. I don't even see the speed difference as an issue as much as (A) simplicity for the user who hasn't figured out regex yet, (B) consistency (we have 'i' versions of most other string functions, why not this one?) The parameter accepting still needs to be fixed though, I copied most of the str_ireplace code from str_replace and forgot to clean that section up and make it nicer. I'll save that for *if* a quorum can be reached to include it at all. On a related topic, the 'boyer' option of str_replace isn't even documented. That alternate method of performing str_replaces look like it's a bit more efficient (no benchmarkes atm) but I'm wondering if there's a specific reasons why it wasn't documented yet. -Pollita --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using IMAP with SSL
Within the cvs HEAD there has been a change made recently to use the --with-imap-ssl tag if the cclient was built with SSL capabilities. Unfortunately this breaks the build on my end rather drastically as default Darwin builds do not use the /path/openssl/all of it's toys go here method, but rather /usr/lib/libssl*.* and /usr/include/openssl/*.h methods. So this leaves me with the question, does anyone have an idea on how to fix this properly before I start hacking at it? All responses of 'change your OS' nature will be ignored :) --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?
Then discontinue it. End of discussion. This is an open source project, and I see little to no-advantage to it's use outside of creating a rather vile aftertaste in the mouths of those developers who are not invited. I've heard the arguments for the list, and I can only say they are valid reasons. But you're now making PHP a political project rather than a software project. Thanks. This is the sort of thing I don't want to have to deal with in my personal time. If you want a private list, take PHP out of the Open Source. If you want to cut down on the signal/noise ratio then moderate the list, but don't make it private and invite only. Zeev no matter how you see it or say it, the inclusion of members into a private mailing list is an exclusive ranking. You may claim otherwise, but all such claims by members of such group will more than likely be disregarded. On Thursday, January 23, 2003, at 11:38 AM, Rasmus Lerdorf wrote: I had nothing to do with that limited php5 list. I thought that was completely bogus myself and argued against it. --- Dan KalowskyCause fear is strong and love's http://www.deadmime.org/~dankfor everyone, who isn't me. [EMAIL PROTECTED] - Burden In My Hand, [EMAIL PROTECTED] Soundgarden -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Win32 builds dead?
Seem to be dead on building ext/rpc (fresh CVS). ext/rpc/php_rpc.h(45) : error C2061: syntax error : indentifier 'rpc_objects_new' ext/rpc/php_rpc.h(45) : error C2059: syntax error : ';' ext/rpc/php_rpc.h(45) : error C2059: syntax error : 'type' --- Dan KalowskyI've learned to fake it, http://www.deadmime.org/~dankand just smile along. [EMAIL PROTECTED]- Candy, [EMAIL PROTECTED] Iggy Pop -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
On Thursday, January 2, 2003, at 05:08 AM, John Coggeshall wrote: When it comes to bug reporting/fixing, perhaps it's feasible to completely separate bug reporting for each module from PHP itself? For example, if each module is maintained completely separately from PHP with it's own version # then there should also be a separate bug reporting system for bugs found with that module. I tend not to see this as the real issue. The bug system can be adapted to our needs as we see fit. The bigger issue is the QA team time, energy, and effort that can be expended to all these test scenarios. This type of decision though will have to be made by the PHP/QA team, and not really by PHP-DEV. If this is of concern to you (developers), I suggest you (developers) become active in the QA process. I really don't see this being an issue any different for PHP Developers than currently setup. Which is support only exists for the latest PHP engine (hence the please try newer version bug responses popularity). When I look at PECL, I envision a system where modules are completely separated from the PHP core. Each module and their maintainer(s) (whomever they are) deal with their own bugs for that module, modules have minnimum PHP core versions for which they work with, etc. We could make this easier by providing a source-forge type of cookie-cutter bug tracking system for each module, and perhaps by making the modules themselves clearly independent of PHP. I'd like to see a system for modules where what modules PHP uses is not defined at compile-time at all by a ./configure statement. Rather, what modules are being used are defined in some sort of configuration file (where the configuration parameters for those modules are also located) and the modules are loaded dynamically. I should be able to go download the GD module and stick it in a subdirectory of /usr/local/lib/php and then edit my modules.conf (or something) file: module name=gd Allow_jpeg=true Allow_tiff=false /module Just remember the idea right now is to move things into PECL to get ready for an eventual version freedom from PHP, but that is not happening just yet. Stig Bakken has suggested this in the past, and you'll find it in archives, that this would be taking the first step towards, working out a lot of the bugs if found and getting the process to iron out. Please realize this change also removes the PHP idea of anyone can fix/add/modify to an extension mantra, and forces it to a realm of per extension release manager/authority. While I like this idea (something I and few others have advocated for awhile), it takes a rather 94 degree turn from how PHP has been developed for the last few years. But it also removes the need to worry about what is enabled by default :) 1) Faster and easier installations of PHP By removing all of those compile-time ./configure options it will make PHP much easier to compile and install. Problems with a single module at compile-time won't stop a user from getting PHP running, and if there is a problem when the module is dynamically loaded it will be easier to figure out what's going wrong. This isn't necessarily the right track to take. Remember that Windows users do not have the need/use of a compiler on their local machines always. As such, a system for distributing a binary is required. This has been hashed out, and Stephen Esser was at one time working on implementing it. Please see the archives for more information about this. --- Dan KalowskyThought I'd visit the club, http://www.deadmime.org/~dankGot as far as the door. [EMAIL PROTECTED] - Don't Get Around Much Anymore, [EMAIL PROTECTED]Ella Fitzgerald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Cutting down on the list of receipients here... Philip please do not put this paragraph into the documentation. If there is any sure fire way to ensure that the latest version of PHP WON'T be installed on a system... it's to encourage end users to contact their system administrator. Although I don't have any better solution at this time... give me another 18 hours to free my brain of things and I might do much better at this. On Wednesday, December 18, 2002, at 05:16 PM, Philip Olson wrote: So every tutorial and documentation on this would have to say this right? Ask your sysadmin what the CGI and CLI versions of your PHP are called, they could be anything as there is no standard. For the purpose of this (tutorial|documentation), we'll call CLI php-cli and CGI php-cgi. Same goes for all cgi scripts, they'll work some places but not others... And various RPM's would have different naming schemes depending on the maintainers preference. Regards, Philip On Wed, 18 Dec 2002, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. -Andrei http://www.gravitonic.com/ * Quantum Mechanics: The Dreams of Which Stuff is Made. * -- 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 --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 when?
Actually I'd say don't roll 4.3 until the New Year. You're going to get the holiday break for many students coming up in a few days. This will give them (me) a large amount of free time to get back to hacking and checking source/bugs. More than that, I tend to think releasing stuff near holidays is a bad idea... no one around to fix things that go really bad, etc etc. On Monday, December 9, 2002, at 04:24 AM, Andi Gutmans wrote: Hi, I'd like to start working towards a beta of ZE2 but it seems that 4.3 is still lingering and I'd like to wait until after 4.3. What's happening with that? Shouldn't we get it out before Christmas? If any bad bugs creep in that'd mean we can use the relatively silent 2-3 weeks following Christmas to fix them. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyMomma take this badge offa me, http://www.deadmime.org/~dankI can't use it anymore. [EMAIL PROTECTED]- Knockin on Heavens Door, [EMAIL PROTECTED]Bob Dylan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New SNMP function names
+1 for me Although I do remember the reasoning for it, it doesn't mean I like the use of the snmpv3 naming scheme either. So if anyone has any better suggestions for these, I'd still like to hear them. On Wednesday, December 4, 2002, at 08:49 AM, Derick Rethans wrote: Hello, while browsing the CVS I found that the following functions were added to the CVS recently: + PHP_FE(snmpv3get, NULL) + PHP_FE(snmpv3walk, NULL) + PHP_FE(snmpv3realwalk, NULL) + PHP_FALIAS(snmpv3walkoid, snmpv3realwalk, NULL) + PHP_FE(snmpv3set, NULL) But those functionnames don't adhere to our nameing guidelines. As those are new functions I propose to change them to the following, to be more consistent with all other functions: snmpv3get - snmp3_get snmpv3walk - snmp3_walk snmpv3realwalk - snmp3_real_walk (or snmp3_walk_oid) snmpv3set - snmp3_get also, there is no need to introduce an alias for a newly created function so I guess we just should drop it. I'd like to make those proposed changes ASAP as they are also added in the PHP_4_3 branch which gets closer to release everyday. regards, Derick -- --- -- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ --- -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyCause fear is strong and love's http://www.deadmime.org/~dankfor everyone, who isn't me. [EMAIL PROTECTED] - Burden In My Hand, [EMAIL PROTECTED] Soundgarden -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Java extension fixes
Comments on the patch. Don't redefine DL_ERROR, this should already be defined by the ZEND engine, but just check to make sure ;) All of your build problems are known problems. If you can fix them, excellent! Just wondering if this has been tested against windows where the most prevalent errors seem to be the improper loading/unloading of the JVM. On Monday, November 25, 2002, at 01:00 AM, Tony J. White wrote: I'm made a stability fix to the PHP Java extension. A full description of the changes as well as the updated java.c file (and patch) can be found here: http://tjw.org/php_java/ Can someone please add this to CVS or should I contact Sam Ruby (the orignal author) to do it? -Tony -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyMomma take this badge offa me, http://www.deadmime.org/~dankI can't use it anymore. [EMAIL PROTECTED]- Knockin on Heavens Door, [EMAIL PROTECTED]Bob Dylan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine
password) - Parameters: $server - RDM Server name $user - database user name $password - user's password Returns: connection handle Description: This function will connection to the RDM Server identified by $server. The $user and $password must be valid users on the server. birdstep_close($conn) - Parameters: $conn - connection handle to close Returns: TRUE if successful, FALSE if an error occurred. Description: This function will close the specified connection to the RDM Server birdstep_exec($conn, $sql) - Parameters: $conn - database connection handle $sql- SQL statement to be executed Returns: Result index if successful, Zero if an error occurred. Description: This function will execute the $sql statement on the server identified by $conn birdstep_fetch($result) - Parameters: $result - result set index (from birdstep_exec()) Returns: TRUE if successful, FALSE if an error occurred. Description: This function will retrieve the next row from a result set. birdstep_fetch_array($result) - Parameters: $result - result set index (from birdstep_exec()) Returns: Associative array of column values with column names as key names. Description: This function will retrieve a row from a result set and return the results as an associative array. The column names will be assigned to the key names. The data values will be assigned to the array elements. birdstep_result($result, $index) - Parameters: $result - result set index (from birdstep_exec()) $index - column index to be retrieved Returns: The value of the column specified by $index in the result set, $result. FALSE if an error occurred. Description: This function is used to retrieve a column value from the current row in the result set. birdstep_freeresult($result) - Parameters: $result - result set index (from birdstep_exec()) Returns: TRUE if successful, FALSE if an error occurred. Description: This function will free a result set that has been previously allocated using the birdstep_exec() function. birdstep_autocommit($conn) - Parameters: $conn - database connection handle Returns: TRUE if successful, FALSE if an error occurred. Description: This function will enable the auto-commit feature of RDM Server. birdstep_off_autocommit($conn) - Parameters: $conn - database connection handle Returns: TRUE if successful, FALSE if an error occurred. Description: This function will disable the auto-commit feature of RDM Server. birdstep_commit($conn) - Parameters: $conn- database connection handle Returns: TRUE if successful, FALSE if an error occurred. Description: This function will commit changes to the database during a transaction. birdstep_rollback($conn) - Parameters: $conn- database connection handle Returns: TRUE if successful, FALSE if an error occurred. Description: This function will rollback changes to the database during a transaction. birdstep_num_fields($result) - Parameters: $result - result set index (from birdstep_exec()) Returns: Number of columns in result set, or FALSE if an error occurred. Description: This function will retrieve the number of columns in the result set. birdstep_field_name($result $index) - Parameters: $result - result set index (from birdstep_exec()) $index - column index of column name to retrieve Returns: Column name, or FALSE if an error occurred. Description: This function will retrieve the name of the column represented by $index. OPEN ITEMS 1. LONG VARCHAR Max Length The maximum length for a LONG VARCHAR column is currently a #define. This should be moved to an INI entry and managed through the Zend INI interface. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyTonight I think I'll walk alo
Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)
On Monday, November 11, 2002, at 02:39 PM, Andi Gutmans wrote: Well I assume lots of extension maintainers are using int's for all sorts of things. I'm not sure it's a good idea to try and catch every last place. In any case, even if we convert everything then my suggestion still stands because it'd help us catch places which aren't defined correctly. Maybe I've missed the point, or I'm too tired to connect neurons today. But what is the point of trying to correct for places which aren't defined correctly? This seems like a rather odd/bad way of looking at this. If you've defined incorrectly, it just shouldn't work. I'd rather lean towards Jason's suggestion --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extending DB2 odbc support
Tim, I've been maintaining the ODBC extension for a bit. While I welcome the addition of new ODBC functionality, I am hesitent to add in functions that are not ODBC compliant to the code (i.e. db2_connect(), or some such). If you can make the functions generic enough that they can be executed through ODBC, then feel free to submit the patches to the list and myself to get them included in. On Friday, November 8, 2002, at 07:12 AM, tim wrote: Hi, I am writing php applications which use php's builtin ibm-db2 support through odbc. However there are some DB2-specific extensions which are not included in php's DB2 support. I am interested in adding this functionality to php. Who should I talk to in order to avoid duplication of work? How would I best implement this in parallel with php's odbc layer? Thanks, Tim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyThought I'd visit the club, http://www.deadmime.org/~dankGot as far as the door. [EMAIL PROTECTED] - Don't Get Around Much Anymore, [EMAIL PROTECTED]Ella Fitzgerald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extending DB2 odbc support
On Friday, November 8, 2002, at 08:34 PM, tim wrote: If I take the existing php odbc code and add the ibm-db2 specific extensions, what are the chances of this making it into the main php distribution as a new extension ( ext/ibmdb2 ) ? Is it a good idea to maintain a separate cvs tree on sf.net so it gets some testing first? I cannot comment directly on the creation of ext/ibmdb2, although I'd rather see something like that moved to PECL (where everything will be eventually). As for separate CVS trees, while it sounds like a good idea, it's my opinion that it's not a good thing. If you can detail/outline the changes you want to make a bit more it might help in the discussion. Right now there is another user extending ODBC to better support IBM DB2 systems. I am looking to create something similar to oracle's php extension. What would be the advantages of doing this? What sort of extra functionality is there that implementing such a system will provide to DB2 systems? I'm just trying to get a feel for what you're reasonings, and level of implementation will be. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
It's interesting to me that this topic is brought up again and again about once every 3 or 4 months. The same points are rehashed each time, and the same result is reached, nothing is changed about mbstring. I believe this is partially because developers ask questions about mbstring, and receive no definitive answer to them (see the archives for a few examples). Historically, I have been against mbstring being enabled by default. My feelings towards anything being enabled by default, unless it is considered core functionality, is pretty negative though. On the flip side though, what exactly were these concerns brought up at the PHP Conference? Is it possible to share them with those of us who were not able to attend? Please include as much detail as possible. On Friday, November 8, 2002, at 01:06 AM, Moriyoshi Koizumi wrote: Hi, Now the transparent encoding conversion is disabled by default, and so is the function overloading. And the extension is not likely to cause any harm to other tests; recently some test failures related to output handlers were reported in fact, but the problem have been properly avoided. Then why do we even have to continue the same discussion? Is it the big deal how many people use mbstring? Now mbstring is not just for CJK people, because it also offers numerous unicode functionality. mb_convert_case(), contributed by Wez, is one of the examples. Besides I wonder why such dangerousness has not been warned up to now if that's the case. Moriyoshi Andrei Zmievski [EMAIL PROTECTED] wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? Comments are welcome. -Andrei http://www.gravitonic.com/ * We are not a clone. * -- 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 --- Dan KalowskyThe future is always uncertain, http://www.deadmime.org/~dankand the end is always near. [EMAIL PROTECTED]- Roadhouse Blues, [EMAIL PROTECTED] The Doors -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compile PHP-CODE
Yes, it's true, it is possible to compile PHP source code. My best friend's sisters' boyfriend's brother knew this guy who saw this other guy compile it once at 31 flavors.* On Wednesday, November 6, 2002, at 10:16 AM, Betim Deva wrote: Does anybody know about the possibilities of compliling the php source code * Extra points if you know where that butchered quote comes from! :) --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Java Extension
: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
On Saturday, November 2, 2002, at 12:38 PM, Robert Twitty wrote: its capabilities and useless in certain situations. Another alternative was to use a commercial ODBC driver management system on UNIX. Sadly, it was not in the budget for this endeavor, and the PHP odbc extensions could use some work in terms of ease of use. I tend to disagree with this bit. The ODBC system is no more complicated than any of the other database interfaces you find on PHP. There is the needed introduction of a odbc.ini file, but thats no more confusing than the need for a TNS Names with Oracle. If you have a problem with the way ODBC is implemented, please feel free to request new features via the bug system, submit patches, or emailing me directly. I have in the past asked numerous times for input on the extension only to receive silence. More importantly, what commercial ODBC system are you looking at? unixODBC, and iODBC work wonderfully for UNIX, and both are free and integrated completely with PHP. Because I was determined to use PHP (I really dislike using JSP / JDBC on UNIX, and IIS / ASP is out of the question), I decided to create my own solution. Since I have a substantial amount of experience in programming directly with the Win32 ODBC API and TCP/IP, I decided to create a service that runs on a Win32 platform that can communicate with any platform via TCP/IP. The service uses a home grown protocol that allows a client to access any database that the service can see via the ODBC drivers that are installed on the computer which it resides. In other words, it allows a PHP client on UNIX to access a database using the ODBC drivers installed on a Windows NT / 2000 server. It is nothing more than a middle man service for Win32 ODBC. The name of the service is called ODBTP (Open Database Transport Protocol), and no there is not a RFC for this protocol. Thus far, I have successfully accessed MS-SQL, Oracle and Sybase databases via ODBTP. This sounds like a lot of work to re-implement the ODBC system. * Supports all data types, including nvarchar, ntext, varchar(255), char(255), datetime, and bigint. I'd like to know how you got around this. It's proven to be a bigger headache in supporting for ODBC than I would have imagined. * Stored procedure execution, parameter passing (including NULL's) and output retrieval. Nice.I haven't worked on this yet at all for PHP ODBC. * UNICODE data is processed using UTF-8 encoding (important since PHP strings are not UNICODE) This is being worked upon. Hopefully I'll have free time again soon. * No discovered memory leaks or buffer overflow possibilities. If you know of any in the current PHP ODBC, let us know. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP and Java
On Thursday, October 24, 2002, at 09:46 PM, Marc Richards wrote: 5) Who is responsible for development of this extension? Sam Ruby wrote it originally, but alas he seems to have disappeared from maintaining it. A few people have done matiaince on it, you can see the bonzai tree, or cvs logs for this. --- Dan KalowskyI've learned to fake it, http://www.deadmime.org/~dankand just smile along. [EMAIL PROTECTED]- Candy, [EMAIL PROTECTED] Iggy Pop -- 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 Thursday, October 17, 2002, at 04:09 AM, Thies C. Arntzen wrote: you mean renaming the oci8 extension - could be done... but i personally see no pressing reason for doing so. Any chance we can rename the configure option from --with-oci8 to just --with-oci? Since it does work with 9 (fairly well I might add), and 7? --- Dan KalowskyThe future is always uncertain, http://www.deadmime.org/~dankand the end is always near. [EMAIL PROTECTED]- Roadhouse Blues, [EMAIL PROTECTED] The Doors -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Plan for PHP 5.0
On Sunday, October 13, 2002, at 09:12 PM, Stig S. Bakken wrote: On Mon, 2002-10-14 at 02:18, Dan Kalowsky wrote: While I don't have the full time to answer everything, this gets both a +1 and a -1 from me. Great idea, but PECL doesn't work everywhere, for example I believe OSX does not yet support it (that being my main platform of concern). If someone gives me an account on an OSX box (or even better, puts an OSX box into my mailbox! ;-) I will make it work. Talk to Marko (Markonen on IRC). His is on a more permanent connection than mine, plus he's in a relatively same time zone as you, which should make things easier ;) For more information on this see an email from Marko Karripinen from July 26th 2002 detailing the original idea/method for doing this. It has been since toned down a bit, but follows the same idea. You're missing the point :-) Nope, I'm not. If you remember I said I'm +1 and -1 for this. The minus one being the statements said before. I don't believe jumping into using PECL without a start of a secure binary distribution method is a wise idea. And by start I mean an actual working template. But I do agree that movement forward on PECL is going to need a drastic step (i.e. what you're suggesting). --- Dan KalowskyI got my mojo working, but it http://www.deadmime.org/~dankjust ain't working on you [EMAIL PROTECTED]- Mojo, [EMAIL PROTECTED]Muddy Waters -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Plan for PHP 5.0
On 14 Oct 2002, Stig S. Bakken wrote: Step #3: Pickle all extensions! Move all extensions except ext/standard w/dependencies to PECL. Yes, everything. We can add CVS aliases to be able to check out like today easily, but this is the first step towards parallelizing the release process. When extensions are pickled, they are given version numbers (0.5 for experimental, 1.0 for the rest unless something suggests otherwise). While I don't have the full time to answer everything, this gets both a +1 and a -1 from me. Great idea, but PECL doesn't work everywhere, for example I believe OSX does not yet support it (that being my main platform of concern). More importantly there is no secure method of distribution for PECL, especially with binaries (Windows). There has been a lot of talk in the #php.bugs channel about this, and there were even a few emails with regards to this very issue on php-dev. A solution has been arrived at, but it has not been implmented yet due to various reasons (mostly time). Before anything at all can/should be pickled, a secure distribution method needs to be in place. For more information on this see an email from Marko Karripinen from July 26th 2002 detailing the original idea/method for doing this. It has been since toned down a bit, but follows the same idea. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Anyone confirm this?
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: Mon Oct 7, 2002 8:24:14 AM US/Eastern
To: [EMAIL PROTECTED]
Subject: #19798 [NEW]: mistype in source
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.2.3
PHP Bug Type: Unknown/Other Function
Bug description: mistype in source
php-4.2.3/ext/standard/quot_print.c
---
while ( str_in[i] )
{
switch (str_in[i])
{
case '=':
if (str_in[i+1] str_in[i+2]
isxdigit((int)str_in[i+1])
isxdigit((int)str_in[i+1]) )
{
str_out[j++] = (php_hex2int((int)str_in[i+1]) 4 )
+ php_hex2int((int)str_in[i+2]);
i += 3;
}
---
may be lines above must looking like:
---
if (str_in[i+1] str_in[i+2]
isxdigit((int)str_in[i+1])
isxdigit((int)str_in[i+2]) )
---
???
--
Edit bug report at http://bugs.php.net/?id=19798edit=1
--
Try a CVS snapshot:
http://bugs.php.net/fix.php?id=19798r=trysnapshot
Fixed in CVS:
http://bugs.php.net/fix.php?id=19798r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=19798r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=19798r=needtrace
Try newer version:
http://bugs.php.net/fix.php?id=19798r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=19798r=support
Expected behavior:
http://bugs.php.net/fix.php?id=19798r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=19798r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=19798r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=19798r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19798r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19798r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=19798r=isapi
---
Dan KalowskyI'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin.
[EMAIL PROTECTED]- Streets of Philadelphia,
[EMAIL PROTECTED]Bruce Springsteen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scratching the 4.3 branch
Since for some reason I didn't get Zeev's original message, I'll just hack in responses here... :) On Sunday, October 6, 2002, at 05:01 AM, Derick Rethans wrote: On Sun, 6 Oct 2002, Zeev Suraski wrote: I think that given the circumstances, we should scratch the 4.3 branch and stick to the main branch for this particular release, at least until we're very close to the release itself. The vast majority of CVS traffic going on these days is bug fixes anyway, so creating the branch only makes it more difficult to keep up - you have to keep the two branches in sync. Two options I see here. Close down CVS HEAD development, and force everyone to work on the branch, or ditch the branch. I don't know how feasible option 1 is. Option 2 is extremely easy to do. The problem though isn't the keeping in sync part. It's the working to clean up bugs, verifying code and functionality parts. Neither option here will deal with that. Maybe it's time to opening up the php5 module then... people would be able to work on experimental stuff there without messing up the stable module. It might be a psychological thing but I think it's appropriate here. I disagree with you on this one Derick. Doing this really just skirts the problem around, and doesn't address it until a later date. Here is an option though. Release RC1. We know it's buggy, we know it's got a lot of problems, and we know that we don't know them all. The stigma that snapshots are unstable isn't going to be changed in the next few days, so lets work with that. By releasing RC1 we can have (potentially) a larger test audience working on making the RC2 better as there seems to be less of a stigma against RCs. There is no real reason why we can't go through multiple RCs this time around... other than time. So lets take advantage of that. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Multiple copies of files in the source... why?
It was just pointed out to me that ext/rpc might be a good way to implement some java fixes for PHP. So upon taking a look, I discovered that ext/rpc/java exists, and it is (was) an exact copy of the ext/java directory tree. Why is this? And why isn't it be kept in sync with ext/java? --- 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
Re: [PHP-DEV] PHP 4.3 branch
On Saturday, October 5, 2002, at 04:30 PM, Sebastian Bergmann wrote: Well, not really. But knowing that HEAD would become PHP 5 could maybe encourage projects like rewriting stuff like ext/domxml, ext/java or sapi/java for PHP 5. Do you really need an artificial reason, such as a PHP 5, to make this happen? If you want any of this to happen, please start doing the work. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c php_pgsql.h
On Wednesday, October 2, 2002, at 12:10 AM, Yasuo Ohgaki wrote: I don't mind to have alias like pg_result_seek() or have only pg_result_seek(). I would rather see it named pg_result_seek as it is more consistent with what this function accomplishes. It also opens the door for ODBC to follow in these steps a bit more. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] 64 bit PHP (long vs int problems)
After having run with this patch for a few days now, it seems to be rather stable. I would like to see this commited, possibly even for the 4.3 branch. I think re-adding some 64 bit capabilities would be a good thing... although I also understand this may make the RC process a bit longer. Mind you, that yes the extensions all need to be audited a bit for this too first... but getting the core Zend/PHP system working would be nice :) On Wednesday, September 25, 2002, at 11:52 PM, Jason Greene wrote: longint.patch --- Dan KalowskyI got my mojo working, but it http://www.deadmime.org/~dankjust ain't working on you [EMAIL PROTECTED]- Mojo, [EMAIL PROTECTED]Muddy Waters -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] patch to restrict database access for ext/pgsql
On Thursday, September 26, 2002, at 06:36 PM, Jon Parise wrote: Isn't it generally better (where better means more secure, efficient, and easily maintained) to handle database access control using PostgreSQL's native access mappings? Yep. Thus why it was created :) --- 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
[PHP-DEV] PREAD yet again
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. 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
[PHP-DEV] configure checks
Is there any real reason why during configure we check for dlopen about 5 times, each time not using the previously cached value? --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PREAD yet again
Thies (et all) Please read up on the bug http://bugs.php.net/bug.php?id=15983edit=1 It contains all the details about this. I have mentioned this on the list at least once before, and received no answers... so suggested fixes would be appreciated. On Thursday, September 19, 2002, at 12:52 PM, Thies C. Arntzen wrote: 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 --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: documentation revisioning (was Re: socketsextension...pecl it)
On 12 Sep 2002, Brian Lalor wrote: It should be released in conjunction with PHP and a new version put up when bugs are fixed and the old versions should be available just like the old versions of PHP are. I don't know what the stats are for how many people are using older versions of PHP versus those on the bleeding edge, but speaking from experience, it sure would be nice to have documentation on hand for the version I'm using without having to refer to caveats about which version the array commands were changed in (another real-world example). This is already done in a lot of stable/non-experimental documentations (see imap_getquota for an example). --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ODBC and PHP
On Tue, 10 Sep 2002, Shane Caraveo wrote: Ok, then I would be for ODBC 3 for PHP 5 as the standard. An ODBC 2 extension can be shuttled out to PECL for those who may need it. But for BC issues, there is still the nameing convention. I would personaly prefer that the odbc functions stay odbc_*, rather than to start iterating through odbc2...odbc3 and so forth. Don't know an easy solution right now. Shane Shane, I agree that the naming convention should stay the same. I'm only calling it that now so I can test it and reference it with other people. :) Dan Kalowsky wrote: On Tue, 10 Sep 2002, Shane Caraveo wrote: Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. This is a tricky question really. Theoretically, yes it should be possible to allow this. You may run into issues with some of the result sets, but the connections should still be the same. You couldn't really do it with a function like odbc_set_version, as my understanding of ODBC states you must declare which version type you are using at compile time. If you have some documentation stating otherwise, I'd be interested in reading it. The reality is, I don't know. All ODBC3 drivers should be able to utilize the deprecated functionality just fine, but the mapping is an unknown and dependent upon vendor implementation. Going the other way, of course, is not going to work. But I don't see a reason to keep such BC at this point. The problem with the current system can be seen with bugs in the result sets. The one area specifically mentioned above. Users are still going to ask Why doesn't my select work? while using NTEXT or something non-compliant. The CURSOR type cannot be changed with the current system. This in itself leads to a slower implementation, a (unnecessarily) larger memory footprint, and in DB2 systems a memory leak. Hey at least I haven't gone as drastic as I originally thought, and asked to drop support specific for things like DB2, Solid, Empress, etc, and only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC). :) Although I still think that would make the most sense and be the easiest to support on our end of things. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: ODBC and PHP
To Whom It May Concern, I've been working for the last few months (delayed often, but mostly the last few weeks) on what I've been tenatively calling ODBC2. Basically this is what I'd like to see PHP v 5 have as it's default ODBC system. Some general notes about it: - It will break BC. I have tried to conform and keep things the same, but I'm not making any promises to keep BC at this time. - It will support ODBC v 3.0 and greater only. With the needs of many DBs to include larger typesets (like TEXT, NTEXT, IMAGE, etc) and UNICODE, I see this as being a necessity. Some implementation notes: - So far my testing is being done using iODBC, unixODBC, and Windows ODBC drivers. I have no way of checking any of the others... help on this front would be appriciated. Some of the features already added to it: - Ability to control the ODBC environment handles before and after a connection is created. - Ability to specify a CURSOR for use in statements. - More strongly enforced safe_mode restrictions. - The ability to connect to data sources without being defined locally. - A user can force the PHP system to create a new connection now. - An attempt to make the ODBC API look more like the MySQL/PostgreSQL APIs feature setwise. - An option for the user to turn on which can allow dynamic sizing of a result set text field (currently it's static). - Use of the default_user, default_db, and default_passwd in the php.ini. - Hopefully more detailed error messages. - Native support for returning results from functions, and SQL based constructs (outside of SELECT statements). If you have any specific functionality you would like to see, please send it to me, and I will see what I can do about adding this in. I would like to add this into the current PHP system, to allow users to start playing with and testing as well. Well probably just as soon as I finish some more of the odbc2_exec/odbc2_execute() cleanups. This code is not optimized in any way, shape, or form. It's not even believed to work with a lot of systems. Because of this, I would like to hear back commentary back on any suggested recourse from those who've done this already. Hopefully this will prove to be a useful change, and people will be happy :) As always send your comments to me. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ODBC and PHP
On Wed, 11 Sep 2002, Wez Furlong wrote: I know this probably isn't the kind of comment you want just now, but... If this is to support ODBC v3+, why not call the functions odbc3_xxx instead of odbc2_xxx? I think this could help prevent some head-scratching a little later down the track. Well technically it's to move PHP's ODBC support further along. I've just been calling it ODBC2 locally here to make life easier when I talk to other people (as in v2 of the PHP ODBC lib). What I'm thinking I'd really like to see is ODBC move to PECL or something like that, to allow me to keep it in a different release schedule (as ODBC standards don't change that rapidly). But I've heard some complaints against such ideas, so I haven't pushed it (yet). Anyways naming convention can be changed very easily. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springstreen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ODBC and PHP
On Tue, 10 Sep 2002, Shane Caraveo wrote: Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. This is a tricky question really. Theoretically, yes it should be possible to allow this. You may run into issues with some of the result sets, but the connections should still be the same. You couldn't really do it with a function like odbc_set_version, as my understanding of ODBC states you must declare which version type you are using at compile time. If you have some documentation stating otherwise, I'd be interested in reading it. The reality is, I don't know. All ODBC3 drivers should be able to utilize the deprecated functionality just fine, but the mapping is an unknown and dependent upon vendor implementation. Going the other way, of course, is not going to work. But I don't see a reason to keep such BC at this point. The problem with the current system can be seen with bugs in the result sets. The one area specifically mentioned above. Users are still going to ask Why doesn't my select work? while using NTEXT or something non-compliant. The CURSOR type cannot be changed with the current system. This in itself leads to a slower implementation, a (unnecessarily) larger memory footprint, and in DB2 systems a memory leak. Hey at least I haven't gone as drastic as I originally thought, and asked to drop support specific for things like DB2, Solid, Empress, etc, and only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC). :) Although I still think that would make the most sense and be the easiest to support on our end of things. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- 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
Commited. On Mon, 9 Sep 2002, Michael Mauch wrote: Hi, http://bugs.php.net/bug.php?id=18640 describes the problem that some Oracle versions (patch levels) on Tru64 seem to have some OCILob* functions in the libocijdbc8 library instead of in the usual libclntsh. This makes the PHP build fail with unresolved symbols. http://bugs.php.net/bug.php?id=14193 also seems to be related. Although this seems to be all Oracle's fault, I suggest to link against libocijdbc8 if it is available. I tested the patch below with Oracle 8.1.7 and 9.0.1 on Tru64 5.1, Oracle 8.1.6 on Tru64 4.0f, Oracle 8.1.7 on Solaris 7, and with Oracle 8.1.6 on Linux/ix86. Only the Oracle 8.1.x on Tru64 needed the patch, but I wanted to make sure that the additional library does no harm to the others. The patch also applies cleanly against 4.2.3, and against the current CVS version (HEAD) if you use --ignore-whitespace (GNU patch). Can somebody please add this? If this is not the right way to send a patch, please tell me. Regards... Michael --- php4-STABLE-200209050900/ext/oci8/config.m4.orig Fri Nov 30 19:59:46 2001 +++ php4-STABLE-200209050900/ext/oci8/config.m4 Fri Sep 6 16:23:01 2002 @@ -68,6 +68,9 @@ 8.1|9.0) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) + if test -f $OCI8_DIR/lib/libocijdbc8.so ; then + PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) + fi PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) ;; --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springstreen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sockets extension
Because the user can see how active such functionality is by looking at the CVS logs, and doing a search on php-dev conversations. While the authors have decided to mark it experimental doesn't mean it will ever not be experimental. Not to continue a flame war, but this is Open Source, and it is done on free time. Because you the user feels you'd like to use such functionality it's not typically a concern for the developers. Often times this functionality is added to make their own lives easier, or to try an experiment with something. Take a look at the iD software policy: it'll be ready when it's ready. Thats all there is to it :) On Mon, 9 Sep 2002, NAIK,ROSHAN (HP-Cupertino,ex1) wrote: Between 15 days and 15 months. Looking at the CVS its been 19 months since the EXPERMENTAL file was last modified for sockets. No offense intended but, sometimes people dont seem to like to be asked such obvious questions by users. I realize that people in open source are not working for money but this attitude may be a little extreme. The obvious meaning behind the question was is this piece under active development?. Users like to know such things so that they can have reasonable expectations from what they are using or make alternate plans. And this list is the most reasonable place for asking something like that. Bundling functionality into the distribution and tagging them as experimental...its a way of giving end users hope to see something concrete sooner or later...so why flame over it when the user comes back asking how it is doing ? --Roshan --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springstreen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #19286 [NEW]: header() Control Char Injection
On Sun, 8 Sep 2002, Stefan Esser wrote: PS: Is php-dev censored? Or why disappeared my mail about MD5/GPG signs of PHP 4.2.3... Is there some autofilter on group says everytime: we do it the next time? Naw I saw it and you bug report on it. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springstreen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [BUG] bugs.php.net bugs
Yeah I've had this problem too since it's moved. So far my answer has been to reload the page, and it goes away. Although I've made mention of it to Derick and Jani. On Fri, 6 Sep 2002, Devon O'Dell wrote: Hi All, I hope this is the right place to post this, I couldn't find a valid place to put this on bugs.php.net. Please correct me if this isn't the right place. Browsing through the bug list, I sometimes get mysql errors when browsing searching for bugs using the input field at the top right. The errors are as follows: Warning: mysql_numrows(): 4 is not a valid MySQL result resource in /local/Web/sites/php-bugs-web/search.php on line 119 and Warning: mysql_fetch_array(): 4 is not a valid MySQL result resource in /local/Web/sites/php-bugs-web/search.php on line 139 I've recieved this twice, once searching for FreeBSD and once searching for ming, however, it does not occur every time, and I've not been able to successfully reproduce it (it happens always on accident) Additionally (while I'm thinking about it), whenever I try to search the whole site on php.ca, I get an error stating: *There was an error executing this query.* Please try later. You can see this at http://www.php.ca/search.php?show=nosourcepattern=something_stupid Feel free to substitute anything for something_stupid (including valid php functions). Greetings, Devon O'Dell --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Windows builds and ftp.c
Warnings in the Windows FTP builds, which may be of concern (or may not be): ftp.c(650) : warning C4018 : '!=' signed/unsigned mismatch ftp.c(1565) : warning C4018 : '!=' signed/unsigned mismatch --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Windows builds and ftp.c
Is that the general consensus still? It seems rather odd to support it, but not care about it. I don't see that patch doing anything evil though in any case. On Thu, 5 Sep 2002, Joseph Tate wrote: I believe that the consensus with warnings on the windows builds is that we don't care. We're not going to cast where it isn't necessary. So you might want to revert your last patch. Joseph -Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 5:21 PM To: PHP Development Mailing list Subject: [PHP-DEV] Windows builds and ftp.c Warnings in the Windows FTP builds, which may be of concern (or may not be): ftp.c(650) : warning C4018 : '!=' signed/unsigned mismatch ftp.c(1565) : warning C4018 : '!=' signed/unsigned mismatch --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pread solutions needed
Please read bug: http://bugs.php.net/bug.php?id=15983 As it states, currently non-i386 Linux boxen are having difficulty with the session functionality. Mainly because of the pread/pwrite functions. The check passes, and the HAVE_PREAD/HAVE_PWRITE flags are given. One of the users has discovered that this is actually a bug in the glibc implementations on non-i386 machines. There is a message (linked in the bug report) that states this has been fixed in CVS as of Tues, 30th July 2002. So what does the official PHP stance become? Do we want to put a series of #defines around this code section to make sure Linux/non-i386 doesn't use this code? Or do we just ignore it and wait for the new glibc code to filter down? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pread solutions needed
On Tue, 3 Sep 2002, Zeev Suraski wrote: Why do we use pread in the first place? I don't know. It looks like we have options for both pread and non-pread capable systems (ext/session/mod_files.c:270). I personally don't see any specific reason to use the HAVE_PREAD version, if we have something that works universally. At 21:27 03/09/2002, Dan Kalowsky wrote: Please read bug: http://bugs.php.net/bug.php?id=15983 As it states, currently non-i386 Linux boxen are having difficulty with the session functionality. Mainly because of the pread/pwrite functions. The check passes, and the HAVE_PREAD/HAVE_PWRITE flags are given. One of the users has discovered that this is actually a bug in the glibc implementations on non-i386 machines. There is a message (linked in the bug report) that states this has been fixed in CVS as of Tues, 30th July 2002. So what does the official PHP stance become? Do we want to put a series of #defines around this code section to make sure Linux/non-i386 doesn't use this code? Or do we just ignore it and wait for the new glibc code to filter down? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~dank a little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. Is --disable-something is too hard to get used to? Yes it is. Why? Because PHP has so many options at this point, finding which modules are automatically enabled isn't terribly easy. More to the point, it's a PITA to find out during the build you forgot to explicitly disable a feature. In general it is easier to enable a feature than to disable a feature (witness Clippy). --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Sun, 1 Sep 2002, James Cox wrote: I vote to remove mbstring as a default module. +1000 And for those who say that i could just disable it -- well, the converse is true. Let us STOP burdening default builds with crap that is unlikely to be used. Another voice of reason! Welcome! --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/exif config.m4
I'll throw my -1 on adding anything to be enabled by default. I've argued this before, and I will continue to argue for less things to be enabled by default. On Thu, 29 Aug 2002, Jani Taskinen wrote: On Wed, 28 Aug 2002, Marcus Börger wrote: Having exif not enabled by default doesn't harm development at all. If people want exif, they can enable it just fine. Adding more 'bloat' (this has nothing to do with the usefulness) to the default compilation is not a good thing, for example we could have enabled sockets, sysvshm, sysvsem... too by default. Derick Of cause exif doesn't affect php development in any way! I meant here that PECL development must not hurt php development. -1 for enabling any extensions by default.. Especially this kind of extensions which are not really widely used.. --Jani --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
Adding to the ever expanding list... On Wed, 21 Aug 2002, Sterling Hughes wrote: Hi all, Following on from the recent debug_backtrace discussion, and the discussion about just what we are releasing next and so on, I'd just thought I would make a couple of comments about PHP 4.3 and about what I think (IMHO) should be the goals of PHP 5. I'm currently reviewing the streams code, to make sure that the API is good enough for a release: there are a couple of things that I want to tidy up ready for PHP 4.3: o Add a set-blocking-flag method to the generic stream operations, So that non-blocking IO can be enabled on any stream that it makes sense to do so. (IIRC, there is a bug in the DB, or this deficiency was mentioned on the list). o Tidy up persistent streams support. (I need some help from someone that really knows what they are doing here). This is important, because I'm not sure that persistent sockets (pfsockopen) are actually working in HEAD ATM. o Implement a filter API, so that filters can be stacked over a stream. I've mentioned this before; it will be useful to stack things like base64, charset conversion, zlib/bzip compression and crypto over a stream - potentially multiple filters. I don't think that this will take too long to implement (perhaps by the weekend). o Implement stat() and readdir() for ftp. I think http will be too hard to achieve in time for 4.3. PHP 5 - Zeev raised the issue of figuring out what we want to be in PHP 5. Well, I can't think of (m)any fancy new features for PHP 5 that we haven't already got in HEAD, but to get the ball rolling, this is my take on how PHP 5 could/should look: Current HEAD, stabilized. This includes things like the new build system, streams, enhancements to post/file uploading, domxml and so on. ZE2, feature complete. (New OO, better rpc/com/java, try/catch, delegation, etc. etc.) To me, that sounds really pretty good. Yes, it's just HEAD with ZE2, but I think it's almost what will be PHP 5. A couple of additions that would make it more attractive: o PEAR/PECL CA fully established. I know that we are aiming to get this off the ground for PHP 4.3, but I'm sure we can improve it for PHP 5. o Bundle Brads php-soap extension, and market PHP 5 as being Web Service Enabled. o Finish off Harald's RPC extension, which should provide Seemless web services. Move Brad's extension into PEAR/PECL, for those people who need to use soap in a manly, yet sexy way. o We really need some people to look at PHP's XML support. Yeah, currently, it kinda-sorta works, however, we can really do it better. I suggest using the DOMXML extension as a base (so much work has been done already). Test strongly, Add full LibXML support, standardize the API to DOM's api, and bundle libxml libxslt with PHP version 5 (removing expat bundling). o See if we can get cURL bundled for PHPv5. o In that vein, get a proper standardized bundling scheme setup, that makes it easy to bundle/unbundle software with PHP. o Update ODBC to v 3.7 support. The current v2 support just doesn't cut it anymore with users wanting to use IMAGE, TEXT, NTEXT, and other various large data field types, and unicode. I started this, but my resource books were ummm... acquired by another and never returned. o Decide if we are or are not going to support the iPlanet system. If we are, it needs to be drastically fixed, if we're not we need to drop it. Really. Look at the bug reports. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
On Wed, 21 Aug 2002, Shane Caraveo wrote: It should simply be marked EXPERIMENTAL, but not removed. On the other hand, it doesn't have to be included in the distribution if it simply does not work correctly. It's apparently been broken since 4.0.5. I did a little bit of patching it up so that it actually compiles and put these fixes into PHP_4_2_0 and HEAD, but nothing is ensuring that it works with completely. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
On Wed, 21 Aug 2002, Pierre-Alain Joye wrote: Works well in 4.1.1 : on : SunOS argiope 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-250 You are the first to report back that I've seen/heard from stating it works. You're even on one of the two major difficulty platforms. Now try using 4.2 ;) --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] odbc_primarykeys return type
Hi Kevin On Sun, 18 Aug 2002, Kevin Gordon wrote: The first two functions return resource and the second two functions return int. Is there any difference? In this case, not really. I think I should probably update some of the documentation it seems. Using a postgresql database odbc_tables works fine. But with odbc_primarykeys I can not find a result. Either A) you've found a bug, or B) you're using it wrong. I'm going to guess B at this time as it does seem to work. Although there is an open bug about it not working for others. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP apxs installs on AIX
On Sat, 17 Aug 2002, Jani Taskinen wrote: It's a bug in libtool. It would be best for everyone (not only PHP project) that it's fixed in it.. Good to have you back. :) Thanks, and will do. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.2.3
Hrm, well a lot of the fixes I've been doing have only gone to head because the belief of no 4.2.3. There are still a few outstanding bugs I'd like to see fixed before things we RC. Sfox and I (mostly her though) have been looking at the dbm_* functionality on Windows. We're questioning if it ever worked at all. I can run through a list if there is a desire to see one. On Sat, 17 Aug 2002, Zeev Suraski wrote: I'd like to raise the option of releasing 4.2.3 again. I believe that it would be quite a while before 4.3.0 is out, and there are quite a few fixes in the 4.2 branch that should make the userbase as soon as possible, especially the Windows userbase. I think that releasing 4.2.3 can be done within approximately one week, with one RC, barring unexpected surprises. Opinions? Zeev --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.2.3
I have to disagree, a LOT of bug fixes have gone in. Honest I can run through the list of things I think should be done, and a list of things that I think should be back ported. None of it is new functionality, all of it is fixes to bugs. And I still think the Tru64/AIX issues will need to be solved as well. On Sat, 17 Aug 2002, Zeev Suraski wrote: I'd really like to avoid waiting this time, though (the enemy of good is better...). Even if we release 4.2.3 as it is in the branch, without any further fixes, it's significantly better than 4.2.2. Translating this into action - my personal preference is to release the RC as early as tomorrow. Zeev At 16:20 17/08/2002, Dan Kalowsky wrote: Hrm, well a lot of the fixes I've been doing have only gone to head because the belief of no 4.2.3. There are still a few outstanding bugs I'd like to see fixed before things we RC. Sfox and I (mostly her though) have been looking at the dbm_* functionality on Windows. We're questioning if it ever worked at all. I can run through a list if there is a desire to see one. On Sat, 17 Aug 2002, Zeev Suraski wrote: I'd like to raise the option of releasing 4.2.3 again. I believe that it would be quite a while before 4.3.0 is out, and there are quite a few fixes in the 4.2 branch that should make the userbase as soon as possible, especially the Windows userbase. I think that releasing 4.2.3 can be done within approximately one week, with one RC, barring unexpected surprises. Opinions? Zeev --- Dan KalowskyA little less conversation, http://www.deadmime.org/~dank a little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.2.3
I disagree that it should go out as is, very strongly at that too. Some fixes not in the 4.2 branches: - ODBC no longer crashes on Windows upon unloading - while not fully tested, ext/java now works for 1.4 JDK's - various memory leak fixes provied by Ilia (pack being one of them) - a few misc fixes for Win32 platforms - nsapi build fix which allows it to build and reported run again (although I still think we need to decide if we can kill this support) - numerous domxml bug fixes have been added as well. - QTDOM fix to allow it to compile again and run again This is one yet to be made, but: - a potential fix to have 'make install' work on AIX machines again finally. These are just bug fixes. I don't want to see new functionality added to PHP for a potential 4.2.3, but I do want to see a LOT of these bugs squished. There is a fix, why go and release another version of PHP with known and non-fixed bugs in it? It still doesn't seem to compile and work on 64-bit arch's. But yet again, there are numerous reasons why we should move to release PHP 4.3. The biggest of which in my book is, it supports OSX! While possibly a minor issue to many of the users on this list, it's becoming a more significant issue, especially with Jaguar/10.2 being released in a few days. There have been numerous fixes to all the code bases in an effort to get support for OSX implemented into them (ext/java still being a bastard). On Sat, 17 Aug 2002, Zeev Suraski wrote: I think it makes good sense to release 4.2.3 as-is (after a short QA cycle, that will ensure we didn't introduce any new bugs). If 4.2.3 becomes a larger project, with more pre-requisites, I don't see it happening (if it will not be simple, it will simply not be). The last time around 4.2.3 died was exactly due to this issue. Zeev At 16:47 17/08/2002, Dan Kalowsky wrote: I have to disagree, a LOT of bug fixes have gone in. Honest I can run through the list of things I think should be done, and a list of things that I think should be back ported. None of it is new functionality, all of it is fixes to bugs. And I still think the Tru64/AIX issues will need to be solved as well. On Sat, 17 Aug 2002, Zeev Suraski wrote: I'd really like to avoid waiting this time, though (the enemy of good is better...). Even if we release 4.2.3 as it is in the branch, without any further fixes, it's significantly better than 4.2.2. Translating this into action - my personal preference is to release the RC as early as tomorrow. Zeev At 16:20 17/08/2002, Dan Kalowsky wrote: Hrm, well a lot of the fixes I've been doing have only gone to head because the belief of no 4.2.3. There are still a few outstanding bugs I'd like to see fixed before things we RC. Sfox and I (mostly her though) have been looking at the dbm_* functionality on Windows. We're questioning if it ever worked at all. I can run through a list if there is a desire to see one. On Sat, 17 Aug 2002, Zeev Suraski wrote: I'd like to raise the option of releasing 4.2.3 again. I believe that it would be quite a while before 4.3.0 is out, and there are quite a few fixes in the 4.2 branch that should make the userbase as soon as possible, especially the Windows userbase. I think that releasing 4.2.3 can be done within approximately one week, with one RC, barring unexpected surprises. Opinions? Zeev --- Dan KalowskyA little less conversation, http://www.deadmime.org/~dank a little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley --- Dan KalowskyA little less conversation, http://www.deadmime.org/~dank a little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 4.2.3
On Sat, 17 Aug 2002, Zeev Suraski wrote: PHP x.y.z has known bugs that are not fixed, for any given x, y and z, since forever, and until the of time. Realize that, and decisions become much simpler. Yes, but again many of these fixes were not applied to the 4_2 Branch because we had been informed that it was dead, long live the 4_3 upcoming branch. That may have been my fault for not appling many of them anyways. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] 4.2.3
Because we aren't always sure what the next version will be. Witness the 4.0.6-4.0.7/4.1 release process. On Sat, 17 Aug 2002, Liz wrote: there should be 'fixed in the next bug-fix release' or 'fixed in the next semi-major release'. How about Will be fixed in version major.minor.buildrelease ?? ie tell them which version it will be fixed in, no confusion at all then --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tru64, snprintf and bug #1298
Yes, that is correct, bug #1298 (it's existed for a LONG time). The user is having some difficulty compiling the Zend libraries for 4.2.2. Mainly it seems that snprintf is turning up as an unresolved symbol. I asked him to grep through the /usr/include looking for it, and the result was nothing. Looking through the code I see PHP has it's own snprintf implementation, and that should suffice. Apparently zend_API.c though doesn't notice it. His fix was to place #include php.h inside the file, and everything worked fine. Does anyone have any more insight into this that they might be able to share? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] #18401 [Opn-Ana]: shuffle() broken (fwd)
Anyone able to confirm or deny the validity of this patch?
-- Forwarded message --
Date: 14 Aug 2002 07:04:50 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: #18401 [Opn-Ana]: shuffle() broken
ID: 18401
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: Arrays related
Operating System: Redhat 7.3
PHP Version: 4CVS-2002-08-12
New Comment:
- if (rnd_idx != cur_elem) {
- temp = elems[cur_elem];
- elems[cur_elem] = elems[rnd_idx];
+ RAND_RANGE(rnd_idx, 0, n_left, PHP_RAND_MAX);
+ if (rnd_idx != n_left) {
+ temp = elems[n_left];
+ elems[n_left] = elems[rnd_idx];
elems[rnd_idx] = temp;
Thanks for detailed report. This diff clearly show where to fix.
Swapping values requires 3 lines!!
Previous Comments:
[2002-08-12 03:10:28] [EMAIL PROTECTED]
I have just tried it with the latest CVS and I still get the same
results. Brad's changes were in a different section of the file.
[2002-08-11 02:30:52] [EMAIL PROTECTED]
I'm pretty Brad has been playing with this code. Can you test again,
and report back with a new snapshot?
[2002-07-18 01:03:51] [EMAIL PROTECTED]
The shuffle() function in the CVS is (still) broken. It does not
correctly generate all possible combinations of the array. (I know this
function was recently updated, this test is with new version.)
Here is a diff to fix the problem:
--- array.c Thu Jul 18 00:50:54 2002
+++ array.new.c Thu Jul 18 00:49:35 2002
@@ -1441,7 +1441,7 @@
{
Bucket **elems, *temp;
HashTable *hash;
- int j, n_elems, cur_elem = 0, rnd_idx, n_left;
+ int j, n_elems, rnd_idx, n_left;
n_elems = zend_hash_num_elements(Z_ARRVAL_P(array));
@@ -1457,13 +1457,12 @@
elems[j++] = temp;
while (--n_left) {
rnd_idx = php_rand(TSRMLS_C);
- RAND_RANGE(rnd_idx, cur_elem, n_left, PHP_RAND_MAX);
- if (rnd_idx != cur_elem) {
- temp = elems[cur_elem];
- elems[cur_elem] = elems[rnd_idx];
+ RAND_RANGE(rnd_idx, 0, n_left, PHP_RAND_MAX);
+ if (rnd_idx != n_left) {
+ temp = elems[n_left];
+ elems[n_left] = elems[rnd_idx];
elems[rnd_idx] = temp;
}
- cur_elem++;
}
HANDLE_BLOCK_INTERRUPTIONS();
Here is some PHP that will reproduce the problem. As you can see the
built-in shuffle() only generates 3 of the 6 possible combinations,
while the userland array_shuffle() correctly generates all 6 with equal
likelyhood.
?php
function array_shuffle($array) {
$i = count($array);
while (--$i) {
$j = mt_rand(0, $i);
if ($i != $j) {
/* swap elements */
$tmp = $array[$j];
$array[$j] = $array[$i];
$array[$i] = $tmp;
}
}
}
function test($function) {
$a = array();
for ($i = 0; $i 1; $i++) {
$p = range(1,3);
$function($p);
$s = join('', $p);
$a[$s]++;
}
print $function\n;
foreach($a as $k = $v) {
print $k: $v\n;
}
}
test('shuffle');
test('array_shuffle');
?
--
Edit this bug report at http://bugs.php.net/?id=18401edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Build warnings on OSX in sockets
Haven't noticed this before, so I'm guessing this isn't a good thing. /Users/dank/Development/php4-cvs/ext/sockets/sockets.c: In function `zif_socket_recvmsg': /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1524: warning: assignment from incompatible pointer type /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1529: warning: assignment from incompatible pointer type /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1578: warning: assignment from incompatible pointer type /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1584: warning: assignment from incompatible pointer type /Users/dank/Development/php4-cvs/ext/sockets/sockets.c: In function `zif_socket_sendmsg': /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1670: warning: assignment from incompatible pointer type /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1698: warning: assignment from incompatible pointer type /Users/dank/Development/php4-cvs/ext/sockets/sockets.c: At top level: /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:115: warning: `php_strerror_buf' defined but not used --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php_error_docref bugs
Running the latest Windows CVS checkout, I get an interesting problem with the php_error_docref output. It seems to cut off the first letter of messages, ala: etwork.php) [a href='http://www.php.net/function.main' Blah blah blah blah. Might be good to fix that. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php_error_docref
A few comments on this. 1) is it possible to cut down on the number of php_error_docref functions to just one? I really don't see a reason for this many different formats. 2) Can we please remove the http://www.php.net/manual/en/blahblahblah; style of use for this? It will tend to force users into one language or another, and not make PHP as friendly/usable to other languages. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main network.c
There was a suggestion, I don't remember if it was agreed upon or not. Regardless as I see it this is still a bug, and until an ini value is added, this shouldn't be allowed out as-is in the next release. If an ini value is added by that time though, it would be nice :) On Tue, 13 Aug 2002, Edin Kadribasic wrote: Hello Dan, Wasn't there an agreement that the timout is going to be a an .ini setting whith a default value of 60? Edin - Original Message - From: Dan Kalowsky [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 4:39 PM Subject: [PHP-CVS] cvs: php4 /main network.c kalowsky Tue Aug 13 10:39:03 2002 EDT Modified files: /php4/main network.c Log: Bug Fix #16113, as reflective of a php-dev convo between wez and iliaa Index: php4/main/network.c diff -u php4/main/network.c:1.57 php4/main/network.c:1.58 --- php4/main/network.c:1.57 Sun Aug 11 07:25:24 2002 +++ php4/main/network.c Tue Aug 13 10:39:03 2002 @@ -15,7 +15,7 @@ | Author: Stig Venaas [EMAIL PROTECTED] | +--- ---+ */ -/* $Id: network.c,v 1.57 2002/08/11 11:25:24 wez Exp $ */ +/* $Id: network.c,v 1.58 2002/08/13 14:39:03 kalowsky Exp $ */ /*#define DEBUG_MAIN_NETWORK 1*/ #define MAX_CHUNKS_PER_READ 10 @@ -515,7 +515,7 @@ sock-is_blocked = 1; sock-chunk_size = FG(def_chunk_size); - sock-timeout.tv_sec = -1; + sock-timeout.tv_sec = 60; sock-socket = socket; stream = php_stream_alloc_rel(php_stream_socket_ops, sock, persistent, r+); -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_error_docref
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote: 2) Can we please remove the http://www.php.net/manual/en/blahblahblah; style of use for this? It will tend to force users into one language or another, and not make PHP as friendly/usable to other languages. NO! First you can simply set docref_root in your ini to point to your local copy of the manual in whatever language and Second it is a problem of the php website. It should automatically redirect from php.net/function.functionname to php.net/manual/yourlanguage/functionname.php I'm not sure I see the point still. What I'm proposing is not allowing: php_error_docref(http://www.php.net/manual/en/function.fopen; TSRMLS_CC, E_WARNING, Spongebob Square Pants rules); as a valid call from within an extension. Because this limits anytime this error occurs to the English manual description only, or any language which is defined really. There is no need for this, as you have provided another option which works much cleaner and better (through the ini options) in my opinion. While the PHP website may have a bug (or two) in it, it's no reason to force end users to be reading languages that they don't know or prefer. I have nothing wrong with: php_error_docref(function.fopen TSRMLS_CC, E_WARNING, Spongebob Square Pants lives in a pineapple under the sea); To me that should be the recommended method, as it will allow the php.ini values for language to override everything nicely, and everyone can see the PHP manual in their desired language. The error of course is still in English but thats another matter. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_error_docref
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote: The point is to be able to direct to external sites not on php.net! For example when a function is just a wrapper around a library then you can use the absolute form of the docref parameter (http://site) to point to the library's website. Okay thats a point I hadn't thought of. Though I'm not sure why we'd be referencing outside sites. Can we then change the CODING_STANDARD example to NOT use the php.net website? Hopefully stopping anyone from using it as a reference to any php-specific documentation, and only for external sites. NULL or #target is best here since it allows the phpdoc group to change their mind for naming the pages. Then again, I don't understand what this parameter is for. If not for the developer to declare which help file this is in, what is the point? Yes I see the anchor tags option, but what is the difference between using an anchor and declaring specifically? It just seems that if this variable is going to be 90% of the time (random guess) NULL, it's not really all the necessary to be included. And judging from the comment by Gabor, the PHPDOC group isn't going to change this format anytime soon. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] odbc setting boneheadedness? (odbc.defaultlrl)
Setting it to 0 should work. Or at least it has in the past. Calling odbc_longreadlen($res_id, value here); should also allow you to override this while running in PHP. A value of zero again is passthrou. Any chance you can share a bit more information about this possible bug? On Mon, 12 Aug 2002, Chuck Hagenbuch wrote: Playing with db-based session handlers today against an ODBC database. Don't worry, it's not production, but it should work, and now it does... except that I had a hell of a time figuring out how to get all of the session data, when sessions get large, back from the db server. I found the odbc.defaultlrl setting pretty quickly, but my first try was to set it to 0 - which, I assumed, would mean no limit (like mssql.textsize). However, it appears that the comment really does _mean_ passthru there. So, is there any way to set it to a no limit value? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] After a few minutes the most aromatic and nice smelling Italian coffee will come out of the exhaustpipe. - Our stove-top espresso pot --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Win32 and ftruncate
Hey list, Any reason that ftruncate has two different implementations on Win32? Please see: ext/standard/flock_compat.h win32/flock.h For more information. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/db db.c
We did a google search and found absolutely nothing with it mentioned. Oddly enough, taking out the #if GDBM_FIX breaks the db functions on FreeBSD On Mon, 12 Aug 2002, Rasmus Lerdorf wrote: Hrm.. I vaguely remember writing this code and dealing with this GDBM_FIX thing 5-6 years ago. If you look in php.h from PHP version 2 you will see this: /* * GDBM_FIX * * Some people have reported problems getting gdbm to work correctly. If * you are seeing a gdbm compatibility problem, try defining this and * let me know if it fixes your problem. If it does, please tell me * which version of gdbm you are using */ /* #define GDBM_FIX 1 */ Hopefully we can safely assume that nobody is using whatever ancient version of gdbm that may have had this problem. -Rasmus On Tue, 13 Aug 2002, Dan Kalowsky wrote: kalowskyTue Aug 13 00:10:31 2002 EDT Modified files: /php4/ext/dbdb.c Log: Fix for Bug #18746 by sfox and I #What is the GDBM_FIX for anyways, we can find it anywhere? Index: php4/ext/db/db.c diff -u php4/ext/db/db.c:1.73 php4/ext/db/db.c:1.74 --- php4/ext/db/db.c:1.73 Fri Jun 28 20:40:34 2002 +++ php4/ext/db/db.cTue Aug 13 00:10:31 2002 @@ -17,7 +17,7 @@ +--+ */ -/* $Id: db.c,v 1.73 2002/06/29 00:40:34 sniper Exp $ */ +/* $Id: db.c,v 1.74 2002/08/13 04:10:31 kalowsky Exp $ */ #define IS_EXT_MODULE #ifdef HAVE_CONFIG_H @@ -38,15 +38,11 @@ #include unistd.h #endif -#ifdef PHP_31 -#include os/nt/flock.h -#else #ifdef PHP_WIN32 #include win32/flock.h #else #include sys/file.h #endif -#endif #if HAVE_FCNTL_H #include fcntl.h @@ -630,7 +626,12 @@ DBM_TYPE dbf; key_datum.dptr = key; +#ifdef PHP_WIN32 + key_datum.dsize = strlen(key+1); +#else key_datum.dsize = strlen(key); +#endif + #if GDBM_FIX key_datum.dsize++; #endif -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] coding standard addition proposal
Hello list, Looking over the commit by Marcus on gd I noticed the #if 0 section on some code. I'd like to propose that the coding standard be updated to NOT do this, but to do something like #if 0_KALOWSKY to make life easier for all running through the code. Yeah I know, you can look in the cvs logs to see who did it, but it makes life a little easier I think to do go with the proposed method. Any +/-1s on this idea? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] coding standard addition proposal
On Sun, 11 Aug 2002, Zeev Suraski wrote: +1 (as long as it's always #if 0_KALOWSKY :) Only on Mondays commits ;) But the reality is whoever is doing the #if 0_ will put their cvs name there. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Comments (Was: [PHP-DEV] coding standard additionproposal)
On Mon, 12 Aug 2002, Yasuo Ohgaki wrote: I'm 0 for this. Since looking up log(annotate) is very easy. If you are using Emacs, Ctrl-x v g other editor users may have harder time, though. Not an editor issue, but more... as we start bundling (sic) more code with PHP, we will run into areas where the original developer has commented out code with #if 0's and so will some of the PHP developers. Which was an original and which one of ours? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.2 on Mac OS X
Jeshua, Please note that PHP 4.2.2 does not officially support OSX (this is in the release notes). The current CVS HEAD does though, where a few of these issues are fixed. Note that I enabled SSL support with my imap build, and I have one instance of the symbol in defined in mail.h - not in lib. I presume this is a imap issue? Are you sure it's enabled? This really isn't a PHP issue but more a linking between IMAP and SSL issue. Undefined symbols: _dyld_object_images I grepped and googled but alas I can not find such a symbol anywhere. I have a hunch that this is an issue for PDFlib. Haven't seen it, haven't gotten to PDFlib yet. dams or markonen? Also, as a side note, when I do a 'make install', the make fails on apxs. It is looking for libphp4.dylib not the created libphp4.so. If I edit config_vars.mk, the make install proceeds just fine. Fixed in CVS. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Odd array problems
My output looks a lot different than yours and I'm not receiving the
notices you are. Same script only on OSX debug from the CLI.
pre /array(3) {
[0]=
string(10)
--br /
[1]=
string(6) br /
[2]=
string(11) After delim
}
End of script
CVS HEAD from earlier this morning (arond 9 am EST).
On Fri, 2 Aug 2002, Chuck Hagenbuch wrote:
With latest CVS (HEAD branch, checked out 10 or so minutes ago), the
following script:
?php
error_reporting(E_ALL);
$text = Before delim.br /\n--br /\nAfter delim;
$parts = preg_split('|(\n--\s*(br /)?\n)|', $text, 2, PREG_SPLIT_DELIM_CAPTURE);
$text = array_shift($parts);
if (count($parts)) {
echo 'pre /'; var_dump($parts);
$text .= $parts[0];
$text .= $parts[2];
}
?
Gives me this output:
array(3) {
[0]=
string(10)
--
[1]=
string(6)
[2]=
string(11) After delim
}
Notice: Undefined offset: 0 in /var/www/array.php on line 10
Notice: Undefined offset: 2 in /var/www/array.php on line 11
But the var_dump() clearly shows that there _are_ elements 0 and 2 in
the array. What am I missing, or is something still off with the array
code?
-chuck
--
hello, I'm a giant cheese, and I'm here to give you a therapeutic massage
---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~danka little more action.
[EMAIL PROTECTED]- A Little Less Conversation,
[EMAIL PROTECTED]Elvis Presley
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Odd array problems
Correction an update from a few mins ago results in the same output as
Chuck's original.
On Fri, 2 Aug 2002, Chuck Hagenbuch wrote:
With latest CVS (HEAD branch, checked out 10 or so minutes ago), the
following script:
?php
error_reporting(E_ALL);
$text = Before delim.br /\n--br /\nAfter delim;
$parts = preg_split('|(\n--\s*(br /)?\n)|', $text, 2, PREG_SPLIT_DELIM_CAPTURE);
$text = array_shift($parts);
if (count($parts)) {
echo 'pre /'; var_dump($parts);
$text .= $parts[0];
$text .= $parts[2];
}
?
Gives me this output:
array(3) {
[0]=
string(10)
--
[1]=
string(6)
[2]=
string(11) After delim
}
Notice: Undefined offset: 0 in /var/www/array.php on line 10
Notice: Undefined offset: 2 in /var/www/array.php on line 11
But the var_dump() clearly shows that there _are_ elements 0 and 2 in
the array. What am I missing, or is something still off with the array
code?
-chuck
--
hello, I'm a giant cheese, and I'm here to give you a therapeutic massage
---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~danka little more action.
[EMAIL PROTECTED]- A Little Less Conversation,
[EMAIL PROTECTED]Elvis Presley
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] share libraries from repository
please direct php help questions to the php-general mailing list. the php-dev list is for the language development itself. On Fri, 2 Aug 2002, [iso-8859-1] Ricardo Javier Aranibar León wrote: Hi List, I need your help. I wrote my classes with php where I defined my objects, then I created my repository in /usr/share/php , in this directory are my clasess. Now, from my directory web I like to call to my classes, then I modified my php.ini (/etc/php.ini) and inserted this line, in the option Paths and Directories include_path = .:/usr/share/php and restart apache. In my page index.php I call to my class with this form ? include (plantilla.class) ? But when I like to see my page I have two message: 1) Warning: Failed opening 'plantilla.class' for inclusion (include_path='.:/usr/share/php') in /usr/local/httpd/htdocs/index.php on line 2 2)Fatal error: Cannot instantiate non-existent class: pagina in /usr/local/httpd/htdocs/index.php on line 3 If somebody can help me I'll thankfull, My box linux is SuSE 7.3, PHP 4.04 and Apache. _ Únase al mayor servicio mundial de correo electrónico: http://www.hotmail.com/es --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] imap quota broken
Jan it is possible to put a fix in to keep some backwards compatibility. I thought about this last night, and I will try to implement it today. If you would test it later today that would be nice. This solution does pollute the array, but it will make old scripts work a bit better. On Thu, 1 Aug 2002, Jan Schneider wrote: OK, thanks for making that clear. Zitat von Dan Kalowsky [EMAIL PROTECTED]: Yes it did. Mainly because the old compatibility was wrong. In the case when a server would respond with multiple resources like so: C: A003 GETQUOTA S: * QUOTA (STORAGE 10 512 MESSAGE 5 256) The imap_get_quota() function would set the usage and limit values to that of the last resource. If there is more than one resource, the last value is NEVER the STORAGE value. The current functionality reflects the proper usage and limit values for all resources, and conforms to RFC 2087. On Thu, 1 Aug 2002, Jan Schneider wrote: One of the lasts commits to the imap quota functions broke backward compatibility with the old imap_get_quota() behaviour. It used to return an array like: array ( 'usage' = 83090, 'limit' = 10, ) but now returns an array like: array ( 'STORAGE' = array ( 'usage' = 83090, 'limit' = 10, ), ) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: solaris8 + php4.2.2 = memory corruption?
I do not get the Bus Error (this was fixed last night by Zeev). And if
you correct the $id bug in this script, it works just fine ... at least on
OSX.
This is from CVS HEAD.
On Thu, 1 Aug 2002, Sulka Haro wrote:
On Mac OS X, php 4.2.1 terminates without output with the given example.
Running a copy of PHP 4.3.0 CLI I updated/compiled from CVS today,
the output is 97Bus error.
Anyone with enough info to say what's similar to both Solaris and OS X?
sulka
At 19:58 +0300 1.8.2002, Anti Veeranna wrote:
I finally tracked this down and it turned out to be a bug
in the code. I also was mistaken when I said that the
code works in 4.1.2/Solaris. It didn't.
To make a long story short:
?php
$foo = array(
97 = 97,
);
$str = ;
foreach($foo as $id = $id)
// ^^
{
$str .= $foo[$id];
};
print $str;
?
---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~danka little more action.
[EMAIL PROTECTED]- A Little Less Conversation,
[EMAIL PROTECTED]Elvis Presley
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bus Error again
Zeev, It's still there... same bt, same spot. That crazy Bus Error... on debug. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] imap quota broken
Yes it did. Mainly because the old compatibility was wrong. In the case when a server would respond with multiple resources like so: C: A003 GETQUOTA S: * QUOTA (STORAGE 10 512 MESSAGE 5 256) The imap_get_quota() function would set the usage and limit values to that of the last resource. If there is more than one resource, the last value is NEVER the STORAGE value. The current functionality reflects the proper usage and limit values for all resources, and conforms to RFC 2087. On Thu, 1 Aug 2002, Jan Schneider wrote: One of the lasts commits to the imap quota functions broke backward compatibility with the old imap_get_quota() behaviour. It used to return an array like: array ( 'usage' = 83090, 'limit' = 10, ) but now returns an array like: array ( 'STORAGE' = array ( 'usage' = 83090, 'limit' = 10, ), ) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bus error on CVS Head
Hi,
Building PHP and running a test script with the CGI or CLI on my MacOSX
machine results in a a Bus Error upon script completion.
I have made a fresh checkout, built clean (with a cvsclean and buildconf),
yet the problem continues. Find a backtrace below, and the error. Any
suggestions/ideas are welcome to be heard.
./configure --enable-debug --without-mysql
--with-imap=/Users/dank/Development/imap-2001a
Script (but it's really any script):
?php
if (!is_dir(/tmp/reports)) mkdir(/tmp/reports, 0777);
if (touch(/tmp/reports/test.txt)) {
print file modification time has been updated \n;
} else {
print could not modify time \n;
}
$fp = fopen(/tmp/reports/test.txt, w);
fwrite($fp, some stuff\n);
fclose($fp);
print end of script \n;
?
backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0017dba4 in _zval_dtor (zvalue=0x664f78, __zend_filename=0x2015f4
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c,
__zend_lineno=277) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:43
43 CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0 0x0017dba4 in _zval_dtor (zvalue=0x664f78, __zend_filename=0x2015f4
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c,
__zend_lineno=277) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:43
#1 0x001704dc in _zval_ptr_dtor (zval_ptr=0x667d84,
__zend_filename=0x2019f0
/Users/dank/Development/php4-cvs/Zend/zend_variables.c,
__zend_lineno=158) at
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c:277
#2 0x0017e0bc in _zval_ptr_dtor_wrapper (zval_ptr=0x667d84) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:158
#3 0x001881dc in zend_hash_destroy (ht=0x667cc8) at
/Users/dank/Development/php4-cvs/Zend/zend_hash.c:543
#4 0x0017dc5c in _zval_dtor (zvalue=0x667c88, __zend_filename=0x2015f4
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c,
__zend_lineno=277) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:51
#5 0x001704dc in _zval_ptr_dtor (zval_ptr=0x667de4,
__zend_filename=0x2019f0
/Users/dank/Development/php4-cvs/Zend/zend_variables.c,
__zend_lineno=158) at
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c:277
#6 0x0017e0bc in _zval_ptr_dtor_wrapper (zval_ptr=0x667de4) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:158
#7 0x001881dc in zend_hash_destroy (ht=0x290004) at
/Users/dank/Development/php4-cvs/Zend/zend_hash.c:543
#8 0x0016ffa8 in shutdown_executor () at
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c:173
#9 0x0017f6d8 in zend_deactivate () at
/Users/dank/Development/php4-cvs/Zend/zend.c:596
#10 0x00139e38 in php_request_shutdown (dummy=0x0) at
/Users/dank/Development/php4-cvs/main/main.c:788
#11 0x0019f8e8 in main (argc=2, argv=0xb9fc) at
/Users/dank/Development/php4-cvs/sapi/cgi/cgi_main.c:1100
#12 0x244c in _start ()
#13 0x227c in start ()
(gdb)
---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~danka little more action.
[EMAIL PROTECTED]- A Little Less Conversation,
[EMAIL PROTECTED]Elvis Presley
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bus error on CVS Head
Interesting side note pointed out by Brad, this only happens when the
--enable-debug option is given to configure.
On Tue, 30 Jul 2002, Dan Kalowsky wrote:
Hi,
Building PHP and running a test script with the CGI or CLI on my MacOSX
machine results in a a Bus Error upon script completion.
I have made a fresh checkout, built clean (with a cvsclean and buildconf),
yet the problem continues. Find a backtrace below, and the error. Any
suggestions/ideas are welcome to be heard.
./configure --enable-debug --without-mysql
--with-imap=/Users/dank/Development/imap-2001a
Script (but it's really any script):
?php
if (!is_dir(/tmp/reports)) mkdir(/tmp/reports, 0777);
if (touch(/tmp/reports/test.txt)) {
print file modification time has been updated \n;
} else {
print could not modify time \n;
}
$fp = fopen(/tmp/reports/test.txt, w);
fwrite($fp, some stuff\n);
fclose($fp);
print end of script \n;
?
backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0017dba4 in _zval_dtor (zvalue=0x664f78, __zend_filename=0x2015f4
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c,
__zend_lineno=277) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:43
43 CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0 0x0017dba4 in _zval_dtor (zvalue=0x664f78, __zend_filename=0x2015f4
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c,
__zend_lineno=277) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:43
#1 0x001704dc in _zval_ptr_dtor (zval_ptr=0x667d84,
__zend_filename=0x2019f0
/Users/dank/Development/php4-cvs/Zend/zend_variables.c,
__zend_lineno=158) at
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c:277
#2 0x0017e0bc in _zval_ptr_dtor_wrapper (zval_ptr=0x667d84) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:158
#3 0x001881dc in zend_hash_destroy (ht=0x667cc8) at
/Users/dank/Development/php4-cvs/Zend/zend_hash.c:543
#4 0x0017dc5c in _zval_dtor (zvalue=0x667c88, __zend_filename=0x2015f4
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c,
__zend_lineno=277) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:51
#5 0x001704dc in _zval_ptr_dtor (zval_ptr=0x667de4,
__zend_filename=0x2019f0
/Users/dank/Development/php4-cvs/Zend/zend_variables.c,
__zend_lineno=158) at
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c:277
#6 0x0017e0bc in _zval_ptr_dtor_wrapper (zval_ptr=0x667de4) at
/Users/dank/Development/php4-cvs/Zend/zend_variables.c:158
#7 0x001881dc in zend_hash_destroy (ht=0x290004) at
/Users/dank/Development/php4-cvs/Zend/zend_hash.c:543
#8 0x0016ffa8 in shutdown_executor () at
/Users/dank/Development/php4-cvs/Zend/zend_execute_API.c:173
#9 0x0017f6d8 in zend_deactivate () at
/Users/dank/Development/php4-cvs/Zend/zend.c:596
#10 0x00139e38 in php_request_shutdown (dummy=0x0) at
/Users/dank/Development/php4-cvs/main/main.c:788
#11 0x0019f8e8 in main (argc=2, argv=0xb9fc) at
/Users/dank/Development/php4-cvs/sapi/cgi/cgi_main.c:1100
#12 0x244c in _start ()
#13 0x227c in start ()
(gdb)
---
Dan Kalowsky A little less conversation,
http://www.deadmime.org/~dank a little more action.
[EMAIL PROTECTED] - A Little Less Conversation,
[EMAIL PROTECTED] Elvis Presley
---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~danka little more action.
[EMAIL PROTECTED]- A Little Less Conversation,
[EMAIL PROTECTED]Elvis Presley
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Nobody needs 4.3 with 1000 new features, everybody needs a PHP Version that has at least as few bugs as 4.0.4pl1. At least a 4.0.2pl1 fixing the so far closed bugs would be great. I have _SERIOUS_ problems with theses bugs for example: I would disagree with this statement. PHP 4-CVS currently makes support for MacOSX possible. While I see this being not so important in your world, it is in mine, and to a large number of up and coming PHP users. With OSX 10.2 coming out in the next few weeks this can, and will be, an important thing to have working. Unfortunately, it cannot be backported, because it utilizes the new build system. But regardless, Sebastian your points are all valid on why a 4.2.3 should be made. I think you forget things though like the amount of time each RC takes, the amount of resources, and the lack of response each one generates. The number of people submitting comments on RCs for 64bit archs is even less. The end points being these, are your bugs fixed in CVS head? From what I've gathered, yes. Can PHP 4.3 be made to be as bug-free as possible? Yes, with some time and help from all developers. You are welcome to contribute patches to close bugs before the GM is released. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
On Mon, 29 Jul 2002, Sebastian Nohn wrote: I don't _need_ a 4.2.3. I need a bug-free PHP version. 4.3.0 will bring a lot of new features, so everything will start from the beginning again. New features = new bugs. As I stated earlier, you are welcome to help ensure that this won't be the case. The best thing you can do is become extremely involved in the RC process and testing. I haven't personally experiences many of the problems you claim, but I don't doubt their existance. The end points being these, are your bugs fixed in CVS head? From what I've gathered, yes. Some are, some are not. Please make a note of which are not, and try to make them as show-stoppers. That denoatation is ultimately upto the Build-Master, but if we don't know what they are... etc etc you know the rest. I don't think, I have enought knowledge of C to do this. Time to brush up, or learn a lot ;) --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] current cvs build errors
On MacOSX 10.1.5 /usr/bin/ld: Undefined symbols: _zif_sha1 _zif_sha1_file make: *** [php] Error 1 bork bork bork! --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mac 8.6 Web Server with PHP
On Thu, 30 Aug 1956, J Abbott wrote: anyone know of a mac 8.6 compatible web server with PHP capibility? No. As far as I am aware, PHP has never been ported to MacOS earlier than OS X.Nor do I think there is a plan to. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3 release call to arms (fwd)
Seems this just went to Stig, but any comments from group would be appriciated... --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- Forwarded message -- Date: Thu, 25 Jul 2002 18:05:47 -0400 (EDT) From: Dan Kalowsky [EMAIL PROTECTED] To: Stig S. Bakken [EMAIL PROTECTED] Subject: Re: [PHP-DEV] 4.3 release call to arms Stig OSX Support is done, Marko got a lot of it done I think. One thing I'd like to see 4.3 is the IMAP quota stuff I've been working on... but I've not had a chance to test it fully... because I have no access to an IMAP server with quota support builtin! (argh). I've sent the patch numerous times to php-dev, gotten no responses, and once to php-general with no response. Suggested recourse of action? On Thu, 25 Jul 2002, Stig S. Bakken wrote: Hi guys, I'd like to start the 4.3 release process now. Anyone with stuff they want to commit before the branch is created, please either commit it or let me know by sunday. I want to create the branch on sunday night GMT+2. Here is, again, the 4.3 TODO list. Most of these require only tweaking and lots of testing. 1. New build system (Sascha) [done?] 2. PHP Streams (Wez) 3. Command-line SAPI installed by default (Edin) * php.ini issues 4. PEAR integration including PECL builder (Stig) 5. MySQL changes (Zak) [in progress] 6. GD bundling (Rasmus) [done?] 7. DOMXML changes (Christian) 8. MacOS X support (Marko) 9. Sockets extension (Jason Greene) 10. Verify new LICENSE (Stig) - Stig --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cvs build issues
Derick Smart-ass :P If you notice the next line is the libtool check which points out version 1.4.1... which is why I'm confused. On Mon, 22 Jul 2002 [EMAIL PROTECTED] wrote: Hey Dan, libtool 1.4 is required a long time now... atleast four months. Dunno why you get this error now :) Derick On Mon, 22 Jul 2002, Dan Kalowsky wrote: I might be a little crazy in the head, or really confused... but this new PHP behavior just baffles me (and I've only been gone for 2 weeks): dank@idoru ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.3.5 found. You need libtool version 1.4 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 dank@idoru libtool --version ltmain.sh (GNU libtool) 1.4.1 (1.922.2.34 2001/09/03 01:22:13) Suggestions or solutions? dank@idoru uname -a Darwin idoru 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] cvs build issues
I might be a little crazy in the head, or really confused... but this new PHP behavior just baffles me (and I've only been gone for 2 weeks): dank@idoru ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.3.5 found. You need libtool version 1.4 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 dank@idoru libtool --version ltmain.sh (GNU libtool) 1.4.1 (1.922.2.34 2001/09/03 01:22:13) Suggestions or solutions? dank@idoru uname -a Darwin idoru 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] IMAP quota functionality
Hey there php-dev readers,
Attached is a patch (based off of 4.2.1 release) for the IMAP system that
needs testing. It's been brought to my attention that the quota support
is sort of... well, not standards compliant. So I tried to fix that.
In the process I've also hopefully added in imap_get_quotaroot()
capabilities as well.
This patch NEEDS through testing, but would be nice to see in 4.3.
Unfortunately I have no access to an IMAP server with quota capabilities
turned on, so I can't really test.
imap_get_quota() should work the same, only now you will be returned the
name value as well, or whatever that is in quota name field (i.e. a
message). The qlist array now looks like:
[qlist] = [name]
= [usage]
= [limit]
imap_get_quotaroot() should not require the user to be run as a mail-admin
user, making this eventually much more useful. Here is an example using
it:
?php
$mbx = imap_open( /* blah blah blah */);
$qroot = imap_get_quotaroot($mbx, INBOX);
// this should retrieve the quota for the logged in users INBOX
if (!$qroot) {
print We have nothing!;
} else {
foreach ($qroot as $name = $value)
print $name and $value\n;
}
?
As usual please test and send any comments back to me.
---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~danka little more action.
[EMAIL PROTECTED] - A Little Less Conversation,
[EMAIL PROTECTED] Elvis Presley
Only in imap: .deps
Only in imap: libs.mk
diff -u imap-orig/php_imap.c imap/php_imap.c
--- imap-orig/php_imap.cWed Apr 24 11:30:16 2002
+++ imap/php_imap.c Thu Jul 18 18:04:21 2002
@@ -22,6 +22,7 @@
| Andrew Skalski [EMAIL PROTECTED] |
| Hartmut Holzgraefe [EMAIL PROTECTED]|
| Jani Taskinen [EMAIL PROTECTED] |
+ | Daniel R. Kalowsky [EMAIL PROTECTED] |
| PHP 4.0 updates: Zeev Suraski [EMAIL PROTECTED] |
+--+
*/
@@ -132,6 +133,7 @@
#if defined(HAVE_IMAP2000) || defined(HAVE_IMAP2001)
PHP_FE(imap_get_quota, NULL)
+ PHP_FE(imap_get_quotaroot, NULL)
PHP_FE(imap_set_quota, NULL)
PHP_FE(imap_setacl,
NULL)
#endif
@@ -371,12 +373,22 @@
{
TSRMLS_FETCH();
- /* this should only be run through once */
- for (; qlist; qlist = qlist-next)
- {
- IMAPG(quota_usage) = qlist-usage;
- IMAPG(quota_limit) = qlist-limit;
- }
+ IMAPG(quota_return) = qlist;
+
+}
+/* }}} */
+
+/* {{{ mail_getquotaroot
+ *
+ * Mail GET_QUOTAROOT callback
+ * Called via the mail_parameter function in c-client:src/c-client/mail.c
+ * Author DRK
+ */
+void mail_getquotaroot(MAILSTREAM *stream, char *mbx, STRINGLIST *qroot)
+{
+ TSRMLS_FETCH();
+
+ IMAPG(quotaroot_return) = qroot;
}
/* }}} */
#endif
@@ -396,6 +408,10 @@
imap_globals-imap_folder_objects = NIL;
imap_globals-imap_sfolder_objects = NIL;
imap_globals-folderlist_style = FLIST_ARRAY;
+#if defined(HAVE_IMAP2000) || defined(HAVE_IMAP2001)
+ imap_globals-quota_return = NIL;
+ imap_globals-quotaroot_return = NIL;
+#endif
}
/* }}} */
@@ -1017,6 +1033,7 @@
{
zval **streamind, **qroot;
pils *imap_le_struct;
+ QUOTALIST *qlist;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, streamind, qroot) ==
FAILURE) {
ZEND_WRONG_PARAM_COUNT();
@@ -1037,9 +1054,54 @@
php_error(E_WARNING, Unable to allocate array memory);
RETURN_FALSE;
}
-
- add_assoc_long(return_value, usage, IMAPG(quota_usage));
- add_assoc_long(return_value, limit, IMAPG(quota_limit));
+
+ qlist = IMAPG(quota_return);
+
+ for (; qlist; qlist = qlist-next) {
+ add_assoc_long(return_value, usage, qlist-usage);
+ add_assoc_long(return_value, limit, qlist-limit);
+ add_assoc_string(return_value, name, qlist-name,
+strlen(qlist-name));
+ }
+
+ IMAPG(quota_return) = NIL;
+}
+/* }}} */
+
+/* {{{ proto array imap_get_quotaroot(int stream_id, string mbox)
+Returns the quota set to the mailbox account mbox */
+PHP_FUNCTION(imap_get_quotaroot)
+{
+zval **streamind, **mbox;
+pils *imap_le_struct;
+STRINGLIST *qlist;
+
+if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, streamind, mbox) ==
+FAILURE) {
+ZEND_WRONG_PARAM_COUNT
Re: [PHP-DEV] Help talking to iODBC...?
This question should really be sent to php-general and not php-dev. In any case... On Mon, 24 Jun 2002, Jay Van Vark wrote: I think I finally got iODBC to talk to my data source, but I still can't get PHP to find the DSN. I have recompiled PHP a couple of time with suggested paths to iODBC... Ie the configure instructions with: --with-iodbc=/usr/local/src/odbcsdk And --with-iodbc=/usr/local The suggested paths? You need to give the path of where your iODBC installation is located. Typically this is /usr/local/odbcsdk but it is completely dependent upon your local installation. Neither seem to have the desired effect -- I have even set Apache to be the same user that I am logged in as so that their shouldn't be any issue there... What is the desired effect? To have iODBC connect to a database, or to compile PHP with iODBC support? --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Help talking to iODBC...?
On Mon, 24 Jun 2002, Jay Van Vark wrote: --with-iodbc=/usr/local/src/odbcsdk I have iODBC installed at /usr/local/src/odbcsdk Then that is the proper path to be using. I am trying to get iODBC to connect to a database - I have PHP compiling ok, but it never finds any of the DSNs that I have defined... I can find them in iSQL, but not from PHP... Have you followed the instructions at iodbc.org? You have to define the ODBCINI path in your PHP file for iODBC to work. Andrew Hill has created a good tutorial on doing this at: http://www.iodbc.org/iodbc-phposxHOWTO.html --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alpha compile error on OSX
On Mon, 10 Jun 2002, Mitch Vincent wrote: I just downloaded the alpha 4.3 from the website and get this : ./configure --with-pgsql --without-mysql --with-pdflib --with-mcrypt --with-zlib --with-gd=/sw --enable-bcmath;make /usr/bin/ld: Undefined symbols: _zend_mh_bundle_error _zend_mh_bundle_load _zend_mh_bundle_symbol _zend_mh_bundle_unload make: *** [php] Error 1 Yep, thats an Alpha release. I know I haven't (and I don't think Marko has either) started playing with ZE2 and OSX. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sun, 2 Jun 2002, Lukas Schroeder wrote:
instead of modifying ./configure to allow grouping a set of --with{out}
--{en|dis}able into one option (--basic, --bare, ...) i propose setting
up brothers of ./config.nice like
./config.bare
./config.basic
./config.standard
./config.everything
This is, in the end, the sort of ultimate I idea I had. A system of
pre-defined flavors for configure to use. The only problem I keep
running into: the need for library paths.
---
Dan KalowskyThe record shows, I took the blows.
http://www.deadmime.org/~dankAnd did it my way.
[EMAIL PROTECTED] - My Way, Frank Sinatra
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Zeev Suraski wrote: I believe there's at least one company that effectively proved that the opposite is true, there are probably many others. I don't see a problem in having core technologies enabled by default. Purists can turn them off, but there are a hell of a lot more average users than there are purists. I don't have the time right now to fully organize my thoughts on this and many of the other emails so you'll have to wait for my response (I know I know). When I state that things shouldn't be enabled by default, it is not towards making it harder for beginners. I would much rather see PHP using something like: ./configure --basic or ./configure --standard or some variation along that theme. Where whatever options are considered by the PHP development community as essential can be enabled. A ./configure should really just build a basic vanilla PHP in my mind. But this concept also goes against 6+ years of configure scripts, and I realize it's an uphill battle. I know it annoyed me to no end that MySQL was being built automatically when I first started using PHP. Or maybe the opposite of this should be allowed. A --disable-standard flag that will turn off all the options PHP developers believe are essential, but can then be overloaded with other options. I have no idea if it is technically feasible, but it's an eventual direction I would rather see. Finding what is enabled by default right now is too difficult, and we just keep plugging in more. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision (was: libxml bundling)
On Sun, 2 Jun 2002, Zeev Suraski wrote: At 07:12 PM 6/1/2002, Björn Schotte wrote: The ease of PHP - one of its biggest advantages is also one of its biggest disadvantages. IMHO. Do you mind elaborating on that?? While I shouldn't speak for others, I can share my take on this. PHP's ease is it's biggest plus. Not only is it easy to learn PHP as a language, but it's extremely easy to extend it into new areas. Because of it's extensibility it's moving in directions that no one really ever thought it'd be used for (i.e. not just web pages). While the innovation is great, it also leads to needs from different groups. And that is where the disadvantage to this system is. I'm not sure there is an exact solution to this either. Although I do think many of these issues will be solved with the full use/implementation of the PECL system, and some other concepts coming down the line (i.e. Marko's dynamically loaded directory). --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Let's please try to keep the points objective. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. Is this really a valid con? This is the standard method of adding functionality to ANY programming language. It's not forcing anyone to do anything. If the end user decides that they would like to have XML capability, they will take the steps required to install such services. As of this moment that includes downloading and installing the libxml services. 2) trim down libxml and put in cvs pros: Build outta the box. Makes php to build without having to download extra libaries for highly used extension like domxml. Since domxml requires a newer version of libxml than most people have it requires them to go an install it before buiding php. Unless you have hard numbers, I'd really appriciate you not stating domxml is a highly used extension. Stating opinion as fact isn't going to help here. cons: People feel that maintaing this would be too much of a hassle. Conserns about file size of the php package. Please keep these points to an objective point, and not a rhetoric with emotion. Con(s): - Requires maintaining code integrity across new versions of libxml - libxml is a moving target - Will require double the effort to provide a 0% increase in output. - Trimmed libxml is not a full libxml, leading to possible end user confusion. - Adds a new point requiring multi-platform release testing. 3) figure out some method to auto download config/install pros: No extra filesize for php source. No matinance for php developers. This point would be more valid for the requires minimal interaction with PHP developers (i.e. hosted site changes location, path, or filename). cons: Someone needs to build this (semi complex). Reliant on other servers being up/ asseable from clients machines (ie have internet connection from the machinge its being installed from) Is this last really a con? It's the same problem across the debian apt-get, the BSD ports collection, and even for getting PHP itself. Which I believe is the more common way for people building PHP than actual tarballs. Although this is only conjecture with no real proof, so take that with a grain of salt. But these methods also check local library versions and will automatically get/update the library if necessary on a per flavor basis. 4) Try and automate the sliming down of libxml and incorp it in the make dist. pros: Still have outta the box but it doesn't live in our cvs. cons: Someone needs to build this (relitivly simple). Still have the filesize issue. Please do not dismiss the trying to hit a moving target as simplisitic. It's not. Having worked with moving targets in the past I can assure you, it is not a fun task. It gets exhausting very quickly. Con(s): - No way to automatically ensure new functionality validity - Will still require developer intervention (albiet less) - Will require multiple OS testing - Will not be valid if libxml is re-written/re-architectured - No way to tell if automated merges have selected the proper option (i.e. bug fix in PHP version and not in official distro). But you did forget at least one other option: 5) Provide a better form of documentation for the end users describing versions with which to use any/all extenions. Pro(s): - Doesn't require bundling of external code - Doesn't increase distribution footprint - Doesn't require double the developer time/effort - Keeps actively maintained libraries away from PHP developers concern - Benefits the entire PHP community rather than a single branch - Keeps the end user informed - Can potentially cut down on submitted bugs by keeping user libraries upto date with the library versions developers/testers are using. Cons: - Requires making information prominent on the web page and within releases - Requires PHP's extension developers to keep upto date information local/specific to PHP only - Requires being translated to all languages PHP manual is available in Do we vote? Do we have all the options listed, along with their pro's and con's yet? --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: I just want to mention one of the more important reasons why I think it's a good idea to include it in the tree. It means that PHP itself and its extensions can rely on having the C API present and can add XML functionality in various places. Andi I wish it became a default module, too. And I will argue that point as well. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Fri, 31 May 2002, Zeev Suraski wrote: As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. I don't think such an assurance existed to begin with, and whether it existed or not, it definitely wasn't the case in the beginning, and I'm not sure how well it's going now. We bundled it not because of any assurance, but because we decided it was important, and we were fed off the Call to undefined function calls on php-general. I'm basing my stance on a post made earlier in this discussion by Rasmus. I really wasn't around during that decision process, so I can't comment on it further. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
