added: fileSourceByteString

[ncaq]

This function is to get FileInfo raw body.

Conduit type is hard for begginer user.

• haskell - Persisting an uploaded file in the database (Couldn't match type ‘ConduitM () ByteString (ResourceT IO) ()’ with ‘HandlerT App IO ByteString’) - Stack Overflow
• Processing an uploaded file with and embedding it in a template - Google グループ

Actually I was not sure when I was a Haskell beginner.

ByteString raw body of FileInfo is need to upload file to S3.
This function running our product.
I send it to upstream.

Before submitting your PR, check that you've:

• Bumped the version number
• Documented new APIs with Haddock markup
• Added @since declarations to the Haddocks for new, public APIs

After submitting your PR:

• Update the Changelog.md file with a link to your PR
• Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

[snoyberg]

There are a few problems with this implementation:

1. CL.foldMap id has quadratic complexity. It would be better to use something like sinkLazy
2. It's more common to use runConduit $ src .| sink

How about:

runConduit $ fileSource fileInfo .| Conduit.

[ncaq]

I use runConduit.
But fileSource function result strict ByteString.
So I think can't use sinkLazy.
Do you think?

[snoyberg]

You'd have to use Data.ByteString.toStrict, but that's more efficient than using foldMap.

[snoyberg]

Can you reword this comment to something like:

Extract a strict `ByteString` body from a `FileInfo`.

This function will block while reading the file.

[ncaq]

@snoyberg I think that sinkLazy can't use this case.
Do you think?

[ncaq]

@snoyberg
I use sinkLazy.
However, Maybe fileSourceByteString return Lazy ByteString is great than Strict?

[snoyberg]

Returning a lazy ByteString instead is a good idea, though then it should be documented to clarify that the value will still be strictly read (as opposed to lazy I/O).

[ncaq]

@snoyberg
I think again.
fileSource is strict, so fileSourceByteString should be strict.

So, I use foldC. Do you think about?

[snoyberg]

foldC has the same quadratic behavior issues as foldMapC.

[ncaq]

@snoyberg
Sorry, What are "complexity" mean code clearing or performance?
I understood to code clearing.
So, I try to write clear code.
But, Are you speak performance?

[snoyberg]

It refers to the performance.

…

On Tue, Apr 24, 2018, 2:03 PM ncaq ***@***.***> wrote: @snoyberg <https://github.com/snoyberg> Sorry, What are "complexity" mean code clearing or performance? I understood to code clearing. So, I try to write clear code. But, Are you speak performance? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1503 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBByLD5-n7thrburn-unt8EwyggqiNks5trwaQgaJpZM4TXpqz> .

[ncaq]

@snoyberg I rewrite.

[snoyberg]

Thanks!