EWS doesn't hate it anymore!
Reviews welcome. I've been slowly integrating feedback as I've received it.
-Filip
> On Nov 4, 2016, at 11:52 AM, Filip Pizlo wrote:
>
> Haha, I'm fixing it!
>
> I could use a review of the time API even while I fix some broken corners in
>
Haha, I'm fixing it!
I could use a review of the time API even while I fix some broken corners in
WebCore and WK2.
-Filip
> On Nov 4, 2016, at 11:31 AM, Brent Fulgham wrote:
>
> EWS Hates your patch! :-)
>
>> On Nov 4, 2016, at 10:01 AM, Filip Pizlo
EWS Hates your patch! :-)
> On Nov 4, 2016, at 10:01 AM, Filip Pizlo wrote:
>
> Hi everyone!
>
> That last time we talked about this, there seemed to be a lot of agreement
> that we should go with the Seconds/MonotonicTime/WallTime approach.
>
> I have implemented it:
Hi everyone!
That last time we talked about this, there seemed to be a lot of agreement that
we should go with the Seconds/MonotonicTime/WallTime approach.
I have implemented it: https://bugs.webkit.org/show_bug.cgi?id=152045
That patch just takes a subset of our time code - all of the stuff
>> Can we go with “WallClock” and “MonotonicClock” instead of “WallTime” and
>> “MonotonicTime"? Clock is a nice clear noun. Also, time is an illusion
>> caused by parallax in the astral plane.
>
> I think time is the right term. "3pm" is a "time", not a "clock". Also 42
> seconds since
I think the actual issue here was that std::chrono::duration can't
represent infinite duration and some of our code has been hacking around
that with std::chrono::duration::max(). Clock time + duration is not going
to overflow if the duration is natural (a finite constant or produced by
diffing
On May 23, 2016, at 11:16 AM, Geoffrey Garen wrote:
>> 3 - There exists a solution - non-templated custom classes - that removes
>> both classes of subtle bugs, without the template creep.
>
> Hard to argue with this.
>
> Can we go with “WallClock” and “MonotonicClock”
> 3 - There exists a solution - non-templated custom classes - that removes
> both classes of subtle bugs, without the template creep.
Hard to argue with this.
Can we go with “WallClock” and “MonotonicClock” instead of “WallTime” and
“MonotonicTime"? Clock is a nice clear noun. Also, time is
ouble min() { return
> -std::numeric_limits::infinity(); }
> static constexpr double zero() { return .0; }
> static constexpr double max() { return
> std::numeric_limits::infinity(); }
> };
>
> }
> }
>
> Best regards,
> Michal Debski
>
>
+1 to Michael’s point. Naming of variables holding seconds/milliseconds is all
over the place.
So, I would favor using Seconds/WallTime/MonotonicTime classes, since they will
basically
guarantee that the variable name and/or type will describe the units near
use-sites and avoid
ambiguity.
Not
On Mon, 2016-05-23 at 07:27 -0700, Filip Pizło wrote:
> You guys are making a convincing case for
> Seconds/WallTime/MonotonicTime!
>
> -Filip
I will add: the convention "double means seconds" is very much not
obvious. It's OK when we're careful to consistently use "seconds" in
function and
You guys are making a convincing case for Seconds/WallTime/MonotonicTime!
-Filip
> On May 22, 2016, at 11:19 PM, Ryosuke Niwa wrote:
>
> I'm with Brady here. In WebCore, there are enough DOM and network
> APIs that mix wall time and monotonically increasing time (e.g. there
>>
>>
>>
>> namespace std {
>> namespace chrono {
>>
>> template<>
>> struct duration_values {
>> static constexpr double min() { return
>> -std::numeric_limits::infinity(); }
>> static constexpr double zero() { r
y(); }};}}
Best regards,Michal Debski
--- Original Message ---
Sender : Filip Pizlo<fpi...@apple.com>
Date : May 23, 2016 02:41 (GMT+01:00)
Title : [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time
Hi everyone!
I’d like us to stop using
r double min() { return
> -std::numeric_limits::infinity(); }
> static constexpr double zero() { return .0; }
> static constexpr double max() { return
> std::numeric_limits::infinity(); }
> };
>
> }
> }
>
> Best regards,
> Michal Debski
>
>
>
> --- Original Message
I'm with Brady here. In WebCore, there are enough DOM and network
APIs that mix wall time and monotonically increasing time (e.g. there
has been proposals to use monodically increasing time in
event.prototype.timeStamp even though various event related code
relies on it being a wall clock time)
return .0; } static constexpr double max() { return std::numeric_limits::infinity(); }};}}
Best regards,Michal Debski
--- Original Message ---
Sender : Filip Pizlo<fpi...@apple.com>
Date : May 23, 2016 02:41 (GMT+01:00)
Title : [webkit-dev] RFC: stop using std::chrono,
> On May 22, 2016, at 6:41 PM, Filip Pizlo wrote:
>
> Hi everyone!
>
> I’d like us to stop using std::chrono and go back to using doubles for time.
> First I list the things that I think we wanted to get from std::chrono - the
> reasons why we started switching to it in
Hi everyone!
I’d like us to stop using std::chrono and go back to using doubles for time.
First I list the things that I think we wanted to get from std::chrono - the
reasons why we started switching to it in the first place. Then I list some
disadvantages of std::chrono that we've seen from
19 matches
Mail list logo