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
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
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
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 de
pport concatenation of files at all costs?
> - We actually ship phar which allows to pack as many namespaced files
> in a single php file, no matter what namespace support we end up
> allowing.
> III) personal preference
> My preference is 3) and the next one would be 2) without fi
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 Runti
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 Developm
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!
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 sorry
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 perspe
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 apl
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 di
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, a
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 M
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 fai
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
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 qui
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 release
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 in
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 defa
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
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 su
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 bug
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.
>>> Y
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 take
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.
Re-ass
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 mor
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 havin
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
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
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 http://
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 pat
Hello Etienne,
Tuesday, August 12, 2008, 3:04:48 AM, you wrote:
> Hello,
> On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>>> but if the {} syntax is introduced, it will be made to affect only the
>>> code inside it, right? If so, I fail to see your poin
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 d
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 wit
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 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;
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
-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--
__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 peopl
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
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/../../../../.
42 matches
Mail list logo
