You are here: Re: [PHP] parent::construct not reliable working on php5.1 b2/b3 « PHP « IT news, forums, messages
Re: [PHP] parent::construct not reliable working on php5.1 b2/b3

Posted by Meno Abels on 08/03/05 13:21

Am 03.08.2005 um 11:03 schrieb Jochem Maas:

> Meno Abels wrote:
>
>> Am 03.08.2005 um 09:22 schrieb Jochem Maas:
>>
>>> Meno Abels wrote:
>>>
>>>
>>>> Thanks,
>>>> the problem with cut an paste i have not only one of these messages
>>>> i get huge amounts of these. So i stripped down to one, sorry
>>>> my fault.
>>>> a) usally 4-6
>>>>
>>>>
>>>
>>> any given class will never have a variable number of parents ;-)
>>> IMHO 6 levels deep is pushing the boat out a bit - but
>>> technically it
>>> should be no problem
>>>
>> depends on the application
>>
>
> IC.
>
>
>>>
>>>
>>>
>>>> b) no
>>>> c) yes, as I mentioned i tried both (old/new)
>>>>
>>>>
>>>
>>> again it may sound stupid but double check spelling in the file.
>>> also check for weird non-printing chars in the problem file -
>>>
>> there are is alot of code which works as i mentioned all the code
>> is generated. The pattern of the working code is not different to the
>> none working. Also i have some examples where i call the same class
>> in other scripts and they are working. So there is no write error.
>> Also
>> the old syntax should work without change and php 4 it works perfect.
>>
>>>
>>>
>>>
>>>> d) never tested i jump over 5.0
>>>>
>>>>
>>>
>>> 5.1 is still beta - test it on 5.0 (consider that the mailing
>>> list equivelant
>>> of a military order ;-)
>>>
>> that will take a while to do
>>
>
> its worth it - regardless of whether it works properly on 5.0 or not
> it strengthens any eventual bug report you may make - i.e. you can
> indicate
> in depth problem research.
>
> also try a fresh build of the latest php5.1 beta - just in case.
>
> no hurry on my account, I'm just an interested bystander :-)
>
>
>>>
>>> does the problem occur in only 1 baseclass? or in a fixed number of
>>> baseclasses? or is does it occur anywhere/everywhere.
>>>
>> i occurs with a random pattern
>>
>
> ouch. when you say random does that mean that running the exact
> same code
> will not always produce the error?
>
> what OS are you on?

FREEBSD 5.4-p6

>
>
>>>
>>> are you trying to reassign $this or are you using the reference
>>> token (&)
>>> when passing objects around? (I ask because you seem to indicate
>>> that the
>>> codebase is being moved from php4 where such things are almost
>>> required to
>>> make usuable OO code - whereas in php5 it's asking for trouble)
>>>
>> NO not used!
>>
>
> we can rule that out then
> !
>
>
>>>
>>> pump up error_reporting to full i.e. error_reporting( E_ALL |
>>> E_STRICT )
>>> - maybe it will give you a hint.
>>>
>> DONE, i see nothing which is seams to be helpfull
>>
>
> darn. so you're not even getting any E_STRICT errors?

i fixed them year go we are working only with E_STRICT on-:)

>
>
>>>
>>> also you might consider placing a call to debug_print_backtrace
>>> () in each
>>> and every constructor to help see wtf is going on.
>>>
>> i'am not clear what is should help for.
>>
>
> it may help you to see a pattern that is not obvious by viewing the
> stack trace
> preceeding each fatal error. just a thought - it may turn up
> nothing :-/
>
>
>>>
>>> lastly get a copy of Zend Studio Client/Server and set it up so
>>> that you
>>> can do step by step debugging to see _exactly_ what is going on.
>>>
>> -:)
>>
>>>
>>> I'm running out of ideas here ... I can only suggest now to post
>>> code
>>> - and plenty of it - if that is possible, send a link to
>>> somewhere rather than
>>> bombard everyone on the list with 1000's of lines of code.
>>>
>> i will work to strip down you can't run the code without 20 own
>> written c++/c
>> extentions.
>>
>
> <ring ring> (alarm bell goes off) - you have 20+ of your own
> extensions that
> are required, there is a distinct possibility that the problem lies
> within them ...
>
> recompling php with all the debug configure options turned on
> and using valgrind and/or gdb to debug maybe what you need to be
> doing.
>

LONG Done, standard procedure, the extentions working all without
change from 4.x.
Our extentions only doing some weired algorithmens on integer and
float matrixes which
are too slow in native php. They do not allocated memory only on the
stack-:). All around
it is pretty simple stuff.

> Side Note: you have code generators and a bunch of custom
> extensions - it sounds
> interesting to say the least! I'd love to see your stuff ... will
> you be going open
> source with it per chance? (maybe that is not even a decision you
> are allowed to make)

it is for you just useless stuff the application is the rapid
development enviroment for a
real huge a datamining application which is mostly design by the use
of MDA(Model Driven Architecture).
We use php for this to safe the huge compile times we need to have on
the also generated
c++ application. PHP is only used for testing and and safe turnaround
times-:) but without the
backend databases which believe me are unsharable-:) you gets out of
the code nothing.

regards

meno

> rgds,
> Jochem
>
>>>
>>>
>>>

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация