> >>Yes, it would, given the root cause - but would you really want to
break
> >>the whole of PHP for an academic exercise?
> >
> > It's not really an academic exercise. If we know there's a bug
someplace
> > we should at least look into it and try and understand it.
>
> Frank's referring to Z
> > I'm a bit behind so sorry if this has been answered already. I don't
think
> > ts_free_id() is a workaround but it's actually correct.
>
> ts_free_id() would be a correct workaround if it came from
zend_shutdown().
> How's it right to suddenly force EVERY extension author to add it to
thei
Yes, it would, given the root cause - but would you really want to break
the whole of PHP for an academic exercise?
It's not really an academic exercise. If we know there's a bug someplace
we should at least look into it and try and understand it.
Frank's referring to Zeev's three-years-ago d
I'm a bit behind so sorry if this has been answered already. I don't think
ts_free_id() is a workaround but it's actually correct.
ts_free_id() would be a correct workaround if it came from zend_shutdown().
How's it right to suddenly force EVERY extension author to add it to their
code individ
At 08:23 AM 5/31/2006, Steph Fox wrote:
Hi Frank,
tsrm_shutdown() is already comented out in the CGI version, most likely as
a fix to the same kind of problem there. Perhaps enabling that again will
show the same kind of problems?
Yes, it would, given the root cause - but would you really wan
At 04:28 AM 5/31/2006, Steph Fox wrote:
Probably some other bug that is the reason of the crash was masked by
omitting FreeLibrary().
I know Tony fixed some kind of such bugs in ext/tidy and ext/sybase.
Yes, he gave those extensions the ts_free_id() workaround I
mentioned a looong time
Need extendsion
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Jun 01, 2006 at 07:17:48AM +0900, TAKAGI Masahiro wrote:
> > Currently, I have karma for phpdoc only.
> > Now I'd like to maintain not only php-doc but peardoc.
> > Could anyone give me karma for peardoc ?
>
> TAKAGI Masahiro mailto:[EMAIL PROTECTED]
Agreed.
--Dan
--
T H E A N A L Y
I have not reviewed the patch in its entirety but the concept and the
code that I did read appear to be fine for 5.2 inclusion by me.
Ilia Alshanetsky
On 30-May-06, at 3:15 PM, Marcus Boerger wrote:
Hello,
i guess i don'T get an answer to this do i?
Saturday, May 27, 2006, 10:32:13 PM
Sorry for inappropriate subject :-(
At Thu, 01 Jun 2006 07:09:55 +0900,
TAKAGI Masahiro wrote:
>
> Hi,
>
> Currently, I have karma for phpdoc only.
> ->
> http://cvs.php.net/viewcvs.cgi/CVSROOT/avail?r1=1.1103&r2=1.1104&diff_format=u
>
> Now I'd like to maintain not only php-doc but peardoc.
Hi,
Currently, I have karma for phpdoc only.
->
http://cvs.php.net/viewcvs.cgi/CVSROOT/avail?r1=1.1103&r2=1.1104&diff_format=u
Now I'd like to maintain not only php-doc but peardoc.
Lukas Smith (lsmith) suggested me to do so.
-> http://news.php.net/php.pear.doc/7965
Could anyone give me karm
Hello Stanislav,
yep exactly right. Maybe we should add documentations for it right now.
And also mark the places like set_error_handler() where it won't work
directly, so noone will change that in upcoming versions while thinking
he was doing a clever optimization.
best regards
marcus
Wednesd
Marcus Boerger wrote:
Welcome
PDF PECL extension
Lauris Bukšis-Haberkorns, mentored by Michael Wallner
Unfortunately, this is not becoming true.
http://code.google.com/soc/php/about.html
http://code.google.com/soc/gimp/about.html
Regards,
--
Michael
--
PHP Internals - PHP Runtime Developm
Hi Steph,
Yes, it would, given the root cause - but would you really want to break
the
whole of PHP for an academic exercise?
Changing the code locally just to test and see if it gave another clude to
the problem would be my approach :-)
I don't need to... the current problem's bleedin' ob
Hi Steph,
> Yes, it would, given the root cause - but would you really want to break
the
> whole of PHP for an academic exercise?
Changing the code locally just to test and see if it gave another clude to
the problem would be my approach :-)
- Frank
--
PHP Internals - PHP Runtime Development
Hi Frank,
tsrm_shutdown() is already comented out in the CGI version, most likely as
a fix to the same kind of problem there. Perhaps enabling that again will
show the same kind of problems?
Yes, it would, given the root cause - but would you really want to break the
whole of PHP for an acade
tsrm_shutdown() is already comented out in the CGI version, most likely as
a fix to the same kind of problem there. Perhaps enabling that again will
show the same kind of problems?
- Frank
> At the moment I'm seeing it with Tidy under 5_2. Just about to get Tony
to
> check.
>
> - Original
On 31.05.2006 11:46, Derick Rethans wrote:
On Wed, 31 May 2006, Marcus Boerger wrote:
right now the fate of E_STRICT error messages is uncertain. A few
people think those should change to fatal after a reasonable amount of
time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
v
At the moment I'm seeing it with Tidy under 5_2. Just about to get Tony to
check.
- Original Message -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>; "'Xuefer'" <[EMAIL PROTECTED]>; "'Andi
Gutmans'" <[EMAIL PROTECTED]>
Cc: "'internals'" ; "'Antony Dov
Steph,
Commenting tsrm_shutdown() or FreeLibrary() is just hidding real bugs.
Of course this is a solution, but not excellent.
Right now I haven't enough time even for ZE and PHP themself, so I don't
like spent it looking into php-gtk on windows.
(I don't know GTK at all).
Do you know any other
Oh well, now I see the difference.
With my patch PHP starts call FreeLibrary() for dll extension.
I am wonder why it wasn't called before. :)
Pure luck, by the look of it :)
Probably some other bug that is the reason of the crash was masked by
omitting FreeLibrary().
I know Tony fixed some kin
On 31.05.2006 15:19, Dmitry Stogov wrote:
Oh well, now I see the difference.
With my patch PHP starts call FreeLibrary() for dll extension.
I am wonder why it wasn't called before. :)
Probably some other bug that is the reason of the crash was masked by
omitting FreeLibrary().
I know Tony fixed
Oh well, now I see the difference.
With my patch PHP starts call FreeLibrary() for dll extension.
I am wonder why it wasn't called before. :)
Probably some other bug that is the reason of the crash was masked by
omitting FreeLibrary().
I know Tony fixed some kind of such bugs in ext/tidy and ext/s
Hmm,
Seems 'f' really make sense for simplification.
I am not sure about other helpers.
I'll need to review patch once again.
Could you include some use-cases (SPL patch that uses this one)?
Thanks. Dmitry.
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: We
C:\sandbox\php5\Zend>grep -l -drecurse "HAVE_LIBDL" *.*
ChangeLog
zend.h
Zend.m4
zend_API.c
zend_config.nw.h
zend_config.w32.h
Zend assumes Windows builds don't have HAVE_LIBDL defined. PHP - which only
uses it in dl.c - assumes they do, and sets it during win32 config.
ZEND_MODULE_DTOR - used
MB>> my patch doesn't change anything. If just adds stuff that deals with
MB>>defined functions only. If now you want to support all functions that
MB>>can be defined later it wouldn't work this way (1). Actually it would
If I understand it right and this patch adds an option for PHP API
functio
Hello Dmitry,
my patch doesn't change anything. If just adds stuff that deals with
defined functions only. If now you want to support all functions that
can be defined later it wouldn't work this way (1). Actually it would
require parsing the zval and checking whether it might get callable in
so
Hello Andi,
that's why i wrote 'might chabge' in the RFC.
best regards
marcus
Wednesday, May 31, 2006, 3:36:29 AM, you wrote:
> At 03:02 PM 5/30/2006, Marcus Boerger wrote:
>> whatever the patch looks like, it is a change from 5.0.0's E_STRICT
>>to a E_COMPILE_ERROR and actually fixes anoth
William Candillon wrote:
> I am open to any suggestions or comments about this project and the
> implementing idea.
One idea that I have is to make the PHP->AST and AST->PHP parts usable
outside the scope of PHPAspect. This would, for instance, give tool
developers and IDE vendors a common base
On Wed, 31 May 2006, Marcus Boerger wrote:
> right now the fate of E_STRICT error messages is uncertain. A few
> people think those should change to fatal after a reasonable amount of
> time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
> version like 5.1 to 5.2 is enough but t
Fixing the config so that ZE doesn't think it's PHP might actually make Zend
more stable too...
I think I _know_ why other extension people are seeing a crash on
ts_free_id(), but my biggest priority at present is getting the PHP-GTK
crash out of the way.
- Steph
Without looking to deeply i
31 matches
Mail list logo
