| Age | Commit message (Collapse) | Author |
|---|
|
This brings a bunch of improvements. I got rid of some custom packages, I can
now build exllama without using a non-default cuda version. Oh yeah and I get to
use GHC 9.6.2 now, a huge upgrade from 9.4. Unfortunately I also updated ormolu
and some unrelated formatting changed, but that's life I guess.
|
|
The main change here is 'puts' now returns a value, this enables me to
collect the value from the conduit source while also doing stuff with
it, like printing or logging it as I want.
Previously I was running conduit over the source, *and then* kicking off
the concurrent processes to wait for the process and collect the output.
This would (I think) drain the source before it got to the 'puts'
conduit run, and so I wouldn't be able to get the output streamed in
real time.
It took a lot of refactoring and exploratory programming to get to this
relatively-small diff, but now puts works correctly. At least I think it
does... it seems to work more reliably from ghci than from the shell.
Maybe the shell or TERM is causing nix-store to do some buffering? Maybe
I need to use the threaded runtime in GHC? Not sure, but I will look out
for this issue and try to identify and fix.
Update: yep it was the threaded runtime. I enabled that and now it works
in the shell. I squashed that commit into this one.
|
|
|
|
This also fixed a bug where every dependency would get pulled into the Haskell
target while searching for transitive dependencies.
|
|
|
|
|
|
|
|
Still need to add this to the CLI, and there should be other features like
delete and so on, but this works for now.
|
|
|
|
Still todo: add authentication. But that can wait.
In re-implementing this, I was able to figure out how to get the Go.mult working
properly as well. The problem is that a tap from a mult channel does not remove
the message from the original channel. I'm not sure if that should be a core
feature or not; for now I'm just draining the channel when it's received in the
Que HTTP handler. (Also, this would be a good place to put persistence: have a
background job read from the original channel, and write the msg to disk via
acid-state; this would obviate the need for a flush to nowhere.)
Also, streaming is working now. The problem was that Scotty closes the
connection after it sees a newline in the body, or something, so streaming over
Scotty doesn't actually work. It's fine, Servant is better anyway.
|
|
This parses the files contents for imports, then uses ghc-pkg to lookup the
package that provides the module. Now I can do that analysis in Haskell instead
of nix, which is much easier to code with.
|
|
Perhaps this is not as performant as the wai-provided one, but it is *much*
simpler and follows my output format, which I think is much easier to quickly
read. Anyway I doubt logging will ever be a bottleneck, and if it is then I
should be able to create some instrument to detect that.
|
|
|
|
|
|
|
