Aki Hideaki Kawai

Sure, I will take a look.

@mawww Hi, I have updated the test, pushed it. The test itself looked working, but some of CI tests failed. https://cirrus-ci.com/build/5797598868013056 Then I rebased this branch onto the current master,...

@krobelus Okay, I will try it, thanks.

@mawww Hi, it seems this PR is ready to get merged. Or am I still expected to do something?

On our application, we make all timestamps to be saved in utc and use only oid 1114. In such a case, just replacing the 1184 with 1114 works. But of...

I wrote [this patch](https://github.com/kayhide/haskell.nix/commit/da574a8c7231ad2bd1d026ab74596b7c7f0f19f3#diff-4e2e86a748f76bc66c0645a7a9cb2915) and solved the gcc version detection. But I could not find out how to apply this patch properly in the process of nix build. Adding this...

I made a progress. The problem was actually triggered by a derivation which comes from [old-ghc-nix](angerman/old-ghc-nix). On that repo, I successfully applied a patch and built `bindist-version` on macOS. I...

Yeah, I setup the nix config to build the golang version. I just tried it on the current `golang` branch and found that does not build. I will take a...

@nobsun コメントありがとうございます。 > 仕組みとしては、Travis-CIとかを使えばいいのかもしれませんね。 そうですね。 それができればバッヂも使えるのでサンプルコードの健全性はひと目でわかるようにできそうです。 Haskell で ci ツールを回したことはありませんけど、依存パッケージを大量に使ってたりしても大丈夫なのかな？ > 基本的には、1. の場合は解説が主で、コードは説明のための具体例、2. の場合はコードが主で、解説はコメントと考えることになります。 このレシピ集では、メンテナビリティを重要な視点として考えています。 いってみればコンテンツを陳腐化させない、というのがミッションですね。 そのために、編集コストはできるだけ下げたいですし、閲覧者が気付いたらすぐにツッコミいれれるような仕組みにもっていきたいです。 いま、1. の方針ではじめているのはそういう背景にもとづいています。 markdown だと前提知識は（haskell や haddock に比べて）少なくて済みますし、github 上でいきなりコンテンツになっている、という手軽さを活用しようとしています。 とはいえ、パッケージにする、という発想はなかったので面白いですね。 コンテンツは markdown のまま何とかしてパッケージにする、というのはさすがにムリでしょうか？

> markdown から有効なコードブロックだけを抽出して、モジュールファイルに変換するツールがあれば、 masterブランチのリポジトリを処理してcodeブランチ（名前は適当）を構成する仕組みが作れそう。 おお、それができればやりたいですね！