readline: Allow history to be disabled #6352

suryagh · 2016-04-22T23:01:07Z

Checklist

tests and code linting passes
a test is included
documentation is changed or added
the commit message follows commit guidelines

Affected core subsystem(s)

readline

Description of change

Fixes #6336

The historySize to default to 30 only if undefined.
If historySize is set to 0, then disable caching the line.
Added unit tests.
Updated documentation.

vsemozhetbyt · 2016-04-22T23:33:03Z

@suryagh May be the file reading example should also be updated by adding historySize: 0.

suryagh · 2016-04-23T00:46:13Z

@vsemozhetbyt,

Are you referring to modifying the Example: Read File Stream Line-by-Line to include historySize option? like:

const rl = readline.createInterface({
  input: fs.createReadStream('sample.txt'),
  historySize: 0
});

I would prefer not to worry about historySize = 0 vs the default 30. Unless someone has a strong opinion.

vsemozhetbyt · 2016-04-23T00:59:22Z

@suryagh Yes, I referred this example and suggested this addition. Do you think this would be unnecessary?

I mean, this is almost a template code, many users could take it as a base for line by line file reading without going into details. This addition would spare them unnecessary overhead.

Fishrock123 · 2016-04-24T00:32:03Z

Sounds fine to me. Could someone describe the use-case in a bit more detail?

vsemozhetbyt · 2016-04-24T00:48:16Z

@Fishrock123 I often use readline to process big (up to 1 GB) text files (dictionaries) line by line: to reformat them, to extract data etc. For such processing history of lines is useless, it only wastes resources.

cjihrig · 2016-04-25T14:13:14Z

Changing from semver-minor to semver-major. This changes behavior when historySize is zero.

cjihrig · 2016-04-25T14:14:38Z

test/parallel/test-readline-interface.js

+ fi = new FakeInput();
+ rli = new readline.Interface({ input: fi, output: fi, terminal: terminal,
+ historySize: 0 });
+ assert.equal(rli.historySize, 0);


Please change this to assert.strictEqual().

cjihrig · 2016-04-25T14:17:49Z

Can you add rli.close() after each of your tests.

vsemozhetbyt · 2016-04-25T14:18:14Z

So now it can't be fixed untill Node 7.0, i.e. untill October 2016?

cjihrig · 2016-04-25T14:20:16Z

It could still potentially make it into v6.

cjihrig · 2016-04-25T14:24:33Z

It would be nice to include a test that verifies that items are not being included in the history.

vsemozhetbyt · 2016-04-25T14:41:55Z

Could anybody help if @suryagh could not implement all the requests untill v6 deadline?

suryagh · 2016-04-25T16:49:54Z

@vsemozhetbyt when is the v6 deadline?

jasnell · 2016-04-25T16:52:58Z

I'll be cutting the v6.x branch tomorrow morning (likely around 9am pacific time) and will be kicking off the build sometime around 10am. Whatever lands before then should make it. I would prefer, however, to get any remaining semver-major PRs landed as soon as possible today in order to give more time for smoke and regression testing.

addaleax · 2016-04-25T17:47:34Z

LGTM

@suryagh Thanks for the changes!

cjihrig · 2016-04-25T17:49:37Z

doc/api/readline.md

@@ -300,7 +300,7 @@ the following values:
 treated like a TTY, and have ANSI/VT100 escape codes written to it.
 Defaults to checking `isTTY` on the `output` stream upon instantiation.

- - `historySize` - maximum number of history lines retained. Defaults to `30`.
+ - `historySize` - maximum number of history lines retained. To disable the history set this value to `0`. Defaults to `30`.


Can you wrap this at 80 characters.

addaleax · 2016-04-25T17:53:31Z

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

addaleax · 2016-04-25T18:17:22Z

CI is green.

@suryagh The commit message may require a bit of cleanup, but we can do that upon landing if you prefer. Specifically:

The commit title should be all lowercase, I’d suggest readline: allow history to be disabled
You don’t need to include your bullet points 5 and 6, as they won’t make any sense outside the context of this PR.
The Author field is currently set to Panikkal, Surya(spanikkal). Is that intentional? Most people prefer to have their name in a more standard format (e.g. without your GitHub handle).

cjihrig · 2016-04-25T18:21:55Z

LGTM, but I still think a test to show that the history is actually disabled would be nice.

suryagh · 2016-04-25T18:29:50Z

@cjihrig presently readline's history array is private to the module. Testing the private internal implementation detail sounds like a code smell to me. However, one approach to achieve this could be to expose the current number of the items in the history as a new api of readline, please let me know you think we should really take this route. Or, can you please point me to somewhere else in the code this is done in a more elegant fashion.

cjihrig · 2016-04-25T18:52:39Z

There is nothing wrong with something testing its own internal implementation. There are a few private methods in readline you can call to manipulate history. You could also take a look at test/parallel/test-repl-persistent-history.js and see if anything there inspires you.

suryagh · 2016-04-25T19:48:55Z

@addaleax made the suggested changes.

fix nodejs#6336 1. The `historySize` to default to `30` only if `undefined`. 2. If `historySize` is set to 0, then disable caching the line. 3. Added unit tests. 4. Updated documentation.

addaleax · 2016-04-25T19:52:06Z

@suryagh Cool! Could you look into @cjihrig’s suggestion to write an additional test for checking that this feature does what it’s supposed to do? As mentioned, it’s definitely okay to inspect private properties in the tests here.

Still LGTM either way.

suryagh · 2016-04-25T20:04:41Z

@addaleax I'm not sure if I can get to @cjihrig suggestion by tomorrow morning cut off time. If not, then I will send a separate PR for the readline tests. Please let me know if thats ok? I'm also thinking of making few additional fixes to the readline tests...unrelated to the current code changes.

Btw - regarding the github handle, it is actually suryagh. The spanikkal that is showing up in the commit is actually for our internal enterprise instance of the github..and for some reason git is using that for all pushes. I tried to ammend the commit to fix it, not sure if it is going through. Please feel free to change it to match other commit log.

addaleax · 2016-04-25T20:31:43Z

@suryagh PR’ed against your fork with a simple suggestion for tests. Be sure to write a small notification here if/when you update this PR so others can see that.

I have to admit I’d feel silly if this doesn’t get included in v6 over a missing test, esp. when it’s a breaking change anyway, so I’m adding it to the milestone. If someone thinks that that doesn’t leave enough time for reviews from more people, they should feel free to remove it.

Check that when setting `historySize: 0`, the `history` property of the readline interface is kept empty.

suryagh · 2016-04-25T20:35:07Z

@addaleax merged the tests. Thank you.

addaleax · 2016-04-25T20:36:01Z

Thanks! @cjihrig That does the trick for you?

cjihrig · 2016-04-25T20:54:56Z

LGTM. Thanks @addaleax

addaleax · 2016-04-25T20:59:02Z

One more CI: https://ci.nodejs.org/job/node-test-commit/3051/

vsemozhetbyt · 2016-04-25T22:36:11Z

I've looked at the last tests of @addaleax and now I feel terribly silly with all the my 'overhead' alarm — the key reason I mention this bug in the first place by. It seems all the history caching does not even start if the terminal is false or undefined (in the functions and events chain _addHistory is not called at all).

All the same this bug fix is still a thing of consistency. However it probably makes sense to add in the readline.createInterface doc part a clarification that historySize has any meaning only if terminal becomes true by any way.

Sorry for all my stupidity and laziness to dig in this deeper (and for my poor English).

addaleax · 2016-04-25T22:50:03Z

@vsemozhetbyt Don’t worry about it too much. This is good for consistency, the less urgent it is the better, and you should by all means feel invited to write something up for the docs!

vsemozhetbyt · 2016-04-25T22:57:12Z

@addaleax Thank you. I'm not so familiar with all the colaboration cobweb, so may be I shoud not interfere in this now in the last fragile moment. But if this PR lands without such clarification, I shall try to add a simple doc PR for it when all the new release bustle ceases.

addaleax · 2016-04-25T23:12:08Z

@vsemozhetbyt I think this PR is more or less good to go, anything else can be done later.

addaleax · 2016-04-26T00:31:53Z

Landed in 0303a25.

1. The `historySize` to default to `30` only if `undefined`. 2. If `historySize` is set to 0, then disable caching the line. 3. Added unit tests. 4. Updated documentation. Fixes: #6336 PR-URL: #6352 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

History caching in the `readline` io is active only for terminal interaction. Appropriate variables are initialized and relevant `_addHistory()` function is called only if exposed `terminal` option of `readline.createInterface()` is set `true` by user or internal output check. This clarification is useful to assure users there will be now wasted overhead connected with history caching if `readline` is used not for terminal interaction (e.g. for reading files line by line). Particularly this fix is helpful after #6352 landing. PR-URL: #6397 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Alexander Makarenko <estliberitas@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

History caching in the `readline` io is active only for terminal interaction. Appropriate variables are initialized and relevant `_addHistory()` function is called only if exposed `terminal` option of `readline.createInterface()` is set `true` by user or internal output check. This clarification is useful to assure users there will be now wasted overhead connected with history caching if `readline` is used not for terminal interaction (e.g. for reading files line by line). Particularly this fix is helpful after nodejs#6352 landing. PR-URL: nodejs#6397 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Alexander Makarenko <estliberitas@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

mscdex added the readline Issues and PRs related to the built-in readline module. label Apr 22, 2016

jasnell added the semver-minor PRs that contain new features and should be released in the next minor version. label Apr 22, 2016

vsemozhetbyt mentioned this pull request Apr 22, 2016

Possible improvement of "Read file stream line-by-line" example in readline doc #5842

Closed

cjihrig added semver-major PRs that contain breaking changes and should be released in the next major version. and removed semver-minor PRs that contain new features and should be released in the next minor version. labels Apr 25, 2016

cjihrig reviewed Apr 25, 2016
View reviewed changes

suryagh force-pushed the fix branch from 93d443a to 2cc3d39 Compare April 25, 2016 17:32

cjihrig reviewed Apr 25, 2016
View reviewed changes

suryagh force-pushed the fix branch from 2cc3d39 to b673829 Compare April 25, 2016 18:07

suryagh force-pushed the fix branch from b673829 to 4e50bad Compare April 25, 2016 18:25

suryagh force-pushed the fix branch from 4e50bad to 20b6c07 Compare April 25, 2016 19:47

readline: allow history to be disabled

5ac572c

fix nodejs#6336 1. The `historySize` to default to `30` only if `undefined`. 2. If `historySize` is set to 0, then disable caching the line. 3. Added unit tests. 4. Updated documentation.

suryagh force-pushed the fix branch from 20b6c07 to 5ac572c Compare April 25, 2016 19:51

addaleax added this to the 6.0.0 milestone Apr 25, 2016

readline: test that disabling history works (#1)

5f4f4ad

Check that when setting `historySize: 0`, the `history` property of the readline interface is kept empty.

addaleax closed this Apr 26, 2016

This was referenced Apr 26, 2016

2016-04-26, Version 6.0.0 (Current) Release #6383

Closed

doc: extra clarification of historySize option #6397

Closed

readline: Allow history to be disabled #6352

readline: Allow history to be disabled #6352

Conversation

suryagh commented Apr 22, 2016 • edited Loading

Checklist

Affected core subsystem(s)

Description of change

vsemozhetbyt commented Apr 22, 2016 • edited Loading

suryagh commented Apr 23, 2016

vsemozhetbyt commented Apr 23, 2016 • edited Loading

Fishrock123 commented Apr 24, 2016

vsemozhetbyt commented Apr 24, 2016 • edited Loading

cjihrig commented Apr 25, 2016

cjihrig Apr 25, 2016

Choose a reason for hiding this comment

suryagh Apr 25, 2016

Choose a reason for hiding this comment

cjihrig commented Apr 25, 2016

vsemozhetbyt commented Apr 25, 2016 • edited Loading

cjihrig commented Apr 25, 2016

cjihrig commented Apr 25, 2016

vsemozhetbyt commented Apr 25, 2016

suryagh commented Apr 25, 2016

jasnell commented Apr 25, 2016

addaleax commented Apr 25, 2016

cjihrig Apr 25, 2016

Choose a reason for hiding this comment

suryagh Apr 25, 2016

Choose a reason for hiding this comment

addaleax commented Apr 25, 2016

addaleax commented Apr 25, 2016

cjihrig commented Apr 25, 2016

suryagh commented Apr 25, 2016

cjihrig commented Apr 25, 2016

suryagh commented Apr 25, 2016

addaleax commented Apr 25, 2016 • edited Loading

suryagh commented Apr 25, 2016

addaleax commented Apr 25, 2016

suryagh commented Apr 25, 2016

addaleax commented Apr 25, 2016

cjihrig commented Apr 25, 2016

addaleax commented Apr 25, 2016

vsemozhetbyt commented Apr 25, 2016 • edited Loading

addaleax commented Apr 25, 2016

vsemozhetbyt commented Apr 25, 2016 • edited Loading

addaleax commented Apr 25, 2016

addaleax commented Apr 26, 2016

suryagh commented Apr 22, 2016 •

edited

Loading

vsemozhetbyt commented Apr 22, 2016 •

edited

Loading

vsemozhetbyt commented Apr 23, 2016 •

edited

Loading

vsemozhetbyt commented Apr 24, 2016 •

edited

Loading

vsemozhetbyt commented Apr 25, 2016 •

edited

Loading

addaleax commented Apr 25, 2016 •

edited

Loading

vsemozhetbyt commented Apr 25, 2016 •

edited

Loading

vsemozhetbyt commented Apr 25, 2016 •

edited

Loading