Tony Cook
2015-08-11 11:07:05 UTC
[Hours] [Activity]
2015/08/03 Monday
0.03 #124062 reject
0.93 #124064 research, comment
0.27 #124066 review, testing, apply to blead
0.18 fix homepage for XSLoader
0.30 #125711 review, testing and apply to blead
0.10 #125737 comment
0.85 #125630 research, testing, comment
0.08 #123543 review and resolve
0.08 #125721 review and comment
0.58 #120826 re-work documentation patch
=====
3.40
2015/08/04 Tuesday
1.42 #125740 testing, ask author about which email address
0.48 #125723 review each of ticket, code, fix
1.22 32-bit solaris math.t failures (similar to cygwin?)
=====
3.12
2015/08/05 Wednesday
2.15 #125710 testing, comment
0.25 #120826 re-test, apply to blead, close
0.38 #125467 check new site, produce a patch and comment
0.60 #125557 research and comment
0.52 #123905 check if fixed, find it was, look for commit and
comment and close
=====
3.90
2015/08/06 Thursday
0.88 #125710 research, testing and comment
0.83 #125751 read over patch
1.48 #125751 research and comment
0.25 #125619 review and comment
0.77 review current state of utf8_strict
1.33 #125760 write up sysread/write() utf-8 RFC and post as
ticket
=====
5.54
Which I calculate is 15.96 hours.
Approximately 18 tickets were reviewed or worked on, and 3 patches
were applied.
[perl #125710] is a ticket I opened myself. I originally noticed that
smokes were consistently failing in ext/POSIX/t/math.t on cygwin.
This test created a signalling NaN value and then checked that the NaN
remained signalling.
I tested a few other platforms and found it passed on 64-bit
(amd64/x86_64) Intel system, but failed on several 32-bit x86 builds,
including on Linux and Solaris, but passed on 32-bit ARM.
The problem turned out to be an interaction between the x87 behaviour
built into any CPU from the 80486 onwards[1] and the ABI for 32-bit
x86 platforms which returns floating point values in x87 registers.
The problem is when loading a 64-bit double into an 80-bit x87 FPU
register a conversion is done that changes any signalling NaN to
non-signalling.
If perl is built with long doubles the conversion isn't done and the
NaNs remain signalling, and the test passes.
This isn't a problem for the 64-bit ABIs, since floating point values
(other than long double) are returned in the SSE registers. (Win32
might be different)
[1] and in the original 80387 FPU
2015/08/03 Monday
0.03 #124062 reject
0.93 #124064 research, comment
0.27 #124066 review, testing, apply to blead
0.18 fix homepage for XSLoader
0.30 #125711 review, testing and apply to blead
0.10 #125737 comment
0.85 #125630 research, testing, comment
0.08 #123543 review and resolve
0.08 #125721 review and comment
0.58 #120826 re-work documentation patch
=====
3.40
2015/08/04 Tuesday
1.42 #125740 testing, ask author about which email address
0.48 #125723 review each of ticket, code, fix
1.22 32-bit solaris math.t failures (similar to cygwin?)
=====
3.12
2015/08/05 Wednesday
2.15 #125710 testing, comment
0.25 #120826 re-test, apply to blead, close
0.38 #125467 check new site, produce a patch and comment
0.60 #125557 research and comment
0.52 #123905 check if fixed, find it was, look for commit and
comment and close
=====
3.90
2015/08/06 Thursday
0.88 #125710 research, testing and comment
0.83 #125751 read over patch
1.48 #125751 research and comment
0.25 #125619 review and comment
0.77 review current state of utf8_strict
1.33 #125760 write up sysread/write() utf-8 RFC and post as
ticket
=====
5.54
Which I calculate is 15.96 hours.
Approximately 18 tickets were reviewed or worked on, and 3 patches
were applied.
[perl #125710] is a ticket I opened myself. I originally noticed that
smokes were consistently failing in ext/POSIX/t/math.t on cygwin.
This test created a signalling NaN value and then checked that the NaN
remained signalling.
I tested a few other platforms and found it passed on 64-bit
(amd64/x86_64) Intel system, but failed on several 32-bit x86 builds,
including on Linux and Solaris, but passed on 32-bit ARM.
The problem turned out to be an interaction between the x87 behaviour
built into any CPU from the 80486 onwards[1] and the ABI for 32-bit
x86 platforms which returns floating point values in x87 registers.
The problem is when loading a 64-bit double into an 80-bit x87 FPU
register a conversion is done that changes any signalling NaN to
non-signalling.
If perl is built with long doubles the conversion isn't done and the
NaNs remain signalling, and the test passes.
This isn't a problem for the 64-bit ABIs, since floating point values
(other than long double) are returned in the SSE registers. (Win32
might be different)
[1] and in the original 80387 FPU