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

New component layout caching #13829

Merged
merged 3 commits into from
Jul 18, 2016
Merged

New component layout caching #13829

merged 3 commits into from
Jul 18, 2016

Conversation

krisselden
Copy link
Contributor

This PR is dependent on this landing glimmerjs/glimmer-vm#217

@chadhietala
Copy link
Contributor

It's failing because tildeio/broccoli-typescript-compiler#20 needs to be merged and released.

@rwjblue
Copy link
Member

rwjblue commented Jul 17, 2016

Upstream broccoli-typescript-compiler was released as v0.6.2

@chadhietala
Copy link
Contributor

Ok now I don't know why the blueprints are failing. I haven't been able repro locally with the same versions node and npm.

@homu
Copy link
Contributor

homu commented Jul 17, 2016

☔ The latest upstream changes (presumably #13832) made this pull request unmergeable. Please resolve the merge conflicts.

@krisselden krisselden force-pushed the new-component-layout-caching branch from 552fce5 to 092fd99 Compare July 18, 2016 17:47
@krisselden krisselden merged commit 64865a8 into master Jul 18, 2016
@chadhietala chadhietala deleted the new-component-layout-caching branch July 18, 2016 20:44
wycats pushed a commit that referenced this pull request Jul 29, 2016
In #13829, we introduced the ability to pass a custom key function for
the cache. However, we are incorrectly passing `(key, value)` to `set`
when the function expects `(obj, value)`.

This is causing problems for caches that uses a custom cache keying
function (such as Glimmer's compilation cache), because the get side
would handle the keying correctly, but the set side would compute the
key based on the already-computed key (i.e. `this.key(this.key(obj))`).

In Glimmer's compilation cache, this is causing the cache to always miss
because the `set` side would cache everything under the `"undefined"`
key.
rwjblue pushed a commit that referenced this pull request Aug 1, 2016
In #13829, we introduced the ability to pass a custom key function for
the cache. However, we are incorrectly passing `(key, value)` to `set`
when the function expects `(obj, value)`.

This is causing problems for caches that uses a custom cache keying
function (such as Glimmer's compilation cache), because the get side
would handle the keying correctly, but the set side would compute the
key based on the already-computed key (i.e. `this.key(this.key(obj))`).

In Glimmer's compilation cache, this is causing the cache to always miss
because the `set` side would cache everything under the `"undefined"`
key.

(cherry picked from commit 80f0462)
toddjordan pushed a commit to toddjordan/ember.js that referenced this pull request Sep 9, 2016
In emberjs#13829, we introduced the ability to pass a custom key function for
the cache. However, we are incorrectly passing `(key, value)` to `set`
when the function expects `(obj, value)`.

This is causing problems for caches that uses a custom cache keying
function (such as Glimmer's compilation cache), because the get side
would handle the keying correctly, but the set side would compute the
key based on the already-computed key (i.e. `this.key(this.key(obj))`).

In Glimmer's compilation cache, this is causing the cache to always miss
because the `set` side would cache everything under the `"undefined"`
key.
webark pushed a commit to webark/ember.js that referenced this pull request Oct 6, 2016
In emberjs#13829, we introduced the ability to pass a custom key function for
the cache. However, we are incorrectly passing `(key, value)` to `set`
when the function expects `(obj, value)`.

This is causing problems for caches that uses a custom cache keying
function (such as Glimmer's compilation cache), because the get side
would handle the keying correctly, but the set side would compute the
key based on the already-computed key (i.e. `this.key(this.key(obj))`).

In Glimmer's compilation cache, this is causing the cache to always miss
because the `set` side would cache everything under the `"undefined"`
key.
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.

5 participants