* EnsoObject is an abstract class, not an interface.
- Also, EnsoObject exports hasLanguage and getLanguage interop messages.
- BranchRecord converted to class
* Implement public getters in BranchResult
* Fix compilation of EnsoFile
* Add test that all enso values must have language
* Revert EnsoException - remove
* DataflowError and PanicException implement hasLanguage and getLanguage
* DataflowError is not EnsoObject - change signatures in some builtins
* Add more members to Module.isMemberInvocable.
Keep in sync with doInvoke.
* Revert "DataflowError and PanicException implement hasLanguage and getLanguage"
This reverts commit b30f3961b7.
* Update the test - test only non-primitive and non-exception values
* Fix indexes in CodeLocationsTest
* Add more members to Function.isMemberInvocable
Keep in sync with doInvoke.
* EnsoObject.toDisplayString delegates to toString method
* EnsoObject.toDisplayString is behind TruffleBoundary
* Warning exports InteropLibrary which delegates to value.
With the exception of toDisplayString message.
* WithWarnings needs to explicitly export toDisplayString.
It is not automatically delegated because it is implemented in the super type.
* EnsoObject.toDisplayString just throws AssertionError
* AssertionError is behind TruffleBoundary
* Implement toDisplayString on some truffle objects
* Warning exports WarningsLibrary
* Revert "Warning exports WarningsLibrary"
This reverts commit a06c672db5.
* Add some warnings test
* Warning.isNull is always false
Even if it wraps Nothing
* Add some unnecessary methods to fix the compilation
* EnsoObject.toDisplayString is abstract
* ImportExportScope.toDisplayString is behind TruffleBoundary.
This fixes native-image build of engine-runner.
* Hide some toDisplayString methods behind TruffleBoundary
This fixes native-image build of engine-runner.
Bypassing failing test.
* Render tables in documentation.
Also:
- Separate parser for our flavor of Markdown from the CodeMirror integration;
move the parser into ydoc-shared and use for Markdown line-wrapping.
- Introduce our own version of yCollab extension; initially just the upstream
version translated to Typescript and our code style.
- Refactor CodeEditor.
* CHANGELOG, prettier
* Apply @farmaazon review.
* Fix
* Lint
* Cleanup
* Integration tests for GraphNodeComment
Also a little refactoring in preparation for new implementation.
* Workaround stuck CI
* Revert "Workaround stuck CI"
This reverts commit 74313842ba.
* Fix merge
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Show halo only on hover
* Fix numeric input widget. (#11561)
* Invert node colors, make edited widgets more prominent
---------
Co-authored-by: Paweł Grabarz <frizi09@gmail.com>
Skipping failing test in GUI packaging.
Nothing changes in Microsoft space.
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>
