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**.
`Meta.get_qualified_type_name` correctly returns fully qualified type name when running a single file from a project with `enso --run Proj/src/Main.enso`.
- ✅ Alter default `Any.pretty` so constructor is prefixed with type name (as needed now).
![image](https://github.com/user-attachments/assets/72d5ff2f-b567-47e2-becf-2e4acd4d089d)
- ✅ 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`.
![image](https://github.com/user-attachments/assets/18bc1d88-8ea9-42d0-8a9c-bc873e5d6835)
- `to_text`, `to_display_text` and `pretty` for `Enso_Secret`
![image](https://github.com/user-attachments/assets/d850c109-d1af-4b6f-a450-013c4d137805)
- 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.
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):
![image](https://github.com/user-attachments/assets/13af3df4-49ff-49bb-9b19-601258a8ca02)
I think it should be a helpful tool for debugging.
Debugger shows only fields of the current atom constructor: (internal members shown in gray, "public" members shown in bold purple)
![image](https://github.com/user-attachments/assets/21815296-c8aa-4ea2-ae7b-6feac78a221f)
(Note that `static_method` is not displayed as a member of `My_Type` - not in scope of this PR)
# Important Notes
The *interop* contract for `Atom` is changed as follows:
- Members are all methods and fields of the current constructor.
- All methods are internal members.
- If the constructor is project-private, fields are internal members.
- All the members are both readable, and invocable.
- Fields are field getters, that is, they are just methods.
- Fields are not invocable
- Constructors and static methods are **not** members of an atom. They should be members of the type.
- Note that methods used to be atom members before #9692
- 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
Fixes#10679 by changing the return type of `EqualsXyzNode`s to `EqualsAndInfo`. This class holds the result of the comparation as well as any attached warnings. `EqualsBuiltinNode` then re-attaches the warnings, if there are any.
- Change default to be from 0.
- Alter widgets so always shown.
- Tweaks to the Welcome screen following review with Product Team.
- Use 0 for default seed option in `Index_Sub_Range.Sample`.
- Add ALIASES for aggregate and running.
- Add more imports for `Widgets.enso` to fix extension methods not working.
Before 3.46, the SQLite parser had a limited stack, which could overflow for certain complex queries.
CTE optimizations make some of our queries much smaller, but also a little bit more deeply nested, causing the parser stack to overflow. 3.46 removes this stack limitation.
Closes#10910.
This implements `DB_Column.with`, which uses `WITH ... AS` SQL clauses to remove duplicates in the generated SQL.
After a discussion with @radeusgd, we concluded that we will probably want a more complete CTE implementation, so this one is useful for now to deal with big queries (like `round`).
# Important Notes
Still to do in this PR:
- [x] Rename `with` to `let` (or something similar)
- [x] tests
- [x] documentation
- [x] remove `State` hack by moving query generation into a class and using a `Ref` field for scoping
Results on `round_float`:
| --- | SQL length in characters (unprettified) | SQL length in lines (prettified) |
| --- | --- | --- |
| Without CTEs | 13193 | 851 |
| With CTEs | 3644 | 187 |
Compare the SQL:
[without-ctes.sql.txt](https://github.com/user-attachments/files/16629356/without-ctes.sql.txt)
[with-ctes.sql.txt](https://github.com/user-attachments/files/16629357/with-ctes.sql.txt)
Update, with name shortening:
| --- | SQL length in characters (unprettified) | SQL length in lines (prettified) |
| --- | --- | --- |
| Without CTEs | 13193 | 853 |
| With CTEs | 2427 | 176 |
[without-cte.txt](https://github.com/user-attachments/files/16694328/without-cte.txt)
[with-cte.txt](https://github.com/user-attachments/files/16694327/with-cte.txt)
- Enables the `..` autoscoping style for creating Atoms in expressions.
- Add type checking to methods in columns.
- Auto wrap returns from method in expressions into a column as needed.
- Remove `Time_Period.Day` to remove confusion..
Majority of warnings handling is now done via newly introduced nodes. Moreover, the underlying representation of warnings storage in `WithWarnings` was changed from `Warning[]` to `EnsoHashMap`.
# Important Notes
- Remove `ArrayRope`.
- Close#10622
- Changes `project-manager` and `ensoup` launcher to run the engine/language-server with working directory set to the directory containing currently running project.
- If the working directory is _not_ "the directory containing currently running project", a warning is written to logs. This can happen if the raw `/bin/enso` engine runner is used in a different directory.
- In the Cloud, the `File.new` interprets relative paths as cloud paths relative to the Cloud directory containing the current project. Absolute paths are unaffected.
- Adjusted Filter_Condition removing keep/drop from basic filters.
- Fix Is_In to have selector.
- Fix for Date simple expressions.
- Add get_row to Table and DB_Table.
In a sequence of value-level operators, whitespace does not affect relative precedence. Functional operators still follow the space-precedence rules.
The "functional" operators are: `>> << |> |>> <| <<| : .`, application, and any operator containing `<-` or `->`. All other operators are considered value-level operators.
Asymmetric whitespace can still be used to form *operator sections* of value-level operators, e.g. `+2 * 3` is still equivalent to `x -> (x+2) * 3`.
Precedence of application is unchanged, so `f x+y` is still equivalent to `f (x + y)` and `f x+y * z` is still equivalent to `(f (x + y)) * z`.
Any attempt to use spacing to override value-level operator precedence will be caught by the new enso linter. Mixed spacing (for clarity) in value-operator expressions is allowed, as long as it is consistent with the precedences of the operators.
Closes#10366.
# Important Notes
Precedence warnings:
- The parser emits a warning if the whitespace in an expression is inconsistent with its effective precedence.
- A new enso linter can be run with `./run libraries lint`. It parses all `.enso` files in `distribution/lib` and `test`, and reports any errors or warnings. It can also be run on individual files: `cargo run --release --bin check_syntax -- file1 file2...` (the result may be easier to read than the `./run` output).
- The linter is also run as part of `./run lint`, so it is checked in CI.
Additional language change:
- The exponentiation operator (`^`) now has higher precedence than the multiplication class (`*`, `/`, `%`). This change did not affect any current enso files.
Library changes:
- The libraries have been updated. The new warnings were used to identify all affected code; the changes themselves have not been programmatically verified (in many cases their equivalence relies on the commutativity of string concatenation).
- Part of #9486
- Fixes `Table.union`, `merge` and `distinct` tests
- Replaces `distinct_on` in `Context` that was actually a Postgres specific addition leaking into the base with a more abstract `Context_Extension` mechanism.
- This allows us to implement the Snowflake-specific `DISTINCT` using `QUALIFY`.