Larry Garfield wrote:
On Thursday 14 August 2008 12:36:29 am Rasmus Lerdorf wrote:
Larry Garfield wrote:
I would also note that "include up front and have a good autoload scheme"
works great if you are writing all classes. If you're trying to use
namespaces and functions, there is no autoload.
On Thu, Aug 14, 2008 at 03:35, Daniel Convissor
<[EMAIL PROTECTED]> wrote:
> On Wed, Aug 13, 2008 at 06:32:37PM +0400, Antony Dovgal wrote:
>> On 13.08.2008 17:51, Daniel Convissor wrote:
>> >
>> >43817 is definitely a regression bug. Things worked correctly in 5.2.1
>> >and then got broken in 5.2
On Thursday 14 August 2008 12:36:29 am Rasmus Lerdorf wrote:
> Larry Garfield wrote:
> > I would also note that "include up front and have a good autoload scheme"
> > works great if you are writing all classes. If you're trying to use
> > namespaces and functions, there is no autoload. That makes
Larry Garfield wrote:
I would also note that "include up front and have a good autoload scheme"
works great if you are writing all classes. If you're trying to use
namespaces and functions, there is no autoload. That makes the autoload
argument moot, and pre-loading everything up front can get
On Wednesday 13 August 2008 6:00:21 pm Lukas Kahwe Smith wrote:
> >> Currently, if you include a file within a class method that contains
> >> function definitions, they remain functions outside the class. If
> >> you
> >> include a file that contains a class.
> >>
> >> In short, only global cpde
Hi,
On Thursday 14 August 2008 04:19:38 Rasmus Lerdorf wrote:
> Arnaud Le Blanc wrote:
> > - Apache effectively seems to resets the signals after MINIT, so original
> > handlers are now saved in RINIT in the first request of the process.
>
> Did you verify this behaviour with Apache2 as well? I'v
Arnaud Le Blanc wrote:
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first request of the process.
Did you verify this behaviour with Apache2 as well? I've only checked
Apache1.
-Rasmus
--
PHP Internals - PHP Runtime Devel
I read parts of the thread and I'm curious about a situation that
seems Marcus' patch will deny.
It seems that it'll be denied the possibility to require/include a
file inside of a method of a class/function inside a namespace.
Now I need to bring a situation where maybe Doctrine will implement.
W
On Wed, Aug 13, 2008 at 06:32:37PM +0400, Antony Dovgal wrote:
> On 13.08.2008 17:51, Daniel Convissor wrote:
> >
> >43817 is definitely a regression bug. Things worked correctly in 5.2.1
> >and then got broken in 5.2.2.
>
> Merging brand new realpath() implementation into a bugfix branch is not
Hi,
I made some changes to the patch:
http://arnaud.lb.s3.amazonaws.com/php-5.3.0-alarms-0808141122.patch
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first request of the process.
- Removed some unneeded blocks/unblocks.
- Cha
C++ is a superset of C thus any C code can be complied as C++ as long as
it doesn't use any
C++ reserved words.
That is not true at all, although it's a common misconception.
Just try the following in C and in C++:
printf("sizeof('x') == %d\n", (int)sizeof('x'));
(hint: they will give you diff
On 14.08.2008, at 00:54, Rasmus Lerdorf wrote:
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different
namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderst
Nuno Lopes wrote:
Antony Dovgal wrote:
On 13.08.2008 01:31, Phil Oleson wrote:
Thus the diff -u I sent in.. which resolves the above compiler
failure with g++.
Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
umm.. how?
cd ext/pspell
/usr/local/php5/bi
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous tim
Lukas Kahwe Smith wrote:
>
> On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
>
>> Simply include a script from two locations with different namespaces
>> or one
>>>
>>> with namespace and the otherone without.
>>
>> I'm afraid you misunderstand how namespaces work. As I explained
>> numerous t
Hi!
So one more thing. If people either explicitly require all their files
up front or make use of a properly designed autoload scheme, they will
side step this problem. So maybe the solution indeed is to have this
Which "this problem"? There's no problem there!
warning with a link to guide
On 14.08.2008, at 00:09, Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different
namespaces or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
nu
Hi!
I think Marcus is talking about files that are included that do not
specify a namespace explicitly. In this situation the context does matter.
No it does not. Would anybody check what they are talking about before
starting to discuss things?
--
Stanislav Malyshev, Zend Software Architect
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces are f
Antony Dovgal wrote:
On 13.08.2008 01:31, Phil Oleson wrote:
Thus the diff -u I sent in.. which resolves the above compiler failure
with g++.
Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
umm.. how?
cd ext/pspell
/usr/local/php5/bin/phpize
env CC=g++
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces are file-local, and this whe
Antony Dovgal wrote:
On 13.08.2008 01:31, Phil Oleson wrote:
Thus the diff -u I sent in.. which resolves the above compiler failure
with g++.
Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
umm.. how?
cd ext/pspell
/usr/local/php5/bin/phpize
env CC=g
Hi!
Simply include a script from two locations with different namespaces or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces are file-local, and this when including file,
it does not matter a bit what was
Hello Stanislav,
Wednesday, August 13, 2008, 10:01:10 PM, you wrote:
> Hi!
>> As painless as possible, so we want to tell people that they shouldn't just
>> write a shell script that adds the name of the directory as the namespace
>> or the name of the project an dthen never read the documentati
Hi!
As painless as possible, so we want to tell people that they shouldn't just
write a shell script that adds the name of the directory as the namespace
or the name of the project an dthen never read the documentation. We
No, unfortunately that won't work. I wish it did, but it would not :)
Hello Stanislav,
Wednesday, August 13, 2008, 8:29:43 PM, you wrote:
> Hi!
>> Once again, no code can trigger the warning right now. As the warning
>> requires a namespace before it can be triggered. Autoload should be
>> declared outside a namespace so that it can load correct namespace classes
Hi Stas,
Am Mittwoch, den 13.08.2008, 11:29 -0700 schrieb Stanislav Malyshev:
[...]
> As for the argument "there's no namespaced code so anything goes since
> we can't break any code" - it's bogus. We expect a lot of existing
> code to be converted to namespaces once 5.3 is out, and we want to
> m
Hi!
Once again, no code can trigger the warning right now. As the warning
requires a namespace before it can be triggered. Autoload should be
declared outside a namespace so that it can load correct namespace classes
anyway. So I do not see an issue here.
autoload can work just fine inside nam
Hi!
As far as I understood the discussion, it was related to OP code caches.
The opcode result from this snippet ...
These will generate identical opcodes except that the class name in the
former snippet would be Foo::Bar of course.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROT
Hi!
Namespaces are new, so it never worked before. But yes, this would trigger
a warning in the compiler which means you are told to not do this with apc
or other compiler caches.
This has very little to do with APC, AFAIU (it doesn't work differenty
with APC than without it), but anyway I th
Hello Lars,
Wednesday, August 13, 2008, 3:35:32 PM, you wrote:
> Hi Markus
> Am Mittwoch, den 13.08.2008, 15:21 +0200 schrieb Marcus Boerger:
> [...]
>> Namespaces are new, so it never worked before. But yes, this would trigger
>> a warning in the compiler which means you are told to not do this
Hi,
On Wednesday 13 August 2008 10:09:43 Dmitry Stogov wrote:
> Hi Lucas,
>
> I took a look into patch and I still don't like it.
> I may miss some things and make mistakes so correct me if I'm wrong.
>
> 1) It makes some slowdown for all SAPIs except Apache1, because it adds
> additional block/u
Hi Lukas,
Am Mittwoch, den 13.08.2008, 16:42 +0200 schrieb Lukas Kahwe Smith:
[...]
> Right, this is quite common. So is including drivers inside factory
> methods. Even if they are not explicit, there is obviously also
> autoload.
Which is not the same, as far as I understand the proposed mo
On 13.08.2008, at 15:35, Lars Strojny wrote:
Hi Markus
Am Mittwoch, den 13.08.2008, 15:21 +0200 schrieb Marcus Boerger:
[...]
Namespaces are new, so it never worked before. But yes, this would
trigger
a warning in the compiler which means you are told to not do this
with apc
or other comp
On 13.08.2008 17:51, Daniel Convissor wrote:
I don't think that would be justified.
This patch is definitely more than just a bugfix and 5.2 is a bugfix-only
release.
43817 is definitely a regression bug. Things worked correctly in 5.2.1
and then got broken in 5.2.2.
Merging brand new real
Hi Anthony:
On Wed, Aug 13, 2008 at 12:01:11PM +0400, Antony Dovgal wrote:
> On 13.08.2008 04:38, Daniel Convissor wrote:
> >Hi Dmitry:
> >
> >On Tue, Aug 12, 2008 at 08:01:24AM -, Dmitry Stogov wrote:
> >>
> >... snip ...
> >> - Fixed bug #43817 (opendir() fails on Windows directories with p
Hi Markus
Am Mittwoch, den 13.08.2008, 15:21 +0200 schrieb Marcus Boerger:
[...]
> Namespaces are new, so it never worked before. But yes, this would trigger
> a warning in the compiler which means you are told to not do this with apc
> or other compiler caches.
You are aware that this is used in
Hello Lars,
Wednesday, August 13, 2008, 11:55:23 AM, you wrote:
> Hi Markus,
> Am Dienstag, den 12.08.2008, 22:51 +0200 schrieb Marcus Boerger:
> [...]
>> a) Prevent include/require inside namespaced functions.
>>
>> Patch: php-no-include-in-namespaced-functions-6.0-20080812.diff.txt
>>
>> Sho
Hi Markus,
Am Dienstag, den 12.08.2008, 22:51 +0200 schrieb Marcus Boerger:
[...]
> a) Prevent include/require inside namespaced functions.
>
> Patch: php-no-include-in-namespaced-functions-6.0-20080812.diff.txt
>
> Should pretty much work.
So this means something like this won't work without a
now I see the main reason of the patch, but while APC is not a part of
PHP yet, it might be better, easer and safer to solve its issue in APC
itself (this is just a though, not a recommendation).
Anyway we need to make this patch better if we commit it, and I would
ask other community members
On 8/13/08 2:10 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I wasn't serious about removing them.
>
> Anyway zend_alloc.c and zend_hash.c don't work with shared memory.
> It's possible to reuse zend_alloc.c to allocate blocks from SHM, but
> it's not its primary purpose. If APC don't do it I
On 8/13/08 1:09 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I took a look into patch and I still don't like it.
> I may miss some things and make mistakes so correct me if I'm wrong.
> 1) It makes some slowdown for all SAPIs except Apache1, because it adds
> additional block/unblock code (mai
I wasn't serious about removing them.
Anyway zend_alloc.c and zend_hash.c don't work with shared memory.
It's possible to reuse zend_alloc.c to allocate blocks from SHM, but
it's not its primary purpose. If APC don't do it I don't see how this
block/unblock code may protect SHM. It definitely m
Dmitry Stogov wrote:
Hi Rasmus,
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional blo
Hi Rasmus,
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainl
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainly in zend_alloc.c)
This is the pa
On 13.08.2008 01:31, Phil Oleson wrote:
Thus the diff -u I sent in.. which resolves the above compiler failure with g++.
Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To un
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainly in zend_alloc.c)
2) It makes ~10 additional syscalls
On 13.08.2008 04:38, Daniel Convissor wrote:
Hi Dmitry:
On Tue, Aug 12, 2008 at 08:01:24AM -, Dmitry Stogov wrote:
... snip ...
- Fixed bug #43817 (opendir() fails on Windows directories with parent
directory unaccessible).
... snip ...
Can you please merge this down to 5.2?
I don
Sebastian Bergmann wrote:
I got a report about a segfault in PHP_5_2 and PHP_5_3 today that is
triggered by PHPUnit running the test below.
Fixed thanks to Dmitry!
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5
Hi Etienne,
I don't see serious issues in implementation except for I would prefer
to add checks if get_closure handler is NULL.
However in general I don't see any use case for this new handler.
From my point of view, it is always possible to use the Closures class
itself and I cannot imagine
51 matches
Mail list logo
