18b2491a41
* Always log verbose to a file The change adds an option by default to always log to a file with verbose log level. The implementation is a bit tricky because in the most common use-case we have to always log in verbose mode to a socket and only later apply the desired log levels. Previously socket appender would respect the desired log level already before forwarding the log. If by default we log to a file, verbose mode is simply ignored and does not override user settings. To test run `project-manager` with `ENSO_LOGSERVER_APPENDER=console` env variable. That will output to the console with the default `INFO` level and `TRACE` log level for the file. * add docs * changelog * Address some PR requests 1. Log INFO level to CONSOLE by default 2. Change runner's default log level from ERROR to WARN Took a while to figure out why the correct log level wasn't being passed to the language server, therefore ignoring the (desired) verbose logs from the log file. * linter * 3rd party uses log4j for logging Getting rid of the warning by adding a log4j over slf4j bridge: ``` ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console... ``` * legal review update * Make sure tests use test resources Having `application.conf` in `src/main/resources` and `test/resources` does not guarantee that in Tests we will pick up the latter. Instead, by default it seems to do some kind of merge of different configurations, which is far from desired. * Ensure native launcher test log to console only Logging to console and (temporary) files is problematic for Windows. The CI also revealed a problem with the native configuration because it was not possible to modify the launcher via env variables as everything was initialized during build time. * Adapt to method changes * Potentially deal with Windows failures |
||
|---|---|---|
| .. | ||
| src | ||
| README.md | ||
Enso Runtime
The Enso runtime is responsible for the actual execution of Enso code. This means that it encompasses the following functionality:
- Parsing: Taking Enso code as input and generating an AST that maintains a sophisticated set of information about the input.
- Desugaring: Reducing the user-facing Enso code into a simplified language
known as
Core. - Type Inference: Inferring the types of bindings in the user's code.
- Type Checking: Checking that the inferred and provided types for bindings match up across the codebase.
- Optimisation: Static optimisation processes to improve the performance of the user's program.
- Code Execution: Actually running the Enso code.
- Introspection Hooks: Providing hooks into the running code to allow the language server to inspect information about the code as it runs.
Truffle Nodes creation convention
All Truffle nodes that are expected to be created as part of ASTs should
implement a public, static build method for creating an instance. If the node
is DSL generated, the build method should delegate to the autogenerated
create method, so that nodes are always created with build. Such a
convention allows us to easily switch node back and forth between manual and DSL
generated implementations, without the need to change its clients.
The only exception are nodes that are never expected to be a part of an AST –
e.g. root nodes of builtin functions, for which an asFunction method should be
implemented instead.
This convention should be implemented for every node throughout this codebase – if you see one not obeying it – please fix it.