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.

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

Refactored all add() calls from SortedSet to only pass single values #203

Merged
merged 2 commits into from
Mar 8, 2016
Merged

Refactored all add() calls from SortedSet to only pass single values #203

merged 2 commits into from
Mar 8, 2016

Conversation

dangrie158
Copy link
Contributor

Before this fix, the index passed all tokens via an apply call, pushing all parameters on the stack.

This behaviour causes a RangeError when more tokens are added than the JS implementation can handle (Firefox 44 -> 262143, Node.js -> 65535, evaluated using this test: http://stackoverflow.com/questions/22747068/is-there-a-max-number-of-arguments-javascript-functions-can-accept)
this fix changes the code so that now only a single value gets passed per call. This way no change to the current API is neccesary.

The code was refactored in a way that it now passes only a single argument at a time, avoiding the usage of apply.

The only parts of the code that still use apply are the EventEmitters and the Plugin subsystem which should be non critical for this type of error.

before this fix, the index passed all tokens via an apply call, pushing all parameters on the stack.
This behaviour causes a RangeError when more tokens are added than the JS implementation can handle (Firefox 44 -> 262143, Node.js -> 65535, evaluated using this test: http://stackoverflow.com/questions/22747068/is-there-a-max-number-of-arguments-javascript-functions-can-accept)
this fix changes the code so that now only a single value gets passed per call. This way no change to the current API is neccesary.

the code was refactored in a way that it now passes only a single argument at a time, avoiding the usage of apply

The only parts of the code that still use apply are the EventEmitters and the Plugin subsystem which should be non critical for this type of error.
@@ -224,7 +224,9 @@ lunr.SortedSet.prototype.union = function (otherSet) {

unionSet = longSet.clone()

unionSet.add.apply(unionSet, shortSet.toArray())
for(var i = 0, shortSetElements = shortSet.toArray(); i < shortSetElements.length; i++){
unionSet.add(shortSetElements[i]);
Copy link
Contributor

Choose a reason for hiding this comment

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

tiny nitpick - none of the other code includes explicitly semicolons. We should probably try and match that style.

@d0ugal
Copy link
Contributor

d0ugal commented Mar 7, 2016

One tiny comment, otherwise the change looks good.

the rest of the project is coded in a semicolon free style. this commit makes a change to match that style in one location
@dangrie158
Copy link
Contributor Author

Thanks I just fixed the line.
I found it really hard to follow the semicolon less style because its almost in the muscle memory to press it when your not used to it.

Maybe I can add a .jshintrc with the lastsemic option set at some point? That would at least supress all warnings for a automatic linter like I have in Atom.

@d0ugal
Copy link
Contributor

d0ugal commented Mar 8, 2016

I found it really hard to follow the semicolon less style because its almost in the muscle memory to press it when your not used to it.

I agree, I prefer JavaScript with semicolons.

Anyway, this change looks good to me now! 👍

@olivernn olivernn merged commit eda358f into olivernn:master Mar 8, 2016
@olivernn
Copy link
Owner

olivernn commented Mar 8, 2016

This is merged in the latest release now, thanks a lot the fix.

I actually think adding some kind of linter to the build would be a fantastic idea, it certainly helps any would be contributors to get their patch applied quicker (sadly I'm probably still the bottleneck though!) and would help ensure a decent level of consistency in the code base.

Also semicolon free style is clearly better... :trollface: 🔥

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants