Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, May 30, 2002 at 02:03:40PM -0700, brad lafountain wrote: We are only talking about a few cvs commands here! We aren't talking about a huge effort. Any effort like this seems like duplicated effort to me. I don't see bad merges a problem here. It's not like I would be applying patches or getting the latest and greates from libxml's cvs. Peridocially someone would just need to update the source files from the 'newest' release. If you're just tracking libxml's tree, why do it at all? I fail to see the benefit here. But as I explained before besides bug fixes and speed increases you wouldn't get much from keeping totally up to date with the bundled libxml. And again.. its not like we are forcing the version on the user nor making it an inconvenionce for them if they already have libxml installed. IMHO, having two ways to accomplish the same thing seems like either duplicated effort or overcomplication. I don't know how much developement other people do but use xml/xml techiologies on a daily basis. I see this is the trend of many developers but I obvisouly cant speak for them. Just because some people do XML development on a daily basis is no reason libxml should be bundled with every one of their favorite technologies. The ability to build outta the box is also what many system admins what to see, maybe not the hacker ones but the ones who just get the job done. I also know alot of managers that will pay for software just cuase it runs outta the box. No needing to depend on other software is installed. That is a poor goal at best, and a disaster at worst. IMO code quality is increased with code modularity. Let libxml do its job and PHP do its own job. I still fail to see what benefit you perceive. There will always be companies willing to buy and sell software like PHP (my employer* sells products that include PHP). I think these companies provide great benefit to their customers. Although I haven't read this entire thread nor heard all sides of the argument, at this point I'm -0.9 to the whole idea. Unless there is a *very* good reason for including 3rd party libraries in PHP, I beleve that should be strongly avoided. -aaron * Email me privately if you don't know who I work for and would like to find out. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Userland access to syntax tree
Is it possible to implement a means to access the syntax tree for a script from Userland, like ext/tokenizer allows access to the parsed tokens? Would be a neat thing :) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compile php_zend2 win32 with domxml
hi ng ! i just compiled php with zend2 on win32 using vc7 - after few minor pitfalls it did work out very well. now my problem is that i want to enable domxml extension and therefore wanted to compile it with latest libxml2. compile runs well but the linkage is somehow broken. linker gives error lnk2019 unreferenced external symbol _zend_objects_get_address referenced in function _php_xpath_get_object. (inirectly via macro Z_OBJPROP_P). do i have a chance to compile ? any help and suggestions welcome, thx ilker -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_objects.c
Andi Gutmans wrote: andiFri May 31 10:32:19 2002 EDT Modified files: /ZendEngine2zend_objects.c Log: - Fix build I still get ZendTS.lib(zend_objects.obj): error LNK2001: Unresolved external symbol _zend_objects_store_put ZendTS.lib(zend_objects.obj): error LNK2001: Unresolved external symbol _zend_object_store_get_object ZendTS.lib(zend_execute_API.obj): error LNK2001: Unresolved external symbol _zend_objects_store_init ZendTS.lib(zend_execute_API.obj): error LNK2001: Unresolved external symbol _zend_objects_store_destroy ZendTS.lib(zend_execute_API.obj): error LNK2001: Unresolved external symbol _zend_objects_store_call_destructors ZendTS.lib(zend_object_handlers.obj): error LNK2001: Unresolved external symbol _zend_objects_store_delete_obj ZendTS.lib(zend_object_handlers.obj): error LNK2001: Unresolved external symbol _zend_objects_store_del_ref ZendTS.lib(zend_object_handlers.obj): error LNK2001: Unresolved external symbol _zend_objects_store_add_ref -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 07:16 PM 5/30/2002, Stig S. Bakken wrote: On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. Having a too old version installed doesn't help much in this case. :-) If Brad is able to trim down libxml2 to a reasonable size, I'm +1 Same here. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 07:08 PM 5/30/2002, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. How do you figure that most people have it installed? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 11:39 PM 5/30/2002, Dan Kalowsky wrote: On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. 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 don't see why it's a problem to bundle libxml2 at all. It doesn't have to be in our CVS, we can integrate it into the makedist procedure, provided Brad can automate his trim-down process. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/java ext/xslt problem
Hi as stated in the bug report, it works with jdk 1.3, maybe you should give that a try. or switch to the xslt-implementation of ext/domxml... chregu On Thu, 30 May 2002, fincom wrote: Hi, There ara some many problems when trying to install both ext/java and ext/xslt. Config : Linux Mandrake 8.1 PHP 4.1.2 APACHE 1.3.23 Lib Sablotron 8 JDK 1.4.0 The compil of ext/java is ok. but when trying to test a simple script. Apache don't respond. I try in console and had the log Message (See hs_err_pid5833.log). I Search the web for a solution or persons that has the same problem : Nothing. Finally i found in bugs.php.net an similare bug for php 4.0 RC (Bugs ID 13344). but without any solution. I tried to desactivate ext/xslt in my php.ini : ;xslt.so And what i See : It work. the example work. Sure it's cool, but i wanna the two extensions (xslt java). Hope that will be resolved. thanks for all the PHP people Around the world. Have Fun !!! PS : Excuse My english :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_objects.c
Try now. Andi At 16:55 31/05/2002 +0200, Sebastian Bergmann wrote: Andi Gutmans wrote: andiFri May 31 10:32:19 2002 EDT Modified files: /ZendEngine2zend_objects.c Log: - Fix build I still get ZendTS.lib(zend_objects.obj): error LNK2001: Unresolved external symbol _zend_objects_store_put ZendTS.lib(zend_objects.obj): error LNK2001: Unresolved external symbol _zend_object_store_get_object ZendTS.lib(zend_execute_API.obj): error LNK2001: Unresolved external symbol _zend_objects_store_init ZendTS.lib(zend_execute_API.obj): error LNK2001: Unresolved external symbol _zend_objects_store_destroy ZendTS.lib(zend_execute_API.obj): error LNK2001: Unresolved external symbol _zend_objects_store_call_destructors ZendTS.lib(zend_object_handlers.obj): error LNK2001: Unresolved external symbol _zend_objects_store_delete_obj ZendTS.lib(zend_object_handlers.obj): error LNK2001: Unresolved external symbol _zend_objects_store_del_ref ZendTS.lib(zend_object_handlers.obj): error LNK2001: Unresolved external symbol _zend_objects_store_add_ref -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / ZendTS.dsp
Andi Gutmans wrote: andiFri May 31 11:34:38 2002 EDT Modified files: /ZendEngine2ZendTS.dsp Log: - Add zend_objects_API.* to dsp Stupid me, I added zend_objects_API.c only to Zend.dsp :) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compile php_zend2 w32 domxml, the 2nd
hi again you may haven't noticed yet, but i recently posted a question in here... !--- snip --- hi ng ! i just compiled php with zend2 on win32 using vc7 - after few minor pitfalls it did work out very well. now my problem is that i want to enable domxml extension and therefore wanted to compile it with latest libxml2. compile runs well but the linkage is somehow broken. linker gives error lnk2019 unreferenced external symbol _zend_objects_get_address referenced in function _php_xpath_get_object. (inirectly via macro Z_OBJPROP_P). do i have a chance to compile without errors ? any help and suggestions welcome, thx ilker !--- snip --- i've been following the list now for some hours, and it seems to me that andi and sebastian are heavily working on zendengine2 object management. i do not consider my question as really urgent or important. nevertheless, reading the latest posts (which obviously seem to be cvs commits and comments of you two), i tend to assume that my question is an actual question. ok, i know (or at least can guess) you have better things to do than answering a question of a newbie. however i'd be _really_ glad if you just would give me a hint or would say: hey buddy - wait - it's on the way to work or something similar. a solution would be the greatest anyway. so, _please_, if anybody knows anything about this issue i mentioned above, or even has a solution or hint for me, _please_ reply. i might be in the wrong newsgroup here. if so, please give me an advice where i can post this question accordingly. please excuse my bad english, thank you indeed, ilker -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] bundling libxml2 / bundling locations
TONGUE_IN_CHEEKReally what we should do is in the configure process, if --with-dom is specified and not found on the system, we could call wget, untar, ./configure make, etc. It's the same right? Oh, then we depend on wget being installed./TONGUE_IN_CHEEK What is the status quo? If you install perl on a system, it runs out of the box right? Sure, well so does php, except that expat is required to build php, so it's bundled. Now, when you install a perl module, you also have to install the libraries upon which it depends. That's only fair. It's the accepted status quo. Effort would far better be spent creating an extension dependency tree page that links to the libxml page so that if one wants to install an extension, he or she knows exactly where to go to get the libraries that they depend on. No suprises, no gimmicks. Now on Windows or similar systems, where the average user is not used to system administration (witness the number of codered attacks still going around), we can pack all these dependant binary libraries into the installer. I'm not sure who builds the installer, but I know I could make one in no time flat, and would be willing to do so (and even automate a build process if necessary). -1 on the bundling idea. +1 for choice. +1 for binary bundling on Windows. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:05 AM To: Dan Kalowsky Cc: brad lafountain; PHP Development Mailing list Subject: Re: [PHP-DEV] bundling libxml2 / bundling locations At 11:39 PM 5/30/2002, Dan Kalowsky wrote: On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. 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 don't see why it's a problem to bundle libxml2 at all. It doesn't have to be in our CVS, we can integrate it into the makedist procedure, provided Brad can automate his trim-down process. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Compile php_zend2 w32 domxml, the 2nd
I think this would be the correct list, but I doubt that anyone has tried to do what you're trying to do. What I would look at first is the list of linked libraries in the project settings. They're probably set to ZE1 settings, and could stand to be updated. Other than that, the standard tricks apply as with all linking errors. The solutions given in the MSDN for link 2019 should give you a clue as to how to fix it. Please keep the list posted as to the steps that you take when you do get it working so that we can make the changes to the project files. If you can't get it working, please post a bug at bugs.php.net. Joseph -Original Message- From: Ilker Cetinkaya [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Compile php_zend2 w32 domxml, the 2nd hi again you may haven't noticed yet, but i recently posted a question in here... !--- snip --- hi ng ! i just compiled php with zend2 on win32 using vc7 - after few minor pitfalls it did work out very well. now my problem is that i want to enable domxml extension and therefore wanted to compile it with latest libxml2. compile runs well but the linkage is somehow broken. linker gives error lnk2019 unreferenced external symbol _zend_objects_get_address referenced in function _php_xpath_get_object. (inirectly via macro Z_OBJPROP_P). do i have a chance to compile without errors ? any help and suggestions welcome, thx ilker !--- snip --- i've been following the list now for some hours, and it seems to me that andi and sebastian are heavily working on zendengine2 object management. i do not consider my question as really urgent or important. nevertheless, reading the latest posts (which obviously seem to be cvs commits and comments of you two), i tend to assume that my question is an actual question. ok, i know (or at least can guess) you have better things to do than answering a question of a newbie. however i'd be _really_ glad if you just would give me a hint or would say: hey buddy - wait - it's on the way to work or something similar. a solution would be the greatest anyway. so, _please_, if anybody knows anything about this issue i mentioned above, or even has a solution or hint for me, _please_ reply. i might be in the wrong newsgroup here. if so, please give me an advice where i can post this question accordingly. please excuse my bad english, thank you indeed, ilker -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Still PHP Streams enabled in ext/standard/info.c
Hi, is there any reason keeping this as it's not optionally disabled anyway but a substantial part of PHP ? - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] fopen zend wrapper and relative paths
The bug #11326 was closed after Zeev added the current executing file's directory to the search path, which solved half of the problem. The original bug #9673 though is still open, and the last comment is pointing to the other half of the problem, dot relative paths. Right now, in main/streams.c/_php_stream_fopen_with_path the dot case is dealt with right from the start and no other paths get expanded. What I propose in order to conclude this matter, to get an intuitive behavior and to remain fully compatible with older versions is to add only the current executing file's directory _after_ the cwd of the main file for dot path expansion. This way the include and live parts of a project get fully decoupled, nested includes work as expected (from everyone's perspective), no longer the need to carry arround a root variable (anticipating that the user may disregard the DOCUMENT_ROOT and install the product relative to something else), and the language scales a little bit better. I'm gonna start doing this right now if no one digs up any security problems that refused to cross my mind. D -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Need Some help writing a module.
Hi all,
I'm writing a PHP module for repat, a C-based RDF parser, very similar to expat, in
fact it uses expat
but for RDF statements.
Maybe some of you with a lot of experience in writing modules can help me with my
problem
I have a C variable, a pointer with say X and when I pass the pointer to a function it
receives not X but
something else.
This is a dump of a silly gdb session showing the problem (using the binary php)
See how report_start_element receies an rdf_parser and that rdf_parser-user_data is
0x81970c
Then this code is executed:
if( rdf_parser-start_element_handler )
{
( *rdf_parser-start_element_handler )(
rdf_parser-user_data,
name,
attributes );
}
and parser_my_start_element (the function acting as start_element_handler) receives
0x1cd (???!!)
This is the dump
Breakpoint 1, report_start_element (rdf_parser=0x81f9a58, name=0x81fa714 html,
attributes=0x81f9ce0) at rdfparse.c:1292
1292if( rdf_parser-start_element_handler )
(gdb) s
1294( *rdf_parser-start_element_handler )(
(gdb) p rdf_parser-user_data
$12 = (void *) 0x81f970c
(gdb) s
Breakpoint 2, parser_my_start_element_handler (user_data=0x1cd, name=0x81fa714 html,
attributes=0x81f9ce0) at repat.c:653
If someone can give me a tip about what may be happening then I'd get back to continue
the module, after this problem it should be
ready next week since everything was on wheels until now.
Thanks for your help!
Garland
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 5/8/02
[PHP-DEV] libxml bundling
Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. 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. cons: People feel that maintaing this would be too much of a hassle. Conserns about file size of the php package. 3) figure out some method to auto download config/install pros: No extra filesize for php source. No matinance for php developers. 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) 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. Do we vote? - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
At 13:12 31/05/2002 -0700, brad lafountain wrote: Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. 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 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. cons: People feel that maintaing this would be too much of a hassle. Conserns about file size of the php package. 3) figure out some method to auto download config/install pros: No extra filesize for php source. No matinance for php developers. 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) 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. Do we vote? - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Andi Gutmans wrote: At 13:12 31/05/2002 -0700, brad lafountain wrote: Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. 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. -- Yasuo Ohgaki -- 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
Re: [PHP-DEV] libxml bundling
Just an overall reply to a point you're making - yes, making the user download and build something if he wants to use XML is really a con, in my opinion. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] ext/bz2/bz2.c - fix mem overrun in _php_stream_bz2open in ZTS mode
Hi,
There's a problem with path_copy and ZTS mode (which defines
VIRTUAL_DIR). It's estrdup()d only in non-ZTS mode but also
efree() in ZTS mode which causes problem.
The patch fixed that, but me being not that familiar with the
things, I better let commit this someone who knows the code
(Wez, Sterling?).
- Markus
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Wishlist: http://guru.josefine.at/~mfischer/wishlist
? bz2-fix-overrun.diff
Index: bz2.c
===
RCS file: /repository/php4/ext/bz2/bz2.c,v
retrieving revision 1.49
diff -u -r1.49 bz2.c
--- bz2.c 19 Apr 2002 10:06:41 - 1.49
+++ bz2.c 31 May 2002 21:25:10 -
-170,18 +170,15
#ifdef VIRTUAL_DIR
virtual_filepath(path, path_copy TSRMLS_CC);
#else
- path_copy = estrdup(path);
+ path_copy = path;
#endif
/* try and open it directly first */
bz_file = BZ2_bzopen(path_copy, mode);
- if (opened_path == NULL) {
- efree(path_copy);
- } else if (bz_file) {
- *opened_path = path_copy;
+ if (bz_file opened_path != NULL) {
+ *opened_path = estrdup(path_copy);
}
- path_copy = NULL;
if (bz_file == NULL) {
/* that didn't work, so try and get something from the network/wrapper
*/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
At 11:19 PM 5/31/2002, Andi Gutmans wrote: At 13:12 31/05/2002 -0700, brad lafountain wrote: Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. 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. It doesn't mean that it has to be in the CVS tree, by the way - if we decide that checking out libxml (or untarring a certain version) is a standard part of getting a PHP source tree ready for development. From what I hear, putting libxml in our CVS is really a bad thing to do, because it's a very active project. Zeev -- 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. Well, I guess perhaps Assurance was not the right word, but the decision to bundle it came after a face to face meeting with the main MySQL folks who at that time agreed to maintain it. In this case the libxml2 developers appear to think it is a bad idea for us to bundle it and I would like to understand a bit more why they have this opinion. I really don't like bundling something against the wishes of the authors. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
First off trimming down means. removing documentation. removing install help. NOT removing any code at all! Why do you feel that bundling is such a burdon and how does it requires more testing. If libxml release a new release and it is decited to upgrade then simply upgrade. I don't understand why you think its such a burdon. It looks like they are releasing a version once a month. I don't really think a hour of a developers time a month is much of a burdon. Besides the fact that i don't think we need to upgrade everytime libxml upgrades. If we bundle the newest one right now php and all of it's xmlbased extensions will work fine. if a new one gets released... so if we (php group) feels that its worth the upgrade then go we do it. Otherwise if an end users feels it is in his best intrest to get the newest version the by all means he can. Im not saying that we need to force a version on them but give them a hand if they don't have any installed. But one thing that I didn't think of that andy pointed out is. The ability for php/zend's core or extensions to use xml. (ie config files for new extensions that are separate from php.ini) Xml is so widley used everywhere. You want proof that xml is widly used??? Are you serious? What kinda comapany do you work for? We pretty much use xml and xml based techonlogies in 90% of our projects. And talk about objective points? Your points don't seem more objective than mine. - Brad --- Dan Kalowsky [EMAIL PROTECTED] wrote: 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
Re: [PHP-DEV] libxml bundling
And talk about objective points? Your points don't seem more objective than mine. Would you localize the symbols in it? What happens if someone loads up another DSO into Apache that also uses libxml? We currently have that headache with expat where someone who uses Apache + PHP + mod_perl have 3 projects that all bundled their own expat and it is quite a hassle to negotiate. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Hi again Why do you feel that bundling is such a burdon and how does it requires more testing. If libxml release a new release and it is decited to upgrade then simply upgrade. I don't understand why you think its such a burdon. It looks like they are releasing a version once a month. I don't really think a hour of a developers time a month is much of a burdon. And then, someone thinks he needs a feature in libxml2, which was not approved by the libxml2 folks, merges that into the php-libxml2 source tree and you are in trouble for the next upgrade... (just an example, how you could end up very quickly in upgrade hell, doesn't have to happen, but my observation of the php-developement doesn't outrule that, either :) ) But one thing that I didn't think of that andy pointed out is. The ability for php/zend's core or extensions to use xml. (ie config files for new extensions that are separate from php.ini) Xml is so widley used everywhere. öööhm. I don't know, how many people here are a little bit familiar with the implementation of libxml2 in php, but before talking about integration of that stuff in a lot of places in php/zend, we should first find a way to make it really (or almost) memory leak free. This is now a little bit better than a few weeks ago, but it's still far from perfect. I won't go into details here, but Lukas Schroeder made some suggestions, how to improve it, but we didn't came up till now with the perfect solution. The main problem lies in the fact, that libxml2 can free nodes without notifying anyone and especially not the zval containers and here come the problems with freeing memory and some segfaults Furthermore, I still think, Sterlings idea of an unified XML-extension would be a good idea (sebastian posted that link some days ago), but it would be a pretty big task. For me it's rather painfull, to have to use different extensions for SAX, DOM and XSLT (ok, the later two can be used with the same extension in the meantime), which can't communicate with each other in a reasonable way. Just my 2 cents before everyone thinks libxml2/domxml is the perfect solutions for all xml-tasks in php (it will be some day hopefully, but it isn't right now) You want proof that xml is widly used??? Are you serious? What kinda comapany do you work for? We pretty much use xml and xml based techonlogies in 90% of our projects. no, i think, he wants proof, that domxml/libxml2 is widely used everywhere there are other ways to use xml than with domxml and since domxml is still (for good reasons) marked experimental, a lot of people avoid to use it. And for the record: I'm still against bundling. Though better documentation, where to download libxml2 and how to install it seperately, even an automatic thingie for that, would certainly help some people. chregu -- 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 wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
[EMAIL PROTECTED] wrote: On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. I see xml and unicode as critical technologies for PHP in it's role as a web based scripting language, as critical as html itself. If people cannot seperate that from the issue of embeding a bit more code in PHP distributions, and recognize that xml is as critical to the future of PHP as the web itself, well, there's no convincing. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] main/streams.c - Fix problem in gets emulation
Another patch, from http://bugs.php.net/17547 (it got
wrapped as usual in the report). The gets() emulation in
_php_stream_gets() didn't really work.
- Markus
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Wishlist: http://guru.josefine.at/~mfischer/wishlist
Index: streams.c
===
RCS file: /repository/php4/main/streams.c,v
retrieving revision 1.52
diff -u -r1.52 streams.c
--- streams.c 30 Apr 2002 00:22:44 - 1.52
+++ streams.c 1 Jun 2002 00:53:22 -
-248,21 +248,13
return NULL;
} else {
/* unbuffered fgets - poor performance ! */
- size_t n = 1;
char *c = buf;
/* TODO: look at error returns? */
- while(n maxlen stream-ops-read(stream, c, 1 TSRMLS_CC) 0) {
- n++;
- if (*c == '\n') {
- c++;
- break;
- }
- c++;
- }
- *c = 0;
- return buf;
+ while (--maxlen 0 stream-ops-read(stream, buf, 1 TSRMLS_CC) ==
+1 *buf++ != '\n');
+ *buf = '\0';
+ return c == buf maxlen 0 ? NULL : c;
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Guys, Unless somebody strongly objects, I suggest we drop the discussion about how horrible it would be to import libxml2 into our CVS. I believe it's well established that it's a Bad Thing to do, there's no point hashing it. I believe the question on the table is whether libxml2 is important enough from an end-user's point of view to be built into PHP. If we decide that the answer to that is positive, then there's a fairly easy way of doing that. My personal opinion is that XML today is as basic and important as ASCII, so bundling libxml makes good sense. I believe that bundling at the makedist level makes the most sense, because: (a) Synchronization is trivial (b) We get to choose what libxml we use, so our libxml-dependent code doesn't have to support the zillion different libxml's out there (the moving target argument, in my opinion, is a good reason for us to bundle a stable version of libxml rather than support all versions out there) We need to address the symbol clash issue, and that's about it. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Did you conduct a survey about that? 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. That said, XML is the ASCII of this age, which makes it more important to enable than any of the other modules that you mentioned. Zeev At 03:08 AM 6/1/2002, [EMAIL PROTECTED] wrote: On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Now on Windows or similar systems, where the average user is not used to system administration (witness the number of codered attacks still going around), we can pack all these dependant binary libraries into the installer. I'm not sure who builds the installer, but I know I could make one in no time flat, and would be willing to do so (and even automate a build process if necessary). -1 on the bundling idea. +1 for choice. +1 for binary bundling on Windows. FYI the binary version of the lib is bundled in win32 distribution. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
