tools: single, cross-platform tick processor

[matthewloring]

Currently there are three separate tick processor scripts for
mac, windows, and linux. These have been replaced with a single
node.js script to improve maintainability and remove the need
to preserve parallel logic in these separate places.

/cc @ofrobots@bnoordhuis@Fishrock123@joaocgreis@Trott

[Fishrock123]

@matthewloring is this change also being upstreamed into the v8 tick processor so that future changes can be ported easily?

I guess it can't since this depends on core modules.

[matthewloring]

Yea, unfortunately v8 doesn't want node specific scripts in their codebase (https://codereview.chromium.org/1179173009/). This change should be forward compatible for the most part since it copies in the logic from the JS scripts in v8. This script would only need updating when v8 processing scripts are added or removed and changes of this nature should be alerted through test/parallel/test-tick-processor

[bnoordhuis]

Does the copyright make sense here? This is all original code, right?

[matthewloring]

I originally wasn't sure since I transliterated this from the bash script which was V8's. This is original code though. I've removed the copyright.

[bnoordhuis]

LGTM. CI: https://ci.nodejs.org/job/node-test-pull-request/306/

[ofrobots]

Unlike in shell, the $$ doesn't get expanded to be the process-id. I think you'll have to manually concatenate process.pid.

[matthewloring]

Fixed.

[ofrobots]

The previous CI failed to launch due to curl: (7) Failed to connect to api.github.com port 443. Launched a new one here: https://ci.nodejs.org/job/node-test-pull-request/311/

[bnoordhuis]

One more try, it looks like the CI was going through a spot of trouble: https://ci.nodejs.org/job/node-test-pull-request/313/

[thefourtheye]

Will cat be available in all the environments?

[sam-github]

Not on windows, it's type there. And why use cat, why not use node to read the files and pipe them to tempScript?

[matthewloring]

Good catch! I've rewritten this but am not sure if my solution is idiomatic. @thefourtheye@sam-github Does this solution seem appropriate?

[matthewloring]

@bnoordhuis Do these CI build failures seem to be caused by my PR specifically or are these general?

[bnoordhuis]

It's possible I forgot to tell the CI to rebase. Let's give it one more spin: https://ci.nodejs.org/job/node-test-pull-request/325/

[bnoordhuis]

Sigh, Jenkins was just restarted. New run: https://ci.nodejs.org/job/node-test-pull-request/330/

[matthewloring]

Some of the Ubuntu machines are hanging but the CI looks clean otherwise.

[ofrobots]

Something jenkins, something something. New CI: https://ci.nodejs.org/job/node-test-pull-request/337/

[matthewloring]

The armv7-wheezy failure is unrelated. Otherwise that run looks good!

[bnoordhuis]

Thanks Matt, landed in e0c3d2a.

@thefourtheye You didn't formally LGTM it but I put you down as a reviewer anyway.

[thefourtheye]

@bnoordhuis Oops, sorry. Code looks okay to me, though I didn't get a chance to test it.

[Fishrock123]

What semver- is this?

This removes the old scripts entirely but really doesn't seem semver-major? Is it?

[matthewloring]

The profiler tools don't constitute part of the public API so I would guess semver-minor but I'm still just understanding semantic versioning.

[Fishrock123]

Perhaps we should make those other files just call the new one for 4.x?

[ChALkeR]

@Fishrock123 Files changed in this PR aren't even packaged. Doesn't look like it deserves even a semver-minor to me.