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:
`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`.
- 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
Once our libraries and tests are compiled with basic inference of method types, some warnings were reported:
```
X:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Database\0.0.0-dev\src\DB_Column.enso:1003:19: warning: Calling member method `div` on type Number will result in a No_Such_Method error in runtime.
1003 | halfway = scale.div 2
| ^~~~~~~~~~~
X:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Image\0.0.0-dev\src\Matrix.enso:381:21: warning: Invoking a value that has a non-function type (type Image) will result in a Not_Invokable error in runtime.
381 | to_image self = Image (Image.from_vector self.normalize.to_vector self.rows self.channels)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Table\0.0.0-dev\src\Internal\Multi_Value_Key.enso:94:22: warning: Calling static method `new` on (type Illegal_State) will result in a No_Such_Method error in runtime.
94 | Error.throw (Illegal_State.new "Ordered_Multi_Value_Key is not intended for usage in unordered collections.")
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
This PR attempts to fix them.
There was also an expected error in the Examples:
```
X:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Examples\0.0.0-dev\src\Main.enso:139:36: warning: Calling static method `frobnicate` on (type No_Methods) will result in a No_Such_Method error in runtime.
139 | no_such_method = Panic.recover Any No_Methods.frobnicate . catch
| ^~~~~~~~~~~~~~~~~~~~~
```
To avoid getting a warning, I wrapped this in `(_ : Any)` to make the warning go away. The behaviour of the function is unchanged.
- ✅ Alter default `Any.pretty` so constructor is prefixed with type name (as needed now).
- ✅ Tests for `pretty` on `Date`.
- `pretty` for ✅ `Date_Time` and ✅ `Time_Of_Day` improved to not have as much noise.
- `pretty` for ✅ `Period`, ✅ `Date_Range` and ✅ `Range`.
- Added custom `pretty` for ✅ `Vector` and ✅ `Array` as built-in method doesn't call through to overrides.
- Added custom `pretty` for ✅ `Column` and ✅ `Table`.
- Bug fix for `pretty` in `Time_Zone` so calls through to `pretty` of the zone_id to ensure safely escaped.
- Initial `default_widget` for `Date` and `Time_Of_Day`.
- Improve widget for `Date.to_date_time`.
- `to_text`, `to_display_text` and `pretty` for `Enso_Secret`
- private constructor for `Enso_Secret` as can't be correctly built directly.
- Use `_` for the testing methods in `HTTP` to clarify they shouldn't be used in general code.
Move annotations into fields of Function and ConstructorDefinition.
# Important Notes
New syntax: Constructor argument-definition lines
- Each argument in a type-constructor definition may be specified on its own (indented) line.
Relaxed syntax: Unparenthesized arguments to annotations
- A generic annotation now uses the rest of the line as its argument expression; the expression no longer needs to be parenthesized.
Numerous times I wasn't sure when running the IDE if I'm running the bundled engine or a development build. Usually this depends on if I launch the standalone IDE or use a development build of project-manager.
Still it's not always obvious, and making sure that your IDE is running the right engine version is very often the first step when debugging issues with e.g. engine changes not showing up properly.
Thus I thought it may be worth to add this method (currently hidden to users in component browser by marking as `PRIVATE`, one has to type it in manually):
I think it should be a helpful tool for debugging.
- Closes#11227
- Additionally, it should fix#11278 by ensuring that every scheduled message goes to the desired endpoint, by splitting each batch by endpoint.
* Add retries to HTTP Get requests
A quick solution to random network failures for GET HTTP requests.
Should reduce the number of IOExceptions that users see while fetching
data.
* Use homemade retry logic for http requests
* Add retries to whole Data.read
Previously, we added retries only to fetch HTTP_Request. That was
insufficient as intermittent errors might happen while reading body's
stream.
Enhanced our simple server's crash endpoint to allow for different kind
of failures as well as simulate random failures.
* Remove retries from Java
Increased the scope of retries in the previous commit.
* nit
* Address PR comments
* PR comments
* Remove builtin
