Skip to content

Don't use reserved word 'volatile' for non-cached properties - #957

Closed
rykov wants to merge 2 commits into
emberjs:masterfrom
rykov:master
Closed

rykov wants to merge 2 commits into
emberjs:masterfrom
rykov:master

Conversation

@rykov

@rykov rykov commented Jun 6, 2012

Copy link
Copy Markdown
Contributor

The verdict online seems mixed on whether volatile is a reserved word in Javascript, but Closure Compiler seems to think that it is and spew many errors when I try to use it as my minifier.

This commit replaces the volatile function with uncached.

@wycats

wycats commented Jun 6, 2012

Copy link
Copy Markdown
Member

Thanks for the pull request. I'm confused about why closure compiler thinks it's reserved. See http://es5.github.com/#x7.6.1.2 for a complete list of the reserved words in ES5.

@travisbot

Copy link
Copy Markdown

This pull request passes (merged fca01d8 into 96791e2).

@rykov

rykov commented Jun 6, 2012

Copy link
Copy Markdown
Contributor Author

Did some digging -- volatile is not reserved in ES5, but it is in ES3. Closure Compiler supports both and defaults to ES3. And you're right, in ES5 mode, Closure Compiler doesn't think it's reserved and finishes the compression. This does the trick in Rails 3.1+:

Closure::Compiler::DEFAULT_OPTIONS[:language_in] = 'ECMASCRIPT5'

Source: http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm

@wagenet

wagenet commented Jun 9, 2012

Copy link
Copy Markdown
Member

@wycats What's the verdict on this? Merge or no?

@wagenet

wagenet commented Jun 9, 2012

Copy link
Copy Markdown
Member

If we don't merge, we should definitely document the solution somewhere.

@rykov

rykov commented Jun 9, 2012

Copy link
Copy Markdown
Contributor Author

I've submitted a pull request to closure-compiler gem to make ES5 the default here: documentcloud/closure-compiler#21

@rykov

rykov commented Jun 9, 2012

Copy link
Copy Markdown
Contributor Author

@wagenet To answer your question, no merge in favor of something like this added to ember-rails

if defined?(Closure::Compiler)
  Closure::Compiler::DEFAULT_OPTIONS[:language_in] = 'ECMASCRIPT5'
end

@wagenet wagenet closed this Jun 9, 2012
@rykov

rykov commented Jun 9, 2012

Copy link
Copy Markdown
Contributor Author

Should I go ahead with the ember-rails suggestion?

@wagenet

wagenet commented Jun 9, 2012

Copy link
Copy Markdown
Member

@rykov, sounds good to me.

@rykov

rykov commented Jun 9, 2012

Copy link
Copy Markdown
Contributor Author

Submitted here: emberjs/ember-rails#61

NullVoxPopuli added a commit that referenced this pull request Aug 7, 2026
Adds the `@ember/scheduler` package proposed by RFC 0957:

- `render`, `layout`, `composite`, `next` and `idle` phase functions,
  each returning a promise that resolves according to the registered
  scheduling strategy
- `registerStrategy`, for providing the scheduling strategy when defining
  the Application
- `@ember/scheduler/strategy`, the default strategy implementation, which
  flushes the render/layout/composite phases in order via ordered
  requestAnimationFrame callbacks within a single frame, prior to paint

The deprecations of @ember/runloop and RSVP described by the RFC are left
to follow-up work; this is the additive API surface.

Fix Safari flake and idle() starvation in the default strategy

The "composite while composite is flushing" test asserted ordering across
two independent channels: a setTimeout task scheduled during frame 1
versus frame 2's requestAnimationFrame callbacks. The HTML spec does not
order pending timer tasks against the next rendering opportunity, and
Safari 15.6 runs the next frame's rAF callbacks first. The test now
anchors entirely to the rAF channel, using a raw requestAnimationFrame
registered ahead of the rescheduled phase windows as the frame-2
boundary.

idle() also armed requestIdleCallback without a timeout; fully-idle or
backgrounded pages can starve rIC indefinitely, leaving the promise
unresolvable. Cap the wait with { timeout: 500 }.
NullVoxPopuli-ai-agent pushed a commit to NullVoxPopuli-ai-agent/ember.js that referenced this pull request Oct 3, 2026
This is the all-optimizations branch as one commit on main f693f24.
The branch had 3 merge commits with conflict resolutions in them, and a
commit-by-commit rebase drops those resolutions. So this commit has the
end state of the branch (c09efdc) merged with main.

The old history is on the branch all-optimizations-pre-rebase.

Changes that main needed, beyond the 8 conflicting files:
- route.ts, router.ts: main's new runloop calls use the same microtask
  helpers as the rest of the spike (queueMicrotask, scheduleMethodOnce)
- classic route manager: native Promise instead of RSVP
- ArrayIterator#nextInto: follows main's next(), which reads the live
  array length
- runloop shim: a typed overload for run(fn), so run returns the
  callback's type
- rollup: rsvp stays a hidden dependency. Main removed the hidden entry
  and the spike removed the exposed one.
- package.json: main's version, without backburner.js

Checks: the type-check has the same 10 errors as c09efdc and no new
ones. pnpm build passes. The browser test suite stops early in the
debug render tree tests, on c09efdc and on this commit.

Commits squashed from c09efdc:
- a9f197d Implement RFC emberjs#957: Render Aware Scheduler Interface
- ed3e2ab Skip unchanged {{#each}} item subtrees during updates
- d9f1250 SPIKE: stack all dbmon-class optimizations to measure the ceiling
- 2607466 SPIKE: delete legacy read-path support from _getProp
- 5530b80 SPIKE: allocation hygiene in the updating VM (fps-neutral)
- b7a4e38 Fix Safari flake and idle() starvation in the default strategy
- e562c08 Adaptive tri-mode flush scheduler on clean main (scheduler lever only)
- 3a3b9e2 Diet the flush machinery; keep macrotask leg alive under rAF starvation
- a80bce4 Fix double-flushing and stand-down starvation in the chain leg
- f8b4d0c End state: remove backburner from the render path entirely
- 908f68b Drop imports orphaned by the legacy read-path removal
- 7c0b543 Clock semantics: one render per tick, bounded settle rounds
- 233200e Adopt Angular's microtask-window tick classifier
- 1a0a834 Make the renderer clock the default @ember/scheduler strategy
- c93641e Diet the per-set path: notify once per tick, one-hop tracked cells
- d6be883 Fix the two hazards the per-set diet shipped with
- 7e5e61e Remove the runloop and RSVP from the framework entirely
- 739bf03 Sync lockfile and renamed-modules with the runloop/RSVP removal
- 2b703ac Known-tag references and pooled tracking frames
- 3e9fc3c Pool the per-tick transaction and updating VM
- 5d5c603 Revert "Pool the per-tick transaction and updating VM"
- 39c062e Remove the tracking-frame Tracker pool as well
- 17ac4c3 Delete backburner; the runloop becomes a dependency-free compat shim
- 5916d3e Restore trailing newline in package.json
- a967e87 Restore _backburner compat stub and boot-deferred assignability
- f69f089 Drain scheduled destroys synchronously when an engine instance is destroyed
- 7077507 Report pending work through the _backburner stub; renderSettled resolves via a flush
- 60f0fc9 Replace the _backburner stub with isRenderPending on @ember/renderer
- c09efdc Report render settledness as edges, not a pollable level

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
NullVoxPopuli-ai-agent pushed a commit to NullVoxPopuli-ai-agent/ember.js that referenced this pull request Oct 3, 2026
Adds the `@ember/scheduler` package proposed by RFC 0957:

- `render`, `layout`, `composite`, `next` and `idle` phase functions,
  each returning a promise that resolves according to the registered
  scheduling strategy
- `registerStrategy`, for providing the scheduling strategy when defining
  the Application
- `@ember/scheduler/strategy`, the default strategy implementation, which
  flushes the render/layout/composite phases in order via ordered
  requestAnimationFrame callbacks within a single frame, prior to paint

The deprecations of @ember/runloop and RSVP described by the RFC are left
to follow-up work; this is the additive API surface.

Fix Safari flake and idle() starvation in the default strategy

The "composite while composite is flushing" test asserted ordering across
two independent channels: a setTimeout task scheduled during frame 1
versus frame 2's requestAnimationFrame callbacks. The HTML spec does not
order pending timer tasks against the next rendering opportunity, and
Safari 15.6 runs the next frame's rAF callbacks first. The test now
anchors entirely to the rAF channel, using a raw requestAnimationFrame
registered ahead of the rescheduled phase windows as the frame-2
boundary.

idle() also armed requestIdleCallback without a timeout; fully-idle or
backgrounded pages can starve rIC indefinitely, leaving the promise
unresolvable. Cap the wait with { timeout: 500 }.
NullVoxPopuli added a commit that referenced this pull request Oct 3, 2026
Adds the `@ember/scheduler` package proposed by RFC 0957:

- `render`, `layout`, `composite`, `next` and `idle` phase functions,
  each returning a promise that resolves according to the registered
  scheduling strategy
- `registerStrategy`, for providing the scheduling strategy when defining
  the Application
- `@ember/scheduler/strategy`, the default strategy implementation, which
  flushes the render/layout/composite phases in order via ordered
  requestAnimationFrame callbacks within a single frame, prior to paint

The deprecations of @ember/runloop and RSVP described by the RFC are left
to follow-up work; this is the additive API surface.

Fix Safari flake and idle() starvation in the default strategy

The "composite while composite is flushing" test asserted ordering across
two independent channels: a setTimeout task scheduled during frame 1
versus frame 2's requestAnimationFrame callbacks. The HTML spec does not
order pending timer tasks against the next rendering opportunity, and
Safari 15.6 runs the next frame's rAF callbacks first. The test now
anchors entirely to the rAF channel, using a raw requestAnimationFrame
registered ahead of the rescheduled phase windows as the frame-2
boundary.

idle() also armed requestIdleCallback without a timeout; fully-idle or
backgrounded pages can starve rIC indefinitely, leaving the promise
unresolvable. Cap the wait with { timeout: 500 }.
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.

4 participants