Closes: https://github.com/enso-org/cloud-v2/issues/1445
PR is more or less ready for feedback,CR, and QA.
# Read before looking into:
**Known issues:**
- [x] Need to adjust timings for the animations (they're a bit out of sync).
- [x] After the latest rebase, the side panel might expand while clicking on the sidebar toggle.
- [ ] Images no longer display. 🤦
- [x] Need to restore the functionality around spotlighting a component
Demo:
https://github.com/user-attachments/assets/8cec9ec0-4753-482e-8637-f3857b4396a5
- Fix any issues identified by the doc writer.
- Alter all `default_widget` functions: all now take display and all use the type check signature.
- Review widgets on AWS APIs and make sure display is correct.
- Cherry-picked out of #10827
- Add `framer-motion` to dialog to animate between dialog sizes.
- Currently visible when switching between types in the Datalink modal.
- Will also be visible when switching between types in the Schedule modal.
# Important Notes
None
Replaces the Regex based number parser with a new parser which works out the same by working out each part as it sees and example of it.
Close#7398 - performance of reading the large CSV now about 2s (down from 15-20s).
Fixes#11426
Now, visualizations should no longer receive stale data props cached from previous visualizations opened on the same node. We do so by changing the visualization ID (reattaching the visualization).
This does not protect from unhandled exceptions happening inside visualizations, though, so a bigger fix will be provided separately.
https://github.com/user-attachments/assets/821b3c11-818e-403b-812d-b3768399b3a4
* Fix Logger's name in stdlib
Somehow SLF4J is able to recognize correctly the provided Logger's name
and print it to the user. Java's Logger is
not.
In addition, we setup SLF4J's configuration, meaning that log-levels are
correctly respected.
For a simple project:
```
from Standard.Base import all
from Standard.Base.Logging import all
type Foo
main =
IO.println "Hello World!"
Foo.log_message level=..Warning "I should warn you about something..."
Foo.log_message level=..Info "Should be seen? By default we only show up-to warnings level"
Foo.log_message level=..Severe "Something went really bad!"
```
This change demonstrates the fix.
Before:
```
> enso --run simple-logging.enso
Hello World!
Nov 08, 2024 6:08:07 PM com.oracle.truffle.host.HostMethodDesc$SingleMethod$MHBase invokeHandle
WARNING: I should warn you about something...
Nov 08, 2024 6:08:07 PM com.oracle.truffle.host.HostMethodDesc$SingleMethod$MHBase invokeHandle
INFO: Should be seen? By default we only show up-to warnings level
Nov 08, 2024 6:08:07 PM com.oracle.truffle.host.HostMethodDesc$SingleMethod$MHBase invokeHandle
SEVERE: Something went really bad!
Foo
```
After:
```
> enso --run simple-logging.enso
Hello World!
[WARN] [2024-11-08T18:03:37+01:00] [simple-logging.Foo] I should warn you about something...
[ERROR] [2024-11-08T18:03:37+01:00] [simple-logging.Foo] Something went really bad!
Foo
```
* Update distribution/lib/Standard/Base/0.0.0-dev/src/Logging.enso
Co-authored-by: Radosław Waśko <radoslaw.wasko@enso.org>
* Test stdlib logs by using MemoryAppender
Added `getEvents` member to `MemoryAppender` so that it is possible to
retrieve individual log messages from tests and test their presence.
Required opening up to some modules to retrieve internals of loggers.
* nit
* small tweaks to eliminate module warnings
---------
Co-authored-by: Radosław Waśko <radoslaw.wasko@enso.org>
Reduce the size of the runtime Docker image from `3.04GB` to `1.41GB`.
```
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
runtime latest ab76231c78c5 9 minutes ago 1.41GB
<none> <none> c8f70807b04f 4 hours ago 3.04GB
```
The image was bloated because of `RUN chmod` and `RUN chown` commands. When the `RUN` command modifies the file, it copies it to a new layer, resulting in a final image with multiple layers containing the same files.
# Important Notes
Note that copying directories with `COPY --chmod=5xx` sets the executable flag to both files and directories. While it is suboptimal (we only need the executable attribute for directories), having executable files in `/opt/enso` should not be an issue. Permissions can be narrowed further when the new Dockerfile `COPY` syntax is stabilized.
- Part of #11311
- Adds ability to read a list of files (Vector, Column, Table) into a Vector.
- Reading into a Table of objects or merged will come in a next PR.
`MetadataStorage` is mutable. Using `Object.equals` in `IR.copy` methods to check whether a _copy is needed_ isn't enough. The fact that two storages are `Object.equal` may be just temporary. Replacing the checks in 69 `IR.copy` methods with identity check - e.g. `ne` in Scala which is `==` in Java.
Using proper structural check inside of `MetadataStorage` fixes#11171.
# Important Notes
I [used this regex](https://github.com/enso-org/enso/issues/11171#issuecomment-2463908932) to find out 69 instances of `IR.copy`:
and I modified all 69 of them.
1. The electron test hit timeouts from time to time, probably because of slow response from the engine: increased timeout.
2. Unify vite version across packages.
* Fix logging in CLI
Previously, unless `--logger-connect` was used, CLI would always
fallback to console logging. In addition it would be misconfigured if
`application.conf` was provided with logging configuration.
This change makes sure that CLI uses the same logging infrastructure as
the rest of the system.
As a result, CLI will now by default not only log to the console and
respect the provided configuration but also log to the file system.
* Update docs
* c&p error
* More examples
Implements #11240.
https://github.com/user-attachments/assets/4d2f8021-3e0f-4d39-95df-bcd72bf7545b
# Important Notes
- Fix a Yjs document corruption bug caused by `DeepReadonly` being replaced by a stub; introduce a `DeepReadonly` implementation without Vue dependency.
- Fix right panel sizing when code editor is open.
- Fix right panel slide-in animation.
- `Ast.Function` renamed to `Ast.FunctionDef`.
The ultimate goal is to reduce the method calls necessary for `Vector.map`.
# Important Notes
- I managed to reduce the number of Java stack frames needed for each `Vector.map` call from **150** to **22** (See https://github.com/enso-org/enso/pull/11363#issuecomment-2432996902)
- Introduced `Stack_Size_Spec` regression test that will ensure that Java stack frames needed for `Vector.map` method call does not exceed **40**.
