Re: [PHP-DEV] Interfaces in PHP
--- Brad LaFountain [EMAIL PROTECTED] wrote:
2) Interfaces as they exist in java don't really give you
much in a stripting
language but if you insist on having something like that
you can curently do it
with the zend1.
class temperature {
function __construct($value) {}
function toCelcius() {}
function toFarenheight() {}
}
just use that class and extend away
Brad ---
Not the same thing at all, as I'm sure you know. You
usually want interfaces in addition to whatever (single)
inheritance structure you already have.
-t
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces in PHP
2) Interfaces as they exist in java don't really give you much in a
stripting
language but if you insist on having something like that you can curently
do it
with the zend1.
class temperature {
function __construct($value) {}
function toCelcius() {}
function toFarenheight() {}
}
just use that class and extend away
- Brad
Brad,
You don't quite get the same functionality from extending a class as you
would from implementing an interface. If I'm extending temperature what
keeps me as a user from not overriding any of those functions? Or what if I
want to extend a different class but still define my class as having those
functions found in temperature? Having interfaces is a nice way to skirt
the issue of not having multiple inheritance built into the language.
Or as my example from before. We have more advanced constructs built into
our class library. An automatic database mirror search library, or maybe we
want to implement some sort of distributed class heirarchy across multiple
servers? It would definetly be more reliable to require certain functions
be defined for classes which implement a certain interface rather than
assume it is there.
And finally if we have a class heirarchy that is already defined and I am
creating a new class called UserMenu and extending the class Menu. What if
I want to make UserMenu searchable even though the class Menu is not? I
can't extend both SearchableObject and Menu. The only way that I can see
this working is if there was multiple inheratence or interfaces. You can
think of it as inserting an additional branch into the class tree heirarchy.
But all of this is doable without having interfaces, it's just that they are
one of the easier ways to solve these problems.
Ben
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Ways to Encourage PHPv5 usage
Due to the current discussion on php-dev relating to debug_backtrace() and the migration of new users to Zend2 and PHPv5, I've decided to come up with a list of more effective methods that we could impose to make sure that everyone upgrades to PHPv5. This list is a result of comprehensive surveys polling 99.6% of the userbase on PHP's 6 million+ domains (and over 1 million IP addresses). Here is my modest proposal... 1) Add a security bug to PHPv4, and only provide the fix with PHPv5. Nobody wants to have an insecure version of PHP on their servers so everybody will happily upgrade, hey, we might even be able to introduce case sensitivity at this point! 2) Make PHPv4 segfault on a random request, tell users this is a design flaw that has been fixed in PHPv5 (when really its just enabling the DOMXML and XSLT extension by default.) 3) If we don't really want to punish users, we can just pretend that we have a security bug, users are stupid, and don't bother reading the source code. They'd believe you if you told them there was a remote root exploit whenever PHP called the count () function. 4) Offer a DotCom sacrifice to the gods, I know some companies perfect for this task. 5) Remove features from PHPv4 and re-add them in PHPv5, its been shown that most PHP users would not use PHPv4 if it didn't have a count() function, therefore, of course, they'd upgrade to PHPv5. 6) Finally, perhaps the most effective method, we can only enable debug_backtrace() in PHPv5, which more than security bugs, random segfaults, improved speed and OO support, and naturally, DotCom sacrifices, will make PHP users upgrade to PHPv5. Now of course, we could just provide an easy and painless migration to PHPv5, like we did with PHPv4 (I was around then, and we did make it as painless as possible, without supporting two versions), backporting a few important features, security/bug fixes, but trying to focus development on PHPv5 (but not to exclude work that has already done on PHPv4), and respect evolution. But, that's not what 99.6% of users want Ah well! -Sterling Ps, some related notes: 1) This message is meant in good humor, don't take it to seriously. I don't think my INBOX can take another flamewar, I'm reading my mail via and unthreaded webmail client (I'm _really_ missing mutt's Thread-Delete feature). 2) I don't think its right to point to Zend as the source of Zeev and Andi's disagreements. They work for Zend, yes its true, anyone in doubt of that, raise your hand (whether Andi is just Zeev's alter-ego is still up to question however :). But I don't see the direct benefit of Zend 2 to Zend unless it means the continued success of PHP, which is really a shared benefit. Furthermore, just because they disagree with you, doesn't mean its to support Zend, the evil branch of Microsoft. They could just be wrong, or vice-versa. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces in PHP
At 09:30 21/08/2002, Ben Dischinger wrote: You don't quite get the same functionality from extending a class as you would from implementing an interface. If I'm extending temperature what keeps me as a user from not overriding any of those functions? Or what if I want to extend a different class but still define my class as having those functions found in temperature? Having interfaces is a nice way to skirt the issue of not having multiple inheritance built into the language. Interfaces, IMHO, simply do not fit the spirit of PHP. PHP is extremely loose about what it 'demands' from the programmer. You don't have types, you don't have to declare variables. But suddenly, we would have a construct that 'requires' you to implement certain functions? Ok fine, so you would have to implement a certain set of functions, but given the loose typing, what does that buy you anyway? You can't force him to return what you expect, or even deal with the arguments you send him according to their intended type. I don't see interfaces as something which makes too much sense in the context of PHP, and considering the added complexity of adding such a new feature, I'm against it. Typically, the argument is between single inheritance with interfaces, and multiple inheritance. We went for a multiple-inheritancish approach with delegation, and I don't think we should overcomplicate it with interfaces. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #19006 [Opn]: Test failure orange/banana
Patch below.
At 09:50 21-8-2002, you wrote:
Sorry for the screwed output,
the expected output, expects an int(0) (the result of array_sum). But
since array_sum no longer changes the actual array, the array remains
in tact as 'string[6] = banana'.
Index: ext/standard/tests/array/003.phpt
===
RCS file: /repository/php4/ext/standard/tests/array/003.phpt,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 003.phpt
--- ext/standard/tests/array/003.phpt 26 Mar 2002 18:18:18 - 1.1.2.1
+++ ext/standard/tests/array/003.phpt 21 Aug 2002 08:04:25 -
-35,9 +35,9
[-2147483648]=
array(2) {
[0]=
-int(0)
+string(6) banana
[1]=
-int(0)
+string(6) orange
}
[test]=
int(27)
-56,9 +56,9
[-2147483648]=
array(2) {
[0]=
-int(0)
+string(6) banana
[1]=
-int(0)
+string(6) orange
}
[-2147483648]=
float(-0.33)
-81,9 +81,9
[1]=
array(2) {
[0]=
-int(0)
+string(6) banana
[1]=
-int(0)
+string(6) orange
}
[2]=
int(27)
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
Hi all, Following on from the recent debug_backtrace discussion, and the discussion about just what we are releasing next and so on, I'd just thought I would make a couple of comments about PHP 4.3 and about what I think (IMHO) should be the goals of PHP 5. I'm currently reviewing the streams code, to make sure that the API is good enough for a release: there are a couple of things that I want to tidy up ready for PHP 4.3: o Add a set-blocking-flag method to the generic stream operations, So that non-blocking IO can be enabled on any stream that it makes sense to do so. (IIRC, there is a bug in the DB, or this deficiency was mentioned on the list). o Tidy up persistent streams support. (I need some help from someone that really knows what they are doing here). This is important, because I'm not sure that persistent sockets (pfsockopen) are actually working in HEAD ATM. o Implement a filter API, so that filters can be stacked over a stream. I've mentioned this before; it will be useful to stack things like base64, charset conversion, zlib/bzip compression and crypto over a stream - potentially multiple filters. I don't think that this will take too long to implement (perhaps by the weekend). o Implement stat() and readdir() for ftp. I think http will be too hard to achieve in time for 4.3. PHP 5 - Zeev raised the issue of figuring out what we want to be in PHP 5. Well, I can't think of (m)any fancy new features for PHP 5 that we haven't already got in HEAD, but to get the ball rolling, this is my take on how PHP 5 could/should look: Current HEAD, stabilized. This includes things like the new build system, streams, enhancements to post/file uploading, domxml and so on. ZE2, feature complete. (New OO, better rpc/com/java, try/catch, delegation, etc. etc.) To me, that sounds really pretty good. Yes, it's just HEAD with ZE2, but I think it's almost what will be PHP 5. A couple of additions that would make it more attractive: o PEAR/PECL CA fully established. I know that we are aiming to get this off the ground for PHP 4.3, but I'm sure we can improve it for PHP 5. o Bundle Brads php-soap extension, and market PHP 5 as being Web Service Enabled. o Finish off Harald's RPC extension, which should provide Seemless web services. Move Brad's extension into PEAR/PECL, for those people who need to use soap in a manly, yet sexy way. o We really need some people to look at PHP's XML support. Yeah, currently, it kinda-sorta works, however, we can really do it better. I suggest using the DOMXML extension as a base (so much work has been done already). Test strongly, Add full LibXML support, standardize the API to DOM's api, and bundle libxml libxslt with PHP version 5 (removing expat bundling). o See if we can get cURL bundled for PHPv5. o In that vein, get a proper standardized bundling scheme setup, that makes it easy to bundle/unbundle software with PHP. -Sterling Beyond that, I can't seem to think of anything else: I know that I would be very happy to start using all these new features in production ASAP, and I think that it will take 4.3 and 4.3.1 to stabilize these features and help us find/fix any problems before following up with PHP 5 in around 6 months time (perhaps slightly less?). With that in mind, once we have released PHP 4.3, it would make sense if we switched the CVS version to build with ZE2 by default, so that we can help test-in the new engine more thoroughly, and perhaps get it released that much sooner? --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Sybase / patches
Hi, in case you remember (if you don't, have a look at the thread [PHP-DEV] Sybase - Error handlers beginning Aug. 7 2002): I compiled my extension against PHP 4.2.2 / 4.2.1 / 4.1.2 recently, doing some improvements and having to change some code due to API incompatibilty (the original patch was against PHP 4.3.0 w/ ZE2). I got it tested on Debian (woody) and FreeBSD 4.3-STABLE without affections on existing source, segfaults or memory leaks, so I guess this thing ought to be OK. I even had time to write up some english documentation: http://sitten-polizei.de/php/README.SYBASE.EN Current sources: http://sitten-polizei.de/php/php_sybase_ct.c http://sitten-polizei.de/php/php_sybase_ct.h After compiling, you should see: Deadlock retry count: Unlimited and sybct.deadlock_retry_count, -1 in the sybase_ct section of phpinfo(). Disclaimer: --- The sybase_unbuffered_query() is experimental and misusage (using it with inserts, closing the connection while reading or trying to fire up another query directly after etc.) may result in unexpected results. Maybe some more intense checks should be done. That's why it's experimental. Feedback welcome:-) -- Timm -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] friendly classes
Hi, I'm currenly looking at/doing a lot of object orientated PHP so I have been looking into what new features Zend 2 will offer me. I have just run into a situation where if I was using Zend 2 I would need some sort of implementation of C++ friends, I'm not to sure about the java alternative (is it package access?). Anyway is this consept likely to appear in PHP at any time? Cheers Tom -- *** Tom Oram SCL Computer Services URL http://www.scl.co.uk/ *** -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces in PHP
Did you guys re-read the discussion in the ZE2 archives as I suggested?
In brief:
class IFoo {
function foo() {}
}
class IBar {
function bar() {}
}
class C {
delegatee $foo = new IFoo(); // implements IFoo by delegation
delegatee $bar = new IBar(); // implements IBar by delegation
}
$c = new C();
if (has_a($c, IFoo))
$c-foo();
if (has_a($c, IBar))
$c-bar();
This has_a function/operator is one of the small things missing
from the current delegation RFC, along with an as operator.
For full details on this stuff, take a look at those archives - theres
no need to keep going round in circles :-)
--Wez.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces in PHP
Wez Furlong wrote:
class C {
delegatee $foo = new IFoo(); // implements IFoo by delegation
delegatee $bar = new IBar(); // implements IBar by delegation
}
I didnt see anyone suggest this as an alternative to the delegatee
syntax, - it just a bit clearer to read (to me anyway..)
class C extends something {
extends IFoo as $foo;
extends IBar as $bar;
var
function
}
just a thought..
regards
alan
$c = new C();
if (has_a($c, IFoo))
$c-foo();
if (has_a($c, IBar))
$c-bar();
This has_a function/operator is one of the small things missing
from the current delegation RFC, along with an as operator.
For full details on this stuff, take a look at those archives - theres
no need to keep going round in circles :-)
--Wez.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP extension initialisation
I had already assumed what Pete said was happening was happening, but I still
don't know how to tell whether I'm in the first one (apache test) or the second
(real init). Any ideas?
Tom
On Wed, 21 Aug 2002, you wrote:
Hi,
I asked about this a few weeks ago with apache on windows.
The best answer I got was from George Schlossnagle:
quoteI believe this is because when apache does it's intial configtest run
as
part of start (to validate it's config), it has to do a complete startup
(otherwise it wouldn't know about conf params used by modules loaded as
DSOs. So you see a startup; shutdown; startup./quote
that's exactly what I saw happen so seeing as shutdown occurs as well it
wasn't a problem in my case.
Pete
--
Tom Oram [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Thu, 15 Aug 2002, you wrote:
--- Tom Oram [EMAIL PROTECTED] wrote:
Hi,
Can someone please answer my question?
When running a PHP extension when PHP is running as an apache module on
linux
it's module init function (PHP_MINIT_FUNCTION) gets called twice, once
before
apache forks then once after, is there any way of finding out which
init you are in. I can't keep a global variable because it get losted in
between init calls, and environment vars/file locks/shared mem/semephores
are
not options.
Are you on Windows IIS? I believe someone recently just asked about that
same
thing. There was a valid explination for it.
No linux, I did say ;), but thanks anyway.
The question still stands open, anyone?
One other quicky, is there a way to find out inside the extension if it
is
being run from with an apache module or its it a standalone executable
(or
running under a different webserver as my module can only ever run with
apache)?
I believe you could
#include SAPI.h
if(!strcmp(sapi_module.name, cgi) || strcmp(sapi_module.name, cli)) {
printf(compiled as a command line executable);
}
This is probably what I need thanks
Thanks for your time,
Tom
--
***
Tom Oram
SCL Computer Services
URL http://www.scl.co.uk/
***
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
***
Tom Oram
SCL Computer Services
URL http://www.scl.co.uk/
***
--
***
Tom Oram
SCL Computer Services
URL http://www.scl.co.uk/
***
--
***
Tom Oram
SCL Computer Services
URL http://www.scl.co.uk/
***
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces in PHP
--- Tim Converse [EMAIL PROTECTED] wrote:
--- Brad LaFountain [EMAIL PROTECTED] wrote:
2) Interfaces as they exist in java don't really give you
much in a stripting
language but if you insist on having something like that
you can curently do it
with the zend1.
class temperature {
function __construct($value) {}
function toCelcius() {}
function toFarenheight() {}
}
just use that class and extend away
Brad ---
Not the same thing at all, as I'm sure you know. You
usually want interfaces in addition to whatever (single)
inheritance structure you already have.
Well the zend1 example I gave was a workaround. But that is why I said if the
deligation gets worked out in zend2 then you could acually do similar stuff.
BTW I do use some stuff like this in some of my classes. I'll create a function
with no implementation and any extending class can override that method and use
its functionality (usally for event like stuff), so I don't have to call
method_exists() before trying to call the method.
- Brad
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
Adding to the ever expanding list... On Wed, 21 Aug 2002, Sterling Hughes wrote: Hi all, Following on from the recent debug_backtrace discussion, and the discussion about just what we are releasing next and so on, I'd just thought I would make a couple of comments about PHP 4.3 and about what I think (IMHO) should be the goals of PHP 5. I'm currently reviewing the streams code, to make sure that the API is good enough for a release: there are a couple of things that I want to tidy up ready for PHP 4.3: o Add a set-blocking-flag method to the generic stream operations, So that non-blocking IO can be enabled on any stream that it makes sense to do so. (IIRC, there is a bug in the DB, or this deficiency was mentioned on the list). o Tidy up persistent streams support. (I need some help from someone that really knows what they are doing here). This is important, because I'm not sure that persistent sockets (pfsockopen) are actually working in HEAD ATM. o Implement a filter API, so that filters can be stacked over a stream. I've mentioned this before; it will be useful to stack things like base64, charset conversion, zlib/bzip compression and crypto over a stream - potentially multiple filters. I don't think that this will take too long to implement (perhaps by the weekend). o Implement stat() and readdir() for ftp. I think http will be too hard to achieve in time for 4.3. PHP 5 - Zeev raised the issue of figuring out what we want to be in PHP 5. Well, I can't think of (m)any fancy new features for PHP 5 that we haven't already got in HEAD, but to get the ball rolling, this is my take on how PHP 5 could/should look: Current HEAD, stabilized. This includes things like the new build system, streams, enhancements to post/file uploading, domxml and so on. ZE2, feature complete. (New OO, better rpc/com/java, try/catch, delegation, etc. etc.) To me, that sounds really pretty good. Yes, it's just HEAD with ZE2, but I think it's almost what will be PHP 5. A couple of additions that would make it more attractive: o PEAR/PECL CA fully established. I know that we are aiming to get this off the ground for PHP 4.3, but I'm sure we can improve it for PHP 5. o Bundle Brads php-soap extension, and market PHP 5 as being Web Service Enabled. o Finish off Harald's RPC extension, which should provide Seemless web services. Move Brad's extension into PEAR/PECL, for those people who need to use soap in a manly, yet sexy way. o We really need some people to look at PHP's XML support. Yeah, currently, it kinda-sorta works, however, we can really do it better. I suggest using the DOMXML extension as a base (so much work has been done already). Test strongly, Add full LibXML support, standardize the API to DOM's api, and bundle libxml libxslt with PHP version 5 (removing expat bundling). o See if we can get cURL bundled for PHPv5. o In that vein, get a proper standardized bundling scheme setup, that makes it easy to bundle/unbundle software with PHP. o Update ODBC to v 3.7 support. The current v2 support just doesn't cut it anymore with users wanting to use IMAGE, TEXT, NTEXT, and other various large data field types, and unicode. I started this, but my resource books were ummm... acquired by another and never returned. o Decide if we are or are not going to support the iPlanet system. If we are, it needs to be drastically fixed, if we're not we need to drop it. Really. Look at the bug reports. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Rasmus Lerdorf wrote: On Mon, 19 Aug 2002, Rasmus Lerdorf wrote: But could you at least answer the question? What is the advantage of allowing user-supplied new session ids? I see no reason not to add a check for this. For example, I have a set of C programs for IRCG load testing. It uses a simple FSM to generate HTTP requests and waste incoming data (like 50K concurrent connections). If this client could not use arbitrary session ids (mysid$running_number), I'd have to actually analyze HTTP replies and the icky Cookie header. Hrm.. Ok, that's what I was looking for. A realworld reason to allow the client to specify the new sids. There are a lot of cases when that can be useful, but that should be controllable behaviour in limited places, not a general one. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Dan Hardiker wrote: Well, more worrisome would be if a bad guy tricks you into clicking on a link or simply sends you an image in an email that makes a request to my server with a valid-looking session id. Then if you go to this site (that I've debunked that scenario already a few times. The net result is that this class of attacks is impossible to prevent. The assumption in your scenario and the following is this: The attacker has access to a script X which calls session_start(). My scenario: 1.) Attacker A accesses X and stores the SID which PHP assigns to him. 2.) A crafts a link containing SID and sends it to victim V. 3.) A keeps SID alive by repeatedly accessing X using SID. 4.) V opens link and authenticates. 5.) A's script notices (4). A can overtake V's session. Ive extended the session handling so that upon session start, it takes a snapshot of the browser string (and maybe a couple of other javascript-retrieved variables about the user's os, eg: the resolution) and build up as much of a picture of the client as possible. So you should pick upt that 'initial propagation mode', so later someone can decide to block a client shift in that while pretending to remain the same client. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3 and PHP 5
And a couple more things. Adding to the ever expanding list... On Wed, 21 Aug 2002, Sterling Hughes wrote: Hi all, Following on from the recent debug_backtrace discussion, and the discussion about just what we are releasing next and so on, I'd just thought I would make a couple of comments about PHP 4.3 and about what I think (IMHO) should be the goals of PHP 5. I'm currently reviewing the streams code, to make sure that the API is good enough for a release: there are a couple of things that I want to tidy up ready for PHP 4.3: o Add a set-blocking-flag method to the generic stream operations, So that non-blocking IO can be enabled on any stream that it makes sense to do so. (IIRC, there is a bug in the DB, or this deficiency was mentioned on the list). o Tidy up persistent streams support. (I need some help from someone that really knows what they are doing here). This is important, because I'm not sure that persistent sockets (pfsockopen) are actually working in HEAD ATM. o Implement a filter API, so that filters can be stacked over a stream. I've mentioned this before; it will be useful to stack things like base64, charset conversion, zlib/bzip compression and crypto over a stream - potentially multiple filters. I don't think that this will take too long to implement (perhaps by the weekend). o Implement stat() and readdir() for ftp. I think http will be too hard to achieve in time for 4.3. PHP 5 - Zeev raised the issue of figuring out what we want to be in PHP 5. Well, I can't think of (m)any fancy new features for PHP 5 that we haven't already got in HEAD, but to get the ball rolling, this is my take on how PHP 5 could/should look: Current HEAD, stabilized. This includes things like the new build system, streams, enhancements to post/file uploading, domxml and so on. ZE2, feature complete. (New OO, better rpc/com/java, try/catch, delegation, etc. etc.) To me, that sounds really pretty good. Yes, it's just HEAD with ZE2, but I think it's almost what will be PHP 5. A couple of additions that would make it more attractive: o PEAR/PECL CA fully established. I know that we are aiming to get this off the ground for PHP 4.3, but I'm sure we can improve it for PHP 5. o Bundle Brads php-soap extension, and market PHP 5 as being Web Service Enabled. o Finish off Harald's RPC extension, which should provide Seemless web services. Move Brad's extension into PEAR/PECL, for those people who need to use soap in a manly, yet sexy way. o We really need some people to look at PHP's XML support. Yeah, currently, it kinda-sorta works, however, we can really do it better. I suggest using the DOMXML extension as a base (so much work has been done already). Test strongly, Add full LibXML support, standardize the API to DOM's api, and bundle libxml libxslt with PHP version 5 (removing expat bundling). o See if we can get cURL bundled for PHPv5. o In that vein, get a proper standardized bundling scheme setup, that makes it easy to bundle/unbundle software with PHP. o Update ODBC to v 3.7 support. The current v2 support just doesn't cut it anymore with users wanting to use IMAGE, TEXT, NTEXT, and other various large data field types, and unicode. I started this, but my resource books were ummm... acquired by another and never returned. o Decide if we are or are not going to support the iPlanet system. If we are, it needs to be drastically fixed, if we're not we need to drop it. Really. Look at the bug reports. o Rewrite the ISAPI IIS interface. Gasp. From the ground up, or find some other way to fix bug #15333. The work arounds listed in the bug report are not acceptable in production systems, just as temporary stop-gap methods for developing new applications until a true fix is found. o Fix register_shutdown_function to work as it did with 4.1, or add a seperate function to add this functionality. And then get it to work on windows. See bug #15209. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Zeev IS Andi? :) (was: Re: [PHP-DEV] PATCH: debug_backtrace() functionfor 4.3-dev/ZE1)
On Tue, 20 Aug 2002, Zeev Suraski wrote: At 16:02 20/08/2002, Jani Taskinen wrote: On Tue, 20 Aug 2002, Andi Gutmans wrote: I still think it shouldn't go in. This is the only feature in Engine 2 which might make non-OOP people convert. Once this isn't in Engine 2 we don't have a carrot for them. I guess you want PHP 5 only to have ZE2 as the only major change? Hmm, where the hell did you dig that from? What I *did* say is that if Hehee...should this be considered as proof that Andi IS your alter-ego? :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tests tweaks
At 03:36 21-8-2002, Marcus Börger wrote: I made the functions a bit more C99 complient (maybe we should use some C99 complience suit...) but unfortuanetley that was not all. 1) someone must have changed ini setting precision from 14 to 12 Adding special INI section to array tests fixed test 1 2. 2) test 003 Test usort, uksort and uasort All this functions fail on the subarray That test is now fixed. There's indeed a printf bug, for AIX: float(-.33) on 003.phpt. Funny thing is, that AIX has snprintf, and it's used. The manpage is here - if you want to see whether that complies to your requirements: http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf2/snprintf.htm But it may be related to a bigger problem, as there are also pure negative array indexes: [-2147483648]= string(6) monkey Must be a type problem. Relating to that, there is a overall mixup for AIX, with headers, resulting in various implicit declaration of standard functions like strcasecmp. This is because AIX has string.h as well as strings.h and has divided the function definitions amongst those two. Additionally time_t != long. I'll see tomorrow, what I can gather and report and/or provide patches. Some examples: /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c: In function `php_mysql_do_connect': /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c:675: warning: implicit declaration of function `strcasecmp' /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c: In function `zif_mysql_info': /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c:987: warning: `id' might be used uninitialized in this function /home/mdev/_src/php-HEAD/ext/session/session.c: In function `php_session_create_id': /home/mdev/_src/php-HEAD/ext/session/session.c:486: warning: long int format, time_t arg (arg 3) /home/mdev/_src/php-HEAD/ext/session/session.c:486: warning: long int format, suseconds_t arg (arg 4) /home/mdev/_src/php-HEAD/ext/session/session.c: In function `php_session_cache_limiter': Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] new webdav patch
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. 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. 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 thanks dave -Original Message- From: Christian Stocker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 1:46 PM To: Rasmus Lerdorf Cc: [EMAIL PROTECTED] Subject: 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Apache 1.2.26 + PHP 4.2.2 segfaults
HI,
I'm having a little bit of a problem getting apache 1.2.26 to work with
php 4.2.2, using gcc 3.1.1, and with pgsql 7.2.1
i compiled apache with these options... (from .spec file)
snip
CFLAGS=$RPM_OPT_FLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
./configure \
--prefix=%{_prefix} \
--exec-prefix=%{_prefix} \
--bindir=%{_bindir} \
--sbindir=%{_sbindir} \
--mandir=%{_mandir} \
--sysconfdir=%{_sysconfdir}/httpd/conf \
--includedir=%{_includedir}/apache \
--libexecdir=%{_libdir}/apache \
--datadir=%{contentdir} \
--iconsdir=%{contentdir}/icons \
--htdocsdir=%{contentdir}/html \
--manualdir=%{contentdir}/html \
--cgidir=%{contentdir}/cgi-bin \
--localstatedir=%{_localstatedir} \
--runtimedir=%{_localstatedir}/run \
--logfiledir=%{_localstatedir}/log/httpd \
--proxycachedir=%{_localstatedir}/cache/httpd \
--add-module=%{SOURCE12} \
--add-module=mod_put-%{mod_put_ver}/mod_put.c \
--add-module=%{SOURCE15} \
--add-module=mod_frontpage.c \
--add-module=mod_throttle-%{mod_throttle_ver}/mod_throttle.c \
--add-module=%{SOURCE18} \
--add-module=mod_auth_pgsql-%{mod_auth_pgsql_ver}/mod_auth_pgsql.c \
--enable-module=all \
--enable-shared=max \
--enable-rule=EAPI \
--disable-rule=WANTHSREGEX \
--enable-module=auth_dbm \
--with-perl=%{__perl} \
--enable-suexec \
--suexec-docroot=%{contentdir} \
--suexec-caller=apache
/snip
and php with these...
snip
ssllibs=-lssl -lcrypto
CFLAGS=$RPM_OPT_FLAGS; export CFLAGS
LIBS=-lttf -lpng -ljpeg -lz; export LIBS
compile() {
./configure \
--prefix=%{_prefix} \
--with-config-file-path=%{_sysconfdir} \
--disable-debug \
--enable-shared \
--enable-pic \
$* \
--with-db3 \
--with-exec-dir=%{_bindir} \
--with-gd \
--with-gdbm \
--with-imap-ssl \
--with-jpeg-dir=%{_prefix} \
--with-ldap \
--with-pic \
--with-pgsql=/usr \
--with-png \
--with-regex=system \
--with-xml \
--with-zlib \
--enable-debugger \
--enable-magic-quotes \
--enable-inline-optimization \
--enable-safe-mode \
--enable-shmop \
--enable-sysvsem \
--enable-sysvshm \
--enable-sockets \
--enable-track-vars \
--enable-yp \
--enable-ftp \
--enable-wddx \
--without-mysql \
--without-oracle \
--without-oci8 \
--with-mm \
--with-pic
%{make}
}
# Build a standalone binary.
make distclean || :
compile --enable-force-cgi-redirect
cp php php_standalone
# Build a module.
make distclean
compile --with-apxs=%{_sbindir}/apxs
# Build individual PHP modules.
build_ext() {
%{__cc} -fPIC -shared $RPM_OPT_FLAGS \
-DCOMPILE_DL_`echo $1 | tr '[a-z]' '[A-Z]'` \
-DHAVE_`echo $1 | tr '[a-z]' '[A-Z]'` \
-I. -I./TSRM -I./main -I`%{_sbindir}/apxs -q INCLUDEDIR` -I./Zend \
-I/usr/include/freetype -I/usr/include/$1 \
-I./ext/$1 -I./ext/$1/lib$1 \
-I./ext/xml/expat/xmltok -I./ext/xml/expat/xmlparse \
`grep ^CPPFLAGS Zend/Makefile | cut -f2- -d=` \
$4 $2 -o $1.so -L.libs $3 -lc
}
build_ext imap ext/imap/php_imap.c %{_libdir}/c-client.a $ssllibs -lpam -ldl
build_ext ldap ext/ldap/ldap.c -lldap -llber
build_ext pgsql ext/pgsql/pgsql.c -lpq -DHAVE_PQCMDTUPLES
/snip
some code above originally derived from one of the old redhat .spec files
and others.
now what happens is while running a php site (with heavy pgsql integration)
i get segfaults in apache, here is the strace...
snip
strlen(X-Powered-By)= 12
memcpy(0x081e310c, X-Powered-By, 13)= 0x081e310c
strlen(PHP/4.2.2) = 9
memcpy(0x081e311c, PHP/4.2.2, 10) = 0x081e311c
strcasecmp(X-Powered-By, Expires) = 19
strlen(Expires) = 7
memcpy(0x081e312c, Expires, 8) = 0x081e312c
strlen(Thu, 19 Nov 1981 08:52:00 GMT) = 29
memcpy(0x081e3134, Thu, 19 Nov 1981 08:52:00 GMT, 30) = 0x081e3134
strcasecmp(X-Powered-By, Cache-Control) = 21
strcasecmp(Expires, Cache-Control)= 2
strlen(Cache-Control) = 13
memcpy(0x081e3154, Cache-Control, 14) = 0x081e3154
strlen(no-store, no-cache, must-revalid...) = 62
memcpy(0x081e3164, no-store, no-cache, must-revalid..., 63) = 0x081e3164
strcasecmp(X-Powered-By, Pragma) = 8
strcasecmp(Expires, Pragma) = -11
strcasecmp(Cache-Control, Pragma) = -13
strlen(Pragma) = 6
memcpy(0x081e31a4, Pragma, 7) = 0x081e31a4
strlen(no-cache)= 8
Re: [PHP-DEV] friendly classes
At 10:59 AM 8/21/2002 +0100, Tom Oram wrote: Hi, I'm currenly looking at/doing a lot of object orientated PHP so I have been looking into what new features Zend 2 will offer me. I have just run into a situation where if I was using Zend 2 I would need some sort of implementation of C++ friends, I'm not to sure about the java alternative (is it package access?). Anyway is this consept likely to appear in PHP at any time? I wouldn't want to get into what I consider the ugly sides of C++'s OOP. If you need friend then just go ahead and make it public :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3 and PHP 5
At 17:55 21/08/2002, Joseph Tate wrote: o Rewrite the ISAPI IIS interface. Gasp. From the ground up, or find some other way to fix bug #15333. The work arounds listed in the bug report are not acceptable in production systems, just as temporary stop-gap methods for developing new applications until a true fix is found. Well, here's one easy to remove :) There's nothing wrong with the ISAPI interface. Nothing that warrants rewriting it, anyway. The bug in question is most probably not related to ISAPI at all; Any corruption or thread safety bug in any part of PHP can cause it. My bet is a thread safety issue in one of the database modules, or based on the report and some personal experience, the session module under Windows. Also note that I fixed a few serious threading issues last week, so multithreaded stability should be better, even though I don't think the bugs I fixed could lead to hard crashes as described in the bug report. o Fix register_shutdown_function to work as it did with 4.1, or add a seperate function to add this functionality. And then get it to work on windows. See bug #15209. I don't think that this kind of features should be in the roadmap for 5. I don't have anything against them, and I won't mind finding them in 5, but it's really not a pre-requisite. I think that at this point we should switch from wish-list mode, to a down-to-earth realistic mode. That is, not put everything that we want to see in the roadmap, but only things which are either pre-requisites or things we know with a great deal of certainty. I did take a look at the bug report and noticed I even analyzed it once... Basically, we can implement a new set of functions in the Apache module. We can definitely not switch back to the old behavior because it would lead to a serious inconsistency across servers. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
On Wed, 21 Aug 2002, Shane Caraveo wrote: It should simply be marked EXPERIMENTAL, but not removed. On the other hand, it doesn't have to be included in the distribution if it simply does not work correctly. It's apparently been broken since 4.0.5. I did a little bit of patching it up so that it actually compiles and put these fixes into PHP_4_2_0 and HEAD, but nothing is ensuring that it works with completely. --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
On Wed, 21 Aug 2002 15:46:50 -0400 (EDT) Dan Kalowsky [EMAIL PROTECTED] wrote: On Wed, 21 Aug 2002, Shane Caraveo wrote: It should simply be marked EXPERIMENTAL, but not removed. On the other hand, it doesn't have to be included in the distribution if it simply does not work correctly. It's apparently been broken since 4.0.5. I did a little bit of patching it up so that it actually compiles and put these fixes into PHP_4_2_0 and HEAD, but nothing is ensuring that it works with completely. Works well in 4.1.1 : on : SunOS argiope 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-250 './configure' '--enable-track-var' '--enable-libgcc' '--prefix=/source/php3-web60/php-4.1.1' '--with-mysql=/ext1/mysql2-web60/mysql-3.23.47' '--with-nsapi=/source/iplanet2/server4' '--with-gnu-ld' '--with-mnogosearch=/heberge/iplanet/webserver/web60/bin/mnogosearch' Please, do not think about drop the nsapi support, never :) pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3 and PHP 5
I am willing to accept this. I don't think it's the job of the PHP group to fix thread-safetyness for all libraries on all platforms. That's a herculean task. Plus, I'm sure we're not alone in problem. Surely the mod_perl folks and [insert your favorite popular Apache module here] have similar issues. If we could say that PHP works on a certain subset of systems (my proposal is that we limit ourselves to the current release versions of popular OSes) with a certain set of extensions (again, I propose everything that is enabled by default, if possible. I'm not sure how large that set of extensions is) then that would be good. If that seems as if it would involve too many hours of QA (which it certainly could), I think the list you're currently making listing what does and doesn't work w/r/t threading is an acceptible substitute. That way, even if we can't fix it, we can at least tell you that your library is broken and switching to [insert thread-safe substitute] will solve the problem. If people choose not to switch, that's their problem, but we've at least given them the information to make a decision before they tear their hair out wondering why PHP keeps crashing. -adam On Wed, 21 Aug 2002, Rasmus Lerdorf wrote: But how do you propose we come up with perfect Apache 2.0 support? If we limit it to the pre-fork mpm, we can probably get quite close to perfect stability, but for any of the threaded mpms we are completely at the mercy of the threadsafetyness of all the various third party libraries on all the various platforms that PHP runs on. There is simply no way to ensure that PHP against Apache 2.0 with a threaded mpm will be production quality. The best we can do is pick a small set of extensions and a small set of platforms and say that with the limited set of extensions, against a specific set of versions of addon libraries on a specific version of that OS, yes, it should be production quality - maybe. -Rasmus On Wed, 21 Aug 2002, Adam Maccabee Trachtenberg wrote: On Wed, 21 Aug 2002, Zeev Suraski wrote: I think that at this point we should switch from wish-list mode, to a down-to-earth realistic mode. That is, not put everything that we want to see in the roadmap, but only things which are either pre-requisites or things we know with a great deal of certainty. I don't know what the timing of PHP 5 will be vis-a-vis Apache 2.0 stabilization, but it'd be real nice if we could have a production quality Apache 2.0 module. I know there's been a lot of work on the module and I rememeber reading that what it mostly needs now is burn-in and testing. (Maybe there is some additional functionality or optimizations we also wish to enable?) So, it could be that everything is perfect by 4.3, but I think it would be good, if we could tell everyone that 5.0 works with Apache 2.0. That could be a nice sized carrot, for those looking for vegetables to support a vegan lifestyle. :) -adam -- adam maccabee trachtenberg [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- adam maccabee trachtenberg [EMAIL PROTECTED] -- 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
Re: [PHP-DEV] PHP 4.3 and PHP 5
Rasmus Lerdorf wrote: But how do you propose we come up with perfect Apache 2.0 support? FastCGI :) If we limit it to the pre-fork mpm, we can probably get quite close to perfect stability, but for any of the threaded mpms we are completely at the mercy of the threadsafetyness of all the various third party libraries on all the various platforms that PHP runs on. There is simply no way to ensure that PHP against Apache 2.0 with a threaded mpm will be production quality. The best we can do is pick a small set of extensions and a small set of platforms and say that with the limited set of extensions, against a specific set of versions of addon libraries on a specific version of that OS, yes, it should be production quality - maybe. -Rasmus Sounds like windows now ;) Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
On Wed, 21 Aug 2002, Pierre-Alain Joye wrote: Works well in 4.1.1 : on : SunOS argiope 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-250 You are the first to report back that I've seen/heard from stating it works. You're even on one of the two major difficulty platforms. Now try using 4.2 ;) --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
On Wed, 21 Aug 2002 16:37:13 -0400 (EDT) Dan Kalowsky [EMAIL PROTECTED] wrote: On Wed, 21 Aug 2002, Pierre-Alain Joye wrote: Works well in 4.1.1 : on : SunOS argiope 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-250 You are the first to report back that I've seen/heard from stating it works. You're even on one of the two major difficulty platforms. Now try using 4.2 ;) 4.1.2 works too, but the apps are in this 2nd servers I used are far less complex, so I will not be affirmative. For the 4.2.x, well, forget it for the next 8-9 months :) on this server. But new servers will come, and have to test which version we ll use. But I prefer to keep a wining team ;). ht pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces in PHP
Thanks for all of your guys' comments on this. Ultimately I see Zeev's insight of PHP not having a strong type definition totally accurate. Even if we did have a mechanism to make sure that a class defined certain functions, we could not readily see if these functions did what we wanted, bringing us to the same problem. The delegation construct looks promising for having a means of multiple inheretence. Ben Zeev Suraski wrote: At 09:30 21/08/2002, Ben Dischinger wrote: You don't quite get the same functionality from extending a class as you would from implementing an interface. If I'm extending temperature what keeps me as a user from not overriding any of those functions? Or what if I want to extend a different class but still define my class as having those functions found in temperature? Having interfaces is a nice way to skirt the issue of not having multiple inheritance built into the language. Interfaces, IMHO, simply do not fit the spirit of PHP. PHP is extremely loose about what it 'demands' from the programmer. You don't have types, you don't have to declare variables. But suddenly, we would have a construct that 'requires' you to implement certain functions? Ok fine, so you would have to implement a certain set of functions, but given the loose typing, what does that buy you anyway? You can't force him to return what you expect, or even deal with the arguments you send him according to their intended type. I don't see interfaces as something which makes too much sense in the context of PHP, and considering the added complexity of adding such a new feature, I'm against it. Typically, the argument is between single inheritance with interfaces, and multiple inheritance. We went for a multiple-inheritancish approach with delegation, and I don't think we should overcomplicate it with interfaces. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tests tweaks
At 17:58 21.08.2002, Melvyn Sopacua wrote: At 03:36 21-8-2002, Marcus Börger wrote: I made the functions a bit more C99 complient (maybe we should use some C99 complience suit...) but unfortuanetley that was not all. 1) someone must have changed ini setting precision from 14 to 12 Adding special INI section to array tests fixed test 1 2. 2) test 003 Test usort, uksort and uasort All this functions fail on the subarray That test is now fixed. There's indeed a printf bug, for AIX: float(-.33) on 003.phpt. That it is there does not mean it is C99 complient. We only use our own snprintf it is missing. Funny thing is, that AIX has snprintf, and it's used. The manpage is here - if you want to see whether that complies to your requirements: http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf2/snprintf.htm There is nothing said about to what it conforms and that there is at least one digit infront of the decimal point is not mentioned either so i guess the function was created before C99. Again it might be a good thing to check for C99 complience of snprintf and use our own function if not. But it may be related to a bigger problem, as there are also pure negative array indexes: [-2147483648]= string(6) monkey Must be a type problem. Relating to that, there is a overall mixup for AIX, with headers, resulting in various implicit declaration of standard functions like strcasecmp. This is because AIX has string.h as well as strings.h and has divided the function definitions amongst those two. Additionally time_t != long. I'll see tomorrow, what I can gather and report and/or provide patches. Some examples: /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c: In function `php_mysql_do_connect': /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c:675: warning: implicit declaration of function `strcasecmp' /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c: In function `zif_mysql_info': /home/mdev/_src/php-HEAD/ext/mysql/php_mysql.c:987: warning: `id' might be used uninitialized in this function /home/mdev/_src/php-HEAD/ext/session/session.c: In function `php_session_create_id': /home/mdev/_src/php-HEAD/ext/session/session.c:486: warning: long int format, time_t arg (arg 3) /home/mdev/_src/php-HEAD/ext/session/session.c:486: warning: long int format, suseconds_t arg (arg 4) /home/mdev/_src/php-HEAD/ext/session/session.c: In function `php_session_cache_limiter': Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] libgd patch for alpha-channel mixing
This is a patch to add nicer alpha-channel mixing to the GD module.
It introduces two new PHP functions:
ImageLayerEffect() ImageColorMatch()
ImageLayerEffect() is similar to the existing ImageAlphaBlending() function in
that it affects the way pixel drawing will be done during any kind of drawing
function. It extends the functionality by allowing you to use new effect
modes. There are four modes: replace, alpha, normal and overlay. Replace and
alpha are like ImageAlphaBlending(FALSE) and ImageAlphaBlending(TRUE)
respectively. Normal mode is like alpha but works on transparent and
semi-transparent backgrounds. Overlay is like the overlay layer effect in
graphics programs.
The ImagePSText() function can now draw on arbitrary backgrounds using the
normal layer effect (my technique is to use a text background colour that has
the same RGB as the text foreground but a transparent alpha.)
ImageColorMatch() is a function I've been using to tweak the
ImageTrueColorToPalette() results. I find that the generated palette gets
close, but doesn't quite match sometimes. This function fixes that problem
(at least it works for me).
Any thoughts? Should I go ahead and commit this? I've never committed to PHP
before so go easy on me :-). I've been using essentially the same code on a
PHP-4.1.0 installation for a while now and I believe it works OK.
Tim
diff -aur php4/ext/gd/gd.c php4-tt/ext/gd/gd.c
--- php4/ext/gd/gd.c Sun Jul 28 20:00:37 2002
+++ php4-tt/ext/gd/gd.c Wed Aug 21 18:24:12 2002
-260,6 +260,10
#ifdef HAVE_GD_WBMP
PHP_FE(image2wbmp,NULL)
#endif
+#ifdef HAVE_GD_BUNDLED
+ PHP_FE(imagelayereffect, NULL)
+ PHP_FE(imagecolormatch, NULL)
+#endif
{NULL, NULL, NULL}
};
/* }}} */
-337,6 +341,12
REGISTER_LONG_CONSTANT(IMG_ARC_NOFILL, gdNoFill, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(IMG_ARC_EDGED, gdEdged, CONST_CS | CONST_PERSISTENT);
#endif
+#ifdef HAVE_GD_BUNDLED
+ REGISTER_LONG_CONSTANT(IMG_EFFECT_REPLACE, gdEffectReplace, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(IMG_EFFECT_ALPHABLEND, gdEffectAlphaBlend, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(IMG_EFFECT_NORMAL, gdEffectNormal, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(IMG_EFFECT_OVERLAY, gdEffectOverlay, CONST_CS | CONST_PERSISTENT);
+#endif
return SUCCESS;
}
/* }}} */
-639,6 +649,46
}
/* }}} */
+/* {{{ proto void imagecolormatch(resource im1, resource im2)
+ Makes the colors of the palette version of an image more closely match the true color version */
+PHP_FUNCTION(imagecolormatch)
+{
+#if HAVE_GD_BUNDLED
+ zval **IM1, **IM2;
+ gdImagePtr im1, im2;
+ int result;
+
+ if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, IM1, IM2 ) == FAILURE) {
+ ZEND_WRONG_PARAM_COUNT();
+ }
+
+ ZEND_FETCH_RESOURCE(im1, gdImagePtr, IM1, -1, Image, le_gd);
+ ZEND_FETCH_RESOURCE(im2, gdImagePtr, IM2, -1, Image, le_gd);
+
+ result = gdImageColorMatch(im1, im2);
+ switch( result )
+ {
+ case -1:
+ zend_error(E_ERROR, %s(): Image1 must be TrueColor, get_active_function_name(TSRMLS_C));
+ RETURN_FALSE;
+ break;
+ case -2:
+ zend_error(E_ERROR, %s(): Image2 must be Palette, get_active_function_name(TSRMLS_C));
+ RETURN_FALSE;
+ break;
+ case -3:
+ zend_error(E_ERROR, %s(): Image1 and Image2 must be the same size, get_active_function_name(TSRMLS_C));
+ RETURN_FALSE;
+ break;
+ }
+
+ RETURN_TRUE;
+#else
+ zend_error(E_ERROR, %s(): requires GD 2.0 or later, get_active_function_name(TSRMLS_C));
+#endif
+}
+/* }}} */
+
/* {{{ proto void imagesetthickness(resource im, int thickness)
Set line thickness for drawing lines, ellipses, rectangles, polygons etc. */
PHP_FUNCTION(imagesetthickness)
-738,6 +788,30
}
/* }}} */
+/* {{{ proto void imagelayereffect(resource im, bool on)
+ Set the alpha blending flag to use the PHP libgd layering effects */
+PHP_FUNCTION(imagelayereffect)
+{
+#ifdef HAVE_GD_BUNDLED
+ zval **IM, **effect;
+ gdImagePtr im;
+
+ if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, IM, effect) == FAILURE) {
+ ZEND_WRONG_PARAM_COUNT();
+ }
+
+ ZEND_FETCH_RESOURCE(im, gdImagePtr, IM, -1, Image, le_gd);
+ convert_to_long_ex(effect);
+
+ gdImageAlphaBlending(im, Z_LVAL_PP(effect) );
+
+ RETURN_TRUE;
+#else
+ zend_error(E_ERROR, %s(): requires PHP libgd extensions, get_active_function_name(TSRMLS_C));
+#endif
+}
+/* }}} */
+
/* {{{ proto int imagecolorresolvealpha(resource im, int red, int green, int blue, int alpha)
Resolve/Allocate a colour with an alpha level. Works for true colour and palette based images */
PHP_FUNCTION(imagecolorresolvealpha)
-2975,7 +3049,7
int space;
int *f_ind;
int h_lines, v_lines, c_ind;
- int rd, gr, bl, fg_rd, fg_gr, fg_bl, bg_rd, bg_gr, bg_bl, _fg, _bg;
+ int rd, gr, bl, al, fg_rd, fg_gr, fg_bl, fg_al, bg_rd, bg_gr, bg_bl, bg_al, _fg, _bg;
int aa[16], aa_steps;
int width, amount_kern, add_width;
double angle, extend;
-3024,16 +3098,19
fg_rd = gdImageRed (bg_img, _fg);
fg_gr
Re: [PHP-DEV] libgd patch for alpha-channel mixing
On Wed, 21 Aug 2002, Tim Toohey wrote:
Any thoughts? Should I go ahead and commit this? I've never committed to PHP
before so go easy on me :-). I've been using essentially the same code on a
PHP-4.1.0 installation for a while now and I believe it works OK.
Looking at your patch I see:
PHP_FUNCION()
{
#if GD_BUNDLED
...code...
#else
zend_error (does not exist);
#endif
}
The preferred way would be not to have these functions available at all
when GD is not bundled, like:
#if GD_BUNDLED
PHP_FUNCTION()
{
}
#endif
(but dont forget the function entry struct then).
Secondly you should use php_error_docref, and not zend_error for
errormessages and finally please stick to the coding standards as used
in the rest of the PHP source (well, most of it :).
Derick
---
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
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tests tweaks
At 00:56 22.08.2002, you wrote:
Hi Marcus,
At 23:54 21-8-2002, Marcus Börger wrote:
At 17:58 21.08.2002, Melvyn Sopacua wrote:
At 03:36 21-8-2002, Marcus Börger wrote:
I made the functions a bit more C99 complient (maybe we should use
some C99 complience suit...) but unfortuanetley that was not all.
1) someone must have changed ini setting precision from 14 to 12
Adding special INI section to array tests fixed test 1 2.
2) test 003 Test usort, uksort and uasort
All this functions fail on the subarray
That test is now fixed.
There's indeed a printf bug, for AIX:
float(-.33) on 003.phpt.
That it is there does not mean it is C99 complient.
We only use our own snprintf it is missing.
Yes, I saw that.
Funny thing is, that AIX has snprintf, and it's used.
The manpage is here - if you want to see whether that complies to
your requirements:
http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf2/snprintf.htm
There is nothing said about to what it conforms and that there is at
least one
digit infront of the decimal point is not mentioned either so i guess the
function was created before C99.
Is this what you are looking for?
#include stdio.h
int main()
{
double f;
char *result;
size_t buf_len=1024;
result = (char *) malloc(buf_len+1);
f = -.;
if(snprintf(result, buf_len, Result is: %f and precision 12:
%.12f\n, f, f) 1)
{
fprintf(stderr, Error\n);
}
else
{
printf(%s, result);
}
}
$ ./snprintf
Result is: -0.33 and precision 12: -0.
No there are more important issues in compliancy .
Especially there are libraries out which do not check for the length
parameter (i already have the code needed for that)
The code for you provided does not work because you only
check for the number of characters written. Instead you must
check for the '0' in front of the decimal point. E.g:
char buf[10];
if (strcmp(0.1, snprintf(buf, sizeof(buf), %.f, .1))) ...
Besides the return value is different in the libraries, too. Some return
the length actually written but C99 requires to return the number of
characters that could have been written if buffer was large enough.
regards
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libgd patch for alpha-channel mixing
On Thu, 22 Aug 2002 08:28, [EMAIL PROTECTED] wrote:
On Wed, 21 Aug 2002, Tim Toohey wrote:
Any thoughts? Should I go ahead and commit this? I've never committed to
PHP before so go easy on me :-). I've been using essentially the same
code on a PHP-4.1.0 installation for a while now and I believe it works
OK.
Looking at your patch I see:
PHP_FUNCION()
{
#if GD_BUNDLED
...code...
#else
zend_error (does not exist);
#endif
}
The preferred way would be not to have these functions available at all
when GD is not bundled, like:
#if GD_BUNDLED
PHP_FUNCTION()
{
}
#endif
(but dont forget the function entry struct then).
Wouldn't it be preferable for the function to be there and report the reason
it doesn't work, ie this function only works when using the bundled GD
library?
Secondly you should use php_error_docref, and not zend_error for
errormessages and finally please stick to the coding standards as used
in the rest of the PHP source (well, most of it :).
Apart from the if(){} style in the libgd section and error messages, am I
missing anything? I tried to be consistent with the existing code in the
module, so function names don't follow the coding standards by not having _
between words - should I fix this for the new functions and be inconsistant
with other Image*() functions?
Derick
Tim
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libgd patch for alpha-channel mixing
Wouldn't it be preferable for the function to be there and report the reason it doesn't work, ie this function only works when using the bundled GD library? No, because then people can't write portable code that checks using function_exists() -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tests tweaks
At 01:25 22-8-2002, Marcus Börger wrote:
At 00:56 22.08.2002, you wrote:
Is this what you are looking for?
#include stdio.h
int main()
{
double f;
char *result;
size_t buf_len=1024;
result = (char *) malloc(buf_len+1);
f = -.;
if(snprintf(result, buf_len, Result is: %f and precision 12:
%.12f\n, f, f) 1)
{
fprintf(stderr, Error\n);
}
else
{
printf(%s, result);
}
}
$ ./snprintf
Result is: -0.33 and precision 12: -0.
No there are more important issues in compliancy .
Especially there are libraries out which do not check for the length
parameter (i already have the code needed for that)
Ok.
The code for you provided does not work because you only
check for the number of characters written. Instead you must
check for the '0' in front of the decimal point. E.g:
char buf[10];
if (strcmp(0.1, snprintf(buf, sizeof(buf), %.f, .1))) ...
Besides the return value is different in the libraries, too. Some return
the length actually written but C99 requires to return the number of
characters that could have been written if buffer was large enough.
Then this one is definetely not C99 compliant. Changed the test to:
#include stdio.h
int main()
{
char buf[5];
int written;
written = snprintf(buf, sizeof(buf), %f, .111);
if (strcmp(0.1, buf)==0 written == 6)
{
printf(OK\n);
}
else
{
printf(Not ok: %s (%i)\n, buf, written);
}
}
Result:
Not ok: 0.11 (5)
Additionally - with %.f it rounds to integer zero.
Result:
Not ok: 0 (1)
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tests tweaks
At 01:51 22.08.2002, Melvyn Sopacua wrote:
At 01:25 22-8-2002, Marcus Börger wrote:
At 00:56 22.08.2002, you wrote:
Is this what you are looking for?
#include stdio.h
int main()
{
double f;
char *result;
size_t buf_len=1024;
result = (char *) malloc(buf_len+1);
f = -.;
if(snprintf(result, buf_len, Result is: %f and precision 12:
%.12f\n, f, f) 1)
{
fprintf(stderr, Error\n);
}
else
{
printf(%s, result);
}
}
$ ./snprintf
Result is: -0.33 and precision 12: -0.
No there are more important issues in compliancy .
Especially there are libraries out which do not check for the length
parameter (i already have the code needed for that)
Ok.
The code for you provided does not work because you only
check for the number of characters written. Instead you must
check for the '0' in front of the decimal point. E.g:
char buf[10];
if (strcmp(0.1, snprintf(buf, sizeof(buf), %.f, .1))) ...
Besides the return value is different in the libraries, too. Some return
the length actually written but C99 requires to return the number of
characters that could have been written if buffer was large enough.
Then this one is definetely not C99 compliant. Changed the test to:
#include stdio.h
int main()
{
char buf[5];
int written;
written = snprintf(buf, sizeof(buf), %f, .111);
if (strcmp(0.1, buf)==0 written == 6)
{
printf(OK\n);
}
else
{
printf(Not ok: %s (%i)\n, buf, written);
}
}
Result:
Not ok: 0.11 (5)
How is this, did you mean 3 * '1'? The function is supposed to return the
number of
characters that could have been written (excluding the terminating \0).
Additionally - with %.f it rounds to integer zero.
Result:
Not ok: 0 (1)
A quick look in the docs says when no precision is given 6 is assumed.
So i would expect 0.111
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: run-tests.php + diff
The following patch produces *.diff files similar to
diff command. These would allow for easier checks in faild tests
when test combines multiple function checks in one test file
or the test uses var_dump for output.
For example i changed precision to 13 in array test 003.phpt
The tests now produce 003.diff
004- float(-0.33)
004+ float(-0.3)
034- float(-0.33)
034+ float(-0.3)
050- float(-0.33)
050+ float(-0.3)
When the test fails because of memory leaks and such then
of cause .log files are better to read.
Any pros/cons?
Here is the diff
cvs -z3 -q diff -w run-tests.php (in directory S:\php4\)
Index: run-tests.php
===
RCS file: /repository/php4/run-tests.php,v
retrieving revision 1.53
diff -u -w -r1.53 run-tests.php
--- run-tests.php 21 Aug 2002 23:06:38 - 1.53
+++ run-tests.php 22 Aug 2002 00:34:57 -
@@ -420,9 +420,30 @@
);
fclose($log);
+$diffname = ereg_replace('\.phpt$','.diff',$file);
+$diff = fopen($diffname,'w')
+or error(Cannot create test log - $logname);
+
+fwrite($diff,generate_diff($wanted,$output));
+fclose($diff);
+
error_report($file,$logname,$tested);
return 'FAILED';
+}
+
+function generate_diff($wanted,$output) {
+$w = explode(\n, $wanted);
+$o = explode(\n, $output);
+$w1 = array_diff($w,$o);
+$o1 = array_diff($o,$w);
+$w2 = array();
+$o2 = array();
+foreach($w1 as $idx = $val) $w2[sprintf(%03d,$idx)] =
sprintf(%03d- $val, $idx+1);
+foreach($o1 as $idx = $val) $o2[sprintf(%03d,$idx)] =
sprintf(%03d+ $val, $idx+1);
+$diff = array_merge($w2, $o2);
+ksort($diff);
+return implode(\r\n, $diff);
}
function error($message) {
--- mailto:[EMAIL PROTECTED] --
Wir sind allzumal Tiere unter Tieren, Kinder der Materie wie sie,
nur wehrloser. Doch da wir im Unterschied zu den Tieren wissen,
dass wir sterben muessen, wollen wir uns auf jenen Augenblick vorbereiten,
indem wir das Leben geniessen, das uns durch Zufall und vom Zufall gegeben
ist.
Umberto Eco, Die Insel des vorigen Tages
- http://marcus-boerger.de -
Tel. 0241 / 874 09-7 ### 0179 / 29 14 980
