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

Useful stuff #20

Merged
merged 5 commits into from Aug 9, 2016
Merged

Useful stuff #20

merged 5 commits into from Aug 9, 2016

Conversation

bergus
Copy link
Contributor

@bergus bergus commented Jul 11, 2016

…that occurred to me during working on cancellation (#21) and handles (#9).
Feel free not to like 130aed7 ("better module structure") and I'll drop it from this PR. The other commits shouldn't be so controversial I hope.

@coveralls
Copy link

coveralls commented Jul 11, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling 130aed7 on bergus:master into 008b3b9 on briancavalier:master.

@@ -52,7 +52,7 @@ module.exports = function upload(stream, idOrPath, tag, done) {
}).chain(function() {
return File.whereUpdate({id: fileId}, {version: version.id})
.execWithin(tx);
}).map(function() {
}).then(function() {
Copy link
Owner

Choose a reason for hiding this comment

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

Good catch.

@briancavalier
Copy link
Owner

Thanks @bergus.

Feel free not to like 130aed7 ("better module structure") and I'll drop it from this PR

I'm def not opposed to improving the module structure. I think it would be easier to review in smaller chunks, though. So, yeah, let's deal with 130aed7 separately. Thanks!

@coveralls
Copy link

coveralls commented Jul 13, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling e7bb832 on bergus:master into a84df67 on briancavalier:master.

@coveralls
Copy link

coveralls commented Jul 13, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling c2c9f26 on bergus:master into a84df67 on briancavalier:master.

@bergus
Copy link
Contributor Author

bergus commented Jul 13, 2016

Rebased and ready to merge (fast-forward?).
ES6 build for performance measurement is now just done via a separately invocable script that overwrites dist/main.js when run.

@@ -27,12 +27,13 @@
],
"scripts": {
"build-dist": "mkdirp dist && rollup -c",
"build": "npm run build-dist && uglifyjs -c 'warnings=false' -m -o dist/creed.min.js -- dist/creed.js",
"build-es6": "mkdirp dist && rollup -f cjs -o dist/creed.js src/main.js",
Copy link
Owner

Choose a reason for hiding this comment

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

indentation

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ooops.

@briancavalier
Copy link
Owner

Thanks for rebasing this into a smaller chunk. I made some comments on the source, but haven't made it through the tests yet. I should have time tonight to review those.

"preversion": "npm run build",
"check-coverage": "istanbul check-coverage --statements 100 --branches 100 --lines 100 --functions 100 coverage/coverage*.json",
"lint": "jsinspect src && eslint src",
"pretest": "npm run lint",
"test": "istanbul cover _mocha",
"test": "istanbul cover node_modules/mocha/bin/_mocha",
Copy link
Owner

Choose a reason for hiding this comment

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

This shouldn't be necessary, since _mocha gets linked in node_modules/.bin/ (I've used istanbul cover _mocha in quite a few other projects without any problem). Did you have problems with it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, like many others: gotwarlost/istanbul/issues/90. The problem is that on Windows, node_modules/.bin/_mocha is a bash file and istanbul throws when trying to load it as a js module.

Copy link
Owner

Choose a reason for hiding this comment

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

Drat, windows 🔫 😭 Oh well, good to know!

* fix quotes of argument to uglify
* not sure whether specifying the path node_modules/mocha/bin/ is an
  antipattern (some comments by npm authors claim so) but istanbul does
  not seem to take the PATH into account
@coveralls
Copy link

coveralls commented Jul 23, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling 0d44e84 on bergus:master into 67f1ac1 on briancavalier:master.

@coveralls
Copy link

coveralls commented Jul 23, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling fd03346 on bergus:master into 67f1ac1 on briancavalier:master.

@bergus bergus mentioned this pull request Jul 23, 2016
2 tasks
@bergus
Copy link
Contributor Author

bergus commented Jul 23, 2016

Ready to merge now, I think.

return assertSame(p, res)
})

/* it('should have never state for never', () => {
Copy link
Owner

Choose a reason for hiding this comment

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

Hmmm, I might have missed these isNever-related tests. Why are they commented out?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They're commented out because they all fail :-) See #30
This is a good example for a difference between futures that are resolved before the method call and those that are resolved "asynchronously".

@briancavalier
Copy link
Owner

Thanks for being patient with my radio silence lately :) I left a couple more comments: one about silencer, and another with a question about some commented-out tests that I just noticed.

@briancavalier
Copy link
Owner

Hmmm, and oddly enough, I'm seeing more difference between the _runAction-based and _when-based coroutine continuations in this branch. It doesn't seem to show up in the doxbee test, but in the parallel test, using _when seems to end up being roughly 10% slower on average. That's definitely not the end of the world, but any thoughts on what might be causing it?

just use "npm run build-es6" instead of "npm run build" and the
/dist/creed.js file will contain native ES6 except for the module syntax

benchmarks will automatically use it instead of /src/main.js as entry point
@coveralls
Copy link

coveralls commented Jul 29, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling 09b0566 on bergus:master into 0f16a8e on briancavalier:master.

@bergus
Copy link
Contributor Author

bergus commented Jul 29, 2016

Considering your comment, I did some benchmarks myself as well. And indeed, the parallel benchmark does show an increase in both runtime (780->620ms) and memory (116->119MB) for the promises-creed-generator test case, comparing origin against my master branch. (The promise-creed test case stays quite constant at 690ms/111MB). So I tried a lot of things:

  • _when vs _runAction in coroutines - no difference at all
  • Coroutine extending Action vs as a standalone class - no difference
  • handle inside try vs outside - no difference
  • Indexed extending Action vs standalone class - no difference
  • Indexed class vs the old object literal solution - bummer! Back at 780ms/116MB. However, at the same time the non-generator test case grew to 117MB?!

This kinda makes sense as doxbee does not use iterables while parallel uses the all function, so that's what makes the difference. I do however not understand why or how this happens, and rather not have to speculate.
I do however believe that an Action subclass is the cleanest solution and a compiler should eventually optimise for that.

@briancavalier
Copy link
Owner

Hmmm, strange. I was able to observe a 10% difference by just flipping back and forth between _when and _runAction in this branch using node 6.3.0 and 6.3.1. Again, I don't see it as a big deal, just seems weird that I don't observe the same difference when flipping back and forth in current creed 1.0.2.

IOW, on my laptop in node 6.3.x, when the only variable is _when vs. _runAction, this branch shows a perf difference which master doesn't. That probably means that there is some interaction between the various changes in this branch, plus maybe some differences in windows vs. OS X.

I agree Indexed is a cleaner solution. I'm cool with it.

@@ -47,6 +47,7 @@ export function silenceError (p) {
p._runAction(silencer)
}

// implements Action
Copy link
Owner

Choose a reason for hiding this comment

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

👍 Thanks for adding this comment, too.

@briancavalier
Copy link
Owner

I'll give this another quick once-over tonight, and then hopefully merge it.

@briancavalier
Copy link
Owner

Have you thought about how we can implement bifunctor with Action?

@bergus
Copy link
Contributor Author

bergus commented Aug 2, 2016

I guess you'd have to do

class Bimap extends Action {
  constructor(f, r, promise) {
    super(promise)
    this.f = f
    this.r = r
    this.handle = null
  }
  fulfilled(p) {
    this.handle = this.handleFulfilled
    this.tryCall(this.f, p.value)
  }
  rejected(p) {
    this.handle = this.handleRejected
    this.tryCall(this.r, p.value)
  }
  …
}

The alternative would be the to pass this.handle as an argument to tryCall directly, and do so in every Action subclass (and in case of Bifunctor, pass either handleFulfill or handleReject).
I don't know which one would be the more reasonable (or better optimised) choice.

@briancavalier
Copy link
Owner

Thanks for the thoughts on bifunctor. I think we can merge this ahead of #34, and figure out a good way to implement bifunctor in the new Action-based world. We can probably refactor to parameterize a bit more.

@briancavalier briancavalier merged commit 42a81f0 into briancavalier:master Aug 9, 2016
@briancavalier
Copy link
Owner

Thanks for all the work on this, @bergus!

@bergus
Copy link
Contributor Author

bergus commented Aug 12, 2016

I just tried merging this and am curious why you did rebase/squash all these commits instead of doing a regular merge? This kinda fragments my history :-/

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.

None yet

3 participants