Re: [PHP-DEV] Tests - and a question
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 reason we didn not do so much about
generating those files. We Only made it briefly and suggested a three
digit numbering scheme. After all th ename in --TEST.. is the important
thing.
Thanks for the responses - you have both made the same point that it's
the --TEST-- section that should really give a descriptive title. Marcus
- I like your suggestion of basic|variation etc better than our
current b|v etc scheme. Raghu - are you OK to switch to longer test case
names?
I think the test names are important to some degree - if you are trying
to look for a testcase for a particular function it is easier to look at
file names than to have to grep for the function name in a test title.
Is there a mapping between the functions listed in the functional ref
and their test cases? This kind of thing would be useful to us so I was
thinking I'd write one. It's probably lazy of me :-) but I'd just like
to click on a function name and go straight to a list of existing test
cases.
You also both made the same point that shorter tests are better and I
think we can improve here - although we have been making an effort to
make the output readable.
Thanks for the effort into test writing!!!
best regards
marcus
Monday, May 14, 2007, 6:43:51 PM, you wrote:
Hi all
We added a few tests for array, string and variable handling functions
at the weekend. As always - any feedback will be welcome.
One thing we had some difficulty with was keeping the test output small
enough to be easily read. We chose to divide up tests like this:
test_name_b.phptb=basic function
test_name_v.phptv=variation
test_name_e.phpte=error cases
test_name_o.phpto=object specific
This may not be the right scheme and I'm happy to change it if anyone
has better suggestions, although it is useful to seperate out the error
case tests because quite a lot of the differences between php5 and php6
seem to be in the exact form of the error message. Using this doesn't
completely solve the problem anyway - I think some of the v tests will
will end up being test_name_v1, test_name_v2 etc.
Thanks, Zoe
IBM UK
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Userspace stream wrappers and Unicode.
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 unicode, but why will unicode kill off userspace stream wrappers? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests - and a question
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 name of the testcase
accomodate name of the functions that are being tested. For example if
009.phpt is written to test basic functionality of current() and next()
functions, the better file name could be current_next_basic.phpt.
Regards,
Raghubansh, IBM India
On 5/15/07, Zoe Slattery [EMAIL PROTECTED] wrote:
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 reason we didn not do so much about
generating those files. We Only made it briefly and suggested a three
digit numbering scheme. After all th ename in --TEST.. is the important
thing.
Thanks for the responses - you have both made the same point that it's
the --TEST-- section that should really give a descriptive title. Marcus
- I like your suggestion of basic|variation etc better than our
current b|v etc scheme. Raghu - are you OK to switch to longer test case
names?
I think the test names are important to some degree - if you are trying
to look for a testcase for a particular function it is easier to look at
file names than to have to grep for the function name in a test title.
Is there a mapping between the functions listed in the functional ref
and their test cases? This kind of thing would be useful to us so I was
thinking I'd write one. It's probably lazy of me :-) but I'd just like
to click on a function name and go straight to a list of existing test
cases.
You also both made the same point that shorter tests are better and I
think we can improve here - although we have been making an effort to
make the output readable.
Thanks for the effort into test writing!!!
best regards
marcus
Monday, May 14, 2007, 6:43:51 PM, you wrote:
Hi all
We added a few tests for array, string and variable handling functions
at the weekend. As always - any feedback will be welcome.
One thing we had some difficulty with was keeping the test output small
enough to be easily read. We chose to divide up tests like this:
test_name_b.phptb=basic function
test_name_v.phptv=variation
test_name_e.phpte=error cases
test_name_o.phpto=object specific
This may not be the right scheme and I'm happy to change it if anyone
has better suggestions, although it is useful to seperate out the error
case tests because quite a lot of the differences between php5 and php6
seem to be in the exact form of the error message. Using this doesn't
completely solve the problem anyway - I think some of the v tests
will
will end up being test_name_v1, test_name_v2 etc.
Thanks, Zoe
IBM UK
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
with Regards,
Raghubansh
Re: [PHP-DEV] Tests - and a question
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 the file. It would be nice to have the name of the testcase accomodate name of the functions that are being tested. For example if 009.phpt is written to test basic functionality of current() and next() functions, the better file name could be current_next_basic.phpt. Well, aesthetically - yes, current_next_basic might look better to those who don't like numbers. But you still have to open the test and read its --TEST-- section contents to learn what exactly it's testing. That said, I'm happy with both func_b.phpt and func_basic.phpt (and even 009.phpt) =) We just need more tests, doesn't matter what their names look like. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests - and a question
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 the --TEST-- section of the file. It would be nice to have the name of the testcase accomodate name of the functions that are being tested. For example if 009.phpt is written to test basic functionality of current() and next() functions, the better file name could be current_next_basic.phpt. Well, aesthetically - yes, current_next_basic might look better to those who don't like numbers. But you still have to open the test and read its --TEST-- section contents to learn what exactly it's testing. That said, I'm happy with both func_b.phpt and func_basic.phpt (and even 009.phpt) =) We just need more tests, doesn't matter what their names look like. 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... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests - and a question
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 Unicode. In these modes expected output of the same test may differ very much. That's why in some cases we have to use two expected output sections - EXPECT(F) for native and UEXPECT(F) for Unicode mode. * There is also UEXPECTREGEX - similar to EXPECTREGEX, but used in Unicode mode. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] dom strange behaviours
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
-
?php
$doc = 'rootnode xml:id=one at=onefirst node/nodenode
xml:id=two at=twosecond node/node/root';
$xmlDoc = new DOMDocument();
$xmlDoc-loadXML($doc);
$nodeList=$xmlDoc-getElementsByTagName('node');
echo 'Current PHP version: ' . phpversion().\n\n;
//echo $xmlDoc-saveXML();
foreach($nodeList as $node){
echo getting id\n;
echo --\n;
echo \tgetAttribute('id'):.$node-getAttribute('id').\n;
echo \tgetAttribute('xml:id'):.$node-getAttribute('xml:id').\n;
echo
\tgetAttributeNS('xml','id'):.$node-getAttributeNS('xml','id').\n.\n;
echo \tgetAttribute('at'):.$node-getAttribute('id').\n;
echo \tgetAttribute('xml:at'):.$node-getAttribute('xml:id').\n;
echo
\tgetAttributeNS('xml','at'):.$node-getAttributeNS('xml','id').\n.\n;
}
//phpinfo();
?
-
Current PHP version: 5.2.1
getting id
--
getAttribute('id'):
getAttribute('xml:id'):one
getAttributeNS('xml','id'):
getAttribute('at'):
getAttribute('xml:at'):one
getAttributeNS('xml','at'):
getting id
--
getAttribute('id'):
getAttribute('xml:id'):two
getAttributeNS('xml','id'):
getAttribute('at'):
getAttribute('xml:at'):two
getAttributeNS('xml','at'):
Current PHP version: 5.1.6
getting id
--
getAttribute('id'):one
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):one
getAttribute('xml:at'):
getAttributeNS('xml','at'):
getting id
--
getAttribute('id'):two
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):two
getAttribute('xml:at'):
getAttributeNS('xml','at'):
Current PHP version: 5.1.4
getting id
--
getAttribute('id'):one
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):one
getAttribute('xml:at'):
getAttributeNS('xml','at'):
getting id
--
getAttribute('id'):two
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):two
getAttribute('xml:at'):
getAttributeNS('xml','at'):
[PHP-DEV] dom strange behaviours
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
-
?php
$doc = 'rootnode xml:id=one at=onefirst node/nodenode
xml:id=two at=twosecond node/node/root';
$xmlDoc = new DOMDocument();
$xmlDoc-loadXML($doc);
$nodeList=$xmlDoc-getElementsByTagName('node');
echo 'Current PHP version: ' . phpversion().\n\n;
//echo $xmlDoc-saveXML();
foreach($nodeList as $node){
echo getting id\n;
echo --\n;
echo \tgetAttribute('id'):.$node-getAttribute('id').\n;
echo \tgetAttribute('xml:id'):.$node-getAttribute('xml:id').\n;
echo
\tgetAttributeNS('xml','id'):.$node-getAttributeNS('xml','id').\n.\n;
echo \tgetAttribute('at'):.$node-getAttribute('id').\n;
echo \tgetAttribute('xml:at'):.$node-getAttribute('xml:id').\n;
echo
\tgetAttributeNS('xml','at'):.$node-getAttributeNS('xml','id').\n.\n;
}
//phpinfo();
?
-
Current PHP version: 5.2.1
getting id
--
getAttribute('id'):
getAttribute('xml:id'):one
getAttributeNS('xml','id'):
getAttribute('at'):
getAttribute('xml:at'):one
getAttributeNS('xml','at'):
getting id
--
getAttribute('id'):
getAttribute('xml:id'):two
getAttributeNS('xml','id'):
getAttribute('at'):
getAttribute('xml:at'):two
getAttributeNS('xml','at'):
Current PHP version: 5.1.6
getting id
--
getAttribute('id'):one
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):one
getAttribute('xml:at'):
getAttributeNS('xml','at'):
getting id
--
getAttribute('id'):two
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):two
getAttribute('xml:at'):
getAttributeNS('xml','at'):
Current PHP version: 5.1.4
getting id
--
getAttribute('id'):one
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):one
getAttribute('xml:at'):
getAttributeNS('xml','at'):
getting id
--
getAttribute('id'):two
getAttribute('xml:id'):
getAttributeNS('xml','id'):
getAttribute('at'):two
getAttribute('xml:at'):
getAttributeNS('xml','at'):
Re: [PHP-DEV] Tests - and a question
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 PHP6 - native and Unicode. In these modes expected output of the same test may differ very much. That's why in some cases we have to use two expected output sections - EXPECT(F) for native and UEXPECT(F) for Unicode mode. Thanks - I've just been looking at this and would like to confirm that I've understood it. We can have both --EXEPECT(F)-- and --UEXPECT(F)-- in a PHPT file. In PHP5 run-tests.php will just ignore the --U.*-- sections. In PHP6 run-tests.php will use the --U.*-- sections if unicode_semantics=on and ignore the corresponding --EXPECT(F)-- sections. If unicode_semantics=off PHP6 will behave the same way as PHP5. Correct? Or is it more complicated that that? * There is also UEXPECTREGEX - similar to EXPECTREGEX, but used in Unicode mode. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Userspace stream wrappers and Unicode.
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, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests - and a question
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 operation modes in PHP6 - native and Unicode. In these modes expected output of the same test may differ very much. That's why in some cases we have to use two expected output sections - EXPECT(F) for native and UEXPECT(F) for Unicode mode. Thanks - I've just been looking at this and would like to confirm that I've understood it. We can have both --EXEPECT(F)-- and --UEXPECT(F)-- in a PHPT file. In PHP5 run-tests.php will just ignore the --U.*-- sections. In PHP6 run-tests.php will use the --U.*-- sections if unicode_semantics=on and ignore the corresponding --EXPECT(F)-- sections. If unicode_semantics=off PHP6 will behave the same way as PHP5. Correct? Or is it more complicated that that? Hmm - this isn't quite right. I get the test to behave differently with an --INI-- section which uses unicode_semantics=on/off, but not when I use a php.ini file... * There is also UEXPECTREGEX - similar to EXPECTREGEX, but used in Unicode mode. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests - and a question
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 plan first... We have two operation modes in PHP6 - native and Unicode. In these modes expected output of the same test may differ very much. That's why in some cases we have to use two expected output sections - EXPECT(F) for native and UEXPECT(F) for Unicode mode. Thanks - I've just been looking at this and would like to confirm that I've understood it. We can have both --EXEPECT(F)-- and --UEXPECT(F)-- in a PHPT file. In PHP5 run-tests.php will just ignore the --U.*-- sections. In PHP6 run-tests.php will use the --U.*-- sections if unicode_semantics=on and ignore the corresponding --EXPECT(F)-- sections. If unicode_semantics=off PHP6 will behave the same way as PHP5. Correct? Or is it more complicated that that? Yup, everything is correct. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests - and a question
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: 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 Unicode. In these modes expected output of the same test may differ very much. That's why in some cases we have to use two expected output sections - EXPECT(F) for native and UEXPECT(F) for Unicode mode. Thanks - I've just been looking at this and would like to confirm that I've understood it. We can have both --EXEPECT(F)-- and --UEXPECT(F)-- in a PHPT file. In PHP5 run-tests.php will just ignore the --U.*-- sections. In PHP6 run-tests.php will use the --U.*-- sections if unicode_semantics=on and ignore the corresponding --EXPECT(F)-- sections. If unicode_semantics=off PHP6 will behave the same way as PHP5. Correct? Or is it more complicated that that? Hmm - this isn't quite right. I get the test to behave differently with an --INI-- section which uses unicode_semantics=on/off, but not when I use a php.ini file... * There is also UEXPECTREGEX - similar to EXPECTREGEX, but used in Unicode mode. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Committing failing tests?
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 intentional behaviour but I'm guessing it might well be something that isn't implemented yet. So, my question is - is it reasonable/helpful to add a test in CVS that I know will fail if it's in an area that is currently under development? Zoe Slattery IBM UK -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Committing failing tests?
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 unicode on. This doesn't look like intentional behaviour but I'm guessing it might well be something that isn't implemented yet. So, my question is - is it reasonable/helpful to add a test in CVS that I know will fail if it's in an area that is currently under development? I would say that it's a good idea to commit those if you are certain that the unicode behavior is wrong. In other cases I suggest to write a mail to internals about it. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Committing failing tests?
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 this case however you need to keep track of changes in the area because sometimes the actual fix chnages the resulting output a bit from the original expectation. So you should stay in touch with the actual developer, of course at least informing him of the error. best regards marcus Tuesday, May 15, 2007, 5:42:40 PM, you 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 intentional behaviour but I'm guessing it might well be something that isn't implemented yet. So, my question is - is it reasonable/helpful to add a test in CVS that I know will fail if it's in an area that is currently under development? Zoe Slattery IBM UK Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : RE : [PHP-DEV] [RFC] Starting 5.3
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 take advantage of this hack. So, if we want to base our format on tar, we will have to put a file with an exotic name as first element. As, anyway, the package file cannot be written via the tar command (because of this ugly first file, and probably because we'll want the next file to be a binary/serialized file map), I don't see a big benefit there. I mean a public RCS like a CVS or SVN server. I found the PHK_Creator package and looked at it in order to review the source code. Yes, I'd like to store it on such a server. But I don't know these systems very well. I planned to put it on sourceforge but I didn't have enough time yet. 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 available. But you say in the doc that the stub can contain any code terminated by an __halt_compiler(); ? I don't understand. If a phar archive is generated by the phar extension, it does not include the PHP_Archive runtime code, right ? So, it cannot run without the phar extension installed. Am I wrong ? I am probably unclear with my argument here. After a deep review of the source code, it seems to me that PHK is basically PHP_Archive with a different file format plus a few built in extras and a separate website. In other words, at the time you started the PHK project, PHP_Archive was fully functioning (version 0.6.0, released on 2005-08-30) and was backed by the officiality of being served from PEAR, a php.net site. Rather than attempt to inject your interesting ideas for the future of PHP_Archive, you seem to have actively avoided PHP_Archive and re-invented the wheel. Actually, there is a reason, PHK was not the first step... The first step was the autoloader. When it was ready, I started thinking of a sort of jar feature for PHK. So, of course, I looked at PHP_Archive to see if I could integrate my autoloader. But, at this time (end 2005), there was not much documentation and the first tests showed that the PHP_Archive'd package checked if it was run as 'main file'. When I tried to include it, I got an error message saying that it had to be the first script to run. So, as I wanted to make library packages, I started a small project which became PHK, without 'actively avoiding' PHP_Archive. I also must say that, yes, I tend to consider that a project whose only documentation is the source code is not a good development base. Maybe it is too theoritical but, IMO, a project without any doc is not 'fully functioning' :) Now, PHP_Archive has evolved into phar and, yes, PHK provides almost every features present in phar. But, where I disagree, is when you say that it just add 'a few built in extras and a separate website'. If you look at the code, you will see that these 'few built-in extras' represent more than 80 % of the product. I think the difference here is the way we consider these 'built-in extras'. I try to consider them from a non-expert point of view, and I try to imagine what can convince and/or seduce an average user. So, by providing demo packages, building kits, and an extensive documentation, I try to solve the problems a newcomer can meet. This is the way I always work. It is not a pleasure but a way to provide something to be considered as a 'product'. You seem to under-estimate the work it needs to design and build these 'few built-in extras': one year ago, I had quite the same features you provide in PHP_Archive/phar today. But I chose to spend several hundreds more hours on the remaining 'few built-in extras'. To resume, when I read phar's doc, I see a tool to be used by people like you or me, people with a (very) good knowledge and experience in PHP, and able to build the 'glue' scripts they need. That's what you consider 'easy', because it would be easy for you. I also find it easy, but my goal with PHK is not to provide a tool that can be used by, maybe, 100 people in the world. To resume, I consider that the features I added upon phar-like bare features are more important than you think. They are at least as important as the low-level ones. Actually, when I had to determine where to stop, I decided that, for most cases, a packager does not have to explicitely use the stream wrapper. It is now the case and the stream wrapper and every underlying features can be considered as advanced features. By contast, in phar, these low-level features are... the only ones available. I hate to be the one to burst our bubble, but unicode is a killer feature and PHP 6 will be adopted en masse, so if this isn't
[PHP-DEV] Re: Committing failing tests?
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 different with unicode on. This doesn't look like intentional behaviour but I'm guessing it might well be something that isn't implemented yet. So, my question is - is it reasonable/helpful to add a test in CVS that I know will fail if it's in an area that is currently under development? Definitely yes. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] register_session_gc_handler proposal
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. The user leaves the site and the session gets destroyed, but the files remain untouched. If I can hook to the gc session function that will solve my case, but currently with session_set_save_handler I have to rewrite session handling, which I don't need... So a simple hook will be very useful. I know there are problems as how will I know which entry has been destroyed... Regards, Emil Ivanov Sofia univesity -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Committing failing tests?
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 generated are different with unicode on.
This doesn't look like intentional behaviour but I'm guessing it might well be
something that isn't implemented yet.
So, my question is - is it reasonable/helpful to add a test in CVS that I know
will fail if it's in an area that is currently under development?
I would say that it's a good idea to commit those if you are certain
that the unicode behavior is wrong. In other cases I suggest to write
a mail to internals about it.
I've looked at this a bit more and have absolutely no idea whether the
behaviour that I get is expected or not, it is certainly different. So,
here is a very cutdown test case that shows the difference. Note that
it's not intended to do anything sensible - I've just pulled it out of a
larger test caes that executes range() with all sorts of input.
This passes fine on PHP6 with unicode.semantics=off.
--TEST--
PHP6 unicode Notices different
--FILE--
?php
$low_arr = ABCD;
$high_arr = array(1,2);
echo \n-- creating an array with low = '$low_arr' and high =
'$high_arr' --\n;
var_dump( range( $low_arr, $high_arr ) );
--EXPECTF--
-- creating an array with low = 'ABCD' and high = 'Array' --
Notice: Array to string conversion in %s on line %d
array(1) {
[0]=
string(1) A
}
--UEXPECTF--
-- creating an array with low = 'ABCD' and high = 'Array' --
Notice: Array to string conversion in %s on line %d
array(1) {
[0]=
unicode(1) A
}
Here is the actual output on PHP6
Notice: Array to string conversion in /home/zoe/TESTS/range/ztest.php on
line 5
-- creating an array with low = 'ABCD' and high = 'Array' --
Notice: Array to string conversion in /home/zoe/TESTS/range/ztest.php on
line 6
array(1) {
[0]=
unicode(1) A
}
So. with unicode.semantics=on an additional Notice is generated which
appears to be caused by the echo statment. Any ideas?
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register_session_gc_handler proposal
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 session function that will solve my case, but
currently with session_set_save_handler I have to rewrite session handling,
which I don't need...
So a simple hook will be very useful.
Hi,
I've also been looking into how this could be implemented elegantly and
I'd like to propose the following:
- Create a class exposed to userland called something like
SessionDefaultHandler, which wraps the session module defined at startup.
- Alter session_set_save_handler() to alternatively take a single
argument, a class name.
- The given handler class must extend SessionDefaultHandler and may
override any of its methods.
- Alter the user session module to use the child class if it's been
registered.
This would provide an elegant solution to your particular problem, as
well as allowing any default session functions to be overridden, wrapped
or called independently.
?php
class MySessionHandler extends SessionDefaultHandler {
function gc($maxlifetime)
{
parent::gc($maxlifetime);
$time = time();
foreach (glob('images/*') as $file) {
if ($time - filemtime($file) $maxlifetime) {
unlink($file);
}
}
return true;
}
}
session_set_save_handler('MySessionHandler');
?
Any thoughts?
Arpad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Committing failing tests?
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 unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RE : RE : [PHP-DEV] [RFC] Starting 5.3
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 available. But you say in the doc that the stub can contain any code terminated by an __halt_compiler(); ? I don't understand. If a phar archive is generated by the phar extension, it does not include the PHP_Archive runtime code, right ? So, it cannot run without the phar extension installed. Am I wrong Yes, noone hinders you to write PHP_Archieve into your stub when using the Phar extension. I am probably unclear with my argument here. After a deep review of the source code, it seems to me that PHK is basically PHP_Archive with a different file format plus a few built in extras and a separate website. In other words, at the time you started the PHK project, PHP_Archive was fully functioning (version 0.6.0, released on 2005-08-30) and was backed by the officiality of being served from PEAR, a php.net site. Rather than attempt to inject your interesting ideas for the future of PHP_Archive, you seem to have actively avoided PHP_Archive and re-invented the wheel. Actually, there is a reason, PHK was not the first step... The first step was the autoloader. When it was ready, I started thinking of a sort of jar feature for PHK. So, of course, I looked at PHP_Archive to see if I could integrate my autoloader. But, at this time (end 2005), there was not much documentation and the first tests showed that the PHP_Archive'd package checked if it was run as 'main file'. When I tried to include it, I got an error message saying that it had to be the first script to run. So, as I wanted to make library packages, I started a small project which became PHK, without 'actively avoiding' PHP_Archive. I also must say that, yes, I tend to consider that a project whose only documentation is the source code is not a good development base. Maybe it is too theoritical but, IMO, a project without any doc is not 'fully functioning' :) Well the limitations you encountered back then are long gone. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : RE : [PHP-DEV] [RFC] Starting 5.3
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 Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: jiania
jiania -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : RE : [PHP-DEV] [RFC] Starting 5.3
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 extremely easy to do with phar, perhaps this is best done
through documentation? Such a script would be extremely short and would
definitely be cut-and-pasteable, for instance:
?php
$here = dirname(__FILE__) . DIRECTORY_SEPARATOR . basename(__FILE__,
'.phar');
mkdir($here);
foreach (new RecursiveIteratorIterator(
new RecursiveDirectoryIterator('phar://' . __FILE__)) as $path
= $unused) {
$newpath = $here . DIRECTORY_SEPARATOR . str_replace('/',
DIRECTORY_SEPARATOR,
str_replace('phar://' . __FILE__ . '/', '', $path));
if (!file_exists(dirname($newpath))) mkdir(dirname($newpath), 0664,
true);
copy($path, $newpath);
}
__HALT_COMPILER();
Setting the stub is really easy:
$phar-setStub($code);
where $code contains the stuff above as a string, or as an open file
pointer to the file stub. The minimal script might want to instead use
$argv[1] or even display a web form, depending on the context - this is
the primary reason we didn't hard-code a massive stub. By default, the
stub created by making a phar is designed for a minimal non-extract
library, but phar is designed with enough flexibility that is is not
just easy but remarkably simple to do extremely complex stuff with the
stub or with the contents. In fact, it is much easier than either
PHP_Archive or PHK, and this is a direct result of features that are not
possible with a userspace stream. One can argue over their utility but
the original reason behind making PHP_Archive into an extension is no
longer the only reason.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
