2020-06-16 19:18:11 +03:00
|
|
|
[workspace]
|
2022-11-15 16:09:39 +03:00
|
|
|
resolver = "2"
|
2022-02-11 15:19:02 +03:00
|
|
|
# Listing only the "root" crates of each app/library. All path dependencies are included in the workspace automatically.
|
2023-02-22 02:29:48 +03:00
|
|
|
# If you want to add sub crate (like `app/gui/config` or `lib/rust/ensogl/examples`), just add it as a path dependency
|
2022-02-11 15:19:02 +03:00
|
|
|
# where plausible.
|
2023-02-22 02:29:48 +03:00
|
|
|
# Any GUI functionality that is not used by the main entry point should be defined somewhere with `examples` in the
|
|
|
|
|
# path, e.g. `lib/rust/ensogl/examples`, or `app/gui/view/examples`; this is used to optimize the application for
|
|
|
|
|
# loading the IDE.
|
2020-06-16 19:18:11 +03:00
|
|
|
members = [
|
2024-03-07 05:20:21 +03:00
|
|
|
"app/gui2/rust-ffi",
|
|
|
|
|
"build/cli",
|
|
|
|
|
"build/macros/proc-macro",
|
|
|
|
|
"build/ci-gen",
|
|
|
|
|
"build/cli",
|
|
|
|
|
"build/intellij-run-config-gen",
|
|
|
|
|
"build/deprecated/rust-scripts",
|
|
|
|
|
"lib/rust/*",
|
|
|
|
|
"lib/rust/parser/doc-parser",
|
|
|
|
|
"lib/rust/parser/src/syntax/tree/visitor",
|
|
|
|
|
"lib/rust/parser/jni",
|
|
|
|
|
"lib/rust/parser/generate-java",
|
|
|
|
|
"lib/rust/parser/schema",
|
|
|
|
|
"lib/rust/parser/debug",
|
|
|
|
|
"lib/rust/enso-pack",
|
|
|
|
|
"tools/language-server/logstat",
|
|
|
|
|
"tools/language-server/wstest",
|
2020-06-16 19:18:11 +03:00
|
|
|
]
|
2022-02-11 15:19:02 +03:00
|
|
|
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
# We are using a version with extended functionality. The changes have been PR'd upstream:
|
|
|
|
|
# https://github.com/rustwasm/console_error_panic_hook/pull/24
|
|
|
|
|
# Remove this patch when the issue is resolved.
|
|
|
|
|
[patch.crates-io]
|
|
|
|
|
console_error_panic_hook = { git = 'https://github.com/enso-org/console_error_panic_hook' }
|
|
|
|
|
|
2020-06-16 19:18:11 +03:00
|
|
|
[profile.dev]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 0
|
|
|
|
|
lto = false
|
2022-06-02 22:24:18 +03:00
|
|
|
debug = 0
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = true
|
2020-06-16 19:18:11 +03:00
|
|
|
|
|
|
|
|
[profile.release]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 3
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
lto = "thin"
|
|
|
|
|
codegen-units = 16
|
|
|
|
|
incremental = true
|
2021-11-10 16:36:08 +03:00
|
|
|
debug = false
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = false
|
2020-06-16 19:18:11 +03:00
|
|
|
|
|
|
|
|
[profile.bench]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 3
|
|
|
|
|
lto = true
|
|
|
|
|
debug = false
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = false
|
2020-06-16 19:18:11 +03:00
|
|
|
|
|
|
|
|
[profile.test]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 0
|
|
|
|
|
lto = false
|
2023-11-08 19:53:39 +03:00
|
|
|
debug = 2
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = true
|
2022-02-11 15:19:02 +03:00
|
|
|
|
|
|
|
|
[profile.integration-test]
|
|
|
|
|
inherits = "test"
|
2022-04-04 18:55:55 +03:00
|
|
|
opt-level = 2
|
2022-05-23 05:16:04 +03:00
|
|
|
|
|
|
|
|
[profile.buildscript]
|
2022-10-11 00:38:48 +03:00
|
|
|
inherits = "dev"
|
|
|
|
|
opt-level = 1
|
2022-05-23 05:16:04 +03:00
|
|
|
lto = false
|
2022-10-11 00:38:48 +03:00
|
|
|
debug = true
|
2022-05-23 05:16:04 +03:00
|
|
|
debug-assertions = true
|
2022-10-11 00:38:48 +03:00
|
|
|
|
|
|
|
|
[workspace.dependencies]
|
2023-01-28 01:39:37 +03:00
|
|
|
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
|
|
|
|
# !!!!!!!!!! WARNING !!!!!!!!!!
|
|
|
|
|
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
|
|
|
|
# We are tryingto maintain minimum set of dependencies. Before adding a new dependency, consult it
|
|
|
|
|
# with the core development team. Thank you!
|
2022-12-15 22:29:00 +03:00
|
|
|
console-subscriber = "0.1.8"
|
2023-11-23 23:19:31 +03:00
|
|
|
dirs = { version = "5.0.1" }
|
|
|
|
|
nix = { version = "0.27.1" }
|
2023-01-27 03:09:09 +03:00
|
|
|
octocrab = { git = "https://github.com/enso-org/octocrab", default-features = false, features = [
|
2024-03-07 05:20:21 +03:00
|
|
|
"rustls",
|
2023-01-27 03:09:09 +03:00
|
|
|
] }
|
2023-11-23 23:19:31 +03:00
|
|
|
platforms = { version = "3.2.0", features = ["serde"] }
|
2024-01-17 10:54:37 +03:00
|
|
|
portpicker = { version = "0.1.1" }
|
2023-01-28 01:39:37 +03:00
|
|
|
regex = { version = "1.6.0" }
|
2023-11-23 23:19:31 +03:00
|
|
|
serde = { version = "1.0.130", features = ["derive", "rc"] }
|
2023-01-28 01:39:37 +03:00
|
|
|
serde_yaml = { version = "0.9.16" }
|
|
|
|
|
serde-wasm-bindgen = { version = "0.4.5" }
|
2023-11-23 23:19:31 +03:00
|
|
|
sysinfo = { version = "0.29.10" }
|
2022-12-15 22:29:00 +03:00
|
|
|
tokio = { version = "1.23.0", features = ["full", "tracing"] }
|
2023-04-06 02:52:16 +03:00
|
|
|
tokio-stream = { version = "0.1.12", features = ["fs"] }
|
2022-12-15 22:29:00 +03:00
|
|
|
tokio-util = { version = "0.7.4", features = ["full"] }
|
2023-09-22 06:43:25 +03:00
|
|
|
wasm-bindgen = { version = "0.2.87", features = [] }
|
2023-04-19 05:26:01 +03:00
|
|
|
wasm-bindgen-test = { version = "0.3.34" }
|
2023-01-28 01:39:37 +03:00
|
|
|
anyhow = { version = "1.0.66" }
|
|
|
|
|
failure = { version = "0.1.8" }
|
|
|
|
|
derive_more = { version = "0.99" }
|
|
|
|
|
assert_approx_eq = { version = "1.1.0" }
|
|
|
|
|
backtrace = { version = "0.3.53" }
|
|
|
|
|
boolinator = { version = "2.4.0" }
|
|
|
|
|
derivative = { version = "2.2" }
|
|
|
|
|
futures = { version = "0.3" }
|
|
|
|
|
itertools = { version = "0.10.5" }
|
|
|
|
|
lazy_static = { version = "1.4" }
|
|
|
|
|
paste = { version = "1.0" }
|
2023-06-14 21:16:50 +03:00
|
|
|
serde_json = { version = "1.0", features = ["raw_value"] }
|
2023-01-28 01:39:37 +03:00
|
|
|
smallvec = { version = "1.0.0" }
|
|
|
|
|
weak-table = { version = "0.3.0" }
|
|
|
|
|
gen-iter = { version = "0.2.1" }
|
|
|
|
|
js-sys = { version = "0.3" }
|
|
|
|
|
owned_ttf_parser = { version = "0.15.1" }
|
|
|
|
|
const_format = { version = "0.2.22" }
|
|
|
|
|
convert_case = { version = "0.6.0" }
|
|
|
|
|
multi-map = { version = "1.3.0" }
|
|
|
|
|
ordered-float = { version = "3.0.0" }
|
|
|
|
|
rustybuzz = { version = "0.5.1" }
|
|
|
|
|
bincode = { version = "2.0.0-rc.1" }
|
|
|
|
|
byte-unit = { version = "4.0.14", features = ["serde"] }
|
|
|
|
|
bytes = { version = "1.1.0" }
|
|
|
|
|
matches = { version = "0.1" }
|
|
|
|
|
console_error_panic_hook = { version = "0.1.6" }
|
2023-08-02 13:11:53 +03:00
|
|
|
reqwest = { version = "0.11.5", default-features = false, features = [
|
2024-03-07 05:20:21 +03:00
|
|
|
"rustls-tls",
|
|
|
|
|
"stream"
|
2023-08-02 13:11:53 +03:00
|
|
|
] }
|
2023-03-03 01:00:47 +03:00
|
|
|
proc-macro2 = { version = "1.0.50" }
|
Introduce new focus APIs, and use for CB (#7167)
Introduce new APIs for managing focus and using focus to inform delivery of keyboard events.
Use new APIs to implement the following behavior:
Focus:
- If the component browser is opened, its initial state is *focused*.
- If the node input area's text component is clicked, the component browser's state becomes *blurred*.
- If a click occurs anywhere in the component browser, the component browser's state becomes *focused*.
Event dispatch:
- When the component browser is in the *focused* state, it handles certain keyboard events (chiefly, arrow keys).
- If the component browser handles an event, the event is not received by other components.
- If an event occurs that the component browser doesn't handle, the node input area's text component receives the event.
[vokoscreenNG-2023-06-29_10-55-00.webm](https://github.com/enso-org/enso/assets/1047859/f1d9d07c-8c32-4482-ba32-15b6e4e20ae7)
# Important Notes
Changes to display object interface:
- **`display::Object` can now be derived.**
- Introduce display object *focus receiver* concept. Many components, when receiving focus, should actually be focused indirectly by focusing a descendant.
- For example, when the CB Panel receives focus, its descendant at `self.model().grid.model().grid` should be focused, because that's the underlying Grid View, which has its own event handlers. By allowing each level of the hierarchy to define a `focus_receiver`, focus can reach the right object without the CB panel having to know structural details of its descendants.
- When delegating to a field's `display::Object` implementation, the derived implementation uses the child's `focus_receiver`, which will normally be the correct behavior.
**Changes to `shortcut` API**:
- New `View::focused_shortcuts()` is a focus-aware alternative to `View::default_shortcuts()` (which should now only be used for global shortcuts, i.e. shortcuts that don't depend on whether the component is focused). It's based on the *Keyboard Event* API (see below), so events propagate up the focus hierarchy until a shortcut is executed and `stop_propagation()` is called; this allows sensible resolution of event targets when more than one component is capable of handling the same keypress.
Keypress dataflow overview:
DOM -> KeyboardManager -> FrpKeyboard -> KeyboardEvents -> Shortcut.
Low-level keyboard changes to support Focus:
- New `KeyboardManager`: Attaches DOM event handlers the same way as `MouseManager`.
- New *Keyboard Event* API: `on_event::<KeyDown>()`. Events propagate up the focus hierarchy. This API is used for low-level keyboard listeners such a `Text`, which may need complex logic to determine whether a key is handled (rather than having a closed set of bindings, which can be handled by `shortcut`).
- FRP keyboard: Now attaches to the `KeyboardManager` API. It now serves primarily to produce Keyboard Events (it still performs the role of making `KeyUp` events saner in a couple different ways). The FRP keyboard can also be used directly as a global keyboard, for such things as reacting to modifier state.
Misc:
- Updated the workspace `syn` to version 2. Crates still depending on legacy `syn` now do so through the workspace-level `syn_1` alias.
2023-07-27 01:13:48 +03:00
|
|
|
syn = { version = "2.0", features = [
|
2024-03-07 05:20:21 +03:00
|
|
|
"full",
|
|
|
|
|
"extra-traits",
|
|
|
|
|
"printing",
|
|
|
|
|
"parsing",
|
|
|
|
|
"visit",
|
|
|
|
|
"visit-mut",
|
Introduce new focus APIs, and use for CB (#7167)
Introduce new APIs for managing focus and using focus to inform delivery of keyboard events.
Use new APIs to implement the following behavior:
Focus:
- If the component browser is opened, its initial state is *focused*.
- If the node input area's text component is clicked, the component browser's state becomes *blurred*.
- If a click occurs anywhere in the component browser, the component browser's state becomes *focused*.
Event dispatch:
- When the component browser is in the *focused* state, it handles certain keyboard events (chiefly, arrow keys).
- If the component browser handles an event, the event is not received by other components.
- If an event occurs that the component browser doesn't handle, the node input area's text component receives the event.
[vokoscreenNG-2023-06-29_10-55-00.webm](https://github.com/enso-org/enso/assets/1047859/f1d9d07c-8c32-4482-ba32-15b6e4e20ae7)
# Important Notes
Changes to display object interface:
- **`display::Object` can now be derived.**
- Introduce display object *focus receiver* concept. Many components, when receiving focus, should actually be focused indirectly by focusing a descendant.
- For example, when the CB Panel receives focus, its descendant at `self.model().grid.model().grid` should be focused, because that's the underlying Grid View, which has its own event handlers. By allowing each level of the hierarchy to define a `focus_receiver`, focus can reach the right object without the CB panel having to know structural details of its descendants.
- When delegating to a field's `display::Object` implementation, the derived implementation uses the child's `focus_receiver`, which will normally be the correct behavior.
**Changes to `shortcut` API**:
- New `View::focused_shortcuts()` is a focus-aware alternative to `View::default_shortcuts()` (which should now only be used for global shortcuts, i.e. shortcuts that don't depend on whether the component is focused). It's based on the *Keyboard Event* API (see below), so events propagate up the focus hierarchy until a shortcut is executed and `stop_propagation()` is called; this allows sensible resolution of event targets when more than one component is capable of handling the same keypress.
Keypress dataflow overview:
DOM -> KeyboardManager -> FrpKeyboard -> KeyboardEvents -> Shortcut.
Low-level keyboard changes to support Focus:
- New `KeyboardManager`: Attaches DOM event handlers the same way as `MouseManager`.
- New *Keyboard Event* API: `on_event::<KeyDown>()`. Events propagate up the focus hierarchy. This API is used for low-level keyboard listeners such a `Text`, which may need complex logic to determine whether a key is handled (rather than having a closed set of bindings, which can be handled by `shortcut`).
- FRP keyboard: Now attaches to the `KeyboardManager` API. It now serves primarily to produce Keyboard Events (it still performs the role of making `KeyUp` events saner in a couple different ways). The FRP keyboard can also be used directly as a global keyboard, for such things as reacting to modifier state.
Misc:
- Updated the workspace `syn` to version 2. Crates still depending on legacy `syn` now do so through the workspace-level `syn_1` alias.
2023-07-27 01:13:48 +03:00
|
|
|
] }
|
|
|
|
|
syn_1 = { package = "syn", version = "1.0", features = [
|
2024-03-07 05:20:21 +03:00
|
|
|
"full",
|
|
|
|
|
"extra-traits",
|
|
|
|
|
"printing",
|
|
|
|
|
"parsing",
|
|
|
|
|
"visit",
|
|
|
|
|
"visit-mut",
|
2023-03-03 01:00:47 +03:00
|
|
|
] }
|
|
|
|
|
quote = { version = "1.0.23" }
|
2023-05-08 17:13:53 +03:00
|
|
|
semver = { version = "1.0.0", features = ["serde"] }
|
2023-07-24 22:58:53 +03:00
|
|
|
strum = { version = "0.24.0", features = ["derive"] }
|
2023-05-08 17:13:53 +03:00
|
|
|
thiserror = "1.0.40"
|
2023-06-17 17:14:19 +03:00
|
|
|
bytemuck = { version = "1.13.1", features = ["derive"] }
|
2023-05-17 21:53:51 +03:00
|
|
|
bitflags = { version = "2.2.1" }
|
2023-07-21 13:11:39 +03:00
|
|
|
superslice = { version = "1.0.0" }
|
2023-07-24 22:58:53 +03:00
|
|
|
# We don't use serde-wasm-bindgen in some cases, because it cannot deal properly with flattened fields, see:
|
|
|
|
|
# https://github.com/cloudflare/serde-wasm-bindgen/issues/9
|
|
|
|
|
gloo-utils = { version = "0.1.7" }
|
