Closed 0xced closed 2 years ago
Thanks for the PR.
Is this more or less equivalent to using half-duplex stream as input while filling it on a separate thread?
Stream
instead of TextWriter
for better compatibility?DelegatePipeSource
into AsyncDelegatePipeSource
and DelegatePipeSource
like it's done with ---DelegatePipeTarget
Console.InputEncoding
as default encoding and provide it via an overload, similar to existing methods#if
directives, use polyfills (see https://github.com/Tyrrrz/CliWrap/blob/82144b8a695f6b10c54c9b70a421c89f52e44269/CliWrap/PipeTarget.cs#L175-L178)I think I have addressed all your points in 1fd00971f3d7d23bed88f523298f364bab172152. And the code is indeed much better like this. π
I have applied your suggested renaming in 8e561fb78960149e825e90d6443045b77d5b5746 and it looks indeed better!
As for the TextWriter
pipe sources, I have kept them because I really like to be able to create a one-liner pipe source instead of a two-liner. Also, I was impressed by the compiler who perfectly understands if you want to use PipeSource.Create(async (stream, _) => β¦)
vs PipeSource.Create(async (writer, _) => β¦)
without having to explicitly specify the Stream
or TextWriter
type.
Anyway, I don't really mind and if you think it's too much for CliWrap, please go ahead and remove them, I won't be offended. π
It should still be a one-liner in your case (the disposal is already performed upstream):
Cli.Wrap("dot").WithStandardInputPipe(PipeSource.Create(stream => graph.Build(new TextWriter(stream))));
I just don't want to deal with buffer size and other options unless I absolutely need to.
Thanks, I'll take it from here :)
Thanks, I'll take it from here :)
Awesome, thanks! π
Thank you for releasing a new version so fast. You can see it in action in my RidGraph micro project.
A real-world usage would be piping the construction of a DotGraph object to the
dot
command line tool like this:βπΊπ¦