console: sub-millisecond accuracy for console.time by targos · Pull Request #3166 · nodejs/node

targos · 2015-10-03T10:27:58Z

This makes the output of console.timeEnd in line with major browsers.

targos · 2015-10-03T11:25:22Z

I just pushed an update to the doc.

thefourtheye · 2015-10-03T11:54:44Z

Why this change is necessary?

Edit: Ah, I see it now. That is kind of the point of this PR

Bikeshedding: this belongs to the first commit «console: sub-millisecond accuracy for console.time», not to «doc: reword description of console.time».

I moved this change to the first commit

Trott · 2015-10-03T15:47:36Z

Should it be semver-minor? More of an enhancement than a bug fix?

Trott · 2015-10-03T15:51:58Z

LGTM if CI is happy and if there's consensus on the semver implications of the change.

targos · 2015-10-03T16:10:45Z

CI: https://ci.nodejs.org/job/node-test-commit/720/
I agree with @Trott about semver-minor.

ChALkeR · 2015-10-03T21:51:27Z

Does this break refs?

Btw, this change is not directly related to this PR.

ChALkeR · 2015-10-03T21:54:34Z

The JS part LGTM.
I suspect that this breaks the docs, though. Why are those non-trivial changes in docs included in this PR, btw?

targos · 2015-10-04T07:20:45Z

@ChALkeR you are right, the doc refs are broken because I changed the titles. Do you you prefer to review the doc changes in another PR or just a second commit in this one ?

aheckmann · 2015-10-05T14:01:48Z

If we consider the output of the console functions to be part of the API, the I think one could view this as semver-major. The change to thses tests demonstrates how downstream apps output parsing will break.

Good point, I don't know what is the policy about console output.
Recent changes to the output of util.format were considered semver-minor IIRC.
cc @nodejs/collaborators

I'm going to say semver-minor for changes to console output but it's never as clear cut as it appears. For this, I personally feel it's small enough of a change that -minor is appropriate.

The probability of this breaking anything is near zero. Still, there seems to be no reason for pulling this into 4.x branch.

Fishrock123 · 2015-10-06T03:18:43Z

I'm not sure this isn't actually semver-major.

It's almost irrelevant right now. It'l probably have to land in v5.x anyways, but we should err on the side of caution still.

targos · 2015-10-06T06:59:05Z

OK for semver-major, this is safer. I added it to the 5.0 milestone.

targos · 2015-10-07T18:10:19Z

I put the doc changes in a separate commit. PTAL.

silverwind · 2015-10-07T18:31:52Z

Maybe call the parameter timerName to be in line with mdn?

same could be done in code, maybe as a seperate commit too.

ChALkeR · 2015-10-07T18:43:07Z

«console: sub-millisecond accuracy for console.time» + one-line doc change («262ms» → «225.438ms») LGTM.
«doc: reword description of console.time» — no review from me, I am not a native English speaker. Also, both versions look fine to me.

evanlucas · 2015-10-08T13:18:07Z

LGTM if CI is green

Trott · 2015-10-08T17:27:23Z

semver-major means TSC has to review before landing, right?

jasnell · 2015-10-08T17:33:02Z

@Trott ... no, semver-major changes can land in master at any time so long as there is good review. They cannot land in stable branches, however, without very good reason and TSC or LTS WG review.

jasnell · 2015-10-08T17:33:46Z

That said, if the change may be controversial or particularly disruptive, you may want to hold off landing until more folks have had the time to review it.

silverwind · 2015-10-08T17:39:51Z

@jasnell is correct. There's no reason to hold off universally approved semver-major commits with our current model, unless you specifically don't want something to land on the next major release.

Trott · 2015-10-08T17:47:05Z

The onboarding.md that I have bookmarked says this:

semver-major (breaking) changes must be reviewed in some form by the TSC

Maybe the onboarding.md needs to be updated? Or there's a newer one that I should use instead of the one I've been using? (I'm reluctant to post the link publicly here because it's a secret gist and not a public gist.)

Or maybe it really does need TSC review. As recently as three days ago, that was the conclusion for a different semver-major PR. #3078 (comment)

/cc @Fishrock123

trevnorris · 2015-10-08T18:16:35Z

I don't think that means we need to have a formal vote on the breaking change. Only that someone from the TSC approves the PR.

Trott · 2015-10-08T18:38:38Z

@trevnorris +1 for a liberal interpretation of in some form.

targos · 2015-10-08T19:29:40Z

CI: https://ci.nodejs.org/job/node-test-commit/769/

Fishrock123 · 2015-10-09T02:55:26Z

@Trott ... no, semver-major changes can land in master at any time so long as there is good review. They cannot land in stable branches, however, without very good reason and TSC or LTS WG review.

I would dispute not:

Pull Requests that require an increase in the Major version must be elevated for review by the TSC. This does not necessarily mean that the PR must be put onto the TSC meeting agenda. If enough TSC members sign-off on the PR and there is clear consensus among TSC members for the change, the Pull Request can be landed. Where there is disagreement among TSC members, semver-major Pull Requests should be put on the TSC meeting agenda.

https://github.com/nodejs/dev-policy#accepting-modifications-through-a-consensus-seeking-process

I think it is best to keep it this way, at least for now.

Fishrock123 · 2015-10-09T02:56:18Z

I don't think that means we need to have a formal vote on the breaking change. Only that someone from the TSC approves the PR.

See above. :)

targos · 2015-10-09T06:14:26Z

CI is happy minus the usual test-stringbytes-external.

@Trott @evanlucas @ChALkeR @nodejs/tsc: LGTY ?

Trott · 2015-10-09T06:26:13Z

Nittiest of all possible nits: The last sentence describes the timer precision, not the accuracy.

Slightly less nitty nit: sub-millisecond is true, but we know that it will be three decimal places, so you could just say it's to the microsecond.

Of course, I can't come up with wording for either of these nits that's better than what's already there, so ¯_(ツ)_/¯

The last sentence describes the timer precision, not the accuracy.

You are right, I will replace "accurate" with "precise" when I land it if nobody objects.

... so you could just say it's to the microsecond

I wanted to do that but I am not sure it's true all the time and on all platforms. Perhaps if the CPU is overloaded we can lose precision ? I really don't know.

Another possibility is just to remove that last sentence entirely. I don't think MDN indicates how many decimal places their timer is good for, for example. People can use it and they get as many decimal places as they get.

MDN stuff for reference:

https://developer.mozilla.org/en-US/docs/Web/API/Console/time

https://developer.mozilla.org/en-US/docs/Web/API/Console/timeEnd

For this sentence I took inspiration from https://developer.chrome.com/devtools/docs/console-api#consoletimelabel
I fine with removing it as well

Ah. Well, in that case, I'm fine with leaving it. If it's good enough for Chrome docs, it's good enough for me.

Sorry for all the bikeshedding on this. LGTM no matter which way you decide to go with it (leave it, remove it, change it as described).

ghost · 2015-10-09T06:27:18Z

A couple of nits, but I'm OK if they're addressed at a later date or ignored entirely. (They're nits after all.)

LGTM

ghost · 2015-10-09T07:03:05Z

Overall LGTM. There's one more slight difference to browser implementations: They limit the amount of active timers to 10000. I don't think we need this, but at least mention it.

ghost · 2015-10-09T07:27:01Z

Yes, they also don't throw when you call console.timeEnd() with a non-existing timer. Another difference is that console.time() is a no-op if a timer with the same name is already running. Our implementation restarts it.
I'd like to improve this as well but I think it's out of scope for this PR.

ghost · 2015-10-16T17:35:15Z

Can I have a sign-off from someone in @nodejs/tsc ?

ghost · 2015-10-16T18:49:46Z

LGTM

This makes the output of console.timeEnd in line with major browsers. PR-URL: nodejs#3166 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com>

PR-URL: nodejs#3166 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com>

Name it timerName instead of label. It is clearer that way and matches the description in the doc. It is also how it's named in MDN. PR-URL: nodejs#3166 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com>

ghost · 2015-10-16T19:11:15Z

Thanks! Landed in 642928b...8c043c1

targos added the console Issues and PRs related to the console subsystem. label Oct 3, 2015

targos force-pushed the precise-console-time branch from e05ca84 to 140f0fe Compare October 3, 2015 11:24

thefourtheye reviewed Oct 3, 2015
View reviewed changes

targos added the semver-minor PRs that contain new features and should be released in the next minor version. label Oct 3, 2015

ChALkeR reviewed Oct 3, 2015
View reviewed changes

aheckmann reviewed Oct 5, 2015
View reviewed changes

targos removed the semver-minor PRs that contain new features and should be released in the next minor version. label Oct 6, 2015

targos added this to the 5.0.0 milestone Oct 6, 2015

targos added the semver-major PRs that contain breaking changes and should be released in the next major version. label Oct 6, 2015

targos force-pushed the precise-console-time branch from 140f0fe to 12a090c Compare October 7, 2015 18:07

silverwind reviewed Oct 7, 2015
View reviewed changes

Trott reviewed Oct 9, 2015
View reviewed changes

rvagg mentioned this pull request Oct 16, 2015

v5.0.0 Planning & Checklist #3397

Closed

13 tasks done

Michaël Zasso added 3 commits October 16, 2015 21:00

console: sub-millisecond accuracy for console.time

419f7d4

This makes the output of console.timeEnd in line with major browsers. PR-URL: nodejs#3166 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com>

doc: reword description of console.time

fc72a57

PR-URL: nodejs#3166 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com>

targos force-pushed the precise-console-time branch from f1c7d44 to 8c043c1 Compare October 16, 2015 19:08

targos merged commit 8c043c1 into nodejs:master Oct 16, 2015

targos deleted the precise-console-time branch October 16, 2015 19:10

rvagg mentioned this pull request Oct 21, 2015

Release proposal: v5.0.0 #3466

Merged

silverwind mentioned this pull request Oct 29, 2015

console: change doc to follow major browser console doc #3584

Closed

Krinkle mentioned this pull request Nov 2, 2015

Prefix commit subjects with semver level jquery/contribute.jquery.org#130

Closed

aliscco mentioned this pull request Jun 25, 2023

[Snyk] Security upgrade @commitlint/cli from 8.3.6 to 17.0.0 aliscco/alisco-node#600

Open

aliscco mentioned this pull request Nov 29, 2023

[Snyk] Security upgrade lerna from 3.22.1 to 5.1.2 aliscco/alisco-node#747

Open

Uh oh!

Conversation

targos commented Oct 3, 2015

Uh oh!

targos commented Oct 3, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Trott commented Oct 3, 2015

Uh oh!

Trott commented Oct 3, 2015

Uh oh!

targos commented Oct 3, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChALkeR commented Oct 3, 2015

Uh oh!

targos commented Oct 4, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fishrock123 commented Oct 6, 2015

Uh oh!

targos commented Oct 6, 2015

Uh oh!

targos commented Oct 7, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChALkeR commented Oct 7, 2015

Uh oh!

evanlucas commented Oct 8, 2015

Uh oh!

Trott commented Oct 8, 2015

Uh oh!

jasnell commented Oct 8, 2015

Uh oh!

jasnell commented Oct 8, 2015

Uh oh!

silverwind commented Oct 8, 2015

Uh oh!

Trott commented Oct 8, 2015

Uh oh!

trevnorris commented Oct 8, 2015

Uh oh!

Trott commented Oct 8, 2015

Uh oh!

targos commented Oct 8, 2015

Uh oh!

Fishrock123 commented Oct 9, 2015

Uh oh!

Fishrock123 commented Oct 9, 2015

Uh oh!

targos commented Oct 9, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost Oct 9, 2015

Choose a reason for hiding this comment