While working on #11482 and enhancing the tests suite with more tests based on `type Complex` a [getRootNode() did not terminate in 100000 iterations](https://github.com/enso-org/enso/pull/11525#issuecomment-2476171597) problem was discovered. Detailed investigation revealed that the existing `ReadArgumentCheckNode` infrastructure was able to create a **cycle** of parent pointers in the Truffle AST.
The problem was in intricate manipulation of the AST while rewriting internals in `ReadArgumentCheckNode`. This PR avoids such manipulation by _refactoring the type checking code_. `ReadArgumentNode` knows nothing about types anymore. When a type check is needed, `IrToTruffle` adds additional `TypeCheckValueNode.wrap` around the `ReadArgumentNode` - that breaks the **vicious circle**.
All the _type checks_ nodes are moved to its own package. All but one of the classes are made package private. The external API for doing _type checking_ is concentrated into `TypeCheckValueNode`.
Fixes `--jvm` option, given to the native image. This was failing on my machine, because when given `--jvm` option, the runner was trying to find the `java` executable from the distribution manager's runtime (on my system located in `~/.local/share/enso/runtime`) and it used the first runtime found. But the first runtime on my system is JDK 17.
The `--jvm` option now tries to:
- Find a JDK from the distribution manager that has the same version as the JDK used for building the engine.
- If there is not an exact version match, it tries to find a runtime from distribution manager that is *newer*.
- If none, fallback to system-wide search
- System-wide search tries to find `java` from `$JAVA_HOME` and from `$PATH`. But this is just a fallback.
# Important Notes
- Added test to Engine CI jobs that pass `--jvm` argument to a native image of engine-runner
- ea3af5ffbc
- `runtime-version-manager` sbt project migrated to a JPMS module
- `engine-runner` now depends on `runtime-version-manager`.
- Removed unnecessary stuff in `runtime-version-manager` dealing with outdated `gu` Graal Updater utility.
- Extracted [GraalVersionManager](1455b025cb/lib/scala/runtime-version-manager/src/main/java/org/enso/runtimeversionmanager/components/GraalVersionManager.java) from [RuntimeVersionManager](d2e8994700/lib/scala/runtime-version-manager/src/main/scala/org/enso/runtimeversionmanager/components/RuntimeVersionManager.scala)
- Minor fixes from past PR.
- Always use Table viz for Table.
- Fix display to `Always` for any AWS required parameters.
- Add widget for `Redshift` credentials and alter `Username_And_Password` to require arguments.
- Fix display in `Data` module methods for required parameters.
- Fix `Statistic.bulk_widget`.
- Alter `Google_Analytics` so credentials the first parameter.
- Add support for storing the credential file in Enso cloud in `Google_Analytics`.
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**.
#10783 introduced another definition of a buildnativeimage task. Since that time, our CI is transiently failing on out of memory error. This PR ensures that there can be just a single `buildNativeImage` task running at a time.
# Important Notes
Manually tested by running
```
sbt:enso> all engine-runner/buildNativeImage project-manager/buildNativeImage
```
And looking at spawn subprocesses. On develop, I have two `native-image` processes, on this PR, there is just a single one.
