enso-org/enso
1
1
Fork 0
mirror of https://github.com/enso-org/enso.git synced 2024-12-24 15:51:54 +03:00
Code Issues Projects Releases Wiki Activity
0e9821519d
enso/distribution/engine/THIRD-PARTY/commons-codec.commons-codec-1.16.0/NOTICES

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

6 lines
140 B
Plaintext
Raw Normal View History

Eliminate VCS TimeoutExceptions on startup (#8080) Having a modest-size files in a project would lead to a timeout when the project was first initialized. This became apparent when testing delivered `.enso-project` files with some data files. After some digging there was a bug in JGit (https://bugs.eclipse.org/bugs/show_bug.cgi?id=494323) which meant that adding such files was really slow. The implemented fix is not on by default but even with `--renormalization` turned off I did not see improvement. In the end it didn't make sense to add `data` directory to our version control, or any other files than those in `src` or some meta files in `.enso`. Not including such files eliminates first-use initialization problems. # Important Notes To test, pick an existing Enso project with some data files in it (> 100MB) and remove `.enso/.vcs` directory. Previously it would timeout on first try (and work in successive runs). Now it works even on the first try. The crash: ``` [org.enso.languageserver.requesthandler.vcs.InitVcsHandler] Initialize project request [Number(2)] for [f9a7cd0d-529c-4e1d-a4fa-9dfe2ed79008] failed with: null. java.util.concurrent.TimeoutException: null at org.enso.languageserver.effect.ZioExec$.<clinit>(Exec.scala:134) at org.enso.languageserver.effect.ZioExec.$anonfun$exec$3(Exec.scala:60) at org.enso.languageserver.effect.ZioExec.$anonfun$exec$3$adapted(Exec.scala:60) at zio.ZIO.$anonfun$foldCause$4(ZIO.scala:683) at zio.internal.FiberRuntime.runLoop(FiberRuntime.scala:904) at zio.internal.FiberRuntime.evaluateEffect(FiberRuntime.scala:381) at zio.internal.FiberRuntime.evaluateMessageWhileSuspended(FiberRuntime.scala:504) at zio.internal.FiberRuntime.drainQueueOnCurrentThread(FiberRuntime.scala:220) at zio.internal.FiberRuntime.run(FiberRuntime.scala:139) at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:49) at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1395) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ```
2023-10-18 12:34:08 +03:00
Upgrade directory-watcher library (#8201) The change upgrades `directory-watcher` library, hoping that it will fix the problem reported in #7695 (there has been a number of bug fixes in MacOS listener since then). Once upgraded, tests in `WatcherAdapterSpec` because the logic that attempted to ensure the proper initialization order in the test using semaphore was wrong. Now starting the watcher using `watchAsync` which only returns the future when the watcher successfully registers for paths. Ideally authors of the library would make the registration bit public (https://github.com/gmethvin/directory-watcher/blob/3218d68a845ebd803ebd98af3be4692d1b63e12c/core/src/main/java/io/methvin/watcher/DirectoryWatcher.java#L229C7-L229C20) but it is the best we can do so far. Had to adapt to the new API in PathWatcher as well, ensuring the right order of initialization. Should fix #7695.
2023-11-02 14:24:26 +03:00
Some portions of this file Copyright (c) 2004-2006 Intel Corporation
this work for additional information regarding copyright ownership.
Reference in New Issue Copy Permalink