Fixes warnings on SBT startup
```
$ sbt
[info] welcome to sbt 1.9.0 (GraalVM Community Java 17.0.7)
...
[warn] 5 feature warnings; re-run with -feature for details
[warn] one warning found
[info] loading settings for project enso from build.sbt ...
```
* Add support for https and wss
Preliminary support for https and wss. During language server startup we
will read the application config and search for the `https` config with
necessary env vars set.
The configuration supports two modes of creating ssl-context - via
PKCS12 format and certificat+private key.
Fixes#7839.
* Added tests, improved documentation
Generic improvements along with actual tests.
* lint
* more docs + wss support
* changelog
* Apply suggestions from code review
Co-authored-by: Dmitry Bushev <bushevdv@gmail.com>
* PR comment
* typo
* lint
* make windows line endings happy
---------
Co-authored-by: Dmitry Bushev <bushevdv@gmail.com>
- Removed `Cursor` and moved all accessors to standalone functions, reducing the generated code size significantly (especially after minification).
- Removed unnecessary `seek`s from everywhere. Now the offseting is part of each `read` implementation.
- Removed unnecessary differences between `read`s on abstract and concrete types. Now abstract types do the pointer access internally in their `read`.
Removes dependencies that should not be in the root `package.json`
Basic testing done with `npm run ci-check`.
Introduced by the following PRs (in order of being merged):
See blame for more details: https://github.com/enso-org/enso/blame/develop/package.json
- #7813
- #7656 (oops)
- #7881
# Important Notes
None
- Closes#7925
# Important Notes
The type -> matching visualization lookup is populated using a `Promise`, so there is a race condition where the selector will incorrectly show the full list of visualizations if it is opened before the `Promise` resolves.
Generate TS bindings and lazy deserialization for the parser types.
# Important Notes
- The new API is imported into `ffi.ts`, but not yet used.
- I have tested the generated code in isolation, but cannot commit tests as we are not currently able to load WASM modules when running in `vitest`.
- Implements https://github.com/enso-org/cloud-v2/issues/631
- Tests for dashboard (`app/ide-desktop/lib/dashboard/`):
- End-to-end tests
- Unit tests
- Component tests
The purpose of this PR is to introduce the testing framework - more tests can be added later in separate PRs.
# Important Notes
To test, run `npm run test` in `app/ide-desktop`, or `app/ide-desktop/lib/dashboard/`. All tests should pass.
Individual test types can be run using `npm run test-unit`, `npm run test-component` and `npm run test-e2e` in `app/ide-desktop/lib/dashboard/`.
Individual end-to-end tests can be run using `npx playwright test -c playwright-e2e.config.ts test-e2e/<file name>.spec.ts` in `app/ide-desktop/lib/dashboard/`.
End-to-end tests require internet access to pass (for things like fonts).
This PR *does* check in screenshots to guard against visual regessions (and/or to make visual changes obvious)
- Implements frontend component of https://github.com/enso-org/cloud-v2/issues/702
- Ensures that the new name is not already present in a sibling in the directory
- Only compares between directories when renaming a directory
- Only compares between files/projects/connectors when renaming one of those
# Important Notes
- This has not been implemented for connectors and files as currently there is no backend endpoint to rename those.
- Secrets are also not implemented yet, AFAIK, so there is no behavior related to secrets.
- Fixes a bug where creating a temporary table could accidentally issue a `DROP` statement of the table name that the user provided, risking destruction of user data.
- Fortunately, the bad scenario was almost impossible, because the `DROP` statement was only issued _if_ we previously checked that the mentioned table _does not exist_ - dropping a nonexistent table does not do any harm.
- It could have been dangerous in a very unlikely scenario that a table was created just between the _existence check_ and the _drop_.
- After the fix the existence check and any modifications are done within a transaction to avoid interference from concurrent modifications, and the DROP is correctly applied to a temporary Enso table instead of the original one.
- Replaced a temporary log with proper simple logging of SQL statements into a file, if an Environment variable is set.
- Used that feature to test that no unexpected statements occur.
- Closes#7749 implementing the in-memory logic.
- Additional complications have surfaced regarding the Database logic, so it has been split off into a separate ticket: #7981
Fixes this issue:
- #7917
This is caused by the dashboard expecting `engineVersion` to be present, whereas it is actually optional.
# Important Notes
This may have been fixed on the Project Manager side, so the bug may not be reproducible. To properly test that this fix works, an older `project-manager` (e.g `2023.2.1-nightly.2023.9.30`) should be used.
- Depends on #7773.
- Implements binary WebSocket protocol (data protocol)
- Performs some editor initialization (the bare minimum so that visualizations work)
- Adds event handlers to receive visualization data updates
# Important Notes
None
We currently scan the entire child list for each call to children, num_children, and get_child_element.
Instead, we should cache the filtered child list on first access.
close#7871close#7698
Changelog:
- fix: the `run` script logic to place the GraalVM runtime in the expected directory when building the bundle
- fix: the `makeBundles` SBT logic to place the GraalVM runtime in the expected directory
This PR includes
* Reading XML from a file, stream, or string
* Reading XML via Data.fetch
* Accessing the root element, element children, and attributes
* Accessing tag text contents
* Get tags by name
* Inner / Outer XML string
It looks like visualization commands had required context lock unnecessairly. Context manager methods are synchronized and therefore should not need the lock before submitting a correspodning background job.
Additionally, the presence of a context lock leads a deadlock:
1. Consider a long running execution of a program that does not finish within the 5 seconds
2. In the meantime there comes either an `AttachVisualization` or `DetachVisualization` request from the client
The latter will get stuck and eventually timeout out because it cannot acquire the lock withing the required time limits. It is still possible that a single long-running `ExecuteJob` might block other ones (including visualization ones) but that's a separate work.
Fixes some issues present in #7941.
# Important Notes
We need to still investigate `ExecuteJob`s need for context lock which might delay the execution of other background jobs that require it as well (mostly concerned about visualization).
Closes#6417
Creating and editing nodes with a component browser does not edit the node in place but creates a temporary AST node with the execution context switch. When the node is committed, the original AST is replaced by the new one, and the temporary node is removed.
This solves several issues:
1. Previewing suggestions or editing nodes should no longer produce unwanted side effects, as the edited node expression is always evaluated with the output context being disabled.
2. Errors no longer propagate down the graph when you edit the node. The edited node has no outputs connected. Inputs behave normally, though.
3. Undo-redo and editing abort is much simpler. To abort editing, remove the temporary node.
https://github.com/enso-org/enso/assets/6566674/8d38e6bc-a4de-4e69-8d48-52d9b45b6554
# Important Notes
The code is a bit awkward in a few places. This is the consequence of previous architecture.
Fixes#7474
Again, a quite complicated issue. The code editor was broken by https://github.com/enso-org/enso/pull/7167 for a few reasons:
1. The text component's shortcuts depend on the `focused` FRP endpoint, which is controlled by `deprecated_(de)focus` inputs. `focused` output was not changed by the code editor `model.focus()` call. (we still use `deprecated_focus` for all other components)
2. `focus()` FRP input was added to the text component but never triggered. It's too easy to confuse it with the `focus()` method of the `object::Instance` (Deref is evil!)
3. The graph editor handles clicks on the background by `blur_tree()`, effectively blurring any focused element in the application. But clicking on code editor (to focus it) also causes a click on the background! So we focus the code editor, and then handle the background click, defocusing it from the graph editor's point of view. It allows graph editor to open CB on <kbd>Enter</kbd> while the code editor is still active.
I solved (3) by disallowing CB opening while code editor is visible. Not ideal, but I guess it solves the issue.
Do you think the other solution is possible – to add some overlay for the code editor and avoid triggering `blur_tree` when clicking on it? That won't work because you still can't defocus the code editor using the new API, so it will always be focused.
So we have a situation when half of the app uses the new focus system, another half uses the old one, and none works properly.
https://github.com/enso-org/enso/assets/6566674/3a0d36ed-4d50-4606-9486-272fbd5d9cb7
* Q: Is it normal for `--inspect` mode to print two debug urls?
* A: No, it should print just one.
* Q: Putting there a Java breakpoint to find out why it the chromeinspector gets initialized twice might reveal the culprit.
* A: The additional listener is happening [here](https://github.com/enso-org/enso/blob/develop/engine/runner/src/main/scala/org/enso/runner/ContextFactory.scala#L117).
# Important Notes
There is no easy check for a language being present without creating an `Engine`. It was thought creating an `Engine` is cheap operation, but it seems to have some downsides. Let's use `ENSO_JAVA` environment variable to decide whether _experimental Espresso_ support shall be enabled.
Closes#7823
We set fallback color for components without an assigned group, use a color defined in the group, or otherwise derive the color from the group name.
All group colors are available in the graph editor as CSS variables so that they can be dynamically edited and debugged via dev tools.
For deriving the color, we use [murmurhash](https://www.npmjs.com/package/murmurhash), which quickly produces sufficiently uniformly distributed 32-bit values and [oklch](https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl) colorspace. We will still have *some* hash collisions between different groups, but it shouldn't matter that much. I have also tried a few other hashes (namely `cybr53` and Java's string hashing), and the results were more or less similar.
`oklch` is rather a new thing in CSS, but it is available starting with Chrome 111, which is exactly the version we're using in Electron.
https://github.com/enso-org/enso/assets/6566674/7177f041-93e9-4536-b19f-6b67a2da8b7e
Adds the ability to declare a module as *private*. Modifies the parser to add the `private` keyword as a reserved keyword. All the checks for private modules are implemented as an independent *Compiler pass*. No checks are done at runtime.
# Important Notes
- Introduces new keyword - `private` - a reserved keyword.
- Modules that have `private` keyword as the first statement are declared as *private* (Project private)
- Public module cannot have private submodules and vice versa.
- This would require runtime access checks
- See #7088 for the specification.
- Fixes#7352 by remembering original value types in type inference mode to be able to reconstruct them for Mixed.
- Added more benchmarks for comparing performance of constructing columns.
- Fixes missing implementations that caused `Table.union` crashing on some type pairs.
- Ensures that `Loss_Of_Integer_Precision` warning is not swallowed when numeric columns are unioned to create a `Float` column.
- Adds test for all of the above cases.
- Allow to output benchmark results to a CSV by setting an environment variable - useful for quickly comparing benchmarks, e.g. in Enso.
This PR adds support for the new Vue-based GUI (aka `gui2`).
The user-facing changes are primarily:
* support for `./run gui2` and `./run ide2` commands (that build just the new GUI and the whole IDE package with new GUI embedded — respectively);
* the top-level `test` and `lint` commands will now invoke the relevant commands on the new GUI
---------
Co-authored-by: Paweł Grabarz <frizi09@gmail.com>
