Hi all,
I've opened up default character encoding RFC for voting.
https://wiki.php.net/rfc/default_encoding
This RFC proposes consolidating character encoding setting.
Vote ends 2014/01/03.
Thank you for voting!
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Vote ends 2014/01/03.
Would you please consider extending the vote one more week because of the
holiday season / end of year festivities? Thanks.
Hi Levi,
On Sat, Dec 21, 2013 at 5:25 AM, Levi Morrison morrison.levi@gmail.comwrote:
Would you please consider extending the vote one more week because of the
holiday season / end of year festivities? Thanks.
Good suggestion!
I'll extend a week.
Thank you.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
Hi all,
I've opened up default character encoding RFC for voting.
https://wiki.php.net/rfc/default_encoding
This RFC proposes consolidating character encoding setting.
Vote ends 2014/01/03.Thank you for voting!
Not directly related to this vote, but ... how does one get to see the bottom of
the page? There are no scroll bars, and page down does not work? I presume that
the current voting IS at the bottom of the page?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Yasuo Ohgaki wrote:
Hi all,
I've opened up default character encoding RFC for voting.
https://wiki.php.net/rfc/default_encoding
This RFC proposes consolidating character encoding setting.
Vote ends 2014/01/03.Thank you for voting!
Not directly related to this vote, but ... how does one get to see the
bottom of the page? There are no scroll bars, and page down does not
work? I presume that the current voting IS at the bottom of the page?
Some CSS change seems to have broke it. While it's fine for me in modern
Firefox, trying it in Opera Mini on my phone, Android Browser (2.3.6
Gingerbread) or IE8 (Windows XP) fails and I can't scroll down.
I'd suggest you try using a newer browser until this is fixed.
--
Andrea Faulds
http://ajf.me/
Forwarded to right place ;)
Andrea Faulds wrote:
Some CSS change seems to have broke it. While it's fine for me in modern
Firefox, trying it in Opera Mini on my phone, Android Browser (2.3.6
Gingerbread) or IE8 (Windows XP) fails and I can't scroll down.I'd suggest you try using a newer browser until this is fixed.
I'm on the current version of Seamonkey on Linux already ...
This 'responsive' theme is simply not working for me. I'd changed the font size
to 150% to make it readable, so the table of contents had droped to the bottom
and is currently inaccessible. I'd not realised it WAS there as I could not
scroll down. Ditch the 'fixed bottom' ... it's not any use and is preventing a
normal scroll bar appearing.
Actually I'm now seeing several problems with each of the scale change setups.
Where should wiki bugs be reported?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Forwarded to right place ;)
Andrea Faulds wrote:
Some CSS change seems to have broke it. While it's fine for me in modern
Firefox, trying it in Opera Mini on my phone, Android Browser (2.3.6
Gingerbread) or IE8 (Windows XP) fails and I can't scroll down.I'd suggest you try using a newer browser until this is fixed.
I'm on the current version of Seamonkey on Linux already ...
This 'responsive' theme is simply not working for me. I'd changed the
font size to 150% to make it readable, so the table of contents had
droped to the bottom and is currently inaccessible. I'd not realised it
WAS there as I could not scroll down. Ditch the 'fixed bottom' ... it's
not any use and is preventing a normal scroll bar appearing.Actually I'm now seeing several problems with each of the scale change
setups. Where should wiki bugs be reported?
Did you shift-reload the page? This was fixed hours ago. At least the
fixed header/footer stuff.
-Rasmus
Rasmus Lerdorf wrote:
Forwarded to right place;)
Andrea Faulds wrote:
Some CSS change seems to have broke it. While it's fine for me in modern
Firefox, trying it in Opera Mini on my phone, Android Browser (2.3.6
Gingerbread) or IE8 (Windows XP) fails and I can't scroll down.I'd suggest you try using a newer browser until this is fixed.
I'm on the current version of Seamonkey on Linux already ...
This 'responsive' theme is simply not working for me. I'd changed the
font size to 150% to make it readable, so the table of contents had
droped to the bottom and is currently inaccessible. I'd not realised it
WAS there as I could not scroll down. Ditch the 'fixed bottom' ... it's
not any use and is preventing a normal scroll bar appearing.Actually I'm now seeing several problems with each of the scale change
setups. Where should wiki bugs be reported?
Did you shift-reload the page? This was fixed hours ago. At least the
fixed header/footer stuff.
Partially working better now ...
But the first time I looked was only a few hours ago perhaps ten minutes before
I posted.
The layout is simply wrong. Having a fixed little block floating in the middle
of the 'large' layout, and the table of contents not then fixed on the right is
just strange, but I have to stretch the browser out to get that ... 'middle'
mode is a lot more readable.
On the 'middle' layout which is the one I'm getting when I have the font at a
suitable size, having the table of content at the bottom is just wrong, it
should be either a popout at the top, or simply on top! And the fixed bar
getting hidden under the right hand side makes it difficult to get at.
In 'small' mode, there is a button for the top menu, but it does not work? All I
get is the truncated heading, body, toc and a big footer block.
Part of the problem is probably due to the changes in the way firefox/seamonkey
now handles 'scaling' of pages with our having lost the much better ability to
simply change font size. Now everything is scaled and that makes the style used
by sites more 'invasive' when font sizes are set for better readability. But
readability is equally bad on Dolphin on the android devices with 1/3 of the
screen now blank so one has to scroll a lot more to read something which used to
fill the whole screen. Devices have moved on considerably from what people think
is the right settings for 'default' widths :( If I could convince the website to
provide 'middle' mode on the android devices things would be a lot more readable.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
In 'small' mode, there is a button for the top menu, but it does not work?
Found that the 'hot spot' for the button is restricted to a small area to the
top right hand corner ... easier to hit with a touch screen ... but easy to miss
with the mouse unless you move to the right area.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
Not directly related to this vote, but ... how does one get to see the
bottom of the page? There are no scroll bars, and page down does not work?
I presume that the current voting IS at the bottom of the page?
https://wiki.php.net/rfc/default_encoding#vote
This link would work.
Thank you for point it out.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
https://wiki.php.net/rfc/default_encoding#vote
This link would work.
Thank you for point it out.
Actually, if you're affected by this, it doesn't work :(
--
Andrea Faulds
http://ajf.me/
I'm getting confused when reading your rfc.
mbstring.http_input (Default: php.output_encoding)
Is this correct? I think (Defualt: php.input_encoding) is correct.
2013/12/20 Yasuo Ohgaki yohgaki@ohgaki.net:
Hi all,
I've opened up default character encoding RFC for voting.
https://wiki.php.net/rfc/default_encoding
This RFC proposes consolidating character encoding setting.
Vote ends 2014/01/03.Thank you for voting!
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I'm getting confused when reading your rfc.
mbstring.http_input (Default: php.output_encoding)
Is this correct? I think
(Defualt: php.input_encoding)is correct.
Thank you for the correction.
I'll fix this now!
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
HI all,
I've opened up default character encoding RFC for voting.
https://wiki.php.net/rfc/default_encoding
This RFC proposes consolidating character encoding setting.
Vote ends 2014/01/03.
Since this RFC is accepted, I've created PR for review.
https://github.com/php/php-src/pull/568
Please comment. Thank you.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
Since this RFC is accepted, I've created PR for review.
https://github.com/php/php-src/pull/568
Please comment. Thank you.
If there is no comment, I'll commit this later.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
https://github.com/php/php-src/pull/568
Please comment. Thank you.
If there is no comment, I'll commit this later.
I see that some tests on Travis segfault with this patch. Could you
please check what's going on?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Sun, Jan 26, 2014 at 3:22 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
I see that some tests on Travis segfault with this patch. Could you
please check what's going on?
It's because these tests were skipped by mistake.
They were enabled only for 5.3 and less :(
Typical configuration works, but it's better to be resolved soon bugs.
I don't have much time now, so I hope someone has time to take care...
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Typical configuration works, but it's better to be resolved soon bugs.
I don't have much time now, so I hope someone has time to take care...
Well, we can not merge a patch that segfaults. So until this is fixed,
that patch is a no go.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Mon, Jan 27, 2014 at 5:15 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Typical configuration works, but it's better to be resolved soon bugs.
I don't have much time now, so I hope someone has time to take care...Well, we can not merge a patch that segfaults. So until this is fixed,
that patch is a no go.
The patch is not causing segfaults.
Zend engine is segfaulting for zend_multibyte tests.
It's a separate issue. You'll see segfaults in 5.4 and up without
my patch.
I've merged zend_multibyte tests fixes already. That's the reason why you
see failing tests on 5.4 and up.
It's a different issue and if nobody is willing to fix. I'll fix
zend_multibyte
next month.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
The patch is not causing segfaults.
Zend engine is segfaulting for zend_multibyte tests.
It's a separate issue. You'll see segfaults in 5.4 and up without
my patch.
No, I don't see segfaults on Travis tests without your patch, but I do
see it with your patch. Which tests are segfaulting without your patch
for you? This needs to be fixed ASAP, segfaults in core code is not a
good thing.
I've merged zend_multibyte tests fixes already. That's the reason why you
see failing tests on 5.4 and up.
I'm not sure I understand what you mean? If those are test fixes, how
come they cause tests to fail?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Mon, Jan 27, 2014 at 7:29 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
The patch is not causing segfaults.
Zend engine is segfaulting for zend_multibyte tests.
It's a separate issue. You'll see segfaults in 5.4 and up without
my patch.No, I don't see segfaults on Travis tests without your patch, but I do
see it with your patch. Which tests are segfaulting without your patch
for you? This needs to be fixed ASAP, segfaults in core code is not a
good thing.
Hmm, then it's my issue.
I'll check it ASAP. Thank you.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Mon, Jan 27, 2014 at 5:15 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Typical configuration works, but it's better to be resolved soon bugs.
I don't have much time now, so I hope someone has time to take care...Well, we can not merge a patch that segfaults. So until this is fixed,
that patch is a no go.The patch is not causing segfaults.
Zend engine is segfaulting for zend_multibyte tests.
It's a separate issue. You'll see segfaults in 5.4 and up without
my patch.I've merged zend_multibyte tests fixes already. That's the reason why you
see failing tests on 5.4 and up.It's a different issue and if nobody is willing to fix. I'll fix
zend_multibyte
next month.
For the record, I committed this patch to 5.4 and up.
As you can see, the patch is simply re-enabled tests for 5.4 and up.
(Note: there is no mbstring.script_encoding INI for 5.4 and up. It's
removed.)
The segfaults of zend engine are irrelevant for this proposal.
commit e769c96a1102f33e5783c35b7a7eedf5d81be7b9
Author: Yasuo Ohgaki yohgaki@php.net
Date: Sun Jan 19 13:28:48 2014 +0900
Enable zend.multibyte tests. Tipcal configuration works, but most tests
fail.
diff --git a/ext/mbstring/tests/zend_multibyte-01.phpt
b/ext/mbstring/tests/zend_multibyte-01.phpt
index d96e0f0..f2403ab 100644
--- a/ext/mbstring/tests/zend_multibyte-01.phpt
+++ b/ext/mbstring/tests/zend_multibyte-01.phpt
@@ -1,14 +1,9 @@
--TEST--
zend multibyte (1)
--SKIPIF--
-<?php
-ini_set("mbstring.script_encoding","SJIS");
-if (ini_set("mbstring.script_encoding","SJIS") != "SJIS") {
-
die("skip zend-multibyte is not available");
-}
-?>
--INI--
-mbstring.script_encoding=Shift_JIS
+zend.multibyte=On
+zend.script_encoding=Shift_JIS
mbstring.internal_encoding=Shift_JIS
--FILE--
<?php
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
For the record, I committed this patch to 5.4 and up.
You seem to be talking about different patch. The patch I am talking
about is https://github.com/php/php-src/pull/568, it was not committed
anywhere (and definitely not in 5.4 as it is targeted to be in 5.6) and
Travis shows segfaults on it (see
https://travis-ci.org/php/php-src/builds/17247814) which are not it
regular master Travis tests.
The segfaults of zend engine are irrelevant for this proposal.
I disagree, segfaults caused by the patch are very relevant.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Mon, Jan 27, 2014 at 7:35 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
For the record, I committed this patch to 5.4 and up.
You seem to be talking about different patch. The patch I am talking
about is https://github.com/php/php-src/pull/568, it was not committed
anywhere (and definitely not in 5.4 as it is targeted to be in 5.6) and
Travis shows segfaults on it (see
https://travis-ci.org/php/php-src/builds/17247814) which are not it
regular master Travis tests.The segfaults of zend engine are irrelevant for this proposal.
I disagree, segfaults caused by the patch are very relevant.
I fetched and merged changes from original php-src into my fork.
I shouldn't have done that :(
I'm guessing that's the reason why we see failed tests.
Finding out what's wrong now. Just a moment.
It takes time for rebuild and full tests.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Stas,
On Mon, Jan 27, 2014 at 7:35 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
For the record, I committed this patch to 5.4 and up.
You seem to be talking about different patch. The patch I am talking
about is https://github.com/php/php-src/pull/568, it was not committed
anywhere (and definitely not in 5.4 as it is targeted to be in 5.6) and
Travis shows segfaults on it (see
https://travis-ci.org/php/php-src/builds/17247814) which are not it
regular master Travis tests.The segfaults of zend engine are irrelevant for this proposal.
I disagree, segfaults caused by the patch are very relevant.
I fetched and merged changes from original php-src into my fork.
I shouldn't have done that :(I'm guessing that's the reason why we see failed tests.
Finding out what's wrong now. Just a moment.
It takes time for rebuild and full tests.
I'm running several rebuild and full tests now. It will take a while.
If there is problem, I'll fix them in this pull request.
Anyway, sorry for the confusion.
For the time being, we may mark zend_multibyte tests as XFAIL.
I'll make time to fix them later.
What do you think?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Mon, Jan 27, 2014 at 5:15 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Typical configuration works, but it's better to be resolved soon bugs.
I don't have much time now, so I hope someone has time to take care...Well, we can not merge a patch that segfaults. So until this is fixed,
that patch is a no go.The patch is not causing segfaults.
Zend engine is segfaulting for zend_multibyte tests.
It's a separate issue. You'll see segfaults in 5.4 and up without
my patch.I've merged zend_multibyte tests fixes already. That's the reason why you
see failing tests on 5.4 and up.It's a different issue and if nobody is willing to fix. I'll fix
zend_multibyte
next month.For the record, I committed this patch to 5.4 and up.
As you can see, the patch is simply re-enabled tests for 5.4 and up.
(Note: there is no mbstring.script_encoding INI for 5.4 and up. It's
removed.)
hi, it is a bit off-topic, but could you please send a patch for the
documentation about the mbstring.script_encoding ini change?
it seems that it isn't documented that we removed that ini
http://docs.php.net/manual/en/migration54.ini.php
that would also let us resolve these two issues:
https://bugs.php.net/bug.php?id=61232&edit=1
https://bugs.php.net/bug.php?id=65520&edit=1
thanks!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi Ferenc,
For the record, I committed this patch to 5.4 and up.
As you can see, the patch is simply re-enabled tests for 5.4 and up.
(Note: there is no mbstring.script_encoding INI for 5.4 and up. It's
removed.)hi, it is a bit off-topic, but could you please send a patch for the
documentation about the mbstring.script_encoding ini change?
it seems that it isn't documented that we removed that ini
http://docs.php.net/manual/en/migration54.ini.php
that would also let us resolve these two issues:
https://bugs.php.net/bug.php?id=61232&edit=1
https://bugs.php.net/bug.php?id=65520&edit=1thanks!
I don't know how this was missed. I didn't realized this change
until Bug #61232.
I've assigned them to myself.
I'll commit changes to doc later :)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
For the record, I committed this patch to 5.4 and up.
As you can see, the patch is simply re-enabled tests for 5.4 and up.
(Note: there is no mbstring.script_encoding INI for 5.4 and up. It's
removed.)hi, it is a bit off-topic, but could you please send a patch for the
documentation about the mbstring.script_encoding ini change?
it seems that it isn't documented that we removed that ini
http://docs.php.net/manual/en/migration54.ini.php
that would also let us resolve these two issues:
https://bugs.php.net/bug.php?id=61232&edit=1
https://bugs.php.net/bug.php?id=65520&edit=1thanks!
I don't know how this was missed. I didn't realized this change
until Bug #61232.I've assigned them to myself.
I'll commit changes to doc later :)
I also noticed that some of removed INIs are still mentioned in
php.ini-development/production.
e.g. session.bug_compat42, session.bug_compat_warn. There may be others.
It is probably better to be checked again...
I just don't have time to do it now.
Could anyone can check and remove them all?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
2014.01.27. 4:23, "Yasuo Ohgaki" yohgaki@ohgaki.net ezt írta:
Hi all,
For the record, I committed this patch to 5.4 and up.
As you can see, the patch is simply re-enabled tests for 5.4 and up.
(Note: there is no mbstring.script_encoding INI for 5.4 and up. It's
removed.)hi, it is a bit off-topic, but could you please send a patch for the
documentation about the mbstring.script_encoding ini change?
it seems that it isn't documented that we removed that ini
http://docs.php.net/manual/en/migration54.ini.php
that would also let us resolve these two issues:
https://bugs.php.net/bug.php?id=61232&edit=1
https://bugs.php.net/bug.php?id=65520&edit=1thanks!
I don't know how this was missed. I didn't realized this change
until Bug #61232.I've assigned them to myself.
I'll commit changes to doc later :)I also noticed that some of removed INIs are still mentioned in
php.ini-development/production.
e.g. session.bug_compat42, session.bug_compat_warn. There may be others.It is probably better to be checked again...
I just don't have time to do it now.
Could anyone can check and remove them all?
Sure.