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.
|
|
|
|
|
# If you want to add sub crate (like `app/gui/config` or `lib/rust/ensogl/example`), just add it as a path dependency
|
|
|
|
|
# where plausible.
|
2020-06-16 19:18:11 +03:00
|
|
|
members = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"app/gui",
|
|
|
|
|
"app/gui/enso-profiler-enso-data",
|
2022-10-11 00:38:48 +03:00
|
|
|
"build/cli",
|
2022-11-09 02:15:26 +03:00
|
|
|
"build/macros",
|
2022-05-23 05:16:04 +03:00
|
|
|
"build/enso-formatter",
|
2022-11-03 10:35:06 +03:00
|
|
|
"build/intellij-run-config-gen",
|
2022-10-11 00:38:48 +03:00
|
|
|
"build/deprecated/rust-scripts",
|
2022-05-23 05:16:04 +03:00
|
|
|
"lib/rust/*",
|
|
|
|
|
"lib/rust/parser/src/syntax/tree/visitor",
|
2022-07-25 17:24:21 +03:00
|
|
|
"lib/rust/parser/jni",
|
Parser: Transpile Rust AST types to Java types (#3555)
Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust.
### New Libraries
#### `enso-reflect`
Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs).
#### `enso-metamodel`
Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term).
The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`.
The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process.
### Important Notes
- Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases.
- Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code.
- `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants.
- Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.)
### Binaries
The `enso-parser-generate-java` crate defines several binaries:
- `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script.
- `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing.
- `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations.
Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
|
|
|
"lib/rust/parser/generate-java",
|
2022-10-12 20:40:16 +03:00
|
|
|
"lib/rust/parser/debug",
|
2022-05-23 05:16:04 +03:00
|
|
|
"lib/rust/profiler/data",
|
2022-09-30 09:45:31 +03:00
|
|
|
"lib/rust/profiler/demo-data",
|
2022-07-22 17:12:52 +03:00
|
|
|
"integration-test",
|
|
|
|
|
"tools/language-server/logstat",
|
2022-09-19 22:02:18 +03:00
|
|
|
"tools/language-server/wstest",
|
2020-06-16 19:18:11 +03:00
|
|
|
]
|
2022-02-11 15:19:02 +03:00
|
|
|
# The default memebers are those we want to check and test by default.
|
|
|
|
|
default-members = ["app/gui", "lib/rust/*"]
|
|
|
|
|
|
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
|
|
|
|
|
debug = true
|
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]
|
|
|
|
|
tokio = { version = "=1.20.1", features = ["full", "tracing"] }
|
|
|
|
|
console-subscriber = "=0.1.7"
|
|
|
|
|
nix = "=0.24.1" # DO NOT BUMP UNTIL NIGHTLY IS UPDATED. Otherwise, it brings too new libc.
|
