Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You need to use the <a href="http://hackage.haskell.org/packages/archive/conduit/0.1.1.1/doc/html/Data-Conduit.html#t:SequencedSink" rel="noreferrer"><code>SequencedSink</code></a> system for this; it uses a sink and a tracked state to produce a conduit from the repeated application of a sink producer.</p> <p>The sink you have created is optimized for incrementally parsing <em>one</em> value, which will be the result at the end of a conduit sequence.</p> <p>Since you want this to be part of a conduit pipeline, however, and each chunk of the incoming <code>ByteString</code> might or might not match your parser one or multiple times, you need to take care to get more fine-grained control of the parsing process, passing on the state of an incomplete parse between every application of the sink.</p> <p>Assuming, for example, that your parser parses <code>[--]</code> or <code>[----]</code> etc., and <code>T</code> is <code>Int</code> denoting the number of dashes parsed, you need to track the state of the parser as demonstrated by this:</p> <pre><code>Input chunk Sink result - Data.Conduit.SequencedSinkResponse [--][---] Emit Nothing [2, 3] [---][--- Emit (Just #func) [3] --------- Emit (Just #func) [] ] Emit Nothing [12] Stop </code></pre> <p>In this case, I use <code>Maybe (ByteString -&gt; Data.Attoparsec.ByteString.Result)</code> as the passed-on state; a different data type might be more suitable depending on the situation.</p> <p>This explicit stream treatment is needed to maintain the pipeline nature of the conduit; having the parser conduit be a "bottleneck", always waiting for enough data to chunk-wise satisfy a parser, would be a major performance sink.</p> <p>The implementation of the needed sink should be fairly trivial with the available <code>ResourceT</code> monad interface.</p> <p><strong>EDIT:</strong> Simply applying your sink in a loop would indeed be the simplest solution, but it will have slightly different performance characteristics if your parser parses short snippets that often end up on the borders of byte chunks.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow can I turn a Sink into a Conduit?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USdflemstr
    1. USdflemstr
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow can I turn a Sink into a Conduit?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks, I'll give that a try. Does this mean that I won't be using attoparsec-conduit at all? If so, would there be any obstacle to adding a generic `conduitParser :: (AttoparsecInput a, ResourceThrow m) => Parser a b -> Conduit a m b` to its interface using this technique, or is it a simple omission?
      singulars
      1. PO
      1. USehird
    2. CO@ehird, I believe that it's simply an omission; the current `sinkParser` code suggests that it could easily be transformed to parse the input stream multiple times, as it uses a similar technique as I described above, only that it stops consuming input after the first parse.
      singulars
      1. PO
      1. USdflemstr
    3. COIndeed, it seems there's already [a pull request](https://github.com/snoyberg/conduit/pull/11) adding `conduitParser` to attoparsec-enumerator; I'll probably use that implementation. Thanks for letting me know about `SequencedSink`, by the way; I passed over it when reading the documentation.
      singulars
      1. PO
      1. USehird
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload