Open stolyaroleh opened 5 years ago
I am not sure about the choice of streaming library. I know about pipes
and conduit
, and I picked the former because it seems to have fewer dependencies.
This is nice! Personally I like pipes. Will try to integrate these changes when prerequisites are in place.
Thanks! I have a fork of hnix-store where I have implemented all ops for a personal project, and this was my attempt to merge my efforts upstream. I just noticed that I have a fix for a bug I introduced with these changes, will update the PR soon. Let me know if you need help with integration.
Soon? :D
It's not quite clear if pipes or dlist from anoher PR or streaming lib.. which is why I've started exploring effect systems so you could possibly use any of that by just replacing interpreter.
For a simple solution that doesn't require adding any extra dependencies, why not just use an IO callback? I.e., plumb a function with signature Logger -> IO ()
through the MonadStore
type, perhaps as part of the ReaderT
context.
Then the user can specify this callback and do whatever they like with it, such as feed it into a streaming library. (I assume this is possible with pipes
?)
Soon? :D
Soon^tm! :upside_down_face:
For a simple solution that doesn't require adding any extra dependencies, why not just use an IO callback? I.e., plumb a function with signature
Logger -> IO ()
through theMonadStore
type, perhaps as part of theReaderT
context.Then the user can specify this callback and do whatever they like with it, such as feed it into a streaming library. (I assume this is possible with
pipes
?)
This was obvious to me but there were many more things that need handling first, but it is done now and you can implement your own runner that uses a custom appendLog
. The typeclass is not quite ideal yet I think because there are too many methods to my liking.
If anyone knows a good solution how to make it easier to implement please step forward! (or even better submit a PR :smiley_cat: )
I will try to implement another runner that prints log to stdout soon^tm just to see how bad it is because the default one is only useful for testing.
..instead of collecting them in memory and then returning everything at once.
I did this by changing the
MonadStore
to:It's a
Producer
of log messages that can fail with anError
:runStore
can now accept aConsumer Logger IO (Either Error a)
parameter to consume logs incrementally. I also added arunStore_
that simply discards all logs.Similarly, I changed the
runOpArgs
andrunOp
: now they accept aGet a
parser that is used to get the result.runOp_
andrunOpArgs_
assume that op does not return anything interesting.I also implemented the
buildPaths
op to confirm that this works.