mirror of https://github.com/enso-org/enso.git synced 2024-11-22 22:10:15 +03:00

History

Hubert Plociniczak 18b2491a41 Always log to console and file (#7825 ) * 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	2023-09-26 11:32:04 +02:00
..
src	Always log to console and file (#7825 )	2023-09-26 11:32:04 +02:00
README.md	Add a markdown style guide (#1022 )	2020-07-21 13:59:40 +01:00

Hubert Plociniczak 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

2023-09-26 11:32:04 +02:00

src

Always log to console and file (#7825 )

2023-09-26 11:32:04 +02:00

README.md

Add a markdown style guide (#1022 )

2020-07-21 13:59:40 +01:00

README.md

Enso Language Server

The Enso Language Server is responsibile for providing a remote-communication protocol for the runtime, exposing many of its features to the users. In addition it provides the backing service for much of the IDE functionality associated with the language. It encompasses the following functionality:

Introspection Services: Giving clients the ability to observe information about their running code including values, types, profiling information, and debugging.
Code Execution: The ability for clients to execute arbitrary Enso code in arbitrary scopes. This can be used in conjunction with the above to provide a REPL with an integrated debugger.
Code Completion: Sophisticated completion functionality that refines suggestions intelligently based on context.
Node Management: Tracking and providing the language server's internal node representation of the Enso program.
Code Analysis: Analysis functionality for Enso code (e.g. find usages, jump-to-definition, and so on).
Refactoring: Refactoring functionality for Enso code (e.g. rename, move, extract, and so on).
Type Interactions: Features for type-driven-development that allow users to interact with the types of their programs.