close#8248
Changelog:
- add: `profiling/start` request starts the sampler and starts collecting runtime events to the log file
- add: `profiling/stop` request stop the sampler and write the profiling data to the `$ENSO_DATA_DIR/profiling` directory
- refactor: rewrite the profiling logic into Java
Fixes a random crash (*) during instrumentation. Notice how `onTailCallReturn` calls `onReturnValue` with `null` frame.
Bonus: noticed that for some reason we weren't getting logs for `ExecutionService`. This turned out to be the problem with the logger name which by default was `[enso]` not
`[enso.org.enso.interpreter.service.ExecutionService`] and there is some logic there that normalizes the name and assumed a dot after `enso`. This change fixes the logic.
(*)
```
[enso.org.enso.interpreter.service.ExecutionService] Execution of function main failed (Cannot invoke "com.oracle.truffle.api.frame.VirtualFrame.materialize()" because "frame" is null).
java.lang.NullPointerException: Cannot invoke "com.oracle.truffle.api.frame.VirtualFrame.materialize()" because "frame" is null
at org.enso.interpreter.instrument.IdExecutionInstrument$IdEventNodeFactory$IdExecutionEventNode.onReturnValue(IdExecutionInstrument.java:246)
at org.enso.interpreter.instrument.IdExecutionInstrument$IdEventNodeFactory$IdExecutionEventNode.onTailCallReturn(IdExecutionInstrument.java:274)
at org.enso.interpreter.instrument.IdExecutionInstrument$IdEventNodeFactory$IdExecutionEventNode.onReturnExceptional(IdExecutionInstrument.java:258)
at org.graalvm.truffle/com.oracle.truffle.api.instrumentation.ProbeNode$EventProviderChainNode.innerOnReturnExceptional(ProbeNode.java:1395)
at org.graalvm.truffle/com.oracle.truffle.api.instrumentation.ProbeNode$EventChainNode.onReturnExceptional(ProbeNode.java:1031)
at org.graalvm.truffle/com.oracle.truffle.api.instrumentation.ProbeNode.onReturnExceptionalOrUnwind(ProbeNode.java:296)
at org.enso.interpreter.node.ExpressionNodeWrapper.executeGeneric(ExpressionNodeWrapper.java:119)
at org.enso.interpreter.node.ClosureRootNode.execute(ClosureRootNode.java:85)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.executeRootNode(OptimizedCallTarget.java:718)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.profiledPERoot(OptimizedCallTarget.java:641)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callBoundary(OptimizedCallTarget.java:574)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.doInvoke(OptimizedCallTarget.java:558)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callDirect(OptimizedCallTarget.java:504)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedDirectCallNode.call(OptimizedDirectCallNode.java:69)
at org.enso.interpreter.node.callable.thunk.ThunkExecutorNode.doCached(ThunkExecutorNode.java:69)
at org.enso.interpreter.node.callable.thunk.ThunkExecutorNodeGen.executeAndSpecialize(ThunkExecutorNodeGen.java:207)
at org.enso.interpreter.node.callable.thunk.ThunkExecutorNodeGen.executeThunk(ThunkExecutorNodeGen.java:167)
...
```
# Important Notes
Fixes regressions introduced in #8148 and #8162
- Add Google Analytics
- Add cross-domain linking between website homepage and cloud dashboard
- Highlight buttons on authentication flows on hover
- Save logged in state as `logged_in` cookie
- Remove saved access token from disk when signing out
- Support `redirect_to` parameter on `/register` page
# Important Notes
None
This change fixes a regression introduced in #7918, which prevented the execution from setting the right log level either via env var or parameter.
Now passing either of the options returns logs of the expected level in the log file:
- `ENSO_LOG_TO_FILE_LOG_LEVEL = trace`
- ... `-vv` ...
Fixes#8274
Fixes: #8230
Fixes some rare cases caught by property tests, involving nodes with 0 width. `MultiRange` does not handle those. The thing is fixed by not using MultiRange, but by sorting nodes by the axis along which we're searching for free place.
All three reported seeds seem to be fixed.
# Important Notes
`MultiRange` is not used now, but I decided to spare it, violating YAGNI rule, as it is tested, and I feel it's a structure which may be useful.
Closes#8182
Also, improved handling of multiple files – they are placed with a small vertical gap now.
The design for uploading files is non-existent, so I implemented something simple and good-looking. We can easily adjust it at any time.
You can’t move or otherwise interact with nodes while they are uploading.
https://github.com/enso-org/enso/assets/6566674/c0709d8f-3b95-4913-a6eb-caae225b6598
- Closes https://github.com/enso-org/cloud-v2/issues/742
Other fixes:
- Fixes another bug I found while testing, with an obscure trigger condition: specifically, dragging a file when the app is initializing
- Removes CSS property transition on hover - I could swear it was working at some point, but seems to no longer work
# Important Notes
None
Adds a `404.html` to allow client-side routing to work when using static hosting.
# Important Notes
- The routing uses the existing logic to infer the base path. This means that if the user accesses an invalid path, the invalid path will be used as the base path.
Previously custom log levels applied only to non-Truffle loggers. To allow it, filtering has to be applied appropriately at two places - first at Java's Handler and then essentially re-confirmed at SLF4J's logger to which the former forwards to.
Filters compose in an `AND` condition, therefore default log level check had to be merged into our custom filters.
`TruffleLogger` has a builtin functionality to perform the filtering when context is configured appropriately. This should be much more efficient than adding a `Filter` to the JUL Handler explicitly.
# Important Notes
```
JAVA_OPTS="-org.enso.compiler.SerializationManager.Logger.level=debug" ./built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/bin/enso --run
```
will now assign a custom log level to `SerializationManager` Logger.
@radeusgd pointed out that tests are checking that the engine does not send updates when the dataflow error changes. In the end, it turned out that those tests were not checking what they said, and the engine sent the proper updates.
Implements #8064 /
@kazcw Could you double-check that this plays well with your edge dragging implementation. Some of the code seemed a work in progress, and I want to avoid any issues with what you had planned there.
- Changes all authentication screens to look similar to the rest of the dashboard
- Greatly simplifies HTML structure
# Important Notes
- This is being added before the official design is ready, *but* it should be useful anyway, because it greatly simplifies the HTML, which should make it easier to implement the new design
- The auth screens have a larger border-radius than all other elements in the app. This is intentional, to make them look like they continue naturally from the fully rounded submit buttons.
- Basic testing done:
- Logging in should still work
- Signing up should still work
- Setting username should still work
- Changing password should still work
- Forgot password should still work
- Password reset should still work
Add `line:column` information to source code references produced by the parser. This information will be used by GUI2 as part of the solution to #8134.
# Important Notes
- `parse_all_enso_files.sh` has been used to ensure this doesn't affect tree structures.
- `parse_all_enso_files.sh` now checks emitted locations for consistency, and has been used to verify that all line:col references match the values found by an independent scan of the source up to the given UTF8 position.
- Closes#5303
- Refactors `JoinStrategy` allowing us to 'stack' join strategies on top of each other (to some extent) - currently a `HashJoin` can be followed by another join strategy (currently `SortJoin`)
- Adds benchmarks for join
- Due to limitations of the sorting approach this will still not be as fast as possible for cases where there is more than 1 `Between` condition in a single query - trying to demonstrate that in benchmarks.
- We can replace sorting by d-dimensional [RangeTrees](https://en.wikipedia.org/wiki/Range_tree) to get `O((n + m) log^d n + k)` performance (where `n` and `m` are sizes of joined tables, `d` is the amount of `Between` conditions used in the query and `k` is the result set size).
- Follow up ticket for consideration later:
#8216
- Closes#8215
- After all, it turned out that `TreeSet` was problematic (because of not enough flexibility with duplicate key handling), so the simplest solution was to immediately implement this sub-task.
- Closes#8204
- Unrelated, but I ran into this here: adds type checks to other arguments of `set`.
- Before, putting in a Column as `new_name` (i.e. mistakenly messing up the order of arguments), lead to a hard to understand `Method `if_then_else` of type Column could not be found.`, instead now it would file with type error 'expected Text got Column`.
A long running initialization of the component blocks the execution significantly. Removed the `BlockingInitialization` and replaced it with a more fine grained locking.
# Important Notes
Added a simple workaround for potential slow initialization of backend - more retries. We should have a better UX in that case anyway, but due to absence of work on that in old GUI, this will have to do.
The main should be problem should be addressed already by other backend changes. Changes in `app` should only be treated as _just in case something bad happens_.
* OpenFileCmd sends a reply when finished
Lack of reply and therefore a non-determinism on when OpenFile handler
can finish, led to some sporadic instability. Once caches format got
changed, things were taking such a long time that I wasn't able to start
even a basic project (requests would start to timeout).
The change also removes PushContextCmd from synchronous cmds (as
introduced in #798 to remove initialization problems in tests as well as
in real scenarions); the change did the job but was also a bit
controversial.
The change can also help with randomly failing applies (#8174) as IDE kept
closing and opening the project that might have exploited the
race-condition.
* Adapt tests
* Make tests more resilient to out of order messages
* Drop retries that lead to confusing errors
* less random failures
* s/OpenFileNotification/OpenFileRequest
Part of #7926
I found myself wanting to use graph store in the `Input` class. As I learned about composables recently, I decided to refactor the class into a composable, to be more vue-like. Putting it in a separate PR because [other task may wanting to do the same](8066)
Also contains some preparations for my actual implementation.
Fixes#8070
When dragging a node, it is snapped to any axis being an extension to another node's boundary. This helps user keeping their nodes neatly aligned.
https://github.com/enso-org/enso/assets/3919101/36dd4d5f-55d3-4f3c-ba49-e8425fae8270
# Important Notes
* Now the position is saved to Yjs doc only when drag is finished.
* Node structure in graph store has two position fields: one representing what is currently stored in the node's metadata, and where the node is displayed. `nodeRects` use the visible rectangles.
- Sets the default limit for `Table.read` in Database to be max 1000 rows.
- The limit for in-memory compatible API still defaults to `Nothing`.
- Adds a warning if there are more rows than limit.
- Enables a few unrelated asserts.
This makes it clearer which files contain React components, and which do not.
# Important Notes
The main things that should be tested to confirm that this did not break anything is the two files containing Tailwind classes:
- Shortcuts ("delete" in context menu should still be red. `text-delete` is used elsewhere though, so this should not be broken either way)
- Indentation of directory contents (multiple levels)
Many of the others should more or less be self-testing:
- `index.tsx` -> `index.ts` would break the entire app if not handled properly
- `hooks.tsx` contains `useNavigate` which would break routing if absent, and `useToastAndLog` which would break most toast notifications.
- `http.tsx` contains the HTTP client which would break all backend requests
- `useRefresh.tsx` would... break login and logout if it was broken I guess
- Closes https://github.com/enso-org/cloud-v2/issues/720
- Integrate Sentry with React and React Router.
# Important Notes
This is currently BROKEN as it requires the Sentry DSN, otherwise no requests are part of a transaction. Not sure how feasible this is unfortunately, especially as (I'm assuming) it will be different for each backend...
... I guess worst case it can be configured via an environment variable like some other build-time defines.
Also the sampling rates should be checked.
The first part of #8158. No progress indication for the user implemented.
https://github.com/enso-org/enso/assets/6566674/2d8157d4-748f-4442-a9c3-a96ba0029056
# Important Notes
A few notable changes:
- A fix for `DataServer/writeBytes`
- Using `@noble/hashes` instead of `sha3` because the latter only works with node. I also tried using `js-sha3`, but it does not work well with Vite (see https://github.com/emn178/js-sha3/issues/36)
- Fixed initialization of the ID map for new nodes. Also, all new nodes are prepended by four spaces to have proper indentation inside the `main` function.
- Fixed random pattern name generation because the previous approach sometimes produces identifiers starting with a number.
* doc
* one test
* date tests
* empty and nothing
* ints floats
* bools
* all columns
* regex and index
* locales
* bad formats
* all with one format
* docs
* examples, not impl db
* docs, more errors
* cleanup
* changelog
* check list
* reorder
* clue
* review
* review
* review
* review
* review
* review
* specify time zone
Debugging the issue reported by @PabloBuchu when the language server initialization hangs in the cloud. I'm still not sure what is happening in the cloud because I was not able to reproduce it when trying to connect two clients simultaneously.
Another potential source of the issue may be the Scala Future -> Java CompletableFuture conversion, but I didn't find anything suspicious there.
