Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)

[Jani Taskinen]

Dmitry Stogov wrote:

David Zülke wrote:

On 28.07.2009, at 13:32, Dmitry Stogov wrote:


Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.

The only thing I didn't understood - why win32/php_stdint.h is needed.

Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a dependency
on ext/date; I think I had trouble compiling ext/soap as a standalone
extension like this. Must check again. Any hints?


I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.


ext/date is not an extension, it's part of core, just like ext/standard so you 
shouldn't have any problems with it.


--Jani



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP floating point history and behaviour.

[Kalle Sommer Nielsen]

Hi

2009/7/28 Lupus Michaelis :
>  Hi,
>
>  I'm wondering where the Zend/zend_float.h include file is used. I'm
> interested in because I'm checking the behaviour variation between PHP4 and
> PHP5 (*), and floating point management seems to be fixed for all platforms
> in an early version of PHP5 (revision r270301).
>
>  By the way, this alteration change something for Intel 32 bit or nothong ?
> It belongs the IEEE 754 ?
>

The floating point behaviour was changed in PHP 5.3, as in this RFC by
Christian Seiler (cc'ed):
http://wiki.php.net/rfc/rounding

You can find where the zend_float.h file is included by a simple grep:
C:\php\src\> grep -ri "zend_float" *
Zend/zend_execute_API.c:#include "zend_float.h"
Zend/zend_float.c:#include "zend_float.h"
Zend/zend_float.h:/* $Id: zend_float.h 277398 2009-03-18 10:18:10Z dmitry $ */
Zend/zend_float.h:#ifndef ZEND_FLOAT_H
Zend/zend_float.h:#define ZEND_FLOAT_H

-- 
regrads,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

[Jani Taskinen]

Gwynne Raskind wrote:

On Jul 27, 2009, at 6:31 PM, Takeshi Abe wrote:

Just to be sure, is there any consensus on this? I thought I should
use svn merge.

README.SVN-RULES says

   1. All changes should first go to trunk and then get merged from trunk
  (aka MFH'ed) to all other relevant branches.

which I've been following so far.


That document is outdated. It's now (strongly) preferred that you use 
one of the various methods for multi-branch commits available in SVN, 
using merge or a sparse checkout.


It's only sparse checkout that works for us.

--Jani


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP floating point history and behaviour.

[Lupus Michaelis]

  Hi,

  I'm wondering where the Zend/zend_float.h include file is used. I'm 
interested in because I'm checking the behaviour variation between PHP4 
and PHP5 (*), and floating point management seems to be fixed for all 
platforms in an early version of PHP5 (revision r270301).


  By the way, this alteration change something for Intel 32 bit or 
nothong ? It belongs the IEEE 754 ?


  Thanks !

(*) I'm not guilty.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: date extension timezonedb generation

[Derick Rethans]

On Wed, 15 Jul 2009, Joe Orton wrote:

> Derick, do you make available the scripts used to generate timezonedb.h?

They're at http://cvs.xdebug.org/cgi-bin/viewvc.cgi/timelib/zones/
> 
> Are you using the location co-ordinates from zone.tab in the "Olson" 
> database?

Yes, but there was a tiny bug with the sign. It's fixed now in SVN, 
thanks for the report.

regards,
Derick

-- 
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)

[Dmitry Stogov]

David Zülke wrote:
> On 28.07.2009, at 13:32, Dmitry Stogov wrote:
> 
>> Hi David,
>>
>> I took only a quick look, but I like the patch.
>> In case it doesn't break any tests, it should be committed at least into
>> HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.
>>
>> The only thing I didn't understood - why win32/php_stdint.h is needed.
> 
> Ah, yes, that's probably an oversight. Good catch. The headers were
> copy-pasted from some ext/date file :)
> 
> Another thing that just occured to me is that we now have a dependency
> on ext/date; I think I had trouble compiling ext/soap as a standalone
> extension like this. Must check again. Any hints?

I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.

Thanks. Dmitry.

> - David
> 
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)

[David Zülke]

On 28.07.2009, at 13:32, Dmitry Stogov wrote:


Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least  
into
HEAD. I agree to commit it into 5.3 too, but RMs take the final  
decision.


The only thing I didn't understood - why win32/php_stdint.h is needed.


Ah, yes, that's probably an oversight. Good catch. The headers were  
copy-pasted from some ext/date file :)


Another thing that just occured to me is that we now have a dependency  
on ext/date; I think I had trouble compiling ext/soap as a standalone  
extension like this. Must check again. Any hints?


- David




smime.p7s
Description: S/MIME cryptographic signature

[PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)

[Dmitry Stogov]

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.

The only thing I didn't understood - why win32/php_stdint.h is needed.

Thanks. Dmitry.

David Zülke wrote:
> *bump*
> 
> Dmitry, did you have a chance to review this patch yet?
> 
> - David
> 
> 
> On 22.06.2009, at 15:21, David Zülke wrote:
> 
>> Hi folks,
>>
>> attached is a patch (with the respective test cases) that implements
>> DateTime marshalling from and to xsd:dateTime in ext/soap as requested
>> in http://bugs.php.net/44383
>>
>> Right now, it is implemented for xsd:date, xsd:time and xsd:dateTime,
>> but not for other types defined in W3C XML Schema such as gDayMonth; I
>> don't really think it makes sense mapping from and to DateTimes in
>> this case (from DateTime to gDayMonth would work, but the other way
>> round would prove rather difficult).
>>
>> Some notes about this patch:
>> - it conforms strictly to the XML Schema specification by only
>> producing canonical representations of values when generating
>> xsd:dateTime and xsd:time values. Specifically:
>> - it will not generate trailing zeroes on microseconds (in other
>> words, it simply generates a fractional second part as mandated by the
>> specification), but it will accept such values
>> - UTC is always used as the timezone (one of the tests in
>> ext/date/tests that mirrors SBR1-echoDate from
>> http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/#SBR1-echoDate 
>> currently
>> does this wrong), but it will accept any timezone
>> - xsd:time produces current date when generating a DateTime object
>> - xsd:date is relatively straightfoward as well:
>> - produces "00:00:00" as the time when creating a DateTime object
>> - accepts any time when parsing
>> - also supports timezones
>> - as a side effect of the patch, microseconds are now supported in
>> time values (for xsd:time and xsd:dateTime), hence the removed comment
>> in to_xml_time
>>
>> The tests have several permutations, but all but one is commented out
>> each. The test_schema() function does some odd (but understandable)
>> stunts with output buffering and global variables that make it
>> impossible to test more than one case at a time. We didn't want to
>> produce a million test files for the several variants; is there a
>> nicer way to test this properly?
>>
>> This feature is enabled by a SoapClient "feature" called
>> SOAP_MARSHAL_DATETIME. I think this is a reasonable choice.
>>
>> Greetings,
>>
>> David
>>
>> 
>>
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

[Lukas Kahwe Smith]

On 28.07.2009, at 01:38, Takeshi Abe wrote:


Hi,

On Mon, 27 Jul 2009 18:44:20 -0400, Gwynne Raskind > wrote:

README.SVN-RULES says

  1. All changes should first go to trunk and then get merged from  
trunk

 (aka MFH'ed) to all other relevant branches.

which I've been following so far.


That document is outdated. It's now (strongly) preferred that you  
use one of the
various methods for multi-branch commits available in SVN, using  
merge or a

sparse checkout.

Yes, I agree svn merge will work well.
IIRC, though, it involves a leading commit for trunk (usually, or  
sometimes for

some branch whatever) and then merged ones for other branches.
Are such sereval commits OK?



I think so yes.
However I think we should standardize on one approach: svnmerge only  
makes sense if everybody uses it.
Personally I favor the svnmerge approach if this also enables us to  
more easily setup a temporary RM maintained branch ahead of a release  
to prevent commit freeze periods.


For extensions we can of course leave it to the extension maintainer,  
however there is no way to ensure that people are aware of what  
merging approach is used in the given extension, so this is also not  
really feasible.


regards,
Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)

[David Zülke]

*bump*

Dmitry, did you have a chance to review this patch yet?

- David


On 22.06.2009, at 15:21, David Zülke wrote:


Hi folks,

attached is a patch (with the respective test cases) that implements  
DateTime marshalling from and to xsd:dateTime in ext/soap as  
requested in http://bugs.php.net/44383


Right now, it is implemented for xsd:date, xsd:time and  
xsd:dateTime, but not for other types defined in W3C XML Schema such  
as gDayMonth; I don't really think it makes sense mapping from and  
to DateTimes in this case (from DateTime to gDayMonth would work,  
but the other way round would prove rather difficult).


Some notes about this patch:
- it conforms strictly to the XML Schema specification by only  
producing canonical representations of values when generating  
xsd:dateTime and xsd:time values. Specifically:
- it will not generate trailing zeroes on microseconds (in other  
words, it simply generates a fractional second part as mandated by  
the specification), but it will accept such values
- UTC is always used as the timezone (one of the tests in ext/date/ 
tests that mirrors SBR1-echoDate from http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/#SBR1-echoDate 
 currently does this wrong), but it will accept any timezone

- xsd:time produces current date when generating a DateTime object
- xsd:date is relatively straightfoward as well:
- produces "00:00:00" as the time when creating a DateTime object
- accepts any time when parsing
- also supports timezones
- as a side effect of the patch, microseconds are now supported in  
time values (for xsd:time and xsd:dateTime), hence the removed  
comment in to_xml_time


The tests have several permutations, but all but one is commented  
out each. The test_schema() function does some odd (but  
understandable) stunts with output buffering and global variables  
that make it impossible to test more than one case at a time. We  
didn't want to produce a million test files for the several  
variants; is there a nicer way to test this properly?


This feature is enabled by a SoapClient "feature" called  
SOAP_MARSHAL_DATETIME. I think this is a reasonable choice.


Greetings,

David

< 
schema089 
.phpt 
> 
< 
soap_marshal_datatype 
.diff 
.txt 
> 
< 
schema087 
.phpt>




smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

[Rasmus Lerdorf]

Moriyoshi Koizumi wrote:
> Incorporating the changes and merges across the branches into one
> commit under a sparse-layouted local copy doesn't do the book-keeping
> against svn:mergeinfo.  That's why I suppose it is not a good idea.

I don't think a merge will work the way we use branches though.  Once
you merge you aren't supposed to keep making changes on the branch.

merge is good for when you create a branch to work on some larger
feature and when it is ready you merge it into trunk and continue
working on it in trunk.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Alternative mbstring implementation using ICU

[Moriyoshi Koizumi]

I set up a RFC page for this in wiki.php.net.  Here it goes:
http://wiki.php.net/rfc/altmbstring

Moriyoshi

2009/7/26 Moriyoshi Koizumi :
> Hi there,
>
> I almost finished an alternative implementation of mbstring that uses
> ICU instead of the exotic libmbfl in hope of replacing the current one
> for 5.4 (and possibly, 6.0.)
>
> Although there are admittingly some known incompatibilities that need
> extra libraries to resolve them besides a number of missing functions
> that are intentionally removed for simplicity's sake, frequently used
> functions are fully usable, and more compliant with the standard (e.g.
> case insensitive matches).
>
> Any comments are appreciated.
>
> The source is ready in the following location:
>
> http://github.com/moriyoshi/mbstring-ng/
>
>
> Implemented functions:
>
> - mb_convert_encoding()
> - mb_detect_encoding()
> - mb_ereg()
> - mb_ereg_replace()
> - mb_internal_encoding()
> - mb_list_encodings()
> - mb_output_handler()
> - mb_parse_str()
> - mb_preferred_mime_name()
> - mb_regex_set_options()
> - mb_split()
> - mb_strcut()
> - mb_strimwidth()
> - mb_stripos()
> - mb_stristr()
> - mb_strlen()
> - mb_strpos()
> - mb_strripos()
> - mb_strrpos()
> - mb_strstr()
> - mb_strtolower()
> - mb_strtotitle()
> - mb_strtoupper()
> - mb_strwidth()
> - mb_substr()
> - mb_substr_count()
>
> Removed functions and reasons behind it:
>
> - mb_check_encoding()
>  Not that usable as it is advertised, period.  First of all, validation
>  in terms of encoding is just as same as filtering through the
>  converter supplied with the same value for the input and output
>  encoding.  Thus just use mb_convert_encoding().
>
> - mb_convert_case()
>  Use mb_strtoupper(), mb_strtolower() and mb_strtotitle()
>
> - mb_convert_kana()
>  This can't be standard-compliant. In addition, part of the
>  functionality is already covered by Normalizer of intl extension, so
>  we need to carefully consider what is actually needed here again.
>
> - mb_convert_variables()
>  This can be implemented as a script.
>
> - mb_decode_mimeheader(), mb_encode_mimeheader()
>  Non-standard compliancy.
>
> - mb_decode_numericentity()
>  Removed in favor of html_entity_decode().
>
> - mb_encode_numericentity()
>  Removed in favor of htmlentities() and htmlspecialchars().
>
> - mb_encoding_aliases()
>  Just unnecessary.
>
> - mb_ereg_match()
>  Use mb_ereg().
>
> - mb_ereg_search(), mb_ereg_search_getpos(), mb_ereg_search_getregs(),
>  mb_ereg_search_init(), mb_ereg_search_pos(), mb_ereg_search_regs() and
>  mb_ereg_search_setpos()
>  I rarely heard a script that actively uses these functions. They
>  involve an internal state that is not visible to users, and thus it
>  most likely causes confusion when used across the function calls.
>  Need to be reimplemented as a class.
>
> - mb_eregi()
>  Use mb_regex_options() and mb_ereg()
>
> - mb_eregi_replace()
>  I wonder why this function was added in the first place because giving
>  'i' option to mb_ereg_replace() works in the same way.
>
> - mb_detect_order(), mb_get_info(), mb_http_input(), mb_http_output(),
>  mb_language() and mb_substitute_character()
>  ini_set() and ini_get() are your friend, I guess...
>
> - mb_regex_encoding()
>  It is really confusing that the current mbstring allows two different
>  encoding defaults that are applied to regex functions and the rest.
>  Those settings are unified in the alternative version and so this is
>  no longer necessary.
>
> - mb_send_mail()
>  The behavior of this function relies on the pseudo-locale setting
>  called "mbstring.language" that supports just a limited set of
>  possible locales. As not everyone can benefit from the function and
>  most significant applications implement their own mail functions, I
>  suppose this is no longer wanted.
>
> - mb_strrchr()
>  Use mb_strrpos().
>
> - mb_strrichr()
>  Use mb_strripos().
>
>
> Known limitations and incompatibilities:
>
> - mb_detect_encoding() doesn't work well anymore due to the
>  inaccuracy of ICU's encoding detection facility.
>
> - Request encoding translator now takes advantage of SAPI filter,
>  therefore the name parts of the query components are not to be
>  converted anymore.
>
> - The group reference placeholders for mb_ereg_replace() is now
>  $0, $1, $2... instead of \0, \1, \2.  This can be avoided if we
>  don't use uregex_replaceAll() and implement our own.
>
> - ILP64 :-p
>
>
> Regards,
> Moriyoshi
>
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] are there alternate interfaces to the bug tracking system?

[Sandro Tosi]

On Sat, Jul 4, 2009 at 18:32, Sandro Tosi wrote:
> Hi all,
>
> On Sat, Jul 4, 2009 at 18:20, Sean Coates wrote:
>>> so what i'm wondering is: is there an easily parseable or structured
>>> interface (xmlrpc, soap, read-only JSON export, whatever) to the php.net
>>> bts
>>> that could be used to get a bug's information?  or would such a bts-link
>>> service need to resort to scraping the page for a particular bug's status?
>>
>> Not sure if this really helps you (and I agree that the bug system really
>> needs some sort of better programmatic interface), but you can translate
>> most bugs.php.net pages into rss (which is easier to parse than HTML...
>> usually (-: ) by prepending rss/ to the URL. This useful for reading.
>>
>> For example:
>> http://bugs.php.net/bug.php?id=46944
>> becomes:
>> http://bugs.php.net/rss/bug.php?id=46944
>
> yeah, I'll probably follow this way, but using the format=xml parameter:
>
> http://bugs.php.net/rss/bug.php?format=xml&id=46944
>
> that seems better for programmatical parsing.

FYI: I've implemented the parsing using the rss xml ouput. In case
some development is done on this side, please keep me in the loop :)

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

[Moriyoshi Koizumi]

Incorporating the changes and merges across the branches into one
commit under a sparse-layouted local copy doesn't do the book-keeping
against svn:mergeinfo.  That's why I suppose it is not a good idea.

Moriyoshi

On Tue, Jul 28, 2009 at 7:44 AM, Gwynne Raskind wrote:
> On Jul 27, 2009, at 6:31 PM, Takeshi Abe wrote:
>>>
>>> Just to be sure, is there any consensus on this? I thought I should
>>> use svn merge.
>>
>> README.SVN-RULES says
>>
>>   1. All changes should first go to trunk and then get merged from trunk
>>      (aka MFH'ed) to all other relevant branches.
>>
>> which I've been following so far.
>
> That document is outdated. It's now (strongly) preferred that you use one of
> the various methods for multi-branch commits available in SVN, using merge
> or a sparse checkout.
>
> -- Gwynne
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: ext/iconv/tests/bug16069.phpt

[Moriyoshi Koizumi]

That is a test that is involved in the iconv's transilteration
feature, the behavior of which may vary by the platform you use.  I
guess we don't actually need to test it then.

Moriyoshi

On Tue, Jul 28, 2009 at 12:27 PM, Rasmus Lerdorf wrote:
> Moriyoshi, or someone who knows CP932 and EUC-JP, could you please have
> a look at ext/iconv/tests/bug16069.phpt
>
> It is failing in all the branches, so I am assuming the expected output
> listed in the test is wrong, but I am a bit lost in figuring out how to
> tell what is going wrong at byte 113 into the output there.
>
> -Rasmus
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php