- When comparing pre-release version, the last part is compared lexicographically. In #11796, I did not consider that `rc` is a suffix that is 'larger' than `nightly` (because `r > n`).
- Now, we set this to a relatively recent nightly build.
- The self-upgrade mechanism will use the latest available build, so once the stable version is released it will be preferred.
- The project-manager should be working again because `2024.5.1-nightly.2024.12.10 > 2024.5.1-nightly.2024.11.29` and also `2024.5.1-rc1 > 2024.5.1-nightly.2024.11.29`.
- Fix bug where `DB_Table` data quality indicators broke deserialization in the table viz.
- Memorization of the untrimmed data quality indicator and move to it being an operation and column function.
- If more than 10,000 rows then use a sample for untrimmed.
- ALIASes for blank functions.
- Fix for Snowflake drill down.
- Bug fix for Long and Double columns with Nothings at end.
- As asked for by @PabloBuchu, related to https://github.com/enso-org/cloud-v2/pull/1580/
- Fixes nightly Extra tests:
- Ensures that the Cloud suite **is actually ran**
- Enables logging of all tests and the Test Report on the nightly to make it possible to inspect what was being run.
Adjust operator parsing to allow chained conversions, like `3.14 : Integer : Text`.
Change the precedence and associativity of the `:` operator, when used as a binary operator in an expression:
- It is now **left-associative**
- It now has **lower** precedence than `->` (previously they were equal)
# Important Notes
One previously-reasonable syntax has **changed interpretation**: `x->x:Type` is no longer a valid way to write a casting function, and would likely result in a type error. There was 1 instance of this syntax in our .enso sources.
If a data quality metric is added to the array sent in the table viz json for a table/column the metric will be added to the columns tooltip without the need for any frontend/ts changes.
This doesn't change anything for the users but here is a screenshot to show the same functionality:
![dqm-enso-driven](https://github.com/user-attachments/assets/7bf83d35-0d63-49ac-8d70-1f86dbedc169)
`ydoc-server` compilation requires generation of `ydoc.cjs` resource that can take time and slow down the libraries development (building the enso distribution). This PR splits Ydoc into a library and the server part to avoid JS resources generation during the compilation of the language server.
Changelog:
- refactor: Ydoc into ~~`ydoc`~~ `ydoc-polyglot` library and `ydoc-server` server parts
- update: language server to depend on the ~~`ydoc`~~ `ydoc-polyglot` library
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`.
![image](https://github.com/user-attachments/assets/f34c4231-9f9f-468b-90e9-bbc7f2374d22)
- 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.
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).
* 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>
- 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.
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**.
close#10757
Changelog:
- add: native-image configuration to the `ydoc-server` project
- add: native-image overrides for loom executors replacing them with platform threads
- update: Helidon `4.1.2`
- fix: issues related to the native-image build