Previously, static method calls on `Any` have not worked as expected. For example, `Any.to_text` returned Function instead of Text. That is because the function resolution for `Any.to_text` finds `Any.type.to_text` method on eigentype which expects two `self` arguments, but only one argument is provided.
Note that `Boolean.to_text` worked previously, and returned "Boolean" as expected. This is because the method resolution finds `Any.to_text` method that takes just one `self` argument.
This PR solves this issue by introducing special handling for static method dispatch on `Any`. Simply put, an additional `self` argument is prepended to the argument list.
# Important Notes
A new child node is introduced to `InvokeMethodNode`. This child node is a copy of the current `invokeFunctionNode` with one more `CallArgumentInfo` in its schema.
* Extract SVGs to individual files
Probably not working for cloud frontend (`watch-dashboard`, `build-dashboard`) yet
Dynamic SVGs were not extracted out
* Make file SVGs work for `watch-dashboard` and `build-dashboard`
* Document SVG loaders
* Address QA issues
There is an issue that after a clean build, the compiler is unable to resolve some types, i.e
```py
$ ./built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/bin/enso --run ~/enso/projects/Unnamed/
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:24:11: error: The name `Connection_Details` could not be found.
24 | connect : Connection_Details -> Connection_Options -> Connection ! SQL_Error
| ^~~~~~~~~~~~~~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:24:33: error: The name `Connection_Options` could not be found.
24 | connect : Connection_Details -> Connection_Options -> Connection ! SQL_Error
| ^~~~~~~~~~~~~~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:24:55: error: The name `Connection` could not be found.
24 | connect : Connection_Details -> Connection_Options -> Connection ! SQL_Error
| ^~~~~~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:24:68: error: The name `SQL_Error` could not be found.
24 | connect : Connection_Details -> Connection_Options -> Connection ! SQL_Error
| ^~~~~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:25:25: error: The name `Connection_Options` could not be found.
25 | connect details options=Connection_Options.Value =
| ^~~~~~~~~~~~~~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:29:29: error: The name `Widget` could not be found.
29 | connection_details_widget : Widget
| ^~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:31:28: error: The name `Vector` could not be found.
31 | default_constructors = Vector.from_polyglot_array <|
| ^~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:32:63: error: The name `False` could not be found.
32 | DatabaseConnectionDetailsSPI.get_default_constructors False
| ^~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:36:9: error: The name `Option` could not be found.
36 | Option name code
| ^~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:37:5: error: The name `Single_Choice` could not be found.
37 | Single_Choice display=Display.Always values=choices
| ^~~~~~~~~~~~~
/home/dbushev/projects/luna/enso/built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Database/0.0.0-dev/src/Connection/Database.enso:37:27: error: The name `Display` could not be found.
37 | Single_Choice display=Display.Always values=choices
| ^~~~~~~
Aborting due to 11 errors and 0 warnings.
Execution finished with an error: Compilation aborted due to errors.
```
The compiler can't resolve those symbols because the `IR` cache for `Standard.Database.Connection.Database` is missing. What happens during the `buildEngineDistribution` is:
- Compiler processes libraries one by one
- Compiler processes (and compiles and generates caches) `Standard.Database` library
- Compiler starts processing `Standard.Visualization` library
- During the compilation of `Standard.Database.Connection.Database` module, it sees that the module was loaded from the cache. But some of the required dependencies from `Standard.Table` library were not loaded from the cache. But at this point, the `Standard.Table` library has not been processed yet and the caches for it don't exist. The compiler decides that the `Database` file was changed, and the cache is invalid and should be cleaned.
Remove a leak detector added in #7038, that has a large (~10s) impact on startup performance. I missed the performance impact during QA, but noticed it after merge.
Fixes#6908
Fast typing leads to a race condition where the end of the node editing can happen where the state of the CB is not caught up yet. This leads to two issues:
1. The wrong selection is made, as the View of the Component Browser has not been updated yet, but the selection from there is used to determine how the node is created.
2. Processing of the keys is aborted early, while still waiting for additional key input.
This is now fixed.
https://github.com/enso-org/enso/assets/1428930/dce82bb3-1c25-4a67-988a-d74469dc8fcd
Closes#6705
This PR removes Tailwind from dependencies of the documentation panel and also brings some essential design improvements.
List of fixed things:
- Massive refactoring, removing unnecessary HTML tags, and simplifying the overall layout.
- Spacing to the right of the bullet in the bullet lists is much smaller. Bullets also have the same color as the following text.
- Paddings before headers increased.
- Colon used instead of the comma between the method link and its summary.
- Module or type names in the top header are now delimited by `.`, which matches the Enso language.
- We now use Twemoji icons in marked sections. Now `Info` and `Important` icons are much nicer.
- Constructors are now in a separate section as methods.
- Headers correctly handle long entry names.
List of not fixed things: (I will create additional issues for them)
- Argument names in the list are not bold. We receive a `<ul>` HTML code from the engine. We don't know whether it contains argument names or something else. It requires support from the LS protocol.
- No highlight for things delimited by `<pre>` tags in the text (like `Nothing` on the screenshot below). It also requires support from the LS protocol because we don't inspect received text and can't modify it.
In the video from IDE, you can see some issues with spacing in the documentation, namely redundant blank lines at the beginning of each example and multiline (and multi-paragraph!) summaries for methods. This can't be fixed on the IDE side. I will create separate issues for that.
https://github.com/enso-org/enso/assets/6566674/e4cef3d1-7a13-4d3b-b11d-f5ee2c05ca82https://github.com/enso-org/enso/assets/6566674/43970982-ba43-4530-8ffd-6bce790d5d77
Fixes#6816.
The code for adding imports for dropdown widgets was unified with CB. The code was moved from the searcher controller to the graph controller.
Also, I changed the signature for a few `lookup_*` methods of the suggestion database, because I have always found it weird that they return `Option` instead of `Result`. They now work nicely with the surrounding code.
https://github.com/enso-org/enso/assets/6566674/49125f8d-096e-4cca-a922-4811ed717a4d
Fixes#6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
1. Fixed leaks of Scene. We were making several cycles of Rc references.
2. Fix removing event listeners: the remove listener option should take same options as those passed in addEventListener.
This should finally fix#6505
Fixes#6855
Correctly sets the layers of the full-screen panel and the scrollbars. The full-screen panel needs to be in the `panel` layer, as it is fixed and above everything else. The scrollbars in the text visualization should be placed together with their parents, so they are switched correctly between layers when enabling/disabling full-screen. Leaving their layer otherwise unspecified should not lead to occlusion issues, as all other elements in the text visualization are Dom elements, and therefore placed below EnsoGL elements.
https://github.com/enso-org/enso/assets/1428930/db80c5b7-69fd-4bf5-84ab-c83664227059
- Removed `module` argument from `enso_project` (new `Project_Description.new` API).
- Removed the custom option from date and time parse/format dropdowns.
- The `format` dropdown uses the value to create the dropdown. (Screenshot below)
- Removed `StorageType` coalescing rules and replaced them with simpler logic in `ObjectStorage`.
- Update signature for `add_row_number` and add aliases.
Request Timeouts started plaguing IDE due to numerous `executionContext/***Visualization` requests. While caused by a bug they revealed a bigger problem in the Language Server when serving large amounts of requests:
1) Long and short lived jobs are fighting for various locks. Lock contention leads to some jobs waiting for a longer than desired leading to unexpected request timeouts. Increasing timeout value is just delaying the problem.
2) Requests coming from IDE are served almost instantly and handled by various commands. Commands can issue further jobs that serve request. We apparently have and always had a single-thread thread pool for serving such jobs, leading to immediate thread starvation.
Both reasons increase the chances of Request Timeouts when dealing with a large number of requests. For 2) I noticed that while we used to set the `enso-runtime-server.jobParallelism` option descriptor key to some machine-dependent value (most likely > 1), the value set would **only** be available for instrumentation. `JobExecutionEngine` where it is actually used would always get the default, i.e. a single-threaded ThreadPool. This means that this option descriptor was simply misused since its introduction. Moved that option to runtime options so that it can be set and retrieved during normal operation.
Adding parallelism intensified problem 1), because now we could execute multiple jobs and they would compete for resources. It also revealed a scenario for a yet another deadlock scenario, due to invalid order of lock acquisition. See `ExecuteJob` vs `UpsertVisualisationJob` order for details.
Still, a number of requests would continue to randomly timeout due to lock contention. It became apparent that
`Attach/Modify/Detach-VisualisationCmd` should not wait until a triggered `UpsertVisualisationJob` sends a response to the client; long and short lived jobs will always compete for resources and we cannot guarantee that they will not timeout that way. That is why the response is sent immediately from the command handler and not from the job executed after it.
This brings another problematic scenario:
1. `AttachVisualisationCmd` is executed, response sent to the client, `UpsertVisualisationJob` scheduled.
2. In the meantime `ModifyVisualisationCmd` comes and fails; command cannot find the visualization that will only be added by `UpsertVisualisationJob`, which might have not yet been scheduled to run.
Remedied that by checking visualisation-related jobs that are still in progress. It also allowed for cancelling jobs which results wouldn't be used anyway (`ModifyVisualisationCmd` sends its own `UpsertVisualisationJob`). This is not a theoretical scenario, it happened frequently on IDE startup.
This change does not fully solve the rather problematic setup of numerous locks, which are requested by short and long lived jobs. A better design should still be investigated. But it significantly reduces the chances of Request Timeouts which IDE had to deal with.
With this change I haven't been able to experience Request Timeouts for relatively modest projects anymore.
I added the possibility of logging wait times for locks to better investigate further problems.
Closes#7005
- Add type detection for `Mixed` columns when calling column functions.
- Excel uses column name for missing headers.
- Add aliases for parse functions on text.
- Adjust `Date`, `Time_Of_Day` and `Date_Time` parse functions to not take `Nothing` anymore and provide dropdowns.
- Removed built-in parses.
- All support Locale.
- Add support for missing day or year for parsing a Date.
- All will trim values automatically.
- Added ability to list AWS profiles.
- Added ability to list S3 buckets.
- Workaround for Table.aggregate so default item added works.
Fixes performance problems observed when creating/resolving errors (#6674):
|before|after|
|---|---|
|||
This also helps with #6637, although I haven't been able to reproduce the degree of slowness shown there so I can't confirm that this resolves that issue.
# Important Notes
- Disable visualizations until shown. [Faster startup, and all graph changes.]
- 6x faster message deserialization. [Saves 400ms when making a change with many visualizations open.]
- Fast edge recoloring. [Saves 100-150ms when disconnecting an edge in Orders.]
- Add a checked implementation of a `profiler` data structure, used instead of the fast `unsafe` version when `debug-assertions` are enabled.
Several small changes:
- Dropdowns: Populate `GridView` lazily (fixes#6865).
- Clear disconnected edges when editing node (fixes case 1 in #7018).
- Fix regression in node selection rendering (2nd bug in #6975).
- Update profiler docs. The hotkey to *prOfile without exiting* is now `Ctrl+Alt+O` (`Ctrl+Alt+P` has been requisitioned by the CB).
Node selection:
| Pre-`Rectangle` | This PR |
| --- | --- |
|  |  |
# Important Notes
- `Rectangle`: When `inset > border`, the extra space is now between the body and the border, not outside the border.
- More robust node layering logic. Now an inconsistent layer order cannot occur, even if something strange happens (like editing an expression and an edge at the same time).
- The dynamic drop down in the `drop_down` example scene doesn't show any entries before (or after) this, so I can't test the dynamic case.
This adds the spec for all update actions, but implements the common input validation framework and `Insert`. Tests for remaining actions are marked as pending - these will be implemented in a subsequent PR.
close#6936
Changelog:
- add: new suggestion type Getter that is not exposed to the api
- update: do not return suggestion of type getter when doing a global search (without specifying self types)
Private suggestions and modules mentioned in the issue will be filtered out after we finish the work on the new (refined) exports algorithm.
# Important Notes
This PR adds facilities for controllers to be aware of what shortcut command is currently being processed. This allows grouping consequences of single user action into a single transaction without hard-coding it separately for all the separate paths case-by-case, which turned out to be challenging and error-prone.
Additionally, a number of minor fixes were carried over from #6877:
* workaround for #6718;
* avoiding creating spurious transactions when dealing with node positions;
* dropping any non-user user-triggered transactions that occur during the IDE project initialization.
Before, we prevented default on every keyboard event, making usage of HTML inputs impossible (both on the dashboard and inside visualizations).
# Important Notes
The list of shortcuts was based on comments in #6364 (where the `preventDefault` was introduced).
As demonstrated in https://github.com/enso-org/enso/actions/runs/5175688022/jobs/9323585204?pr=6940
```
org.enso.interpreter.test.instrument.RuntimeAsyncCommandsTest *** ABORTED ***
org.graalvm.polyglot.PolyglotException: java.util.NoSuchElementException
at java.base/java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:811)
at java.base/java.util.WeakHashMap$EntryIterator.next(WeakHashMap.java:848)
at java.base/java.util.WeakHashMap$EntryIterator.next(WeakHashMap.java:846)
at org.enso.interpreter.runtime.ThreadExecutors.shutdown(ThreadExecutors.java:46)
at org.enso.interpreter.runtime.EnsoContext.shutdown(EnsoContext.java:198)
at org.enso.interpreter.EnsoLanguage.finalizeContext(EnsoLanguage.java:179)
at org.enso.interpreter.EnsoLanguage.finalizeContext(EnsoLanguage.java:65)
at org.graalvm.truffle/com.oracle.truffle.api.LanguageAccessor$LanguageImpl.finalizeContext(LanguageAccessor.java:326)
at org.graalvm.truffle/com.oracle.truffle.polyglot.PolyglotLanguageContext.finalizeContext(PolyglotLanguageContext.java:404)
at org.graalvm.truffle/com.oracle.truffle.polyglot.PolyglotContextImpl.finalizeContext(PolyglotContextImpl.java:2925)
```
There was an inherent race condition between edit, close & open commands which could not be prevented solely using locks. `EditFileCmd` triggered `EnsureCompiledJob` which was applying edits collected over time. At the same `CloseFileCmd` and `OpenFileCmd` were executed asynchronously and required locks on compilation unit and file lock.
Additionally, open file was resetting the module's runtime source irrespective of any edits that could already have been applied with the asynchronous execution in `EnsureCompiledJob`. This was visible especially during early manipulation of the project when open/close was performed due to a bug in IDE (#6843).
Now commands can be run either synchronously or asynchronously. Only that way can we ensure that `close` & `open` commands finish by the time any editions are being applied to module's sources.
Closes#6841.
# Important Notes
In the given video, `"foo"` would be greyed out because it would never be part of the module's (runtime) sources. Therefore no IR would be generated for it or instrumentation, meaning it would be present in `expressionUpdates` information necessary for IDE.
[Kazam_screencast_00014.webm](https://github.com/enso-org/enso/assets/292128/226a17b8-729a-415a-803f-003a9695b2f1)
