Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

benchmark: improve compare output #18597

Closed
wants to merge 2 commits into from
Closed

benchmark: improve compare output #18597

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ff1ac36
benchmark: improve compare output
BridgeAR Feb 5, 2018
de425e2
fixup: escape double quotes properly
BridgeAR Feb 6, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions benchmark/compare.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
'use strict';

const fork = require('child_process').fork;
const { fork } = require('child_process');
const { inspect } = require('util');
const path = require('path');
const CLI = require('./_cli.js');
const BenchmarkProgress = require('./_benchmark_progress.js');
Expand Down Expand Up @@ -76,7 +77,7 @@ if (showProgress) {
// Construct configuration string, " A=a, B=b, ..."
let conf = '';
for (const key of Object.keys(data.conf)) {
conf += ` ${key}=${JSON.stringify(data.conf[key])}`;
conf += ` ${key}=${inspect(data.conf[key])}`;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually wondering, is there a place where we benefit from using inspect here as opposed to simply String(data.conf[key])? Because as far as I can tell, conf is generally number, string or true/false.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do because we will actually be able to distinguish the data types by using util.inspect. By only converting it to a string, the string 'true' would look the same as the boolean true.

Copy link
Contributor

@apapirovski apapirovski Feb 6, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair.

Personally, I'm not sure I actually love that part of the functionality but obviously that's not something that needs to be addressed in this PR. Since it's generating CSV, having true and "true" be equivalent is almost preferable to me.

One other thing... util.inspect will do the following:

util.inspect("true");
// '\'true\''
JSON.stringify("true");
// '"true"'

The former doesn't seem correct for the purposes of CSV.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW one of the problems with single quotes is there seems to be no accepted way of handling them. Some parsers seem to treat them as equivalent to double quotes (meaning they need to be escaped) and others treat them as just a character.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@apapirovski I wrote this with the RFC 4180 specs in mind. If a parser does something else (and many do), then that is just tough luck. Creating CSV files that work in all parsers is a very big challenge. We just need to make sure it works with read.csv in R.

}
conf = conf.slice(1);
// Escape quotes (") for correct csv formatting
Expand Down