多言語を扱う際のメンタルモデル

NetflixでDeath Noteを見ていた際に「L is dead」というメッセージが見えた。Lが実際に死んでからしばらく時間が立っているので、実は他にも「L is alive」等のメッセージが存在し現在のLの状況を伝えたという感じだったのだろうか。

「Death」「die」「dead」は全て英語で死を表すがそれぞれ、名詞、動詞、形容詞（または副詞）になる。北斗の拳の有名な台詞の一つである、「お前はもう死んでいる」は英語にすると「You are already dead」になる（と思う）が、「You are dying」 にはならない。もし上記のLの死亡を伝えるメッセージが、Lの現在の状態を表すものではないのであれば「L has died」の方がいい気がする。

形容詞としての「dead」対応する日本語の単語は存在するのだろうか？形容詞として「死んでいる状態」を表す単語というのを実は知らない。複数言語（といっても三つだけだが）を扱えるようになると、言語Aにはあるが言語Bに対応する単語がないということがままある。例えば「おにぎり」をずばり表す英訳や蘭訳はない気がする。逆に、蘭語の「beleg」のズバリは日本語にない気がする。（そういえば「忖度」という言葉の訳はドイツ語にズバリで「vorauseilender Gehorsam」とか「unausgesprochene Anweisung」とかいうそうだ。）

多言語を扱う際にはこういった「ある言語にはある概念」を扱う必要がでてくる。二言語だと言語Aで考えて言語Bに翻訳するみたいになる気がする。これが面倒になると最初から言語Bで考えるという風になる気がする（余談だが、この状態になると、酔っ払っていても言語Bで会話できる）。僕はこの状態で言語Cが入ってきた。言語Cの習熟度は他の二言語に比べると遥かに低いのだが、不思議なことに言語Cで話しているときは言語Cで考えているのである（もちろん、足りていない部分は先の二言語で補っているが）。これは一体どういうことなのだろうか？

思考という部分は置き換え可能なパーツでできているとすると割と理解できる動作なのかぁという気がする。脳内モデルが「入出力-思考-抽象概念」みたいな三層でできているとするのである。二言語を扱っていた最初期では「思考」の部分が母語になっていたが、これが徐々に第二言語に置き換えることが可能になった。そして、新たに覚えた言語は基本的な部分ができるようになると、置き換えの動作がスムーズにいき、習熟度が低くても置き換えられるようになったと仮定できる。

なんかこういったのを何度もブログに書いてる気がするなぁ、なんでだろ？自分のメンタルモデルを言語化するのが好きなのかね？

MSYS2サポート 2

前回の続きと僕なりの回答。

前回MSYS2上でのシンボリックリンクの話とSagittarius上でどうするかというのを書いた。書いた後に助言やMSYSがどのようにシンボリックリンクを扱っているかというののヒント(調べた結果Qiitaの記事が古いのか現状の挙動と違った)をもらったのでそれを踏まえて実装してみた、という話。

【MSYS2上でのシンボリックリンク】

 MSYS2上ではシンボリックリンクはデフォルトでは作られず、ファイルのコピーとなる。この挙動を制御するためには環境変数MSYSを適切に設定する必要がある。2018年現在では以下の表のようになる。

値	挙動
winsymlinks winsymlinks:lnk	ショートカットを作成する。 MSYS2上からはシンボリックリンクとして見える、かつWindows上ではショートカットになる。
winsymlinks:native winsymlinks:nativestrict	シンボリックリンクを作成する。 Windows上でもシンボリックリンクになるが、管理者権限またはWindows 10かつDeveloper modeである必要がある。 失敗した場合は単にコピーになるか、作成されない。
上記以外 未設定(デフォルト)	ファイルをコピーする。

ソースも確認したのでこれであっているはず。ちなみに上記はsymlink(2)の挙動なので、ln -sは多少違うかもしれない(たぶんあってると思うけど)。

【Sagittarius上ではどうしたか】 

シンボリックリンクの作成を失敗したくないというのが大前提としてあったので、最低でもショートカットにフォールバックするようにしたかった。ということで、Sagittarius上では以下のフローでシンボリックリンクの作成をする。

1.  環境変数のチェック
1. コピー以外のいずれかならばsymlink(2)を使用する
2. コピーならばWindows上のシンボリックリンクを試す
2. ファイルが作成されているかチェック
1. 作成されているなら終了
2. 作成されていないなら、環境変数MSYSにwinsymlinks:lnkを設定し#1へ 

(Windows上のシンボリックリンクを試す必要ないかもしれないなぁとこれ書いてて思ったので、ファイルチェック→環境変数セット→リトライのフローだけにするか。)

とりあえずこれで、create-symbolic-link手続きがMSYS上では何かしらシンボリックリンクっぽいものを作成することになる。いつも思うがサポートする環境を増やすときはこうい環境特有の workaround が必要になるの辛い。

MSYS2サポート

Sagittarius 0.9.0からはMSYS2が実験的にサポートされる。実験的と書いているのは単にまだ安定しないのと、他のPOSIX環境と多少挙動が異なる点があるというところからである。挙動に関しては積極的に変えていく可能性があるので、WindowsかつMSYS2を使っている方がにフィードバックを送ってくれると反映される可能性が高い。

MSYS2という環境はCygwinに比べるとWindowsとの互換性を重要視したPOSIXエミュレーターに見える(あまり使っていないのでぱっと見の感想)。現状で一番困っているのはシンボリックリンクの扱いで、例えばPOSIXのsymlink(2)は必ず失敗する。失敗してエラーを投げられると困るので、現状はシンボリックリンク関係の部分はWin32APIのCreateSymbolicLinkを使って凌いでいるが、このAPIは管理者権限を要求するので普通にSagittariusを起動して使用すると失敗する(何も作ってくれない)。

個人的にWindows上で使うPOSIXエミュレータを以下の理由からMSYS2に乗り換えようかなと思っている：

• プロセスの作成が失敗しない
• メモリの制限がない

この二つは結構重要で、最近書いているこれはプロセスを多用するからである。そうすると上記のシンボリックリンクが問題になってくる。

代替案としては

• ショートカットを使う
• ハードリンクとジャンクションポイントを使う

一つ目は割と茨の道で、理由としては.lnk拡張子がネックになる。二つ目はボリューム跨ぎができない、ジャンクションポイントは絶対パスが必要になるとう結構制限がある。

個人的には管理者権限を要求してもいいかとは思うが、もしそれができない状態かつMSYS2上でscheme-envを使いたいという状況が出てきた場合に困りそうである。いろいろな意見がほしいところである。

TLS実装2（完）

Sagittarius上にビルトインなTLSを実装し終えた。POSIXな環境（Linux、OSX）ではOpenSSLをWindowsな環境ではSchennal、CygwinとMSYS2上ではあればOpenSSL、なければSchannelを使うという感じになっている。

今までPure SchemeだったのがCでの実装になったのだから性能にもなにかしら影響があるだろうと思ってベンチマークを取ってみた。

意外にも有意な差がない。Schemeの性能が高いんだと喜びたいところだが、以下のような理由だろう：

• 暗号、復号及びMACは元々Cでやられている
• TLSパケットの送受信は上記がメイン
• （おそらく）OpenSSLはスタックの破棄みたいなセキュリティ上のオーバーヘッドがある

元々ビルトインにしようと思ったのは別の理由からなので、あまりおまけを期待しすぎてはいけない。よりセキュアになったということにしておく。

一応2月のリリースには間に合ったということで。

TLS実装

Scheme環境ツールでTLS実装をOpenSSLかSSPIに切り替えると書いて、実際にそうしているのだが、SSPI（正確にはSchannel）の実装が辛い。何が辛いか？

• ドキュメントが飛び飛び
• MSDNにAPIの説明はあるんだけど、フローの説明がない
• 例えばX.509証明書と秘密鍵をメモリ上から読み取り、紐付けるということが（今のところ）ドキュメントから読み取れない
• サンプルが少ない
• Schannel SSL辺りでぐぐっても片手で数えられるくらいしか見つからない
• それらのサンプルもあんまり使い込まれてないらしく、普通の用途しかサポートしてない
• X.509証明書はファイルから読むとか
• だめならSchannelでセルフ署名を作るとか

OpenSSLの実装は例も多く（逆にドキュメントがしょぼい気がする）割と簡単にいったので「これはSchannelもスムーズに行くのでは？」という淡い期待があったのだが、シャボン玉より簡単に弾けた…

これこの後後方互換を保つとかの作業もあるのだが、2月のリリースに間に合うのかね？不安になってきた。

Mingwサポート

Ubuntu上でもWindows用のコードをコンパイルしたいと思いMingwのサポートをしてみた。実際にMingwでコンパイルされたバイナリを動かしていないのでコンパイルできる以上の意味を今のところ持っていない（そのうちCIでは回すようにしたいが、優先度的には多少低め）。

とりあえずMSVCとの非互換な部分は大きく以下：

• struct timespecが存在する
• .ccファイルをC++として認識する(と思われる)
• Boehm GCのコンパイルで困らされた
• __tryと__finallyがない
• __try1と__except1はうまいこと動かない
• リンカがエラーを投げる
• なので今のところ代替手段なし…
• 細かいライブラリの名前が違う、かつ#pragma commentは動かない
• ws2_32とか

これら以外は大きなコードの変更もなくコンパイルできた（動いたとは言っていない）。

Twitterで「移植性を考えたらC言語を使うしかない」というのをみたが、C言語を使ってかつ多大な努力を払わないと移植性なんて得られんなぁ…同じWindows上のバイナリを作るのにもこれだよ。

上記にもあるが、コンパイルできるだけで動くとは言っていないので、Mingwの環境がある方だれか試してくれないかなぁ（ﾁﾗﾁﾗ Issue上げたりPR送ってくれたりするとなお嬉しいなぁ（ﾁﾗﾁﾗ

Scheme環境ツール

各種Scheme処理系をある程度便利に使いたいと思い、こんなんを書いている。なんでそんなことを思ったかというと：

1. タイムゾーンなSRFIを書こうかな
2. ポータブルな実装がいるよなぁ
3. 処理系を簡単にスイッチできないかなぁ ← これ

完全にYak shavingである。今時かどうかは知らないが、目標としてはインストール不要の完全オンデマンドみたいなのを目指している。なので、READMEにも書いたがこんな感じでインストールかつ使用できる。

$ curl https://raw.githubusercontent.com/ktakashi/scheme-env/master/bin/install.sh | sh
$ export PATH=$HOME/.scheme-env/bin:$PATH
$ scheme-env install chibi-scheme
$ scheme-env switch chibi-scheme@master
$ scheme-env run

これでChibi Schemeをソースからビルドしてかつ使用可能にしてくれる。ソースからビルドするので、各処理系が要求する依存関係は予めインストールされている必要がある（流石にそこまで面倒見れない）。ちなみに最初のShellスクリプト以外は全部Scheme（Sagittarius）で書かれている。

今のところインストール可能な処理系はChibiとSagittariusだけだが、すぐにGaucheや他の処理系もサポートされる予定。

動作環境はUbuntuを想定しているが、ホスト処理系（Sagittarius）の要求するパッケージのインストールをしないのであれば、 他のPOSIX環境でも動くはず（自信ない）。Cygwinはプロセスを多用していることもあって多分無理(誰かこの問題直して…)。MingwサポートしてMsys上でとかかなぁ。

ここからはどうでもいい話なのだが、実はこれを作ったおかげで0.9.0のリリースが大分遅れることになった。理由は以下：

•  Ubuntu上でHomeが暗号化されているとC Assertで落ちる
• キャッシュファイルのPATHが長すぎるのが原因だけど、そのままだとあまりに不便
• (rfc tls)でbitbucket.orgに繋げられない
• TLS 1.2実装の問題
• 流石に温かみのある手作り実装に疲れてきたのでOpenSSLやSSPIに切り替える

1つ目は直したんだけど、2つ目が流石に時間がかかる。OpenSSLは楽なんだけど、SSPIがねぇ。まぁ、来月くらいにはリリースできるんじゃないかなぁくらいの気持ちではいるが、さて。

リストの作成

こんなツイートをしたが、どう書くかというのは示してなかったので(iPhone上からだったので)、せっかくだしブログのネタにしようという話。

(append L (list ...)) となっているところは cons + reverse に書き換えられる気がする。O(n^2) が O(n) になるからかなり性能に響くはず。 https://t.co/f14prELLP7

— Kei (@tk_riple) 4 January 2018

リストの生成方法にはいくつか方法があるが、今回は有名どころを二つ書いておく。
【cons + reverse】
cons + reverseはまぁよく使われるパターンで、この名前で呼べば大体どんなものかの想像がつくくらいだ(と思う)。ツイートで言及しているQiita記事にある手続きfをこのパターンで書き直してみた。

(define (f/cons+reverse init n)
  (let loop ((i 0) (r init))
    (if (< i n)
        (loop (+ i 1) (cons (tent_func (car r)) r))
        (reverse r))))

nthが何をしているものなのかよくわからなかったが、おそらく(nth -1 L)はリストの最終要素を取り出すものと予想。(そのように実装して元の手続きを動かしたらそれっぽい値返したし。)
これだとappendがなくなるので、O(n^2)がO(n)になる。一時リストの生成が嫌ならreverse!を使えば生成されるリストもたかだか一個になる。
doで以下のように書くこともできる。

(define (f/cons+reverse init n)
  (do ((i 0 (+ i 1)) (r init (cons (tent_func (car r)) r)))
      ((= i n) (reverse r))))

どちらがいいかは好み次第。
ちなみに、reverseがないので保留と言われた(記憶、Twitter上で見つからん)のだが、reverseはこんな風に書ける。

(define (reverse l)
  (do ((l l (cdr l)) (r '() (cons (car l) r)))
      ((null? l) r)))

RnRS準拠の処理系なら絶対持ってるはずだが、自作の処理系だったという可能性も踏まえてみる。 (積極的に無駄な処理をするコードを直していくスタイル)

【unfold】
Schemeの標準にはないが、SRFI-1 (R7RS-large)にはunfold という手続きがある。これを使うと上記は以下のように書ける。

(define (f/unfold init n)
  (unfold (lambda (x) (< (car x) 0))
          cdr
          (lambda (x) (cons (- (car x) 1) (tent_func (cdr x))))
          (cons n init)))

こっちは多少メモリ効率が悪い(シードの生成に必ずペアを作ってる)し、unfoldの使用方法が多少変則的な感はある。

ループ内で(append result (list ...))みたいなコードを見つけたら積極的に書き換えていきたいところである。

日付と時間 その２

前回の続き

Shiroさんの案では calendar 自体が （y, m, d, H, M, S) の組を持つというもので、SRFI-19 の date は （y, m, d, H, M, S) + timezone というもの。っで、 calendar の種類は複数あって、例えばグレゴリアン歴の2018年1月8日は D = (2018, 1, 8, 0, 0, 0)だけど、これと同等のユリウス暦は2017年12月26日 D = (2017, 12, 26, 0, 0, 0)になる。更に、それぞれの calendar が時間の演算を持つというもの。例えば calendar A では一日が30時間だとすると、その calendar における日付B+1日というのは Gregorian calendar では1日と6時間を足したことになるが、この差異を calendar がよしなにしてくれるというもの。（意図を正しく理解していれば）

個人的には非常に可搬性が高く、火星に行っても火星用の calendar を作成すれば使えるいいアイデアだと思うんだけど、地球上でプログラムをするのであれば、RFC3339で定義されている時間で概ね事足りると思ったりもする。（まぁ、宇宙開拓史みたいなゲームを作って火星のカレンダーが必要だみたいなのはあるかもしれんが、レアケースと割りきってもいいよね？）

そうするとこんな感じで簡略化するとよくね？という気にもなる。
日付 D = (y, m, d, H, M, S)
カレンダー C
タイムゾーン TZ
として、日付Dは常にRFC3339で表現できるものとする。日付の演算はデフォルトでは以下のようにできる：
D+1d = (y, m, d+1, H, M, S) = (y, m, d, H + 24, M, S) = ...
カレンダーCは例えばユリウス通日等の計算や、そのカレンダー上での一日を日付D上に加算するのに使ったりするこんな感じ。

(calendar:days->date calendar:julian 0) ;; -> D(-4714 11 24 12 0 0)

タイムゾーンTZはまぁ、普通にタイムゾーンで、SRFI-19の date は D+TZ になる。

目を凝らすと日付Dは (y, m, d, H, M, S) + RFC3339 と言えなくもなく、デフォルトの演算は calendar Crfc3339 によって提供されるものとも言えるので、多少の利便性だけとも言えなくもない。じゃあ、最初からそうすればよくね？という気もしてきた。う〜ん。

日付と時間

日付や時間はプログラムを書く上で鬼門になりがちなものである。例えば、2018年1月4日11時10分と言った時に、この時間は常に同じ時間を指すだろうか？答えはNoである。例えばオランダと日本では別々の時間になる。同一時刻を指すようにするにはタイムゾーンの指定が必要になる。

Schemeには日付と時間を扱うSRFIがある。SRFI-19である。多くの場合はこのSRFIで事足りるのだが、局所時間を扱う際にこまることがある。例えば上記の日付をタイムゾーンを気にせず表せない。

;; これはエラー
(make-date 0 0 10 11 4 1 2018 #f)
;; これは常にUTC
(make-date 0 0 10 11 4 1 2018 0)
;; これだと常にUTC+1:00、夏時間どうする？
(make-date 0 0 10 11 4 1 2018 3600)

とりあえず全ての日付はUTC+0にして扱うという手もあるのだが、バッチ処理を日付が変わるときに行うというようなことが面倒になる。また、このSRFIには日付のみ、時間のみを扱う術がない。例えば11時15分という時間と(make-date 0 0 15 11 0 0 0 0)は等価か？あるいは2018年1月4日は(make-date 0 0 0 0 4 1 2018 0)と等価であるかということである。答えはケースバイケースであるとは思うが、多くの場合はNoではないだろうか？

Javaは1.8からjava.timeというパッケージが導入された。これは上記のようなジレンマを解決してくれそうな雰囲気がある（使ったことないので未確認）。Sagittariusにもこれと似たようなものを入れるべきかなぁと考えている。こんな感じでの階層だろうか？

+-------+   +-------+
| date  |   | time  |
+---+---+   +---+---+
    |           |
    +-----+-----+ 
          |
    +-----+-----+   +-------------+
    | date-time |   | zone-offset |
    +-----+-----+   +------+------+
          |                |
          +-------+--------+
                  |
       +----------+----------+
       | offsetted-date-time | <-- SRFI-19 dateと等価
       +---------------------+

時間が常にローカル時間かというのはわからないので、offsetted-timeみたいなのもあっていいかもしれない。timeだと名前が被るから別名にする必要も有りそうだが。

ちょっと考える必要があるが、割と早めに導入したい気持ちもある。

追記
Shiroさんのアイデア

で、日付によらない時間(H,M,S)の演算をclockと考えよう、と思ったんですが、calendarにH,M,Sを持たせても良い気がしてきました。7時間の5倍を35時間と扱うか1日と11時間と扱うか、も同じものの表現が複数あると考えればいいし…そうするとsrfi-19 dateはcalendarのD=(y,m,d,H,M,S)の正規形+TZですね。

— Shiro Kawai (@anohana) 4 January 2018

これを使ってSRFI-19を実装するとすると、Calendarは3つ必要になりそう。(たぶん)Gregorian、JulianとModified Julian。内Julian calendarとModified Julian calendarは要らんかもしれんが、あると綺麗っぽい。これを踏まえると以下のようにするといいだろうか？

                  +------------+
                  |  timezone  |
                  +------------+
                  | - Offset   |
                  +------+-----+
+------------+           |
|    date    |           |
+------------+           |
| - timezone |<>---------+                  +------------+
| - calendar |<>------------+               | date-tuple |
+------------+              |               +------------+
                 +----------+----------+    | -(Y,M,D)   |
                 |      calendar       |    +-----+------+
                 +---------------------+          |
                 | - YMD: date-tuple   |<>--------+
                 | - HmS: time-tuple   |<>--------+
                 +---------------------+          |
                                            +-----+------+
                                            | time-tuple |
                                            +------------+
                                            | -(H,m,S)   |
                                            +------------+

calendarは演算手続きの集合にして、こうした方がいいだろうか？

+--------------+                                  +------------+ +------------+
|   calendar   |                                  | date-tuple | | time-tuple |
+--------------+                                  +------------+ +------------+
| - operations |                                  | - (Y,M,D)  | | - (H,m,S)  |
+------+-------+                                  +------+-----+ +------+-----+
       |                                                 |              |
       |             +-------------------+               |              |
       |             |     local-date    |               |              |
       |             +-------------------+               |              |
       |             | - YMD: date-tuple |<>-------------+              |
       +-----------<>| - calender        |                              |
       |             +-------------------+                              |
       |                                                                |
       |             +-------------------+                              |
       |             |     local-time    |                              |
       |             +-------------------+                              |
       |             | - HmS: time-tuple |<>----------------------------+
       +-----------<>| - calendar        |
                     +-------------------+
                              :
                            so on
                              :

どっちもしっくりこない感じがするなぁ。もう少し考える必要がありそうだ。

謹賀新年

年末年始を病院で過ごしていたのでいわゆる「今年を振り返って」みたいなのが書けなかった。（僕自身が病気ではないです、後は察してください）

昨年はいろいろあって、一年が長かったのか短かったのかよく分からない状態である。少なくとも去年の１月に何をしていたのかは全く思い出せない。引っ越しがあったのでそれに記憶の大部分を取られている気もする。

今年の抱負と目標：

• ジムに週二で通う
• 割と毎年言ってるなぁ
• Scheme関連のブログ記事を週一で書く
• 習慣にすればなんとか行けるかなぁ
• 最悪「Sagittariusの中身」とか書きだせば…
• 今作ってるWebアプリを公開する
• モチベーションが落ち気味なので宣言しておけば嫌でもやるだろう

あんまり関係ないけど、転職も考えていたりする。完全リモートワークOKならオランダ国外でも問題ないです。

95%の人は満足するけど残りの5％は不満を持ち得るシステムの5％に入ってしまった件

表題が示す通りなんだけど、そんな境遇に陥った。

今の会社に入って1年半たつのだが、買収があったりして給与システムの大幅な見直しみたいなのがあった。今までは、なんとなく評価された人が昇給されたりボーナスがあったりみたいな超おおざっぱな感じだったんだけど(特に決められたルールがなかった)、スケール制(ランク制？)みたいなのが導入されたり、固定値のボーナス(オランダ的には13ヵ月目ともいう)が導入されたりしてきた。

これだけ見ると改善があって、透明性が増したからいいじゃんなんだけど、導入されたシステムには頭打ち もあって、あるランクで最高額に到達したら昇給が発生しないのである。この状態で昇給するにはランクアップするしかない。僕はこの状態であるという通知を受けた。一応満額まで数パーセントあるように見えるが、微妙な曖昧性があるので、満額と言われてもおかしくない状態。

っで、現状ではランクアップの方法は不明かつシニアエンジニアとして雇われているので、この職責上でこの上ってなんになるんだろう的なのもある。

周りの反応を見るに、この状況にある被雇用者は本当に少数っぽくて、ちょっと話を聞いていただけだと、普通評価でも毎年3～4％の昇給が望めると喜んでいる人の方が多いくらいだった。いままで昇給のルールすらなかったのだから気持ちは分かるが…

このシステムが導入される際に一応プレゼンがあったんだけど、そこで言われたのが、「頭打ちになった際にはランクアップするために別のポジションに着く必要があるが、社内にそのポジションがなかったら社外で探すしかない」という旨の言葉だったりする。こういう状況の人間が発生することは分かっていたうえでのこの発言＋特に救済(現状の職責より1ランク高いものを割り当てておくとか)をしなかったのは潔いなと思う反面、いま開発者が去るだけで入ってこない状況を軽めに見てるのかなぁとも思ったり。(もしくは僕は穀潰しとみなされているか、それはそれで悲しいが…)

今週のどこかで昇給についての面接があるらしいので、ランクアップの可能性があるのかないのか聞かないとなぁ。可能性0ならしょうがない、次の職場をまじめに探すかねぇ。

プログラミング言語Schemeの学び方

これに触発されてみた。
調簡易なHTTPサーバーをR7RS＋SRFIで作ってSchemeを学ぼうという話。スライド145にある項目をとりあえず列挙

• Socketの扱い
• 正規表現
• リソースの開放
• 並行処理
• 文字列の扱い

【Socketの扱い】
Scheme標準にはないのでSRFI-106を使う。サーバーSocketはこう作る。

(define server-socket (make-server-socket "8080"))

そして、こんな風に待ち受ける。

(let loop ()
  (let ((socket (socket-accept server-socket)))
    (loop))

特に何もしないソケットがリークしまくるサーバーの出来上がり。

【正規表現】
Scheme標準にはないのでSRFI-115を使う。HTTPリクエストの最初の一行をパースする正規表現はこんな感じで書ける。

(define first-line
  '(: "GET" (+ space)
      (-> path (: "/" (+ ascii))) (+ space)
      "HTTP/" (: num "." num)))

こんな感じで使う

(cond ((regexp-matches first-line line) =>
       (lambda (m)
         (let ((path (regexp-match-submatch m 'path)))
           ;; get the content of the path
           ))))

サブマッチに名前は付ける必要はないが、あるとわかりやすい。

【リソースの開放】
Schemeに便利な汎用リソース開放構文というのはないので、都度用途に合わせて作ったり標準にあるものを用いる。例えば、ポートの開放はclose-portを使い、call-with-portを使えば、正常処理後にはポートを閉じてくれる。Socketの開放はsocket-shutodownやsocket-closeを用いる。
サーバをであれば、以下のようなものが便利に使えなくもない。

(define (finish)
  (close-port in)
  (close-port out)
  (socket-shutdown socket *shut-rdwr*)
  (socket-close socket))

inとoutはソケットポートである。

【並行処理】
Scheme標準にはないのでSRFI-18を使う。SRFI-18はプリミティブなスレッドとミューテックスしか提供しないので、高度なものが必要であれば自分で作る必要がある。
投げっぱなしスレッドは以下のように作れる。

(thread-start! (make-thread (lambda () (handle-request socket))))

処理系によってはスレッドの作成は高価な場合があるので、可能であればスレッドプール等は作っておきたいところ。R6RS処理系かつSRFI-18をサポートしているのであれば、拙作の(util concurrent)が使える。

【文字列の扱い】
スライドにあるような便利なものはない。連結したければstring-append等を使う必要がある。文字列操作は高価な場合があるので(例：参照にO(n)かかる)、使える場面ではポートを使いたいところ。

さて、上記全てを踏まえて非常に簡易なGETリクエストのみに対応したHTTPサーバは以下になる。R7RSではバイナリポートと文字ポートは分かれていて、処理系によっては厳しく分けてあつかう(特にR6RS/R7RSな処理系、Sagittariusなど)ので、I/Oの部分がどうしても煩雑になる。例えば、出力の際には文字列を一旦バイナリに変換している。

(import (scheme base)
        (scheme write)
        (scheme file)
        (srfi 18)
        (srfi 106)
        (srfi 115))

;; Assume all ASCII
(define (read-binary-line in)
  (let ((out (open-output-string)))
    (let loop ((b (read-u8 in)))
      (case b
        ((#x0d)
         (case (peek-u8 in)
           ((#x0a) (read-u8 in) (get-output-string out))
           (else (write-char (integer->char b) out) (loop (read-u8 in)))))
        (else (write-char (integer->char b) out) (loop (read-u8 in)))))))

(define (handle-request socket)
  (define in (socket-input-port socket))
  (define out (socket-output-port socket))
  (define first-line
    '(: "GET" (+ space)
        (-> path (: "/" (+ ascii))) (+ space)
        "HTTP/" (: num "." num)))
  (define (finish)
    (close-port in)
    (close-port out)
    (socket-shutdown socket *shut-rdwr*)
    (socket-close socket))
  (define (http-error status e)
    (define message (string->utf8 "Not okay"))
    (report-error e)
    (write-bytevector (string->utf8 "HTTP/1.1 ") out)
    (write-bytevector (string->utf8 (number->string status)) out)
    ;; laziness...
    (write-bytevector (string->utf8 " BOO\r\n") out)
    (write-bytevector (string->utf8 "Content-Type: text/plain\r\n") out)
    (write-bytevector (string->utf8 "Content-Length: ") out)
    (write-bytevector (string->utf8
                       (number->string (bytevector-length message))) out)
    (write-bytevector (string->utf8 "\r\n\r\n") out)
    (write-bytevector message out)
    (finish))
    
  (guard (e (else (http-error 500 e)))
    (let ((line (read-binary-line in)))
      (cond ((regexp-matches first-line line) =>
             (lambda (m)
               (let ((path (regexp-match-submatch m 'path))
                     (bout (open-output-bytevector)))
                 (guard (e (else (http-error 404 e)))
                   (let ((file (string-append "." path)))
                     (call-with-port (open-binary-input-file file)
                       (lambda (in)
                         (define buf (make-bytevector 1024))
                         (let loop ((n (read-bytevector! buf in)))
                           (write-bytevector buf bout 0 n)
                           (when (= n 1024)
                             (loop (read-bytevector! buf in))))))))
                 (write-bytevector (string->utf8 "HTTP/1.1 200 OK\r\n") out)
                 (write-bytevector (string->utf8 "Content-Type: text/plain\r\n") out)
                 (let ((bv (get-output-bytevector bout)))
                   (write-bytevector (string->utf8 "Content-Length: ") out)
                   (write-bytevector (string->utf8
                                          (number->string
                                           (bytevector-length bv))) out)
                   (write-bytevector (string->utf8 "\r\n\r\n") out)
                   (write-bytevector bv out)
                   (finish)))))
            (else (http-error 403 #f))))))

(define server-socket (make-server-socket "8080"))

(display "Starting server on port 8080") (newline)
(let loop ()
  (let ((socket (socket-accept server-socket)))
    (thread-start! (make-thread (lambda () (handle-request socket))))
    (loop))

もう少し簡単に書きたいと思ったら、Sagittariusに付属している(net server)を使うか、拙作Paellaを使うと簡単にHTTPサーバが書ける。後者はサーバというよりはWebアプリが簡単に書けると言うべきか。

スレッドの軽量化

Sagittariusはスレッドの作成が重い。理由は至って簡単でスレッド毎にVMを複製するからである。あまり気にするほどスレッドを使っていなかったのだが、最近（というか昨日）Paellaに非同期的なのを入れた際にこれはまずいと思いだした。何がまずいかというと、Paellaに入れた非同期構造は、サーバーからソケットの管理を外した後にスレッドを作ってその中でリクエストを処理するというものだからだ。つまり、スレッドの作成の重さがそのままボトルネックになる。

スレッドの生成で最も重いのはVMスタックを割り当てる部分だと大まかにあたりをつけてはいた。ついでに、VMスタックをCスタック上におければよくね？とも考えてはいた。ずっと思っていただけで実行には移さなかったのだが、ここに来てちと重要になりそうなのでえいや！っと試してみることにした。

スレッド＝VMということはスレッドの寿命＝VMの寿命でもあるので、開始時にスレッドのスタックからVMスタックを割り付ければ問題ないはず。ということでそんな感じのコードを書いて適当なベンチマークを行ってみた。以下はベンチマークのコード

(import (rnrs) (srfi :1) (srfi :18) (time))

(define data (iota 10000))

(let ((threads
       (time (map (lambda (i)
                    (thread-start! (make-thread (lambda () i)))) data))))
  (assert (equal? data (map thread-join! threads))))

スレッドの生成時間のみを測りたいので、こんなに単純。っで以下が結果(環境 Ubuntu 16.04 64bit Intel® Core™ i7-6820HQ CPU @ 2.70GHz × 8):
元のコード

$ sash thread-bench.scm

;;  (map (lambda (i) (thread-start! (make-thread (lambda () i)))) data)
;;  2.626753 real    3.012000 user    0.256000 sys

改良版

$ ./build/sagittarius -Dbuild thread-bench.scm

;;  (map (lambda (i) (thread-start! (make-thread (lambda () i)))) data)
;;  0.239091 real    0.120000 user    0.224000 sys

ちょっと出来過ぎな感じもするが、効果はありっぽい。まぁ、生成数をひとけた減らすと３倍程度の改善になるので、メモリの圧迫が減っただけとも言える（それが目的なのではあるが）。

アクター

メッセージパッシングとも言う。

Sagittariusには(util concurrent)があるのだが、今までこのスタイルのライブラリを追加してなかった。理由としては

• 実装自体はトリビアルであること
• ライブラリにするにはアイデアの練りが足りないこと

の二つが主であった。のだが、あまりにも似たようなパターンを書くので重い腰を上げることにした。以下のように使う。

(import (rnrs) (util concurrent))

(define actor
  (make-shared-queue-channel-actor
    (lambda (input-receiver output-sender)
      (let loop ()
        (let ((in (input-receiver)))
          ;; do whatever with the input
          (output-sender (result)) ;; if output should be sent
          (loop))))))

(actor-send-message! actor 'message) ;; send a message to the actor
(actor-receive-message! actor)

わざわざチャンネルに使われているキュー名が入っているのは以下の理由から

• shared-priority-queueバージョンのアクターもある
• 入力と出力にどんなキューが使われるのか分からないので、make-actorみたいなのにはできない

二つ目の理由からmake-actor手続きは入力と出力を作る手続きを受け取るようになっている。

これをアクターと呼んでいいのかは正直よくわからないが、広義ではアクターモデルだろうということで。

バグ取り

Sagittariusには(net server)というライブラリがあって、それを使うと割と簡単にノンブロッキングなサーバーが書けたりする。このライブラリは(paella)の基盤になっていたりするので、個人的に書くWebアプリは意識の外側にくらいの位置ではあるが使われていることになる。そんなライブラリ+news-reader.nlで使われているということもあってそれなりに安定していると盲信していたのだが、実はそんなことなかったという話。

ことの発端は今書いているWebアプリがある程度走るとCPUを100%使いだすというもの。これが続くと嫌だなぁと思って、モニター機能をつけてみたところ、どうも挙動が怪しい。スレッドを50個作っているのに動いているように見えるのは一つしかない。スレッドにソケットを割り当てるために持っている優先度付きキューもなぜか要素が一つしかない。

結論を言うと3つのバグが複合的に働いてCPU使用率を100%にしていた。

【バグ1】
優先度付きキューの比較ロジックがおかしかった。スレッドにソケットを割り当てるようなので、スレッドIDとそのスレッドが保持しているソケットの数をペアにして持っていたのだが、その比較がおかしく、ソケットの数が同一であれば同一の要素とみなしてしまっていた。そうすると初期化時にすべての要素が同一とみなされかつ、追加時に同一要素を削除しているので結果的に一つにしかなっていなかった。
修正はこんな感じ：https://bitbucket.org/ktakashi/sagittarius-scheme/commits/c52fab262da092a1ca676c9e067798a4c60f610f?at=default

【バグ2】
優先度付きキューに要素を足すときにサイズの取得がロック外だったため最大値を設定しているにも関わらずキューのサイズが増えていた。これ自体はCPU使用率100%に直接関係はないのだが、モニターを作ったときに予定外の値が渡されるので気付いた。
修正はこんな感じ：https://bitbucket.org/ktakashi/sagittarius-scheme/commits/a96c51bd93076ddb5454060b82cc1ed087c681f1?at=default

【バグ3】
Paellaが特定の場合にソケットを閉じていなかった。データ読み取りすると空データを返すソケットを閉じていなかった。これが無限ループを起こしてCPU使用率100%になっていた。Linux上でのみ起きるので気付きにくかったというのはある(言い訳)
修正はソケットを閉じるだけ。

実用に耐えているからといってバグがないわけではないという話である。しかし、今までスレッド1個しか働いてなかったのか、ソケット自体は複数個扱えてたのが災いして気付かんかった。

砂場と模型

Mockの訳が模型でもいいかは自信ない(疑似だと味気なかった)。

プログラミングをしていると、テストをどうするかというので困る時がある。例えばあるコンポーネントのテストをしたいが、それはHTTPサーバを必要とする場合とか。実際に必要となるものによっては簡易版を用意してやるとか手はあるが、ユニットテストレベルでそこまでやる気にならないこともある。そもそも、用意した簡易版の何かしらは正しく動くのかとかも気になる。

Sagittariusではいろいろ黒魔術的な何かを使えばライブラリに束縛された値を上書きすることが可能ではある。っが、これをやるとグローバルに変更されるという問題もある。テストの実行単位が常に単一であるとか、単一スレッドでしか走らないとかにしてしまえばこれだけでも問題はないのだが、数が増えるとそれがボトルネックになるのが見えているのでできれば避けたい。

っと、この辺りまでが最近まで悶々としていた問題。もとになったのは、SchemeでもMockitoみたいなのほしいなぁというもの。そこから可搬性とか考えずに、とりあえず束縛だけ一時的に変更できればなんとかできなくね？というところに至る。っで、悶々としている間になんとかなりそうだなぁと思ったので実装してみた。実装の詳細は面白くもないだろうので割愛。(sagittarius sandbox)というライブラリに実装。使い方は以下：

(import (rnrs) (sagittarius sandbox))

(define s "b")
(define (test) (string-ref s 0))
(with-sandbox
  (lambda ()
    (define-in-sandbox '(rnrs) (string-ref s i) #\a)
    (test)))
;; => #\a

;; (test)
(playground ((string-ref '(rnrs) (lambda (s i) #\a)))
  (test))
;; => #\a

コメントアウトされてるtestのコメント外すと予定と違う値が返ってくるが、既知のバグということで。理由としてはサンドボックス内で作られる束縛は指定されたライブラリのみ作用するけど、上記のtestで使われてるstring-refは(rnrs)が依存しているライブラリの一つで定義されてるので、一回サンドボックス外で実行するとGLOCに置き換わって定義されてるライブラリを直で見に行くから。VM内でGLOCに置き換える部分をもう一段ラップして元の識別子を残すようにすれば解決できるんだけど、性能への影響が怖いのとそこまで需要があるかなぁという気持ちが混じりあってとりあえず保留。性能に影響がでないうまい方法を思いついたらやることにする。

サンドボックスができれば次はモックだということでちゃちゃっと作った。以下のように使える。

(import (rnrs) (srfi :1) (sagittarius mock))

(define (test) (make-list 3 #f))
(let ((status (mock-up ((srfi :1)) 
                (test) (mock-status-of 'make-list))))
  (mock-status-arguments-list status))
;; => ((3 #f))

(mock-up ((srfi :1)) 
  (mock-it '(srfi :1) (make-list . args) '(a a))
  (make-list 3 #f))
;; => (a a)

まだAPIが荒いのでもう少し練らないととは思いつつ、テストに使えそうな感じではある。実装に綺麗い目な黒魔術(絶対にドキュメント化されないという意味で)を多用しているのは、まぁご愛敬ということで。

浮動小数点とC99とSRFI-144と

Sagittarius 0.8.6でSRFI-144をサポートした。このSRFIをポータブル実装を使ってサポートするとパフォーマンス的に得るものが何もないと思いC側でサポートすることあらかじめ決めていた。ネックになるのはこのSRFIが要求しているのがC99の数学関数であることで、Sagittariusでサポートを明記しているVS2010ではC99がサポートされていない。VS2013からはサポートされているので、4年も前の環境だし上げてもいいかなぁとは思ったが、何かの間違いでこのバージョンを使っている人がソースからコンパイルしているという可能性も0ではないかなぁと思い互換レイヤを書くことにした。

互換レイヤ自体はまぁ、普通の苦労で済んだのだが、そこから先が大変だった。Ubuntu 16.04では動くがTravis上のUbuntu 12.04ではテストがこけるとか、VS2013でのCランタイムではテストがこけるとか完全に環境依存の問題に移行したのである。ちなみに嵌ったのは以下：

• VS2013以降のtgammaはアンダーフローが起きると0.0を返すが、Linux(glibc)では-0.0が返る(たぶんどっちも仕様上はOK)
• VS2013以降のynは第二引数が0.0だとNaNを返すが、Linux(glibc)では-inf.0が返る(POSIX見ると第二引数が0.0だとpole errorで-HUGE_VALとあるが、C99が同義かはしらない)
• glibcの特定のバージョン(2.21以下と思われる)ではremquoとlogbが不正な値を返すことがある。(remquoについてはバグレポートを見つけたが、logbは完全に勘。下手するとeglibc固有の問題化もしれない)
• fl-leastはDBL_TRUE_MIN(C11)が割り当てられるので、どのバージョンのVSがサポートしてるか不明

とにかく環境がないということの方が辛く、おとなしくポータブル実装を使っておけばよかったという気持ちに何度もさせられた。また、参照実装に付属しているテストが要求する誤差が結構厳しく、適当な実装だと誤差が大きすぎるというのも苦労した(Windows)。

苦労の甲斐があるかはわからないが、Sagittarius上で浮動小数点を扱う際はこのSRFIを使うとCと同等の速度が得られることだけは保証されるようになった。っが、個人的に浮動小数点はあまり使わないので、自分では有難みを享受できないという悲しい話もあったりなかったりする。

オランダでの収入と支出

ITエンジニアと給料では給料だけにしか触れなかったが、この記事によるとアメリカの一部地域（例：シリコンバレー）では生活コストも高いので世帯年収1200万以下は貧民層となるらしい。生活コストも含めた比較となるとオランダくらいしかできないので、ざっくりとオランダでの生活コストを調べてみた。

生活コスト
日用品等のコストは「Cost of Living in Netherlands」のページが詳しい。基本的には食品はそれなりに安く、家賃は高いという感じらしい。
ざっくりとしたコストとしては「What is the average cost of living in The Netherlands」のページに書いてある。以下は適当な日本語訳したリスト

• 家賃： €800-1000
• 電気、水道等： €150
• インターネット（大抵テレビと電話もついてくる）：€30−50
• 健康保険：€270（3x90 １８歳以下の子供は無料）
• その他保険： €30
• 交通費： €100
• 食費：€100週 （€400月）

合わせると€1780−2000くらい。これに交際費等が入ってくるが、感覚的に妥当な数字かもう少しかかるかなぁというところ（上記だと最低限くらいしかない感じ）。

収入
2016年における一人あたりの手取りの平均収入は€2158となっている（参考： Average Salary in European Union 2016)。平均世帯収入は単純に2倍すればいいだろうか？

以下は2017年の額面における手取り額（日本語ただしいか？）

月収（額面）	月収(手取り)	年収額面
2000	1695	25920
3000	2228	38880
4000	2736	51840
5000	3244	64800
6000	3726	77760
7000	4170	90720
8000	4614	103680
9000	5058	116640
10000	5502	129600
参考:Dutch Income Tax Calculator

年収の算出は月収x12.96になっている（注：オランダでは月8％の休暇手当が義務付けられている）。もちろんボーナスのでる会社もあるので、この年収は月収に対しての最低保証額ということになる。

€2000(上記の生活コスト)＋€1000（ある程度の交際費と貯金）くらいを文化的な生活とすると、世帯収入的には年€50000くらいあれば「中の中」くらいだろうか？累進課税がキツ目なので、収入が一人だと年€61000くらいないと厳しい感じである。

現在位置ユーロ130円なので、世帯収入650万円（一人なら793万円）で「中の中」くらいの生活ができるとすれば、アメリカの1200万円で「中の下」と比べるとましなのかね？ただ、年収€61000を新卒（エントリーレベル）で出す会社は今のところオランダでは見たことないので（というか、これくらいだと既にシニアレベル）、やはり給与面ではオランダはアメリカに比べると塩っぱい気がする。少なくともIT産業に於いては。

引っ越し

7年住んだアパートからの引っ越しが完了した。新居の準備がまだ全部終わっていないが（床のフローリングが一部終了してない等）今週中には終わるだろう。7年も住んでいると普段は気にしなくてもこういう時に物であふれていたんだなぁと気付かされた。引越し業者が荷物の運び出しを完了した後で10箱以上自力で運びだしたりしていた（箱詰めが失敗したとも言えなくないが、細々したものというのは往々にして忘れられがちなのだ）。

オランダのアパートは入る時も出るときも割と面倒である。入るときはだいたい床はコンクリートむき出しの状態、壁紙はあったりなかったり。出るときは以下の状態にして出ろと言われる：

• 床はコンクリートむき出し
• 壁は白く塗ってあること
• 天井も白く塗ってあること
• 壁に開けた穴は埋めること

まぁ、入った時と同じにしろと言われる。ただ、僕の場合は多少特殊で、入った時は「天井が白ければよい」という条件だったんだけど、途中で大家が変わったので「壁も白くしろ」が追加された。なので、受け取った時は青い壁とか、トイレに模様とかあったんだけど、それらを全て白く塗りつぶせという話になった。納得が行かないが、まぁしょうがない。

偶然にも、新しい居住者が入れ替わりで入ることになりかつその人がフローリング、冷蔵庫、洗濯機、オーブン、ベッドフレームを引き取ると言ったのでそれらの運び出し及び廃棄をする必要がなくなったのは幸運だったのだろう。その人にとってもそれらが無料で手に入るのは悪くない条件だと思う。多少汚れてたりしても…（余談だが、フローリングはアパートが広いこともあって総額で2000ユーロ以上かかってたりする。）

新居の鍵の受け渡しから退去までが一週間しかなく、その間に荷出しとかもあったので、非常に疲れる週であった。連日23時くらいまで運び出しと清掃等を行っていたのだが、22時くらいまでは明るいという非常に幸運な時期に引っ越ししたとも言える。これが冬だったら暗闇の中いろいろやることになっていた。

どうでもいいのだが、敷金が帰ってくるまでに2ヶ月かかるってどういうことなんだろう？どう考えても時間かけ過ぎだと思うだが？