Hello everybody,
Am Dienstag, den 12.08.2008, 03:04 +0200 schrieb Etienne Kneuss:
[...]
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
namespace none;
code
Only nicer. And I can hardly how it's going
On Mon, Aug 11, 2008 at 23:41, Greg Beaver [EMAIL PROTECTED] wrote:
Dmitry Stogov wrote:
This behavior is already implemented in improved patch that I sent on
Saturday.
Thanks. Dmitry.
[snip]
What I mean is:
fopen(this_is_not_a_dir_but_a_file/../../../../../../../../etc/passwd,
r);
Does this change affect code like:
include ../file.php;
That will work fine.
I was thinking along the same line. I bet some people have been lazy
and used __FILE__. /../../foobar.php.
That will not work. And that is moronic code anyway. Why wouldn't they
use __DIR__ there?
-Rasmus
--
__FILE__. /../../foobar.php probably could work on Windows/BSD only,
but won't work anymore.
The patch is committed.
Thanks. Dmitry.
Rasmus Lerdorf wrote:
Does this change affect code like:
include ../file.php;
That will work fine.
I was thinking along the same line. I bet some people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Dmitry,
__FILE__. /../../foobar.php probably could work on Windows/BSD only,
but won't work anymore.
this works on Linux and everywhere where GLIBC is used, because GLIBC
realpath() supports this nonsense.
Stefan
-BEGIN PGP SIGNATURE-
realpath(__FILE__ . /..) doesn't work (returns false) on php-5.2
Linux, however include(__FILE__ . /../some.php) worked with 5.2.
Thanks. Dmitry.
Stefan Esser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Dmitry,
__FILE__. /../../foobar.php probably could work on Windows/BSD
Hello Lars,
Tuesday, August 12, 2008, 8:50:16 AM, you wrote:
Hello everybody,
Am Dienstag, den 12.08.2008, 03:04 +0200 schrieb Etienne Kneuss:
[...]
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
Hello Stanislav,
Tuesday, August 12, 2008, 2:45:12 AM, you wrote:
Hi!
3. You want another namespace, just write namespace again.
No, that's not for kids to play with. That's grown-up stuff. Rated X.
LOL, That pretty much defeats the whole KISS approach. I suggest we drop
that after all
Hello Marcus,
Am Dienstag, den 12.08.2008, 11:43 +0200 schrieb Marcus Boerger:
[...]
So you are saying that the current namespace is not a control structure?
It is, yes. But it is somewhat special (I'm having a hard time to
explain that better, sorry). This being special is well-expressed with
On Tue, Aug 12, 2008 at 09:56, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
I was thinking along the same line. I bet some people have been lazy
and used __FILE__. /../../foobar.php.
That will not work. And that is moronic code anyway. Why wouldn't they use
__DIR__ there?
Because it didn't
On 11.08.2008 21:54, Phil Oleson wrote:
Was running pspell through g++ and found that a couple of error conditions
segments in pspell.c
are using the wrong cleanup methods. delete_pspell_manager() should be
delete_pspell_can_have_error()
We'd certainly need some more details to get this
On 01.08.2008 14:11, Antony Dovgal wrote:
I can agree that disabling something that was already enabled in 5.2 might create
some confusion, but why enable scarcely created extensions by default, especially if
they are known to cause lost of obscure problems in the past (like Phar)?
See
hi,
On Tue, Aug 12, 2008 at 4:25 PM, Antony Dovgal [EMAIL PROTECTED] wrote:
On 01.08.2008 14:11, Antony Dovgal wrote:
I can agree that disabling something that was already enabled in 5.2 might
create some confusion, but why enable scarcely created extensions by
default, especially if they
Hello Antony,
Tuesday, August 12, 2008, 4:25:37 PM, you wrote:
On 01.08.2008 14:11, Antony Dovgal wrote:
I can agree that disabling something that was already enabled in 5.2 might
create
some confusion, but why enable scarcely created extensions by default,
especially if
they are known
On 12.08.2008 18:50, Pierre Joye wrote:
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?
I'm going to disable ext/phar before alpha2.
You've been warned.
Are you saying that you are going to disable every extension
On 12.08.2008 18:59, Marcus Boerger wrote:
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?
I'm going to disable ext/phar before alpha2.
You've been warned.
Fixed :-)
I'm sorry to say that, but the problem is far
Hi Tony,
No, I said I'm going to disable new extension that is known to cause
obscure problems in the past and that still does cause them at present,
and that was (mistakenly) enabled by default right after its creation.
That really wasn't an obscure bug once the user posted the dump.
Not so lately I read an article about compacting library files into one big
file and with opcode cache it gave 22 times faster aplication load.
Article is in russian, so thouse who can read it be my guest:
http://dklab.ru/chicken/nablas/49.html
For others I will make a quick summary.
What was
Hello Antony,
Tuesday, August 12, 2008, 5:05:08 PM, you wrote:
On 12.08.2008 18:59, Marcus Boerger wrote:
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?
I'm going to disable ext/phar before alpha2.
You've been
On 12.08.2008 19:12, Steph Fox wrote:
Hi Tony,
No, I said I'm going to disable new extension that is known to cause
obscure problems in the past and that still does cause them at present,
and that was (mistakenly) enabled by default right after its creation.
That really wasn't an obscure
On 12.08.2008 19:23, Marcus Boerger wrote:
If you still insist on disabling it, you should at least wait till we are
closer to release so that we get the chance to fix more of these.
Are you saying we need to enable by default all extensions in order to fix
their bugs?
I don't recall seeing
Hello Antony,
Tuesday, August 12, 2008, 5:27:54 PM, you wrote:
On 12.08.2008 19:12, Steph Fox wrote:
Hi Tony,
No, I said I'm going to disable new extension that is known to cause
obscure problems in the past and that still does cause them at present,
and that was (mistakenly) enabled by
Hello Antony,
Tuesday, August 12, 2008, 5:31:08 PM, you wrote:
On 12.08.2008 19:23, Marcus Boerger wrote:
If you still insist on disabling it, you should at least wait till we are
closer to release so that we get the chance to fix more of these.
Are you saying we need to enable by default
On 12.08.2008, at 17:31, Antony Dovgal wrote:
On 12.08.2008 19:23, Marcus Boerger wrote:
If you still insist on disabling it, you should at least wait till
we are
closer to release so that we get the chance to fix more of these.
Are you saying we need to enable by default all extensions
On 12.08.2008 19:36, Marcus Boerger wrote:
That would actually be a good thing to do. But seriously we decided to give
Phar a try, so we should stick to that until close to final release.
See, that's exactly what I said to Pierre ten minutes ago.
We'll keep it enabled until close to the
Hi Tony,
Not sure what you meant here, but I've been informed about it about 1 hour
ago.
Sorry - it was assigned to you, so I assumed you were aware it was actually
a Phar bug. My bad, I didn't reflect on just how many bugs are assigned to
you.
Surely asking how many bugs are left is
On 12.08.2008 19:35, Lukas Kahwe Smith wrote:
If we, the RMs, see that these extensions are not yet ready, we will
not hesitate to pull any of them. We will make such a decision before
we go into the RC phase. Until then it would be only fair to not push
the developers in question into such
On 12.08.2008, at 17:54, Antony Dovgal wrote:
On 12.08.2008 19:35, Lukas Kahwe Smith wrote:
If we, the RMs, see that these extensions are not yet ready, we
will not hesitate to pull any of them. We will make such a
decision before we go into the RC phase. Until then it would be
only
On 12.08.2008 19:49, Steph Fox wrote:
Sorry - it was assigned to you, so I assumed you were aware it was actually
a Phar bug. My bad, I didn't reflect on just how many bugs are assigned to
you.
I assigned it to me in order to keep track of it.
We've had two alphas and a beta release between
I assigned it to me in order to keep track of it.
Ack, it's not a *problem*, I'm very glad someone's doing that. Just this
time it meant there was an open Phar bug that none of the Phar team knew
existed for the last few weeks.
We've had two alphas and a beta release between March and now,
On 12.08.2008 20:02, Lukas Kahwe Smith wrote:
What result are you expecting?
That they are removed immediately?
That all bugs are instantly fixed?
That the previous decisions of enabling by default of these extensions
is revoked in light of bugs being found in the alpha phase of 5.3?
No, I
On 12.08.2008, at 18:19, Antony Dovgal wrote:
Therefor, I'd expect some kind of plan like wait for X weeks or
till X alpha, then check the number of bugs fixed. If it's still too
high - the extensions are apparently not ready., or wait till
alphaX, then start voting, or wait till aplhaX
Hi!
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
Again, my point exactly. The above construction - which {} syntax
encourages you to use - should never be used at all!
My point is that if we are going to allow multiple namespaces per file
solely on the
Hi!
So you are saying that the current namespace is not a control structure?
Simple fact is that is is not. It doesn't even exist at runtime, so it
hardly can control execution.
And you are also saying that we are python where whitespace has a
semantical and syntactical meaning? I am
Hi!
LOL, That pretty much defeats the whole KISS approach. I suggest we drop
that after all then.
PHP always had some areas that are not as simple as others (references
for one). Maybe we should just close the project and go play Tetris?
That's very unproductive position - do it as I want or
Hi,
I am sorry, but I cannot keep up with this thread. Is anyone even
presenting novel arguments? This is why I asked for a vote and not
more discussion. I guess my mistake was for asking for a summary.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime
On 8/11/08 8:52 AM, Dmitry Stogov [EMAIL PROTECTED] wrote:
I'll try to review it on Tuesday/Wednesday.
Thanks. Dmitry.
I've just updated the patches. Only some very minor changes as discussed
before and they should cleanly apply against current cvs.
-lucas
--
PHP Internals - PHP Runtime
the
following:
a) Prevent include/require inside namespaced functions.
Patch: php-no-include-in-namespaced-functions-6.0-20080812.diff.txt
Should pretty much work.
b) Allow both 'namspace foo;' as well as 'namespace foo {}'.
Patch: php-namespaces-with-curlies-6.0-20080812.diff.txt
Note
Antony Dovgal wrote:
On 11.08.2008 21:54, Phil Oleson wrote:
Was running pspell through g++ and found that a couple of error
conditions segments in pspell.c
are using the wrong cleanup methods. delete_pspell_manager() should
be delete_pspell_can_have_error()
We'd certainly need some more
Antony Dovgal wrote:
On 01.08.2008 14:11, Antony Dovgal wrote:
I can agree that disabling something that was already enabled in 5.2
might create some confusion, but why enable scarcely created
extensions by default, especially if they are known to cause lost of
obscure problems in the past
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.
class MyObject {
public function getX() {
return NULL;
}
}
class MyTest extends PHPUnit_Framework_TestCase {
public function
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?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D
42 matches
Mail list logo
