Zenza Bronica S 系用接写リングの説明書（をスキャンしたものをプリントしたもの）を入手したので文字データに起こした。
この接写リングは4個（C-A C-B C-C C-D）で1組になっています 使用できるレンズも 40 mm～200 mm までと巾広く 標準レンズ使用の場合で等倍までの近接撮影ができます 4個の接写リングは撮影の目的に合わせ ご自由に組合せてご使用ください 別表は S2 型・C2 型カメラに 接写リングと交換レンズを組合せた場合の撮影倍率と露出倍数の関係を示します
（表）
● 被写体に近接するに従って フィルム面とレンズの距離は遠くなり 実際のレンズの明るさ（F値）は減少します 表中の露出倍数を参考にして露出時間を増加してください
● 接写には ブロニカ TTL 露光計の併用をおすすめいたします 露出倍率などに関係なく 指針を 0 に合わせるだけで 正しい露光が得られ 完全に遮光されたピントフードがついていますので映像は明瞭です
id:syocy のブログを見たので Windows で自分がどうしているかをメモしておく。
最近は ghcup があるがシェルスクリプト製で自分は PowerShell ユーザーなので stack を使っている。（ghcup はなんで Haskell 製じゃないんだ1？）
GHC 8.8 を使うには resolver は ghc-8.8 や nightly を指定する。まだ LTS にはなっていない。
エディターは Spacemacs を使っている。前は IntelliJ IDEA に HaskForce プラグインを入れて使っていたが、ソースコード量に対して線形以上に動作が遅くなっている感覚があって使わなくなってしまった。
Spacemacs の提供してる Haskell レイヤーに Happy Haskell Programming を追加して使っている。
.spacemacs.d\init.el に次のように追記している（リポジトリー）。
(defun dotspacemacs/user-config () … (add-to-list 'load-path "~/.spacemacs.d/hhp/elisp") (autoload 'hhp-init "hhp" nil t) (autoload 'hhp-debug "hhp" nil t) (add-hook 'haskell-mode-hook (lambda () (hhp-init))) … )
HHP は stack プロジェクトを考慮しないので、unveil-stack を使って、ghc コマンドが呼ばれると現在のプロジェクトの resolver が指定する ghc を呼び直すようにしている。hhpc や hhpi についても同様で stack exec -- hhpc のように呼び直している。
Spacemacs の Haskell レイヤーについてはここを、HHP の機能についてはここを参照のこと。
Haskell プロジェクトのビルドは stack 経由だが、その他のタスク用に PowerShell 版の Make のような Psake を使っている（発音は「酒」と同じだそうだ）。
リポジトリーの全ファイルに stylish-haskell や hlint をかけたり、改行を CR/LF から LF に変換したりするのに使っている。
Task Format {
Exec { Get-ChildItem -Filter '*.hs' -Recurse src | ForEach-Object { stack exec -- stylish-haskell -i $_.FullName } }
}
Task Lint {
Exec { stack exec -- hlint src }
}
PowerShell 用 ghcup 作りました。GHC 環境構築 概観 と PowerShell - 趣味はデバッグ……↩
ブログに書いてみるとよく分からなくなってきました 🙃
Haskell-jp で回答をもらいました。
@lotz84_ さんの記事や GHC のプロファイルに出てくる CAF がよく分かってなかったのをまとめる。
fact のメモ化lotz さんの記事の階乗 fact 関数を題材にする。
fact :: Int -> Integer fact 0 = 1 fact n = fromIntegral n * fact (n-1)
lotz さんの記事よれば、次の実装だとメモ化されるとのこと。
-- | 関数をメモ化する関数 memoize :: (Int -> a) -> Int -> a memoize f = (map f [0..] !!) fact :: Int -> Integer fact = memoize fact' where fact' 0 = 1 fact' n = fromIntegral n * fact' (n-1)
な、なんで……
1つめを fact1、2つめを fact2 として GHCi で確かめてみる。
> :set +s > fact1 50000 `seq` pure () (2.44 secs, 2,605,979,968 bytes) > fact1 50000 `seq` pure () (2.41 secs, 2,605,979,968 bytes) > fact2 50000 `seq` pure () (2.50 secs, 2,613,580,040 bytes) > fact2 50000 `seq` pure () (0.00 secs, 88,432 bytes)
確かに fact2 の2回めの評価はすぐに終わっている。
簡単のために fact2 を次のように書き換える。
fact3 :: Int -> Integer fact3 = (map fact' [0..] !!) where fact' 0 = 1 fact' n = fromIntegral n * fact' (n-1)
> fact3 50000 `seq` pure () (2.47 secs, 2,611,180,024 bytes) > fact3 50000 `seq` pure () (0.00 secs, 88,432 bytes)
同じようにメモ化されている。
では次のように書き換えると？ポイントフリー化されていたのを引数を明示するようにした。
fact4 :: Int -> Integer fact4 x = map fact' [0..] !! x where fact' 0 = 1 fact' n = fromIntegral n * fact' (n-1)
> fact4 50000 `seq` pure () (2.58 secs, 2,619,180,432 bytes) > fact4 50000 `seq` pure () (2.59 secs, 2,619,180,432 bytes)
メモ化されない。
もう1つ、ラムダ式で定義すると？
fact5 :: Int -> Integer fact5 = \x -> map fact' [0..] !! x where fact' 0 = 1 fact' n = fromIntegral n * fact' (n-1)
> fact5 50000 `seq` pure () (2.57 secs, 2,619,180,432 bytes) > fact5 50000 `seq` pure () (2.52 secs, 2,619,180,432 bytes)
メモ化されない。
何か特別な形である必要があるみたい。
Haskell High Performance Programming によると、その特別な形は Constant Applicative Form（定作用形）というらしい。プロファイルを取ると Cost Centre に CAF と書かれてあるやつ。
とりあえず、項がラムダ式であるとダメだそうなので fact5 は CAF ではない。
項がスーパーコンビネーターであるとは、項が定数もしくは、項がコンビネーターであり全ての部分項がスーパーコンビネーターであるものである。
これは次の定義と同値だそう。
任意の
\x1 x2 … xn -> E（Eはラムダ式でない。。）の形の式で次の場合に限りそれはスーパーコンビネーターである。
Eにおける自由変数はx1,x2, …xnのみで、かつEに出現するラムダ式は全てスーパーコンビネーターである。
fact3 が CAF であるかを確認する。
fact3 :: Int -> Integer fact3 = (map fact' [0..] !!) where fact' 0 = 1 fact' n = fromIntegral n * fact' (n-1)
map fact' [0..] !! は定数でないため部分式が全てスーパーコンビネーターであればよい。
部分項である map は、あ、あれ？定数でないしスーパーコンビネーターでもなくただの変数では……？2つめの定義においても x1, x2, … xn 以外の自由変数だし……
…………
……
…
いかがでしたか？関数がメモ化関数になるためには定義が CAF でないといけないようです 😎
なんで fact3 が CAF なのか教えてください 🙏
Haskell-jp で回答をもらいました。
（Markdown モードで引用の中でコードブロック書くのどうやるんだ……）
@mizunashi-mana
スーパーコンビネータは，一般の文脈では確かにコンビネータで部分項がスーパーコンビネータであるものを指しますが， CAF の文脈では，
だと思うのが良いと思います．厳密には，
https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts/storage/gc/CAFs
に書いてある通り，要はサンクとなる static closure のことを指しています．
ところでメモ化の要因は，確かに fact3 が CAF であることもありますが，一番の要因として， Core では関数適用の引数は let を通して変数に束縛されることになるので，実際にはこのプログラムは
fact3 = (!!) fact3' where fact3' = map fact' l l = [0..] fact' 0 = 1 fact' n = ...
みたいなものと等価になります (厳密にはこれも怪しいですが) ．で， fact3' が CAF となるからというのが大きいですね (なお実際 GHC 8.6.5 では fact3' が floating out されていて， fact3 自体は最終的に eta expand されて fact3 = \x -> (!!) fact3' x という形になっていました)
え？6？いやいや 5 ですよ？
慣れ親しんだ秋葉原の地を飛び出して池袋にやってきました。
めちゃくちゃ広くてびっくりです。秋葉原通運会館からアキバスクエアにやってきたときも思いましたが、同じ感想がもう一度。
ガラス張りじゃなくなったので外の行列見てやばいやばい言えなくなったのはほんのちょっとだけ残念です。
kakkun61 という名前でもろもろアカウントを取っているのですが、今回は卓番号が「か61」ということでまさに自分のための場所でした。覚えやすい！
そんな弊卓の様子です。
新刊落としました…… フィルムカメラに目覚めた結果土日をそれに使ってしまい云々
ま、まぁ、でも、商業化した『Haskell で作る Web アプリケーション』は初技術書典持参だったし云々
はい。楽しみにしていただいたみなさまにはすみませんでした。
被チェック数は60でした。
売上部数は下記の通り。
『手続き Haskell』は印刷部数のおよそ半分が売れて、『Haskell で作る Web アプリケーションは完売でした。
技術書典 2・4 でも頒布した（同人版ですが）『Haskell で作る Web アプリケーション』が思った以上にサクサク売れていったのが印象的でした。技術書典への新規参加者か、表紙がよくなったことか、その両方か。
それでは。
Servant は型レベルプログラミングによって、ウェブアプリとしてのインターフェースと実装との差異を防ぐことのできるウェブアプリフレームワークです。
haskell-servant.readthedocs.io
日本語記事としては lotz さんのこちらが分かりやすいので、参考にしてください。
Haskell Relational Record は言語内 DSL によって SQL を生成するもので、正しくない SQL に相当するものは型エラーとなります。
この2つを組み合わせることで、ユーザーからのリクエストから DB 操作を経てレスポンスの返答まで型に守られて開発ができるようになります。
この記事で解説するソースコードはこのリポジトリーで公開しています。
Stack の resolver は 12.26 を使用しています。
下記のようなインタフェースを持ったアプリを作ります。
/books で返る JSON は次のような形式です。
{ "ABC of Read": { "name": "ABC of Read", "auther": "Mary" }, "The Good Text": { "name": "The Good Text", "auther": "John" } }
/book/1 で返る JSON は次のような形式です。
{ "name": "The Good Text", "auther": "John" }
DB 接続を扱うということは、ハンドラー内で接続にアクセスできないといけません。ここでは Reader モナドトランスフォーマーを Servant のハンドラーに積みます。ロガーも使うのでその上に Logging モナドトランスフォーマーも積みました。
type Handler = LoggingT (ReaderT (Pool Connection) Servant.Handler)
Api 型とそれぞれのハンドラーが定義されている場合、ハンドラー拡張前では Application 型の値は次のようになっているでしょう。この部分は積んだモナドトランスフォーマーをはがすように書きかえなければいけません。
app :: Application app = serve api server api :: Proxy Api api = Proxy server :: Pool Connection -> Server Api server pool = Index.handler :<|> Books.handler :<|> Book.handler
次のように書きかえます。
makeApp :: IO Application makeApp = do pool <- createPool connect disconnect 1 -- stripes 1 -- time for keeping open 5 -- resource per stripe pure $ serve api $ server pool api :: Proxy Api api = Proxy server :: Pool Connection -> Server Api server pool = hoistServer api (flip runReaderT pool . runStdoutLoggingT) $ Index.handler :<|> Books.handler :<|> Book.handler
接続は再利用したいので resource-pool を用います。server 関数は hoistServer 関数を使ってモナドトランスフォーマーをはがす関数を埋め込みます。hoistServer などについてはこちらを参考にしてください。リンク先の記事は最新版の Servant 0.12 に対応させました。
通常は runQuery' 関数に接続を渡して使用しますが、今回作ったハンドラーは Reader モナドで接続を持っていますので接続を渡す部分を隠すことができるはずです。次のようなラッパー関数を作りました。
runQuery' :: (ToSql SqlValue p, FromSql SqlValue a) => Query p a -> p -> Handler [a] runQuery' q p = do pool <- lift ask withResource pool $ \conn -> liftIO $ R.runQuery' conn q p
今のところ次のようなモジュール構成にして開発しています。
この記事は IIJ の執務時間を使って書かれました。
コードは前回記事と同じです（再掲）。
import Control.Concurrent import Control.Monad import System.Exit import System.IO import System.Win32.Console.CtrlHandler main :: IO () main = do tid <- myThreadId let handler event = do if event == cTRL_C_EVENT then do putStrLn "goodbye!" killThread tid pure True else pure False pHandler <- mkHandler handler success <- c_SetConsoleCtrlHandler pHandler True when (not success) $ do putStrLn "SetConsoleCtrlHandler failed" exitFailure let loop n = do putStr $ show n ++ ", " hFlush stdout threadDelay 1000000 loop (n+1) loop 0
これを次の4通りのオプションでビルドします。
name: windows-interruption dependencies: - base >= 4.7 && < 5 - Win32 executables: app-rtsopts-threaded: main: Main.hs source-dirs: . ghc-options: - -rtsopts - -threaded app-threaded: main: Main.hs source-dirs: . ghc-options: - -threaded app-rtsopts: main: Main.hs source-dirs: . ghc-options: - -rtsopts app: main: Main.hs source-dirs: .
これを実行してみます。
タイミングによる。
$ app 0, 1, 2, goodbye! goodbye! app.exe: thread killed （応答がなくなる）
$ app 0, 1, 2, goodbye! goodbye! app.exe: thread killed （終了する）
$ app 0, goodbye! app.exe: thread killed app.exe: warning: too many hs_exit()s
また、GHC 8.6.3 でコンパイルしたときですが、下記のようなエラーが出ることもありました。そもそも GHC 8.6.3 は Windows でのビルドにバグがあるので、他は GHC 8.4.4 を使っています。
$ app
0, 1, 2, goodbye!
goodbye!
Access violation in generated code when writing 0x20
Attempting to reconstruct a stack trace...
app.exe: internal error: scavenge_stack: weird activation record found on stack: 5212000
(GHC version 8.6.3 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Frame Code address
* 0x484dd00 0x736b99
タイミングによる。
$ app-rtsopts 0, 1, 2, goodbye! goodbye! app-rtsopts.exe: thread killed
$ app-rtsopts 0, 1, 2, goodbye! app-rtsopts.exe: thread killed app-rtsopts.exe: warning: too many hs_exit()s
--install-signal-handlers はデフォルトでは yes。
タイミングによる。
$ app-rtsopts +RTS --install-signal-handlers=no 0, 1, 2, goodbye!
$ app-rtsopts +RTS --install-signal-handlers=no 0, goodbye! app-rtsopts.exe: thread killed app-rtsopts.exe: warning: too many hs_exit()s
$ app-rtsopts +RTS --install-signal-handlers=no 0, 1, 2, goodbye! goodbye! app-rtsopts.exe: thread killed
想定通りの動作。
$ app-threaded 0, 1, 2, goodbye! app-threaded.exe: thread killed
想定通りの動作。
$ app-rtsopts-threaded 0, 1, 2, 3, goodbye! app-rtsopts-threaded.exe: thread killed
想定通りの動作。
$ app-rtsopts-threaded +RTS --install-signal-handlers=no 0, 1, 2, 3, 4, 5, goodbye! app-rtsopts-threaded.exe: thread killed
タイミングによるときの動作。
ハンドラーが2回呼ばれるときは killThread も2回呼んでいるはずなので、その後がおかしくなることはありそう。また killThread しているが、それは自分自身ではないのかの確認もしたい。
System.Win32.Console.CtrlHandler とか GHC RTS を追うしかない気がするので追ってみます。
GHC RTS はこの辺（rts/win32/ConsoleHandler.c）からかなぁ。
Ctrl-C 等の割り込みの扱い方です。
System.Win32.Console.CtrlHandler を使います。
Ctrl-C が押されたらクロージングの処理を伴って終了するプログラムを書いてみます。
import Control.Concurrent import Control.Monad import System.Exit import System.IO import System.Win32.Console.CtrlHandler main :: IO () main = do tid <- myThreadId let handler event = do if event == cTRL_C_EVENT then do putStrLn "goodbye!" killThread tid pure True else pure False pHandler <- mkHandler handler success <- c_SetConsoleCtrlHandler pHandler True when (not success) $ do putStrLn "SetConsoleCtrlHandler failed" exitFailure let loop n = do putStr $ show n ++ ", " hFlush stdout threadDelay 1000000 loop (n+1) loop 0
実行してみましょう
> runhaskell Main.hs 0, 1, 2, 3, 4, 5, goodbye! Main.hs: thread killed
ちゃんと goodbye と出力されて終了しました！killThread は例外を伴って終了するので Main.hs: thread killed というメッセージが出てしまっています。もし気になるなら例外を握りつぶすか MVar を使って終了を監視する仕組みを作るといいでしょう。
肝心の割り込みを制御する関数は c_SetConsoleCtrlHandler です。
c_SetConsoleCtrlHandler :: PHANDLER_ROUTINE -> BOOL -> IO BOOL mkHandler :: Handler -> IO PHANDLER_ROUTINE type BOOL = Bool type Handler = CtrlEvent -> IO BOOL type PHANDLER_ROUTINE = FunPtr Handler
c_SetConsoleCtrlHandler の第1引数にはコールバック関数（のポインター）を、第2引数には追加時に True を、削除時に False を指定します。
CtrlEvent の値は予め用意されていて下記があります。
cTRL_C_EVENT :: CtrlEvent cTRL_BREAK_EVENT :: CtrlEvent
Handler の返り値は、イベントを処理して次のハンドラーにイベントを伝播させないなら True を、そうでないなら False を指定します。上の例では handler という関数にメッセージの表示とメインスレッドの停止の処理を書いて Handler として渡していました。
この記事は HaskellでCtrl-Cを制御する - Qiita のオマージュです。
runhaskell を使うと確かにこの動作をするのですが、ビルドして実行バイナリーを作ると Ctrl-C を2回打たないと止まりません。原因と背景を説明できる方いませんか？
> stack exec windows-interruption-exe 0, 1, 2, 3, goodbye! goodbye! windows-interruption-exe.EXE: thread killed
あと、Ctrl-Break だとハンドルせず終了するはずだけどしないような……
ちゃんと C のドキュメント読もう。→ 読んだ。理解は合ってそう。（追記）
議論は Haskell-jp Slack で。参加方法はこちら。
