問題タブ [haskell-pipes]

私はこのコードを持っています:

replaceNth :: 関数 位置の値 ' - ' を (' P ') に置き換えます

マトリックスで「 - 」を「 P 」にする各ケースを変更したい

しかし、それは機能していません。私は常にこのエラーがあります:

これが合理的な機能要求であるかどうか疑問に思っています (既に存在していて、アクセス方法がわからない場合はなおさらです)。

これが望ましい理由の例は、pipes ライブラリです。パイプは型を定義します:

大量のエイリアスがあり、そのうちのいくつかは次のとおりです。

ご想像のとおり、これは明確なエラー メッセージの最悪のシナリオです。ドキュメントを読んでいるプログラマーとして、パラメーターの少ない単純な型の観点から考えていますが、すべてのエラー メッセージは次のような 6 つのパラメーターを持つモンスター型の観点から見ています。

そのメッセージが次のようになると、より明確になります。

副次的な質問として、GHC が b0 に置き換える特定の型 Integer を見失うのはなぜですか? 宣言された型は次のとおりです。

ともかく ...

機能要求として型エイリアスのエラー報告を改善することは可能でしょうか?それとも GHC は型エラーを検出するずっと前にエイリアスを忘れてしまうのでしょうか? （GHCはエラーメッセージの「実際の型」の部分でエイリアスを覚えているように見えるため、GHCはエイリアスを追跡する必要があるように思えますが、コンパイラがどのように機能するかはわかりません。）

ばかげたやり方かもしれませんが、これで終わりです。HTTP リクエストの送受信をレスポンスの処理から分離したかったのです。

正当なようです。しかし、応答の一部が出力され、「Network.Socket.ByteString.recv: failed (Unknown error)」が表示されます。他に何をする必要がありますか？

問題

こんにちは！私はロギング ライブラリを作成しています。別のスレッドで実行されるロガーを作成したいと考えていますが、すべてのアプリケーション スレッドはメッセージを送信するだけです。この問題に対する最もパフォーマンスの高いソリューションを見つけたいと考えています。ここには単純な unbound キューが必要です。

アプローチ

利用可能なソリューションがどのように機能するかを確認するためにいくつかのテストを作成しましたが、ここで非常に奇妙な結果が得られました。以下に基づいて 4 つの実装 (ソース コードを以下に示します) をテストしました。

1. パイプ同時実行
2. Control.Concurrent.Chan
3. Control.Concurrent.Chan.Unagi
4. 「Haskell での並列および並行プログラミング」という本で説明されているように、MVar ベースこの手法では、容量 1 の制限付きキューが得られることに注意してください。

テスト

テストに使用したソースコードは次のとおりです。

でコンパイルしてghc -O2 Main.hs実行するだけです。テストでは、20 個のメッセージ プロデューサが作成され、それぞれが 1000000 個のメッセージを生成します。

結果

質問

pipes-concurrent バージョンのパフォーマンスが非常に遅い理由と、chan ベースのバージョンよりもはるかに遅い理由をお聞きしたいと思います。MVar がすべてのバージョンの中で最速であることに、私は非常に驚いています。なぜこの結果が得られたのか、どのような場合でもより良い結果が得られるのか、誰か詳しく教えていただけますか?

JSON 型の簡単な例を次に示します。

pipes-aeson を使用して、decodedレンズを使用してソケット経由で送信される JSON メッセージのストリームをデコードするにはどうすればよいですか? 例として、解析されたときにそれらを出力したいと思います:

ProxyHaskell Pipesに 2 つあるとしましょう。これらは、外部システム プロセスを表します。

したがってEffect、次のように、それらを にフックします。

これにより、終了する最初からがEffect得られます。通常、これはではなく になります。最初に終了しない場合でも、パイプの戻り値を取得する慣用的な方法は何ですか?ExitCodeProxyproduceconsumeconsume

consumeこれまでのところ、ストリームが完了したことを認識できるように、ある種の厄介なインバンド シグナリングを行わなければ、これは不可能だと考えています。最後の Proxy がシャットダウンすることを知る唯一の方法は、 から何かを取得することです。そのため、ストリームが終了したことを知らせるawaitために空を送ることができます。ByteStringしかし、それは正しくありません。私が今持っているのは、終了値を提供できる別のMVarですが、これを行うにはもっと慣用的な方法が必要だと思います。