Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

wai-graceful

技術

wai-graceful の仕組みを眺めた。

warp 側に手を入れずにどうしてるのかと思ったら forkIO してサーバスレッドを別で立てといた上で、シグナル受け取ってからリクエスト捌き終わるまでメインスレッド残すのね。リクエストの処理が強制終了されることがないものの、シャットダウン中もリクエスト受け続けて 503 返し続けるのはどうなんだろ。リクエストを待ち続けていいのかも気になる・・・まあgracefulだからタイムアウトさせなくていいってのはあるかも。

そもそも warp ってシグナルどう扱ってるんだろ。

Windows 上での getChar のための no-buffering-workaround パッケージ

技術

hiratara.hatenadiary.jp

エンターキーを押さないとキー入力を受け付けてくれない。大昔からチケットが上がっていて、

今日気がついたのだけど、Hackageにいい感じのパッケージが上がってる。

no-buffering-workaround: Workaround for GHC bug #2189.

使い方は initGetCharNoBuffering を呼んで ((ただし、こいつはNOP。UNIX環境だと NoBuffering を呼んでくれるので、その代わりに使っておくと良い)) 、 getChar の代わりに getCharNoBuffering を使うだけ。お手軽。

ただし、こいつで作った実行ファイルは msys2 上からはまともに動かない。PowerShellから叩くと、いい感じに動いた。

Unit への implicit conversion

技術

内容はともかく気になったのが、

  def A_B_Cのつもりで書いた間違っているのにビルドが通る例(): Future[Unit] = {
    funcA()
      .map { _ =>funcB()}
      .map { _ =>funcC()}
    // ※たとえでこう書いていますが、本来はfor文とかを使いましょう
    // ※返値の型は本当はFuture[Future[Unit]]です。
  }

《Scala》Future[Unit]は気をつけて使おうの話

がなんでコンパイル通るのかなと思って *1 、 sub typing や ビルトインで定義されている implicit conversion を疑ってたんだけど、 Unit に関するものは見つからず、なんでだろうと。

答えは、単純に言語仕様だから、だった。

If e has some value type and the expected type is Unit, e is converted to the expected type by embedding it in the term { e; () }. https://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html

*1:コメントの型も正しい意味なのやら

`stack setup --upgrade-cabal` した

技術

lts-7.19 使ってたら嫌な感じのエラー。

    /tmp/stack25595/cairo-0.13.3.1/Setup.hs:8:29: error:
        • Couldn't match expected type ‘Distribution.Simple.UserHooks.UserHooks’
                      with actual type ‘Cabal-1.24.2.0:Distribution.Simple.UserHooks.UserHooks’
          NB: ‘Cabal-1.24.2.0:Distribution.Simple.UserHooks.UserHooks’
                is defined in ‘Distribution.Simple.UserHooks’
                    in package ‘Cabal-1.24.2.0’
              ‘Distribution.Simple.UserHooks.UserHooks’
                is defined in ‘Distribution.Simple.UserHooks’
                    in package ‘Cabal-1.24.0.0’
        • In the first argument of ‘defaultMainWithHooks’, namely
            ‘gtk2hsUserHooks’
          In the expression: defaultMainWithHooks gtk2hsUserHooks
          In an equation for ‘main’:
              main = defaultMainWithHooks gtk2hsUserHooks

ほぼ読んでない けど、

$ stack setup --upgrade-cabal

で解決。ついちょっと先日にもやった気がする。

build とか install じゃなくて setup なとこに注意。

とかやってたら、ghc-8.0.2 が使えるようになってた。

"hSetBuffering stdin NoBuffering doesn't work on Windows" とのこと

技術

完全に序盤で投げ出されているけど、Haskellでroguelikeを実装するエントリ。

https://github.com/jamiltron/Thieflike

Haskell には https://hackage.haskell.org/package/LambdaHack っていうroguelikeがあって そっちのほうが真面目に作られてるのだけど、CLIのバックエンドがvtyなのでwin環境では動かない。一方、Thieflikeはansi-terminalが使われているので動く。はずだったのだけど。

動かしてみると、エンターキーを押さないとキー入力を受け付けてくれない。大昔からチケットが上がっていて、

https://ghc.haskell.org/trac/ghc/ticket/2189

  • Milestone set to 6.8.3
  • Milestone changed from 6.8.3 to 6.10.1
  • Milestone changed from 6.10.1 to 6.10.2
  • Milestone changed from 6.10.2 to 6.12.1
  • Milestone changed from 6.12.1 to 6.12 branch
  • Milestone changed from 6.12 branch to 6.12.3
  • Milestone changed from 6.12.3 to 6.14.1
  • Priority changed from normal to low
  • Milestone changed from 7.0.1 to 7.0.2
  • Milestone changed from 7.0.2 to 7.2.1
  • Milestone changed from 7.2.1 to 7.4.1
  • Milestone changed from 7.4.1 to 7.6.1
  • Milestone changed from 7.6.1 to 7.6.2
  • Milestone changed from 7.6.2 to 7.10.1
  • Milestone changed from 7.10.1 to 7.12.1
  • Milestone changed from 7.12.1 to 8.0.1
  • Milestone changed from 8.0.1 to 7.10.3
  • Milestone changed from 7.10.3 to 8.0.1
  • Milestone 8.0.1 deleted

https://ghc.haskell.org/trac/ghc/ticket/11394

Milestone set to 8.4.1

という終わりの見えない状況で辛い。

msys2の最新版で [lost server] が発生

技術

msys2 をアップデートしたら、 tmux でクリップボード周りを操作すると [lost server] 的なメッセージが出て死ぬようになってしまった。今までも何度かあったこととは言え、辛さに溢れる。

とりあえずこれの通り msys2 のランタイムのバージョン下げたら直った。この辺もいつもの通りの対処法。

https://github.com/Alexpux/MSYS2-packages/issues/791#issuecomment-275253779

MSYS2でHDBC-sqlite3をコンパイル

技術

当然のことながら、msys2のshellではなくmingw64のshellから操作する。

まず、 sqlite3 を入れる。

pacman -S mingw64/mingw-w64-x86_64-sqlite3

後はビルドするだけなんだけど、2点注意がいる。

  • --extra-include-dirs と --extra-lib-dirs にmingw64関連のディレクトリを明示する
  • --skip-msys を指定する

--skip-msys は ここ とか ここ 読めばわかるけど、指定しなければwin環境のGHCがデフォルトで内部に持ってるmsys2のPATHを見てしまうのを、抑制して見ないようにしてくれる。

stack build --skip-msys --extra-include-dirs=/c/msys64/mingw64/include/  --extra-lib-dirs=/c/msys64/mingw64/lib/ HDBC-sqlite3

余談

--extra-* の指定が必要な理由はよくわからない。明示しなくてもmingw64のshellを使ってるのだから勝手に見て欲しいもの。

依存ライブラリのチェックはcabal側でやってて 、ここで使うgccがどれなのかがまず重要である。ここに関しては一応 stack 側で --with-gcc=/c/msys64/mingw64/bin/gcc のような指定は可能で、これを指定するとライブラリのチェックでは落ちなくなる。しかし、結局buildの部分で落ちる。

2017-01-29 10:45:52.197846: [debug] Run process: C:\stack_root\setup-exe-cache\x86_64-windows\Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.1.exe --builddir=.stack-work\dist\ca59d0ab build --ghc-options " -ddump-hi -ddump-to-file"
@(System\Process\Read.hs:340:3)

--  While building package HDBC-sqlite3-2.3.3.1 using:
      C:\stack_root\setup-exe-cache\x86_64-windows\Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.1.exe --builddir=.stack-work\dist\ca59d0ab build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

...略...

    [7 of 7] Compiling Database.HDBC.Sqlite3 ( Database\HDBC\Sqlite3.hs, .stack-work\dist\ca59d0ab\build\Database\HDBC\Sqlite3.o )

    C:\tools\msys64\tmp\stack12828\HDBC-sqlite3-2.3.3.1\hdbc-sqlite3-helper.c:1:21: error:
         fatal error: sqlite3.h: No such file or directory
    compilation terminated.
    `gcc.exe' failed in phase `C Compiler'. (Exit code: 1)

ここで setup.exe 呼ぶのにも --with-gcc が必要な気がするのだけど、 stack がそれを指定していないように見える。が、面倒なのでこれ以上は追いかけてない。