close#7184
The constructor value was not accessible because during the re-compilation a new instance of the type was registered in runtime. Then during the execution, an old cached instance of the type was used in method resolution.
Changelog:
- update: the registration of types in runtime
- update: invalidate cached nodes that became a resolution error after applying the edit
More cases in E2E tests checking all ways of using component browser.
The tests found one actual bug: sometimes we displayed only a few entries after opening CB because the scroller size was not refreshed (we assumed it will be available in the next tick). Refactored Component Browser so it does not use nextTick anymore.
Further AST integration and API refinement before introducing the new synchronization mechanism.
closes#8609
# Important Notes
API changes:
- Renamed `Ast.parseExpression` / `Ast.parse` to better reflect their usage:
- `Ast.parse` returns a block or a single expression, depending on its input; this is convenient for expressions expected to be single-line.
- `Ast.parseBlock` always treats its input as a block; this is suitable for parsing a file.
- `astExtended` is no longer needed to access span information. `Ast.span` provides access to the value when appropriate (the project's committed modules have spans; uncommitted changes or other parsed expressions don't).
- `SourceRange` is now used everywhere in place of `ContentRange`--the two types had the same definition.
Features:
- Fix CodeEditor viewing.
Implementation improvements:
- Updated widget update handlers (#8545) implementation to Ast API.
- Integrated `imports` more thoroughly with new AST APIs.
- More tests.
After #8620, there is a noticeable slowdown in `EqualsBenchmarks.equalsTrees` as suggested in https://github.com/enso-org/enso/pull/8620#issuecomment-1870776609. After some digging, I realized that the number of warmup iterations is most probably insufficient. Let's increase the warmup for this benchmark and see if we can get its score down again.
I noticed that sources in `runtime/bench` are not formatted at all. Turns out that the `JavaFormatterPlugin` does not override `javafmt` task for the `Benchmark` configuration. After some failed attempts, I have just redefined the `Benchmark/javafmt` task in the `runtime` project. After all, the `runtime` project is almost the only project where we have any Java benchmarks.
# Important Notes
`javafmtAll` now also formats sources in `runtime/bench/src/java`.
After #8467, Engine benchmarks are broken, they cannot compile - https://github.com/enso-org/enso/actions/runs/7268987483/job/19805862815#logs
This PR fixes the benchmark build
# Important Notes
Apart from fixing the build of `engine/bench`:
- Don't assemble any fat jars in `runtime/bench`.
- Use our `TestLogProvider` in the benches instead of NOOP provider.
- So that we can at least see warnings and errors in benchmarks.
Implements #8525
[Screencast from 18-12-23 14:40:29.webm](https://github.com/enso-org/enso/assets/1428930/c7db2a9d-0020-4bce-b44c-d6712df58098)
# Important Notes
Previously, we re-used the API from the dashboard. But this mechanism is brittle and is currently even broken with the new GUI. So instead, I just used the Vue equivalent toast API, which seems easier to use.
- Closes https://github.com/enso-org/cloud-v2/issues/804
- The GUI should now properly configure deep links and auth settings, among other things, because the logic has been ported over from the GUI1 runner.
- The porting was very basic; it may be a good idea to refactor it later, but that is out of scope of this PR.
- This also means that `runner/` should be safe to remove along with GUI1 in the future, as all code relevant to GUI2 now resides in `app/gui2/runner`.
# Important Notes
- The built `ide2` has been tested on Windows, but should also be tested on macOS.
- Should *also* be fully tested in `npm run dev`.
Make sure that the correct test logging provider is loaded in `project-manager/Test`, so that only WARN and ERROR log messages are displayed. Also, make sure that the test log provider parses the correct configuration file - Rename all the `application.conf` files in the test resources to `application-test.conf`.
The problem was introduced in #8467
- After [suggestion](https://github.com/enso-org/enso/pull/8497#discussion_r1429543815) from @JaroslavTulach I have tried reimplementing the URL encoding using just `URLEncode` builtin util. I will see if this does not complicate other followup improvements, but most likely all should work so we should be able to get rid of the unnecessary bloat.
E2E were failing on develop, now they're fixed.
1. There was a problem in CB which I don't know by what was triggered (But this test is fixed/extended anyway in #8559
2. Otherwise, the test scenes didn't have any nodes due to some races in initialization.
- Closes https://github.com/enso-org/cloud-v2/issues/787
# Important Notes
- Only an issue on macOS. This fix has been tested a bit on macOS, but it doesn't hurt to test again. It also wouldn't hurt to test on Windows and perhaps mobile too.
- The module is edited by changing the AST, not the text representation.
- `IdMap`s no longer need to be maintained in parallel with the module content; they are snapshots produced as needed from the ASTs.
- Simplistic synchronization is in place until #8237: Edits are never merged; if two edits are started from the same state, one will be overwritten.
- Closes#8354
- Extends `simple-httpbin` with a simple mock of the Cloud API (currently it checks the token and serves the `/users` endpoint).
- Renames `simple-httpbin` to `http-test-helper`.
It is currently not possible to understand the nature of random timeouts for launcher tests on MacOS. Hopefully the additional info will bring us closer to understanding where is the problem.
Related to #8546.
Followup to #8467
Fixes the issue when `runtime/test` command fails to compile without fat jar classes:
```
sbt:enso> runtime/test
[warn] JPMSPlugin: Directory /home/dbushev/projects/luna/enso/engine/runtime-fat-jar/target/scala-2.13/classes does not exist.
[warn] JPMSPlugin: Directory /home/dbushev/projects/luna/enso/engine/runtime-fat-jar/target/scala-2.13/classes does not exist.
[info] compiling 106 Scala sources and 60 Java sources to /home/dbushev/projects/luna/enso/engine/runtime/target/scala-2.13/test-classes ...
[warn] Unexpected javac output: error: module not found: org.enso.runtime
[warn] 1 error.
[warn] frgaal exited with exit code 1
[error] (runtime / Test / compileIncremental) javac returned non-zero exit code
```
We infer old IDs from module's IRs location, instead. This workarounds ill-constructed IdMaps at the start of the project.
If IDE or backend ends up with invalid ID map, I suppose application of edits might still fail.
# Important Notes
Closes#8500 by not doing the parsing at all. Since I couldn't figure why we had invalid metadata in the first place, this might still bite us at some point.
- Closes#8398
# Important Notes
- The original error caused by a failing `text/openFile` (`openTextFile`) is still present, but (seemingly?) harder to repro now
close#7555
Compiler passes after `GenerateMethodBodies` expect the method body to be a function.
After fixing the pass, the compilation returns a proper compiler error:
```
built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Table/0.0.0-dev/src/Data/Column.enso:869:22: error: Methods must have only one definition of the `this` argument, and it must be the first.
869 | round self round self (decimal_places:Integer = 0) (use_bankers:Boolean = False) = Value_Type.expect_numeric self <|
| ^~~~
Aborting due to 1 errors and 0 warnings.
```
- Closes#8352
- ~~Proposed fix for #8493~~
- The temporary fix is deemed not viable. I will try to figure out a workaround and leave fixing #8493 to the engine team.
- Remove validation from old password and login password.
- Use login and logout consistently (rather than sign in and sign out in some places).
- Change message on user not found.
