Marcus Boerger wrote:
Hi Marcus Tony
Hello Zoe,
that's pretty fine. Instead of _[bveo][0-9]?.phpt you could do
_(basic|variation|error|object)[0-9]{3}.phpt. Which is a tad bit better.
However those are just filenames helping you to find the correct test
file while developing. For that
On 14/05/07, Greg Beaver [EMAIL PROTECTED] wrote:
... unicode is a killer
feature and PHP 6 will be adopted en masse, ... , it
will simply mean the death of userspace stream wrappers for anything but
custom projects.
Not being obtuse or antagonistic, just not understanding the
implications of
Hello Zoe, Marcus Tony,
Files names having _(basic|variation|error|object).phpt looks much better.
File names _[0-9]*.phpt does not give much detail about what are the
functions being testing by this testcase until one looks at the --TEST--
section of the file. It would be nice to have the
On 05/15/2007 11:52 AM, SoftVirus wrote:
Hello Zoe, Marcus Tony,
Files names having _(basic|variation|error|object).phpt looks much better.
File names _[0-9]*.phpt does not give much detail about what are the
functions being testing by this testcase until one looks at the --TEST--
section of
Antony Dovgal wrote:
On 05/15/2007 11:52 AM, SoftVirus wrote:
Hello Zoe, Marcus Tony,
Files names having _(basic|variation|error|object).phpt looks much
better.
File names _[0-9]*.phpt does not give much detail about what are the
functions being testing by this testcase until one looks at
On 05/15/2007 12:44 PM, Zoe Slattery wrote:
We're on it :-) Will probably have a few more questions on Unicode
testing later, noticed that you are putting UEXPECT section in tests-
but need to understand the implemenentation plan first...
We have two operation modes in PHP6 - native and
Hi all,
I've some problems with getAttribute* methods. I thing it is a bug, but
before send it, I'd like to propose a little test to you all, just to have
a confirmation (maybe is my installation only).
first the code and after the output I got on three different servers
Hi all,
I've some problems with getAttribute* methods. I thing it is a bug, but
before send it, I'd like to propose a little test to you all, just to have
a confirmation (maybe is my installation only).
first the code and after the output I got on three different servers
Antony Dovgal wrote:
On 05/15/2007 12:44 PM, Zoe Slattery wrote:
We're on it :-) Will probably have a few more questions on Unicode
testing later, noticed that you are putting UEXPECT section in tests-
but need to understand the implemenentation plan first...
We have two operation modes in
Richard Quadling wrote:
Not being obtuse or antagonistic, just not understanding the
implications of unicode, but why will unicode kill off userspace
stream wrappers?
It's not about unicode. It's just been argued that each userspace
stream wrapper will be marked as remote stream.
Regards,
--
Zoe Slattery wrote:
Antony Dovgal wrote:
On 05/15/2007 12:44 PM, Zoe Slattery wrote:
We're on it :-) Will probably have a few more questions on Unicode
testing later, noticed that you are putting UEXPECT section in
tests- but need to understand the implemenentation plan first...
We have two
On 05/15/2007 02:46 PM, Zoe Slattery wrote:
Antony Dovgal wrote:
On 05/15/2007 12:44 PM, Zoe Slattery wrote:
We're on it :-) Will probably have a few more questions on Unicode
testing later, noticed that you are putting UEXPECT section in tests-
but need to understand the implemenentation
Hello Zoe,
it ignores the php.ini more or less. You should be using run-tests.php
switches -u, -U and -N.
Try: php run-tests.php -h
best regards
marcus
Tuesday, May 15, 2007, 1:33:28 PM, you wrote:
Zoe Slattery wrote:
Antony Dovgal wrote:
On 05/15/2007 12:44 PM, Zoe Slattery wrote:
Hi
I have some updates that I'd like to make to
ext/tests/standard/array/range.phpt, the updates work fine with
unicode.semantics=off but not with unicode.semantics=on. The problem
seems to be that the warning Notices that are generated are different
with unicode on. This doesn't look like
On Tue, 15 May 2007, Zoe Slattery wrote:
I have some updates that I'd like to make to
ext/tests/standard/array/range.phpt, the updates work fine with
unicode.semantics=off but not with unicode.semantics=on. The problem seems to
be that the warning Notices that are generated are different with
Hello Zoe,
I did the same with a certain case in SPL. The result was that any
test run of 5.2.1 had failures on that test while as HEAD did not have
it anymore. The thing is that I used it to remind myself that i have
to merge the fix and to anybody else that this is not working correct
yet. In
From: Greg Beaver [mailto:[EMAIL PROTECTED]
Both phar/PHP_Archive and PHK support this. The only file
format that would allow this kind of shebang is the tar
file format, as the first element in the file is a filename.
The original design of PHP_Archive used the tar file format
to
On 05/15/2007 07:42 PM, Zoe Slattery wrote:
Hi
I have some updates that I'd like to make to
ext/tests/standard/array/range.phpt, the updates work fine with
unicode.semantics=off but not with unicode.semantics=on. The problem
seems to be that the warning Notices that are generated are
Hi folks,
Sorry to bother you, as I know you are quite busy, but I have a problem and
maybe a elegant solution does not exist right now.
The case is simple:
A user is allowed to upload files to the server, which are store in a
temporary location and their filenames are stored in the session.
Derick Rethans wrote:
On Tue, 15 May 2007, Zoe Slattery wrote:
I have some updates that I'd like to make to
ext/tests/standard/array/range.phpt, the updates work fine with
unicode.semantics=off but not with unicode.semantics=on. The problem seems to
be that the warning Notices that are
Emil Ivanov wrote:
The case is simple:
A user is allowed to upload files to the server, which are store in a
temporary location and their filenames are stored in the session.
The user leaves the site and the session gets destroyed, but the files
remain untouched.
If I can hook to the gc
On 05/15/2007 10:46 PM, Zoe Slattery wrote:
So. with unicode.semantics=on an additional Notice is generated which
appears to be caused by the echo statment. Any ideas?
Yes, I'll look into it a bit later.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To
Hello LAUPRETRE,
Tuesday, May 15, 2007, 7:12:27 PM, you wrote:
From: Greg Beaver [mailto:[EMAIL PROTECTED]
This is exactly how phar/PHP_Archive works. For example:
http://pear.php.net/go-pear.phar contains the complete
PHP_Archive class, which will fall back to the phar extension
if
Yes, noone hinders you to write PHP_Archieve into your stub when using
the Phar extension.
Actually, I would say it would be better to have some minimized
version which is extract-only, has all the comments stripped, etc. for
inclusion in the archives.
--
Stanislav Malyshev, Zend Products
jiania
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
Yes, noone hinders you to write PHP_Archieve into your stub when using
the Phar extension.
Actually, I would say it would be better to have some minimized
version which is extract-only, has all the comments stripped, etc. for
inclusion in the archives.
This is
26 matches
Mail list logo
