Right now niv updates packages one after the other. This can be slow if the nix/sources.json contains lots of packages.
There's a branch somewhere that simply calls (something similar to) forConcurrently when iterating over the packages to upgrade. The main drawback is that all outputs get mangled.
I recently played with an idea for a logger (I unfortunately lost the niv branch):
- A single thread is responsible for rendering and has associated state. The state looks something like
TVar (Map Key [String]) where each Key is allocated some screen space which can grow and shrink depending on the [String] (the lines to display). This is made possible by the use of ANSI control codes.
- There is one
Key issued per thread. Whenever the code calls (an overriden version of) putStrln, myThreadId is used to generate the Key. It then writes its new output to the global (TVar (Map Key [String])) rendering state.
Right now niv updates packages one after the other. This can be slow if the
nix/sources.jsoncontains lots of packages.There's a branch somewhere that simply calls (something similar to)
forConcurrentlywhen iterating over the packages to upgrade. The main drawback is that all outputs get mangled.I recently played with an idea for a logger (I unfortunately lost the niv branch):
TVar (Map Key [String])where eachKeyis allocated some screen space which can grow and shrink depending on the[String](the lines to display). This is made possible by the use of ANSI control codes.Keyissued per thread. Whenever the code calls (an overriden version of)putStrln,myThreadIdis used to generate theKey. It then writes its new output to the global (TVar (Map Key [String])) rendering state.