Add esbuild as peer dependency of esbuild plugin

The plugin imports the Plugin type from the esbuild module, so I think it is better to declare it as a dependency of some sort.
The issue I've seen without adding esbuild as a dependency is that the Plugin import is a moving target since it will resolve to an apparently random version of esbuild depending on the user's setup.
For example, I've started getting some errors in my build when I updated tsup, which uses esbuild internally and which recently upgraded to 0.17.0. The issue ultimately boils down to Vanilla Extract's plugin arbitrarily resolving the Plugin type from version 0.14.0 which was transitively present in the dependency tree and which has an incompatible type wrt 0.17.0.
My hope is that using a peer dependency will at least surface potential incompatibilities errors in a more predictable manner.

As an aside, I've randomly sampled esbuild plugins from https://github.com/esbuild/community-plugins to see what they do, and I don't think I've found one that does the same as the others 😅. Some use "esbuild": "*" as a peer dep, some don't specify anything, some add esbuild as a dependency, some use ^, some use >=, and so on.
I've ultimately opted for a peer dependency, since it feels more natural for a plugin (it's fair to assume the consumer of this will have esbuild as a dependency on their end)

@AndrewLeedham and all other people interested in getting this merged: I created #1171 from latest master and made sure all other packages that have @vanilla-extract/integration in their dependencies aren't affected at all (they now have esbuild as their own dependency)

@MichaelDeBoey thanks for picking this up! I haven't had any time to come back to it. Closing in favor of #1171


Update animation docs to explain when you should dispose animations

Looking at the flutter source code this seems to be done in some places but not others. The animations page makes no mention of dispose.

Usually, yes.  Typically one object will be responsible for an animation controller.  For example, it will start it under various circumstances.  That object should stop the animation controller in dispose.  The spinning_square.dart example should do that but is currently a bad example.

We should also update the animations page with this information.

Best practice is that any object with a dispose method should, in its dispose method, call the dispose method of all the objects it owns that also have dispose methods. In general, always call dispose on an object with such a method if you are done with that object.

FYI @LarkAscending (just in case a new animation page is being considered, not suggesting any higher priority).

This is called out pretty clearly in the docs now: https://github.com/flutter/flutter/blob/84aa29ce639492ad183ac972cf325b0e180c1d26/packages/flutter/lib/src/animation/animation_controller.dart#L108-L113


[Symfony]: Folder ./app is missing permissions

Run commands CreateApp and CloneApp do not have permission to the ./app folder

Fix in
https://github.com/mmaximo33/efde/releases/tag/1.1.1


simplify and coding style

Give it a try and merge if it still works (have not tested it)
Changes:

convert tabs to spaces
deduplicate event handler object

Works very nicely.

@fabianfrz Thats Great. Tipps from a pro are welcome. Thx Fabian. I have to learn a lot but i Love it.....thx
@marjohn56 you also Need some fixes on your Template. Like font-size, padding.... See my Plugin prˋs i have done. I also did a modification for the original theme. See my prs....thx Martin for testing

@fabianfrz  your improvements work without any problems. Do i have to make a new pr for your modification? I will now compare both files to see what i can do better next time.
I really thank you. That's great.
best regards rené

@fabianfrz ok, sorry...now i See. I automatically merged this. Ok

@opnsenseuser the merged file should go into your merge request so it should be visible in the other repository. You should know that a branch is just a tag for a series of commits. You can always commit on it so you don't have to create a new pull request etc. The diff just updates.


Defining personal genomes on a variation graph

Hi,
For some analyses, like Allelic Specific Expression, one wants to have a personal version of the reference. That is the reference modified to represent the known sequence of a individual. It seems this would be trivial with variation graphs if one has a set of variants for which a individual is hom/het. Question: is it possible to align the reads against a subset of the paths of the graph? like define a subset of the graph removing paths for alleles not present on a personal genome (it is hom at the site) and keeping only paths for het sites?
Thanks in advance

@inti I think this should be possible by annotating paths in the graph. These paths can be used to project alignments (vg surject) against the graph against a particular path. This subgraph could be a personal genome. Does this make sense?

Yes, it does make sense. I just have not got chance to try it. I will have a chance soonish. Cheers, Inti

On Jul 13, 2015, at 08:38, Erik Garrison<EMAIL_ADDRESS>wrote:
@inti https://github.com/inti I think this should be possible by annotating paths in the graph. These paths can be used to project alignments (vg surject) against the graph against a particular path. This subgraph could be a personal genome. Does this make sense?
—
Reply to this email directly or view it on GitHub https://github.com/ekg/vg/issues/40#issuecomment-120898605.

I'm going to close this because, while it's a cool project, it's not really a vg bug.

Hey @inti , if you've tried it out let us know - we'd like to hear a success story if you have one, and you can catch us on gitter if for some reason things didn't work!

Thanks. I will try to get around to test it and I will let you know. Cheers, Inti

On Sep 21, 2016, at 05:03, Eric T. Dawson<EMAIL_ADDRESS>wrote:
Hey @inti https://github.com/inti , if you've tried it out let us know - we'd like to hear a success story if you have one, and you can catch us on gitter https://gitter.im/vgteam/vg if for some reason things didn't work!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/vgteam/vg/issues/40#issuecomment-248540103, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXApQmmcH2CbqjXi23Z-MP4uCOdhcgHks5qsOTYgaJpZM4E4bA1.


webpack treeshaking/deadcode elimination additional features?

So currently, webpack imperitively builds a dependency graph, and has library specific syntax for code splitting, lazy loading, and optimizing chunks (sub-tree of modules), based on order, occurence, size, etc.
However one feature that is limiting that we believe we would love to leverage (as a library) a better tree shaking story.
Currently webpack only "marks" unused modules and exports, dependencies, etc. Would it be possible to design a future that would allow some more advanced c-c-js features like --module but instead passing the symbol/name references in the ast of the code that is not used?
--unused-symbols="name:file:line:loc" etc.
This is kind of off the top of my head but I wondered if this is something that could be considered or noteworthy. If anything just get the discussion flowing for a more powerful webpack+cc-js story.
Thanks!

This might be off the mark but I spent most of today trying to understand why the closure compiler can't minify a webpack bundle very well.
It seems to me that it's due to webpack loading modules at runtime, if you could flatten your dependencies when only ES6 imports were used (don't think it would be compatible with CommonJS) then the advanced compilation would be able to remove dead code better.
i.e. instead of this
var installedModules = {};
// ...
function __webpack_require__(moduleId) {
  // This has side effects but with ES6 modules usually we don't care about them
  // but because of this the closure compiler can't get rid of dead code
  modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
}
// Load entry module and return exports
__webpack_require__(__webpack_require__.s = 0);

have something like this
// Generate a bundle with modules already loaded, will lose record of the side
// effects caused by loading them at runtime, but for most cases that's okay
var installedModules = {
  1: {
    exports: { /* ... */ }
  },
  2: {
    exports: { /* ... */ }
  },
}
// Run entry module....

Can you explain the motivation for using webpack together with closure compiler? Closure compiler is a bundler so it should get individual ES6 JS inputs. Minifying a bundle is a bad idea because

closure can drop whole modules if they are not imported
the output bundle is ES5(?) so closure loses the class structure
properly composing the sourcemaps seems hard

I do think it would be interesting if webpack's code splitting for lazy loading could produce a manifest file listing the chunks and their inputs, then closure compiler could produce optimized chunks along the lines of https://github.com/cramforce/splittable

My original thinking was that the compiler was only a code minifier. I wanted the ease of use of webpack with the power of the CC in advanced mode. After getting my sample project working with the CC it was very difficult, documentation is thin and some versions of the CC just don't work, webpack is much easier to use, there's loads of documentation and a larger community to help.
But it came down to my bundle size, with CC it was 6.8 kb but with webpack it was 151kb, CC is the winner here. Webpack only does tree shaking at a surface level, i.e. the exports that aren't imported. CC removes all the dead code.

• closure can drop whole modules if they are not imported
I'm probably not understanding what you mean but I think I'd want this, I don't want modules that aren't loaded in my bundle

• the output bundle is ES5(?) so closure loses the class structure
I'm not sure what impact this has?

• properly composing the sourcemaps seems hard
I guess I could map back to the unminified webpack bundle, that would probably be enough to track down bugs

It makes sense to use webpack still, as the devserver (closure is too slow
for a good edit-refresh cycle) and for code splitting. I'm just pointing
out that the closure compiler integration should take individual ES6
sources rather than the bundle(s) as inputs.

closure dropping modules is important, because some modules might have
side effects on load (eg. class definitions) but you can demonstrate the
module can't be loaded at runtime (no import from there) so it can give
extra size improvements
losing the class structure means less efficient optimization, I'd expect
single digit percentage size increase from ES5
bad sourcemaps are a constant productivity drain, we try fairly hard not
to break these

I am working this week on a much easier build system for invoking closure
compiler, using http://bazel.build and
https://github.com/bazelbuild/rules_closure with TypeScript apps, maybe
that's useful for you? Follow
https://github.com/bazelbuild/rules_typescript/issues/6
On Sun, Sep 24, 2017 at 4:32 PM Alastair Taft<EMAIL_ADDRESS>wrote:

My original thinking was that the compiler was only a code minifier. I
wanted the ease of use of webpack with the power of the CC in advanced
mode. After getting my sample project working with the CC it was very
difficult, documentation is thin and some versions of the CC just don't
work, webpack is much easier to use, there's loads of documentation and a
larger community to help.
But it came down to my bundle size, with CC it was 6.8 kb but with webpack
it was 151kb, CC is the winner here. Webpack only does tree shaking at a
surface level, i.e. the exports that aren't imported. CC removes all the
dead code.
• closure can drop whole modules if they are not imported
I'm probably not understanding what you mean but I think I'd want this, I
don't want modules that aren't loaded in my bundle
• the output bundle is ES5(?) so closure loses the class structure
I'm not sure what impact this has?
• properly composing the sourcemaps seems hard
I guess I could map back to the unminified webpack bundle, that would
probably be enough to track down bugs
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/closure-compiler-js/issues/36#issuecomment-331747742,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5I8dMk1fpzzIr8QmtCQY10kM5JboMks5sluZ5gaJpZM4K11U6
.

Ah thanks, that's some very good points to consider and thanks for those links will have a read through them.

For proper webpack support, use the https://github.com/webpack-contrib/closure-webpack-plugin plugin


Warnings buffer pops up when .envrc is blocked

I often visit files in projects where direnv is not allowed.
I do not necessarily want to unblock .envrc for these projects.
In this case, the *Warnings* buffer keeps popping up with the error message from direnv.
Is there any way to prevent these warnings from appearing?

If (warn ...) were replaced with (display-warning 'direnv ...) then it would be possible to customize  warning-suppress-log-types to hide the warnings.

makes sense, can you cook a pr?

Sure - #61.
Ideally direnv would show its status in the modeline, but I don't know how to do that.


Improve test suite speed

Summary
Using t.Parallel to speed up tests and also creating a faster make target to test locally (running all tests, but using build caches).
Also, pulling some of data creation on tests outside so we can avoid generating a lot of data without reason.
Having faster test suit improves feedback loop and CI times.
The native histogram tests are still taking an awful amount of time, but I did not had time to take a look into extracting data creation.
On main I get:
      329.71 real       411.05 user        37.16 sys

On my branch I get:
       80.68 real       434.55 user        90.90 sys

without racing it is a much better:
real    0m13.486s    user    0m48.597s   sys     0m4.594s

Changes

test speedup
Improving test speed by using parallel testing
Adding target to test without race detector
The export in the makefile had no side-effects

Awesome, this is great! Thanks
$ time go test .
ok  	github.com/thanos-io/promql-engine/engine	30.370s


Failed to execute goals [[package]]. Exit code: 1

When i run
nix run github:fzakaria/mvn2nix#mvn2nix > 'mvn2nix-lock.json'
i do get the error
zsh: no matches found: github:fzakaria/mvn2nix#mvn2nix
So i have to run
nix run 'github:fzakaria/mvn2nix#mvn2nix' > mvn2nix-lock.json
but then i get
Failed to execute goals [[package]]. Exit code: 1
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

system: "x86_64-linux"
host os: Linux 5.10.79, NixOS, 21.11 (Porcupine)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.4
channels(root): "nixos-21.11pre332061.92377ca569e, home-manager"
channels(user): ""
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

You can add -vvv or verbosity flags to see what the error is.
It will depend on the Java project you are trying to execute this on.
I will say that there are missing feature gaps in this current solution that fail to work for complex java projects.

This was some time ago. I cant reproduce this anymore. Yes it was a complex java project with tomcat.

same here, trying to build https://github.com/yacy/yacy_search_server
cd $(mktemp -d)
git clone --depth 1 https://github.com/yacy/yacy_search_server
cd *
nix run github:fzakaria/mvn2nix#mvn2nix -vvvvv

...
trying flake output attribute 'apps.x86_64-linux.mvn2nix'
using cached string attribute 'apps.x86_64-linux.mvn2nix.type'
using cached string attribute 'apps.x86_64-linux.mvn2nix.program'
querying info about missing paths...
starting pool of 24 threads
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: created
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: woken up
querying info about missing paths...
starting pool of 24 threads
entered goal loop
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: init
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: loading derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: have derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: done
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: goal destroyed
Failed to execute goals [[package]]. Exit code: 1

build instructions: yacy is built with ant (not with maven)

Compile from source
The source code is bundled with every YaCy release. You can also get YaCy
from https://github.com/yacy/yacy_search_server by cloning the repository.
git clone https://github.com/yacy/yacy_search_server

Compiling YaCy:

You need Java 1.8 and ant
See ant -p for the available ant targets

Can you provide a gist or dump of the full logs?
Farid Zakaria
On Thu, Nov 17, 2022 at 7:20 AM milahu @.***> wrote:

same here, trying to build https://github.com/yacy/yacy_search_server
cd $(mktemp -d)
git clone --depth 1 https://github.com/yacy/yacy_search_servercd *
nix run github:fzakaria/mvn2nix#mvn2nix -vvvvv
...
trying flake output attribute 'apps.x86_64-linux.mvn2nix'
using cached string attribute 'apps.x86_64-linux.mvn2nix.type'
using cached string attribute 'apps.x86_64-linux.mvn2nix.program'
querying info about missing paths...
starting pool of 24 threads
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: created
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: woken up
querying info about missing paths...
starting pool of 24 threads
entered goal loop
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: init
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: loading derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: have derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: done
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: goal destroyed
Failed to execute goals [[package]]. Exit code: 1
build instructions: yacy is built with ant (not with maven)
Compile from source
The source code is bundled with every YaCy release. You can also get YaCy
from https://github.com/yacy/yacy_search_server by cloning the repository.
git clone https://github.com/yacy/yacy_search_server
Compiling YaCy:

You need Java 1.8 and ant
See ant -p for the available ant targets

—
Reply to this email directly, view it on GitHub
https://github.com/fzakaria/mvn2nix/issues/43#issuecomment-1318791715,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAETXDUF4CZGE5DAE4HPSN3WIZEKXANCNFSM5IKA2EEA
.
You are receiving this because you commented.Message ID:
@.***>

git checkout origin/master

git rev-parse HEAD
309adb814e100098c593ccda59fc428c3de0bb37

nix run github:fzakaria/mvn2nix#mvn2nix -vvvvv 2>&1 | tee mvn2nix.log

mvn2nix.log

system: "x86_64-linux"
host os: Linux 5.15.76, NixOS, 22.11 (Raccoon), 22.11.20221104.1e53371
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.11.0
channels(user): ""
channels(root): "nixpkgs-unstable-e9545762b032559c27d8ec9141ed63ceca1aa1ac"
nixpkgs: /nix/store/qx49n5zbgid072vrhv6cjnqc94242y1r-source

I don't think you are capturing STDERR which is where the error logs are
emitted to.
Farid Zakaria
On Fri, Nov 18, 2022 at 4:05 AM milahu @.***> wrote:

git checkout origin/master
git rev-parse HEAD
309adb814e100098c593ccda59fc428c3de0bb37
nix run github:fzakaria/mvn2nix#mvn2nix -vvvvv 2>&1 | tee mvn2nix.log
mvn2nix.log
https://github.com/fzakaria/mvn2nix/files/10041038/mvn2nix.log

system: "x86_64-linux"
host os: Linux 5.15.76, NixOS, 22.11 (Raccoon),
22.11.20221104.1e53371
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.11.0
channels(user): ""
channels(root):
"nixpkgs-unstable-e9545762b032559c27d8ec9141ed63ceca1aa1ac"
nixpkgs: /nix/store/qx49n5zbgid072vrhv6cjnqc94242y1r-source

—
Reply to this email directly, view it on GitHub
https://github.com/fzakaria/mvn2nix/issues/43#issuecomment-1319911353,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAETXDU5FEY2PQYBF5WGG5TWI5WJJANCNFSM5IKA2EEA
.
You are receiving this because you commented.Message ID:
@.***>

stderr is captured by

2>&1

you cannot reproduce?

I'm getting this when trying to build https://github.com/keycloak/keycloak

Error log from
nix run github:fzakaria/mvn2nix#mvn2nix -vvvvv > mvn2nix-lock.json 2&>error.log

run inside this repository:
acquiring write lock on '/nix/var/nix/temproots/22149'
acquiring write lock on '/nix/var/nix/temproots/22149'
using cache entry '{"name":"source","type":"file","url":"https://api.github.com/repos/fzakaria/mvn2nix/commits/HEAD"}' -> '{"etag":"W/\"42f6c2ae9f67037645d14746653f283dd75005cb37eaf271d1c5c542a781db15\"","url":"https://api.github.com/repos/fzakaria/mvn2nix/commits/HEAD"}', '/nix/store/rkifz3ax1hhiwnj4ifdpjpjm28n7wgvx-source'
using cache entry '{"name":"source","type":"file","url":"https://api.github.com/repos/fzakaria/mvn2nix/commits/HEAD"}' -> '{"etag":"W/\"42f6c2ae9f67037645d14746653f283dd75005cb37eaf271d1c5c542a781db15\"","url":"https://api.github.com/repos/fzakaria/mvn2nix/commits/HEAD"}', '/nix/store/rkifz3ax1hhiwnj4ifdpjpjm28n7wgvx-source'
HEAD revision for 'https://api.github.com/repos/fzakaria/mvn2nix/commits/HEAD' is ea21cfe97069feee55fa307ca9b125616c1fa84f
HEAD revision for 'https://api.github.com/repos/fzakaria/mvn2nix/commits/HEAD' is ea21cfe97069feee55fa307ca9b125616c1fa84f
using cache entry '{"rev":"ea21cfe97069feee55fa307ca9b125616c1fa84f","type":"git-tarball"}' -> '{"lastModified":1629170129,"rev":"ea21cfe97069feee55fa307ca9b125616c1fa84f"}', '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source'
using cache entry '{"rev":"ea21cfe97069feee55fa307ca9b125616c1fa84f","type":"git-tarball"}' -> '{"lastModified":1629170129,"rev":"ea21cfe97069feee55fa307ca9b125616c1fa84f"}', '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source'
got tree '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source' from 'github:fzakaria/mvn2nix/ea21cfe97069feee55fa307ca9b125616c1fa84f'
got tree '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source' from 'github:fzakaria/mvn2nix/ea21cfe97069feee55fa307ca9b125616c1fa84f'
checking access to '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source/flake.nix'
checking access to '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source/flake.nix'
evaluating file '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source/flake.nix'
evaluating file '/nix/store/xikn60z5hl58fapganb6qvlx0krnm0hl-source/flake.nix'
old lock file: {
  "nodes": {
    "nixpkgs": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-s1RTYNKw7ySyqrZjns9Cq+Nnjpp75ePgL06pgcbIpoA=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "21b696caf392ad6fa513caf3327d0aa0430ffb72",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-21.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "nixpkgs": "nixpkgs",
        "utils": "utils"
      }
    },
    "utils": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-A8BU7bjS5GirpAUv4QA+QnJ4CceLHkcXdRp4xITDB0s=",
        "owner": "numtide",
        "repo": "flake-utils",
        "rev": "f7e004a55b120c02ecb6219596820fcd32ca8772",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "flake-utils",
        "type": "github"
      }
    }
  },
  "root": "root",
  "version": 7
}
old lock file: {
  "nodes": {
    "nixpkgs": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-s1RTYNKw7ySyqrZjns9Cq+Nnjpp75ePgL06pgcbIpoA=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "21b696caf392ad6fa513caf3327d0aa0430ffb72",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-21.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "nixpkgs": "nixpkgs",
        "utils": "utils"
      }
    },
    "utils": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-A8BU7bjS5GirpAUv4QA+QnJ4CceLHkcXdRp4xITDB0s=",
        "owner": "numtide",
        "repo": "flake-utils",
        "rev": "f7e004a55b120c02ecb6219596820fcd32ca8772",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "flake-utils",
        "type": "github"
      }
    }
  },
  "root": "root",
  "version": 7
}
computing lock file node ''
computing lock file node ''
computing input 'nixpkgs'
keeping existing input 'nixpkgs'
computing lock file node 'nixpkgs'
computing input 'utils'
keeping existing input 'utils'
computing input 'nixpkgs'
keeping existing input 'nixpkgs'
computing lock file node 'nixpkgs'
computing input 'utils'
keeping existing input 'utils'
computing lock file node 'utils'
computing lock file node 'utils'
new lock file: {
  "nodes": {
    "nixpkgs": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-s1RTYNKw7ySyqrZjns9Cq+Nnjpp75ePgL06pgcbIpoA=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "21b696caf392ad6fa513caf3327d0aa0430ffb72",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-21.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "nixpkgs": "nixpkgs",
        "utils": "utils"
      }
    },
    "utils": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-A8BU7bjS5GirpAUv4QA+QnJ4CceLHkcXdRp4xITDB0s=",
        "owner": "numtide",
        "repo": "flake-utils",
        "rev": "f7e004a55b120c02ecb6219596820fcd32ca8772",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "flake-utils",
        "type": "github"
      }
    }
  },
  "root": "root",
  "version": 7
}
new lock file: {
  "nodes": {
    "nixpkgs": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-s1RTYNKw7ySyqrZjns9Cq+Nnjpp75ePgL06pgcbIpoA=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "21b696caf392ad6fa513caf3327d0aa0430ffb72",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-21.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "nixpkgs": "nixpkgs",
        "utils": "utils"
      }
    },
    "utils": {
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-A8BU7bjS5GirpAUv4QA+QnJ4CceLHkcXdRp4xITDB0s=",
        "owner": "numtide",
        "repo": "flake-utils",
        "rev": "f7e004a55b120c02ecb6219596820fcd32ca8772",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "flake-utils",
        "type": "github"
      }
    }
  },
  "root": "root",
  "version": 7
}
trying flake output attribute 'apps.x86_64-linux.mvn2nix'
trying flake output attribute 'apps.x86_64-linux.mvn2nix'
using cached string attribute 'apps.x86_64-linux.mvn2nix.type'
using cached string attribute 'apps.x86_64-linux.mvn2nix.type'
using cached string attribute 'apps.x86_64-linux.mvn2nix.program'
using cached string attribute 'apps.x86_64-linux.mvn2nix.program'
querying info about missing paths...
starting pool of 24 threads
querying info about missing paths...
starting pool of 24 threads
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: created
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: woken up
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: created
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: woken up
querying info about missing paths...
starting pool of 24 threads
querying info about missing paths...
starting pool of 24 threads
entered goal loop
entered goal loop
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: init
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: init
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: loading derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: loading derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: have derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: have derivation
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: done
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: goal destroyed
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: done
building of '/nix/store/6x3sayxvzx1b3n49wcsxmsn58ybl8hva-mvn2nix-0.1.drv!out' from .drv file: goal destroyed
Failed to execute goals [[package]]. Exit code: 1
Failed to execute goals [[package]]. Exit code: 1

a trivial reason for this error is a missing pom.xml file

[ERROR] The goal you specified requires a project to execute but there is no POM in this directory


Add drop down to gpg for cases where signing and verifying happen

Here's the backdrop... Helm uses golang.org/x/crypto/openpgp which is an incomplete implementation of pgp (according to its authors). It's state even caused a serious discussion on deprecating it that did not occur. There appears to be some issues with subkeys (#7340) and it supports PGP but not necessarily GngPG/GPG. GnuPG switched keyring formats to .kbx files that this package does not know how to read. This leads to errors like the one in #7226.
The current work around is to use a plugin. Specifically, https://github.com/technosophos/helm-gpg which drops down to use openssl and gpg.
I've also had people ask about signing and verifying with x.509 certificates.
Git, for signing commits, works with gpg, allows you to set the gpg program, and can even work with X.509 certs for signing. You can see the config settings at https://git-scm.com/docs/git-config#Documentation/git-config.txt-gpgprogram.
I propose the Helm client works directly with gpg instead of needing a plugin. Git can work directly with gpg via one of these methods:

We add a --gpg flag to the --sign and --verify commands that causes it to drop down to gpg and use that for signing and verification. Similar to what the plugin does.
Add a configuration option to Helm in a similar manner to git. This could enable X.509 signing and verification. Note, this would require adding Helm configuration options.

My hope here is to be pragmatic and provide a useful solution for folks. The current state of signing and verifying does not have a great UX.

Note, dropping down to gpg would mean the support of hardware keys (e.g., Yubikey) when signing.

I believe @technosophos and I discussed doing this for CNAB long ago when we were discussing options for signing bundles with hardware keys. Dropping down to gpg seems like the best possible option given the stark differences between GnuPG and Go's openpgp library, and it shouldn't be too difficult to implement (famous last words).
One other option we discussed was to push forward with the OCI spec, which has native signing support for objects via notary. If we were to get it in a stable place, we would get signing for free. That way we were not investing in two "competing" interests. That being said, I can see why this would be useful for users running chart repositories today, especially with Go's openpgp implementation lacking support for many of the use cases people have today.

I'm not understanding what you mean by "dropping down to gpg". Can you pleas explain?

By "dropping down" to gpg, we mean to shell out to gpg directly when we need to perform signing/validation. Right now, all of the signing logic is performed by golang.org/x/crypto/openpgp.
https://github.com/helm/helm/blob/master/pkg/provenance/sign.go

Excellent! My two cents are that I think it sounds like a good short-term solution to use shell and run GPG, and move to OCI with Notary in the future. Would make a lot of sense to have the same work-flow for charts as for Docker images.

@lindhe There is one quirk...

move to OCI with Notary in the future

When you move an image between different OCI registries the hash can (and often will) change. Even if the image is the same. The signature though Notary is for an image in a particular registry.
The Helm provenance system is for a chart that can be passed around. If that same chart is in multiple registries or even moved via other methods it can be verified. Notary cannot handle this case in its current form.

My limited experience with the Helm provenance system is that exceedingly few charts are signed. So perhaps it's not too big of a deal to change paradigm.

We did some diligence on whether we could directly use Notary/TUF for Helm charts, and that is actually a possibility for the future. In Helm 4, I would be happy to ditch the OpenPGP-based system and switch wholesale to Notary.
Yes, I just said "Helm 4" :-). I'd rather not wait three years between major upgrades again.
But if anyone has interest in starting to mock that out, I would LOVE to start working on a proposal for a modern verification scheme. (Doesn't have to be Notary. That's just one option that looks enticing.)

@technosophos I would be interested in trying out a POC on this. I am just a little confused about the fact that, if we are using Notary which is used for signing images, how can it be repurposed for signing helm charts ?

Not custom. https://github.com/theupdateframework/notary is for arbitrary collections of data and based on TUF, so there is nothing in it specific for signing images.

Just an FYI that Notary is undergoing a pretty big change (see https://www.docker.com/blog/community-collaboration-on-notary-v2/). Can we drop down to gpg in a manner that is backwards compatible for now and then switch to Notary v2 when that is ready?

@iamktm Even if support for Notaryv1 is merged it would mostly be experimental as v1 is not up to the mark compared to what Notaryv2 is going for. https://github.com/helm/helm/pull/7829 has been raised as resurrecting the implementation done by @radu-matei . It would be nice for users to still be able to use this to play around with Notaryv1 to see what the future solution in v2 might resemble.

Any news on this?
Btw, is there any possibility of creating the signatures "externally", without the support of helm?

My limited experience with the Helm provenance system is that exceedingly few charts are signed. So perhaps it's not too big of a deal to change paradigm.

... maybe a reason for that is the limited support of actually creating a signed helm chart?

Okay, I've run out of patience. Until helm natively supports it, here's an alternative small signature script: https://gitlab.com/MatthiasLohr/helm-sign

Out of curiosity, are there any discussions about how chart signatures should work in Helm 4? Or perhaps we're just hoping to use OCI Registry (what's it called again?) and let Notary take care of it...


[BUG] ATEM TV Studio 4K no longer recognised / functioning

Same probs

This is fixed in the 2.2.0-77ba794-2756 beta build


Add Quest Info

Improves the quest reward table to provide more information on weapon variants.
Before:

After:

At least, that's how this PR started. Then I thought it would be cool to cache the task data, add a list of quests to each trader, have an overall tasks page that lists them all, and have task detail pages. All that is basically finished except for the task detail page, which is difficult for me because I'm bad at page layouts.
Here's the main task list:
https://better-quests-table.tarkov-dev.pages.dev/tasks

.deploy to development

.deploy to development

.deploy to development

.deploy to development

Submenu has layout issues:

.deploy to development

.deploy to development

Preview URL: https://better-quests-table.tarkov-dev.pages.dev/

.deploy to development

.deploy to development

.deploy to development

Now the menu is way off to the left on our main items. I say let's revert the menu position back and think about a proper fix later ;)

Can we make this

a link to the map on which the quest is to be done?

Can we make this  a link to the map on which the quest is to be done?

We don't really have individual pages for each map, and the map image pages all have different suffixes (-3d, -2d, etc.). What would we link to?

Can we make this  a link to the map on which the quest is to be done?

We don't really have individual pages for each map, and the map image pages all have different suffixes (-3d, -2d, etc.). What would we link to?

Same logic as with stash bot for the map command

.deploy to development

.deploy to development

.deploy to development

.deploy


Observers cannot open furnace/beacon inventory

Steps to reproduce:

Go on a server with a furnace/beacon
Right click the furnace/beacon

Aren't beacons along with crafting benches unopenable as an observer?

The beacon is a tile entity, the crafting table no

@TiTo-418: Furnace inventories are working for me in the latest version.

Not working in OBSERVERS in 2a4772c701447286848ef0559355d1614ee4974e


Better file Creation/Renaming - WIP

It looks like there's some old stuff in this PR that reverts things to an older version.
It might make sense to start fresh, branching from main, then add the new modal to the clean slate.
Will do local testing later to help identify the bug.
Thanks for this!

I'm going to create a new branch and implement the Modal there. Will try to find that bug along the way and create a new PR when ready. Thanks!


fix(http): do not attempt to autolink if previous character is often found in markup

Initial checklist

[x] I read the support docs
[x] I read the contributing guide
[x] I agree to follow the code of conduct
[x] I searched issues and couldn’t find anything (or linked relevant results below)
[x] If applicable, I’ve added docs and tests

Description of changes

added a check to previousHttp to avoid > and =
made sure that the previous check does not apply to previousEmail

see https://github.com/micromark/micromark-extension-gfm/pull/4
Porting the tests is a bit tricky, as they depend on the interplay with raw HTML parsing, so I'm only adding minimal tests here.

Codecov Report

Merging #8 (451672b) into main (17fb8ca) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main        #8   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            3         3
  Lines          683       686    +3
=========================================
+ Hits           683       686    +3

Impacted Files
Coverage Δ

dev/lib/syntax.js
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 17fb8ca...451672b. Read the comment docs.

The proper way would probably be to check if we are in an HTML a tag, but I'm not sure how to do that.

The goal of this package is to match GitHub, and GitHub does not do this. Instead, GitHub adds links inside links


Add "Always Reference By Directory" field and implication

There's apparently no issue opened for this, but it's a feature which Makin helped discuss a while ago.

Adds an alwaysReferenceByDirectory property to tracks, which removes it from the pool of valid targets for find.track's underlying matchName function. This means it won't count as an ambiguity.
Adds a matching Always Reference By Directory YAML field.
The default for alwaysReferenceByDirectory is usually false, but is true for re-releases whose name matches that of the original.

Merge alongside (i.e. before) hsmusic/hsmusic-data#272. Related to but separate from #274.

This was merged! Just also rebased on the way, I think.


fix(nuxt): don't run nuxt:checkIfLayoutUsed plugin for island

🔗 Linked issue
fix #24528

❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
[x] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
hi :wave: this PR prevent nuxt:checkIfLayoutUsed from being ran in an island context

📝 Checklist

[x] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (main@e3b8b84). Click here to learn what that means.

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #24529   +/-   ##
=======================================
  Coverage        ?   58.65%
=======================================
  Files           ?        5
  Lines           ?      861
  Branches        ?       46
=======================================
  Hits            ?      505
  Misses          ?      356
  Partials        ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


GeoHome Device Details API returned 401

Get an API returned 401

401 means you are not authorised to access the system. Did you e-mail<EMAIL_ADDRESS>to ask them to enable your meter? That's required to get access

thank you, i will ask them


considering replacing gulp

gulp not getting maintainence releases and getting vuln warnings
https://docs.microsoft.com/en-us/aspnet/core/client-side/using-grunt?view=aspnetcore-5.0

could just use msbuild tasks as statiq is doing the rest of the legwork


chore: migrate to nx release [WIP]

Fixes #500

@vmasek a big part of the migration to nx release is done in this PR as well, but it might be easier to start again from main than reconciling with main.


checkpiont can not be loaded and dataset also

the dataset and checkpoint can not be loaded successful

Please elaborate the issue you are facing in more lucid, concise, and comprehensive manner.

For loading checkpoints,
Please take a look at demo notebook :
For dataset, We will need more detail to resolve the issue

maybe it is my network result to fail load the dataset


Fix auth provider link position

Summary
Fixes https://github.com/rancher/dashboard/issues/9252

I'm not sure this is a good fix. The area already has a mix of col / span plus flex. Adding another layout type isn't advised.
The original problem was the span-6 height: 100% applying to multiple elements within the gutless class. it just needed changing to & > .span-6


[Self Request] Magnifier does not show on long press

Once https://github.com/flutter/flutter/pull/107477 lands, we'll have a magnifier in flutter. Currently, the implementation doesn't show the loupe on long press, but it should. I don't think it's going to take too long but I didn't want to bloat that massive PR, so I'm filing this as a separate issue

unassigned :( got too wrapped up in docs.
@justinmc @Renzo-Olivares @LongCatIsLooong


postfix rejected legit email

Hi, i am expecting a legit email from a store. They say they have sent but i didnt get anything. Checking the logs, i see it was rejected by anonaddy:
Aug 21 09:15:15 anonaddy postfix/smtpd[1902]: NOQUEUE: reject: RCPT from mx2-eu2.digital.nuance.com[<IP_ADDRESS>]: 450 4.7.1 <smtp.digital.nuance.com>: Helo command rejected: Host not found<EMAIL_ADDRESS><EMAIL_ADDRESS>proto=ESMTP helo=<smtp.digital.nuance.com>

I wonder if there is any way to allow this kind of messages through, as i missed an important email. (This was delivery instructions for an item i bought)
Seems like postfix, in the container has this:
smtpd_helo_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname

Maybe there could be an option to allow these messages?

You can now override postfix main configuration: https://github.com/anonaddy/docker#override-postfix-main-configuration

Quick question about this: is there a decent case for removing reject_unknown_helo_hostname?
It seems like it's fairly common for this check to fail (the server announcing itself as something which isn't public) for legitimate emails and I've seen a few issue requests about this (I also have this issue with university of maryland email servers).
Furthermore simplelogin doesn't recommend using this option (https://github.com/simple-login/app#postfix).
It would be nice not to have to include the entire main.cf just to remove that one line, is there a good argument for keeping it in?


home incoming call map + connect actions

This applies the new incoming actions to home and additionally adds a new connect action.
We build the engine, register sagas, then tell the engine we're done building sagas. If its connected it'll emit a connect event. This lets us remove another one of these custom callback schemes in engine. i back applied this to some of the actions i already cleaned up

@keybase/react-hackers

@keybase/react-hackers

@keybase/react-hackers bump


[java] Parse KLASS generic type

For example:
public class foo.bar.Foo<T extends baz.qux.Bar>
Where signature should be foo.bar.Foo, but existing (\S+) captures foo.bar.Foo<T

Similarly, where signature should be MyClass<T, V>, only MyClass<T, is captured.
Example can be generated in https://github.com/material-motion/material-motion-family-rebound-android/ by running
apidiff 232399fc08314b0fbf2d31959c5a625f18911a3d cc4382f0c30ff3a808b1cabd4768ce2ce2e648d8 android library


Feature request: implement MDC using Node Aync Hooks

Hi, it would be nice to have a feature like Mapped Diagnostic Context from Java world to support complex back-end application logging. I believe it is now possible in Node.js since there is experimental support for Async Hooks.
If you are not familiar, it is a map bound to current thread holding additional contextual information like current user id that is logged along with every message. Since every HTTP request is always handled by one particular thread, it is very useful.
Have you considered adding something like this? Link below shows how it can be achieved.
https://medium.com/@guysegev/async-hooks-a-whole-new-world-of-opportunities-a1a6daf1990a

I found a good lib, then i will try it.
The zone.js is from angular team to sovle context, it's like thread-local-storage.

A Zone is an execution context that persists across async tasks. You can think of it as thread-local storage for JavaScript VMs.

I think a possible alternative is to implement a mdc from cls-hooked. But I haven't been able to figure out the best way to integrate this and keep winston's client code typical (i.e. abstracting the client from the namespace.run (...) or namespace.bind (...) methods)
I don't know if it would be possible to integrate it as a transport "decorator" or something like that


Feature/tab index

Issue: https://github.com/Capgemini/dcx-react-library/issues/301
In this PR:

[x] Button
[x] CopyToClipboard
[x] Details
[x] FormDate

Still to do:

[ ] FormSelect
[ ] MultiSelect
[ ] Progress
[ ] Range
[ ] Table

Codecov Report
Base: 100.00% // Head: 100.00% // No change to project coverage :thumbsup:

Coverage data is based on head (6cdbcf7) compared to base (efcff42).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@              Coverage Diff              @@
##           release/0.6      #389   +/-   ##
=============================================
  Coverage       100.00%   100.00%
=============================================
  Files               44        44
  Lines             1006      1011    +5
  Branches           392       397    +5
=============================================
+ Hits              1006      1011    +5

Impacted Files
Coverage Δ

src/button/Button.tsx
100.00% <ø> (ø)

src/copyToClipboard/CopyToClipboard.tsx
100.00% <100.00%> (ø)

src/details/Details.tsx
100.00% <100.00%> (ø)

src/formDate/Date.tsx
100.00% <100.00%> (ø)

src/formDate/FormDate.tsx
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Remove legacy moderation system

Part of the cleanup for Wagtail 6.0 - giving this its own PR since it's a pretty big (and standalone-reviewable) thing.
Please check the following:

[x] Do the tests still pass?
[x] Does the code comply with the style guide?

[x] Run make lint from the Wagtail root.

@laymonage Have rebased and hopefully accounted for all of the above.


Extensions using the "type" command (for ex. Vim) have poor performance due to being single-threaded with other extensions

I don't know if this is a known/accepted issue, but I've had a number of users complain of poor performance in the editor when using my extension along with the Vim extension.
This appears to be because the Vim extension uses the type command to handle keypresses (in the extension host). This means if pressing a key triggers a command that blocks in another extension (for example the first character press can trigger code completion, which if the list is 20,000 items can block the thread for a little while while they're build + serialised) the typing in the editor is really sluggish.
You can easily reproduce this by making an extension that blocks for 1s when asked for completions:
context.subscriptions.push(vscode.languages.registerCompletionItemProvider({ scheme: "file" }, {
	provideCompletionItems(document: vscode.TextDocument, position: vscode.Position, token: vscode.CancellationToken, context: vscode.CompletionContext): vscode.ProviderResult<vscode.CompletionItem[] | vscode.CompletionList> {
		console.log('Completion request');
		var start = Date.now();
		let i = 0;
		while (Date.now() < start + 10000) {
			// Block for a second...
			i++;
		}
		return [new vscode.CompletionItem(`aaaItem (${i} iterations)`)];
	},
}));

If you run this and enabled the Vim plugin, when you start typing on a newline (which triggers completion), the characters you type won't appear for a while.
Of course, extensions should try to avoid blocking the extension host as much as possible, but sometimes it's unavoidable (for ex. assembling and serialising a huge number of completion items). It's not clear where users should raise bugs, since in isolation neither extension is really doing anything wrong.
I don't know what the fix is (separate extension host for type-handling extensions might work, but that might also be a huge task), but I couldn't find any issues discussing this and figured it was worth some discussion (even if only to have the information described in one place we can point people to that hit these issue).

Similar issue https://github.com/microsoft/vscode/issues/65876 . @DanTup thanks for the nice write up.

In general, I agree. But running each extension in its own separate thread has implications such as: text buffer memory duplication or a variant of a text buffer written in C++ that can be snapshotted and shared safely across threads, native node modules loaded by extensions in the ext host which are not multi-process aware, or sync API dependencies between extensions. It also means that the renderer process will need to host N extension hosts (sending messages to N different endpoints) with its perf implications... I don't think we will change this architecture too soon...

Of course, extensions should try to avoid blocking the extension host as much as possible, but sometimes it's unavoidable (for ex. assembling and serialising a huge number of completion items). It's not clear where users should raise bugs, since in isolation neither extension is really doing anything wrong.

The extension that eats 1s from the event loop is definitely doing something wrong and should get a bug. IMHO, 1s is a very very long time to be blocking the event loop, even that of the extension host.

IMHO, 1s is a very very long time to be blocking the event loop, even that of the extension host.

That's true, but 1s is way longer than is required to make typing feel sluggish. Even 200ms could feel sluggish, and saying we shouldn't block for 200ms across any machines is an impossible task (I've had logs where things that take only 10-20ms on my machine, many hundreds of ms on some users machines).
Even if extensions only ever blocked for shorter periods - some users have tons of them installed, so they could still easily add up.
I understand it's hard to solve, but a lot of time goes into debugging performance issues (both by users and extension authors). I've personally spent a lot of time digging into this (I got a report that typing was super sluggish, and I was under the impression that keystrokes were always handled in the main VS process - it was a lot of digging to figure out what was actually going on - especially as I couldn't repro it for a long time because I didn't know about Vim and how it worked), and I'm certain I'm not the only one.
If it's going to remain like this, maybe there should at least be a warning in the console the first time a keystroke takes longer than ` few hundred ms because it went via the extension host and was slow. That would've saved a lot of time.

I agree and appreciate your frustration and wasted time on this and I am sorry about it...
I don't have a good answer except to point out that things could be worse... I'm happy extensions are not running with the rest of VS Code on the renderer process... That was one of my contributions to the architecture of VS Code, one which I had to defend quite sternly to more experienced folks coming in with an Eclipse background (where everything is single proc, albeit with multiple threads, but oftentimes stuff ended up on the UI thread...), or looking at Atom or other editors...
The current reality is that extensions today share a single event loop and that everyone needs to play nice (and yield every now and then) for things to work out well. Sharing a single event loop doesn't mean you can't do expensive stuff per-se, it means you shouldn't block for extended periods of time. If you were to yield every 10ms, in the spirit of "cooperative threading", things would work out... In any case, I am not against improving this, by all means I would like to have it better, but please accept that I believe it is difficult and costly to improve now, and it is not at the top of the list priority wise.
We have all kind of automatic warnings when the extension host becomes unresponsive for a certain time, but nothing so small as a few hundred ms... It is also worth keeping in mind that for us, there is no correlation between pressing a keystroke and vim issuing an edit. In other words, typing ends up invoking the type command. By default the type command is implemented by us on the renderer. The vim extension effectively overwrites it and at some later point (async from the point of view of the renderer) issues edits back to the renderer process. We have no idea that those edits have as root cause a certain keypress or that a long time has passed... So it isn't something straight-forward to detect on our side (in the core)... We might detect it if we were to expand the editing API and add some correlation argument that could be passed back to us so we have a chance to correlate the keydown / command invocation with an edit...
I am sorry I don't have better answers, I am open to ideas... For a while I thought that perhaps we should do a special case and have 2 extension hosts, one for vim, and one for everything else...

I'm happy extensions are not running with the rest of VS Code on the renderer process... That was one of my contributions to the architecture of VS Code

FWIW, I'm also happy about this. It does add some limitations (for ex. the "Flutter UI Guides" in IntelliJ are synced perfectly to editing), but I hate a laggy editor - that's why I opened this issue to start a discussion - it feels like a backdoor :-)

please accept that I believe it is difficult and costly to improve now, and it is not at the top of the list priority wise

Ofc, I didn't mean to sound like I thought you had to fix this - but I think it would be a shame to just close it "as designed" without thinking about options (even if they're way down the list).

there is no correlation between pressing a keystroke and vim issuing an edit. In other words, typing ends up invoking the type command. By default the type command is implemented by us on the renderer. The vim extension effectively overwrites it and at some later point (async from the point of view of the renderer) issues edits back to the renderer process

Good point - I thought you could wait until the command finished executing (I presume you know when that happens) - but it didn't occur to me that it could do its own async work and return early :(

For a while I thought that perhaps we should do a special case and have 2 extension hosts, one for vim, and one for everything else

That's what I meant with "separate extension host for type-handling extensions might work" above. Assuming only one extension can take it, it could be an additional host just for the type-handling extension. It would be better if it wasn't Vim-specific ofc (which might mean you'd need something in the manifest to declare that it handles typing - which might not be a bad thing to ensure the user doesn't have two of them).
Since you said "For a while", I presume you no longer think that? It does add complexity, but if supporting these kinds of extensions is important, it doesn't sound completely crazy to me (with my very limited understanding of VS Code :-)). It would solve the "who should fix this?" confusion with current behaviour - Vim should understandably be upset if other extensions hog the thread and make them perform badly, but it's easy for other extensions to argue "well you delegated your key presses to the extension host, you gotta deal with added latency during typing".. If it's not really obvious where the fault lies, it's likely not to be fixed by either.

I am pretty bummed that we have brought the Vim extension to where it is now, and are constantly bombarded with performance issue reports. It is almost "good enough" but this caveat is enough to turn a percentage of users away from the experience and it is a bit demoralizing at times to have no path forward.
Thanks for the explanations in this issue report though, the comments have cleared up a few things for me.

The Rust analyzer extension also uses this command:
https://github.com/rust-analyzer/rust-analyzer/issues/2331
I suspect its use will become more common as extensions want to provide additional functionality that the VS Code API doesn't support. I think this problem is only going to get worse.
Maybe as a start, VS Code should prompt users when an extension registers this (like it does when an extension tries to override PATH in the terminal) so there's least have some visibility that the extension does something that could significantly impact editor performance? For Vim it might be more obvious it's doing something like this, but for something like Rust I think it's far less obvious.

However desirable it may be in theory to run extensions in a separate process, in practice it's resulted in far worse and less likely to get fixed Vim emulation performance than all of the following IDEs:

Eclipse
Visual Studio
Qt Creator
Sublime
WebStorm
Atom
CodeSandbox

I have the same problem. I got lag when typing in VScode. I disabled VimExtension. It works well.
How did you fix it?

@bpasero @jrieken @joaomoreno @mjbvz @isidorn @alexdima @sandy081 @Tyriar @aeschli @roblourens
What will it take for this to get fixed?  Is there something we can do?  Would it be worth my time to try to make a PR either to run VSCodeVim in a separate host, or enable "type" command extensions to run in the main process (the only solution I think will guarantee acceptable performance in the long run)?
It's really disappointing to see new features being added when catastrophic performance issues like this languish.  This is catastrophic for Vim users; I usually even have to disable the builtin TypeScript and JavaScript langauge features extension to get acceptable keyboard responsiveness.  I'm gonna have to jump ship at some point (and stop contributing VSCode extensions to the ecosystem) if this issue never gets fixed.

@jedwards1211 Can you please profile the extension host the next time you notice typing is unresponsive for you? This can be easily done by opening F1 > Developer: Show Running Extensions and then clicking the Start Profile action. Once the profile is stopped, the UI should show next to each activated extension how much time it consumed. This should help to clarify who is the culprit for the high latency that you are experiencing.

@alexdima fixing extensions one at a time, forever, is not a reasonable answer to this problem.

@alexdima Come on, man, we want a change to the architecture that allows VSCodeVim to be as responsive as the rest of the UI even if another extension is pegging the CPU.  Mouse clicks don't get slowed down when this is happening, nor does builtin keyboard input, so we just won't accept any excuses for why VSCodeVim shouldn't be able to be as responsive as builtin keyboard input.

We can look into having another extension host just for vim.
But please try to think also about the following statements:

"Staging in git has poor performance due to being single-threaded with other extensions"
"Editing in a custom image editor has poor performance due to being single-threaded with other extensions"
"Semantic highlighting has poor performance due to being single-threaded with other extensions"
"Intellisense has poor performance due to being single-threaded with other extensions"

I consider the extension host to be an integral and critical part of VS Code. I think the VS Code experience with an unresponsive extension host is horrible and should be used only in emergency cases, like saving dirty files and restarting VS Code.
All of those statements above and possibly hundreds more are equally valid if we don't actively try to identify and improve poor performing extensions. I don't see any harm in my asking to profile and make an issue or a PR to a poor performing extension. It is something you can do, involves little VS Code expertise and can scale independently of VS Code. If you manage to find a real performance problem in a popular extension and get that filed and possibly fixed with a PR, you will have improved things for everyone else that uses that extension, independent of the VS Code core. Independent if those people use vim or not, all of them that are using that extension will have more idle time on their CPUs, meaning more free cores that can then be made available to the renderer process, to the GPU process, or their favourite language server process.
We can look into having a special process dedicated to vim, but, please, realise that is partially a bandaid.
Please, you can help right now by profiling and identifying problems. Doing that is not exclusive with having a special process dedicated to vim.

I think the main problem is the treating vim extensions as "ordinary extensions", however for VIM users these are core editor part, not extension, not even different than built-in keyboard typing. Consider if one day built-in vscode keyboard input would become unresponsive - what would you do? Fix it ASAP, probably even outside of ordinary release schedule.
VIM users are not second class passengers, however this long-term unresolved situation makes me thinks so.

Whilst the sentiment is sensible, of the posited scenarios, only the image editor is analogous to text input, and still less important IMO. As I said, it's desirable for non-interactive extensions to behave, but it's truly a bandaid requiring continual effort to rely on users profiling/patching every poorly performing extension as it's released/updated.
Maybe a separate extension host for type extensions is not the ideal solution, but if solving the problems of the extension host for the general case is (understandably) too hard for the foreseeable future, an interim solution would be greatly appreciated to make the editor experience bearable. Even if other extensions are performing "pretty well", input lag of even minor significance is quite disconcerting.

@alexdima

realise that is partially a bandaid

I'll see if I can profile what's causing problems, but we see fixing poorly performing extensions as a bandaid.  Your examples really demonstrate the need for each extension to run in a separate extension host process.  I mean even the TypeScript extension blocks Vim for about a second when bringing up the suggestions for aws-sdk (I had to disable automatic suggestions).  Is there even a way to fix things that are bound to be expensive like that?  Are extensions able to do everything in a Worker?

To be clear, I'm asking what I can do to help solve this problem permanently.  As @pdf has mentioned, debugging poorly performing extensions is not a permanent solution because new performance issues with extensions can pop up at any time.

And clearly I need to repeat that
Other IDEs don't have problems with slow Vi input

@alexdima It's worth mentioning that @DanTup puts every effort into optimizing his extension to workaround this bug. And users of the dartcode extension come here only when all the efforts were deemed futile. Me and other vim users submitted him profiles many times over and he did everything possible and then some (short of rewriting vscode) to help us.

@alexdima

We can look into having another extension host just for vim

Okay, is the core team going to commit to working on this?  Or accept a PR for it if I'm able to learn the codebase enough to make one?

@alexdima

one which I had to defend quite sternly to more experienced folks coming in with an Eclipse background (where everything is single proc, albeit with multiple threads, but oftentimes stuff ended up on the UI thread...)

Well guess what, Eclipse is the IDE I have been most satisfied with, including with the Vrapper extension, it is lightyears more responsive than VSCodeVim.  In the past five years or so I haven't noticed any issues with UI lag in Eclipse.
I guarantee you the VSCodeVim experience will suck forever unless it's eventually moved into its own process or into the main process (the idea of every keystroke and buffer interaction having to go over IPC should fill anyone with disgust anyway).

I do agree that giving Vim its own host specifically isn't an ideal fix. It would prevent someone else coming along and making a very similar extension that performs the same. I think any fix should affect all extensions equally.
However I also agree that having fixing this in every extension is also not a feasible fix. How does an extension author know how long it's reasonable to block for? What do we do when we have to do a lot of work (for example, completion lists these days can be huge when you add in people wanting completions for unimported symbols and the need to supply fill edits for this up-front because we can't supply these asynchronously). The amount of time is also very dependant on the speed of a users machine and the number of extensions trying to run code at the same time. I've already tried to litter yeilds throughout my completion code, but it didn't really solve the issue (it also makes things overall slower if it's done too much or is unnecessary).
There was a question above about Workers that I'm not sure was answered (https://nodejs.org/docs/latest-v12.x/api/worker_threads.html ?). Is it possible/feasible to have extensions run in their own workers without needing separate processes?

I do agree that giving Vim its own host specifically isn't an ideal fix.

Whilst this is the terminology that's been thrown around I suspect if going this route, rather than doing this explicitly, you'd move any extensions that implement type onto a separate host.

worker_threads API for extensions tracked in #88386.

I was thinking more of VS Code doing this automatically (to eliminate this kind of issue) than have extensions do it (even if only for the type-handling extensions). Assuming it could work, wouldn't that be less effort than spawning additional extension hosts?

there is another old & sad issue about input latency #27378

I just realized, wouldn't it be better for the extension host to automatically report long-running extension tasks than having humans do it every time?

@jrieken @joaomoreno seeing that you have thumbs up on @alexdima's comment, you have to understand that it comes across as pushing back against our requests for real change.  When are we going to have real change in type command performance?

wouldn't it be better for the extension host to automatically report long-running extension tasks than having humans do it every time?

VS Code already detects when an extension blocks the thread for long enough (3s?) and gives a warning. I don't think it could really be done for shorter periods (as would be required to catch those affecting typing) because there's such variance across user machines that it'd be triggered all the time.
Knowing what extension is blocking is only half the problem. I can easily give some examples of my own extension causing this issue for Vim users. The issue is - what do I do? The users want completion lists with thousands of items (symbols that aren't yet imported, that will automatically add the imports) and the time it takes to deserialise the results from the language server, map them into VS Code classes (including building edits for things like the import statements) then having VS Code serialise them to go over to the editor can easily add up (esp on slow/busy machines) to longer than the delay people would want to see keypresses delayed by.
Add that the user may have lots of extensions all running code. It doesn't seem realistic to me to say "all of the users extensions combined must run in a single shared thread but never block combined for more than ".

workerpool greatly works for LaTeX Workshop. Parsing LaTeX files for suggestions, resizing PNG files for hovers, and rendering PDF files to SVG files for hovers are asynchronously executed in a separate process. It is straightforward to use. You can try it.

As popular as Vim is, you'd think this would be considered more important.

https://insights.stackoverflow.com/survey/2018/#technology-most-popular-development-environments

@dantup I'm going to ask the author of VSCodeVim if he's willing to ask all of its users to come upvote this issue...maybe ask users of your extension to upvote this as well?
It's really sad how apathetic the maintainers are about this.

+1

I started having this issue after I added the flutter/dart googleapis package, probably due to the amount of exports it has. Typing stutters for up to second while it tries to autocomplete, it was disrupting enough that I was considering dropping vscode. I set "dart.autoImportCompletions": false and it seems to have resolved it. However, this is not ideal and I'd really like to see this issue get resolved. I think I saw this same issue with typescript in combination with large packages such as the aws sdk.

I can confirm I have the same issue with the AWS SDK and built-in TS/JS extension.

For some reason neovim extension and simplevim doesn't have this problem.

@sdyalor both of those extensions unbind from the type command during insert mode to avoid any delay while typing in text.  However commands outside of insert mode can still get delayed just as much as ever.

@alexdima lately I've seen the builtin TS/JS extensions block Vim for several seconds when I'm in the middle of typing a function and it tries to rebuild the outline (I see an intermittent progress bar in the outline view while it's not taking keyboard input).
@tamuratak @jrieken @rebornix @joaomoreno I know you all want me to open a separate issues for other extensions' performance problems like this but please understand from my perspective that seems like it would perpetuate my suffering.  I think the only hope of seeing a permanent solution where type commands run in a separate thread is to report other extensions' performance problems here.

This problem two years ago is still unresolved. For me, vim is irreplaceable, but vscode is replaceable. If fleet is released, I think I will give up vscode, which is really frustrating.

In our latest Insiders Build, we have added a new experimental setting that would allow to execute the vim extension in a dedicated extension host process.
Configure the following in your settings.json and then reload window or restart:
"extensions.experimental.affinity": {
	"vscodevim.vim": 1
},

You can double check that vim is loaded in a separate process using F1 > Developer: Show Running Extensions:

@alexdima can we expect this to come in the next release? I'm hesitant to move to Insiders from stable (just as a general rule of thumb) but am willing to move over if it'll be "experimental" for a while before officially released.

This feature came too late.
It's available now and it's great.

This setting has a GUI now.

Add a line for vscodevim.vim and restart. Totally worth it. For me, it makes a huge difference!

This setting has a GUI now.

Add a line for vscodevim.vim and restart. Totally worth it. For me, it makes a huge difference!

Thank you so much! This worked for me

This fix is working great for me. Both the vim and neovim extensions were randomly very slow/laggy prior to setting this.

Does affinity work on https://vscode.dev/ as well?

Does affinity work on https://vscode.dev/ as well?

Thanks to https://github.com/microsoft/vscode/pull/164150 , it will also work on vscode.dev with the next stable release.

Thank you. This makes a huge difference 👍

I'm using M1 mac.
Using the arm 64 version instead of amd version improved the speed dramatically.
arm 64 version is here
https://code.visualstudio.com/docs/?dv=osx

I stumbled upon this issue while searching for laggy typing and missed input. After running the profiler I found two extension that had >150ms runtime where other had <1ms: vim and Intellicode.
Using the affinity setting I moved vim out of the way (affinity=1), but the lagginess remained. I also moved intellicode (and the intellicode completion extension) in yet another process (affinity=2 for both of them), and the issue disappeared.
Thanks for that. I'm not sure how desirable it could be to auto-adjust this setting when some extension misbehave, but even as a clutch it works well enough.

I'm having this issue re-appear after seemingly being fixed a few months ago with the affinity setting. It seems to be an interaction of two or more extensions. If I disable either pylance or vscodevim, it seems to work happily. But with both of them installed, as soon as I start typing something (in insert mode), I get crazy lag and skipped and repeated keystrokes (and sometimes it treats inline blame annotations (via Gitlens) as actual text in the editor). While the madness is happening (and indeed, every single time I start typing something, VSCode starts analyzing some number of files). Restarting VSCode doesn't fix the issue.


Support downloads from Huggingface Model Hub

Adds preliminary support to download and run models from the Huggingface Model Hub.

Thanks @zjgarvey! I'll go ahead and merge this. Using json to store metadata sounds neat, we can discuss it and I can open a PR for that too.


Let update_elected_producers() reduce the schedule

Line 125 in https://github.com/EOSIO/eosio.contracts/blob/7c042002b903bbf13c7ae37851f03edf58ae9ff8/contracts/eosio.system/src/voting.cpp
      if( top_producers.size() == 0 || top_producers.size() < _gstate.last_producer_schedule_size ) {
         return;
}

so, if a small network has less than 21 active producers, a producer cannot leave the schedule because the unregprod will be ignored. This is dangerous for network stability because a BP can unregprod and switch off the server, being sure that they did the right thing. The network will not be able to replace the BP or remove it from the schedule, unless they create sock puppets to fill in 22 positions.
I believe this rule should be removed. It's causing a danger for small networks and doesn't make sense for big ones.
It should be modified to disallow reducing the schedule to zero only.

Running a small network, having this issue.

It would be better to make this number configurable and able to be modified by the existing BP vote as it presents a risk of network lockup in certain edge cases.


Support eslint v9 flat config

Oops! Something went wrong! :(
"eslint": "^9.9.0",

Would anyone like to take this?

Nice. I don't know about v8 compatibility, but to be honest, I'm still on v8.

I'll try to keep compat but if it doesn't work we'll just have to maintain 2 versions, cause I'm on v8 in most projects as well

Can anyone help testing #53?

https://github.com/pmndrs/eslint-plugin-valtio/releases/tag/v0.7.0
Up


enable/disable logrocket

At the moment, logrocket is only disabled when you are in dev mode.
It would be nice to able to set your own logic whether or not to enable logrocket.
Use case: I build a deploy preview on my server (that is: production mode), I want to test that specific deploy without logrocket recording it.

Why don't you just clear logRocketId in your nuxt.config.js file for that specific deploy?

Ok, never thought of that, thanks!
FYI: an error is thrown in the console log if logRocketId: '' which makes sense

@miteyema Thanks for the tip.
This should be fixed in v1.2.5
Can you please test and confirm? I'd appreciate it.

Awesome, thanks for the fix!

@farzadso Is there a way to enable/disable for certain users/our own logic, I would need to disable it for certain user types.


Create a 2018 tag instead of branch

Created a release of the 2018 material (including a v2018 tag).


⚠ Bofrost.at has degraded performance

In bdd8893, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1225 ms

Resolved: Bofrost.at performance has improved in 1198bba.


fix insights widget issue

This PR fixes #15818
during recent vscode merge, the protected modifier for the _config parameter was removed due to the newly introduced override keyword. but the actual protected variable _config in base class is not initialized.
fix: assign the value to this._config before consuming it.
I also checked other classes that extends the dashboardWidget class, and they already have the change applied, seems Charles might have missed this class during the merge.

Pull Request Test Coverage Report for Build 951403191

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 42.972%

Totals

Change from base Build 951316318:
-0.002%

Covered Lines:
26329

Relevant Lines:
55635

💛  - Coveralls


Disabled accounts

Similar to https://github.com/benallfree/pockethost/issues/40, let's add a field in the profile or user record where we can disable accounts. This should probably wait until after PB v0.8 release, where user/profile refactoring has happened.

There is some complexity here in terms of updating existing security rules to check for disabled==false. Putting on hold til after 1.0.

moved to roadmap


[Backport] Update third_party/binutils to 2.26, add ICF fix

This is needed to order for the build to work on Ubuntu 16.04 with
Chromium's clang and binutils.
Original commit message:

The new binutils 2.26 release incorporates two out of the three
fixes that we were applying to the 2.25 version.  There is also
an upstream fix, that's not in 2.26, for a bug that made the
linker crash when using --icf for x86-32, which we now apply
locally so it should become safe to use gold with --icf for x86.
BUG=610908
<EMAIL_ADDRESS>Review-Url: https://codereview.chromium.org/1950343004

BUG=XWALK-7062

rs+


[ISSUES-3063][Improve] Improve ImplicitsUtilsTest test code coverage

What changes were proposed in this pull request
Improve ImplicitsUtilsTest test code coverage

Brief change log

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Does this pull request potentially affect one of the following parts

Dependencies (does it add or upgrade a dependency): (yes / no)

cc @zzzk1 @wolfboys


demo: Initial hierarchical clustered simplification (Nanite) demo

This PR adds a new demo file, nanite.cpp, that implements Nanite-style hierarchical simplification.
Working off the SIGGRAPH presentation by Brian Karis, it builds a DAG of clusters; for each cluster,
it tracks the bounds and error that can be used to do LOD selection in parallel / independently at
runtime.
The goal of this code is not to be a production quality pipeline (yet!); it is to serve as a testing
ground for future improvements in meshoptimizer's algorithms as well as development of new
algorithms. In the future this may become a good starting point, but for now the main purpose
is to be a test harness, as such there's a bunch of statistics / visualization support code here (and
more to come in the future at some point).
Also, to have a reasonable baseline, this code integrates with METIS to optionally use it to build
clusters, as well as to partition clusters. Without METIS we can still build clusters using meshopt,
but for partitioning we resolve to just sequentially merge clusters (which is obviously suboptimal).
METIS triangle partitioning is generally better in terms of maintaining contiguous clusters, but
worse in terms of generating a good cluster fill. There might be a way to coerce METIS to generate
better clusters with more tweaks; currently what often happens is that it decides to split a 256-size
partition into 127 and 129 triangles, and then has no choice but to split the 129-triangle partition
into two smaller ones. This may be fixable by repeatedly asking METIS to generate partitions with
different triangle counts but this becomes even more expensive... since METIS is only used here to
set a baseline, this is probably fine.
METIS cluster partitioning has surprising failure cases where it decides that a good partition should
consist of 4 clusters that barely connect; this was unexpected because it doesn't seem to happen during
triangle builds. Maybe with this in mind, a reasonable (unordered) greedy cluster merge could work
better, but this will need to be investigated separately in the future anyway.
The actual simplification currently uses automatic border detection; it would be better to switch to
using external vertex tagging via vertex_lock, but for now models I use for testing that have a lot of
room to improvement are not bottlenecked by this.
The actual DAG build is also very sensitive to all of the details above in ways that seem somewhat
difficult to control. If a group at any point earlier in the pipeline is stuck (eg can't be simplified too
much), it could be because the group has internally bad topology (faceting, UV seams), but could
also be because the group is formed of disjointed clusters, or the clusters themselves are formed
of disjointed triangles. This is bad because a) the group itself is kept at a high resolution, b) removing
this group from future simplification permanently locks the boundary edges for other clusters,
which exacerbates the problem.
To try to get around this, the DAG flow has very lax simplification limits (we keep anything where we
can remove 15% of triangles without breaking borders), and also keeps anything that gets stuck in
the queue and retries later - this in some cases makes things worse but often helps.
The error propagation is using a simpler variant of the full error described in Nanite paper; their
error looks at projected bounds whereas we just approximate it, but that doesn't matter as much.
What does matter for correctness is enforcing that the error is monotonic, which we do by ensuring
spherical group bounds are merged conservatively.
Finally, the METIS support code is written with zero regards towards efficiency; it uses bad containers
and inefficient algorithms in some places for expediency. This is because hopefully in a year or so
all of the METIS code can be removed because meshopt replacements will be superior. :crossed_fingers:
The demo can be coerced to dump parts of the mesh as .obj via DUMP env var, which can be pretty
conveniently visualized in Blender:

Future work here includes more statistics around meshlet quality, maybe fixes around METIS usage
to improve the baseline a bit, and more importantly this will be used to improve the library in the future :)
This contribution is sponsored by Valve.

Btw, I highly recommend downloading a really large asset like https://quixel.com/megascans/free?category=3D asset&assetId=siEoZ (make sure to check the download source quality asset option) and testing on that.

METIS cluster partitioning has surprising failure cases where it decides that a good partition should
consist of 4 clusters that barely connect; this was unexpected because it doesn't seem to happen during
triangle builds. Maybe with this in mind, a reasonable (unordered) greedy cluster merge could work
better, but this will need to be investigated separately in the future anyway.

I've heard that adding weights based on cluster center distances can help.

The actual simplification currently uses automatic border detection; it would be better to switch to
using external vertex tagging via vertex_lock, but for now models I use for testing that have a lot of
room to improvement are not bottlenecked by this.

Why so? Don't you want to lock the vertices of the meshlet group border? Which is what SimplifyOptions::LockBorder should do afaik?

Don't you want to lock the vertices of the meshlet group border? Which is what SimplifyOptions::LockBorder should do afaik?

This only matters when the source asset has geometric borders. If it does, then they will be locked just as meshlet borders are, when they could in theory be simplified instead.
For example, the asset you linked has geometric borders :sweat_smile: highlighted here:

As a result, using LockBorder in this case will lock that border in all clusters, and you will never get below a fairly large triangle count as a result.
This is easy to change; similarly to cluster boundary edge detection, every vertex that is shared between any two clusters can be tagged as locked before processing all clusters in the queue at a given level or a group. But since I'm testing on assets that don't have this, I'm cutting this particular corner for now.

Are you saying that meshopt's locked vertices are based on the vertex data, and not the index data I provide? E.g. using SimplifyOptions::Sparse | SimplifyOptions::LockBorder is locking the edges of the entire mesh whenever simplifying? If so, I should definitely switch to manual vertex locks... 😅

It is based on index data. But the edge that is a border edge in the source geometry will always remain a border edge for any subset of the mesh.


Session storing issues

I made the login for the assignment and everything works fine for me but when my team mates pull the changes they get an error Message: Session: Configured save path '' is not a directory, doesn't exist or cannot be created.
Do you have office hours today or tomorrow?
@jim-parry

application/config/config/php ... line 373 ...
you have configured your sessions to store stuff locally, using files, but without specifying a file path that you have write permisisons to.
You might have a local application/config/development/config.php, with proper session config settings. Your team mates will need to do something similar, or else you need to update the shared config so that sessions work for everyone.


Sync of local changes triggers DavX syncloop

I am using DavX to sync my tasks with my Synology NAS. If i do a local change in Opentask DavX beginns to sync about every 5 seconds and the phone beginns to vibrate in the same interval. If I uninstall Opentask the syncloop is stopped, thus I think its a bug in Opentask and not in DavX.
There seem to be many people experiencing the same problem, if you look at the reviews in GooglePlay.
I have recognized that the App OneDrive gets stuck in a syncloop too. At least the notifications implies that, because they appear and disappear approximately every second. Can there be a connection to the bug in Opentask?

Hi,
I had the exact same issue when I tried to use opentasks 1.1.17 but rolled back to 1.1.13 and everything is working fine. I tried with 1.1.15 and same issue. I don't know if that helps.
@jason076 Did you manage to make it working?

@Simounet I had no time to further investigate the issue, thus I am still experiencing the bug.

I had the exact same issue when I tried to use opentasks 1.1.17 but rolled back to 1.1.13 and everything is working fine. I tried with 1.1.15 and same issue. I don't know if that helps.

I tried the rollback to 1.1.13 and it seems to work for me too. But that should not be the solution. I have installed 1.1.15 and my phone starts again vibrating a few times in a short amount of time, if I add or remove a task. I have examined the DavX debug log, but I can't find anything suspicious there.

Please check if this is still an issue in 1.1.18.

I can't see it on fdroid right now. I'll wait and let you know when it will be available.

@Simounet https://github.com/dmfs/opentasks/blob/master/releases/opentasks-1.1.18.apk

I've got this issue:
Authority: org.dmfs.tasks

REMOTE RESOURCE:
https://domain.tld/remote.php/dav/calendars/User/default/123456-654c-44fd-8e04-da4654da6.ics

EXCEPTION:
at.bitfire.ical4android.InvalidCalendarException: Couldn't parse iCalendar object
	at at.bitfire.ical4android.Task$Companion.fromReader(Task.kt:69)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager.processVTodo(TasksSyncManager.kt:140)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager.access$processVTodo(TasksSyncManager.kt:44)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager$downloadRemote$2$1$1.invoke(TasksSyncManager.kt:126)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager$downloadRemote$2$1$1.invoke(TasksSyncManager.kt:44)
	at at.bitfire.davdroid.syncadapter.SyncManager.useRemote(SyncManager.kt:820)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager$downloadRemote$2$1.invoke(TasksSyncManager.kt:113)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager$downloadRemote$2$1.invoke(TasksSyncManager.kt:44)
	at at.bitfire.dav4jvm.Response$Companion.parse(Response.kt:211)
	at at.bitfire.dav4jvm.DavResource$processMultiStatus$2.invoke(DavResource.kt:465)
	at at.bitfire.dav4jvm.DavResource.processMultiStatus(DavResource.kt:484)
	at at.bitfire.dav4jvm.DavResource.processMultiStatus(DavResource.kt:435)
	at at.bitfire.dav4jvm.DavCalendar.multiget(DavCalendar.kt:151)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager$downloadRemote$2.invoke(TasksSyncManager.kt:112)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager$downloadRemote$2.invoke(TasksSyncManager.kt:44)
	at at.bitfire.davdroid.syncadapter.SyncManager.useRemote(SyncManager.kt:809)
	at at.bitfire.davdroid.syncadapter.SyncManager.useRemoteCollection(SyncManager.kt:830)
	at at.bitfire.davdroid.syncadapter.TasksSyncManager.downloadRemote(TasksSyncManager.kt:111)
	at at.bitfire.davdroid.syncadapter.SyncManager$syncRemote$1$1.run(SyncManager.kt:451)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:457)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
	at java.lang.Thread.run(Thread.java:784)
Caused by: net.fortuna.ical4j.data.ParserException: Error at line 8:Attempt to invoke virtual method 'java.util.TimeZone java.util.Calendar.getTimeZone()' on a null object reference
	at net.fortuna.ical4j.data.CalendarParserImpl.parse(CalendarParserImpl.java:158)
	at net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:198)
	at net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:178)
	at at.bitfire.ical4android.Task$Companion.fromReader(Task.kt:67)
	... 23 more
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'java.util.TimeZone java.util.Calendar.getTimeZone()' on a null object reference
	at java.text.DateFormat.getTimeZone(DateFormat.java:704)
	at net.fortuna.ical4j.model.DateTime.<init>(DateTime.java:236)
	at net.fortuna.ical4j.model.DateTime.<init>(DateTime.java:244)
	at net.fortuna.ical4j.model.property.UtcProperty.<init>(UtcProperty.java:67)
	at net.fortuna.ical4j.model.property.Created.<init>(Created.java:86)
	at net.fortuna.ical4j.model.property.Created$Factory.createProperty(Created.java:143)
	at net.fortuna.ical4j.model.PropertyFactoryImpl.createProperty(PropertyFactoryImpl.java:72)
	at net.fortuna.ical4j.data.CalendarBuilder$ContentHandlerImpl.startProperty(CalendarBuilder.java:326)
	at net.fortuna.ical4j.data.CalendarParserImpl$PropertyParser.parse(CalendarParserImpl.java:245)
	at net.fortuna.ical4j.data.CalendarParserImpl$PropertyParser.access$1100(CalendarParserImpl.java:229)
	at net.fortuna.ical4j.data.CalendarParserImpl$PropertyListParser.parse(CalendarParserImpl.java:210)
	at net.fortuna.ical4j.data.CalendarParserImpl$ComponentParser.parse(CalendarParserImpl.java:422)
	at net.fortuna.ical4j.data.CalendarParserImpl$ComponentParser.access$900(CalendarParserImpl.java:406)
	at net.fortuna.ical4j.data.CalendarParserImpl$PropertyListParser.parse(CalendarParserImpl.java:208)
	at net.fortuna.ical4j.data.CalendarParserImpl.parseCalendar(CalendarParserImpl.java:115)
	at net.fortuna.ical4j.data.CalendarParserImpl.parseCalendarList(CalendarParserImpl.java:180)
	at net.fortuna.ical4j.data.CalendarParserImpl.parse(CalendarParserImpl.java:149)
	... 26 more

@dmfs
Version 1.1.18 seems to fix the issue for me!

Ok, it was more like a davdroid cache issue. It seems to be working right now. 🤞
Thanks!

Great! I'm closing this again.


Ability to renumerate selected numbers

@akalongman Please provide more details on this enhancement. I need some context to work on this issue.