[PHP-DEV] Bug #14498 Updated: undefined symbol: my_message_no_curses

[georg]

ID: 14498
Updated by: georg
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: MySQL related
Operating System: Cobalt Linux 5.0
PHP Version: 4.1.0
Assigned To: zak
New Comment:

Thats not a php-bug, its a mysql/cobalt problem.
Configure mysql with following additional options:

-disable-shared -with-mysqld-ldflags="-all-static" 
-with-client-ldflags="-all-static"


Previous Comments:


[2001-12-31 19:14:51] [EMAIL PROTECTED]

By not specifying a path to the MySQL libraries, you are 
using PHP's built-in library.

I would guess this is a problem with MySQL - I will check 
it out.




[2001-12-13 17:36:06] [EMAIL PROTECTED]

Compiled MySQL 3.23.46 with these configure options:

./configure \
--prefix=/usr/local/mysql \
--enable-assembler \
--with-low-memory

Compiled PHP 4.10 with these options:

./configure --with-apxs=/usr/sbin/apxs \
--with-mysql=/usr/local/mysql \
--with-imap=/usr/local/src/imap-2000c \
--with-imap-ssl \
--with-zlib \
--enable-track-vars \
--with-gettext \
--with-gd \
--with-jpeg-dir=/usr/local/lib \
--with-mm=/usr/local/lib/mm \
--enable-sysvshm \
--enable-ftp

Starting Apache 1.3.22 with "apachectl start" gives me this:

Syntax error on line 238 of /etc/httpd/conf/httpd.conf:
Cannot load /usr/lib/apache/libphp4.so into server: 
/usr/local/mysql/lib/mysql/libmysqlclient.so.10: undefined symbol: 
my_message_no_curses

I can work-around this bug by NOT specifying the dir when configuring PHP i.e. 
(--with-mysql as opposed to --with-mysql=/usr/local/mysql)







Edit this bug report at http://bugs.php.net/?id=14498&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14787: HTTPS still not working

[chassaing]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.1
PHP version:  4.1.1
PHP Bug Type: cURL related
Bug description:  HTTPS still not working

When using cURL to fetch pages over SSL, curl_error report "SSL: couldn't
create a context!". This happens with the openssl extension compiled with
PHP. Fetching pages over regular HTTP works fine. This bug is around since
4.0.6, disappeared in CVS later on, then reappeared in the 4.1 RC and is
still here in 4.1.1.

PHP compiled as :
./configure \
--prefix=/usr/home/myhome/local \
--enable-bcmath \
--with-zlib \
--with-png-dir=/usr/local \
--with-jpeg-dir=/usr/local \
--with-tiff-dir=/usr/home/myhome/local \
--with-t1lib=/usr/home/myhome/local \
--with-freetype-dir=/usr/home/myhome/local \
--enable-gd-native-ttf \
--with-gd=/usr/home/myhome/local \
--enable-exif \
--with-mysql=/usr/local \
--with-ming=/usr/home/myhome/local \
--disable-pear \
--with-config-file-path=/usr/home/myhome/local/etc \
--enable-debug=no \
--enable-force-cgi-redirect=yes \
--with-openssl=/usr/local/ssl \
--with-curl=/usr/home/myhome/src/curl-7.9 \
--with-dom=/usr/home/myhome/local

-- 
Edit bug report at: http://bugs.php.net/?id=14787&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14788: mkdir

[yangmx]

From: [EMAIL PROTECTED]
Operating system: redhat 7.2
PHP version:  4.0.6
PHP Bug Type: *Directory/Filesystem functions
Bug description:  mkdir

in apache vhost:
mkdir(path, 0777);
but the directory's mod is 755
-- 
Edit bug report at: http://bugs.php.net/?id=14788&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[David Eriksson]

At 13:58 2001-12-31 -0500, Joao Prado Maia wrote:
>I would think the following extensions should also go to PECL:
>.
>.
>.
>satellite

Sure, Satellite could probably be moved there...

-\- David Eriksson -/-


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Moving extensions to PECL

[Marcel Beerta]

> > Are there any well-founded objections to this (either in practice
> > or principle)?
>
> no objections, but one thing that should be considered is what happens
> to the documentation for these extensions when they are no longer a
part
> of the core distribution.

Documentation should really be an important issue, too I think. In my
opinion, the docs of the moved-out extensions should go into the Peardoc
repository, but I don't exactly know, how far the setup of the
Doc-Platform for PEAR is.


--
Marcel "mazen" Beerta
http://www.mazenphp.de | http://www.etcpasswd.de
[EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Markus Fischer]

On Mon, Dec 31, 2001 at 02:01:52PM -0500, Jon Parise wrote : 
> On Mon, Dec 31, 2001 at 01:58:42PM -0500, Joao Prado Maia wrote:
> 
> > > > > This is definitely not an inclusive list; it's just a start.  I
> > > > > can't imagine a lot of people using these modules, so they seem
> > > > > like good candidates for removal from the base PHP distribution.
> > 
> > What about the 'fribidi' extension then ? ;)
>  
> Okay, before this gets out of hand:
> 
> I do _not_ want to create a list of extensions to pull from the
> base distribution.  My intensions are simply to try moving a few
> "standard" extensions out of the base PHP distribution and into
> PECL to help test the PECL build infrastructure and to
> standardize the procedure for moving extensions out of the base
> distribution.
> 
> I probably should have made that clearer before.
> 
> I don't want this to turn into a "this extension is too big and
> is seldom used" kind of thread.  We've had enough of those in the
> past.

Yeah, that is really a great idea! (+1).

- Markus

-- 
Please always Cc to me when replying to me on the lists.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists

[Markus Fischer]

On Mon, Dec 31, 2001 at 09:21:15PM -, [EMAIL PROTECTED] wrote : 
> ID: 14782
> Updated by: zak
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Feedback
> Bug Type: Feature/Change Request
> Operating System: all
> PHP Version: 4.1.1
> New Comment:
> 
> Hi Mike,
> 
> Unless one of the developers objects, I will add the alias 
> - however, if the change is made, it would not show up 
> 'til the next release.

-1 ... it's too late now. 4.1.0 with, 4.1.1 without, 4.1.x
with ... no, this doesn't make sense IMHO 

-- 
Please always Cc to me when replying to me on the lists.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14783 Updated: Using unlink causes segfault

[mfischer]

ID: 14783
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: DOM XML related
Operating System: RH6.2/Apache/libxml2.4.12
PHP Version: 4.1.1
New Comment:

This has been fixed in CVS.

Previous Comments:


[2001-12-31 16:16:27] [EMAIL PROTECTED]

Symptoms:
- using unlink() causes segfault

Script to reproduce:



Hello
World

END_XML;
$dom = xmldoc($xml);

// this so I can see it.
header('Content-type: text/plain');

$ctx = $dom->xpath_new_context();

$res = xpath_eval($ctx,"//foo");

foreach ($res->nodeset as $child) {
$child->unlink();
} 

echo $dom->dumpmem();
?>

Other notes:

- some cursory debugging I did suggested that it was the cleanup routines at the end 
of the script that were causing the crash.  Looking at php_domxml.c, the recursive 
node memory cleanup appears to be choking on a pointer already freed during the 
unlink() call.





Edit this bug report at http://bugs.php.net/?id=14783&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13396 Updated: php4ts.dll crashes on shutdown of Windows

[steve]

ID: 13396
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Reproducible crash
Operating System: Windows 98 SE
PHP Version: 4.0.6
New Comment:

After some research I now believe my issue was caused by a configuration error in 
Personal Web Server 4.0.  I determined that despite my setting the registry's Script 
Map to use PHP.EXE, PWS was really using PHP in ISAPI mode, which I hadn't noticed 
from the phpinfo() report.  This setting appears to be in the metabase.bin file, which 
is apparently not editable on Windows 9x.  I finally uninstalled PWS and installed 
Apache's web server to fix the problem.  I suspect an uninstall and reinstall of PWS 
would have worked also since the uninstall deletes the metabase.bin file.

Previous Comments:


[2001-09-22 10:19:19] [EMAIL PROTECTED]

I think this is really a "me too" for bug #12270, but I can't add to that report.

I have also had this happen on I believe just 4.0.5 and 4.0.6, on Windows 98 SE and 
PWS. Earlier versions did not have this problem.  I am using PHP.EXE.

To reproduce, open ANY .php page in a browser, and shut down Windows. If I open no 
.php pages (i.e. PHP never runs), I do not get the error.

I have tried putting php4ts.dll in my \windows\system folder, and adding it to the 
PATH, to no avail.





Edit this bug report at http://bugs.php.net/?id=13396&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14781 Updated: ftp_login failure after mysql_connect

[mfischer]

ID: 14781
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: FTP related
Operating System: Linux Redhat 6.2/7.2
PHP Version: 4.1.1
New Comment:

Your code doesn't watch out for operator precedence:

$foo = function1() ||  die("i'm dead now");

will evalute to

$foo = ( function1() ||  die("i'm dead now") );

which means $foo will be true (if function1 succeeded).

For your code this means:

$hFtp = ( ftp_connect ("localhost") || die ("Could not connect.\n") ).

and therefore $hFtp will be boolean true and not your resource/connection id. Proper 
parenthesizing will solve this:

( $hFtp = ftp_connect ("localhost") ) || die ("Could not connect.\n");

Previous Comments:


[2001-12-31 11:30:49] [EMAIL PROTECTED]

I wanted to connect to a ftp server, get some files and insert them into a database.
I started connecting to the ftp server, then logging in and that worked fine. Then I 
added a mysql_connect and now I get an error on ftp_login that says that it can not 
find ftpbuf.
(tried on two systems: Linux Redhat 6.2, Linux Redhat 7.2).

I'm not sure if this is a failure of ftp functions, mysql, a documentation problem or 
me being too stupid.

After dropping all unneccessary code, the file looks like that:


I got the following error message:
Warning: Unable to find ftpbuf 1 in "scipt" on line "XX",
(which is the ftp_login line (ftp_connect works!)).

If you drop mysql_connect, its working fine...

I'm using build in mysql support (for version 3.23.39), ftp is of course enabled too.

Hopefully this is a stupid question and there is an easy answer...
Thanks in advance and a happy new year,
flim





Edit this bug report at http://bugs.php.net/?id=14781&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14376 Updated: Multiple Variants cause apache to loop (?)

[lobbin]

ID: 14376
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: COM related
Operating System: W2k Server
PHP Version: 4.0.6
New Comment:

No feedback. Closing.

Previous Comments:


[2001-12-11 13:54:42] [EMAIL PROTECTED]

Try the latest development version from www.php4win.com, and check if it still has the 
problem.
Please report back.



[2001-12-07 07:24:06] [EMAIL PROTECTED]

PHP and COM are working together, but whenever multiple VARIANTs are made it has 
problems, single variants are okay. Once I perform the query on the object and get the 
values retuned to the browser, apache seems to get stuck in a loop and uses up around 
98% of all system resources. 

$a = new VARIANT();
$b = new VARIANT();
will cause an apparent loop/whatever (Sorry I've not used the correct terminology)

$a = new VARIANT();
on it's own allows the rest of the script to function.
It is almost like PHP is not releasing the variant and allowing the page to display.
See forums at ZEND, subject : PHP, COM and VARIANTS 
Whilst the values are returned to the browser, they do not actually get displayed, I 
end up with a white page, that is continually indicating that it is loading. However, 
if I view the source code I end up seeing the exact output and variables I was 
expecting, but it simply doesn't display. 
If I then kill the apache process (W2k, Apache, PHP setup for development work) the 
page displays. 
Help! 
I have tried to close/kill/exit/unload the COM object and the VARIANTS too, but all to 
no avail. We know that the COM object is completing all it's stuff as we've put that 
through the VB debugger (I haven't got time to learn the Zend debugger right now! 
Unless anyone knows of any really quick tutorials) 
If we do not use the VARIANT call but still use the COM object the system performs as 
expected, but as soon as a VARIANT gets involved the performance goes downhill, 
instantly. The browser does not display and the Server goes into a loop that absorbs 
all system resources. 
Please, please, can anybody help? I'm stumped.

Enabled extensions are:

extension=php_gd.dll
extension=php_ming.dll
extension=php_pdf.dll
extension=php_pgsql.dll
extension=php_zlib.dll

The binary install was a default binary from www.firepages.com.au for W2k (the 13Mb 
one).
Hope this helps.

Biz





Edit this bug report at http://bugs.php.net/?id=14376&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14398 Updated: PHP Core Dumps when connecting via UNIX sockets

[lobbin]

ID: 14398
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: PostgreSQL related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

No feedback. Closing.

Previous Comments:


[2001-12-11 16:48:34] [EMAIL PROTECTED]

Just to add:
Try 4.1.0, maybe the problem has already been fixed.



[2001-12-11 14:55:28] [EMAIL PROTECTED]

please post a backtrace here, check on :
bugs.php.net/how-to-report.php how to do it.

Derick



[2001-12-10 04:46:57] [EMAIL PROTECTED]

The database called phpbook belongs to user postgres and is located on the local host 
(-> Access via UNIX sockets and not TCP/IP).
pg_host causes PHP to core dump - other commands don't  seem to work properly as well.

";
}
 
echo "Host: ".pg_host($dbh)."";
echo "Database: ".pg_dbname($dbh)."";
echo "Port: ".pg_port($dbh)."";
echo "tty: ".pg_tty($dbh)."";
?>


bash-2.05$ php connect.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
 
Segmentation fault





Edit this bug report at http://bugs.php.net/?id=14398&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Adam Dickmeiss]

On Mon, Dec 31, 2001 at 01:38:48PM -0500, Jon Parise wrote:
> I think the following "standard" extensions should be moved to
> PECL:
> 
> ext/cybercash
> ext/icap
> ext/pfpro
> ext/yaz
> 
> This is definitely not an inclusive list; it's just a start.  I
> can't imagine a lot of people using these modules, so they seem
> like good candidates for removal from the base PHP distribution.
> 
> Are there any well-founded objections to this (either in practice
> or principle)?

I'll be happy to move yaz away. I hope that moved away extensions
will not be "invisible" in the future. We use yaz and a lot of our
users in the Libraries world are too.

If this means that the documentation for YAZ which I wrote will no
longer be translated to other languages we can live with that.

The good thing about the move is that extensions will have an
independant release-cycle so that they don't have to wait for
official PHP releases, etc.

Note, that as extensions move away from the core, it'll be not
be obvious when there are Zend API changes unless we're informed.
(so far, people have patched yaz for Zend API changes, thank you).

So what's the procedure? Creating pear/XML/yaz and move stuff
to that directory? Moving documentation? How?

-- Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14434 Updated: gmp()-failure

[lobbin]

ID: 14434
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Unknown/Other Function
Operating System: Linux 2.4.x/Apache 1.3.22
PHP Version: 4.1.0
New Comment:

No feedback. Closing.

Previous Comments:


[2001-12-11 15:58:51] [EMAIL PROTECTED]

Please post a short script illustrating the problem, and
any specific errors you are getting.



[2001-12-11 15:27:11] [EMAIL PROTECTED]

Starting with version 4.1.0, the gmp_init() and/or gmp_strval() function seems broken. 
Having checked the
changelog/press release for 4.1.0, there was mention of an
optional argument to gmp_init(), one that I do not use. And
code that worked in 4.0.6 does not work with 4.1.0 (no other changes other than 
upgrading to the new PHP). Reverting back to 4.0.6 immediately resolves the
problem.




[2001-12-11 15:26:27] [EMAIL PROTECTED]

Starting with version 4.1.0, the gmp_init() and/or gmp_strval() function seems broken. 
Having checked the
changelog/press release for 4.1.0, there was mention of an
optional argument to gmp_init(), one that I do not use. And
code that worked in 4.0.6 does not work with 4.1.0 (no other changes other than 
upgrading to the new PHP). Reverting back to 4.0.6 immediately resolves the
problem.





Edit this bug report at http://bugs.php.net/?id=14434&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] MOPS Benchmark

[Sebastian Bergmann]

Sebastian Bergmann wrote:
>   Updated table:
>
> Language  | Elapsed time | MOPS
> --+--+--
  Parrot 0.0.3  |   7 seconds  | 26.99
> Python|  88 seconds  |  2.27
> Perl  | 102 seconds  |  1.96
> Ruby  | 124 seconds  |  1.59
> PHP (+ ZendOptimizer) | 142 seconds  |  1.41
> PHP   | 158 seconds  |  1.27
> PHP (Zend Engine 2)   | 177 seconds  |  1.13

  Now I am depressed,
Sebastian

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14789: _SERVER["REQUEST_URI"] not fully given to Caudium 1.0.34

[delahaye]

From: [EMAIL PROTECTED]
Operating system: FreeBSD / Linux
PHP version:  4.1.1
PHP Bug Type: Other web server
Bug description:  _SERVER["REQUEST_URI"] not fully given to Caudium 1.0.34

When using PHP 4 with Caudium, the $REQUEST_URI / _SERVER["REQUEST_URI"]
var is not full.

For example, look at this phpinfo():
http://aleph1.net/test.php3/toto/a=b&c=d

You get the following line :
_SERVER["REQUEST_URI"] /test.php3  

It should have been : 
_SERVER["REQUEST_URI"] /test.php3/toto/a=b&c=d
-- 
Edit bug report at: http://bugs.php.net/?id=14789&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Moving extensions to PECL

[Martin Jansen]

On 31 Dec 2001 19:18:59 -, Jim Winstead wrote:

>Jon Parise <[EMAIL PROTECTED]> wrote:
>> Are there any well-founded objections to this (either in practice
>> or principle)?
>
>no objections, but one thing that should be considered is what happens
>to the documentation for these extensions

The documentation of the extensions can be easily merged in the 
peardoc repository. Right now there is no automated build for
the manual, but you promised to help us with that in 2002, no? :-)

- Martin

-- 
  Martin Jansen, <[EMAIL PROTECTED]>
  http://www.martin-jansen.de/



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] MOPS Benchmark

[Zeev Suraski]

I wouldn't pay too much attention to anything in version 0.0.3.  The Zend 
engine was quicker than Perl at this kind of stuff during initial stages of 
development, but as more features and functionality are added, it became 
slower.

That said - if you're using PHP because of performance, you're choosing the 
wrong language.  For instance, I can pretty much assure you that 
Microsoft's CLR is going to be quicker, because it'll be almost in the same 
speed of native code.  The thing about PHP is everything it gives you, and 
the ease of using everything it gives you, while still being quite 
quick.  It's not supposed to be the quickest.

Zeev

At 15:38 01/01/2002, Sebastian Bergmann wrote:
>Sebastian Bergmann wrote:
> >   Updated table:
> >
> > Language  | Elapsed time | MOPS
> > --+--+--
>   Parrot 0.0.3  |   7 seconds  | 26.99
> > Python|  88 seconds  |  2.27
> > Perl  | 102 seconds  |  1.96
> > Ruby  | 124 seconds  |  1.59
> > PHP (+ ZendOptimizer) | 142 seconds  |  1.41
> > PHP   | 158 seconds  |  1.27
> > PHP (Zend Engine 2)   | 177 seconds  |  1.13
>
>   Now I am depressed,
>Sebastian
>
>--
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14789 Updated: _SERVER["REQUEST_URI"] not fully given to Caudium 1.0.34

[jan]

ID: 14789
Updated by: jan
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Other web server
Operating System: FreeBSD / Linux
PHP Version: 4.1.1
New Comment:

REQUEST_URI is an apache specific variable. no bug ->bogus.

Previous Comments:


[2002-01-01 09:56:13] [EMAIL PROTECTED]

When using PHP 4 with Caudium, the $REQUEST_URI / _SERVER["REQUEST_URI"] var is not 
full.

For example, look at this phpinfo(): http://aleph1.net/test.php3/toto/a=b&c=d

You get the following line :
_SERVER["REQUEST_URI"] /test.php3  

It should have been : 
_SERVER["REQUEST_URI"] /test.php3/toto/a=b&c=d





Edit this bug report at http://bugs.php.net/?id=14789&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14768 Updated: Upgrade to 4.1.0 breaks database connection

[php]

ID: 14768
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 4.1.0
New Comment:

Neither mysql_connect or mysql_pconnect seemed to work.

Previous Comments:


[2001-12-30 08:20:13] [EMAIL PROTECTED]

Are you using mysql_pconnect()



[2001-12-30 07:03:37] [EMAIL PROTECTED]

Just to clarify - I'm using the standard Win32 binaries as downloadable from the 
php.net site.



[2001-12-30 07:00:22] [EMAIL PROTECTED]

Today I upgraded PHP on my WinXP system from 4.0.6 to 4.1.0 as I was finding 4.0.6 
slow and thought 4.1.0 may help. After the upgrade, all MySQL connectivity was broken 
- none of my scripts installed could connect. MySQL was running fine (and 
winmysqladmin from the mysql\bin directory was able to connect fine). Restarting MySQL 
and IIS did not help.

I was able to downgrade back to 4.0.6 (from the backup directory created during 
install), which immediately fixed the problem.





Edit this bug report at http://bugs.php.net/?id=14768&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14790: --with-zlib == broken phpinfo()

[db]

From: [EMAIL PROTECTED]
Operating system: OpenBSD 2.9
PHP version:  4.1.1
PHP Bug Type: Zlib Related
Bug description:  --with-zlib == broken phpinfo()

Hi,

If I use --with-zlib and I launch phpinfo() function it breaks after
calendar (before zlib!) table.
I solved configuring without "--with-zlib".

(Note that with 4.0.6 all went right.)

Thanks.


Ed


-- 
Edit bug report at: http://bugs.php.net/?id=14790&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] MOPS Benchmark

[Sebastian Bergmann]

Zeev Suraski wrote:
> I wouldn't pay too much attention to anything in version 0.0.3.

  Of course.

> The Zend engine was quicker than Perl at this kind of stuff during 
> initial stages of development, but as more features and 
> functionality are added, it became slower.

  I understand this, and somewhat expect Parrot to become slower. Apart
  from that, I have a feeling that the fundamental difference of using a
  register machine model for the virtual machine instead of the
  ''traditional'' stack machine approach will give Parrot -- and hence
  Perl 6 -- a huge performance advantage.

> That said - if you're using PHP because of performance, you're 
> choosing the wrong language.  For instance, I can pretty much assure 
> you that Microsoft's CLR is going to be quicker, because it'll be 
> almost in the same speed of native code.

  I chose PHP for its ease of use and its sex appeal.

  I don't mind PHP to be slower than Perl or Python that much. But what
  I would not mind would be the Zend Engine 2 beeing slower than the
  Zend Engine 1...

  BTW: Happy New Year :-)

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14783 Updated: Using unlink causes segfault

[mfkahn2]

ID: 14783
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: DOM XML related
Operating System: RH6.2/Apache/libxml2.4.12
Old PHP Version: 4.1.1
PHP Version: CVS Jan. 1 2002
New Comment:

Just checked out and built from CVS this morning (2002/1/1).  The test script still 
crashes.  

Previous Comments:


[2002-01-01 07:11:54] [EMAIL PROTECTED]

This has been fixed in CVS.



[2001-12-31 16:16:27] [EMAIL PROTECTED]

Symptoms:
- using unlink() causes segfault

Script to reproduce:



Hello
World

END_XML;
$dom = xmldoc($xml);

// this so I can see it.
header('Content-type: text/plain');

$ctx = $dom->xpath_new_context();

$res = xpath_eval($ctx,"//foo");

foreach ($res->nodeset as $child) {
$child->unlink();
} 

echo $dom->dumpmem();
?>

Other notes:

- some cursory debugging I did suggested that it was the cleanup routines at the end 
of the script that were causing the crash.  Looking at php_domxml.c, the recursive 
node memory cleanup appears to be choking on a pointer already freed during the 
unlink() call.





Edit this bug report at http://bugs.php.net/?id=14783&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] MOPS Benchmark

[Andi Gutmans]

At 04:59 PM 1/1/2002 +0100, Sebastian Bergmann wrote:
>   I don't mind PHP to be slower than Perl or Python that much. But what
>   I would not mind would be the Zend Engine 2 beeing slower than the
>   Zend Engine 1...

That's pretty weird. I ran the same script and they are pretty much the 
same which makes sense because non of the code which is used in that script 
was changed between ZE1 and ZE2.
In any case, pertaining things such as the OOP in ZE2 I wouldn't bench mark 
it at this time because it is work in progress and hasn't been optimized (I 
know that your test didn't involve it but I'm beating you to it :)

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 5

[Andi Gutmans]

Hey,

The Zend Engine 2 has made lots of progress.
I think we should have a discussion of what other things besides the 
scripting engine we'd like to change for PHP 5.
I know there was talk on deprecating some stuff such as old-style function 
names, moving extensions to PECL etc.. I think it's a good time to start 
discussing some of these issues (hopefully we can keep things short :)
Also, let's try and keep the scope to realistic changes which won't turn 
PHP upside down and which are doable within a relatively short period of 
time. I think it'd be really cool if we could get an alpha of PHP 5 out by 
Spring.

Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys 
implemented for PECL. I know that if it's not a really cool easy to use 
mechanism I would prefer to wait until we write one. One of the main 
strengths of PHP is that everything is bundled together and is easy to 
setup. We shouldn't make it much harder on people. Although we're planning 
on only move the unimportant extensions out of PHP I still think it should 
be extremely easy to get a list of available extensions (maybe even a part 
of the ./configure process) and to easily download/configure/install them.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] MOPS Benchmark

[Sebastian Bergmann]

Andi Gutmans wrote:
> That's pretty weird.

  Benchmarks usually are. Just to make it clear: I did one run for each
  language / configuration only. No multiple iterations to get a mean
  value. That alone disqualifies my test results.

> I ran the same script and they are pretty much the same which makes 
> sense because non of the code which is used in that script was changed
> between ZE1 and ZE2.

  I'm reliefed!

> (I know that your test didn't involve it but I'm beating you to it :)

  I'm planning to write a PHP OOP benchmark sometime soon to compare
  ZE1 and ZE2.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Egon Schmid]

From: "Adam Dickmeiss" <[EMAIL PROTECTED]>

> On Mon, Dec 31, 2001 at 01:38:48PM -0500, Jon Parise wrote:
> > I think the following "standard" extensions should be moved to
> > PECL:
> >
> > ext/cybercash
> > ext/icap
> > ext/pfpro
> > ext/yaz
> >
> > This is definitely not an inclusive list; it's just a start.  I
> > can't imagine a lot of people using these modules, so they seem
> > like good candidates for removal from the base PHP distribution.
> >
> > Are there any well-founded objections to this (either in
practice
> > or principle)?
>
> I'll be happy to move yaz away. I hope that moved away extensions
> will not be "invisible" in the future. We use yaz and a lot of our
> users in the Libraries world are too.
>
> If this means that the documentation for YAZ which I wrote will no
> longer be translated to other languages we can live with that.
>
> The good thing about the move is that extensions will have an
> independant release-cycle so that they don't have to wait for
> official PHP releases, etc.
>
> Note, that as extensions move away from the core, it'll be not
> be obvious when there are Zend API changes unless we're informed.
> (so far, people have patched yaz for Zend API changes, thank you).
>
> So what's the procedure? Creating pear/XML/yaz and move stuff
> to that directory? Moving documentation? How?

Well, I know librians will love the YAZ extension. I suggest to move
the documentation in a new part in the PHP Manual. I think of a
split of the original Function Reference in something like Basic
Function Reference and Extended Function Reference. I don´t see any
improvement if it is hidden in the PEAR docs.

-Egon


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14768 Updated: Upgrade to 4.1.0 breaks database connection

[mfischer]

ID: 14768
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 4.1.0
New Comment:

Wait until 4.1.1 and see if its fixed (I bet it is).

Previous Comments:


[2002-01-01 10:38:17] [EMAIL PROTECTED]

Neither mysql_connect or mysql_pconnect seemed to work.



[2001-12-30 08:20:13] [EMAIL PROTECTED]

Are you using mysql_pconnect()



[2001-12-30 07:03:37] [EMAIL PROTECTED]

Just to clarify - I'm using the standard Win32 binaries as downloadable from the 
php.net site.



[2001-12-30 07:00:22] [EMAIL PROTECTED]

Today I upgraded PHP on my WinXP system from 4.0.6 to 4.1.0 as I was finding 4.0.6 
slow and thought 4.1.0 may help. After the upgrade, all MySQL connectivity was broken 
- none of my scripts installed could connect. MySQL was running fine (and 
winmysqladmin from the mysql\bin directory was able to connect fine). Restarting MySQL 
and IIS did not help.

I was able to downgrade back to 4.0.6 (from the backup directory created during 
install), which immediately fixed the problem.





Edit this bug report at http://bugs.php.net/?id=14768&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14783 Updated: Using unlink causes segfault

[mfischer]

ID: 14783
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Feedback
Bug Type: DOM XML related
Operating System: RH6.2/Apache/libxml2.4.12
PHP Version: CVS Jan. 1 2002
New Comment:

Did the same before I replied and it didn't crash, hm.

What were your ./configure options?

Do you have another small, self-contained sample?

Feedback.

Previous Comments:


[2002-01-01 11:15:45] [EMAIL PROTECTED]

Just checked out and built from CVS this morning (2002/1/1).  The test script still 
crashes.  



[2002-01-01 07:11:54] [EMAIL PROTECTED]

This has been fixed in CVS.



[2001-12-31 16:16:27] [EMAIL PROTECTED]

Symptoms:
- using unlink() causes segfault

Script to reproduce:



Hello
World

END_XML;
$dom = xmldoc($xml);

// this so I can see it.
header('Content-type: text/plain');

$ctx = $dom->xpath_new_context();

$res = xpath_eval($ctx,"//foo");

foreach ($res->nodeset as $child) {
$child->unlink();
} 

echo $dom->dumpmem();
?>

Other notes:

- some cursory debugging I did suggested that it was the cleanup routines at the end 
of the script that were causing the crash.  Looking at php_domxml.c, the recursive 
node memory cleanup appears to be choking on a pointer already freed during the 
unlink() call.





Edit this bug report at http://bugs.php.net/?id=14783&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Martin Jansen]

On Tue, 1 Jan 2002 18:36:57 +0100, Egon Schmid wrote:

>Well, I know librians will love the YAZ extension. I suggest to move
>the documentation in a new part in the PHP Manual. I think of a
>split of the original Function Reference in something like Basic
>Function Reference and Extended Function Reference. 

If yaz is going to become part of PECL (= part of PEAR), documentation
should be placed in the PEAR manual. Everything else is less intuitive
and will irritate people IMO.

- Martin

-- 
  Martin Jansen, <[EMAIL PROTECTED]>
  http://www.martin-jansen.de/



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Markus Fischer]

On Tue, Jan 01, 2002 at 06:52:55PM +0100, Martin Jansen wrote : 
> On Tue, 1 Jan 2002 18:36:57 +0100, Egon Schmid wrote:
> 
> >Well, I know librians will love the YAZ extension. I suggest to move
> >the documentation in a new part in the PHP Manual. I think of a
> >split of the original Function Reference in something like Basic
> >Function Reference and Extended Function Reference. 
> 
> If yaz is going to become part of PECL (= part of PEAR), documentation
> should be placed in the PEAR manual. Everything else is less intuitive
> and will irritate people IMO.

Will the PEAR manual be reachable via the php.net search
function?

If the documentation gets split up (which, in one way, makes
sense) how do you find the documentation than for your
favourite extension?

It's important to still have ONE extension index which links
then to the proper documentation (either PHP manual or PEAR
manual) so this all gets less confusing.

-- 
Please always Cc to me when replying to me on the lists.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: PHP 5

[Jim Winstead]

Andi Gutmans <[EMAIL PROTECTED]> wrote:
> The Zend Engine 2 has made lots of progress.

is there an up-to-date summary of the changes beyond the original ze2
proposal? example scripts that show the new features?

> Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys 
> implemented for PECL. I know that if it's not a really cool easy to use 
> mechanism I would prefer to wait until we write one. One of the main 
> strengths of PHP is that everything is bundled together and is easy to 
> setup. We shouldn't make it much harder on people. Although we're planning 
> on only move the unimportant extensions out of PHP I still think it should 
> be extremely easy to get a list of available extensions (maybe even a part 
> of the ./configure process) and to easily download/configure/install them.

having everything bundled is a strength for people who install from
source, but it really doesn't do much to help people who haved installed
from a distribution or are in a shared-hosting situation. those are the
places where something like perl's cpan really shines (and where the
pear/pecl stuff presumably will too).

i'd really love to see the existing pear/pecl stuff brought out into the
open more, even if it is not fully baked. i think the fact that it is
relatively hidden makes it extremely difficult for people to know where
things are headed, how close (or far) they are, and how to help.

(and 'unimportant' is a dangerous word. obviously that depends on the
situation.)

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Sebastian Bergmann]

Jim Winstead wrote:
> is there an up-to-date summary of the changes beyond the original ze2
> proposal? example scripts that show the new features?

  ZendEngine2/ZEND_CHANGES for starters.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Moving extensions to PECL

[Jim Winstead]

On Tue, Jan 01, 2002 at 04:05:18PM +0100, Martin Jansen wrote:
> On 31 Dec 2001 19:18:59 -, Jim Winstead wrote:
> >Jon Parise <[EMAIL PROTECTED]> wrote:
> >> Are there any well-founded objections to this (either in practice
> >> or principle)?
> >
> >no objections, but one thing that should be considered is what happens
> >to the documentation for these extensions
> 
> The documentation of the extensions can be easily merged in the 
> peardoc repository. Right now there is no automated build for
> the manual, but you promised to help us with that in 2002, no? :-)

yes, yes, i'll get to it.

but i don't see how moving the documentation from the phpdoc repository
to the peardoc repository improves the situation at all. (in fact, it
will make it slightly worse. the pear website is not mirrored, and i
don't think it is even mirrorable.)

i was thinking more along the lines of something that allowed the
documentation for an extension to be managed on its own, just like we're
allowing the extension itself to be. and then some additional mechanism
that allows the documentation for extensions to be plugged into the main
documentation.

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Andi Gutmans]

At 05:56 PM 1/1/2002 +, Jim Winstead wrote:
>(and 'unimportant' is a dangerous word. obviously that depends on the
>situation.)

I think it's obvious what I meant.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14791: Array_shift always the problem ...

[philippe]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.9
PHP version:  4.1.1
PHP Bug Type: Arrays related
Bug description:  Array_shift always the problem ...

This script : 

\n";
array_shift($toto);
print "next : ";
print_r($toto);
print "\n"; 
?>

give this :

before : Array ( [1] => 1 [2] => 2 [3] => 3 [4] => 4 [5] => 5 [6] => 6 ) 
next : Array ( [0] => 2 [1] => 3 [2] => 4 [3] => 5 [4] => 6 ) 

normally i should have :

before : Array ( [1] => 1 [2] => 2 [3] => 3 [4] => 4 [5] => 5 [6] => 6 ) 
next : Array ( [1] => 2 [1] => 3 [2] => 4 [3] => 5 [4] => 6 ) 

Regards,

Philippe BEAU
Email / Philippe--at--beau.nom.Fr
-- 
Edit bug report at: http://bugs.php.net/?id=14791&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14791 Updated: Array_shift always the problem ...

[philippe]

ID: 14791
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: Linux 2.4.9
PHP Version: 4.1.1
New Comment:

Scuse me, a little error by my hands ... ;(

normally i should have :

before : Array ( [1] => 1 [2] => 2 [3] => 3 [4] => 4 [5] => 5 [6] => 6 )

next : Array ( [1] => 2 [2] => 3 [3] => 4 [4] => 5 [5] => 6 ) 

Regards,

Philippe BEAU
Email / Philippe--at--beau.nom.Fr

Previous Comments:


[2002-01-01 13:20:40] [EMAIL PROTECTED]

This script : 

\n";
array_shift($toto);
print "next : ";
print_r($toto);
print "\n"; 
?>

give this :

before : Array ( [1] => 1 [2] => 2 [3] => 3 [4] => 4 [5] => 5 [6] => 6 ) 
next : Array ( [0] => 2 [1] => 3 [2] => 4 [3] => 5 [4] => 6 ) 

normally i should have :

before : Array ( [1] => 1 [2] => 2 [3] => 3 [4] => 4 [5] => 5 [6] => 6 ) 
next : Array ( [1] => 2 [1] => 3 [2] => 4 [3] => 5 [4] => 6 ) 

Regards,

Philippe BEAU
Email / Philippe--at--beau.nom.Fr





Edit this bug report at http://bugs.php.net/?id=14791&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 5

[Georg Richter]

Although we're planning
> on only move the unimportant extensions out of PHP I still think it should
> be extremely easy to get a list of available extensions (maybe even a part
> of the ./configure process) and to easily download/configure/install them.

Please could you explain "unimportant" ?!

Georg

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 5

[Andi Gutmans]

At 07:24 PM 1/1/2002 +0100, Georg Richter wrote:
>Although we're planning
> > on only move the unimportant extensions out of PHP I still think it should
> > be extremely easy to get a list of available extensions (maybe even a part
> > of the ./configure process) and to easily download/configure/install them.
>
>Please could you explain "unimportant" ?!

Uhm it's what we've always talked about: "Extensions which are not very 
widely used". (Why do people always need to get so picky about wording?) 
This can of course include extensions who'se author wants it to be outside 
of PHP because of the release cycle.
If you need an example. MySQL is widely used. fribidi is not widely used. 
session is widely used. readline is not.
We agreed in the past that there is a set of core extensions which we'd 
want to keep in PHP. We don't want to remove everything from PHP as this 
was always one of PHP's strengths.

Anyway, I don't know why we are clinging to the "unimportant" part of what 
I wrote and not the important part which is how PECL actually uses it and 
what the vision for PECL is.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Egon Schmid]

From: "Martin Jansen" <[EMAIL PROTECTED]>

> On Tue, 1 Jan 2002 18:36:57 +0100, Egon Schmid wrote:
>
> >Well, I know librians will love the YAZ extension. I suggest to
move
> >the documentation in a new part in the PHP Manual. I think of a
> >split of the original Function Reference in something like Basic
> >Function Reference and Extended Function Reference.
>
> If yaz is going to become part of PECL (= part of PEAR),
documentation
> should be placed in the PEAR manual. Everything else is less
intuitive
> and will irritate people IMO.

Are you sure that librians find the PEAR documentation? As I can see
PEAR and PHP documentation differs in many things. I think Adam
would be glad if he can maintain the YAZ functions as before.

-Egon


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14784 Updated: shmop_write causes segfault

[markhers]

ID: 14784
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Linux (RH 6.2 / 2.4.3)
PHP Version: 4.1.1
New Comment:

Sorry. I forgot to include the backtrace:

< start >

Program received signal SIGSEGV, Segmentation fault.
0x40103493 in memcpy (dstpp=0x40319000, srcpp=0x81ea42c, 
len=1) at ../sysdeps/generic/memcpy.c:61
61  ../sysdeps/generic/memcpy.c: No such file or 
directory.
(gdb) bt
#0  0x40103493 in memcpy (dstpp=0x40319000, srcpp=
0x81ea42c, len=1) at ../sysdeps/generic/memcpy.c:61
#1  0x40583745 in ?? () from /usr/local/apache/libexec/
libphp4.so
#2  0x4053f235 in ?? () from /usr/local/apache/libexec/
libphp4.so
#3  0x4054e22b in ?? () from /usr/local/apache/libexec/
libphp4.so
#4  0x4055f861 in ?? () from /usr/local/apache/libexec/
libphp4.so
#5  0x4055c1f2 in ?? () from /usr/local/apache/libexec/
libphp4.so
#6  0x4055cb56 in ?? () from /usr/local/apache/libexec/
libphp4.so
#7  0x4055cb88 in ?? () from /usr/local/apache/libexec/
libphp4.so
#8  0x80550f3 in ap_invoke_handler ()
#9  0x8069529 in process_request_internal ()
#10 0x806958c in ap_process_request ()
#11 0x8060a6e in child_main ()
#12 0x8060c20 in make_child ()
#13 0x8060d79 in startup_children ()
#14 0x80613d6 in standalone_main ()
#15 0x8061ba3 in main ()
#16 0x400bb9cb in __libc_start_main (main=0x806184c , 
argc=2, argv=0xba2c, init=0x804f47c <_init>, 
fini=0x809858c <_fini>, rtld_fini=0x4000aea0 <_dl_fini>
, stack_end=0xba24) at ../sysdeps/generic/libc-
start.c:92

< end >

  mjh

Previous Comments:


[2001-12-31 21:20:53] [EMAIL PROTECTED]

I have been experimenting with semaphores/shmop to provide 
query caching for an application I am working on. The 
purpose, of course, bears no bearing on the issue I am 
reporting however as I am just doing testing of the two 
extensions at this point.

I used this article as the starting point for my testing - 
http://zez.org/article/articleprint/46/.

So I put together this script:

--

function mtime()
{
return array_sum( explode( " ", microtime() ) );
}

function supecho( $text )
{
echo "$text\r\n";
flush();
}

function subecho( $text )
{
echo " -->> $text\r\n";
flush();
}

supecho( "Starting semaphore testing..." );

// Start semaphore handling

$semaphoreID=   sem_get( 0xee3 , 1 , 0666 ); // Get a 
semaphore named "0xee3"

supecho( "Attempting to get a semaphore" );

if( $semaphoreID )
{
subecho( "success" );

supecho( "Attempt to obtain our shared memory segment" );

$testID =   shmop_open( 0xff3, "ac", 0, 0);

if( $testID ) // Already exists
{
subecho( "Success (opening with 'a' flag)" );

$sharedID   =   shmop_open( 0xff3, "a", 0, 0);
}
else // create it
{
subecho( "Does not exist..." );

supecho( "Attempting to create shared memory section 
with 'c' flag and 0xxf3 address" );

$sharedID   =   shmop_open( 0xff3, "c", 0644, 100);

if( $sharedID )
{
subecho( "Success" );
}
else
{
subecho( "Failure" );
}
}

if( $sharedID )
{
subecho( "Attempt to obtain a shared memory segment 
success" );

supecho( "Going for a semaphore acquisition" );

sem_acquire( $semaphoreID );

subecho( "Semaphore acquired" );

$myString   =   "a";

supecho( "Shared mem segment size (in bytes): 
".shmop_size( $sharedID ) );

supecho( "Starting to read total segment" );

$start  =   mtime();

subecho( "Reading shared memory segment into memory --| 
".shmop_read( $sharedID, 0, shmop_size( $sharedID ) ) );
subecho( ( ( shmop_size( $sharedID )) / ( mtime() - 
$start ) )." bytes/second" );

/* THIS WRITE STATEMENT 

[PHP-DEV] Bug #14784 Updated: shmop_write causes segfault

[mfischer]

ID: 14784
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux (RH 6.2 / 2.4.3)
PHP Version: 4.1.1
New Comment:

A backtrace without --enable-debug is pretty useless. Can you recompile and paste the 
backtrace again?

Also, please don't wrap the lines.

Previous Comments:


[2002-01-01 15:17:07] [EMAIL PROTECTED]

Sorry. I forgot to include the backtrace:

< start >

Program received signal SIGSEGV, Segmentation fault.
0x40103493 in memcpy (dstpp=0x40319000, srcpp=0x81ea42c, 
len=1) at ../sysdeps/generic/memcpy.c:61
61  ../sysdeps/generic/memcpy.c: No such file or 
directory.
(gdb) bt
#0  0x40103493 in memcpy (dstpp=0x40319000, srcpp=
0x81ea42c, len=1) at ../sysdeps/generic/memcpy.c:61
#1  0x40583745 in ?? () from /usr/local/apache/libexec/
libphp4.so
#2  0x4053f235 in ?? () from /usr/local/apache/libexec/
libphp4.so
#3  0x4054e22b in ?? () from /usr/local/apache/libexec/
libphp4.so
#4  0x4055f861 in ?? () from /usr/local/apache/libexec/
libphp4.so
#5  0x4055c1f2 in ?? () from /usr/local/apache/libexec/
libphp4.so
#6  0x4055cb56 in ?? () from /usr/local/apache/libexec/
libphp4.so
#7  0x4055cb88 in ?? () from /usr/local/apache/libexec/
libphp4.so
#8  0x80550f3 in ap_invoke_handler ()
#9  0x8069529 in process_request_internal ()
#10 0x806958c in ap_process_request ()
#11 0x8060a6e in child_main ()
#12 0x8060c20 in make_child ()
#13 0x8060d79 in startup_children ()
#14 0x80613d6 in standalone_main ()
#15 0x8061ba3 in main ()
#16 0x400bb9cb in __libc_start_main (main=0x806184c , 
argc=2, argv=0xba2c, init=0x804f47c <_init>, 
fini=0x809858c <_fini>, rtld_fini=0x4000aea0 <_dl_fini>
, stack_end=0xba24) at ../sysdeps/generic/libc-
start.c:92

< end >

  mjh



[2001-12-31 21:20:53] [EMAIL PROTECTED]

I have been experimenting with semaphores/shmop to provide 
query caching for an application I am working on. The 
purpose, of course, bears no bearing on the issue I am 
reporting however as I am just doing testing of the two 
extensions at this point.

I used this article as the starting point for my testing - 
http://zez.org/article/articleprint/46/.

So I put together this script:

--

function mtime()
{
return array_sum( explode( " ", microtime() ) );
}

function supecho( $text )
{
echo "$text\r\n";
flush();
}

function subecho( $text )
{
echo " -->> $text\r\n";
flush();
}

supecho( "Starting semaphore testing..." );

// Start semaphore handling

$semaphoreID=   sem_get( 0xee3 , 1 , 0666 ); // Get a 
semaphore named "0xee3"

supecho( "Attempting to get a semaphore" );

if( $semaphoreID )
{
subecho( "success" );

supecho( "Attempt to obtain our shared memory segment" );

$testID =   shmop_open( 0xff3, "ac", 0, 0);

if( $testID ) // Already exists
{
subecho( "Success (opening with 'a' flag)" );

$sharedID   =   shmop_open( 0xff3, "a", 0, 0);
}
else // create it
{
subecho( "Does not exist..." );

supecho( "Attempting to create shared memory section 
with 'c' flag and 0xxf3 address" );

$sharedID   =   shmop_open( 0xff3, "c", 0644, 100);

if( $sharedID )
{
subecho( "Success" );
}
else
{
subecho( "Failure" );
}
}

if( $sharedID )
{
subecho( "Attempt to obtain a shared memory segment 
success" );

supecho( "Going for a semaphore acquisition" );

sem_acquire( $semaphoreID );

subecho( "Semaphore acquired" );

$myString   =   "a";

supecho( "Shared mem segment size (in bytes): 
".shmop_size( $sharedID ) );

supecho( "Starting to read total segment" );

$start  =   mtime();

subecho( "

[PHP-DEV] Built-in SOAP based Web Services support (was Re: PHP 5)

[Manuel Lemos]

Hello,

Andi Gutmans wrote:
> 
> Hey,
> 
> The Zend Engine 2 has made lots of progress.
> I think we should have a discussion of what other things besides the
> scripting engine we'd like to change for PHP 5.
> I know there was talk on deprecating some stuff such as old-style function
> names, moving extensions to PECL etc.. I think it's a good time to start
> discussing some of these issues (hopefully we can keep things short :)
> Also, let's try and keep the scope to realistic changes which won't turn
> PHP upside down and which are doable within a relatively short period of
> time. I think it'd be really cool if we could get an alpha of PHP 5 out by
> Spring.

One thing that I think it is really vital to prevent PHP to leak even
more users to other languages is to have built-in support for consuming
Web services.

Why is this vital? Because Microsoft and other companies have been
working hard to making this built-in feature on the languages that they
support. So, now it is easy to point a program in such languages to a
WSDL file URL and the language makes the Web services interface
automatically available to the program as it it was accessing the
methods of a local class. If PHP does not make this as easy, we'll see a
lot of people leaving PHP for those other languages.

Why built-in support (and not some local user classes)? Because the
definition of the interface such Web services depends on the remote
server. There seems to not be a way to add an interface dynamically to
PHP, except for dynamically generating code for a class file and loading
it afterwards. It would work, but it would not as fast as it could and
it would not be a assumed as a built-in feature of PHP that users could
rely on its official support.

Why SOAP (and not XML-RPC for instance)? The technical merits of the
protocols are not very relevant in this circumstance. The truth is that
Microsoft and other companies have been pushing very hard for SOAP based
Web services. We are already seeing a lot of SOAP based services that
will never be available through XML-RPC because their authors only have
tools to create Web services via SOAP and not XML-RPC. Insisting on
XML-RPC just to be against Microsoft and their friends would be
counterproductive that is not what people that want to consume such Web
services need. Supporting both XML-RPC and SOAP would be nicer but
probably with little advantage in the end for the majority Web service
consumers. PHP already has built-in XML-RPC support that Sterling added.


So how would I see this SOAP based Web services work conviniently:

- A PHP function would take an URL for a WDSL file and dynamically added
a class that exposes public functions that when called would invoke the
remote Web services.

- The PHP user could either create an object of that class or extend it
with subclass. This way he could override the default methods for error
handling, logging and authentication. 


I don't think it is soon to add built-in support for Web services in
PHP, but I am afraid the later it is added, the more users will give up
on PHP for other languages with such support.

Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14784 Updated: shmop_write causes segfault

[Prottoss]

I found the reason behind your bug.

When you are checking if the segment exists or not you are using
$testID =   shmop_open( 0xff3, "ac", 0, 0);

instead of

$testID =   shmop_open( 0xff3, "a", 0, 0);

which simply tried to open the segment and will return FALSE if it fails.

Once I changed your code to mine, the segfault stopped appearing.

If you have any further questions you can email me, I am one of the shmop 
module authors. I believe the bug is occuring because you are passing an 
invalid flag to shmop_open(). I ask that someone would remove the misleading 
comment on shmop_open() page which tells people to use 'ac' flag to see if 
segment exists or not. Also, to whom should I submit a patch that will 
prevent this from happening in the future?

Prottoss
[EMAIL PROTECTED]
ICQ: 23361082
http://mediaminer.org/

On January 1, 2002 03:17 pm, [EMAIL PROTECTED] wrote:
> ID: 14784
> User updated by: [EMAIL PROTECTED]
> Reported By: [EMAIL PROTECTED]
> Status: Open
> Bug Type: Reproducible crash
> Operating System: Linux (RH 6.2 / 2.4.3)
> PHP Version: 4.1.1
> New Comment:


-- 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14783 Updated: Using unlink causes segfault

[mfkahn2]

ID: 14783
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: DOM XML related
Operating System: RH6.2/Apache/libxml2.4.12
PHP Version: CVS Jan. 1 2002
New Comment:

My configuration notes:

- PHP built as DSO, apache with disable-rule=EXPAT 

Here's my PHP build configuration:

./configure --with-pgsql --prefix=/usr/local/apache 
--with-apxs=/usr/local/apache/bin/apxs  --with-pdflib=shared  
--with-dom=/usr/local/lib --enable-xslt --with-xslt-sablot=/usr/local 
--with-expat=/usr/local --with-zlib --with-gd=/usr/local --with-jpeg-dir=/usr 
--with-png-dir=/usr --with-t1lib=/usr/local

Another note:

I didn't find issues every time I unlinked a node, only when I unlinked (it seems) all 
the nodes selected--either from an XPath query or a children() call.  And I noted that 
the did in fact occur during clean-up, not the unlink calls (no real debug, just 
through writing error_log messages at certain points in the PHP script).



Previous Comments:


[2002-01-01 12:45:41] [EMAIL PROTECTED]

Did the same before I replied and it didn't crash, hm.

What were your ./configure options?

Do you have another small, self-contained sample?

Feedback.



[2002-01-01 11:15:45] [EMAIL PROTECTED]

Just checked out and built from CVS this morning (2002/1/1).  The test script still 
crashes.  



[2002-01-01 07:11:54] [EMAIL PROTECTED]

This has been fixed in CVS.



[2001-12-31 16:16:27] [EMAIL PROTECTED]

Symptoms:
- using unlink() causes segfault

Script to reproduce:



Hello
World

END_XML;
$dom = xmldoc($xml);

// this so I can see it.
header('Content-type: text/plain');

$ctx = $dom->xpath_new_context();

$res = xpath_eval($ctx,"//foo");

foreach ($res->nodeset as $child) {
$child->unlink();
} 

echo $dom->dumpmem();
?>

Other notes:

- some cursory debugging I did suggested that it was the cleanup routines at the end 
of the script that were causing the crash.  Looking at php_domxml.c, the recursive 
node memory cleanup appears to be choking on a pointer already freed during the 
unlink() call.





Edit this bug report at http://bugs.php.net/?id=14783&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (was Re: PHP 5)

[Zeev Suraski]

At 22:24 01/01/2002, Manuel Lemos wrote:
>One thing that I think it is really vital to prevent PHP to leak even
>more users to other languages is to have built-in support for consuming
>Web services.

Manuel,

A friendly suggestion - you always sound as if the house is burning, the 
ceiling is collapsing , and soon enough all will be lost, unless a miracle 
happens.  While this may be true in your opinion, I can tell you that it 
doesn't have a very positive effect on the way your words are accepted by 
the users of this, or any other pro-PHP mailing list.  "If that's the 
truth, we don't want to hear it" sums it up pretty well, especially when 
most people here believe it's not the truth.

About SOAP and Web services - I agree with you that it would be very good 
to have built-in support for it in PHP.  However, suggesting this kind of 
ideas is usually pretty pointless, unless you're willing to actually do 
something about it.  I think the only time it worked in the past was when 
Sascha picked up the challenge of creating a session module for PHP, 
because PHP really needed one (kodus to Sascha on that) - but that's the 
exception to the rule.

I think Rasmus was looking into that a couple of months ago, btw.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (was Re:PHP 5)

[Derick Rethans]

On Tue, 1 Jan 2002, Zeev Suraski wrote:

> About SOAP and Web services - I agree with you that it would be very good
> to have built-in support for it in PHP.  However, suggesting this kind of
> ideas is usually pretty pointless, unless you're willing to actually do
> something about it.  I think the only time it worked in the past was when
> Sascha picked up the challenge of creating a session module for PHP,
> because PHP really needed one (kodus to Sascha on that) - but that's the
> exception to the rule.
>
> I think Rasmus was looking into that a couple of months ago, btw.

The project we are currently doing, SRM, works a lot like the things
you are describing, the only real difference is that we don't use SOAP as
transport protocol, but a bytestream protocol. However, adding a XPL-RPC
(or SOAP) layer is on the TODO list to. In the next few weeks, I'm going
to setup upp some demos, and release some of the code (the PHP extension)
so that other can play with it too a little.

If somebody has any questions, feel free to ask them on the SRM
mailinglists. ([EMAIL PROTECTED]).

Derick
The SRM-Team


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Built-in SOAP based Web Services support (was Re: PHP 5)

[Richard Heyes]

> However, suggesting this kind of
> ideas is usually pretty pointless, unless you're willing to actually do
> something about it.

Well Andi asked for discussion on ideas for php5. And these suggestions imo
are not pointless, as a developer may well pick up on them and start work on
them.

--
Richard Heyes
"If you have any trouble sounding condescending,
find a Unix user to show you how it's done." - Scott Adams


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Martin Jansen]

On Tue, 1 Jan 2002 19:55:33 +0100, Egon Schmid wrote:

>Are you sure that librians find the PEAR documentation? 

When they find the PHP documentation, they can also find the
PEAR documentation, no? :-)

>As I can see
>PEAR and PHP documentation differs in many things. 

What kind of differences are you talking about?

- Martin

-- 
  Martin Jansen, <[EMAIL PROTECTED]>
  http://www.martin-jansen.de/



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Moving extensions to PECL

[Martin Jansen]

On Tue, 1 Jan 2002 10:09:51 -0800, Jim Winstead wrote:

>i was thinking more along the lines of something that allowed the
>documentation for an extension to be managed on its own, 

Documentation somewhere is better than documentation nowhere ;-).

Anyways, I don't have a really strong opinion when it comes to
documentation for extensions that are moved over to PECL. If
people want to leave it in phpdoc that's ok for me.

- Martin

-- 
  Martin Jansen, <[EMAIL PROTECTED]>
  http://www.martin-jansen.de/



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Built-in SOAP based Web Services support (was Re: PHP 5)

[Zeev Suraski]

At 23:30 01/01/2002, Richard Heyes wrote:
> > However, suggesting this kind of
> > ideas is usually pretty pointless, unless you're willing to actually do
> > something about it.
>
>Well Andi asked for discussion on ideas for php5. And these suggestions imo
>are not pointless, as a developer may well pick up on them and start work on
>them.

It wasn't exactly a suggestion.  It was more like "unless you do it, PHP is 
going to be a useless piece of crap that nobody would use;  if you do it - 
it's still pretty hopeless, but just a tiny bit less".

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Built-in SOAP based Web Services support (was Re: PHP 5)

[Jim Winstead]

Manuel Lemos <[EMAIL PROTECTED]> wrote:
> One thing that I think it is really vital to prevent PHP to leak even
> more users to other languages is to have built-in support for consuming
> Web services.

http://aspn.activestate.com/ASPN/WebServices/SWSAPI/phptut

yes, that's not built-in. but dealing with xml in c is a grotty,
not-very-fun task. so not fun that i wouldn't hold my breath waiting for
a built-in implementation to materialize because someone decided to
knock one together. like the xmlrpc implementation now included with
php4, i suspect you'll have to wait for some corporate interest to
decide they need a high-performance soap implementation for php before
one shows up.

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Manuel Lemos]

Hello,

Zeev Suraski wrote:
> 
> At 22:24 01/01/2002, Manuel Lemos wrote:
> >One thing that I think it is really vital to prevent PHP to leak even
> >more users to other languages is to have built-in support for consuming
> >Web services.
> 
> Manuel,
> 
> A friendly suggestion - you always sound as if the house is burning, the
> ceiling is collapsing , and soon enough all will be lost, unless a miracle
> happens.  While this may be true in your opinion, I can tell you that it
> doesn't have a very positive effect on the way your words are accepted by
> the users of this, or any other pro-PHP mailing list.  "If that's the
> truth, we don't want to hear it" sums it up pretty well, especially when
> most people here believe it's not the truth.

What you are saying is that when I make a suggestion people become
emotional and work very hard to raise as much objections as they can
instead of staying rational and try to see the benefits of the
suggestion.


 
> About SOAP and Web services - I agree with you that it would be very good
> to have built-in support for it in PHP.  However, suggesting this kind of
> ideas is usually pretty pointless, unless you're willing to actually do
> something about it.  I think the only time it worked in the past was when
> Sascha picked up the challenge of creating a session module for PHP,
> because PHP really needed one (kodus to Sascha on that) - but that's the
> exception to the rule.

Honestly I don't expect you to follow any suggestion I make.
Disconsidering my suggestions works more against you than to me because
you are the one that is making money from PHP development. What I am
trying to say is that sooner or later you will realize how silly it is
to spend so much effort in contradicting me or otherwise overrule my
suggestions.

You seem to forget that this is a forum where at least a few thousand
users are not saying anything but they are paying close attention to
everything that is said. Seeing my (and also of many others) sugestions
being disconsidered just like you systematically do, you are only
discouraging others to step up and also present their suggestions. Of
course you will disagree because your behaviour became more and more
predictable over time.

 
> I think Rasmus was looking into that a couple of months ago, btw.

Anything came out of it? Rasmus?
 
Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (was Re:PHP 5)

[Manuel Lemos]

Hello,

Derick Rethans wrote:
> 
> On Tue, 1 Jan 2002, Zeev Suraski wrote:
> 
> > About SOAP and Web services - I agree with you that it would be very good
> > to have built-in support for it in PHP.  However, suggesting this kind of
> > ideas is usually pretty pointless, unless you're willing to actually do
> > something about it.  I think the only time it worked in the past was when
> > Sascha picked up the challenge of creating a session module for PHP,
> > because PHP really needed one (kodus to Sascha on that) - but that's the
> > exception to the rule.
> >
> > I think Rasmus was looking into that a couple of months ago, btw.
> 
> The project we are currently doing, SRM, works a lot like the things
> you are describing, the only real difference is that we don't use SOAP as
> transport protocol, but a bytestream protocol. However, adding a XPL-RPC
> (or SOAP) layer is on the TODO list to. In the next few weeks, I'm going
> to setup upp some demos, and release some of the code (the PHP extension)
> so that other can play with it too a little.

I don't think what I suggested is anyway related. What I suggested is
way built-in PHP to consume remote Web services provided via SOAP. What
you have is session data manager working in a controlled client-server
architechture. The service you provide is very specific. Web services
are defined by remote providers.

If you already have a bytestream protocol for exchanging session data
between the client and the server, I doubt that a XML-RPC or a SOAP
transport layer would provide any advantage. It would make data
marshalling and exchaging slower without providing any extra flexibility
( I think).

Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Manuel Lemos]

Hello,

Zeev Suraski wrote:
> 
> At 23:30 01/01/2002, Richard Heyes wrote:
> > > However, suggesting this kind of
> > > ideas is usually pretty pointless, unless you're willing to actually do
> > > something about it.
> >
> >Well Andi asked for discussion on ideas for php5. And these suggestions imo
> >are not pointless, as a developer may well pick up on them and start work on
> >them.
> 
> It wasn't exactly a suggestion.  It was more like "unless you do it, PHP is
> going to be a useless piece of crap that nobody would use;  if you do it -
> it's still pretty hopeless, but just a tiny bit less".

Of course you may interpret it the way you want, but I described a
feature that PHP does not have and even suggested an implementation
format. Since I already noticed several people dropping PHP to do simple
things such as consuming a Web service because there much better
alternatives for this purpose, I added that I am afraid that this trend
of dropping PHP for the lack of support like this will be more evident
soon or later. Of course you may continue to disconsider my suggestions
as you usually do.

Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Sean R. Bright]

Manuel:

Is there something stopping you from implementing this?

Sean

> -Original Message-
> From: Manuel Lemos [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 01, 2002 5:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Built-in SOAP based Web Services 
> support (wasRe:
> PHP 5)
> 
> 
> Hello,
> 
> Zeev Suraski wrote:
> > 
> > At 23:30 01/01/2002, Richard Heyes wrote:
> > > > However, suggesting this kind of
> > > > ideas is usually pretty pointless, unless you're 
> willing to actually do
> > > > something about it.
> > >
> > >Well Andi asked for discussion on ideas for php5. And 
> these suggestions imo
> > >are not pointless, as a developer may well pick up on them 
> and start work on
> > >them.
> > 
> > It wasn't exactly a suggestion.  It was more like "unless 
> you do it, PHP is
> > going to be a useless piece of crap that nobody would use;  
> if you do it -
> > it's still pretty hopeless, but just a tiny bit less".
> 
> Of course you may interpret it the way you want, but I described a
> feature that PHP does not have and even suggested an implementation
> format. Since I already noticed several people dropping PHP 
> to do simple
> things such as consuming a Web service because there much better
> alternatives for this purpose, I added that I am afraid that 
> this trend
> of dropping PHP for the lack of support like this will be more evident
> soon or later. Of course you may continue to disconsider my 
> suggestions
> as you usually do.
> 
> Regards,
> Manuel Lemos
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: 
> [EMAIL PROTECTED]
> 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Built-in SOAP based Web Services support (was Re: PHP 5)

[Manuel Lemos]

Hello,

Jim Winstead wrote:
> 
> Manuel Lemos <[EMAIL PROTECTED]> wrote:
> > One thing that I think it is really vital to prevent PHP to leak even
> > more users to other languages is to have built-in support for consuming
> > Web services.
> 
> http://aspn.activestate.com/ASPN/WebServices/SWSAPI/phptut
> 
> yes, that's not built-in. but dealing with xml in c is a grotty,
> not-very-fun task. so not fun that i wouldn't hold my breath waiting for
> a built-in implementation to materialize because someone decided to
> knock one together. like the xmlrpc implementation now included with
> php4, i suspect you'll have to wait for some corporate interest to
> decide they need a high-performance soap implementation for php before
> one shows up.

Of course I know I there are a few PHP SOAP client implementations. I
happed to have my own as well. The key of the suggestion was to have
this built-in just like several other languages have and PHP does not
have until someone opens their eyes and realize the importance of having
this built-in. It is very good the analogy that Zeev made with built-in
session support that ASP always had and PHP hadn't until somebody
(Sascha?) bothered to make it happen as a built-in feature. I don't
think it was added because there was some corporate interest in high
performance session support.

Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Manuel Lemos]

Hello,

"Sean R. Bright" wrote:
> 
> Manuel:
> 
> Is there something stopping you from implementing this?

Yes, free time to motivate me to stop working on other developments from
which I can make a living.

Another thing, it has been a while (more than 2 years) since I decided
to not dedicate my developments wholly to PHP. I have been working on a
meta-programming language that lets me write software that can be
compiled to generate code in different languages: PHP, Java, Perl,
etc... This means whatever I write in that meta-language can be used not
just withing PHP programs but also programs in other languages.
I think that constraining myself just to PHP will limit the
possibilities and the future of my software developments.

I already have some SOAP components written in this meta-language. If I
work on something that would make it easier to provide and consume Web
servers (and I have been doing some work), I will invest my time better
on doing it with this meta-language rather than something that is PHP
specific.

If you care about this meta-language, look here:
http://www.meta-language.net/ .

Anyway, notice that my suggestion was just made because Andi asked for
suggestions and I thing built-in Web services consuption support is
important for PHP and not because I have a special need for that.


Regards,
Manuel Lemos

> 
> Sean
> 
> > -Original Message-
> > From: Manuel Lemos [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 01, 2002 5:54 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PHP-DEV] Built-in SOAP based Web Services
> > support (wasRe:
> > PHP 5)
> >
> >
> > Hello,
> >
> > Zeev Suraski wrote:
> > >
> > > At 23:30 01/01/2002, Richard Heyes wrote:
> > > > > However, suggesting this kind of
> > > > > ideas is usually pretty pointless, unless you're
> > willing to actually do
> > > > > something about it.
> > > >
> > > >Well Andi asked for discussion on ideas for php5. And
> > these suggestions imo
> > > >are not pointless, as a developer may well pick up on them
> > and start work on
> > > >them.
> > >
> > > It wasn't exactly a suggestion.  It was more like "unless
> > you do it, PHP is
> > > going to be a useless piece of crap that nobody would use;
> > if you do it -
> > > it's still pretty hopeless, but just a tiny bit less".
> >
> > Of course you may interpret it the way you want, but I described a
> > feature that PHP does not have and even suggested an implementation
> > format. Since I already noticed several people dropping PHP
> > to do simple
> > things such as consuming a Web service because there much better
> > alternatives for this purpose, I added that I am afraid that
> > this trend
> > of dropping PHP for the lack of support like this will be more evident
> > soon or later. Of course you may continue to disconsider my
> > suggestions
> > as you usually do.
> >
> > Regards,
> > Manuel Lemos
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail:
> > [EMAIL PROTECTED]
> >

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14789 Updated: _SERVER["REQUEST_URI"] not fully given to Caudium 1.0.34

[delahaye]

ID: 14789
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Other web server
Operating System: FreeBSD / Linux
PHP Version: 4.1.1
New Comment:

Note that it's probably the same bug than http://bugs.php.net/bug.php?id=10159 , 
though.

Previous Comments:


[2002-01-01 10:36:39] [EMAIL PROTECTED]

REQUEST_URI is an apache specific variable. no bug ->bogus.



[2002-01-01 09:56:13] [EMAIL PROTECTED]

When using PHP 4 with Caudium, the $REQUEST_URI / _SERVER["REQUEST_URI"] var is not 
full.

For example, look at this phpinfo(): http://aleph1.net/test.php3/toto/a=b&c=d

You get the following line :
_SERVER["REQUEST_URI"] /test.php3  

It should have been : 
_SERVER["REQUEST_URI"] /test.php3/toto/a=b&c=d





Edit this bug report at http://bugs.php.net/?id=14789&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10159 Updated: bug with Caudium 1.0.2RC2

[mfischer]

ID: 10159
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Other web server
Operating System: FreeBsd 4.1
PHP Version: 4.0.4pl1
New Comment:

Until you come up with a concrete problem this is bogus.

Previous Comments:


[2001-04-04 10:53:45] [EMAIL PROTECTED]

The php support Caudium (roxen) server (the pike module)
seems to be very buggy !! For example , phpNuke website
based or phpmyadmin interface should not work !!
Simple php pages work as  Well.  There is certainly
a problem with include files, ...






Edit this bug report at http://bugs.php.net/?id=10159&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] SOAP and CORBA

[Nick Loman]

Hello PHP developers,

Interesting to think about what might make a nice foundation technology 
for all the exciting potential of PHP5. SOAP is obviously an important
technology for websites in the future. But given that (I guess) most of us
are not really that keen to follow in the nervous footsteps of Microsoft, 
and given that XML brings me out in a horrible rash, why don't we think
about CORBA as a fundamental PHP technology?

CORBA is now finally in a state where people can actually use it
without running away screaming. There are now enough free implementations
on enough platforms to enable mainstream PHP support. David Eriksson
has done some nice stuff with Universe/Satellite, but I don't think PHP's
CORBA support is currentl "plug n' go" enough to really be capitalised on
(it currently relies on a fair amount of knowledge of CORBA).

What would be fantastic is a situation where newbie PHP coders feel
confident enough to use CORBA services exposed to the Internet (not many
exist at the moment, the "classic" example is Random.org but this
could change). If it was easy enough to start interacting with ORBs
exposed to the 'Net, and it was easy enough for PHP developers to write
their own net-facing ORBs, we could potentially be facing an interesting
paradigm shift whereby PHP users are exposing their interesting objects
(which may, e.g. provide access to databases, content) to the 'net. Much
sexier than say RDF, no?

If anyone would like to help me in my quest to make CORBA more mainstream
(CORBA isn't really scary, at its most basic its just cross-platform
remote procedure calls) I would love to work with you.

All the best for 2002 everyone,

Nick.







-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SOAP and CORBA

[Markus Fischer]

No one will stop you from implementing it. And it is
certainly an advantage for PHP.

-- 
Please always Cc to me when replying to me on the lists.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14792: PHP fails to complie becuase of libphp4.a error

[djoutlaw23]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.1
PHP Bug Type: Compile Failure
Bug description:  PHP fails to complie becuase of libphp4.a error

This fails to complie because in the apache/src/modules/php4

libphp4.a is named incorrectly.  It is named libmodphp4.a

If you change the name it will finish the compile.



Thanks
-- 
Edit bug report at: http://bugs.php.net/?id=14792&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14792 Updated: PHP fails to complie becuase of libphp4.a error

[mfischer]

ID: 14792
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 4.1.1
New Comment:

Too less information. Which distribution? Which configure line? What's the exact error 
output (copy & paste)? 

Previous Comments:


[2002-01-01 20:04:30] [EMAIL PROTECTED]

This fails to complie because in the apache/src/modules/php4

libphp4.a is named incorrectly.  It is named libmodphp4.a

If you change the name it will finish the compile.



Thanks





Edit this bug report at http://bugs.php.net/?id=14792&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Zeev Suraski]

At 00:34 02/01/2002, Manuel Lemos wrote:
>What you are saying is that when I make a suggestion people become
>emotional and work very hard to raise as much objections as they can
>instead of staying rational and try to see the benefits of the
>suggestion.

It's about how you make the suggestions, Manuel.  "vital to prevent PHP to 
leak even
more users to other languages" is a pretty annoying sentence to read.  In 
case you're not sure what it means - it means that:
(a) PHP is 'leaking' lots of users today
(b) If we do it, it'll go on leaking as it does today
(c) If we don't - it'll leak even more

If people indeed become emotional about suggestions you make (I certainly 
don't) then you probably have earned it yourself.

At any rate - I did not contradict you.  On the contrary, I said I think 
it's important, even very important.  I'm saying that the position you 
usually take, which is kind-of like the biblical prophets telling everybody 
they're wrong and what they must do to prevent hell from breaking loose, 
isn't one that's going to earn you much interest in your ideas.  You may 
try the positive approach instead, especially if you're just pitching an 
idea for somebody else to implement, with no intention of doing anything 
about it yourself.

You think that my behavior is so predictable, you didn't even appear to 
read what I said.  If it wasn't too transparent I'd be saying that it was 
your response which was quite predictable - you always do that when people 
don't cry in joy in the sound of your ideas...

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14792 Updated: PHP fails to complie becuase of libphp4.a error

[djoutlaw23]

ID: 14792
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 4.1.1
New Comment:

Sorry I cant post the error message since I fixed it and complied PHP4 fully. 

Version is 4.1.1 just downloaded it today
Sever is Apache 1.3.20 for Linux

If you try and complie Apache for php with this command
./configure --activate-module=src/modules/php4/libphp4.a
13. 

you will get an error that libphp4.a can not be found.

This is due to libphp4.a being named libmodphp4.a
after you have did a make install on php only.

I dotn know if this confuses people but if you follow the install straight php.net you 
will notice the error.

In linux you must go to the /apache_1.3.X/src/modules/php4
and you will find the libmodphp4.a file change the name and it should finish the 
complie



Previous Comments:


[2002-01-01 20:22:44] [EMAIL PROTECTED]

Too less information. Which distribution? Which configure line? What's the exact error 
output (copy & paste)? 



[2002-01-01 20:04:30] [EMAIL PROTECTED]

This fails to complie because in the apache/src/modules/php4

libphp4.a is named incorrectly.  It is named libmodphp4.a

If you change the name it will finish the compile.



Thanks





Edit this bug report at http://bugs.php.net/?id=14792&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14779 Updated: mail() on win2k not parsing Cc: properly

[irc-html]

ID: 14779
Updated by: irc-html
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Duplicate
Bug Type: Mail related
Operating System: Win2k
PHP Version: 4.1.1
New Comment:

I see there are already several of the same reports.

Status:  Duplicate

Previous Comments:


[2001-12-31 00:22:07] [EMAIL PROTECTED]

Want to send an e-mail to 2 e-mail addresses, one normal To: and other Cc:.  Simple 
script works on linux but not on win2k:

$headers = "Cc: <[EMAIL PROTECTED]>\r\n";
$headers .= "From: \"Program Test\" <[EMAIL PROTECTED]>\r\n";
mail('<[EMAIL PROTECTED]>', 'subject', 'message', $headers);

SMTP server is qmail.  Email successfully sent to To: address but Cc header in message 
to Cc address (Cc address never receives email, drops to 'catch-all' account) ends up 
to be:

Delivered-To: cc: <[EMAIL PROTECTED]

Note the cc: and the dropped '>'.

I'm assuming this is a bug with the mail handler in PHP with win32.  I've also tried 
the same code without surrounding the e-mail addresses with <>.

Same behavior with 4.0.6 (on win32).





Edit this bug report at http://bugs.php.net/?id=14779&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe:PHP 5)

[Manuel Lemos]

Hello,

Zeev Suraski wrote:
> 
> At 00:34 02/01/2002, Manuel Lemos wrote:
> >What you are saying is that when I make a suggestion people become
> >emotional and work very hard to raise as much objections as they can
> >instead of staying rational and try to see the benefits of the
> >suggestion.
> 
> It's about how you make the suggestions, Manuel.  "vital to prevent PHP to
> leak even
> more users to other languages" is a pretty annoying sentence to read.  In
> case you're not sure what it means - it means that:
> (a) PHP is 'leaking' lots of users today

True. I don't know how many, but I know it is happening.


> (b) If we do it, it'll go on leaking as it does today

False, if you do it you will give one less reason for users to drop PHP.


> (c) If we don't - it'll leak even more

True, that is for sure.  Microsoft has been very successful despite many
legal difficulties. Now that they are basically gone, this year will be
probably a blast for them. A lot of people will be giving them even more
credit than before. I am not blaming them. What I am saying is that PHP
will be lagging way behind if it still does not catch up on the new
really good features that Microsoft has been building into them.

Microsoft is not all, Borland Delphi/Kylix has been going through the
route of betting the farm on Web services that they even advertise it.
Furthermore, they can build full applications and Apache server modules
like Perl making Web applications running at full speed, which is a
thing that PHP never provided.


 
> If people indeed become emotional about suggestions you make (I certainly
> don't) then you probably have earned it yourself.

Even if that is true, one thing that you still not get it, is that two
wrongs do not make it right. This means in practice that because I made
the suggestions you work very hard to justify not accepting them or at
least putting them in practice, even if the ones to benefit most from
what I suggested are you and not me. Yeah, getting emotional makes you
act against yourself.


 
> At any rate - I did not contradict you.  On the contrary, I said I think
> it's important, even very important.  I'm saying that the position you
> usually take, which is kind-of like the biblical prophets telling everybody
> they're wrong and what they must do to prevent hell from breaking loose,
> isn't one that's going to earn you much interest in your ideas.  You may
> try the positive approach instead, especially if you're just pitching an
> idea for somebody else to implement, with no intention of doing anything
> about it yourself.
> 
> You think that my behavior is so predictable, you didn't even appear to
> read what I said.  If it wasn't too transparent I'd be saying that it was
> your response which was quite predictable - you always do that when people
> don't cry in joy in the sound of your ideas...

You are still not getting it, I don't have a problem when people do not
accept my ideais. My problem only happens when arises when people invent
forced excuses for not accepting my ideas or at least to not put them in
practice.

It is like Richard Heyes said very well,

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14793: Setlocale not working for Japanese

[danradigan]

From: [EMAIL PROTECTED]
Operating system: Redhat Linux 7.1 J edition
PHP version:  4.0.6
PHP Bug Type: Strings related
Bug description:  Setlocale not working for Japanese

When I set setlocale ("LC_ALL", "ja_JP") and then call the function print
(strftime ("%A.\n")), japanese format dates do not appear.  I do get the Y
character with monies though.

When I run the code below, I do not get compete info for the Japanese
locale. 

setlocale(LC_ALL, "en_US");

$locale_info = localeconv();

echo "\n";
echo "\n";
echo "  Monetary information for current locale:  \n";
echo "\n\n";

echo "int_curr_symbol:   {$locale_info["int_curr_symbol"]}\n";
echo "currency_symbol:   {$locale_info["currency_symbol"]}\n";
echo "mon_decimal_point: {$locale_info["mon_decimal_point"]}\n";
echo "mon_thousands_sep: {$locale_info["mon_thousands_sep"]}\n";
echo "positive_sign: {$locale_info["positive_sign"]}\n";
echo "negative_sign: {$locale_info["negative_sign"]}\n";
echo "int_frac_digits:   {$locale_info["int_frac_digits"]}\n";
echo "frac_digits:   {$locale_info["frac_digits"]}\n";
echo "p_cs_precedes: {$locale_info["p_cs_precedes"]}\n";
echo "p_sep_by_space:{$locale_info["p_sep_by_space"]}\n";
echo "n_cs_precedes: {$locale_info["n_cs_precedes"]}\n";
echo "n_sep_by_space:{$locale_info["n_sep_by_space"]}\n";
echo "p_sign_posn:   {$locale_info["p_sign_posn"]}\n";
echo "n_sign_posn:   {$locale_info["n_sign_posn"]}\n";
echo "\n";
 
 
 
 
-- 
Edit bug report at: http://bugs.php.net/?id=14793&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14784 Updated: shmop_write causes segfault

[markhers]

ID: 14784
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating System: Linux (RH 6.2 / 2.4.3)
PHP Version: 4.1.1
New Comment:

Backtrace with --with-debug:

==

Program received signal SIGSEGV, Segmentation fault.
0x40103487 in memcpy (dstpp=0x4040a000, srcpp=0x81f990c, 
len=96) at ../sysdeps/generic/memcpy.c:55
55  ../sysdeps/generic/memcpy.c: No such file or 
directory.
(gdb) bt
#0  0x40103487 in memcpy (dstpp=0x4040a000, srcpp=
0x81f990c, len=96) at ../sysdeps/generic/memcpy.c:55
#1  0x40285c37 in zif_arsort (ht=3, return_value=0x81f96bc, 
this_ptr=0x0, return_value_used=1) at array.c:444
#2  0x4022df34 in execute (op_array=0x81eeb74) at ./
zend_execute.c:1799
#3  0x4024051b in zend_parse_arg_impl (arg=0x8, va=0x0, 
spec=0x3) at zend_API.c:387
#4  0x40252582 in php_fopen_primary_script (file_handle=
0xb704) at fopen_wrappers.c:305
#5  0x4024d50e in should_overwrite_per_dir_entry 
(orig_per_dir_entry=0x8122fec, new_per_dir_entry=0x0) at 
mod_php4.c:646
#6  0x4024e350 in zm_info_apache (zend_module=0x8122fec) at 
php_apache.c:289
#7  0x4024e3cc in zif_virtual (ht=135409644, return_value=
0x805d55c, this_ptr=0x1f4, return_value_used=23) at 
php_apache.c:315
#8  0x80550f3 in ap_invoke_handler ()
#9  0x8069529 in process_request_internal ()
#10 0x806958c in ap_process_request ()
#11 0x8060a6e in child_main ()
#12 0x8060c20 in make_child ()
#13 0x8060d79 in startup_children ()
#14 0x80613d6 in standalone_main ()
#15 0x8061ba3 in main ()
#16 0x400bb9cb in __libc_start_main (main=0x806184c , 
argc=2, argv=0xba1c, init=0x804f47c <_init>, 
fini=0x809858c <_fini>, rtld_fini=0x4000aea0 <_dl_fini>
, stack_end=0xba14) at ../sysdeps/generic/libc-
start.c:92

===

And it's not me who's wrapping the text...

Previous Comments:


[2002-01-01 15:19:08] [EMAIL PROTECTED]

A backtrace without --enable-debug is pretty useless. Can you recompile and paste the 
backtrace again?

Also, please don't wrap the lines.



[2002-01-01 15:17:07] [EMAIL PROTECTED]

Sorry. I forgot to include the backtrace:

< start >

Program received signal SIGSEGV, Segmentation fault.
0x40103493 in memcpy (dstpp=0x40319000, srcpp=0x81ea42c, 
len=1) at ../sysdeps/generic/memcpy.c:61
61  ../sysdeps/generic/memcpy.c: No such file or 
directory.
(gdb) bt
#0  0x40103493 in memcpy (dstpp=0x40319000, srcpp=
0x81ea42c, len=1) at ../sysdeps/generic/memcpy.c:61
#1  0x40583745 in ?? () from /usr/local/apache/libexec/
libphp4.so
#2  0x4053f235 in ?? () from /usr/local/apache/libexec/
libphp4.so
#3  0x4054e22b in ?? () from /usr/local/apache/libexec/
libphp4.so
#4  0x4055f861 in ?? () from /usr/local/apache/libexec/
libphp4.so
#5  0x4055c1f2 in ?? () from /usr/local/apache/libexec/
libphp4.so
#6  0x4055cb56 in ?? () from /usr/local/apache/libexec/
libphp4.so
#7  0x4055cb88 in ?? () from /usr/local/apache/libexec/
libphp4.so
#8  0x80550f3 in ap_invoke_handler ()
#9  0x8069529 in process_request_internal ()
#10 0x806958c in ap_process_request ()
#11 0x8060a6e in child_main ()
#12 0x8060c20 in make_child ()
#13 0x8060d79 in startup_children ()
#14 0x80613d6 in standalone_main ()
#15 0x8061ba3 in main ()
#16 0x400bb9cb in __libc_start_main (main=0x806184c , 
argc=2, argv=0xba2c, init=0x804f47c <_init>, 
fini=0x809858c <_fini>, rtld_fini=0x4000aea0 <_dl_fini>
, stack_end=0xba24) at ../sysdeps/generic/libc-
start.c:92

< end >

  mjh



[2001-12-31 21:20:53] [EMAIL PROTECTED]

I have been experimenting with semaphores/shmop to provide 
query caching for an application I am working on. The 
purpose, of course, bears no bearing on the issue I am 
reporting however as I am just doing testing of the two 
extensions at this point.

I used this article as the starting point for my testing - 
http://zez.org/article/articleprint/46/.

So I put together this script:

--

function mtime()
{
return array_sum( explode( " ", microtime() ) );
}

function supecho( $text )
{
echo "$text\r\n";
flush();
}

function subecho( $text )
{
echo " -->> $text\r\n";
flush();
}

supecho( "Starting semaphore testing..." );

// Start semaphore handling

$semaphoreID=   sem_get( 0xee3 , 1 , 0666 ); // Get a 
semaphore named "0xee3"

supecho( "Attempting to get a semaphore" );

if( $semaphoreID )
{
subecho( "success" );

supecho( "Attempt to obtain 

Re: [PHP-DEV] SOAP and CORBA

[Andi Gutmans]

At 12:44 AM 1/2/2002 +, Nick Loman wrote:

>Hello PHP developers,
>
>Interesting to think about what might make a nice foundation technology
>for all the exciting potential of PHP5. SOAP is obviously an important
>technology for websites in the future. But given that (I guess) most of us
>are not really that keen to follow in the nervous footsteps of Microsoft,
>and given that XML brings me out in a horrible rash, why don't we think
>about CORBA as a fundamental PHP technology?
>
>CORBA is now finally in a state where people can actually use it
>without running away screaming. There are now enough free implementations
>on enough platforms to enable mainstream PHP support. David Eriksson
>has done some nice stuff with Universe/Satellite, but I don't think PHP's
>CORBA support is currentl "plug n' go" enough to really be capitalised on
>(it currently relies on a fair amount of knowledge of CORBA).
>
>What would be fantastic is a situation where newbie PHP coders feel
>confident enough to use CORBA services exposed to the Internet (not many
>exist at the moment, the "classic" example is Random.org but this
>could change). If it was easy enough to start interacting with ORBs
>exposed to the 'Net, and it was easy enough for PHP developers to write
>their own net-facing ORBs, we could potentially be facing an interesting
>paradigm shift whereby PHP users are exposing their interesting objects
>(which may, e.g. provide access to databases, content) to the 'net. Much
>sexier than say RDF, no?
>
>If anyone would like to help me in my quest to make CORBA more mainstream
>(CORBA isn't really scary, at its most basic its just cross-platform
>remote procedure calls) I would love to work with you.
>
>All the best for 2002 everyone,

We are going to try to improve the object overloading in ZE2 so I suggest 
not working on this before we see what we can come up with. Basically we 
are just trying to make it easier for people to overload objects from C and 
make it a bit more powerful.
In the meanwhile you can still play around with different Corba 
implementations and choose how you're going to do it but I suggest waiting 
because it'll hopefully save you lots of headaches.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Andi Gutmans]

At 09:13 PM 1/1/2002 -0200, Manuel Lemos wrote:
>I already have some SOAP components written in this meta-language. If I
>work on something that would make it easier to provide and consume Web
>servers (and I have been doing some work), I will invest my time better
>on doing it with this meta-language rather than something that is PHP
>specific.

It's a shame that if you have something good that you're not willing to 
share it with the PHP community.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe:PHP 5)

[Manuel Lemos]

Hello,

Andi Gutmans wrote:
> 
> At 09:13 PM 1/1/2002 -0200, Manuel Lemos wrote:
> >I already have some SOAP components written in this meta-language. If I
> >work on something that would make it easier to provide and consume Web
> >servers (and I have been doing some work), I will invest my time better
> >on doing it with this meta-language rather than something that is PHP
> >specific.
> 
> It's a shame that if you have something good that you're not willing to
> share it with the PHP community.

You must have got me wrong. I already released a SOAP server base class
that lets implement SOAP services in PHP just by subclassing it and
implementing the specific methods that provide your Web services without
having to worry with the complications of SOAP protocol. This class was
written in MetaL but the PHP version generated by MetaL compiler was
made available here last year:

http://phpclasses.upperdesign.com/browse.html/package/251

This class does not generate a WSDL definition but it was suficient to
write this SOAP interface to ezmlm. I needed this for a project where I
needed a programatic way to remotely count how many subscribers there
are in a list, subscribe, unsubscribe and verify if a subscriber is
already subscribed. These classes were also written in MetaL but the PHP
version is available here:

http://phpclasses.upperdesign.com/browse.html/package/177

As you may see here, I have been sharing a lot:

http://phpclasses.upperdesign.com/browse.html/top/

http://phpclasses.upperdesign.com/browse.html/author/1

Half of the questions I have been sharing here were written in MetaL,
despite that is irrelevant for people that been using them because they
only see PHP code and HTML documentation (documentation was
automatically generated from MetaL source).

As for MetaL itself, it is not yet ready for release because I am still
working on unexpected challenges to make it fit Java limitations, but
the goal is to release it as an Open Source project after I finish make
the proof of concept that is generating programs from MetaL source code
into several languages (PHP, Java and Perl) and demonstrate that they
work seeminglessly. After 2 years and a half of development that is
about to happen in a matter of a few weeks.

Meanwhile I already presented MetaL in O'Reilly Open Source Conference
2001 in San Diego and PHP Conference 2001 in Frankfurt. The slides of
the presentations are available here:

http://www.meta-language.net/

Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SOAP and CORBA

[Manuel Lemos]

Hello,

Andi Gutmans wrote:
> 
> At 12:44 AM 1/2/2002 +, Nick Loman wrote:
> 
> >Hello PHP developers,
> >
> >Interesting to think about what might make a nice foundation technology
> >for all the exciting potential of PHP5. SOAP is obviously an important
> >technology for websites in the future. But given that (I guess) most of us
> >are not really that keen to follow in the nervous footsteps of Microsoft,
> >and given that XML brings me out in a horrible rash, why don't we think
> >about CORBA as a fundamental PHP technology?
> >
> >CORBA is now finally in a state where people can actually use it
> >without running away screaming. There are now enough free implementations
> >on enough platforms to enable mainstream PHP support. David Eriksson
> >has done some nice stuff with Universe/Satellite, but I don't think PHP's
> >CORBA support is currentl "plug n' go" enough to really be capitalised on
> >(it currently relies on a fair amount of knowledge of CORBA).
> >
> >What would be fantastic is a situation where newbie PHP coders feel
> >confident enough to use CORBA services exposed to the Internet (not many
> >exist at the moment, the "classic" example is Random.org but this
> >could change). If it was easy enough to start interacting with ORBs
> >exposed to the 'Net, and it was easy enough for PHP developers to write
> >their own net-facing ORBs, we could potentially be facing an interesting
> >paradigm shift whereby PHP users are exposing their interesting objects
> >(which may, e.g. provide access to databases, content) to the 'net. Much
> >sexier than say RDF, no?
> >
> >If anyone would like to help me in my quest to make CORBA more mainstream
> >(CORBA isn't really scary, at its most basic its just cross-platform
> >remote procedure calls) I would love to work with you.
> >
> >All the best for 2002 everyone,
> 
> We are going to try to improve the object overloading in ZE2 so I suggest
> not working on this before we see what we can come up with. Basically we
> are just trying to make it easier for people to overload objects from C and
> make it a bit more powerful.
> In the meanwhile you can still play around with different Corba
> implementations and choose how you're going to do it but I suggest waiting
> because it'll hopefully save you lots of headaches.

Yes, adding and maintaining static CORBA interfaces is an hell to deal
with IDL compilers and stuff, but I think dynamic invocation fits well
with the nature of PHP.

You may want to talk with Lukas Smith and Gavin Sherry as I heard them
talking about adding some kind of CORBA support to PHP.

Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 5

[Sebastian Bergmann]

Andi Gutmans wrote:
> I think we should have a discussion of what other things besides the
> scripting engine we'd like to change for PHP 5.

  I think an important issue would be to make extensions thread-safe,
  where possible.

  configure should be modified to throw warnings if non thread-safe
  extensions are about to be built when thread-safety is enabled.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 5

[Manuel Lemos]

Hello,

Sebastian Bergmann wrote:
> 
> Andi Gutmans wrote:
> > I think we should have a discussion of what other things besides the
> > scripting engine we'd like to change for PHP 5.
> 
>   I think an important issue would be to make extensions thread-safe,
>   where possible.
> 
>   configure should be modified to throw warnings if non thread-safe
>   extensions are about to be built when thread-safety is enabled.

Good suggestion! I bet your next suggestion is to add thread creation
that works under Unix and Windows! I know it is tricky, but it is about
time because other languages like Perl, Java, Python, etc.. already have
thread support. :-)

Regards,
Manuel Lemos

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Björn Schotte]

* Andi Gutmans wrote:
> It's a shame that if you have something good that you're not willing to 
> share it with the PHP community.

There are other PHP SOAP implementations out there.
http://dietrich.ganx4.com/soapx4/

-- 
Sichere PHP Applikationen / Notfall-Consulting mit der
PHP Feuerwehr / Code inspection / Code rehearsal / API
Checkup.   mailto:[EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 5

[Sebastian Bergmann]

Manuel Lemos wrote:
> Good suggestion!

  Thanks.

> I bet your next suggestion is to add thread creation that works under
> Unix and Windows!

  Hm, no.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14794: xml_set_object() should take object by-reference

[vvo]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4 / Apache 1.3
PHP version:  4.1.1
PHP Bug Type: XML related
Bug description:  xml_set_object() should take object by-reference

I am getting the following warning after I switched to
'php.ini-recommended':

Warning:  Call-time pass-by-reference has been deprecated - argument passed
by value;  If you would like to pass it by reference, modify the
declaration of xml_set_object()... 

Apparently, xml_set_object() takes an object by value, which renders this
functionality useless: The only way it's any good is when the object is
passed by reference, so that the event-receiving object is the same
instance that was passed as a parameter to xml_set_object() call.
Otherwise, there is no way for a copied object to pass parsed data out to
the caller of xml_set_object() (without global variables, of course).

Please fix xml_set_object() to take an object by reference.

Thanks.
-- 
Edit bug report at: http://bugs.php.net/?id=14794&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14772 Updated: some links are missing (cosmetic error)

[georg]

ID: 14772
Updated by: georg
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: Documentation problem
Operating System: n/a
PHP Version: 4.1.1
New Comment:

REOPENED

bug still exists in online manual (build date 2002-01-01)
and ditto in my local cvs build.

Georg

Previous Comments:


[2001-12-30 10:46:53] [EMAIL PROTECTED]

Fixed in cvs.
Thnaks for the report.



[2001-12-30 09:17:19] [EMAIL PROTECTED]

This is a docu prob.



[2001-12-30 08:50:32] [EMAIL PROTECTED]

This is only a little thing. On the function page for "socket_get_status", the 
references to related functions at the button are not hyperlinked. It's the line "See 
also accept_connect(), bind(), connect(), listen(), and strerror()." Fix when you can. 
Thanks. - Dan






Edit this bug report at http://bugs.php.net/?id=14772&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support (was Re:PHP5)

[Derick Rethans]

On Tue, 1 Jan 2002, Manuel Lemos wrote:

> > The project we are currently doing, SRM, works a lot like the things
> > you are describing, the only real difference is that we don't use SOAP as
> > transport protocol, but a bytestream protocol. However, adding a XPL-RPC
> > (or SOAP) layer is on the TODO list to. In the next few weeks, I'm going
> > to setup upp some demos, and release some of the code (the PHP extension)
> > so that other can play with it too a little.
>
> I don't think what I suggested is anyway related. What I suggested is
> way built-in PHP to consume remote Web services provided via SOAP. What
> you have is session data manager working in a controlled client-server
> architechture. The service you provide is very specific. Web services
> are defined by remote providers.

I think I know quite good what SRM can do, and that is not only session
data. Besides storing session data, which is not the main goal of SRM
anymore, it can do things like persistent objects (whose methods can be
called remotely), self contained scripts acting on events, function
libraries (written in PHP, accessed through the deamon from a client side
script).

>
> If you already have a bytestream protocol for exchanging session data
> between the client and the server, I doubt that a XML-RPC or a SOAP
> transport layer would provide any advantage. It would make data
> marshalling and exchaging slower without providing any extra flexibility
> (I think).

It would certainly be slower, but it also extends SRM's capability to work
a lot easier with other languages than PHP. The only thing that need to be
written to support a new language is the clientside in that case.

Derick

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]