> Fatal error: Invalid opcode 56/16/8. in
> /Users/rasmus/php53/run-tests.php on line 547
>
> Could we get a cleaner patch to have a look at? One that doesn't hurt
> my brain quite as much to get working?
>
Because he doesn't attached the regenerated zend_vm_execute.h in the
patch.
> Matt
A bit of a messy patch in that it doesn't have a single top-level
directory, but after hacking it, it applied. For others testing this,
make sure you run ext/tokenizer/tokenizer_data_gen.sh and of course
genfiles with the latest re2c.
I'm still not getting something that works though. Everyt
Stanislav Malyshev wrote:
Hi!
How can it break existing code? It's only on issue if a class is part
of a namespace, and existing code doesn't have namespaces. So it
*can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy t
Hi,
Over the past several months there have been various discussions about
PHP 6, and backwards compatibility, and what that entails, and seeming
it's come up again, I've finally written my thoughts:
Unicode is probably the biggest change, and the one that has the most
repercussions for b
Hello George,
sounds like you found a bug to me. We somehow need to have a request
variale that tracks whetehr the signal handling was activated. Since the
user could change the ini settings during the script, we either need to
disallow that (in case we don't yet) and can use the same checks as
Hello Stanislav,
I must be having a headache here. But there seriously seems to be a
misunderstanding.
We definitively introduced __construct as a bug fix in our language design.
And that is that you can have a function a in your class b that suddenly
becomes a constructor in the derived class
On 5/5/08, Pierre Joye <[EMAIL PROTECTED]> wrote:
> We can then even drop the old form in php 6.x. Many changes have no
> gain but make the language clearer or cleaner. It is not an objective
> change but it does help to cleanup the language.
>
> I will not die if we still support old things fo
On Mon, May 5, 2008 at 9:18 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
>
> > kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3 and
> remove in PHP 6.x.
> >
>
> There's nothing to fix, it's not broken.
Ok, point made. Once again a "you vs all other" thread, no
Hi!
kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3
and remove in PHP 6.x.
There's nothing to fix, it's not broken.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runti
Hi!
We can then even drop the old form in php 6.x. Many changes have no
gain but make the language clearer or cleaner. It is not an objective
change but it does help to cleanup the language.
There's nothing to "cleanup". You trying to prove that this form should
be removed by representing it
Seems that PHP engine is using ITIMER_PROF and SIGPROF for limiting
the max execution time of a php script, and gprof cannot produce
useful results.
Is there an option to turn it off temporarily? Is there a better tool
for code optimization?
IIRC if "max_execution_time" is 0 then timeout sho
On 05.05.2008, at 20:51, Pierre Joye wrote:
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
It's just simple to make constructors work in the same way in
namespaces and
out of them. It would be difficult to explain why the first script
prints
"ok" and the second do
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> It's just simple to make constructors work in the same way in namespaces and
> out of them. It would be difficult to explain why the first script prints
> "ok" and the second doesn't.
It is easy to explain: "You have to use
Hi!
Seems that PHP engine is using ITIMER_PROF and SIGPROF for limiting the
max execution time of a php script, and gprof cannot produce useful
results.
Is there an option to turn it off temporarily? Is there a better tool
for code optimization?
IIRC if "max_execution_time" is 0 then timeout
It's just simple to make constructors work in the same way in namespaces
and out of them. It would be difficult to explain why the first script
prints "ok" and the second doesn't.
I think, we must support old-style constructors for both cases or remove
them at all, but as I said removing t
Hi,
Seems that PHP engine is using ITIMER_PROF and SIGPROF for limiting the
max execution time of a php script, and gprof cannot produce useful
results.
Is there an option to turn it off temporarily? Is there a better tool
for code optimization?
Thanks,
George
--
PHP Internals - PHP Runtime
Hi!
code should be updated to use the normal constructor (which exists
since 4-5 years).
There's nothing "not normal" about using either form of constructors,
why force people to rewrite their perfectly good and working code?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
Hi!
How can it break existing code? It's only on issue if a class is part of
a namespace, and existing code doesn't have namespaces. So it *can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy to do. Forcing people to rena
On Mon, 5 May 2008, Dmitry Stogov wrote:
> As we didn't drop this support yet, and it didn't work in namespaces by
> mistake I've fixed it to work in the same way as without namespaces.
>
> Removing this support won't give any speedup (except of compilation speed),
> but might break a lot of code
Hi Dmitry,
On Mon, May 5, 2008 at 8:02 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> As we didn't drop this support yet, and it didn't work in namespaces by
> mistake I've fixed it to work in the same way as without namespaces.
>
> Removing this support won't give any speedup (except of compilat
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation
speed), but might break a lot of code.
Thanks. Dmitry.
Antony Dovgal wrote:
On 05.
Hi!
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
If by old-style ctors you mean this:
namespace Foo;
class Bar {
function Bar() {/* ctor! */}
}
then I think it should be su
Thanks Matt for the nice work :)
Also removed the ST_START_[HEREDOC|NOWDOC] states
in the scanner, by doing their work (to catch immediate ending label) in
the
initial heredoc rule.
This one was in my todo list as well. I think there might be other places
where a similar optimization can be
Pierre Joye escribió:
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
--
"Progress is possible only if we train ourselves to think about programs
without thinking of them as pieces o
Hi all,
This patch... Saves one opcode per interpolated string by moving what was
the first ADD_STRING/ADD_VAR op into INIT_STRING; changes the
ADD_[CHAR|STRING|VAR] op types from (TMP, ) to (,
UNUSED), since that seems to make more sense (see ADD_ARRAY_ELEMENT) and
simplifies things a bit, and s
in ext/date/ of php5/6, i see the following code
===config.m4=
cat > $ext_builddir/lib/timelib_config.h <
#endif
EOF
===config.w32=
var tl_config = FSO.CreateTextFile("ext/date/lib/timelib_config.h", true);
tl_config.WriteLine("#include \"config.w32.h\"");
tl_config.Close();
===
Arvids Godjuks wrote:
> Well, at least in my country i haven't saw any normal programmer not using
> unicode :)
I guess that was meant to be an ironic comment but I think we should
improve the signal-to-noise ration on internals again.
- Chris
--
PHP Internals - PHP Runtime Development Mailin
Well, at least in my country i haven't saw any normal programmer not using
unicode :)
2008/5/5 Christian Schneider <[EMAIL PROTECTED]>:
> Arvids Godjuks wrote:
> > Most normal developers are for years with utf-8 for now and even
> wouldn't
> > notice it.
>
> Sorry to destroy your pipe dream but t
Arvids Godjuks wrote:
> Most normal developers are for years with utf-8 for now and even wouldn't
> notice it.
Sorry to destroy your pipe dream but that's just not true.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Just use Unicode and don't even think about backward compability, because
thouse who need it most probably still are with PHP4 and MySQL 3.x
Most normal developers are for years with utf-8 for now and even wouldn't
notice it.
So +1 for pure Unicode. No switches. Lame hosting companies 100% will me
Dmitry Stogov schrieb:
- Fixed bug #44913 (Segfault when using return in combination with
nested loops and continue 2)
What about PHP_5_2?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Am 05.05.2008 um 09:51 schrieb Antony Dovgal:
On 04.05.2008 20:34, Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a
Derick Rethans wrote:
On Mon, 5 May 2008, Lester Caine wrote:
So from *MY* point of view unicode_semantics=on is creating a THIRD
case to have to manage? PLEASE can someone take charge and at least
get PHP6 moving forward to a stable alpha so that we have something
users can be happy to test
On 05.05.2008 14:13, Derick Rethans wrote:
Support for old-style constructors in namespaces
Do we really want/need this?
I'm not really sure either.
5.3 seems to be perfect candidate for dropping this kind of backward
compatibility.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime
On Mon, May 5, 2008 at 12:13 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 5 May 2008, Dmitry Stogov wrote:
>
> > dmitryMon May 5 09:44:07 2008 UTC
> >
> > Added files:
> > /ZendEngine2/testsns_063.phpt
> >
> > Modified files:
> > /ZendEngine2
On Mon, 5 May 2008, Dmitry Stogov wrote:
> dmitryMon May 5 09:44:07 2008 UTC
>
> Added files:
> /ZendEngine2/testsns_063.phpt
>
> Modified files:
> /ZendEngine2 zend_API.c zend_compile.c
> Log:
> Support for old-style
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (58 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
===
On 05.05.2008 12:44, Tomas Kuliavas wrote:
PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
No, they do not work in the same way.
I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
we could, but that's not always possible.
In my case they do.
This means your
>> PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
>
> No, they do not work in the same way.
> I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
> we could, but that's not always possible.
In my case they do.
--
Tomas
--
PHP Internals - PHP Runtime Developme
On Mon, 5 May 2008, Lester Caine wrote:
> So from *MY* point of view unicode_semantics=on is creating a THIRD
> case to have to manage? PLEASE can someone take charge and at least
> get PHP6 moving forward to a stable alpha so that we have something
> users can be happy to test against!
I thin
On 05.05.2008 12:16, Tomas Kuliavas wrote:
PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
No, they do not work in the same way.
I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
we could, but that's not always possible.
Same for PHP6 - there will be some d
Hi,
The company I work for has as a rule to update it's projects to the latest
php. This starts usually one month before the official release.
Can you tell me when will php 5.3 be released? Of course not the exact date
but something around it :) Like month?
Best Regards, Dimitar Isusov
> Lester Caine schrieb:
>> That sounds like just the sort of edge case that Derick is suggesting
>> needs logging for fixing up. unicode_semantics=on is just another bodge
>> to to make it happen rather than a solution. I think I understand your
>> description, and to my eyes it looks like a unicod
Lester Caine schrieb:
That sounds like just the sort of edge case that Derick is suggesting
needs logging for fixing up. unicode_semantics=on is just another bodge
to to make it happen rather than a solution. I think I understand your
description, and to my eyes it looks like a unicode bug that
>
>
> My biggest concern is the 2 code bases that need to be maintained by the
> PHP developers, you need to have two branches for handling unicode and
> native strings.
> To sum it up, unicode_semantics is in the exact same vain as
> ze1_compatability and it was a complete failure.
Totally agr
On 04.05.2008 20:34, Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the G
Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the Google Summer of Code
47 matches
Mail list logo
