问题标签 [conduit]

我正在尝试使用 Conduit Network，但无法编译此代码，因为它找不到数据构造函数：HostAny

安装了conduit-extra，所以我很困惑为什么找不到它？

这是 GHC 错误：

pez@devbox:~/dev$ runhaskell server.hs

我一直在使用conduit-extraUNIX 包，它基本上允许使用 UNIX 域套接字轻松创建服务器，特别是使用runUnixServerfunciton。

问题是函数存在后并没有清理套接字文件，这意味着它需要手动清理。这是一个简单的示例，它基本上创建了一个回显服务器。

我用谷歌搜索了一下，发现这里处理资源的正确方法是使用resourcet包。虽然问题是资源中的大多数 API 都希望我自己分配资源，但情况并非如此runUnixSever，它不会返回任何内容。

一开始我以为可以用register,来注册一个删除文件的函数，比如下面

但是，这种方法存在问题，至少就文档而言allocate：

这与调用分配然后注册释放操作几乎相同，但这可以正确处理异步异常的屏蔽。

这是否意味着它register本身不处理异步异常？runUnixServer如果是这样，当由（文档说它为每个客户端生成一个线程）生成的处理程序之一引发错误时，这可能是一个问题吗？

我想出的第三个也是最后一个解决方案是使用allocate, 以确保正确处理异步异常（我不确定在这种情况下是否真的有必要）。

但这真的是最好的解决方案吗？因为我正在创建一个我永远不会使用的值，(return 1)然后使用一个const函数在终结器中忽略该值。

我目前正在对我的程序进行基准测试，看看我是否可以提高它的性能。目前我的程序将获取一个输入文件并运行一些算法将其拆分为多个文件。

将文件拆分为 3 部分大约需要 14 秒，其中-O2包含库和可执行文件的编译标志。

看起来它花费了大约 60% 的时间sinkFile，我想知道是否可以做些什么来改进以下代码。

以下是 GHC 分析的输出：

这表明sinkFile需要很多时间。（我已经对列表访问等进行了基准测试，以防您想知道它们的处理率为 0%）

虽然我理解像这样的小程序 IO 通常是瓶颈，但我想看看我是否可以提高我的程序的运行时性能。

干杯!

根据文档MonadIO，如果底层 Monad 有一个MonadIO实例 ( MonadIO m => MonadIO (ConduitM i o m)) ，则有一个ConduitM 实例。

那为什么会这样：

失败：

(MonadIO (ConduitM Int Data.Void.Void IO)) 没有使用 'liftIO' 产生的实例 在 '(.)' 的第一个参数中，即 'liftIO' 在 '(>>=) 的第二个参数中'，即'(liftIO . print)' 在'($$)'的第二个参数中，即'await >>= (liftIO . print)'</p>

我在这里想念什么？

刚刚检查过，显然我有变压器 0.22 和变压器 0.3，这可能是原因。

在启动更多管道之前，我需要在与客户端之间来回做一些事情并获取客户端对象或其名称字符串。

但我似乎无法让 appSink 让我有一个返回值。

我该怎么做？

更新

这是我最终得到的解决方案：

我有一个类型的 ConduitConduit a m a和一个类型的函数(a -> Maybe a)。我想运行该函数，然后如果它返回 Nothing，请使用 Conduit。也就是说，我想要一个类型的函数

或者，更受限制的类型

如果有帮助，我的具体情况如下：

我正在编写处理 IRC 消息的代码，并且我有一个函数：

我希望能够maybePipe handlePings pipe在该函数中执行（或等效）操作，因此当 IRC 消息是 ping 时，我们以 pong 响应并且不调用用户指定的 Conduit。

我使用以下方法编写了以下解析代码attoparsec：

这适用于小型文件，我执行它是这样的：

但是当文件的大小大于 70MB 时，它会消耗大量的内存。作为解决方案，我想我会使用attoparsec-conduit. 在浏览了他们的API之后，我不确定如何让它们一起工作。我的解析器具有类型Parser Test，但它sinkParser实际上接受 type 的解析器Parser a b。我对如何在常量内存中执行这个解析器感兴趣？（基于管道的解决方案也是可以接受的，但我不习惯 Pipes API。）

我正在使用sourceFilewhich yieldByteString和另一个产生的来源Word8。我的Word8源头是无限的。

我需要一种方法将我Word8的源转换[Word8]为列表与第一个源的长度相同的ByteString源。

现在我正在开发一种以太网数据包处理库。基本思想是数据包有两种不同的来源：网络接口和 pcap 转储文件。数据包应按流分组，应过滤流，应以一种方式处理 UDP 流，以另一种方式处理 TCP，等等。我开发了没有管道的版本，但我发现现在有太多重复的代码，什么时候我正在尝试抽象然后我正在发明类似于管道的东西。所以我尝试切换到管道然后卡住了。

所以图片是这样的：

第一个问题是流程图。它应该累积流量，并且当流量中的数据包超过某个阈值时 - 将其传递给处理。

第二个问题是我想为 UDP 和 TCP 处理使用不同的管道，所以应该以某种方式拆分管道。

另一个问题是所有这些东西都应该是多线程的，所以生产者和消费者应该在不同的线程中。

那么，就管道而言，这张图片中的内容应该是什么？

来源就是来源，很清楚。但是流程图应该是什么？一个接收器，它产生进一步处理的源？许多流是巨大的，因此必须避免在进一步处理之前将所有数据包累积在内存中。

有任何想法吗？同样，很清楚如何在没有管道的情况下完成所有这些操作，因此问题是如何使用它们正确设计它。

UPD。

我想使用管道从文件中读取，然后将其流式传输到标记器中。罪魁祸首是，即使是相同的字符序列也可能会根据先前的输入产生不同的标记。

那么我怎样才能在一堆中间处理State一个呢？ConduitIO

仅仅编写Conduit Char (State TokenizerStateType) Token确实会产生几个错误类型的错误（需要 IO，状态得到错误类型）。

由于我不在自己的计算机上，因此我无法提供无法正常工作的最小示例，但是一旦有可用的 ghc，我将添加一个。