[PHP-DEV] IRCG/PHP and Apache 1.3
Hi! For all of you who are interested in running IRCG in combination with Apache 1.3, have a look at: URL:http://schumann.cx/ircg/ircg4.php -- About IRCG IRCG is a revolutionary way for dispatching messages to huge groups of users over an arbitrary number of separate communication channels in real-time. IRCG provides message streams over persistent HTTP connections and can interface with a subsystem to produce static file snippets. All aspects of IRCG are scriptable using PHP. IRCG is format and content agnostic, and can produce any output format you require, including XML, XHTML/HTML, and WML. Typical applications of IRCG include online gaming/gambling sites and web chat systems. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default Return-Path with mail() and qmail
hi, I'm a big -1 on this. The patch will not actually solve the root problem. On Unix systems, the MTA needs to know that the webserver user is 'trusted' to masquerade as another user. In exim this would be the 'trusted-users' directive, sendmail, qmail, and postfix have similar directives. Thanks for pointing this out. I was pretty sure there was something un-RFC-ish about my patch. However, I think the patch creates a more intuitive behaviour: If the user supplies a From: header, he expects all replies coming back to this address -- be it human generated responses or bounce messages. In contrast to qmail-inject (handling local mails), qmail-smtp (the SMTP-daemon) DOES use the From header (of the mail envelope, not header) for the Return-Path. I would call this inconsistent behaviour. However, I'm currently discussing this on the qmail mailing list, please don't be bothered by this here :) You might consider recommending a configuration setting like the following in each VirtualHost block on a multi-domain Apache server. This sends bounces and replies to the webmaster of the domain if no attempt is made to set the From: and Reply-to: headers when mail() is used. VirtualHost www.mydomain.com pph_admin_value sendmail_path /usr/sbin/sendmail -t [EMAIL PROTECTED] That's actually a good proposition. The documentation team might want to catch this up. Unfortunately, this doesn't work with my setup, as I'm (mod_cgi-)wrapping all scripts. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Modules/Extensions not in 4.3
The peardoc format will be phased out for peardoc2 which
uses several files, that is one per function, one for constants,
etc.
It makes sense to document PECL in the pear manual since PECL is
in pear.
Well, actually this what I wanted to hear :) I also think that moving
PECL module's manuals to PECL is the way to go. Those extensions are
mostly rarely used... We can make up a list in the manual about moved
extensions and some text about why this happened / happens...
IMO, a lot of extensions that are currently documented in the PHP
manual could be moved to PECL and PEAR doc. This would make the
PHP manual lighter to download, display, handle. The PHP manual
could keep documentation about the core extensions (still to be
defined).
This isn't really the question as we (the doc teams) don't make
these (php4/ext-pecl) decisions. I don't think anyone feels
the documentation of PECL modules belong in the php manual or
vice versa but the question is how and when to deal with the
moved extensions. When the php-dev team moves an extension we:
(a) Move the docs (phpdoc-peardoc)
Verify the docs are online in the pear manual before removed
from the php manual. (which means the peardoc vs peardoc2
craziness must also be dealt with)
(b) Make sure php.net/{extensionname} still does something
useful.
Whether filler pages or 404 handles this is in question.
And whether or not individual functions are kept track
of is another. Also, this may just refer to (c).
(c) Make a note in an up-and-coming phpdoc appendix page on
moved and removed extensions which may look like:
=
| Extension | Change | Reason | Moved in |
=
aspell removed pspell.. 4.3.0
cybercashremoved ...4.3.0
cybermut moved.. ...4.3.0
-
(d) ???
Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.
Maybe all moves have been completed?. For now, we rely on NEWS
entries.
Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time. A few were removed in 4.3.0,
see NEWS and CVS entries for details. Removed/deprecated
extensions have been dealt with in a couple different ways:
(1) icap : php.net/icap simply redirects to php.net/mcal
icap docs are not generated.
(2) aspell : All deprecated functions have been listed for
quite some time. It also mentions use pspell
(3) Redirect to (c) above.
I prefer the second because of historical reasons and the
fact that users may still be using the old functions. For
how long will these docs remain? Should they ever go in the
appendix instead? Will this confuse users? These are good
questions :) Also, what is done may depend on the individual
extensions themselves although consistancy has its merits.
Regards,
Philip Olson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Modules/Extensions not in 4.3
ext/db is deprecated by dba since 4.3 (earlier versions of dba are very
different).
I plan on emulating db calls in ext/dba. If this is done we can either
remove db
or move it to pecl (i vote for removing then). The remaining difference
current
difference between the two is that db uses magic quotes for key names while
dba does not. I plan to make the wrapper functions in dba work exactly the
same
way as in db.
If you want to do something about those two extensions now you could simply
add a note to every db page that db is deprecated and also add a link to the
corresponding dba functions.
regards
marcus
At 11:57 29.11.2002, Philip Olson wrote:
The peardoc format will be phased out for peardoc2 which
uses several files, that is one per function, one for constants,
etc.
It makes sense to document PECL in the pear manual since PECL is
in pear.
Well, actually this what I wanted to hear :) I also think that moving
PECL module's manuals to PECL is the way to go. Those extensions are
mostly rarely used... We can make up a list in the manual about moved
extensions and some text about why this happened / happens...
IMO, a lot of extensions that are currently documented in the PHP
manual could be moved to PECL and PEAR doc. This would make the
PHP manual lighter to download, display, handle. The PHP manual
could keep documentation about the core extensions (still to be
defined).
This isn't really the question as we (the doc teams) don't make
these (php4/ext-pecl) decisions. I don't think anyone feels
the documentation of PECL modules belong in the php manual or
vice versa but the question is how and when to deal with the
moved extensions. When the php-dev team moves an extension we:
(a) Move the docs (phpdoc-peardoc)
Verify the docs are online in the pear manual before removed
from the php manual. (which means the peardoc vs peardoc2
craziness must also be dealt with)
(b) Make sure php.net/{extensionname} still does something
useful.
Whether filler pages or 404 handles this is in question.
And whether or not individual functions are kept track
of is another. Also, this may just refer to (c).
(c) Make a note in an up-and-coming phpdoc appendix page on
moved and removed extensions which may look like:
=
| Extension | Change | Reason | Moved in |
=
aspell removed pspell.. 4.3.0
cybercashremoved ...4.3.0
cybermut moved.. ...4.3.0
-
(d) ???
Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.
Maybe all moves have been completed?. For now, we rely on NEWS
entries.
Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time. A few were removed in 4.3.0,
see NEWS and CVS entries for details. Removed/deprecated
extensions have been dealt with in a couple different ways:
(1) icap : php.net/icap simply redirects to php.net/mcal
icap docs are not generated.
(2) aspell : All deprecated functions have been listed for
quite some time. It also mentions use pspell
(3) Redirect to (c) above.
I prefer the second because of historical reasons and the
fact that users may still be using the old functions. For
how long will these docs remain? Should they ever go in the
appendix instead? Will this confuse users? These are good
questions :) Also, what is done may depend on the individual
extensions themselves although consistancy has its merits.
Regards,
Philip Olson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Modules/Extensions not in 4.3
Wez Furlong schrieb: o One doc download for the PHP core + bundled extensions (which may reside in PECL). o One doc download for the PEAR classes + non-bundled PECL extensions o One doc download for extension developers (the streams and zend API stuff needs a proper home). o One doc system to rule them all (but keep it modular of course). +1 Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Modules/Extensions not in 4.3
IMO, the manual should include all of the maintstream PHP extensions.
The reasoning is that if someone downloads the PHP manual, they expect
to get the PHP manual and not have to hunt around for docs on extensions
X, Y, Z.
Remember that one of our goals is to move most of ext/* into PECL, but
still bundle these pickled extensions in our official release packages,
so the idea that PECL should be documented under PEAR is not such a good
one.
Again, IMO, the madness of having no less than 3 different docu systems
(phpdoc, peardoc and peardoc2) makes very little sense; why not just use
one system (tm) for docs? (let's save some developer brain power for
more useful things).
So, what I'd like to see (and this seems reasonable, IMO) is:
o One doc download for the PHP core + bundled extensions (which may
reside in PECL).
o One doc download for the PEAR classes + non-bundled PECL extensions
o One doc download for extension developers (the streams and zend API
stuff needs a proper home).
o One doc system to rule them all (but keep it modular of course).
--Wez.
On Fri, 29 Nov 2002, Philip Olson wrote:
The peardoc format will be phased out for peardoc2 which
uses several files, that is one per function, one for constants,
etc.
It makes sense to document PECL in the pear manual since PECL is
in pear.
Well, actually this what I wanted to hear :) I also think that moving
PECL module's manuals to PECL is the way to go. Those extensions are
mostly rarely used... We can make up a list in the manual about moved
extensions and some text about why this happened / happens...
IMO, a lot of extensions that are currently documented in the PHP
manual could be moved to PECL and PEAR doc. This would make the
PHP manual lighter to download, display, handle. The PHP manual
could keep documentation about the core extensions (still to be
defined).
This isn't really the question as we (the doc teams) don't make
these (php4/ext-pecl) decisions. I don't think anyone feels
the documentation of PECL modules belong in the php manual or
vice versa but the question is how and when to deal with the
moved extensions. When the php-dev team moves an extension we:
(a) Move the docs (phpdoc-peardoc)
Verify the docs are online in the pear manual before removed
from the php manual. (which means the peardoc vs peardoc2
craziness must also be dealt with)
(b) Make sure php.net/{extensionname} still does something
useful.
Whether filler pages or 404 handles this is in question.
And whether or not individual functions are kept track
of is another. Also, this may just refer to (c).
(c) Make a note in an up-and-coming phpdoc appendix page on
moved and removed extensions which may look like:
=
| Extension | Change | Reason | Moved in |
=
aspell removed pspell.. 4.3.0
cybercashremoved ...4.3.0
cybermut moved.. ...4.3.0
-
(d) ???
Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.
Maybe all moves have been completed?. For now, we rely on NEWS
entries.
Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time. A few were removed in 4.3.0,
see NEWS and CVS entries for details. Removed/deprecated
extensions have been dealt with in a couple different ways:
(1) icap : php.net/icap simply redirects to php.net/mcal
icap docs are not generated.
(2) aspell : All deprecated functions have been listed for
quite some time. It also mentions use pspell
(3) Redirect to (c) above.
I prefer the second because of historical reasons and the
fact that users may still be using the old functions. For
how long will these docs remain? Should they ever go in the
appendix instead? Will this confuse users? These are good
questions :) Also, what is done may depend on the individual
extensions themselves although consistancy has its merits.
Regards,
Philip Olson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
On November 29, 2002 01:05 am, Sara Golemon wrote: I disagree with this, the current behaviour is imho wrong. mailto: is a url, rejecting the patch because it introduces a special case, is not a good thing. parse_url() is for _all_ url's, not just http:// url's, and besides, the current syntax for mailto is completely valid, and should be parsed anyway. (ie, a special case shouldn't be required if the url parser was rfc compliant). PHP's php_url_parse() function is not in any way limited to http:// as you claim, it support a large variety of valid URLs, take a look at the very extensive test for parse_url() function located here: ext/standard/tests/strings/url_t.phpt. Even the regular expression described in RFC 2396 does not recognize mailto: any differently the our very own parse_url(). It looks like php_url_parse can be modified to return user and host for mailto schemes without making it a 'special case', but that would also remove the current 'path' index which would break existing PHP code ((bad)). So we can (A) put in a special case, or (B) not modify the function at all. Either way leaves someone unhappy so in the absence of a majority I can't help but do nothing. This request will have to remain open, at least for now. Users requests all kinds of features all the time, just because someone will be unhappy because their request is not implemented is hardly a reason to implement it. As a rule, special cases are bad, if you REALLY think this is useful functionality we are better off adding a parse_email() function, who's job would be to break email addresses into parts. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Some image functions are broken
i was just about to create some image (ext/gd) tests while i found out that imagegd2 and imagefromgd functions are broken. I checked with versions 4.3 and cvs. - You can convert an image to gd but you cannot reload it. - You cannot create an gd2 image. - png - jpeg and reverse is good. [marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 'imagegd(imagecreatefrompng($argv[1]), $argv[2]);' -- ext/gd/tests/test.png ext/gd/tests/test.gd make: `sapi/cli/php' is up to date. [marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 'imagegd2(imagecreatefrompng($argv[1]), $argv[2]);' -- ext/gd/tests/test.png ext/gd/tests/test.gd2 make: `sapi/cli/php' is up to date. Segmentation fault [marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 'imagepng(imagecreatefromgd($argv[1]), $argv[2]);' -- ext/gd/tests/test.gd ext/gd/tests/test1.png make: `sapi/cli/php' is up to date. Segmentation fault [marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 'imagejpeg(imagecreatefrompng($argv[1]), $argv[2]);' -- ext/gd/tests/test.png ext/gd/tests/test.jpeg make: `sapi/cli/php' is up to date. [marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 'imagepng(imagecreatefromjpeg($argv[1]), $argv[2]);' -- ext/gd/tests/test.jpeg ext/gd/tests/test.1.png make: `sapi/cli/php' is up to date. [marcus@zaphod php4-HEAD]$ cm cmp cmuwmtopbm [marcus@zaphod php4-HEAD]$ cmp ext/gd/tests/test.png ext/gd/tests/test.1.png ext/gd/tests/test.png ext/gd/tests/test.1.png differ: char 36, line 3 They differ because jpeg compression losses. :-) But the result looks o.k. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] test
test, please ignore J -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C++ extensions and ext_skel
The only modified file is ext_skel. There's also the addition of a file in ext/skeleton -- skeleton.cpp to go along with skeleton.c. I suppose I could get rid of the .cpp file, make a few changes to skeleton.c and have ext_skel make the proper modifications when it's replacing extname, EXTNAME and whatnot. The changes to config.m4 and Makefile.in are done in ext_skel. J Sascha Schumann wrote: On Thu, 28 Nov 2002, J Smith wrote: A couple of times a month, I get questions about from people looking to use C++ with PHP. Apparently, a lot of people end up reading some post I made to php.dev or something a year or so ago about C++, and although it worked at the time, the procedure I describe has become stale. I messed around a bit with ext_skel and ext/skeleton today and added an option to ext_skel (--cpp) that creates a basic C++ extension rather than the standard C extension. The C++ extension is pretty much the same as the standard C extension, with the exception of some extern C linkage, modifications to config.m4 and Makefile.in and a small C++ class thrown in for fun. Cannot those be unified? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PEAR-DOC] Re: [PHP-DEV] Re: Modules/Extensions not in 4.3
Well, you suggestion makes sense. I wonder about something though. How
different are phpdoc/peardoc/peardoc2 ?
As i said the plan was to move from peardoc to peardoc2. If we move
everything to phpdoc we'll have to port peardoc and peardoc2 to phpdoc, it
will need a lot of work.
There is also a project to generate peardoc2 automoatically from PHPDoc
comments using phpdocumentor and others scripts, greg beaver as well as
alexander are working on that. If peardoc2 and phpdoc are compatible that
would be great.
Arnaud.
IMO, the manual should include all of the maintstream PHP
extensions.
The reasoning is that if someone downloads the PHP manual, they expect
to get the PHP manual and not have to hunt around for docs on
extensions
X, Y, Z.
Remember that one of our goals is to move most of ext/* into PECL, but
still bundle these pickled extensions in our official release
packages,
so the idea that PECL should be documented under PEAR is not
such a good
one.
Again, IMO, the madness of having no less than 3 different
docu systems
(phpdoc, peardoc and peardoc2) makes very little sense; why
not just use
one system (tm) for docs? (let's save some developer brain power for
more useful things).
So, what I'd like to see (and this seems reasonable, IMO) is:
o One doc download for the PHP core + bundled extensions (which may
reside in PECL).
o One doc download for the PEAR classes + non-bundled PECL extensions
o One doc download for extension developers (the streams and zend API
stuff needs a proper home).
o One doc system to rule them all (but keep it modular of course).
--Wez.
On Fri, 29 Nov 2002, Philip Olson wrote:
The peardoc format will be phased out for peardoc2 which
uses several files, that is one per function, one for
constants,
etc.
It makes sense to document PECL in the pear manual
since PECL is
in pear.
Well, actually this what I wanted to hear :) I also
think that moving
PECL module's manuals to PECL is the way to go. Those
extensions are
mostly rarely used... We can make up a list in the
manual about moved
extensions and some text about why this happened / happens...
IMO, a lot of extensions that are currently documented in the PHP
manual could be moved to PECL and PEAR doc. This would make the
PHP manual lighter to download, display, handle. The PHP manual
could keep documentation about the core extensions (still to be
defined).
This isn't really the question as we (the doc teams) don't make
these (php4/ext-pecl) decisions. I don't think anyone feels
the documentation of PECL modules belong in the php manual or
vice versa but the question is how and when to deal with the
moved extensions. When the php-dev team moves an extension we:
(a) Move the docs (phpdoc-peardoc)
Verify the docs are online in the pear manual before removed
from the php manual. (which means the peardoc vs peardoc2
craziness must also be dealt with)
(b) Make sure php.net/{extensionname} still does something
useful.
Whether filler pages or 404 handles this is in question.
And whether or not individual functions are kept track
of is another. Also, this may just refer to (c).
(c) Make a note in an up-and-coming phpdoc appendix page on
moved and removed extensions which may look like:
=
| Extension | Change | Reason | Moved in |
=
aspell removed pspell.. 4.3.0
cybercashremoved ...4.3.0
cybermut moved.. ...4.3.0
-
(d) ???
Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.
Maybe all moves have been completed?. For now, we rely on NEWS
entries.
Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time. A few were removed in 4.3.0,
see NEWS and CVS entries for details. Removed/deprecated
extensions have been dealt with in a couple different ways:
(1) icap : php.net/icap simply redirects to php.net/mcal
icap docs are not generated.
(2) aspell : All deprecated functions have been listed for
quite some time. It also mentions use pspell
(3) Redirect to (c) above.
I prefer the second because of historical reasons and the
fact that users may still be using the old functions. For
how long will these docs remain? Should they ever go in the
appendix instead? Will this confuse users? These are good
questions :) Also, what is done may depend on the individual
extensions themselves although consistancy has its merits.
Regards,
Re: [PHP-DEV] ZE2 and standard class initialization
Applied. Andi At 05:31 PM 11/28/2002 +0100, Marcus Börger wrote: In ZE2 zend.c there is a structure member not initialized for. See patch below. marcus Index: Zend/zend.c === RCS file: /repository/ZendEngine2/zend.c,v retrieving revision 1.191 diff -u -r1.191 zend.c --- Zend/zend.c 24 Nov 2002 20:15:56 - 1.191 +++ Zend/zend.c 28 Nov 2002 16:24:02 - @@ -289,6 +289,8 @@ zend_standard_class_def-handle_property_get = NULL; zend_standard_class_def-handle_property_set = NULL; zend_standard_class_def-refcount = 1; + zend_standard_class_def-constants_updated = 0; zend_hash_add(GLOBAL_CLASS_TABLE, stdclass, sizeof(stdclass), zend_standard_class_def, sizeof(zend_class_entry *), NULL); } -- 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 question
At 04:30 PM 11/28/2002 +, James Cox wrote: it means double colon in hebrew... i think Zeev and Andi must not have known what to call it in english when they put it in... but hey, it was the first i18n'ized error message :) We are very attached to this token because it was put in when we were coding very late one night a few years ago :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZE2 + public/protected/private/final
At 06:25 PM 11/28/2002 +0100, Marcus Börger wrote: With current ZE2 it is possible to instanciate an abstract class. That is a class that has at least one abstract method. When we add a flag field to class_entry struct we can handle this. We simply need to set an abstract flag for the class entry when any abstract method is added or inherited. I updated the full patch to do it that way: http://marcus-boerger.de/php/ext/ze2/ze2-f3p-21128.diff.txt I thought about this but am not quite sure how I feel about this. I know that theoretically in C++ and Java you can't instantiate such classes but I'm not sure it'd be too bad in PHP. If I were to implement this I'd probably use a counter to *remember* how many abstract methods a class has. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
It looks like php_url_parse can be modified to return user and host for mailto schemes without making it a 'special case', but that would also remove the current 'path' index which would break existing PHP code ((bad)). So we can (A) put in a special case, or (B) not modify the function at all. Either way leaves someone unhappy so in the absence of a majority I can't help but do nothing. This request will have to remain open, at least for now. Users requests all kinds of features all the time, just because someone will be unhappy because their request is not implemented is hardly a reason to implement it. As a rule, special cases are bad, if you REALLY think this is useful functionality we are better off adding a parse_email() function, who's job would be to break email addresses into parts. I'm not so much worried about the user in this case, a few explodes will keep them happy. I'm more worried about the behavior of parse_url being just plain lacking. mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to everybit as much parsing as http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value The ONLY real concern here, and reason for not fixing php_url_parse, comes in the fact that 'path' would no longer contain '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would likely break existing scripts. Perhaps the compromise is to create a new function 'parse_url_rfc' (name could be better) which behaves correctly (without having special cases). Then add a note to the manpage for parse_url saying to use parse_url_rfc instead, and eventually depricate parse_url (perhaps with PHP 5.0). -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
On Fri, 29 Nov 2002, Sara Golemon wrote: I'm not so much worried about the user in this case, a few explodes will keep them happy. I'm more worried about the behavior of parse_url being just plain lacking. mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to everybit as much parsing as http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value The ONLY real concern here, and reason for not fixing php_url_parse, comes in the fact that 'path' would no longer contain '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would likely break existing scripts. Because mailto URL is not one of the common internet/host URLs (that parse_url was designed to handle), this should not happen. Perhaps the compromise is to create a new function 'parse_url_rfc' (name could be better) which behaves correctly (without having special cases). Then add a note to the manpage for parse_url saying to use parse_url_rfc instead, and eventually depricate parse_url (perhaps with PHP 5.0). But which RFC would it follow? There are at least 3 :) Why not just use the Net_URL pear package? --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
On November 29, 2002 12:41 pm, Sara Golemon wrote: It looks like php_url_parse can be modified to return user and host for mailto schemes without making it a 'special case', but that would also remove the current 'path' index which would break existing PHP code ((bad)). So we can (A) put in a special case, or (B) not modify the function at all. Either way leaves someone unhappy so in the absence of a majority I can't help but do nothing. This request will have to remain open, at least for now. Users requests all kinds of features all the time, just because someone will be unhappy because their request is not implemented is hardly a reason to implement it. As a rule, special cases are bad, if you REALLY think this is useful functionality we are better off adding a parse_email() function, who's job would be to break email addresses into parts. I'm not so much worried about the user in this case, a few explodes will keep them happy. I'm more worried about the behavior of parse_url being just plain lacking. mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to everybit as much parsing as http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value The ONLY real concern here, and reason for not fixing php_url_parse, comes in the fact that 'path' would no longer contain '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would likely break existing scripts. Perhaps the compromise is to create a new function 'parse_url_rfc' (name could be better) which behaves correctly (without having special cases). Then add a note to the manpage for parse_url saying to use parse_url_rfc instead, and eventually deprecate parse_url (perhaps with PHP 5.0). No. parse_url_rfc would be misleading because it would not follow RFC. There are special rules for scheme:, scheme:/ and scheme://, your suggested patch would actually break RFC, since mailto: is already parsed properly according to RFC. E-mail addresses are not urls, if we want to offer an email parser it should be separate function parse_email or something similar, there is no need to pollute php_parse_url() with hacks for non-intended functionality. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
I'm not so much worried about the user in this case, a few explodes will keep them happy. I'm more worried about the behavior of parse_url being just plain lacking. mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to everybit as much parsing as http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value The ONLY real concern here, and reason for not fixing php_url_parse, comes in the fact that 'path' would no longer contain '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would likely break existing scripts. Perhaps the compromise is to create a new function 'parse_url_rfc' (name could be better) which behaves correctly (without having special cases). Then add a note to the manpage for parse_url saying to use parse_url_rfc instead, and eventually deprecate parse_url (perhaps with PHP 5.0). No. parse_url_rfc would be misleading because it would not follow RFC. There are special rules for scheme:, scheme:/ and scheme://, your suggested patch would actually break RFC, since mailto: is already parsed properly according to RFC. E-mail addresses are not urls, if we want to offer an email parser it should be separate function parse_email or something similar, there is no need to pollute php_parse_url() with hacks for non-intended functionality. Okay, okay... I throw my hands up... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Modules/Extensions not in 4.3
On Fri, 29 Nov 2002, Wez Furlong wrote:
IMO, the manual should include all of the maintstream PHP extensions.
The reasoning is that if someone downloads the PHP manual, they expect
to get the PHP manual and not have to hunt around for docs on extensions
X, Y, Z.
So mainstream is defined as which are bundled with the
PHP4 source, whether it's in PECL or not? Does anyone
know or have a list of what will go where and when? Is
the install, configure, and use process different for
PECL extensions? Why are any PECL extensions bundled in
PHP4 source? That seems to defeat the purpose.
Currently the php and pear docs are like separate entities,
perhaps we should tie them closer together. Like,
download-docs.php can include versions with the pear manual.
And php.net/{pearextension} can either redirect to or
load appropriate manual/info pages. Anyway, point is
they can be better and closer friends.
Remember that one of our goals is to move most of ext/* into PECL, but
still bundle these pickled extensions in our official release packages,
so the idea that PECL should be documented under PEAR is not such a good
one.
I'm not familiar with this topic. Currently PECL is documented
under PEAR, and since it's part of PEAR it makes sense. It's
hard enough to decide which extensions go into PECL let alone
which PECL are documented in what manual. I am curious what is
meant by most, that sounds a little scary and makes having
all extensions in one manual more attractive. Is there an
option to only download needed pecl at compile time, kinda
like how 'pear install foo' is done now? Or an option to
download each separate, or all of them at once? I don't see
why any PECL would be bundled. But anyway, back to the docs.
Some disadvantages of having the docs separate:
* phpdoc has a ton more translators.
* more people have phpdoc karma and feel comfortable
touching phpdoc source
* downloading two manuals and/or viewing two websites
* most living in pecl, yet many bundled in php4
With the main advantage being it would be in its proper home.
Again, IMO, the madness of having no less than 3 different docu systems
(phpdoc, peardoc and peardoc2) makes very little sense; why not just use
one system (tm) for docs? (let's save some developer brain power for
more useful things).
The peardoc/peardoc2 issue is temporary and confusing but will
be remedied at some point, not sure when. In fact, I personally
don't document pear because of it. The matter of a completely
separate PECL manual I also disagree with. Although who knows,
maybe if the build processes were more closely done together it
wouldn't be so bad.
So, what I'd like to see (and this seems reasonable, IMO) is:
o One doc download for the PHP core + bundled extensions (which may
reside in PECL).
o One doc download for the PEAR classes + non-bundled PECL extensions
o One doc download for extension developers (the streams and zend API
stuff needs a proper home).
o One doc system to rule them all (but keep it modular of course).
I agree with this except have reservations about some PECL
going in PEAR manual while others in the main manual. I
*strongly* agree with a uniform system but AFAICT it won't
exactly be the case with current plans (phpdocumentor).
Regarding the separate developers manual, the main reason it
hasn't already been done (aside from time constraints) is there
is question on whether it should be translated or not. I vote no
it shouldn't as that'd mean outdated developer docs as the zendapi
stuff seems to change a lot and translations are slow and
sometimes are just one-time operations. In fact, aren't the current
en zendapi docs already outdated? I don't know this topic. On a
related note, those PHP4/README.* docs would fit nicely in this
dev manual.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Modules/Extensions not in 4.3
Hi Philip, On Fri, 29 Nov 2002, Philip Olson wrote: So mainstream is defined as which are bundled with the PHP4 source, whether it's in PECL or not? Does anyone know or have a list of what will go where and when? Is the install, configure, and use process different for PECL extensions? Why are any PECL extensions bundled in PHP4 source? That seems to defeat the purpose. As I just explained to you on IRC (and repeating here for the record), the aim is to have a virtually empty php5/ext/ directory and have all extensions (besides standard) living in PECL. Once in PECL, the extensions gain dependency tracking information. When we publish a release, we will pick the gold extensions based on the userbase (popular extensions will be included by default) and the level of maintenance (crufty extensions might not be bundled by default). So, what I'd like to see (and this seems reasonable, IMO) is: o One doc download for the PHP core + bundled extensions (which may reside in PECL). o One doc download for the PEAR classes + non-bundled PECL extensions o One doc download for extension developers (the streams and zend API stuff needs a proper home). o One doc system to rule them all (but keep it modular of course). Regarding the separate developers manual, the main reason it hasn't already been done (aside from time constraints) is there is question on whether it should be translated or not. I vote no it shouldn't as that'd mean outdated developer docs as the zendapi stuff seems to change a lot and translations are slow and sometimes are just one-time operations. In fact, aren't the current en zendapi docs already outdated? I don't know this topic. On a related note, those PHP4/README.* docs would fit nicely in this dev manual. Yes, the developer docs should be written only in english for the reasons you mention above (which are similar to the reasons for not localizing the php error messages). --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Changes to ext_skel for C++
Attached is a patch to ext_skel that adds an optional argument (--cpp) that
will create a PHP extension in C++ rather than C. Also attached is
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
modifications for using C++. I could've just made some changes to
skeleton.c and done some sed work in the ext_skel script, but I think it's
clearer to have them separated into two files.
The ext_skel patch is based on the current HEAD.
Comments?
J
Index: ext_skel
===
RCS file: /repository/php4/ext/ext_skel,v
retrieving revision 1.44
diff -u -3 -p -r1.44 ext_skel
--- ext_skel 18 Nov 2002 15:55:07 - 1.44
+++ ext_skel 29 Nov 2002 18:20:40 -
@@ -7,7 +7,7 @@ givup() {
usage() {
echo $0 --extname=module [--proto=file] [--stubs=file] [--xml[=file]]
-echo[--skel=dir] [--full-xml] [--no-help]
+echo[--skel=dir] [--full-xml] [--no-help] [--cpp]
echo
echo --extname=module module is the name of your extension
echo --proto=file file contains prototypes of functions to create
@@ -18,6 +18,7 @@ echo --full-xml generate xml
echo (not yet implemented)
echo --no-help don't try to be nice and create comments in the code
echo and helper functions to test if the module compiled
+echo --cpp create a C++ extension
exit 1
}
@@ -58,6 +59,9 @@ while test $# -gt 0; do
--skel=?*)
skel_dir=$optarg
;;
+--cpp)
+cpp=yes
+;;
*)
usage
;;
@@ -94,7 +98,7 @@ if test -z $stubs; then
fi
if test -n $proto; then
- cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -f $skel_dir/create_stubs
+ cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -v cpp=$cpp -f $skel_dir/create_stubs
fi
if test -z $stubs; then
@@ -165,11 +169,16 @@ if test \$PHP_$EXTNAME != no; then
dnl ])
dnl
dnl PHP_SUBST(${EXTNAME}_SHARED_LIBADD)
+eof
- PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)
+if test $cpp = yes; then
+ echo PHP_REQUIRE_CXX() config.m4
+ echo PHP_NEW_EXTENSION($extname, $extname.cpp, \$ext_shared) config.m4
+else
+ echo PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared) config.m4
fi
-eof
+echo fi config.m4
$ECHO_N .cvsignore$ECHO_C
cat .cvsignore eof
@@ -178,7 +187,11 @@ cat .cvsignore eof
*.la
eof
-$ECHO_N $extname.c$ECHO_C
+if test $cpp = yes; then
+$ECHO_N $extname.cpp$ECHO_C
+else
+$ECHO_N $extname.c$ECHO_C
+fi
echo s/extname/$extname/g sedscript
echo s/EXTNAME/$EXTNAME/g sedscript
echo '/__function_entries_here__/r function_entries' sedscript
@@ -189,6 +202,7 @@ echo '/__function_entries_here__/D'
echo '/__function_stubs_here__/D' sedscript
echo '/__header_here__/D' sedscript
echo '/__footer_here__/D' sedscript
+
if [ ! -z $no_help ]; then
echo /confirm_$extname_compiled/D sedscript
echo '/Remove the following/,/^\*\//D' sedscript
@@ -197,7 +211,11 @@ if [ ! -z $no_help ]; then
echo '/^[[:space:]]*\/\*/,/^[[:space:]]*\*\//D' sedscript
fi
-sed -f sedscript $skel_dir/skeleton.c $extname.c
+if test $cpp = yes; then
+sed -f sedscript $skel_dir/skeleton.cpp $extname.cpp
+else
+sed -f sedscript $skel_dir/skeleton.c $extname.c
+fi
$ECHO_N php_$extname.h$ECHO_C
@@ -273,7 +291,15 @@ To use your new extension, you will have
4. $ ./configure --[with|enable]-$extname
5. $ make
6. $ ./php -f ext/$extname/$extname.php
-7. $ vi ext/$extname/$extname.c
+eof
+
+ if test $cpp = yes; then
+ echo 7. $ vi ext/$extname/$extname.cpp
+ else
+ echo 7. $ vi ext/$extname/$extname.c
+ fi
+
+ cat eof
8. $ make
Repeat steps 3-6 until you are satisfied with ext/$extname/config.m4 and
/* __header_here__ */
#ifdef HAVE_CONFIG_H
#include config.h
#endif
extern C {
#include php.h
#include php_ini.h
#include ext/standard/info.h
}
#include php_extname.h
// C++ header...
#include string
using namespace std;
/* If you declare any globals in php_extname.h uncomment this:
ZEND_DECLARE_MODULE_GLOBALS(extname)
*/
/* True global resources - no need for thread safety here */
static int le_extname;
/* {{{ extname_functions[]
*
* Every user visible function must have an entry in extname_functions[].
*/
function_entry extname_functions[] = {
PHP_FE(confirm_extname_compiled, NULL) /* For testing, remove later. */
/* __function_entries_here__ */
{NULL, NULL, NULL} /* Must be the last line in extname_functions[] */
};
/* }}} */
/* {{{ extname_module_entry
*/
zend_module_entry extname_module_entry = {
#if ZEND_MODULE_API_NO = 20010901
STANDARD_MODULE_HEADER,
#endif
extname,
extname_functions,
PHP_MINIT(extname),
PHP_MSHUTDOWN(extname),
[PHP-DEV] Re: #20673 [Opn-Ver]: Inexplicable arithmetical error due to references
[EMAIL PROTECTED] wrote in php.bugs: [2002-11-27 07:04:52] [EMAIL PROTECTED] ? $a = 7; $a = $a + $a++; echo $a; //the result is 14; ? When I add a reference to $a, the behavior of $a + $a++ becomes inexplicable different. Note that $a isn't changed anywhere! ? $a = 7; $b = $a; $a = $a + $a++; echo $a; //the result is 15; ? The only difference is $b = $a, but why $a takes care of references to itself? Ilia verified the bug, and I can reproduce that behaviour here as well. But I'm not sure whether the expressions $a = $a + $a++; or $x = $a + $a++; really are valid/legal/well-defined expressions. When exactly is that $a++ meant to be interpreted/executed? Before or after that other $a is looked at? I know that PHP is not C, but hasn't that something to do with sections 3.1 to 3.3 of the C FAQ, http://www.eskimo.com/~scs/C-faq/s3.html? Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZE2 + public/protected/private/final
At 17:40 29.11.2002, Andi Gutmans wrote:
At 06:25 PM 11/28/2002 +0100, Marcus Börger wrote:
With current ZE2 it is possible to instanciate an abstract class. That is
a class
that has at least one abstract method. When we add a flag field to
class_entry
struct we can handle this. We simply need to set an abstract flag for the
class
entry when any abstract method is added or inherited.
I updated the full patch to do it that way:
http://marcus-boerger.de/php/ext/ze2/ze2-f3p-21128.diff.txt
I thought about this but am not quite sure how I feel about this. I know
that theoretically in C++ and Java you can't instantiate such classes but
I'm not sure it'd be too bad in PHP.
If I were to implement this I'd probably use a counter to *remember* how
many abstract methods a class has.
Andi
I would like a list of abstract methods in case the error is at hand more.
On the other side i do not know if the check is what we want. I mean it
keeps you away
from using abstract classes what is a must in C++/Java. But for PHP this is
only valid
as long as we do not:
a) allow to dynamically add new methods to instances/classes
(This would make some more thinks complicated but makes PHP more object
oriented)
b) explicitly allow using abstract classes by decision here
Also the check has one negative aspect: it cost time (even thogh only a few
small tests).
Your counter would be slower and could instead be simply computed when the
error is
being generated. See pseudo code:
cnt = 0
foreach function in function_table
if function-common.fn_flags FN_ABSTRACT
cnt++
Since there is until now no need to change the class_entry while inheriting
a method we
can also show the class in which the method was introduced. Maybe like
shown below:
class test {
abstract funcition a();
}
class fail extends test {
}
$t = new fail();
Fatal Error: You cannot instanciate abstract class fail (abstract methods:
test::a)
marcus
p.s. I updated the complete patch:
http://marcus-boerger.de/php/ext/ze2/ze2-f3p-21129.diff
after your commit.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] +3 for Win32 CoInitalize/CoUninitialize Call Move, Please Apply
We got +3 on applying this but missed it for 4.3.0 RC2. Will someone
with the correct karma please apply it to the 4.3.0 tree?
Michael
--- Michael Sisolak [EMAIL PROTECTED] wrote:
Date: Mon, 25 Nov 2002 10:32:13 -0800 (PST)
From: Michael Sisolak [EMAIL PROTECTED]
Subject: [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move
To: [EMAIL PROTECTED]
While stess testing the recent threading fixes under the ISAPI module
I
was seeing a lot of instability in IIS after the testing finished.
While the PHP pages would continue to load, no ASP pages would
anymore.
I have tracked this down to the placement of the Win32
CoInitialize()
and CoUninitialize() calls. In the current 4.3.0 release candidate
CoInitialize() and CoUninitialize() are only called once per thread
(from the basic_globals_ctor/_dtor in basic_functions.c). According
to
Microsoft, however, at
http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/devs0hm5.asp:
COM initialization, from CoInitialize or CoInitializeEx, affects the
thread in which it's called. For this reason, you cannot initialize
COM
unless you uninitialize it before returning from your callback
function. [ . . .] CoInitialize and CoUninitialize need to be called
in
order. If one is called twice in a row, by different ISAPIs on the
same
thread, your users may see error 270.
This is exactly the error I am seeing: if I load an ASP page in a
thread that has processed PHP pages I get the 270 error (reported as
Error -2147417842 (0x8001010e)). I moved the CoInitilize call to
PHP_RINIT_FUNCTION(basic) and CoUninitialize to
PHP_RSHUTDOWN_FUNCTION(basic) and reran my stress testing. After
100,000 PHP page loads IIS now remains stable and able to process
both
ASP and PHP pages.
I ran this by Zeev and he suggested that some kind of just-in-time
COM
initialization, but I'm not going to have the time to get to this
full
solution until later. In the meantime for 4.3.0 I request that the
attached patch is applied that moves the CoInitialize or
CoInitializeEx
calls to be per-request. This is the last little fix that all the
multi-threading bug fixing to make the ISAPI rock solid in 4.3.0
requires. I've done a lot of testing and feel very confident about
including this patch.
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- basic_functions.c.orig Fri Nov 08 10:49:32 2002
+++ basic_functions.c Mon Nov 25 13:25:09 2002
@@ -959,10 +959,6 @@
memset(BG(url_adapt_state), 0, sizeof(BG(url_adapt_state)));
memset(BG(url_adapt_state_ex), 0, sizeof(BG(url_adapt_state_ex)));
-#ifdef PHP_WIN32
- CoInitialize(NULL);
-#endif
-
BG(incomplete_class) = php_create_incomplete_class(TSRMLS_C);
}
@@ -973,9 +969,6 @@
if (BG(sm_allowed_env_vars)) {
free(BG(sm_allowed_env_vars));
}
-#ifdef PHP_WIN32
- CoUninitialize();
-#endif
}
@@ -1102,6 +1095,10 @@
PHP_RINIT_FUNCTION(basic)
{
+#ifdef PHP_WIN32
+ CoInitialize(NULL);
+#endif
+
memset(BG(strtok_table), 0, 256);
BG(strtok_string) = NULL;
BG(strtok_zval) = NULL;
@@ -1182,6 +1179,10 @@
if (BG(mmap_file)) {
munmap(BG(mmap_file), BG(mmap_len));
}
+#endif
+
+#ifdef PHP_WIN32
+ CoUninitialize();
#endif
return SUCCESS;
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
J Smith wrote:
Attached is a patch to ext_skel that adds an optional argument (--cpp) that
will create a PHP extension in C++ rather than C. Also attached is
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
modifications for using C++. I could've just made some changes to
skeleton.c and done some sed work in the ext_skel script, but I think it's
clearer to have them separated into two files.
The ext_skel patch is based on the current HEAD.
Comments?
J
skeleton.h also needs to be dealt with. If you do not, visual studio
will export symbols as c++ symbols and the extension will not work.
Simple solution is to have
#ifdef __cplusplus
extern C {
#endif
at the top of skeleton.h, and close it at the bottom.
Shane
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
On Fri, 29 Nov 2002, J Smith wrote: Attached is a patch to ext_skel that adds an optional argument (--cpp) that will create a PHP extension in C++ rather than C. Also attached is skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few modifications for using C++. I could've just made some changes to skeleton.c and done some sed work in the ext_skel script, but I think it's clearer to have them separated into two files. I'm reluctant to duplicate the contents of the .c file for maintenance reason. Cannot you just put the C++ specific code into a /* Remove this part, if this is not a C++ extension */ #ifdef __cplusplus #endif section? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
Is this a problem with VS.net or something? I've never done that with any of
my C++ extensions and they've all worked fine on VC++ 6.
If it is a problem, though, I'll make the changes.
J
Shane Caraveo wrote:
J Smith wrote:
Attached is a patch to ext_skel that adds an optional argument (--cpp)
that will create a PHP extension in C++ rather than C. Also attached is
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
modifications for using C++. I could've just made some changes to
skeleton.c and done some sed work in the ext_skel script, but I think
it's clearer to have them separated into two files.
The ext_skel patch is based on the current HEAD.
Comments?
J
skeleton.h also needs to be dealt with. If you do not, visual studio
will export symbols as c++ symbols and the extension will not work.
Simple solution is to have
#ifdef __cplusplus
extern C {
#endif
at the top of skeleton.h, and close it at the bottom.
Shane
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
How about adding something like this to skeleton.c: /* __begin_extern_c__ */ /* __end_extern_c__ */ And having the sed script in ext_skel replace them with the proper extern C stuff? That way there's no need for skeleton.cpp and just a few changes need to be made in skeleton.c. J Sascha Schumann wrote: On Fri, 29 Nov 2002, J Smith wrote: Attached is a patch to ext_skel that adds an optional argument (--cpp) that will create a PHP extension in C++ rather than C. Also attached is skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few modifications for using C++. I could've just made some changes to skeleton.c and done some sed work in the ext_skel script, but I think it's clearer to have them separated into two files. I'm reluctant to duplicate the contents of the .c file for maintenance reason. Cannot you just put the C++ specific code into a /* Remove this part, if this is not a C++ extension */ #ifdef __cplusplus #endif section? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: telecart
helping in translation the php menual to hebrew. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
