[PHP-DEV] mono doesn't compile

2003-11-27 Thread Magnus Määttä
Hi

I have mono-0.28 installed.

gccache -DSUPPORT_UTF8 -DLINK_SIZE=2 -DPOSIX_MALLOC_THRESHOLD=10 -I/opt/dev/
php/php5/ext/pcre/pcrelib -Iext/pcre/ -I/opt/dev/php/php5/ext/pcre/ 
-DPHP_ATOM_INC -I/opt/dev/php/php5/include -I/opt/dev/php/php5/main -I/opt/
dev/php/php5 -I/opt/dev/php/php5/Zend -I/usr/include/libxml2 -I/usr/X11R6/
include -I/usr/include/freetype2 -I/usr/include/imap -I/usr/interbase/include 
-I/opt/dev/php/php5/ext/mbstring/oniguruma -I/opt/dev/php/php5/ext/mbstring/
libmbfl -I/opt/dev/php/php5/ext/mbstring/libmbfl/mbfl -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/mysql -I/usr/local/www/oracle/
rdbms/public -I/usr/local/www/oracle/rdbms/demo -I/usr/local/www/oracle/
plsql/public -I/usr/include/pspell  -I/opt/dev/php/php5/TSRM  -mmmx 
-march=pentium2 -g -Wall  -c /opt/dev/php/php5/ext/pcre/pcrelib/study.c -o 
ext/pcre/pcrelib/study.o  && echo > ext/pcre/pcrelib/study.lo
/opt/dev/php/php5/ext/mono/php_mono.c: In function `property_exists':
/opt/dev/php/php5/ext/mono/php_mono.c:226: warning: control reaches end of 
non-void function
/opt/dev/php/php5/ext/mono/php_mono.c: In function `objects_compare':
/opt/dev/php/php5/ext/mono/php_mono.c:236: warning: control reaches end of 
non-void function
/opt/dev/php/php5/ext/mono/php_mono.c: In function `get_php_type':
/opt/dev/php/php5/ext/mono/php_mono.c:329: warning: control reaches end of 
non-void function
/opt/dev/php/php5/ext/mono/php_mono.c: In function `lookup_mono_method_ex':
/opt/dev/php/php5/ext/mono/php_mono.c:389: warning: unused variable `j'
/opt/dev/php/php5/ext/mono/php_mono.c: In function `method_get':
/opt/dev/php/php5/ext/mono/php_mono.c:667: error: structure has no member 
named `arg_types'
/opt/dev/php/php5/ext/mono/php_mono.c: In function `call_method':
/opt/dev/php/php5/ext/mono/php_mono.c:685: warning: `return' with no value, in 
function returning non-void
/opt/dev/php/php5/ext/mono/php_mono.c: At top level:
/opt/dev/php/php5/ext/mono/php_mono.c:739: warning: missing braces around 
initializer
/opt/dev/php/php5/ext/mono/php_mono.c:739: warning: (near initialization for 
`mono_object_handlers[0]')
/opt/dev/php/php5/ext/mono/php_mono.c:740: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:742: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:745: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:746: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:748: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:749: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:750: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:751: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:753: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c:755: warning: initialization from 
incompatible pointer type
/opt/dev/php/php5/ext/mono/php_mono.c: In function `object_dtor':
/opt/dev/php/php5/ext/mono/php_mono.c:780: warning: unused variable `pm'
/opt/dev/php/php5/ext/mono/php_mono.c: In function `object_new':
/opt/dev/php/php5/ext/mono/php_mono.c:789: warning: unused variable `tmp'
/opt/dev/php/php5/ext/mono/php_mono.c: In function `zm_startup_mono':
/opt/dev/php/php5/ext/mono/php_mono.c:1041: error: structure has no member 
named `arg_types'
/opt/dev/php/php5/ext/mono/php_mono.c:1054: error: structure has no member 
named `arg_types'
/opt/dev/php/php5/ext/mono/php_mono.c: At top level:
/opt/dev/php/php5/ext/mono/php_mono.c:632: warning: 
`php_call_mono_method_with_signature' defined but not used
/opt/dev/php/php5/ext/mono/php_mono.c:1019: warning: `destroy_globals' defined 
but not used
make: *** [ext/mono/php_mono.lo] Error 1
make: *** Waiting for unfinished jobs

-- 
The SAME WAVE keeps coming in and COLLAPSING like a rayon MUU-MUU ...

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: Sybase_ct sybase_fetch_array feature

2003-11-27 Thread Timm Friebe
On Wed, 2003-11-26 at 09:55, Alex Bazan wrote:
> Hello,
> sorry for the inconvenience of sending this mail directly to you, but
> i've tried several ways (bug reporting, php_dev list...) to get in
> touch with the developers of sybase_ct extension, without any luck.
I received your mail but just didn't have time to answer it in depth
yet.
 
> Since php 430, there's a new feature on this extension, that applies
> to sybase_fetch_array() and some other sybase_fetch_something
> functions.
I know, it was me who added it:) Since the changes made in one place in
the C sourcecode, it also affects sybase_fetch_object() and you'll find
the same behaviour in sybase_fetch_assoc() which was introduced in the
same patch.

[...]
> This feature was never present in versions before 430 and it's not
> present on any other fetch_array function from other database
> extensions.
Correct. I implemented it as the previous behaviour annoyed me - you'd
have to look at the numeric indexes and the SQL query (counting the
occurances of the field name) to see which one of the names was
"swallowed"...

> I would like to say that I am against implementing these sort of
> repetitive field returns.
Well, it's been implemented for a while (for over a year now, as cvs log
clearly states) and removing it will probably cause other users to
complain... removing this feature is not an option, AFAIS.

> If a programmer wants multiple (identically named) fields returned,
> they can always modify their SQL statement to reflect unique field
> names:
> 
> select t1.id as id1, t2.id as id2 from t1,t2
Which they should be doing anyway, IMO.
 
> PHP should NOT be mangling field names returned from the database
> driver, it should simply return the name-value of the LAST field of
> any given name, as always did.
OK, this is a (rather small) BC break - but the other way around, I
considered it a bug ("field names are disappearing"). I don't know about
what other database extension maintainers think about this, and I guess
you're right I'm the only one whose extension behaves like this. But
maybe it should be considered a bug in other extensions, too?

Anyway, that's why the note was added to the manual[*].
 
> The principal problem is when upgrading PHP. There are loads of cases
> where you can find in a database different tables with some identical
> field names. I know this is poor database design,
I would not say so. We have a rather large amount of tables containing
the fields "lastchange" and "changedby". Now, if I'd just experimentally
fire a query something like 'select * from a, b where a.id= b.id' you
used to get something like this from sybase_fetch_array():

array(
  0 => 127772,
  'id' => 127772,
  1 => 127772,
  2 => 'Dec 14 1977 11:55 AM',
  'lastchange' => 'Dec 14 1977 11:55 AM',
  3 => 'Dec 14 2003 11:55 AM',
  4 => '[EMAIL PROTECTED]',
  'lastchange' => '[EMAIL PROTECTED]',
  5 => '[EMAIL PROTECTED]'
);

Well, without the knowledge of the SQL statement, I'd be guessing (and
could, if I knew lots about the tables' contents) that 'Dec 14 2003
11:55 AM' would probably be the contents of b.lastchange. It could also
be any other field, but I wouldn't know - *unless* - I have the field's
name (and I will, using sybase_ct included in 4.3.0, slightly mangled,
but still readable to a human).

Whatsoever, I shouldn't be doing 'select *' in the first place, and am
only doing this for debugging purposes, to see what the tables contain
(just like using sqsh or isql).

>  but sometimes you find that you have to work with a design where this
> occurs. With this new feature on sybase_fetch_array() all the code
> where one just assumed that the returned value for field X was from
> the last table selected, MUST BE RE-WRITTEN.
Why? You'll have additional array keys in your array but how would this
have an impact on well-written sourcecode? I can (and did) think of
implications on scripts using abovementioned SQL statements where column
names are ambiguous and rely on the fact that you'll have one of the
values accessible via string key and the other one only via numeric key
(but which one, if you come to think about it?). They shouldn't count on
it, as anyone might change the order of columns selected in the SQL
query. 

Nevertheless, I tested sybase_ct at the company I work for in 350'000+
LOC and it didn't produce any weird side effects, so I assumed this
change would be fine with most users. OK, maybe this was a blatant
assumption.
 
> Also, this is a feature only implemented in Sybase library functions,
> so when creating cross-db applications, it is much more difficult to
> implement generic code.
I fail to see your point here. Could you give me an example (a couple of
lines) what kind of cross-db applications would be affected by this
change? 

Come to think of it, you'll never be able to write 100% cross-RDBMS
applications: For example, PostgreSQL does not know identity fields
(implemented via sequences) so there is no such thing as @@identity
the

Re: [PHP-DEV] libpcre 4.4 released

2003-11-27 Thread Jani Taskinen
 
I don't think it's necessary, according to this:

  http://www.pcre.org/changelog.txt

   there aren't any fixes in the code itself, only stuff that
   affect their compile stuff. (compiling it as standalone lib)
   
   --Jani
   

On Thu, 20 Nov 2003, Sebastian Bergmann wrote:

>  Maybe update the bundled libpcre to 4.4?
>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] CVS Account Request: xxiengb

2003-11-27 Thread Enrique Garcia Briones
I would like to participate in the spanish translation of the php documentation, I 
have already subscribed to the phpdoc and phpdoc-es list, how long it will take to 
have an account if allowed?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Concern about changing zval's passed by reference

2003-11-27 Thread Robert Twitty
hanks Marcus

zval_dtor is what I need.

-- bob

On Thu, 27 Nov 2003, Marcus Boerger wrote:

> Hello Robert,
>
> Wednesday, November 26, 2003, 11:32:48 PM, you wrote:
>
> > Hello
>
> > I am using the macros ZVAL_BOOL, ZVAL_LONG, ZVAL_DOUBLE and ZVAL_STRING to
> > change the value of a zval passed by reference.  I noticed that these
> > macros do not free the original value if it's a string, array, object or
> > resource prior to the change.  This causes a possible memory leak.  Is
> > this a normal practice?  And, if not, what is the accepted practice for
> > changing zval's passed by reference?
>
> You need to free the value prior to overwriting it by zval_dtor() or you
> need to use the appropriate zval change macro.
>
> --
> Best regards,
>  Marcusmailto:[EMAIL PROTECTED]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] __autoload() lowercase

2003-11-27 Thread Eduardo R. Maciel
--- Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Please checkout the CVS and let me know if it works
> for you.
> 
Hello Andi,

  It seems to be working.

  I´m going to make more tests. If anything goes wrong
I´ll tell you.

  If somebody else would like to test, would help i 
think.

regards,
Eduardo R. Maciel



__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Daniel Convissor
Greetings:

I have been testing/tweaking PHP 5 via a major OOP based project of mine
that relies on PEAR::DB.  There are some major hangups, most of which I've 
mentioned in other places.  To be complete, I'll touch on them here.

1)  The "var: Deprecated." warning from the new E_STRICT level is a real
pain.  Now, in order to have code that will run under PHP 4 and 5, all
users will have to change their errro reporting level to * ~E_STRICT.  
Worse, since strict is disabled, people won't be able to see really major
deprication problems problems.  I urge var deprication be removed from
E_STRICT until PHP 5 deployments far outweigh PHP 4 deployments.


2)  Argv and argc are not being defined anymore.  Haven't heard back on 
either the bug report or the thread I started here.

http://bugs.php.net/bug.php?id=26206
[PHP-DEV] argv & argc not defined. intentional? bug 26206
http://groups.google.com/groups?threadm=bp3rs1%249p0%241%40FreeBSD.csie.NCTU.edu.tw


3)  Return by reference's bizarre behaviors.  I'm in favor of making it 
just work for actual cases where variables (hence real references) are 
being returned.  Discussion:

[PHP-DEV] return by reference behaviors in PHP 5
http://groups.google.com/groups?threadm=bpuutq%24fbf%241%40FreeBSD.csie.NCTU.edu.tw


4)  When loading the class files PHP crashes.  Bug report:

http://bugs.php.net/?id=26418


Thanks,

--Dan

-- 
 FREE scripts that make web and database programming easier
   http://www.analysisandsolutions.com/software/
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335   f: 718-854-0409

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Edin Kadribasic
Andi, any chance of fixing this? I think there was a long thread on engine2 
about this and there was an agreement that this should work as in php4.

Edin


On Thursday 27 November 2003 13:47, Derick Rethans wrote:
> On Thu, 27 Nov 2003, Edin Kadribasic wrote:
> > On Thursday 27 November 2003 11:47, Jan Schneider wrote:
> > [snip]
> >
> > > behaviour/notification and not working on-the-fly-generation of
> > > stdClass objects. It's not that much of a problem for us as we will
> > > release new
> >
> > What exactly is the problem with stdClass? We have a lot of code overhere
> > that rely on stdClass behaiving as it did in php4.
>
> By doing this:
>
>  $tpl->foo = 'blaat';
> ?>
>
> in PHP 4 you would get a object of stdClass, in PHP 5 you get a warning.
>
> Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Segmentation fault in php4-STABLE-200311270830

2003-11-27 Thread Ilia Alshanetsky
Could you please supply the PHP script used?

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Marcus Boerger
Hello Stanislav,

Thursday, November 27, 2003, 3:32:25 PM, you wrote:

MB>>> It respects the refcoutning while destructing the zvals.

> I don't exacetly understand _how_ it respects them so that this solves the
> circular dependency problem. In fact, in the patch in the URL you have 
> sent I don't even see one call to destructor. Also, does you patch take 
> into account the fact that a number of zvals can refer to the same object?

When a zval is an object and it gets freed the destructor is called.

MB>>> Controlling life time of objects and hence you could also control
MB>>> lifetime of resources if you use php5 new database systems which use
MB>>> objects natively or if you use wrapper objects. So with destructors
MB>>> you can free them as soon as possible (automagically) without any
MB>>> further time consumpting tests. So you will also get lower memory

> I don't see how you can do that. Only place when you don't have to call 
> dtor manually and can be sure the object is destroyed is the end of the 
> request. But by the end of the request all resources are freed anyway, so 
> you don't need dtors to free them.

Well i can test my scripts - and i do understand refcounting and php. So at
least an expirienced programmer can take advantage.



-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread George Schlossnagle
On Nov 27, 2003, at 8:41 AM, Christian Schneider wrote:

Marcus Boerger wrote:
He doesn't say that. We are doing a lot of work on the QA front and of
course fix bugs and release new versions. But our policy is to 
introduce
Ok, I declare it a bug then so you can include it in the next bug fix 
release.
I lost the beginning of the thread - what's the bug?  That __clone() 
doesn't exist in php4?  All sorts of object model features don't exist 
in php4, that's one of the major feature set additions in php5.

George

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Stanislav Malyshev
MB>> It respects the refcoutning while destructing the zvals.

I don't exacetly understand _how_ it respects them so that this solves the 
circular dependency problem. In fact, in the patch in the URL you have 
sent I don't even see one call to destructor. Also, does you patch take 
into account the fact that a number of zvals can refer to the same object? 

MB>> Controlling life time of objects and hence you could also control
MB>> lifetime of resources if you use php5 new database systems which use
MB>> objects natively or if you use wrapper objects. So with destructors
MB>> you can free them as soon as possible (automagically) without any
MB>> further time consumpting tests. So you will also get lower memory

I don't see how you can do that. Only place when you don't have to call 
dtor manually and can be sure the object is destroyed is the end of the 
request. But by the end of the request all resources are freed anyway, so 
you don't need dtors to free them.
-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: When is php going to grow up?? (fwd)

2003-11-27 Thread Ivan Rodriguez

- Original Message -
From: "Cristiano Duarte" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 27, 2003 2:12 PM
Subject: [PHP-DEV] Re: When is php going to grow up?? (fwd)


> > When is php going to grow up?? I want to be able to write php store
procedures
> > inside any of the major databases (Postgre, Sql Server
,db2,Oracle,Sybase)
> I guess you can write php stored procedures in PostgreSQL...
>
> > I want php to be one of the .Net languages supported by Microsoft
> > (like perl, or C#) so I can write my windows GUI based applications.
> ...
You can do you GUI applications multiplataform with PHP-GTK
>
> > I want to be able to compile my php applications.
> You can compile it and even encode it. But you can't package it yet. :-(
>
> > I want to run a php application server (EPB Enterprise PHP Bean)(similar
> weblogic,websphere,etc) and all the cool things it implies(load balancing,
> transactions, messaging etc, etc).
> It would be a great step forward! With the CLI sapi you can run
> a PHP script as an executable program. With a CORBA, COM or XML-RPC you
> can make your script act as a server application (that's not an
> apllication server).
>
> > I think PHP is too good to stay where it is.
> I agree. Even with some opinions that PHP isn't made for enterprise
> services, that it's only a "Web Script Language", I think that, in
> the near future, it will hit the enterprise services as a free software
> application server language.
> There will be a long path till then, but PHP5 is a start and there are a
> lot of developers contributing for it.
>
> Best Regards,
>
> Cristiano Duarte
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Marcus Boerger wrote:
He doesn't say that. We are doing a lot of work on the QA front and of
course fix bugs and release new versions. But our policy is to introduce
Ok, I declare it a bug then so you can include it in the next bug fix 
release. The point about not being able to compile it on thousands of 
machines was polemic (if not wrong) at the very least.

And I didn't want to continue this on the list (I took it off-list) but 
it was brought back here. Sorry for that.

I'll shut up now,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Marcus Boerger
Hello Christian,

Thursday, November 27, 2003, 2:23:16 PM, you wrote:

> Derick Rethans wrote:
>> No, what I said was correct. As it is very unlikely that we create a new
>> PHP 4 minor version we CAN not at a new function as it's impossible to
>> modify source that has already been compiled on thousands of machines.

> So no more bug fixes either? That's serious stuff and quite interesting 
> release management.

> I'm tempted to bet that there will be another PHP4 release... (-:C

> Oh, and just calling it "PHP 4.3.4 patch level xy" doesn't count ;-)

> Maybe it could be done as a "missing __clone() method added" bug fix 
> then ;-)

> Hmm.. if you completely abandon the PHP4 branch then maybe I could take 
> over and do PHP 4.4 on my own :-)

He doesn't say that. We are doing a lot of work on the QA front and of
course fix bugs and release new versions. But our policy is to introduce
newer functionality only in minor versions. And the active RM has no plans
for a 4.4 version since that would delay 5 more.


-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Derick Rethans wrote:
No, what I said was correct. As it is very unlikely that we create a new
PHP 4 minor version we CAN not at a new function as it's impossible to
modify source that has already been compiled on thousands of machines.
So no more bug fixes either? That's serious stuff and quite interesting 
release management.

I'm tempted to bet that there will be another PHP4 release... (-:C

Oh, and just calling it "PHP 4.3.4 patch level xy" doesn't count ;-)

Maybe it could be done as a "missing __clone() method added" bug fix 
then ;-)

Hmm.. if you completely abandon the PHP4 branch then maybe I could take 
over and do PHP 4.4 on my own :-)

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


[PHP-DEV] Re: When is php going to grow up?? (fwd)

2003-11-27 Thread Cristiano Duarte
> When is php going to grow up?? I want to be able to write php store procedures
> inside any of the major databases (Postgre, Sql Server ,db2,Oracle,Sybase)
I guess you can write php stored procedures in PostgreSQL...

> I want php to be one of the .Net languages supported by Microsoft 
> (like perl, or C#) so I can write my windows GUI based applications. 
...

> I want to be able to compile my php applications.
You can compile it and even encode it. But you can't package it yet. :-(

> I want to run a php application server (EPB Enterprise PHP Bean)(similar
weblogic,websphere,etc) and all the cool things it implies(load balancing,
transactions, messaging etc, etc).
It would be a great step forward! With the CLI sapi you can run
a PHP script as an executable program. With a CORBA, COM or XML-RPC you
can make your script act as a server application (that's not an
apllication server).

> I think PHP is too good to stay where it is.
I agree. Even with some opinions that PHP isn't made for enterprise
services, that it's only a "Web Script Language", I think that, in
the near future, it will hit the enterprise services as a free software
application server language.
There will be a long path till then, but PHP5 is a start and there are a
lot of developers contributing for it.

Best Regards,

Cristiano Duarte

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Jan Schneider
Zitat von Edin Kadribasic <[EMAIL PROTECTED]>:

> On Thursday 27 November 2003 11:47, Jan Schneider wrote:
> [snip]
> > behaviour/notification and not working on-the-fly-generation of
> stdClass
> > objects. It's not that much of a problem for us as we will release new
>
> What exactly is the problem with stdClass? We have a lot of code overhere
> that
> rely on stdClass behaiving as it did in php4.

Actually I'm not sure if this problem still exists, but I found that
checking our commits related to ZE2 fixes.

Creating objects on the fly didn't work or at least raised a warning/error.
I changed code like:

$not_existing_object->foo = "bar";

to:

$not_existing_object = new stdClass();
$not_existing_object->foo = "bar";

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Derick Rethans
On Thu, 27 Nov 2003, Christian Schneider wrote:

> [This is off-list]

(not anymore)

> Derick Rethans wrote:
> > We can not add a new function to PHP 4 anyway... so there is no other
> > acceptable solution...
>
> Should be "We do not WANT to add a new function to PHP4".

No, what I said was correct. As it is very unlikely that we create a new
PHP 4 minor version we CAN not at a new function as it's impossible to
modify source that has already been compiled on thousands of machines.

Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Derick Rethans
On Thu, 27 Nov 2003, Edin Kadribasic wrote:

> On Thursday 27 November 2003 11:47, Jan Schneider wrote:
> [snip]
> > behaviour/notification and not working on-the-fly-generation of stdClass
> > objects. It's not that much of a problem for us as we will release new
>
> What exactly is the problem with stdClass? We have a lot of code overhere that
> rely on stdClass behaiving as it did in php4.

By doing this:

foo = 'blaat';
?>

in PHP 4 you would get a object of stdClass, in PHP 5 you get a warning.

Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Segmentation fault in php4-STABLE-200311270830

2003-11-27 Thread Marcus Boerger
Hello Jean-Pierre,

Thursday, November 27, 2003, 1:27:25 PM, you wrote:


> - Original Message - 
> From: "Ilia Alshanetsky" <[EMAIL PROTECTED]>
> To: "Jean-Pierre Arneodo" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, November 27, 2003 2:18 AM
> Subject: Re: [PHP-DEV] Segmentation fault in v4.3.4


>> This problem is now fixed, thank you for reporting it.
>>
>> Ilia

> OK, it works better with php4-STABLE-200311270830

> But, Valgrind reported others similar problem.
> At the beginning of the log, it's an https call through Curl.
> Look at the end for zend related reports.

> The process die in the exit() function.

> Jean-Pierre



> ==1239== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==1239== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
> ==1239== Using valgrind-2.0.0, a program supervision framework for
> x86-linux.
[...]

According to the valgrind output most errors are caused by the crypt library
which is not our problem and about which we cannot do anything than hoping
for a fix as we do for a long time now. The end of your output of course is
interesting.



-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Marcus Boerger
Hello Stanislav,

Thursday, November 27, 2003, 1:28:36 PM, you wrote:

MB>>> Ok, sure we care in request shutdown but at least page delivery isn't
MB>>> affected by the patch. 

> Definitely it is. The fact that it's _next_ page delivery that would be 
> affected is not helping much - any page but the very first since server 
> run is the next for some page and it is reasonable to expect that on 
> the loaded server the pages are requested continiously. 

> Side note - could you give me a quick explanation about what you patch is 
> meant to do?

It respects the refcoutning while destructing the zvals.

MB>>> loosing one of the major oo features to be introduced with php5. And the

> Do you mean destructors?

sure

MB>>> slowdoen is of course only in one functionality. And it allows things that
MB>>> make the whole script faster so i don't see any problem with it.

> Like what?

Controlling life time of objects and hence you could also control lifetime
of resources if you use php5 new database systems which use objects natively
or if you use wrapper objects. So with destructors you can free them as soon
as possible (automagically) without any further time consumpting tests. So
you will also get lower memory usage for free which typically results in
faster execution.

-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Segmentation fault in php4-STABLE-200311270830

2003-11-27 Thread Jean-Pierre Arneodo

- Original Message - 
From: "Ilia Alshanetsky" <[EMAIL PROTECTED]>
To: "Jean-Pierre Arneodo" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, November 27, 2003 2:18 AM
Subject: Re: [PHP-DEV] Segmentation fault in v4.3.4


> This problem is now fixed, thank you for reporting it.
>
> Ilia

OK, it works better with php4-STABLE-200311270830

But, Valgrind reported others similar problem.
At the beginning of the log, it's an https call through Curl.
Look at the end for zend related reports.

The process die in the exit() function.

Jean-Pierre



==1239== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==1239== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==1239== Using valgrind-2.0.0, a program supervision framework for
x86-linux.
==1239== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==1239== Estimated CPU clock rate is 1615 MHz
==1239== For more details, rerun with: -v
==1239==
==1239== Syscall param write(buf) contains uninitialised or unaddressable
byte(s)
==1239==at 0x404FAFB4: __libc_write (in /lib/i686/libc-2.2.4.so)
==1239==by 0x403A9D50: BIO_write (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x4033EDEB: ssl3_write_pending (in /lib/libssl.so.0.9.6b)
==1239==by 0x4033EAA1: ssl3_write_bytes (in /lib/libssl.so.0.9.6b)
==1239==Address 0x47C0989B is 15 bytes inside a block of size 18437
alloc'd
==1239==at 0x4002BB60: malloc (vg_replace_malloc.c:153)
==1239==by 0x4037BFAC: CRYPTO_malloc (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40340481: ssl3_setup_buffers (in /lib/libssl.so.0.9.6b)
==1239==by 0x40339ACD: ssl3_connect (in /lib/libssl.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x4039C105: RSA_padding_add_PKCS1_type_2 (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x40399A41: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x4039B3E5: RSA_public_encrypt (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x4033B959: ssl3_send_client_key_exchange (in
/lib/libssl.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x40393DA7: BN_bin2bn (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40399AD1: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x4039B3E5: RSA_public_encrypt (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x4033B959: ssl3_send_client_key_exchange (in
/lib/libssl.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x40393E98: BN_ucmp (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x403928F4: BN_mod_exp_mont (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40399B9D: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x4039B3E5: RSA_public_encrypt (in /lib/libcrypto.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x403928FA: BN_mod_exp_mont (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40399B9D: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x4039B3E5: RSA_public_encrypt (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x4033B959: ssl3_send_client_key_exchange (in
/lib/libssl.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x40394532: BN_mul (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40398992: BN_mod_mul_montgomery (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x40392947: BN_mod_exp_mont (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40399B9D: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x40398B50: BN_from_montgomery (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x403989A8: BN_mod_mul_montgomery (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x40392947: BN_mod_exp_mont (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40399B9D: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x40398B59: BN_from_montgomery (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x403989A8: BN_mod_mul_montgomery (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x40392947: BN_mod_exp_mont (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40399B9D: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x40398BBA: BN_from_montgomery (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x403989A8: BN_mod_mul_montgomery (in
/lib/libcrypto.so.0.9.6b)
==1239==by 0x40392947: BN_mod_exp_mont (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40399B9D: RSA_eay_public_encrypt (in
/lib/libcrypto.so.0.9.6b)
==1239==
==1239== Conditional jump or move depends on uninitialised value(s)
==1239==at 0x40393E98: BN_ucmp (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x40398C94: BN_from_montgomery (in /lib/libcrypto.so.0.9.6b)
==1239==by 0x403989A8: BN_mod_mul_montg

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Stanislav Malyshev
MB>> Ok, sure we care in request shutdown but at least page delivery isn't
MB>> affected by the patch. 

Definitely it is. The fact that it's _next_ page delivery that would be 
affected is not helping much - any page but the very first since server 
run is the next for some page and it is reasonable to expect that on 
the loaded server the pages are requested continiously. 

Side note - could you give me a quick explanation about what you patch is 
meant to do? 

MB>> loosing one of the major oo features to be introduced with php5. And the

Do you mean destructors?

MB>> slowdoen is of course only in one functionality. And it allows things that
MB>> make the whole script faster so i don't see any problem with it.

Like what? 
-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Edin Kadribasic
On Thursday 27 November 2003 11:47, Jan Schneider wrote:
[snip]
> behaviour/notification and not working on-the-fly-generation of stdClass
> objects. It's not that much of a problem for us as we will release new

What exactly is the problem with stdClass? We have a lot of code overhere that 
rely on stdClass behaiving as it did in php4.

Edin

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Marcus Boerger
Hello Stanislav,

Thursday, November 27, 2003, 1:00:20 PM, you wrote:

MB>>> with 1 < c < 1.1. Since we never cared about shutdown time this
MB>>> should be ok

> If we are talking about request shutdown, we definitely do care about it. 
> Slower is the request shutdown, more time the httpd process/thread takes 
> per request, more load on the server.

Ok, sure we care in request shutdown but at least page delivery isn't
affected by the patch. And anyway a little bit slowdown is much better then
loosing one of the major oo features to be introduced with php5. And the
slowdoen is of course only in one functionality. And it allows things that
make the whole script faster so i don't see any problem with it.

-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Derick Rethans
On Thu, 27 Nov 2003, Christian Schneider wrote:

> Björn Schotte wrote:
> > I think they solve the problem exactly the way Wez told you.
>
> Which means everyone has to reinvent the wheel. Ok, fine with me.

We can not add a new function to PHP 4 anyway... so there is no other
acceptable solution...

Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Björn Schotte wrote:
I think they solve the problem exactly the way Wez told you.
Which means everyone has to reinvent the wheel. Ok, fine with me.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Stanislav Malyshev
MB>> with 1 < c < 1.1. Since we never cared about shutdown time this
MB>> should be ok

If we are talking about request shutdown, we definitely do care about it. 
Slower is the request shutdown, more time the httpd process/thread takes 
per request, more load on the server.
-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Björn Schotte
Hi Christian,

* Christian Schneider wrote:
> If you read my original posting you'll notice that I've already done 
> this but I thought other people have exactly the same problem.

I think they solve the problem exactly the way Wez told you.

-- 
Schnellanbindung an 350 Standorte?! CaseStudy anfordern unter:
[EMAIL PROTECTED]
ThinkPHP / rent-a-phpwizard   [EMAIL PROTECTED]
Sedanstraße 27 Tel: 0931 / 78 43 804
97082 Würzburg Fax: 0931 / 78 43 795
http://www.thinkphp.de/  http://www.rent-a-phpwizard.de/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Wez Furlong wrote:
Why not add your own clone() function to your apps;
If you read my original posting you'll notice that I've already done 
this but I thought other people have exactly the same problem.
Looks like I was wrong.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Wez Furlong
Hey Christian,

Why not add your own clone() function to your apps;
something like this:

if (version_compare(phpversion(), "5.0", "<")) {
function clone($object) { return $object; }
} else {
function clone($object) { return $object->__clone(); }
}

then (re)write all your code to call clone() where
you need it.

[I know that this is what you want to have in php 4
and php 5 right now anyway; but its only a couple
of lines of code to add to your project]

--Wez.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Marcus Boerger
Hello Derick,

Thursday, November 27, 2003, 11:54:07 AM, you wrote:

> Hey,

> On Wed, 26 Nov 2003, Andi Gutmans wrote:

>> Now that we're at a very advanced stage and the code freeze is coming up, I
>> think it'd be a good idea to start running some PHP 4 applications on PHP 5
>> and see how easy things go. I'm sure we'll bump into some issues and many
>> of them might be solvable (using the already existing compatibility mode
>> for object cloning or by other means).

> There is one major problem that I see at this moment, and that is the
> problem with shutdown order and destructors.

> Problem 1:

> extension=mysql.so

[...]

Since about three month i have a patch to fix this. The latest update can be
found here: http://marcus-boerger.de/php/ext/ze2/ze2-shutdown-20031002.diff.txt
Tell me if it doesn't apply then i'll update it.

What it basically does is destructing the zval's in correct order. The old
algorythm had a magnitude of O(n) while the new one has a magnitude of
O(n*log(n)) while it should have a normal runtime of N(n) in most cases too.
Maybe it is a little bit slower so that runtime could be written as N(n*c)
with 1 < c < 1.1. Since we never cared about shutdown time this should be ok
anyways. Also the inner loop breaks at a mximum of 64 where its minimum
depends on the outer loop. That means that in worst case scenarios that the
algorythmn can't solve a few variables take more time then the rest but at
least they are freed anyway.


-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Derick Rethans wrote:
Just use an auto_prepend which sets the implicit_clone option... no
problems then anymore.
*Sigh*

Looks like you're not reading my postings really.

This means your migration path to ref on assignement semantics is:
1) current code, copy (PHP4)
2) wait months for PHP5 to be ready for production, twidddling thumbs
3) current code, copy (Switch to PHP5 with implicit clone)
4) atomic rewrite, ref (PHP5, incompatible with PHP4)
So I can't start to migrate my code to PHP5 yet *or* I have to branch my 
code at 2) just for this which I won't do as it could be a couple of 
months until we decide it is ready for production machines. And I can't 
switch back to PHP4 if I run into other problems.

But ok, seems like I'm the only one bothered by this.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Derick Rethans
On Thu, 27 Nov 2003, Christian Schneider wrote:

> Marcus Boerger wrote:
> > If i get you right you want to have __clone() for PHP4, too right? But
> > that's already to late.
>
> That's what I was told when I was asking for ref on assignment for PHP4.
>   And now we have to go through this hassle for PHP5. I simply cannot
> believe noone thought of this problem when it was still possible to add
> it to PHP4 _and_ we stick to this just for the sake of a feature freeze.
> The function is so trivial (and IMHO so important) that being strict
> here seems plain wrong to me. After all it hinders migration to PHP5!

Just use an auto_prepend which sets the implicit_clone option... no
problems then anymore.

Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Marcus Boerger wrote:
If i get you right you want to have __clone() for PHP4, too right? But
that's already to late.
That's what I was told when I was asking for ref on assignment for PHP4. 
 And now we have to go through this hassle for PHP5. I simply cannot 
believe noone thought of this problem when it was still possible to add 
it to PHP4 _and_ we stick to this just for the sake of a feature freeze. 
The function is so trivial (and IMHO so important) that being strict 
here seems plain wrong to me. After all it hinders migration to PHP5!

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Jan Lehnardt
Hi Andi,
On 26 Nov 2003, at 16:32, Andi Gutmans wrote:
If anyone here has time or has already tried running some popular PHP 
packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to 
hear about your experience and especially the problems.
I forwarded this to pear-dev. I know that some people are already
playing with 5 there, so they could share their results.
Jan
--
Q: Thank Jan? -  A: http://geschenke.an.dasmoped.net/
"We cats are very independent. We need nobody,  no time,
 no where, no way. Isn't that right Pooky?" - Garfield
Key Fingerprint 7BCC EB86 8313 DDA9 25DF 1805 ECA5 BCB7 BB96 56B0
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Marcus Boerger
Hello Christian,

Thursday, November 27, 2003, 11:51:06 AM, you wrote:

> Andi Gutmans wrote:
>> You can use the zend2.implicit_clone INI directive (change it at 
>> run-time if you want at the beginning of the application).

> But I do want to move my application to the new semantics, I think it is 
> much more reasonable than the PHP4 behaviour anyway (sadly enough my 
> request to ref instead of copy on assignment was turned down in the PHP4 
> alpha days ;-)).

> I simply want to have a way of doing an explicit clone where it is 
> really needed. I still can't see no reason why there should be no 
> migration path for this. PHP5 adoption is going to be hard enough due to 
> subtle bugs arising from this so I think clone() is the least we could 
> do here. Forcing people to use zend2.implicit_clone won't help this IMHO.

If i get you right you want to have __clone() for PHP4, too right? But
that's already to late. And using it on PHP5 to emulate PHP4 behavior where
needed might not solve all problems, so what can we do besides __clone and
the ini directive?


-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Derick Rethans
Hey,

On Wed, 26 Nov 2003, Andi Gutmans wrote:

> Now that we're at a very advanced stage and the code freeze is coming up, I
> think it'd be a good idea to start running some PHP 4 applications on PHP 5
> and see how easy things go. I'm sure we'll bump into some issues and many
> of them might be solvable (using the already existing compatibility mode
> for object cloning or by other means).

There is one major problem that I see at this moment, and that is the
problem with shutdown order and destructors.

Problem 1:

extension=mysql.so

c = mysql_connect();
}
function __destruct() {
mysql_close($this->c);
}
}

$f = new foo();
?>

This little script will give you a nice unresolved symbol when doing the
mysql_close as the extensions are unloaded before the dtors run.

Problem 2:
The following script:



crashes Xdebug. While I thought it was *my* bug, it turned out to have
the same cause as problem 1: the dtor is run after the GET/POST/COOKIE
var tables are destroyed. (Xdebug tries to check some things in there on
every function call). It's not only this, see problem 3.


788  zend_hash_find(PG(http_globals)[TRACK_VARS_GET]->value.ht, 
"XDEBUG_SESSION_START", sizeof("XDEBUG_SESSION_START"), (void **) &dummy) == SUCCESS

(gdb) bt
#0  0x0826325d in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x8417660 "/dat/dev/php/php-5.0dev/Zend/zend_hash.c", line=841)
at /dat/dev/php/php-5.0dev/Zend/zend_hash.c:53
#1  0x082656f1 in zend_hash_find (ht=0x5a5a5a5a,
arKey=0x406446bd "XDEBUG_SESSION_START", nKeyLength=21, pData=0xbfffe70c)
at /dat/dev/php/php-5.0dev/Zend/zend_hash.c:841
#2  0x406325dd in xdebug_execute (op_array=0x405f9000)
at /dat/dev/php/xdebug/xdebug.c:788
#3  0x08252cd3 in zend_call_function (fci=0xbfffec20, fci_cache=0x0)
at /dat/dev/php/php-5.0dev/Zend/zend_execute_API.c:737

(gdb) frame 3
#3  0x08252cd3 in zend_call_function (fci=0xbfffec20, fci_cache=0x0)
at /dat/dev/php/php-5.0dev/Zend/zend_execute_API.c:737
737 zend_execute(EG(active_op_array) TSRMLS_CC);
(gdb) print *executor_globals.active_op_array
$2 = {type = 2 '\002', function_name = 0x405f5608 "__destruct",
  scope = 0x405f7518, fn_flags = 16640, prototype = 0x0, num_args = 0,
  arg_info = 0x0, pass_rest_by_reference = 0 '\0', refcount = 0x405f792c,
  opcodes = 0x405f7968, last = 5, size = 5, T = 0, brk_cont_array = 0x0,
  last_brk_cont = 0, current_brk_cont = 4294967295, static_variables = 0x0,
  start_op = 0x0, backpatch_count = 0, return_reference = 0 '\0',
  done_pass_two = 1 '\001', uses_this = 0 '\0',
  filename = 0x405f5d8c "/dat/dev/php/xdebug/tests/bug1.php",
  line_start = 3, line_end = 5, doc_comment = 0x0, doc_comment_len = 0,
  reserved = {0x0, 0x1, 0x8414a60, 0x923}}


Problem 3:

All extension globals are also destroyed before destructors run:

0x40631ac0 in add_stack_frame (zdata=0xbfffeb80, op_array=0x405f9000, type=0)
at /dat/dev/php/xdebug/xdebug.c:684
684 xdebug_llist_insert_next(XG(stack), XDEBUG_LLIST_TAIL(XG(stack)), tmp);
(gdb) bt
#0  0x40631ac0 in add_stack_frame (zdata=0xbfffeb80,
op_array=0x405f9000,
type=0) at /dat/dev/php/xdebug/xdebug.c:684
#1  0x40632040 in xdebug_execute (op_array=0x405f9000)
at /dat/dev/php/xdebug/xdebug.c:830
#2  0x08252cd3 in zend_call_function (fci=0xbfffec20, fci_cache=0x0)
at /dat/dev/php/php-5.0dev/Zend/zend_execute_API.c:737


(gdb) print xdebug_globals.stack
$2 = (xdebug_llist *) 0x0

(this variable is initialized in MINIT and destroyed in MSHUTDOWN).


Parts of a chat with Zeev about this:

12:11 <@Derick> the hook you added "exec_finished" didn't solve my problem
12:11 <@Derick> because destructors are still called AFTER RSHUTDOWN :(
12:11 <@Zeev> they're not supposed to
12:11 <@Zeev> but I didnt do anything beyond exec_finished
12:11 <@Zeev> that is, nothing uses it yet
12:11 <@Derick> so what's the point of it ? :)
12:11 <@Zeev> the point is that it solves the problem
12:11 <@Zeev> once things start using it :)
12:12 <@Zeev> I can barely type
12:12 <@Zeev> my fingers are on fire
12:12 <@Derick> well, then the ZE needs to be modified to use  it ;)
12:12 <@Derick> Zeev: peppers?
12:12 <@Zeev> derick the engine isnt supposed to use it
12:12 <@Derick> heh
12:12 <@Zeev> it simply has to call destructors after exec_finished
12:12 <@Zeev> but before rshutdown
12:12 <@Derick> yes
12:13 <@Zeev> but we cant do that before modules like the session module implement 
exec_finished
12:13 <@Derick> doesn't that need an engine mod then?
12:13 <@Derick> Zeev: ah ha
12:13 <@Zeev> because they're the reason destructors are called after rshutdown to 
begin with
12:13 <@Zeev> and yeah
12:13 <@Derick> Zeev: the problem is that if you mod session, the stuff needs to work 
first ... it's a chicken and egg problemm

Related test case:

14:46 <@Derick> ZE2 accessing globals from destructor in shutdown 
[tests/classes/destructor_and_globals.phpt]

Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Andi Gutmans wrote:
You can use the zend2.implicit_clone INI directive (change it at 
run-time if you want at the beginning of the application).
But I do want to move my application to the new semantics, I think it is 
much more reasonable than the PHP4 behaviour anyway (sadly enough my 
request to ref instead of copy on assignment was turned down in the PHP4 
alpha days ;-)).

I simply want to have a way of doing an explicit clone where it is 
really needed. I still can't see no reason why there should be no 
migration path for this. PHP5 adoption is going to be hard enough due to 
subtle bugs arising from this so I think clone() is the least we could 
do here. Forcing people to use zend2.implicit_clone won't help this IMHO.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Jan Schneider
Zitat von Andi Gutmans <[EMAIL PROTECTED]>:

> Hi guys,
>
> Now that we're at a very advanced stage and the code freeze is coming up,
> I
> think it'd be a good idea to start running some PHP 4 applications on PHP
> 5
> and see how easy things go. I'm sure we'll bump into some issues and many
> of them might be solvable (using the already existing compatibility mode
> for object cloning or by other means).
>
> If anyone here has time or has already tried running some popular PHP
> packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear
> about your experience and especially the problems.

Horde et al suffered from new reserved words, the known
return-non-variables-by-reference-problem, the changed array_merge()
behaviour/notification and not working on-the-fly-generation of stdClass
objects. It's not that much of a problem for us as we will release new
major versions near to the PHP 5 release, that will be tested with PHP
HEAD.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Andi Gutmans
What had to be patched? Is it something we can fix or add to a 
compatibility mode?

Andi

At 11:24 AM 11/27/2003 +0100, Marcus Boerger wrote:
Hello Ivan,

same for me with a two weeks old 5b2-dev. It also runs other applications
and only one had to be patched (i didn't knew it was running n the server).
Thursday, November 27, 2003, 10:51:34 AM, you wrote:

> Hi Andi, I try phpmyadmin with php 5.0.0beta1 under Red Hat 9 and works
> perfect.
> - Original Message -
> From: "Andi Gutmans" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, November 26, 2003 4:32 PM
> Subject: [PHP-DEV] Compatibility problems with PHP 5
>> Hi guys,
>>
>> Now that we're at a very advanced stage and the code freeze is coming up,
> I
>> think it'd be a good idea to start running some PHP 4 applications on PHP
> 5
>> and see how easy things go. I'm sure we'll bump into some issues and many
>> of them might be solvable (using the already existing compatibility mode
>> for object cloning or by other means).
>>
>> If anyone here has time or has already tried running some popular PHP
>> packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear
>> about your experience and especially the problems.
>>
>> Thanks,
>> Andi
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>


--
Best regards,
 Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Andi Gutmans
At 11:00 AM 11/27/2003 +0100, Christian Schneider wrote:
Andi Gutmans wrote:
issues and many of them might be solvable (using the already existing 
compatibility mode for object cloning or by other means).
Could we please, please, please have a way of cloning objects which works 
in both versions? I'd like to use the new semantics as soon as it's 
available (no compatibility mode) but still be able to run my application 
on PHP4.

See my posting about the need for a clone() function. I didn't get an 
answer there so I wonder how everyone else is dealing with this issue.
You can use the zend2.implicit_clone INI directive (change it at run-time 
if you want at the beginning of the application).

Andi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Andi Gutmans
Great to hear that!

At 10:51 AM 11/27/2003 +0100, Ivan Rodriguez wrote:
Hi Andi, I try phpmyadmin with php 5.0.0beta1 under Red Hat 9 and works
perfect.
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 26, 2003 4:32 PM
Subject: [PHP-DEV] Compatibility problems with PHP 5
> Hi guys,
>
> Now that we're at a very advanced stage and the code freeze is coming up,
I
> think it'd be a good idea to start running some PHP 4 applications on PHP
5
> and see how easy things go. I'm sure we'll bump into some issues and many
> of them might be solvable (using the already existing compatibility mode
> for object cloning or by other means).
>
> If anyone here has time or has already tried running some popular PHP
> packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear
> about your experience and especially the problems.
>
> Thanks,
> Andi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Marcus Boerger
Hello Ivan,

same for me with a two weeks old 5b2-dev. It also runs other applications
and only one had to be patched (i didn't knew it was running n the server).

Thursday, November 27, 2003, 10:51:34 AM, you wrote:

> Hi Andi, I try phpmyadmin with php 5.0.0beta1 under Red Hat 9 and works
> perfect.

> - Original Message -
> From: "Andi Gutmans" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, November 26, 2003 4:32 PM
> Subject: [PHP-DEV] Compatibility problems with PHP 5


>> Hi guys,
>>
>> Now that we're at a very advanced stage and the code freeze is coming up,
> I
>> think it'd be a good idea to start running some PHP 4 applications on PHP
> 5
>> and see how easy things go. I'm sure we'll bump into some issues and many
>> of them might be solvable (using the already existing compatibility mode
>> for object cloning or by other means).
>>
>> If anyone here has time or has already tried running some popular PHP
>> packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear
>> about your experience and especially the problems.
>>
>> Thanks,
>> Andi
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>




-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: [PHP-QA] Compatibility problems with PHP 5

2003-11-27 Thread Derick Rethans
On Wed, 26 Nov 2003, Andi Gutmans wrote:

> If anyone here has time or has already tried running some popular PHP
> packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear
> about your experience and especially the problems.

make install segfaults at the moment, see the mail I posted yesterday.
Testing stuff is quite hard now...

Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: Compatibility problems with PHP 5

2003-11-27 Thread Christian Schneider
Andi Gutmans wrote:
issues and many of them might be solvable (using the already existing 
compatibility mode for object cloning or by other means).
Could we please, please, please have a way of cloning objects which 
works in both versions? I'd like to use the new semantics as soon as 
it's available (no compatibility mode) but still be able to run my 
application on PHP4.

See my posting about the need for a clone() function. I didn't get an 
answer there so I wonder how everyone else is dealing with this issue.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Ivan Rodriguez
Hi Andi, I try phpmyadmin with php 5.0.0beta1 under Red Hat 9 and works
perfect.

- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 26, 2003 4:32 PM
Subject: [PHP-DEV] Compatibility problems with PHP 5


> Hi guys,
>
> Now that we're at a very advanced stage and the code freeze is coming up,
I
> think it'd be a good idea to start running some PHP 4 applications on PHP
5
> and see how easy things go. I'm sure we'll bump into some issues and many
> of them might be solvable (using the already existing compatibility mode
> for object cloning or by other means).
>
> If anyone here has time or has already tried running some popular PHP
> packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear
> about your experience and especially the problems.
>
> Thanks,
> Andi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Compatibility problems with PHP 5

2003-11-27 Thread Andi Gutmans
Hi guys,

Now that we're at a very advanced stage and the code freeze is coming up, I 
think it'd be a good idea to start running some PHP 4 applications on PHP 5 
and see how easy things go. I'm sure we'll bump into some issues and many 
of them might be solvable (using the already existing compatibility mode 
for object cloning or by other means).

If anyone here has time or has already tried running some popular PHP 
packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear 
about your experience and especially the problems.

Thanks,
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


[PHP-DEV] CVS Account Request: lucamariano

2003-11-27 Thread Luca Mariano
I need CVS access for the PEAR package Net_Server documentation and development

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php