問題タブ [conduit]

pipesパッケージのチュートリアル[ 1]は、モナド演算子Control.Pipes.Tutorialを使用してパイプコンポーネントを「垂直にスタック」する方法を示しています。>>

Control.Frameでそれを行うにはどうすればよいですか？

たとえば、Control.Frameチュートリアルの定義を使用します。

>>ここでforを使用し???ても、タイプチェックは行われません。

[1] http://hackage.haskell.org/packages/archive/pipes/latest/doc/html/Control-Pipe-Tutorial.html#g:4

更新：これが私が試したことのペーストです：http：//hpaste.org/77986

問題のようです-上記の貼り付けcloseの関数を参照してください。明示的に指定しない場合、bar8フレームは構成可能です。もちろん、私は最終的にそれらを閉じる必要があります。うーん...>>close

二つの考えの間には強いつながりがあるように私には思えます。私の推測では、Iteratees で任意のグラフを表現する方法があれば、FRP は Iteratees の観点から実装できると思います。しかし、私の知る限り、彼らはチェーンのような構造しかサポートしていません。

誰かがこれに光を当てることができますか？

コンジットパッケージを試しています。network-conduit パッケージも見つけたので、ファイルの内容をソケットに送信する単純な TCP クライアントを作成しようとしました。

ただし、アプリ シンクは ResourceT に存在しないため、これは機能しません。

ただし、runResourceT がないと、明らかに機能しません。

私の推測では、リソースを実際に管理することなく、appSink (m=IO) を ResourceT にラップする必要があります。しかし、私はそれを行う方法を理解できません。

...？

私は Haskell のリストについて考えていましたが、他の言語では、すべてにリストを使用するわけではないと考えました。確かに、後で値が必要な場合はリストを保存したいかもしれませんが、それが 1 回限りの場合、たとえば から反復する[1..n]場合、実際に必要なのはインクリメントされる変数だけであるリストを使用する必要はありません。

また、「リストの融合」について読んだところ、Haskell コンパイラはこの最適化を実装して中間リストを排除しようとしますが、しばしば失敗し、ガベージ コレクターが 1 回しか使用されないリストをクリーンアップする必要があることに気付きました。

また、注意を怠ると、リストを簡単に共有できます。つまり、ガベージ コレクターがリストをクリーンアップしないため、以前は定数空間で実行するように設計されていたアルゴリズムでメモリが不足する可能性があります。

したがって、少なくともリストを実際に「保存」したくない場合は、リストを完全に避けるのが最善だと思いました。

その後、次のようconduitに書かれている に出会いました。

ストリーミング データの問題を解決し、コンスタント メモリ内のデータ ストリームの生成、変換、および消費を可能にします。

これは完璧に聞こえました。リソースの取得と解放の問題conduitのために設計されていることは知っていますが、リストの代わりにドロップインとして使用できますか?IO

たとえば、次のことができますか。

そして、適切に配置されたいくつかの型注釈を使用して、リストの代わりにプロセス全体にコンジットを使用しますか?

おそらくそのclassy-preludeようなコードが許可されることを望んでいましたが、よくわかりません。可能であれば、誰かが上記のように例を挙げてもらえますか?

複数のパイプを 1 つにマージすること、またはその逆は可能ですか?

次の機能の実装に苦労しています。

conduitライブラリ の基本を学ぶためにnetwork-conduit、単純なエコー サーバーを作成していました。

それは私が望んでいたことを行いますが、クライアントが接続の一部を閉じると、サーバーは残りのデータを書き出して接続の送信部分も閉じるのではなく、入力を待っています。

私は削除echoしてみました

しかし、問題はまだあります。私は何を間違っていますか？

I have this conduit expression which works:

I'm having trouble splitting it up into two pieces, i.e. something like:

so that I can use:

or whatever... The error message I get from the type-checker is somewhat inscrutable.

I've written a daemon in Haskell that scrapes information from a webpage every 5 minutes.

The daemon originally ran fine for about 50 minutes, but then it unexpectedly died with out of memory (requested 1048576 bytes). Every time I ran it it died after the same amount of time. Setting it to sleep only 30 seconds, it instead died after 8 minutes.

I realized the code to scrape the website was incredibly memory inefficient (going from about 30M while sleeping to 250M while parsing 9M of html), so I rewrote it so that now it only uses about 15M extra while parsing. Thinking the problem was fixed, I ran the daemon overnight and when I woke up it was actually using less memory than it was that night. I thought I was done, but roughly 20 hours after it had started, it had crashed with the same error.

I started looking into ghc profiling but I wasn't able to get that to work. Next I started messing with rts options, and I tried setting -H64m to set the default heap size to be larger than my program was using, and also using -Ksize to shrink the maximum size of the stack to see if that would make it crash sooner.

Despite every change I've made, the daemon still seems to crash after a constant number of iterations. Making the parsing more memory efficient made this value higher, but it still crashes. This doesn't make sense to me because none of these have runs have even come close to using all of my memory, much less swap space. The heap size is supposed to be unlimited by default, shrinking the stack size didn't make a difference, and all my ulimits are either unlimited or significantly higher than what the daemon is using.

In the original code I pinpointed the crash to somewhere in the html parsing, but I haven't done the same for the more memory efficient version because 20 hours takes so long to run. I don't know if this would even be useful to know because it doesn't seem like any specific part of the program is broken because it run successfully for dozens of iterations before crashing.

Out of ideas, I even looked through the ghc source code for this error, and it appears to be a failed call to mmap, which wasn't very helpful to me because I assume that isn't the root of the problem.

(Edit: code rewritten and moved to end of post)

I'm pretty new at Haskell, so I'm hoping this is some quirk of lazy evaluation or something else that has a quick fix. Otherwise, I'm fresh out of ideas.

I'm using GHC version 7.4.2 on FreeBsd 9.1

Edit:

Replacing the downloading with static html got rid of the problem, so I've narrowed it down to how I'm using http-conduit. I've edited the code above to include my networking code. The hackage docs mention to share a manager so I've done that. And it also says that for http you have to explicitly close connections, but I don't think I need to do that for httpLbs.

Here's my code.

and it's output:

Getting rid of the regex computations fixed the problem, but it seems that the error happens after the networking and during the regex, presumably because of something I'm doing wrong with http-conduit. Any ideas?

Also, when I try to compile with profiling enabled I get this error:

Indeed, I have not installed profiling libraries for http-conduit and I don't know how.

パイプの概念のさまざまな実装の違いを理解しようとしています。コンジットとパイプの違いの 1 つは、パイプを融合する方法です。コンジットは

パイプが持っている間

私が正しく理解している場合、pipesでは、2 つのパイプのいずれかが停止すると、その結果が返され、もう一方が停止します。コンジットでは、左のパイプが終了すると、その結果が下流の右のパイプに送信されます。

私は、conduitのアプローチの利点は何だろうか? コンジットおよびを使用して実装するのは簡単ですが、パイプおよび>+>を使用して実装するのは（より）難しい例（できれば実世界）を見たいと思います。>->

コンジットとパイプの違いを理解しようとしています。パイプとは異なり、コンジットには残り物の概念があります。残り物は何に役立ちますか？残り物が不可欠な例をいくつか見てみたいと思います。

そして、パイプには残り物の概念がないので、それらと同様の動作を実現する方法はありますか？