Re: [PHP-DEV] Re: [PHP-I18N] Help: Sablotron and Shift-jis
On Fri, 2003-03-07 at 08:50, Moriyoshi Koizumi wrote: It works for me. See the attached example. Anyway, you don't have to crosspost your question to [EMAIL PROTECTED], which is for developing php internals and irrelevant for such user questions. ditto for php-xml-dev, a list _for_ developing of the xml extensions in PHP and not _with_. Your issue looks like a Sablotron problem and not a php at all, by the way ;) chregu Hope this helps Moriyoshi Michel Sahyoun [EMAIL PROTECTED] wrote: Does anyone have an example of using XSLT with Sablotron to transform and XML document containing Shift-jis encoded characters? I keep getting the following error message: Illegal Character for Encoding 'Shift-jis' I am using the latest from snap.php.net and sablotron 0.97 FullPack with iconv, and Javascript. In my php file, I call xslt_set_encoding($xsltHandle, 'Shift-jis'); My xsl file has xsl:output method=xml omit-xml-declaration=yes encoding=Shift-jis / My XML file has: ?xml version=1.0 encoding=Shift-jis ? Am I doing something wrong? Is the encoding name misspelled? Anything else I could check? Thanks, Michel -- PHP Internationalization 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 -- Christian Stocker [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml close document routine
Hi You're right, there is no functionality right now, which is freeing the domxml resources and I looked quickly through your patch. But i'm not sure, what you're gaining exactly with it. You're not freeing the libxml resources itself (and therefore the actual xml data), but just the Zend-Resources to it. Maybe this is very helpful in your special case, but IMHO not a general solution to the problem ;) Could you please send me an example of your script. Maybe I can see then, where this functionality is especially useful. chregu On Sun, 2003-02-23 at 02:40, Robert Oldham wrote: Overview: domxml does not include a close document routing to release memory after an xml document has been processed. I have added one. Purpose: I am using PHP's domxml functionality to parse thousands (17,000+) xml documents in a single request. The current implementation of domxml in PHP does not allow for xml documents to be closed, so memory is lost at more than 7KB/document during processing. I have been able to reduce this to 1KB/document by adding a close document routine to the PHP domxml extension and calling that close routine in my PHP scripts. Diff: Please see the patch files for my changes at the following URLs. http://robertoldham.com/php_domxml.h.php4.diff http://robertoldham.com/php_domxml.c.php4.diff http://robertoldham.com/php_domxml.h.php5.diff http://robertoldham.com/php_domxml.c.php5.diff Caveats: Lacking familiarity with PHP development, I am not sure that my implementation of the close routine is optimal. However, I have been using this code change in php-4.2.3, php-4.3.0 and php-4.3.1 for approximately 6 weeks without any problems. I am also unfamiliar with the process of getting a change reviewed and applied. If I have done anything wrong, or need to do additional things to follow this through, please let me know. Thank you, Robert Oldham -- christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] when PHP code causes crash due to bad input, is it a bug?
Am Freitag, 10.01.03 um 21:02 Uhr schrieb gk: I am trying to help with PHP. But this experience makes me feel like it is not worth it. Can anyone give me some clarification. Is there a common agreement on what constitutes a bug? I have worked as Sr. SQA engineer for many years and have always worked under the understanding that crashes are unacceptible - no matter what caused them: code should be able to handle bad data and not crash. See my bug report and analysis by Daniel Veillard of libxml2 at: http://bugs.php.net/bug.php?id=21477 Greg, don't make that big fuss about it. I fixed the code 15 minutes after bogusfying your report, so it throws an error, if the input is bad. Maybe setting it to bogus was a little bit too unfair, but my additional comments should have clarified it... chregu - Greg Date: Fri, 10 Jan 2003 11:50:35 -0800 To: [EMAIL PROTECTED] From: gk [EMAIL PROTECTED] Subject: Re: Bug #21477 [Opn-Bgs]: $node-dump_node($node) crashes with libxml2-2.4.30 At 06:54 PM 1/10/2003 +, you wrote: You're not in position to decide what is bogus and what is not. This is bogus. - Greg Keraunen -- 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] ZE2 dev snaps
On Mon, 6 Jan 2003, Stephan Seidt wrote: At least ./buildconf with --ZendEngine2 did never work for me. ;) I also did cvs co ZendEngine2 in php4 cvstree root. Did you rename ZendEngine2 to Zend? (Or make a symbolic link, after renaming the old Zend directory to something else) chregu Mark J. Hershenson wrote: Hi all, I know there are Win32+ZE2 Package snapshots on snaps.php.net, but I don't believe I've read why there isn't a ZE2 source code snapshot for everyone else. Checking out the source with CVS may not be the world's most difficult practice, but automating that process likely isn't either. ;) Is there a timeline for this, or is this being intentionally kept off the radar? -- mjh -- nam...christian stockeradr...pflanzschulstr. 31, ch-8004 zurich pho...+41 43 317 9984 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] OSX Project Builder and PHP Developement
Hi Is anyone using Apple's Project Builder for developing PHP? Or did someone try and gave up, because it's not usable? It looks like a nice IDE, but targeted at Java and Obj-C.. If anonye uses it, could you publish the .pbproj file, so I don't have to fiddle around with all those settings ;) On the other hand, compiling PHP on OSX from the command line works excellent and I will stick to that, if PB isn't that great. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [4.3.0RC4] mem leaks with DOMXML ext
On Fri, 27 Dec 2002, Lucas M. Kalita wrote: Configure line: ./configure --with-mysql --with-dom --with-dom-xslt --with-apxs=/usr/bin/ap xs --with-zlib --enable-debug I keep getting those (or similar) on every request, is it normal?: on every request or just if you're using domxml-methods? If the later is the case, please provide the shortest possible example. chregu /root/php-4.3.0RC4/ext/domxml/php_domxml.c(786) : Freeing 0x08550AA4 (12 bytes), script=/var/www/its/x.pro /root/php-4.3.0RC4/ext/domxml/php_domxml.c(782) : Freeing 0x08550424 (12 bytes), script=/var/www/its/x.pro /root/php-4.3.0RC4/Zend/zend_hash.c(406) : Freeing 0x08533EEC (35 bytes), script=/var/www/its/x.pro Last leak repeated 1 time /root/php-4.3.0RC4/Zend/zend_hash.c(178) : Freeing 0x08533D8C (32 bytes), script=/var/www/its/x.pro /root/php-4.3.0RC4/Zend/zend_API.c(597) : Freeing 0x08513EDC (44 bytes), script=/var/www/its/x.pro /root/php-4.3.0RC4/Zend/zend_API.c(585) : Actual location (location was relayed) /root/php-4.3.0RC4/ext/domxml/php_domxml.c(4885) : Freeing 0x084D753C (12 bytes), script=/var/www/its/x.pro LK -- nam...christian stockeradr...pflanzschulstr. 31, ch-8004 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bugs.php.net categories for PECL modules
Hi as PECL is getting more and more attention, it would be nice, if they had their own categories in bugs.php.net. There's category PEAR, but I don't think this is the right place. The question for me is just, if they should be in a PECL topcategory or just in the appropriate other categories (in our case, should imagick be in PECL/imagick or in Graphics/imagick?) What do others think? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bugs.php.net categories for PECL modules
On Mon, 2002-12-09 at 13:12, Jani Taskinen wrote: On 9 Dec 2002, Christian Stocker wrote: Hi as PECL is getting more and more attention, it would be nice, if they had their own categories in bugs.php.net. There's category PEAR, but I don't think this is the right place. The question for me is just, if they should be in a PECL topcategory or just in the appropriate other categories (in our case, should imagick be in PECL/imagick or in Graphics/imagick?) What do others think? It needs it's own bug system. Please don't add anymore categories in the existing one, it's full. I don't mind having its own bug system, but 1) Do user know, if it's in PECL or not? 2) As more and more extension go into PECL (someday all), this system will be as full as todays... (except maybe the core modules like Scripting Engine et al) chregu, just some thoughts throwing around.. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: VS: [PHP-DEV] GIF support
On Mon, 2002-11-25 at 10:33, Carsten Gehling wrote: Fra: Markus Fischer [mailto:[EMAIL PROTECTED]] Sendt: 20. november 2002 14:11 Emne: Re: [PHP-DEV] GIF support A project exists already: http://pear.php.net/package-info.php?pacid=76 Is there a Win32 binary available? nope, or at least, not one that I would know of (I don't have a windows developement environement) ImageMagick does support compressed gifs, if you compile it by yourself and give the right switches to the ./configure script chregu -- christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: mcmontero
On 25 Nov 2002, Michael C. Montero wrote: Christian Stocker and I are joining our ImageMagick module efforts into 1 project. He recommended I get a CVS account to check the new code in directly. I will specifically be updating ext/imagick. Just to clarify this. Michael needs a PEAR Account, since ext/imagick is in PEAR/PECL. And if possible, give him peardoc access as well, maybe he's a better docwriter than me :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Magick version 0.4a Released!
Hi I just had a very quick look at your code and didn't even try it out (lack of time...), but I'm just wondering, why you wrote you're own extension and didn't start with imagick from PECL ( http://pear.php.net/package-info.php?pacid=76 ) ? Maybe we really can join our efforts and do something together (I didn't work for a long time on ext/imagick..), it would be a pity, if we have 2 different imagemagick extensions in the long term :) so long chregu On Fri, 2002-11-22 at 23:08, Michael Montero wrote: Just released the next version of magick, the PHP ImageMagick extension. It's now available as this URL: http://magick.communityconnect.com/ Here are the latest changes: o functions added: magick_writeimages() magick_destroyhandle() magick_image2blob() magick_drawarc() magick_drawcircle() magick_drawpoint() magick_border() magick_frame() magick_raise() magick_getwidth() magick_getheight() magick_getmimetype() magick_setfillcolor() magick_setfontface() magick_charcoal() magick_implode() magick_oilpaint() magick_solarize() magick_swirl() magick_wave() o more preparation for image lists o fixed incorrect comments in some examples o fixed incorrect calls to magick_failedreason() and magick_faileddescription() in most examples o a number of examples weren't exiting properly on errors, that's been fixed o phpinfo() now displays available font family and font names o coolest function so far: magick_oilpaint(). The output is awesome! o added MaxRGB to phpinfo() section Got through quite a few things today. Shooting for beta release by the end of next week. -- Michael C. Montero Chief Technology Officer Community Connect Inc. Co-founder [EMAIL PROTECTED] -=-=-=-=-= Community Connect Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- The Premier Source of Interactive Online Communities149 Fifth Avenue http://www.CommunityConnectInc.com/ New York, NY 10010 http://www.AsianAvenue.com/ http://www.BlackPlanet.com/ Click into Asian AmericaThe World Is Yours http://www.MiGente.com/ http://www.DiversityJobMarket.com/ The Power of LatinosIn partnership with The New York Times - Your Message May Appear Below This Line -- christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 snaps ext/xslt
On Tue, 2002-11-05 at 15:09, Melvyn Sopacua wrote: At 14:58 11/5/2002 +0100, Edin Kadribasic wrote: As a note: Ginger Alliance is motivated to synchronise their next maintenance release, with php 4.3, to avoid the unfortunate API incompatibilities, that plagued previous releases and created noise, both on sablist as on the php-bug db. Allthough we try to keep compatibility with 0.96, there are a number of new features in 0.97(?) implemented for the php extension. Any chance that 4.3.0-release can be built with that version? During RC* shouldn't matter - in fact it would show if BC is not broken on win32. But 0.97 has not been released yet, has it? If it gets released please drop me a note so I can upgrade the lib on our win32 build machine. Yes, correct. The plan is they release 0.97RC at the same time, we release RC1, so feedback on the new combi can be addressed in 0.97 release. one question about that: will sablotron replaced the name of their Arena() class to SabArena in 0.97, so it won't crash PHP when compiled with ext/xslt and ext/java? That would be great. The Sablotron developers said, they will do it, but unfortunately not when :) see http://bugs.php.net/bug.php?id=13344 for details chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Sab] Future of Sablotron (fwd)
Hi This came from the sablotron guys. Maybe interesting to have a look at. chregu -- Forwarded message -- Date: Thu, 19 Sep 2002 13:24:58 +0200 From: Petr Cimprich [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Sab] Future of Sablotron Hi all, We have put together a short document about possible future directions of Sablotron development: http://www.gingerall.org/charlie/ga/html/FUTURE.html Its intention is to open a discussion about the movement of Sablotron after v1.00. Your comments, ideas, complaints, etc. are appreciated. Your feedback can help to turn Sablotron into what you want or need. Best Regards, Petr -- Petr Cimprich Ginger Alliance www.gingerall.com Archives and info: http://www.gingerall.org/charlie/ga/xml/m_ml.xml Mailing list maintained by Ginger Alliance -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOM-XML memory leak?
On Mon, 2 Sep 2002, Markus Fischer wrote: On Mon, Sep 02, 2002 at 04:42:38PM -0400, Al Baker wrote : I want to use the dom-xml extension in a production environment, is the dom-xml memory leak significant, ie will the whole machine run out of available memory or ? You mean this built in feature that domxml leaks a few bytes every hour? Err, really, what are you talking about? Do you have a bug report ID or something concrete you're talking about but missed to mentioned ? ;) Al talks presumably about the mentioning of a leak in the PHP Weekly Newsletter, which I reported last week on php-dev. It's not really serious in my opinion, a few bytes per request. But I had no time to investigate further. Maybe I shouldn't publicly announce such stuff in the future, it only scares the hell out of people :) Al, if you really concerned about it, set MaxRequestsPerChild in httpd.conf (if you're using apache) to something reasonabe and you won't even notice anything. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] MFH -R php4/pear/* files
On Thu, 29 Aug 2002, Edin Kadribasic wrote: Please, could some kind developer MFH the lastest PEAR files so they could ship in the next 4.2.3 release? I'm able to test and attend fixes it may need fast. There has been a huge change in pear from version 4.2.0 to the current development branch. The build system is different, etc. I'm afraid that a big indiscriminate MFH could break things. Plus most of the packages that are in php4/pear in 4.2.0 have disappeared in 4.3.0-dev. If you have specific things that should be merged, that would be a different thing altogether. as i understand the core pear developer, it's only the pear-installer which should be merged into 4.2.3, not all the other packages (they can stay, where they are now). So only pear/PEAR/ has to be merged (IIRC) a big +1 from me to do that. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] destructor in domxml not freeing all memory, any clues?
On Wed, 28 Aug 2002, Brad LaFountain wrote:
I don't think this is the problem but when using libxml i found i need to call
xmlCleanupParser(); after I parse a file.
nope. didn't help. thanks for the tip anyway :)
chregu
- brad
--- Christian Stocker [EMAIL PROTECTED] wrote:
Hi
I just watched my apache and simply doing
domxml_new_doc(1.0);
eats memory on the httpd process, which is not released after script end.
not much, but constantly...
the destructor code for a DomDocument Object looks the following:
static void php_free_xml_doc(zend_rsrc_list_entry *rsrc TSRMLS_DC)
{
xmlDoc *doc = (xmlDoc *) rsrc-ptr;
if (doc) {
node_list_wrapper_dtor(doc-children);
node_wrapper_dtor((xmlNodePtr) doc);
xmlFreeDoc(doc);
}
}
there are no children, so node_list_wrapper_dtor does nothing here.
node_wrapper_dtor is (shortened to the relevant stuff):
*
static inline void node_wrapper_dtor(xmlNodePtr node)
{
zval *wrapper;
wrapper = dom_object_get_data(node);
if (wrapper != NULL ) {
zval_ptr_dtor(wrapper);
}
}
*
Anyone any idea, what I have to release additionally to avoid this memory
leak? I'm not (yet) that much of an expert in ZE :)
TIA
chregu
--
christian stocker | bitflux GmbH | schöneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
christian stocker | bitflux GmbH | schöneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] new webdav patch
Hi I think allowing php users to process webdav methods in user-space is an awesome idea. One question I have, why are the MKCOL, DELETE, and UNLOCK methods not listed? according to RFC 2518 (http://ftp.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.txt), DAV clients are required to support them. The problem with PHP was not, that it didn't accept requests other than POST/GET/HEAD, but that it didn't allow post data for those other requests (except OPTION, this was blocked right at the beginning). MKCOL et al don't need post-data, so we can leave them out from the patch (and it is even advised to do so, because you don't want post-data on stuff which doesn't need it :) ) Also, would you be interested in including the extensions to DAV defined by DeltaV? This would add the following methods: VERSION-CONTROL, REPORT, CHECKIN, CHECKOUT, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY. never worked with deltav, but i see no problem with including them as well (at least the one, which need post-data...). And since subversion is using some of DeltaV, I think/hope it will be much more widespread in the future.. I'm not terribly familiar w/ the DeltaV stuff, but it seems that if php is getting the ability to handle dav request, why not include this extension. You can read more about deltav at http://www.webdav.org/deltav/protocol/rfc3253.html i'll check it out, when i have some spare time :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new webdav patch
Hi I took rasmus input and made a new (hopefully) better patch, to allow webdav methods. I also changed the option allow_option to allow_webdav_methods, which should be more descriptive. The patch can be found at http://trash.chregu.tv/webdav.diff I hope, it's cleaner now than before :) chregu -- christian stocker | bitflux GmbH | schöneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new webdav patch
On Tue, 20 Aug 2002, Rasmus Lerdorf wrote: It is getting there. You are checking for POST under webdav_methods when POST is already allowed by default, so it is a redundant strcmp(). oops. that one slipped through and was certainly not intended to be there :) Anybody else here have an issue with adding this configue option which will allows webdav methods through to be handled in user space? Just to avoid missunderstandings: It's not a ./configure option, but a php.ini/.htaccess option, which is turned off by default. chregu -Rasmus On Tue, 20 Aug 2002, Christian Stocker wrote: Hi I took rasmus input and made a new (hopefully) better patch, to allow webdav methods. I also changed the option allow_option to allow_webdav_methods, which should be more descriptive. The patch can be found at http://trash.chregu.tv/webdav.diff I hope, it's cleaner now than before :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new webdav patch
On Tue, 20 Aug 2002, Rasmus Lerdorf wrote: On Tue, 20 Aug 2002, Rasmus Lerdorf wrote: It is getting there. You are checking for POST under webdav_methods when POST is already allowed by default, so it is a redundant strcmp(). oops. that one slipped through and was certainly not intended to be there :) Anybody else here have an issue with adding this configue option which will allows webdav methods through to be handled in user space? Just to avoid missunderstandings: It's not a ./configure option, but a php.ini/.htaccess option, which is turned off by default. Sorry, right, I should have been more explicit. Do you have karma to commit this? If nobody screams, I suggest you commit it. No, I don't have karma for the whole php4 tree. Someone else has to commit it or if noone wants to be blamed later, someone has to give me karma :) christian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] a patch for making a webdav server work
Hi I started coding a WebDAV Server in userlan php. Unfortunately it needs patching of the PHP-Sources, 'cause php does not accept http OPTIONS and HTTP_RAW_POST_DATA for other http-directives than POST, which a WebDAV server needs. The patch can be found at http://trash.chregu.tv/webdav.diff (against HEAD) I'm totally not sure, if I screwed up anything with that patch, but it runs since some weeks on my webserver without problems. More about my (totally unfinished) WebDAV class can be found at http://bitflux.ch/developer/misc/webdavserver.html Opinions? Possibility in including it in php 4.3? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] a patch for making a webdav server work
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
Well, the stuff I did in the apache_hooks branch shows how you can hook
into other stages of the request chain and, for example, define a PHP
script to be called at the url translation stage or the auth stage. The
latter would allow you to perform PHP-based auth on all files, not just
PHP files, for example.
Being able to run PHP code to translate a requested uri into a different
on-disk resource would probably be useful in some sort of virtual
filesystem context, but I don't think it is directly needed for DAV
support.
I'm not too crazy about Christian's patch. It allows POST data on a HEAD
request, for example. I think that is a bad idea.
yep, i agree with you on that, it was a quickdirty proof-of-concept hack
by me and i didn't think much about possible risks..
This change:
- !strcmp(SG(request_info).request_method, POST)) {
+ strcmp(SG(request_info).request_method, GET)) {
should instead check AP(accept_options) and only if that is on should it
explicitly allow POST data on an OPTIONS request.
However, is OPTIONS the only DAV primitive that has associated POST data?
nope. OPTIONS is not handled at all by PHP at the moment, therefore i made
this change with accept_options (OPTIONS is explicitely blocked right
now). The other primitives which have POST data (see
http://asg.web.cmu.edu/rfc/rfc2518.html for the details)
PROPFIND
PROPPATCH
PUT
MOVE
COPY
LOCK
Just did a quick check, maybe i missed some. OPTIONS on the other hand,
doesn't have POST data, IIRC.
I'm open to other (better) solutions to the problem, but i would be really
glad, if something goes into the main php distribution (patching php is
not a solution for everyone ). And if anyone points me to the right
solution, i'll try to make a better patch :)
chregu
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] a patch for making a webdav server work
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
nope. OPTIONS is not handled at all by PHP at the moment, therefore i made
this change with accept_options (OPTIONS is explicitely blocked right
now). The other primitives which have POST data (see
http://asg.web.cmu.edu/rfc/rfc2518.html for the details)
PROPFIND
PROPPATCH
PUT
MOVE
COPY
LOCK
Just did a quick check, maybe i missed some. OPTIONS on the other hand,
doesn't have POST data, IIRC.
I'm open to other (better) solutions to the problem, but i would be really
glad, if something goes into the main php distribution (patching php is
not a solution for everyone ). And if anyone points me to the right
solution, i'll try to make a better patch :)
If the only PHP change that is actually needed to handle DAV in userspace
is to allow POST data through on a set of DAV primitives, then I have no
problems with a patch to that effect.
great :) do you think, we need an option for allowing that (like for
example allow_webdav_primitives instead of accept_options) and then only
allowing post_data for these primitives, if it is set or would the
following be just ok:
if (SG(request_info).request_method
!strcmp(SG(request_info).request_method, POST)
!strcmp(SG(request_info).request_method, PROPFIND)
!strcmp(SG(request_info).request_method, PROPPATCH)
!strcmp(SG(request_info).request_method, PUT)
!strcmp(SG(request_info).request_method, MOVE)
!strcmp(SG(request_info).request_method, COPY)
!strcmp(SG(request_info).request_method, LOCK)) {
or is there an even better solution?
And I suppose you need to also
always populate HTTP_RAW_POST_DATA and then parse the XML blurb yourself.
exactly.
chregu
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] sigs for php sources
Hi Are there any plans to provide any kind of verification for the tar-balls from php.net (md5, gpg, whatever)? Due to the latest incidents (openssh et al..) more people are aware of the fact, that changed sources could be a problem. I know, you're talking about providing this stuff to pear, but what about the actual php-sources? It shouldn't be a problem to add some md5 stuff to each tarball (for the time being). At least one could then be sure, that the mirrors (where we all download our sources ;) ) didn't compromise it (if I download the md5 sig from another server...). Using GPG (or openssl as discussed some days ago) would provide more security than just md5, but maybe we should waiting for the verifying pear-installer for doing that. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for xslt - Showing Sablotron Version number in phpinfo()
Hi The Subject says it all. It's quite useful to have the Sablotron version number in phpinfo, therefore I added this. It's available at http://trash.chregu.tv/sablot-version.diff Would be great, if someone with enough karma could add it. Unfortunately the version number seems only to be available since sablot 0.95, but better than nothing :) chregu -- christian stocker | bitflux GmbH | schöneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- 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
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. [...] 7. DOMXML changes (Christian) there were no commits lately, so i don't think there are many problems right now. But i will test it again, when the branching is done :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Broken php_domxml.c on make in v4.2.2 (Im guessing)
On Tue, 23 Jul 2002, Dan Hardiker wrote: Hi, That worked for one machine, but this machine is still giving me jip. Configure line exactly the same, error exactly the same - but pkg_info different (uninstall / installed versions of libxml). [11:07:39][root@insomniac]:/usr/local/php-4.2.2$ pkg_info | grep xml libxml2-2.4.23 Xml parser library for GNOME [11:07:39][root@insomniac]:/usr/local/php-4.2.2$ Please note that on the machine that worked, I have lib2-2.4.21 installed - would this make much difference? If you have the same error-message, you maybe have the old library lying around somewhere. It works fine with 2.4.23 for me. Check if it really gets the correct header-files (in php 4.2.3, we will have a ./configure, which checks for the correct version..) chregu Thanks, - Dan Hello, upgrade libxml2 to atleast 2.4.14 and it should work again. Derick On Tue, 23 Jul 2002, Dan Hardiker wrote: Hi, Running the following xml library packages: [10:29:58][root@insomniac]:/usr/local/php-4.2.2$ pkg_info | grep xml libxml2-2.4.1 Xml parser library for GNOME libxml2-2.4.12 Xml parser library for GNOME [10:33:08][root@insomniac]:/usr/local/php-4.2.2$ I have no problem with the following configure line: ./configure --with-mysql=/usr/local/ --with-pgsql --with-gd=/usr/local/ --with-openssl --with-curl --enable-ftp --with-dom --enable-trans-sid -enable-sockets --enable-wddx --with-zlib --with-mcrypt=/usr/local/ --withfreetype --with-t1lib --with-ttf --with-freetype-dir=/usr/local/ --enable-pcntl Problems only arise upon make (this is just the part that died): [10:29:34][root@insomniac]:/usr/local/php-4.2.2$ make Making all in Zend Making all in main Making all in ext Making all in zlib Making all in ctype Making all in curl Making all in domxml gcc -I. -I/usr/local/php-4.2.2/ext/domxml -I/usr/local/php-4.2.2/main -I/usr/local/php-4.2.2 -I/usr/local/php-4.2.2/Zend -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local//include/freetype2/freetype -I/usr/local//include -I/usr/local//include/mysql -I/usr/local/include/pgsql -I/usr/local/php-4.2.2/ext/xml/expat -I/usr/local/php-4.2.2/TSRM -g -O2 -c php_domxml.c touch php_domxml.lo php_domxml.c: In function `zif_domxml_doc_get_element_by_id': php_domxml.c:2675: warning: passing arg 2 of `xmlHashScan' from incompatible pointer type php_domxml.c: In function `zif_domxml_doc_ids': php_domxml.c:3292: warning: passing arg 2 of `xmlHashScan' from incompatible pointer type php_domxml.c: In function `zif_xmldoc': php_domxml.c:3309: `xmlDoValidityCheckingDefaultValue' undeclared (first use in this function) php_domxml.c:3309: (Each undeclared identifier is reported only once php_domxml.c:3309: for each function it appears in.) php_domxml.c:3325: `xmlLoadExtDtdDefaultValue' undeclared (first use in this function) *** Error code 1 Stop in /usr/local/php-4.2.2/ext/domxml. *** Error code 1 Stop in /usr/local/php-4.2.2/ext/domxml. *** Error code 1 Stop in /usr/local/php-4.2.2/ext. *** Error code 1 Stop in /usr/local/php-4.2.2. [10:29:58][root@insomniac]:/usr/local/php-4.2.2$ Is there any more information I can give to help find a patch for this... or is it something Im doing wrong? I would really like to upgrade to 4.2.2 due to the security vunerability (and due to the nature of the applications running on this live server - post cannot be turned off). Alternative suggestions (and even hints as to how I could find the source of the problem and fix it myself would be welcomed - I have limited, but basic foundation in C programming). Thanks -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- 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 --- -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Broken php_domxml.c on make in v4.2.2 (Im guessing)
On Tue, 23 Jul 2002, Dan Hardiker wrote: On Tue, 23 Jul 2002, Dan Hardiker wrote: Hi, That worked for one machine, but this machine is still giving me jip. Configure line exactly the same, error exactly the same - but pkg_info different (uninstall / installed versions of libxml). [11:07:39][root@insomniac]:/usr/local/php-4.2.2$ pkg_info | grep xml libxml2-2.4.23 Xml parser library for GNOME [11:07:39][root@insomniac]:/usr/local/php-4.2.2$ Please note that on the machine that worked, I have lib2-2.4.21 installed - would this make much difference? If you have the same error-message, you maybe have the old library lying around somewhere. It works fine with 2.4.23 for me. Check if it really gets the correct header-files (in php 4.2.3, we will have a ./configure, which checks for the correct version..) chregu [11:41:22][root@insomniac]:/usr/local/lib$ ls -la | grep libxml2 -rw-r--r-- 1 root wheel 767658 Jul 23 10:54 libxml2.a -rwxr-xr-x 1 root wheel 645 Jul 19 2001 libxml2.la lrwxr-xr-x 1 root wheel 12 Jul 23 10:54 libxml2.so - libxml2.so.5 -rwxr-xr-x 1 root wheel 704631 Jul 23 10:54 libxml2.so.5 [11:41:22][root@insomniac]:/usr/local/lib$ The libxml2.la file is from libxml 2.4.11 and is now dormant (I believe)... but the file sizes seem to be about right - and seen as I updated libxml to 2.4.23 today it all seems present and correct. As regards to it getting the correct header files, all I could find from the configure output was: === checking for DOM support... yes checking for libxml version... = 2.4.2 === if you're not sure, you should ./configure with ---with-dom=/path/to/your/libxml/root/installation which is normaly either /usr/ or /usr/local/ you can also change the line #if LIBXML_VERSION = 20402 in configure to #if LIBXML_VERSION = 20414 and then it should really check for the right version and abort, if it didn't found the right one... HTH chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Broken php_domxml.c on make in v4.2.2 (Im guessing)
On Tue, 23 Jul 2002, Dan Hardiker wrote: Hi, Still having major issues ... same error, same place, different .configure file (I edited it to read #if LIBXML_VERSION = 20414 instead), different configure line... same result. New Configure line (altered the --with-dom option): ./configure --with-mysql=/usr/local/ --with-pgsql --with-gd=/usr/local/ --with-openssl --with-curl --enable-ftp --with-dom=/usr/local/ --enable-trans-sid --enable-sockets --enable-wddx --with-zlib --with-mcrypt=/usr/local/ --with-mhash=/usr/locl/ --with-freetype --with-t1lib --with-ttf --with-freetype-dir=/usr/local/ --with-apxs Configures fine, makes all the way up until the domxml extension and then dies miserably. BTW - Im running FreeBSD 4.6-STABLE if that makes a difference ... but the whole scenario works fine on another machine. i have no idea about freeBSD (shame on me) Alternative suggestions would be most welcome. Thanks, search for libxml2/include/xmlversion.h (with locate or whatever). If you find two, then delete the older one (or move). The whole include dir if you only find one, look at the line #define LIBXML_VERSION_STRING 20423 if the version is less than 20414, you lost :) you should then reinstall libxml2 with include files. I have the same packages installed in the same locations on a different machine, can I just copy the php4 apxs module across? (getting to a last resort) mmh. libraries are normally dynamically linked... no idea if this works... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] open_basedir and safe_mode_exec_dir
Hi I prefer the php.ini option open_basedir much more over safe_mode to provide virtual hosting for some clients of mine, but to have a little more security, I additionally need to turn off some function with disable_functions (exec, system, shell_exec and popen come to mind). But it would be very convenient, if I could use sth like safe_mode_exec_dir for non_safe_mode mode to allow nevertheless some command line commands. I know, not the best way to enforce security :) Would this be anyhow possible or do we open safe_mode-hell again with such a possibility? another little thingie: the description to open_basedir in the distributed php.ini is between all the safe_mode config, therfore maybe a lot of people don't know, that one can use this whithout safe_mode enabled. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml win32 build broken (HEAD)
On Tue, 25 Jun 2002, Edin Kadribasic wrote: Configuration: domxml - Win32 Release_TS Compiling... php_domxml.c c:\php4build\snap\ext\domxml\php_domxml.c(201) : error C2099: initializer is not a constant c:\php4build\snap\ext\domxml\php_domxml.c(203) : error C2099: initializer is not a constant c:\php4build\snap\ext\domxml\php_domxml.c(282) : error C2099: initializer is not a constant c:\php4build\snap\ext\domxml\php_domxml.c(323) : error C2099: initializer is not a constant these are the lines with eg PHP_FE(xmldoc, third_arg_force_ref) therefore it chokes on third_arg_force_ref. What did I wrong there? Isn't this the standard way to do it (I assumed that from other sources) c:\php4build\snap\ext\domxml\php_domxml.c(1448) : warning C4013: 'xmlCreateFileParserCtxt' undefined; assuming extern returning int c:\php4build\snap\ext\domxml\php_domxml.c(1450) : warning C4013: 'xmlCreateMemoryParserCtxt' undefined; assuming extern returning int undefined? mmmh, maybe we have to include libxml/parserInternals.h explicitely. Just added it. Hope it helps chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ihavealreadyanidcalled_chregu
I'd like to have access to the domxml documentation. Hopefully, I will some day update the manual with all the new functions I put into domxml in the recent weeks :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Suggestion about native DB support.
Hi Maybe Jonas' opinion about SQLlite and php is of interest in this discussion (was today on pear-dev) see http://marc.theaimsgroup.com/?l=pear-devm=102466375605972w=2 chregu From: Garland foster [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 4:02 PM To: [EMAIL PROTECTED]; Jedi/Sector One Cc: Yasuo Ohgaki; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. I agree that you can't bundle everything that might be useful, I just thought that an official native form of DB support may be useful for webmasters and developers, webmasters won't need to install MySQL, Postgress, DBM and all the possible storage solutions for PHP and developers won't have to code 5 different options for an application that uses a simple key-value storage. May be the advantages outweight the bundling disadvantages... - Original Message - From: [EMAIL PROTECTED] To: Jedi/Sector One [EMAIL PROTECTED] Cc: Garland foster [EMAIL PROTECTED]; Yasuo Ohgaki [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, June 21, 2002 10:58 AM Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. On Fri, 21 Jun 2002, Jedi/Sector One wrote: On Fri, Jun 21, 2002 at 10:37:15AM -0300, Garland foster wrote: What about the native DBM support? Nobody answered that part. And what about SQLite? Porting existing PHP scripts (designed for MySQL or PostgreSQL) to SQLite is easy. And what about mind, or mcrypt, or curl, or... or... There is simply too much out there. I really think that bundling more is not the way to go (maybe except for some xml thing... which I still won't like to see bundled). Derick -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net -- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 -- 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 -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/xslt is not working in php 4.3-dev
Hi ext/xslt seems not to work anymore. I get Warning: Sablotron error on line 1: XML parser error 3: no element found in /usr/local/apache/htdocs/test/sab.php on line 21 or Warning: Sablotron error on line 1: unknown encoding '' in /usr/local/apache/htdocs/test/sab.php on line 21 (on the same file, if i hit Reload a few times, both messages appear from time to time) I'm not sure, if it's a bug (there is a bug report about that at http://bugs.php.net/bug.php?id=16193), but as the last entries in the changelog are: revision 1.46 date: 2002/04/21 00:41:37; author: sterling; state: Exp; lines: +7 -3 expletives deleted. revision 1.45 date: 2002/04/21 00:27:04; author: sterling; state: Exp; lines: +6 -6 some more fixes towards making it work again It looks like, sterling knows, that it's not working, but the last commit is 7 weeks old... Had a quick check over the source files, but couldn't figure out, what is going wrong. Anybody knows more about the state of this extension? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] domxml and validation
Hi Some maybe already recognized it, for the others: There's DTD-Validation in domxml available now. Just for the record, some examples how to use it. $xmldoc = xmldocfile(xhtml1.xhtml,DOMXML_LOAD_PARSING,$error); will parse the file as before, but gives you more meaningfull errormessages in the array $error. For example: $error = Array ( [0] = Array ( [errormessage] = Entity 'copy' not defined [nodename] = p [line] = 102 [col] = 60 [directory] = /usr/local/apache/htdocs/test [file] = xhtml1.xhtml ) $xmldoc = xmldocfile(xhtml1.xhtml,DOMXML_LOAD_VALIDATING,$error); will validate against the DTD in the xml Document. THe error-messages are in $error as well - $error = Array ( [0] = Array ( [nodename] = head [line] = 8 [col] = 31 [directory] = /usr/local/apache/htdocs/test [file] = xhtml1.xhtml [errormessage] = No declaration for attribute blbla on element link ) The same principle works with domxml_open_mem() as well. Furthermore, there's a $xmldoc-validate([$error]) method. It returns true or false on validating and some errormessages in the array $error. The problem here is, that i was not able to get more meaningful messages than $error = Array ( [0] = Array ( [errormessage] = No declaration for attribute blbla on element link ) therefore it's maybe better to do the validating on parsing, 'cause then you can get line and cole number for locating the error. that's it for the moment. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOMXML Function consistency
Hi I have no problem with that, but the old functions should not be deprecated, it's the W3C-Standard way. And if i understood it correctly, both methods (name and nodeName) can be used for the same... chregu On Fri, 7 Jun 2002, Joseph Tate wrote: A bug report or two have been made regarding function names in attribute nodes. Taking a look, nodes have the following access functions: node_name node_type node_value etc. However attribute nodes have the following access functions: name value specified I am thinking that to make it more consistent, we should change the attribute functions to attr_name or node_name attr_value or node_value attr_specified or node_specified I'd vote for the latter series since the programmer already knows they're attributes. Renaming will reduce the WTF factor. We can leave the aliases to the old functions for a while to maintain BC. WISH: I wish there was a Zend Function for marking a function alias as deprecated, I.e. so that a warning message is displayed if the function is used after being marked deprecated. A way to display the replacement function in the warning message would be nice too. Joseph -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOMXML Function consistency
On Fri, 7 Jun 2002, Garland foster wrote: The DOM level 1 W3C's recommendation specifies node_name, node_type and node_value, I'd like the DOMextension to map the W3C spec as close as possible. but it's at least a DOM level 2 W3C recommendation: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-637646024 (except type) I'd even recommend not implementing the suggested functions as alises since that would encorage non-standard DOM applications. keeping BC for some time is not that bad :) chregu - Original Message - From: Joseph Tate [EMAIL PROTECTED] To: Php-Dev List [EMAIL PROTECTED] Sent: Friday, June 07, 2002 11:16 AM Subject: [PHP-DEV] DOMXML Function consistency A bug report or two have been made regarding function names in attribute nodes. Taking a look, nodes have the following access functions: node_name node_type node_value etc. However attribute nodes have the following access functions: name value specified I am thinking that to make it more consistent, we should change the attribute functions to attr_name or node_name attr_value or node_value attr_specified or node_specified I'd vote for the latter series since the programmer already knows they're attributes. Renaming will reduce the WTF factor. We can leave the aliases to the old functions for a while to maintain BC. WISH: I wish there was a Zend Function for marking a function alias as deprecated, I.e. so that a warning message is displayed if the function is used after being marked deprecated. A way to display the replacement function in the warning message would be nice too. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Zeev Suraski wrote: 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. yep :) 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) I do not agree with that. libxml is a moving target feature wise, but they really try to keep the api stable (they do not succeed always :) ). I don't see any sense not supporting the latest available libxml2 version (they bugfix and speedimprove it constantly), but just some version, we think is stable (libxml2 was never a problem recently with stability). And at the moment, we do not support zillions of libxmls, but only versions greater than 2.4.14 (which had unfortunaly a little api-change, so we can't support lower versions anymore) We need to address the symbol clash issue, and that's about it. Does this mean, we are not able to link it to an already existing external library anymore and we always include it into the executable (adding 1.5 MB to the exec and not sharing it with other programs), or do i really miss something (hey, it's early...)... Furthermore, if we support linking to an external libxml2.so/.dll, we have to support new versions anyway ... 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, Zeev Suraski wrote: At 12:45 PM 6/1/2002, Christian Stocker wrote: 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) I do not agree with that. libxml is a moving target feature wise, but they really try to keep the api stable (they do not succeed always :) ). Feature-wise in a way that the wrapper module code won't have to change in order to take advantage of? yes, bugfixes and speed improvements. We don't have to change the wrapper module to take advantage of speed improvements in libxml2 or for example bug fixes in the xpath implementation (2 issues currently discussed at the libxml mailinglist) But also feature-wise in adding new features (for example xml-schema support). Though, the php-module does not take advantage of this without adding new functions ... I guess it depends to the answer of my first question - whether new features will be transparently available to users, even without changes to the wrapping PHP module. If that's the case, we probably should think of a way to support the local library, probably in the same way we handle MySQL. If (!!) we bundle, then this is the only way to go IMHO If not - I see no problem in always using the bundled library, regardless of what's already installed - on the contrary, I see a fairly big advantage. I see really no advantage in this approach (more memory needed for example, maybe symbol clashes and all other reasons from sync-hell i mentioned in my previous mails ) chregu -- 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] 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] bundling libxml2 / bundling locations
Hi I still would like to see it bundled. I do understand that libxml2 is being developed regulary but since domxml does require a semi-new version of libxml2 that most people don't have. I don't know when 2.4.14 was released but the date on the file server is 2/8/2002. Thats pretty recent. Yep, 2.4.14 is from then. I don't/didn't have that version installed on my system. Pretty much every project that i work on uses some kinda xml processing I don't know if thats true for a majority of people or not but I definlty rely on it alot. If you compile php by yourself anyway, what's the problem with having to download another library and doing ./configure make make install for that. Ok, it's a little bit more work for you, but you're compiling anyway... If we bundle 2.4.14 we can change domxml's config script to detect the version on the system if its greater than 2.4.14 then it can link against that version if it isn't then it will use the bundled version. As far as upgrading the version that is bundled. How often or if ever do we need to. If changes in domxml require a newer version of libxml2 then thats when we can upgrade the bundled lib otherwise we wouldn't need to. did you read the changelog? almost every release has bugfixes and speed improvements. If that's the case with a new release, i see no reason not having to sync it. Therefore i think it's a PITA :) And since Daniel Veillard is almost certainly not in the mood of updating this by himself, someone of us has to take over this part (ok, you would do that..) If we don't include it, it's up to the system administrator to get the latest libxml2 libraries, if he wants bugs fixed and the fastest implementation. And it's really not that difficult to update libxml (did i say apt-get upgrade? but also with rpm-based distros it shouldn't be much of a hassle, since there are rpms on the xmlsoft server...) From my understanding libxml2 is faster than expat? I don't know. SAX-Parsing can't be that difficult to implement. But since there is no SAX support in ext/domxml, it's hard to compare,, and all the things like ext/xml and ext/xmlrpc can be converted to libxml2? don't know if ext/xmlrpc would benefit from libxml2, but ext/xml could be certainly ported to libxml. Since we do bundle expat i don't see the big problem with bundling libxml2. I see the problem with maintaining that and adding another 800kB,... I'm still -1 with that. (but i see the point in andis MS reference it works out of the box, maybe the PECL/bundling idea is not that bad, then we can just throw the libxml tarball in that... ) chregu -- 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 Wed, 29 May 2002, brad lafountain wrote: Hello all, It was mentioned before about bundling libxml2 with php with expat or instead of expat. Where do we stand with this? I emailed the developer asking permission to bundle it if we choose to do it (no response yet). öhm, libxml2 is a relatively huge project with a fast developement cycle.. I don't see the point in bundling that with php. It's actively maintained (not as for example gd), we don't need any patches to get it running and it comes with most (all?) distros (not installed by default everywhere, but it's available). And installation from source is also no pain at all... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unified XML Extension
On Thu, 30 May 2002, Sebastian Bergmann wrote: I think the best solution would be to do what Sterling proposes in http://bumblebury.com/phptodo/xmsl.html. that sounds interesting :) The DOM-ZVAL Transformation is really a problem and gives us much headache in domxml with memleaks and all those nasty things... but i didn't look much into ZE2 until now, so can't comment on this object overloading stuff. libxml2 supports almost every technology mentioned on sterlings page (not sure about XInclude, but soon it will support xsl:schema for example as well) and a lot is already in ext/domxml (but maybe not in the best way...) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] XPath
On Thu, 23 May 2002, Michael Dransfield wrote: whilst we are on the 'X' topic, does anyone know of an XPath implementation. I know of some (quite good) php classes [http://sourceforge.net/projects/phpxpath/], but no compiled extensions. what's wrong with http://www.php.net/manual/en/function.xpath-eval.php ? there since 4.0.4 ... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] webdav server implementation
Hi
I've got today a WebDAV server in PHP-Userland running. It works quite
well with nautilus and cadaver and not so well with MS-Stuff... but it was
just a proof of concept and I will get that running, too :) When i
finished it, I will most likely put it online anywhere (or contribute it
to PEAR ..)
BUT, it doesn't work without patching PHP. I had to change main/SAPI.c to
get the POST-data from the other REQUEST_METHODs than POST (PROPFIND et
al.) line 307 should then be (real patch attached)
strcmp(SG(request_info).request_method, GET)) {
instead of
!strcmp(SG(request_info).request_method, POST)) {
but i don't know, if this has any unwanted sideeffects, or if this is the
right thing to do... Or are for example PUT requests in any way
handled with PHP at the moment?
Comments are very welcome about that :)
chregu
--
christian stocker | bitflux GmbH | schöneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
Index: SAPI.c
===
RCS file: /repository/php4/main/SAPI.c,v
retrieving revision 1.129
diff -u -r1.129 SAPI.c
--- SAPI.c 14 Jan 2002 13:36:54 - 1.129
+++ SAPI.c 19 May 2002 20:05:58 -
@@ -303,7 +303,7 @@
if (SG(server_context)) {
if (SG(request_info).request_method
-!strcmp(SG(request_info).request_method, POST)) {
+strcmp(SG(request_info).request_method, GET)) {
if (!SG(request_info).content_type) {
SG(request_info).content_type_dup = NULL;
if(PG(always_populate_raw_post_data)) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] JFYI: domxml memory leak
Hi For all of those, who don't read the bug-list: domxml had a pretty big memory leak in 4.2.0 and 4.2.1 if you use append_child/add_child/append_sibling. If you create big XML-Documents with those functions, you are really urged to try the new version from CVS, which should fix the problem. Windows is not tested yet, AFAIK ... Anyway, is there ever going to be a 4.2.2 release, or will the next release be 4.3 (and i can stop MFHing :) )? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml questions
On Sat, 18 May 2002, Lukas Schroeder wrote: On Sat, May 18, 2002 at 10:05:32AM -0400, Rob Richards wrote: I have been going through the latest domxml extension and have a few questions about it. Looking at the docs, it is indicated that set_content and get_content are depreciated. set_content - Create a new node with e.g. DomDocument_create_text_node() und add it with DomNode_append_child(). get_content - Content is just a text node and can be accessed with DomNode_child_nodes(). Would get_content really be replace with node_value? All the child_nodes would give you is the child nodes. the contents of an element-node are contained in a child-node of that element-node with the special node-name #text. using child_nodes would give you these contents. but, without a get_content() (get_node_value()) function there is no way to get the nodeValue (content) of the #text node. hehe. i hope, that deprecating or even removing a get_content() function (or an equivalent) wont happen, because i definately dont want to replace entity-references in contents manually. the purpose of get_content() was and is to do that for me. yep. i agree. Making domxml w3c-compliant doesn't mean for me removing all the other not-w3c-compliant functions. I don't see any sense in removing this sometimes very handy functions. I'm not sure, why these functions are markes as deprecated in the manual... On that note, if you are trying to set the value of an existing node, using the replacement (as indicated from the docs) you would should be creating a new node and appending it, which means you then should remove the old node. Shouldnt there be a set_node_value or similar function to just replace the content of an existing node? A set_node_value function would be DOM compliant as the nodeValue property is read/write according to the specs. but that doesn't help you anything. nodeValue of an element node does not carry the content of this element (IIRC). nodeValue of a textnode does on the other side.. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cant compile 4.2.1 on FreeBSD with domxml support
On Sat, 18 May 2002, Markus Fischer wrote: What version of libxml2 ? Needs to be = 2.4.14 yep. php 4.2.1 doesn't check for the right version (it only checks for 2.4.2, but it needs functions implemented since 2.4.14). this is fixed in CVS (HEAD and PHP_4_2_0 branch) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix for bug 16888
On Thu, 16 May 2002, Joseph Tate wrote: The following fixes bug 16888 so that Apache and IIS no longer crash on Windows when using the domxml extension with more than 128 nodes. See http://bugs.php.net/bug.php?id=16888 for details. Will the memory leak gurus please have a go at this and let me know what problems arise? Also, please test on non Win platforms to make sure that no functionality is lost. i certainly will (but i'm not the memory leak guru :) ), but the patch didn't make it through the mailing list. can you put it somewhere online? or send it to me personally, i can put it then on my webserver. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOM XML uses non-DOM compliant calls
Hi Yeah thats pretty much it. It does make it eaiser for people using dom in another lanugage to pick it up in php if it did conform to the standard. Expecially how we are trying to conform the functions to begin with. Instead of having append_child... why not add_child.. 'cause appendChild, resp. append_child is the the w3c standard ... - We started conforming to the standard why not go the whole way. - 'cause, as said before, it's the php way to seperate words. And i would much apreciate, if this would be everywhere the same (isset and is_null as a wonderfull example...) And with alias we can have the php standard and the w3c standard. i don't see a reason for that. it's not that complicated to change appendChild to append_child in your code. you have to change your code anyway. and since PHP is not case-sensitive functionname wise, you will get funny stuff (see ext/gd in all the tutorials, if php is ever going case sensitiv (is it?), then all those examples are in big trouble :) ) I'm certainly against introducing the non-underscore api-stuff. and BTW, i didn't found anything on w3.org, which says method names have to be studly caps (but i just had a quick look). The php-api is more or less clear in that way, that where w3c suggest an uppercase letter, php makes an underscore. Therefore it's not that hard to switch between different languages. ok. i repeat more or less what others said... chregu - Brad --- Markus Fischer [EMAIL PROTECTED] wrote: Hi, I fail to see the advante. Is it only that 'it looks like what the w3c recommends' and 'so users already used to the api have it easier' or did I miss something else? - Markus On Tue, May 14, 2002 at 01:47:22PM -0700, Brent R. Matzelle wrote : --- brad lafountain [EMAIL PROTECTED] wrote: Why don't we just add alias... so it will be BC and so we don't get shunned on by people like that. That would fit the bill nicely. Brent __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc - I mean When in doubt, blame mcrypt is more often right than wrong :) Always right, never wrong :) - Two PHP developers who want to remain unnamed -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.1
On Mon, 6 May 2002, brad lafountain wrote: Hello, I have a patch for DomXML that does 2 things. It allows you to use new and constructors to create dom elements. Ex. $doc = new DomDocument(some.file, true); $ele = new DocElement(name); $doc-append_child($ele); as i said before, this is not according to the DOM-Standard, so i would rather prefer not to include this kind of behaviour, but i'd like to hear other opinions about that and it also PHPAPI exports one function that can be used in other places (my extension). don't know exactly, what you mean with that. Can you give an example and more important the source code to that :) Is it a possiblity to get this change in this release. mmh. that's more or less to late now... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.1
On Mon, 6 May 2002, brad lafountain wrote: --- Christian Stocker [EMAIL PROTECTED] wrote: On Mon, 6 May 2002, brad lafountain wrote: Hello, I have a patch for DomXML that does 2 things. It allows you to use new and constructors to create dom elements. Ex. $doc = new DomDocument(some.file, true); $ele = new DocElement(name); $doc-append_child($ele); as i said before, this is not according to the DOM-Standard, so i would rather prefer not to include this kind of behaviour, but i'd like to hear other opinions about that You are acually goign to argue that it isn't a dom-standard, so you don't want it put in? There are a bunch of document non dom-standart functions. I don't see how this is any different. not really. but uwe made a lot of efforts to make it finally more dom compliant. But you're right, it doesn't hurt anyone, so i'm not really against it. Does the dom-standard doesn't say that you need a separte xmldoc() and not a new DomDocument, does it?. ranting is really not necessary here :) domxml was for a long time just a hack and didn't follow much of the standard, therefore there is still a lot of not-standard stuff in there and this stuff will (hopefully) not removed for BC's sake... static zval *php_domobject_new(xmlNodePtr obj, int *found TSRMLS_DC); to PHPAPI zval *php_domobject_new(xmlNodePtr obj, int *found TSRMLS_DC); Then declaring PHPAPI zval *php_domobject_new(xmlNodePtr obj, int *found TSRMLS_DC); in php_domxml.h yep, no problem with that mmh. that's more or less to late now... Man... When is the next planned release? don't know. ask stig .) What if just get in the PHPAPI export and try and convince you all about the new Dom* later? RC2 was tagged today, so it's really to late (see dericks mail). You have to wait for 4.3 ... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.1
ranting is really not necessary here :) domxml was for a long time just a hack and didn't follow much of the standard, therefore there is still a lot of not-standard stuff in there and this stuff will (hopefully) not removed for BC's sake... I honistly wasn't ranting. That was a serious question. I wasn't sure if the standard says how to create the inital domdocument. there was a :) at the end, so it was not meant really serious. The standard says it's: DOMImplementation.createDocument() this would make domxml_create_document() in php it's domxml_new_doc()... mmmh, maybe make an alias for that... Ok... I have to do some more testing. I'll submit a patch (hopefully later today). since 4.3 will not be released in the next days, i would rather prefer you test your patch thoroughly .) so take your time. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml extension
On Sun, 5 May 2002, brad lafountain wrote:
Hello,
I was wondering who was maintaing the dom xml extension.
I was just testing out some stuff.
-
$xml = new DomElement('asdf');
just doesn't work..
$xml = new DomElement('asdf');
$real_element = $xml-domelement('asdf');
works...
I looked into this.. Two reasons this is happening..
1)
The register_class_entry has DomElement not domelement (all the classes are
like that).
So that is why the constructor isn't being called.
2)
The constructor returns a zval instead of making the addintions to the current
object.
you should use $xml-create_element(bla), which does the second thing
for you.
chregu
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml extension
Hi
Yeah but i don't have a $xml
alls i want to do is
$node = new DomElement('blah');
I'm not sure, why you want this, but it doesn't make much sense to me and
is not in the sense of the DOM-Standard:
Objects implementing some interface X are created by a createX()
method on the Document interface; this is because all DOM objects live in
the context of a specific Document.
therefore you need a document to create an element and this constructor is
somehow stupid (IMHO) and for this reason also not documentated. I don't
know, why it's there at all...
Currently your constructors aren't even being called... ever!
they are not my constructors and i didn't wrote them :)
chregu
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 4.3 charter and release plan
In [EMAIL PROTECTED], Stig S. Bakken wrote: Hi, I've volunteered to RM (release master, not /bin/rm) PHP 4.3. This release will be synchronized with the public release of the PEAR (including PECL) infrastructure. This time I'd like to try partitioning the work a bit by identifying the major changes and have one person sign up as responsible for each. I will do the overall coordination and handle stuff that don't belong to these major changes. Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 7. DOMXML changes? (Christian) if noone else really would like to do it, i can take over this part. I don't think, there's much new stuff in domxml since 4.2 (yes, there is some, but nothing really critical), but testing all this would be a good idea, maybe adding missing functions from the DOM-Specs as well (but this depends until when we want tp release php4.3). I'm already using domxml from 4.3 on my testing machine and didn't realize any problems with it till now. christian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] The PHP Platform
In [EMAIL PROTECTED], Joseph Tate wrote: I didn't know that compiling with just domxml gave xslt as well. are you sure of this? --with-dom-xslt and --with-dom-exslt But only since PHP 4.2 chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] domxml nightmare and suggestion
Hi In the last weeks, whenever i read some comments about php and what is bad about it (besides all the good points :) ), domxml seems to be one of the top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Furthermore, to make the task in implementing a full w3c-DOM-API a lot easier, i would suggest, we would use libgome2 (http://phd.cs.unibo.it/gdome2/) as the underlying library. gdome2 is based on libxml2, but provides a W3C-DOM level2 implementation (not like libxml2, which has it's own DOM-implementation). The only disadvantage is, that it needs libglib as well, so we would add another library to the prerequisites for domxml... (BTW, libgdome2 seems to be compiling under Windows as well) Ideas, thoughts, etc? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 /ext/domxml php_domxml.c php_domxml.h
In cvssteinm1018611144@cvsserver, Uwe Steinmann wrote: steinmFri Apr 12 07:32:24 2002 EDT Modified files: /php4/ext/domxml php_domxml.c php_domxml.h Log: - append_child(): actually do an append child and not and add sibling mmh, you just broke some of my applications :) I know, it was the wrong behaviour before, but now I will have big troubles to make my application cross-version compatible (and it looks like, there's no method append_sibling with that old behaviour.) solutions? don't know. maybe adding a function with that old behaviour maybe, so i can check for this in my applications. maybe reverting (but then we don't follow w3c, but this function was in domxml for a long time..) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] webDAV and php
Hi I'm really interested in having a possibility to handle webDAV requests in PHP and I know this was discussed before, but never heard much again. Anyone knowing of someone working on WebDAV-Server integration with PHP? Would it be easier to integrate it with apache 2 than with apache 1.3? I'm willing to help with developement, but I have no idea about apaches interface and mod_dav (which would maybe be the best solution, a mod_dav_php would be really great :) ) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: proposed domxml funciton name changes:
In [EMAIL PROTECTED], Joseph Tate wrote: I propose the following function name changes for clarity and consistency: Rename: domxml_node_insert_before - domxml_node_insert_node domxml_node_append_child - domxml_node_append_node I agree here with Ricky. Please stick to the W3C DOM Proposals as much as possible. The domxml extension has already a lot of functions and it would be really a PITA if PHP would use other names than everyone else for DOM-functionality... Remove: alias to unlink (in favor of the more consistent unlink_node) domxml_node_new_child() (in favor of a domxml_doc_create_* domxml_node_add_child() combination) No no no :) Don't remove any functions without really good intentions. It will break a lot of my scripts (domxml_node_new_child() doesn't look like a w3c reco. but anyway, i assume a lot of people use it ...) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [patch] domxml ./. fix for some memory leaks + cleanups
Applied chregu In [EMAIL PROTECTED], Lukas Schroeder wrote: hi! this patch is against current cvs. it contains some trivial cleanups and fixes for several memory leaks, where memory that gets malloc()ed in libxml2 is not free()d. please apply... additionally, this patch changes get_attribute() to return FALSE instead of an empty string if the attribute does not exists. without this change, php code cannot distinguish between a missing and an empty attribute. i hope this gets applied too... regards, -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] session.send_cache_headers as new ini entry
Hi We had a problem, sending dynamically generated pdf documents to MSIE 5.5, if we used sessions. It looked like the Cache-Control and Pragma Headers caused the problem, therefore i created a patch for session.c with a new ini-directive session.send_cache_headers. If this is set to false, then this headers are not sent and MSIE will not crash. I'm not sure if this is the right way, or if there are better solutions, or if i did it correctly, but you can find the patch (for HEAD) at http://trash.chregu.tv/session.diff As I heard, a lot of people have this problem, maybe this workaround could be a saver for them :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session.send_cache_headers as new ini entry
Hi I commented out Cache-Control, Pragma and Expires and this helped... Didn't investigate further, since it worked with that :) Maybe just one of these headers is really offending... chregu On Wed, 20 Mar 2002, Markus Fischer wrote: Christian, could you do me a favour and pasting the offending HTTP headers which caused the problem? I'm investigating a similar problem here. - Markus On Wed, Mar 20, 2002 at 05:47:35PM +0100, Christian Stocker wrote : Hi We had a problem, sending dynamically generated pdf documents to MSIE 5.5, if we used sessions. It looked like the Cache-Control and Pragma Headers caused the problem, therefore i created a patch for session.c with a new ini-directive session.send_cache_headers. If this is set to false, then this headers are not sent and MSIE will not crash. I'm not sure if this is the right way, or if there are better solutions, or if i did it correctly, but you can find the patch (for HEAD) at http://trash.chregu.tv/session.diff As I heard, a lot of people have this problem, maybe this workaround could be a saver for them :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session.send_cache_headers as new ini entry
Hi different behaviour -blank page and no crash -just a crash sometimes also a complete crash of MSIE 5.5, then only a windows (win2k) reboot helped to get it back completely. chregu On Wed, 20 Mar 2002, Markus Fischer wrote: I forgot to ask also .. what did you expirience exactly? Crash of the Internet Explorer Client (Browserwidnow suddenly closed) ? - Markus On Wed, Mar 20, 2002 at 06:20:36PM +0100, Christian Stocker wrote : Hi I commented out Cache-Control, Pragma and Expires and this helped... Didn't investigate further, since it worked with that :) Maybe just one of these headers is really offending... chregu On Wed, 20 Mar 2002, Markus Fischer wrote: Christian, could you do me a favour and pasting the offending HTTP headers which caused the problem? I'm investigating a similar problem here. - Markus On Wed, Mar 20, 2002 at 05:47:35PM +0100, Christian Stocker wrote : Hi We had a problem, sending dynamically generated pdf documents to MSIE 5.5, if we used sessions. It looked like the Cache-Control and Pragma Headers caused the problem, therefore i created a patch for session.c with a new ini-directive session.send_cache_headers. If this is set to false, then this headers are not sent and MSIE will not crash. I'm not sure if this is the right way, or if there are better solutions, or if i did it correctly, but you can find the patch (for HEAD) at http://trash.chregu.tv/session.diff As I heard, a lot of people have this problem, maybe this workaround could be a saver for them :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] cvs server: waiting for cvs's lock in /repository/php4/ext/domxml since hours :)
Hi I wanted to commit some stuff, but i get cvs server: [10:34:25] waiting for cvs's lock in /repository/php4/ext/domxml since hours. Anyone an idea, what's wrong? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SHA-1 support
In [EMAIL PROTECTED], André NæSs wrote: Markus Fischer [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I can see a possible point with a dedicated sha1() function, but I don't see one in saying that mhash() is badly documented (even if it was, it's very easy to find the right information within seconds). The later case would vindicate a documentation report. Hm. My bad, I seem to have read only the entry on mhash() after ending up there through a search. A reference to Mhash from crc32() and md5() would be nice though, just to tell people about other hashing functions. Maybe there should also be a mention of the fact that MD5 is fairly easy to crack? Who said that? Never heard of any claims, that md5 is insecure ... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] openssl_pkcs7_sign segfaults. patch included
Could someone with enough karma fix the following bug in ext/openssl/openssl.c in the openssl_pkcs7_sign function thanks chregu Index: openssl.c === RCS file: /repository/php4/ext/openssl/openssl.c,v retrieving revision 1.39 diff -u -r1.39 openssl.c --- openssl.c 11 Dec 2001 15:30:00 - 1.39 +++ openssl.c 28 Jan 2002 21:35:06 - @@ -2151,7 +2151,7 @@ char * extracertsfilename = NULL; long extracertsfilename_len; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, sszza!|ls, - infilename, infilename_len, *outfilename, outfilename_len, + infilename, infilename_len, outfilename, +outfilename_len, zcert, zprivkey, zheaders, flags, extracertsfilename, extracertsfilename_len) == FAILURE) return; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: cvs: php4 /ext/xslt config.m4
In cvssterling1011288098@cvsserver, Sterling Hughes wrote: sterling Thu Jan 17 12:21:38 2002 EDT Modified files: /php4/ext/xsltconfig.m4 Log: Update for Sablotron .8 wouldn't it be more consistent to call this config-param --with-xslt-sablot-js instead of --with-sablot-js? We just dumped --with-sablot :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] karma request for ext/domxml (fwd)
Hi Posted this to [EMAIL PROTECTED] and got no reply, so here is it again (and i hope you won't get this twice, since my first attempt a few minutes ago went to the wrong adress, maybe... it's late :) ): I'd like to help out with the domxml developement and ask therefor for karma .) We use domxml heavily at our office and encounter from time to time bugs (already submitted some), so i'd like to get more involved into the developement of domxml and help to get rid of some of these DOMXML_NOT_IMPLEMENTED() Macros. The libxml library has also some nice features not yet prototyped and implemented in domxml. Furthermore I have a patch, which adds exslt-support for the xslt functions in domxml and some other little stuff. see http://php.chregu.tv/domxml.diff if you are interested. i already have a cvs-account for pear. thanks and have a nice night :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/domxml config.m4 php_domxml.c php_domxml.h
In [EMAIL PROTECTED], Sebastian Bergmann wrote: Jaroslaw Kolakowski wrote: - Added preliminary DOM XSLT support: -- uses the libxslt library, -- operates on DOM objects, not strings, -- functions: domxml_xslt_process(), domxml_xslt_version(). Please don't put this into ext/domxml, but implement it as a backend for ext/xslt. I think, the idea here was to use domxml-objects for feeding a xsl-processor without the need for a transformation from a domxml-tree to a string to a ext/xslt-domtree (if i build the xml with domxml for example). I find this feature rather useful, but if this is achievable with the ext/xslt backend as well, that would naturally be even better or at least more consistent. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ext/imagick update (fwd)
On Wed, 21 Nov 2001, Sterling Hughes wrote: So imagemagick would be less popular than, say, Ovrimos, YAZ(eesh), SESAM, Crédit Mutuel CyberMUT... no, I don't remember saying these belonged in PHP's CVS, they are there for a large part imho legacy reasons and laziness (ie, not enough bitching when they were proprosed). ok, I give up ;) You're right, if you say, that not sooo many extensions should be in the core php4 distribution. It makes the Release process somehow complicated... But unfortunately the pear-framework is at the moment not very sophisticated for handling traditional php-extension. But I will put some of my effort into that and hope the pear-folks will agree :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ext/imagick update
On Tue, 20 Nov 2001, Egon Schmid wrote: From: Christian Stocker [EMAIL PROTECTED] I wrote further on my ImageMagick extension (still a lot missing), but most importantly i wrote some documentation. You can have a look at it at http://php.chregu.tv/imagick/ comments etc. always welcome. Looks good. Please commit it to phpdoc and make your updates there. mmh, as the extension is not in the php-source tree at the moment, it doesn't make sense to check it in into phpdoc. Or am I wrong about that? But as soon as ext/imagick is in the cvs (if...), I will commit my documentation to phpdoc as well. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ext/imagick update
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote: On Wed, 21 Nov 2001, Christian Stocker wrote: On Tue, 20 Nov 2001, Egon Schmid wrote: From: Christian Stocker [EMAIL PROTECTED] I wrote further on my ImageMagick extension (still a lot missing), but most importantly i wrote some documentation. You can have a look at it at http://php.chregu.tv/imagick/ comments etc. always welcome. Looks good. Please commit it to phpdoc and make your updates there. mmh, as the extension is not in the php-source tree at the moment, it doesn't make sense to check it in into phpdoc. Or am I wrong about that? But as soon as ext/imagick is in the cvs (if...), I will commit my documentation to phpdoc as well. Did you request a cvs account already? IMO this would be a fine extension. I already have a cvs-account (for pear), i would just need karma for ext/imagick and phpdoc... However, i think it should move to the PEAR repository, as soon as that framework is ready. I thought about that, too. But unfortunately the framework for traditional native php-extension in c is not really there (for packages written in PHP, it's almost ready...). chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ext/imagick update (fwd)
On Wed, 21 Nov 2001 15:22:12 +0100, derick wrote: Let it do to the list then ... On Wed, 21 Nov 2001, Christian Stocker wrote: On Tue, 20 Nov 2001, Egon Schmid wrote: From: Christian Stocker [EMAIL PROTECTED] I wrote further on my ImageMagick extension (still a lot missing), but most importantly i wrote some documentation. You can have a look at it at http://php.chregu.tv/imagick/ comments etc. always welcome. Looks good. Please commit it to phpdoc and make your updates there. mmh, as the extension is not in the php-source tree at the moment, it doesn't make sense to check it in into phpdoc. Or am I wrong about that? But as soon as ext/imagick is in the cvs (if...), I will commit my documentation to phpdoc as well. Did you request a cvs account already? IMO this would be a fine extension. However, i think it should move to the PEAR repository, as soon as that framework is ready. I see no point in adding this extension to cvs actually, when we have pear, let's add it there, until then, I don't think this belongs in the php documentation or in the php source tree (no offense christian I just don't see a general enough usage for this extension). mmh.I'm fine with pear, if there would be a standard way for deploying traditional extensions. About the general usage of this extension: I see a lot of people using ImageMagick with exec()/system() since it supports a vast number of imageformats and some other features not supported by gd. Nevertheless, i'm certainly not offended, if you don't want it in the main cvs, but I think a lot of people could see a real use in it. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ext/imagick update (fwd)
On Wed, 21 Nov 2001 16:27:28 +0100, Sterling Hughes wrote: [snip] I think perhaps we should in the meantime have a little repository somewhere of extensions (just a list), where imagemagick could be listed. Also, as you said yourself, currently its very basic, so at least we should let it mature a little (btw, I'm just going on what you said here, I haven't looked at the code). yes, it's basic, but useable. ImageMagick's functionlist is extensiv, so it will be a lot to do. But the repository is a good idea. Or just hack the pear.php.net site the way, that one can see the php-c-extensions without all the pear-php-packages.. Anyway, I think this whole issue with extensions in PEAR/PECL should be discussed/implemented/whatever. Maybe better on pear-dev... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] ext/imagick update
Hi I wrote further on my ImageMagick extension (still a lot missing), but most importantly i wrote some documentation. You can have a look at it at http://php.chregu.tv/imagick/ comments etc. always welcome. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] ext/magick
Hi I wrote in the last few days my first php-extension. It's an extension for the ImageMagick library. It can't do much at the moment, more or less only converting from one image-format to another (but since ImageMagick supports a lot of them, it will be the main feature of it anyway..) if anyone is interested, it's available from http://pear.chregu.tv/magick.tgz or web cvs http://cvs.bitflux.ch/index.cgi/pearlib/magick/ since it's my first extension you'll maybe find some errors. any hints/help would be appreciated :) Features to come are: - support multiple images - support all the manipulation stuff - documentation ... - and more :) Is there any interest to get that included in the main php4 cvs, or should I check that in in the pear/pecl-cvs? or even not check it in anywhere and just make it downloadable from my site? so long chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ext/magick
On Mon, 19 Nov 2001, Andrei Zmievski wrote: I would suggest naming the functions with imagick_* prefix. You never know what other 'magick' might come along. Also, use underscores to separate words in the function names, i.e. imagick_sample_image() instead of magick_sampleimage(). ok, done that :) it's now called imagick. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] segfauls with ZEND_FETCH_RESOURCE (my first php extension...)
Hi
I wrote today my first php-extension and so far, everything worked fine,
until i used ZEND_FETCH_RESOURCE. My module seems not to be able to handle
that well, 'cause if i use it like the other extensions, i get a segfault.
The offending line is:
ZEND_FETCH_RESOURCE(test, php_test*, arg1, -1, magick object,
le_magick);
which produces the following segfault (from gdb):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7524)]
0x40224fa9 in zend_fetch_resource (passed_id=0x8123634, default_id=-1,
resource_type_name=0x4037a630 magick object,
found_resource_type=0x0,
num_resource_types=1) at zend_list.c:123
123 } else if ((*passed_id)-type != IS_RESOURCE) {
If i change the -1 to 1, then it handles Resource ID #1 without any
problem, but that's certainly not the solution, since everyone else uses
the -1
I stripped my code down until it does not much useful, only the ressource
stuff, but i still get segfaults.
The code is accesible at http://cvs.bitflux.ch/index.cgi/pearlib/magick/
any help/hints/etc is/are very welcome. I'm sure it's something very
stupid.
BTW: at www.zend.com/apidoc are some (important) tables missing...
chregu
--
nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich
pho...+41 1 451 6021 www...http://phant.ch/chregu
mob...+41 76 561 8860 [EMAIL PROTECTED]
wor...+41 1 240 5670 gpg...0x5CE1DECB
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] segfauls with ZEND_FETCH_RESOURCE (my first phpextension...)
On Sun, 18 Nov 2001, Markus Fischer wrote: On Sun, Nov 18, 2001 at 09:36:52PM +0100, Christian Stocker wrote : BTW: at www.zend.com/apidoc are some (important) tables missing... What exactly, can you elaborate more? the tables with the overview of all MACRO-Definition and more. Just all tables... The rest of my problem is solved. My first extension is running :) (there was a * too much and a too few...). BTW, the extension is for accessing ImageMagicks functions. It's very rudimentary at the moment, but if someone is interested, just have a look at http://cvs.bitflux.ch/index.cgi/pearlib/magick/ chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] email adress change request for cvs account
Hi my old company fucked up :) could someone please change my email adress from [EMAIL PROTECTED] to [EMAIL PROTECTED] for my cvs account (chregu). the old address bounces back since yesterday. (sorry for the trouble, but it's a kindergarten here at the moment...) thanks chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #12999 Updated: configure with sablotron support
Hi out there... this error pops up, when one doesn't have expat-dev installed (at debian, no idea about slackware), so maybe you should install expat from source or at least the expat developement package chregu In article [EMAIL PROTECTED], sniper [EMAIL PROTECTED] wrote: ID: 12999 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Sablotron XSL Operating System: Slackware Linux 8.0 PHP Version: 4.0.6 New Comment: Does config.log have any clues what might be wrong? Previous Comments: [2001-08-28 08:20:19] [EMAIL PROTECTED] hi, i can't compile php 4.0.6 and higher (4.0.7RC1) with sablotron support. i'm always getting a configure error: configure: error: iconv not found you can view the config.log at www.unividuum.de/config.log . anything else you need to know? thanks, cu. Edit this bug report at http://bugs.php.net/?id=12999edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mysql_fetch_xml
In article [EMAIL PROTECTED], Joey Smith [EMAIL PROTECTED] wrote: I agree with Brian on this. The only way I can see it being a good idea to have this in a module is if it were made part of the dbx extension, or maybe a PEAR C module... There's already a sql2xml module in pear called XML_sql2xml, which uses PEAR::DB and has some more features (so it's also more bloated, maybe :) ), but does basically the same. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mysql_fetch_xml
In article [EMAIL PROTECTED], Eliot Shepard [EMAIL PROTECTED] wrote: There's already a sql2xml module in pear called XML_sql2xml, which uses PEAR::DB and has some more features (so it's also more bloated, maybe :) ), but does basically the same. Ah. Had I been more aware of PEAR, I would have found this. Off-topic I know, but is there a plan for something a la search.cpan.org for PEAR? not yet, but (hopefully) soon. Some people are working on making pear.php.net useful ;) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
On Mon, 20 Aug 2001, Colin Viebrock wrote: FWIW, I've needed to hack my code to handle three differences between the 2 different API versions. To be honest, I can't keep track of which API was in which release of PHP, so I'll just call them API A) and API B). 1) Names of tags: API A) $node-name API B) $node-tagname 2) Tag attribute value: API A) $node-children[0]-content API B) $node-value 3) Is a node a text node: API A) $node-type == XML_TEXT_NODE API B) strtolower(get_class($node)) == 'domtext' i have one more :) content of a node API A) $node-content API B) $node-children()-content (that does not work this way, but you get the idea...) I haven't installed libxml 2.4.2 and PHP 4.0.7rc1 yet, but I'm wondering if someone can tell me which API version is in use? This script should tell you: it's API B) as far as i know chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] about domxml api-change in 4.0.7
Hello it looks like the new domxml-extension (and therefore a api-change) got into 4.0.7RC1. I still find it quite unfortunate to have this api-change in a minor release, but first the manual says, it's experimental and second i found a way, to write my code to work with the new and the old extension (bloats the code a little bit, but it works...) But could someone please at least make a note about that in the NEWS file. I think, a lot of people are using the domxml-extension and if it's not in the NEWS-file, they won't notice it and are surprised, that their scripts do not work anymore... BTW, i'm not sure if one can call it an api-change, since the functions did not change, but the structure of the returned values ... ($node-tagname instead of $node-name for example) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
In article [EMAIL PROTECTED], Joey Smith [EMAIL PROTECTED] wrote: Christian: The only change that I am aware of is the removal of half of the aliases that domxml used to use. For example, previous versions had both $node-tagname and $node-tag_name, which both returned the same structure. I have removed all of the former in favor of the latter, to hold to PHP conventions. Given the chance to think about it, you're right, there should have been some mention in NEWS about the work going on in domxml, but as it has been more or less completely broken for 2 point releases, I wasn't concerned at the time. What is the old API that you are referring to (ie, what PHP version)? the 2 changes i'm aware of (between 4.0.6 and 4.0.7): 1) $xml-root() in 4.0.6 returns: DomNode Object ( [node] = Resource id #3 [type] = 1 [name] = ibaconfig [content] = ) but in 4.0.7 DomElement Object ( [type] = 1 [tagname] = ibaconfig [0] = 3 [1] = 136185560 ) especially the difference between in name and tagname is annoying. -[content] is also missing in .7, so i have to do a $root-children(), where i can find the content of a DomElement-Object, but the structure of the returned array/classes is also different and not complete (why is there no type-attribute in a DomText Node?) I assume, these changes are done to comply with some standards/common writing of doms, so I see the intention behind that, but it should be noted somewhere (and the manual be updated). The changes between 4.0.6 and .7 are this big, 'cause the domxml version from an older version (4.0.4?) was included in the release and not the one in the cvs since 4.0.5-dev (or around that...). it was rolled back in 4.0.5 and 4.0.6 , 'cause of the drastic api-changes... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
On Sat, 18 Aug 2001, Jani Taskinen wrote: DOMXML is an experimental extension. So you can expect it to change still..Your mileage may vary :) e.g. In 4.0.7 the required libxml version will be 2.4.2. You obviously haven't read the manual.. sure, i read the manual and i'm aware of the experimental state :) I didn't say (this time ...), we should go back, i just wanted to point out, that the change should be mentionend in the NEWS file and (even better) the Manual (even though domxml is stated experimental, it's long enough in php to be used by a variety of people..). chregu --Jani On Sat, 18 Aug 2001, Christian Stocker wrote: In article [EMAIL PROTECTED], Joey Smith [EMAIL PROTECTED] wrote: Christian: The only change that I am aware of is the removal of half of the aliases that domxml used to use. For example, previous versions had both $node-tagname and $node-tag_name, which both returned the same structure. I have removed all of the former in favor of the latter, to hold to PHP conventions. Given the chance to think about it, you're right, there should have been some mention in NEWS about the work going on in domxml, but as it has been more or less completely broken for 2 point releases, I wasn't concerned at the time. What is the old API that you are referring to (ie, what PHP version)? the 2 changes i'm aware of (between 4.0.6 and 4.0.7): 1) $xml-root() in 4.0.6 returns: DomNode Object ( [node] = Resource id #3 [type] = 1 [name] = ibaconfig [content] = ) but in 4.0.7 DomElement Object ( [type] = 1 [tagname] = ibaconfig [0] = 3 [1] = 136185560 ) especially the difference between in name and tagname is annoying. -[content] is also missing in .7, so i have to do a $root-children(), where i can find the content of a DomElement-Object, but the structure of the returned array/classes is also different and not complete (why is there no type-attribute in a DomText Node?) I assume, these changes are done to comply with some standards/common writing of doms, so I see the intention behind that, but it should be noted somewhere (and the manual be updated). The changes between 4.0.6 and .7 are this big, 'cause the domxml version from an older version (4.0.4?) was included in the release and not the one in the cvs since 4.0.5-dev (or around that...). it was rolled back in 4.0.5 and 4.0.6 , 'cause of the drastic api-changes... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
On Sat, 18 Aug 2001, Jani Taskinen wrote: DOMXML is an experimental extension. So you can expect it to change still..Your mileage may vary :) e.g. In 4.0.7 the required libxml version will be 2.4.2. mmmh, JFYI, i have here only 2.4.1, but it seems to work with no problems. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
On Yesterday, Joey Smith wrote: That will change shortly. saw the cvs-commit. But just one question (out of curiosity): what's the sense of asking for 2.4.2, when 2.4.1 seems to work as well? Or did I just not hit that bug in 2.4.1 till now :) chregu On Sat, 18 Aug 2001, Christian Stocker wrote the following to...: On Sat, 18 Aug 2001, Jani Taskinen wrote: DOMXML is an experimental extension. So you can expect it to change still..Your mileage may vary :) e.g. In 4.0.7 the required libxml version will be 2.4.2. mmmh, JFYI, i have here only 2.4.1, but it seems to work with no problems. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] DOM/XML in 4.0.7
In article [EMAIL PROTECTED], Andi Gutmans [EMAIL PROTECTED] wrote: Hey, For 4.0.6 I rolled back the DOM/XML changes. It seems as if the current upgrade isn't being fixed. Maybe we should revert it back to what it was in 4.0.6 until it gets a thorough make over? yes, please :=) chregu, who has the same issues as in 4.0.6 about the domxml enhancements... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.6RC2
On 23 May 2001 09:58:18 -0700, [EMAIL PROTECTED] (Andi Gutmans) wrote: At 12:23 PM 5/23/2001 +0200, Christian Stocker wrote: In article [EMAIL PROTECTED], Andi Gutmans [EMAIL PROTECTED] wrote: Guys, I'd like to roll 4.0.6RC2 this evening (my evening which is in like 12 hours) as I mentioned a couple of days ago. I think we can also send it with a good explanation of what it is and what it isn't to php-general@ and get some more testing done and hopefully release 4.0.6 ASAP. it doesn't look like domxml was reverted to the old behaviour. Yeah but Colin said it works fine. Are you sure we should revert? I really want to get 4.0.6 out of the door and roll RC2 today. I have no clue about the DOM XML module and am not sure what we should do. There have always been problems with it. but as I said in the thread issues about domxml in 4.0.6 it's still almost impossible to write cross-version code with domxml which works in 4.0.5 and 4.0.6, just because for example the children() funcion returns a different array in the two versions. and i think, this is very nasty... I'm not sure anymore about the segfaults with the old syntax (eg domxml_children()), but as they are still in the documantation, i think a lot of people use them, as well. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Rollback of DOM/XML to 4.0.5 version
On 24 May 2001 05:39:14 -0700, [EMAIL PROTECTED] (Andi Gutmans) wrote: Hi, I rolled back DOM/XML and will hopefully roll RC2 today. I think my mmmh. checking for DOM support... yes ./configure: line 15188: syntax error near unexpected token `AC_ADD_INCLUDE($DOM XML_DIR/include)' ./configure: line 15188: ` AC_ADD_INCLUDE($DOMXML_DIR/include)' is it my fault? or is there really an error? (latest PHP_4_0_6 cvs on linux 2.4.2 and i did a buildconf after the update...) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Rollback of DOM/XML to 4.0.5 version
On 24 May 2001 08:14:02 -0700, [EMAIL PROTECTED] (Andi Gutmans) wrote: At 03:08 PM 5/24/2001 +, Christian Stocker wrote: On 24 May 2001 05:39:14 -0700, [EMAIL PROTECTED] (Andi Gutmans) wrote: Hi, I rolled back DOM/XML and will hopefully roll RC2 today. I think my mmmh. checking for DOM support... yes ./configure: line 15188: syntax error near unexpected token `AC_ADD_INCLUDE($DOM XML_DIR/include)' ./configure: line 15188: ` AC_ADD_INCLUDE($DOMXML_DIR/include)' is it my fault? or is there really an error? (latest PHP_4_0_6 cvs on linux 2.4.2 and i did a buildconf after the update...) Good chance that this is an error in the branch. I copied the PHP 4.0.5 config.m4 version to the PHP 4.0.6 branch. I think the format of config.m4 has changed since. Can you try and use the config.m4 from the main CVS branch (php4/ext/domxml/config.m4) and let me know if it works. If it does I will substitute that and release RC2. that was it. with the HEAD-Version of config.m4 it worked fine and compiled. I really need a couple of people to give me thumbs up on this one. It's just delaying 4.0.6 looks good from my side. didn't do a thorough checking but at least it works as expected. thumbs up for RC2 from my side :) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.6RC2
In article [EMAIL PROTECTED], Andi Gutmans [EMAIL PROTECTED] wrote: Guys, I'd like to roll 4.0.6RC2 this evening (my evening which is in like 12 hours) as I mentioned a couple of days ago. I think we can also send it with a good explanation of what it is and what it isn't to php-general@ and get some more testing done and hopefully release 4.0.6 ASAP. it doesn't look like domxml was reverted to the old behaviour. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] issues about domxml in 4.0.6
On Yesterday, Colin Viebrock wrote: I've contacted Uwe, and if he doesn't object (or respond ;) within the next day or so, I'll revert the commit in the 4_0_6 branch (leaving head alone). Whoa. Are you saying that 4.0.6 will revert to the domxml syntax that was in 4.0.4 and previous? And that 4.0.5 will just have it's own syntax? no, i don't think, either, that this would be a good idea. but in 4.0.5 the old and the new syntax worked (i'm not sure what's really old and what's new). so if i want to get the childrens of a root domNode i could write: $children = domxml_children($root); (the old method ?) or $children = $root-children; (i assume the new one...) in 4.0.5 both worked. in 4.0.6 only the second works, the first causes a segfault... and segfaults are very annoying for debugging php-code (and maybe some coders even don't know, where their error_log file is to look for segfaults...) and if you compare the returned array $children from the above example in 4.0.5 and in 4.0.6 they are quite different, and that's much more annoying for writing cross-version (what a word...) code. If the this change stays in 4.0.6 please please at least update the documentation and clearly state the difference between 4.0.5 and 4.0.6. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] issues about domxml in 4.0.6
Hello As mentioned in bug #9896 the api for domxml seems to has changed a lot... it's now almost impossible to write code with domxml which works in 4.0.5 and 4.0.6. for example $root-children() returns a completely different Array (tagname instead of name and so on...). Does this make sense for a minor-update? And all the domxml function still just produce a segfault on 4.0.6. if this is not supported anymore, fine ($root-children() instead of domxml_children($root) works also in 4.0.5), but i'd prefer a fatal error instead of a segfault :) Maybe I have to live with all these api-changes and as soon as all our servers have 4.0.6, it won't be a problem for me. But I think i'm not the only one which disturbs that a little bit. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] off...+41 1 240 2304 icq...4196137 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] issues about domxml in 4.0.6
On Wed, 16 May 2001, Jani Taskinen wrote: On Wed, 16 May 2001, Christian Stocker wrote: As mentioned in bug #9896 the api for domxml seems to has changed a lot... it's now almost impossible to write code with domxml which works in 4.0.5 and 4.0.6. for example $root-children() returns a completely different Array (tagname instead of name and so on...). Does this make sense for a minor-update? No, it does not make any sense. Just curious..what would you think the version number change should be? So that it would tell you that there has been major changes? i think, 4.1 would make me to have a look, if there were some api-changes. but not 4.0.5 to 4.0.6... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
