2011-12-29

括弧ゴルフ

折角リーダーマクロを作ったし括弧ゴルフでもしてみるかとやってみた。以下のサイトのルールで。
本当にLispはカッコが多い?
最後にあるLispのリーダーマクロを参考にGaucheのfoldを使ったケースを実装してみた。
#! /usr/local/bin/sash
(set-macro-character #\! (lambda (p c) (read-delimited-list #\$ p)))
! import ! srfi :1 $ $
! fold ! lambda ! x y $ ! print ! - x 1 $ "!= " y $ ! * x y $ $ 1
  ! iota ! string->number ! cadr ! command-line $ $ $ 2 $ $
まぁ、ある意味当たり前だが、括弧8個でいける。
set-macro-characterは本来は(sagittarius reader)をインポートして使うべきだが気にしない。
しかし、これ見てSchemeと思う人はおらんだろうなぁ。

リーダーマクロが動いた

まだ、あまりテストしていないが、簡単なリーダーマクロが動いた。
とりあえず当初の目的の通り正規表現を#/regex/と書ける様にしてみた。こんな感じ。
#<(sagittarius regex)
(import (sagittarius regex))
(define rx #/\w+/)
(print (regex-replace-all rx "abcdef@abcdef" "**$0**"))
もちろん#/regex/ixumsのようにも書ける。
汚いなぁと思うのは#<(ライブラリ)のように書かないとリーダーマクロがインポートされない部分。上記のようなプログラムなら(import)がやっても一緒なのだが、ライブラリが問題になってくるので、こんな風にした。
また、loadしたファイルの影響を受けると意味が分からなくなるので影響範囲はファイル単位になっている。

括弧ゴルフに勝つるツールが手に入った(違

2011-12-23

Linuxでコンパイルさせるためのメモ

tarボールでコンパイルさせるテストの一環。
そのうちソースに反映させるが、忘れないようにメモしておこう。

xubuntu 10.xx(細かいバージョン忘れた)ではapt-getでインストールできるcmakeのバージョンが2.8.3だったので、CMakeLists.txtの先頭行にあるバージョンを2.8.3にしてテスト。

手直しが必要だったファイル:
  • library.c
  • core.c 
  • transcoder.c
  • system.c
  • load.c
  • test-lib.c
  • src/CMakeLists.txt
  • ext/ffi/CMakeLists.txt
library.cとsystem.cはミューテックスの初期化問題。まじめにInit関数でやりましょう。特にlibrary.cはInit関数がないので作成して、core.cで呼ぶ必要がある。
system.cは<io.h>がないって言われたのと、environがないって言われた。<io.h>はcmakeを走らせる際にチェックを追加する。environはどうしよう?見つからない理由が分からない。とりあえず通した際にはextern char **environをつけた。
transcoder.cはcodec内で使ってる名前で怒られた。その名もputcとgetc。こいつらマクロなんだ。知らなかった。あればundefするように変更。どうせ中では使ってないし。ってか、こんな極悪なマクロ作るなよ・・・mix、max並みにひでぇ・・・
test-lib.cはuintptr_tがないと怒られた。&t;stdint.h>をインクルードして解決。
src/CMakeLists.txtはpthreadとdlをターゲットリンクに追加。
ext/ffi/CMakeLists.txtはapt-getでlibffiをインストールしたので、ターゲット名が違った。この辺Cygwin版と比較する必要があるなぁ。

以上をなおしたらコンパイルが通った。意外と自動ダウンロード機能も働いていて、BoehmGCは勝手にダウンロードしてコンパイルしていた。(zlibは既にいたのでそのまま使用していたが)
ユニットテストはなんと肝心なrun-test.scmがtarボールに入っていなかった。とりあえずリポジトリからファイルをダウンロードして走らせる(汗。自宅のxubuntuは非常に非力なマシンで動いているので初回テストはガリガリと音を立てていたが(メモリが少ないのよ)、オールクリア。キャッシュテスト用に再度走らせても問題なかった。大枠の出来は割といい感じみたいだ。
ドキュメントの生成も(テストが通ったので当たり前だが)動いている。
まっさらな状態で一応全部いけるということが分かったのは大きい。

それにしても、非力なマシンにもかかわらずコンパイル時間がCygwinでやるより早かった。VCでnmakeを使ったときにも感じていたが、GCCが遅いのだとばかり思っていた。

バージョン0.2.3リリース

今までextディレクトリをtarボールに入れ忘れていたということに気づいて、今回からはそれらが入ってきます。(ということは今までのtarボールってコンパイルすらできなかったということだろうか・・・試してないからなぁ。今後は試すようにしよう。)

今回のリリースは後の拡張に備えたメンテナンスリリースです。

修正された不具合:
  • ライブラリインラインでマーキングミスがあったのが修正されました
  • bitwise-first-set-bitにbignumを与えた際、不正な値を返すことがあった不具合が修正されました
  • renameエクスポートが正しく動作していない不具合が修正されました
改善された動作
  • 文字セットが組み込みになりました
  • gcdにbignumを与えた際のパフォーマンスが改善されました。メモリの使用量が大幅に減っているはずです
  • 正規表現ライブラリが新たに書き直されました。単純な正規表現でかつ巨大なテキストに対してのマッチングもしくは文字列置換であれば以前のものより高速に動作することが期待できます
新たに追加されたライブラリ
  • パフォーマンス測定用ライブラリ(time)が追加されました。現在のところtimeマクロのみエクスポートされています
Windowsバイナリでテストケースを走らせると失敗するテストが2つあります。base64ライブラリのテストとmimeライブラリのテストです。どちらのライブラリもドキュメント化されていないのですが、使用する際は注意してください。

次はリーダーマクロだ!ほぼ正規表現のためだけに入れるといっても過言ではないが、まぁ気にしない。

根本的な解決ではないが

RSA鍵の作成時に素数チェックにgcdを使用していて、Bignumのgcdが非常にナイーブな実装だったため大量のメモリを使用していた。そこで、binary GCDを実装して、メモリの割り当てが最大で4回になるように実装しなおした。そしたら、前述の不具合はとりあえずなりを潜めたのであった。
(あんまり高速化にはなっていないっぽい。512ビットの鍵ペアを作るのに2秒かかる[Core2Duo 3GHz]。Javaでは109ミリセコンドという、20分の1の時間で生成された。う~む)

Windows版のSagittariusでもそれなりにいけるようになってきたような気はするが、テストを走らせると失敗するケースが1つ増えた。正規表現ライブラリを置き換えたからかもしれない。かなりテストを書いたがまだカバーしきれてないらしい。でもテスト外で同じ正規表現、同じ文字列でマッチさせるときっちりマッチするんだよなぁ。メモリ系だろうか、また・・・。Windows版だけというのがまた痛い。メイン環境じゃないからデバッグがしづらい・・・

とりあえず、「よきに計らえ」と勝手に言い聞かせて0.2.3をリリースしてしまおう。

2011-12-22

バグの原因究明

Sagittariusにはドキュメント化されていないライブラリが結構ある。理由はさまざまで、APIが固定されていないとか、近い将来変更になるのでその後とか、バグが取れてないとか、まぁいろいろだ。
その中の「バグが取れていない」の代表格暗号化ライブラリでどこに不具合があるのかがようやく分かった。
結論を言えば、メモリ割り当ての際にオーバーラップして割り当てているせいで、メモリ破壊を起こしているというものだ。
原因はおそらく2つに分けられるだろうが、1つはBoehmGCがマークミスを起こしている。これは回避しようがないので、あきらめるしかない。もう一つは何らかの理由により、割り当てたメモリが使われていないという状態になり、GCによって回収されている(一緒くさいな・・・)。とりあえず前者っぽい挙動をしている。なぜだ?

今回はどうやって直すかというのではなく、どうやって探したかをメモしておく。場所を特定するのに非常に面倒なバグだったので。

起きた環境:
  • VCでコンパイルしたバイナリ
  • 自宅ノートPCのCygwinでコンパイルしたバイナリ
職場のPCでは起きないという隠密バグ(職場もCygwin)。BoehmGCのコンパイル時フラグかな?
使用したツール:
  • WinDbg
  • GDB
NMakeを使っているので、VC++ Expressではデバッグできなかった(評価版なのでプロセスアタッチできない)。
デバッグ方法:
WinDbgでウォッチ式を指定。地道に起きるまでステップ実行(涙)。WinDbgではウォッチ式をしていしても、人の目で監視しないとだめだった。面倒すぎ。
ある程度特定したのちに、自宅PCのGDBでデバッグ。何が壊れているのか分かっているので、ブレークポイントでその値が設定される場所で停めて、アドレスを確認。以下のコマンドを打つ。

watch *0x{上記で調べたアドレス}
最初、丁寧にキャストして実行したらGDBが終わらなかった。キャストせずに上記のように打つとハードウェアウォッチポイントになるらしく、実行がすごく速かった。っで、たどり着いた先はBoehmGCのmalloc。。。どうしろと?
さて、解決方法でも考えるか・・・

2011-12-20

ベンチマークとって見た

新正規表現ライブラリのテストを書いているのだが、どの程度速く(もしくは遅く)なったのか知りたかったので、比較してみた。
コードは以下
(add-dynamic-load-path "./build")
(add-load-path "./sitelib")
(load-dynamic-library "sagittarius--regex2")
(load-dynamic-library "sagittarius--regex")
(import (rnrs)
 (time)
 (srfi :13) (srfi :1))

(define bench
  '(begin
     (define-syntax bench-regex
       (syntax-rules ()
  ((_)
   (begin
     (define rx
       (compile-regex "[-_.0-9A-Za-z]+@[-_0-9A-Za-z]+[-_.0-9A-Za-z]+" 0))
     (define (repeat s c) (string-concatenate (make-list c s)))
     (define s (repeat "abcdefgh" 500))
     (define m (regex-matcher rx s))
     (define times 20)
     (time (do ((i 0 (+ i 1))
         (r (regex-replace-all m " ")
     (regex-replace-all m " ")))
        ((= i times) r)))))))
     (bench-regex)))

(let ((args (command-line)))
  (if (= (length args) 2)
      (cond ((string=? (cadr args) "old")
      (eval bench
     (environment '(sagittarius regex impl) 'user)))
     ((string=? (cadr args) "new")
      (eval bench
     (environment '(sagittarius regex2 impl) 'user)))
     (else 
      (error 'command-line "unknown option")))
      (print "usage: test2.scm old|new")))
で、結果。
$ time ./build/sash -D./build test2.scm old

;;  9.964000 real    9.890000 user    0.000000 sys
./build/sash -D./build test2.scm old  10.06s user 0.03s system 99% cpu 10.176 total
$ time ./build/sash -D./build test2.scm new

;;  0.013000 real    0.015000 user    0.000000 sys
./build/sash -D./build test2.scm new  0.19s user 0.00s system 96% cpu 0.193 total
Pikeさんパネェっす。
別にこのパターンに特化しているわけではないのだが、Perl拡張正規表現が入ってくると別の話になる。それは一つ前のエントリで書いた通り、VMが遅いけど多機能モードに移行するので以前のものより遅くなる可能性が高い。(というか、多分遅くなる)
ただ、個人的に(後方参照はかなり便利だからちょっと考え物だが)先読み、後読み系やpossessiveマッチはあまり使わないので気にしていない。便利なんだろうけど、そんな込み入った正規表現書かないという理由で。

テストケース整備して、APIを以前のものと同じにしたら0.2.3をリリースしよう。

2011-12-19

ハイブリッドVM(正規表現)

正規表現を書き書き直している最中、RE1とRE2を参考にしたPikeVMでは肯定先読み系はおろかpossessiveマッチさえも実装が困難だということに気づいた。
そこでとりあえず普通に再帰を使って書いてみたら恐ろしく遅かった。
どうしたらいいかなぁと電車の中で考えていたら、「ハイブリッドにしちまえよ」という悪魔のささやきが聞こえたのでやってみた。

どうしたか?
拡張正規表現(ここでは上記の2つ+バックリファレンスを指します)を除いた単純な正規表現のみで記述されたパターンはPikeVMで動かし、えらいごてごてした正規表現は再帰を使ったVMで動かしてみた。
これやるとおそらくpossessiveマッチで書いた方が遅いという不思議現象が起きるがそれは置いておいて、後読み(と後方参照もかな?)を除いた210個の単体テストが通った。遅いVMだと異常に実装が楽だったが、涙が出るほど遅く、PikeVMでは速いけどバックトラック系の処理が書けないというジレンマをまぁ使えそうかなぁと思える程度には解消した気がする。
(それでもJavaから移植したコードの方がまだ多少速い・・・まぁ最適化ほとんどしてないからある意味当たり前なんだけど)

後は後読みと細かいフラグの部分を実装して、APIを実装したら一応完成か。クリスマスまでに間に合うだろうか?

2011-12-16

ふと、テレビを見ていて思ったこと

標題に似合わず英語関連です。

文自体は忘れたが、その中にあった単語「labour」を見てふと思ったこと。
そういえば、上記の単語は自然な感じだが、「labor」と書かれると不自然な感じがする。いや、単に英語と米語の違い名だけで意味は一緒なのだが。っでなんとなく自然に感じるつづりと不自然感じがするつづりを並べてみた。
ちょっとしたつづりの比較
英語米語自然だと感じる方
colourcolorcolor
labourlaborlabour
behaviourbehavior両方OK
favourfavor両方OK
favouritefavoritefavourite
centrecentercenter
theatretheater両方OK
とりあえず思いついたのがこんな感じだった。不思議と「ou」になるのが自然と感じるみたいだが、さすがに「color」はこっちのが自然だ。「center」もまぁどちらかと言えばという感じだが、職業柄どうしてもこっちの綴りになる感じ。そのため、「theatre」はこっちの方が自然。(というか街中で見るのはこっちか、bioscoopeだし)
labourは多分カナダにいたときに見た「labour day」が印象に残っているのだろう。
あと何があるだろう?「z」と「s」かな「analyse」とか。うっかり「s」で書いて、Google先生に尋ねたりしてる。
ヨーロッパなのでCMとか英語よりになるんだろう。実際そうだと感じるし。

どうでも話だった。
そういえば、中学、高校の英語のテストで「centre」って書いたら○もらえるのかね?「favourite」はいけると思うけど、どうなんだろう?

2011-12-15

正規表現実装中

ぶっちゃけ行き詰ったのでちょっと問題点の洗い出し。

出来てそうなこと
  • greedyマッチ
  • non-greedyマッチ
  • スタートとエンドアンカー
  • 単語境界
  • グループ(キャプチャリングとそうじゃないの含む)
  • 文字クラス
出来がやばそうなの
  • 肯定、否定先読み及び後読み
  • possessiveマッチ
やばそうなのもある程度は動いてるんだけど、パターンによっては簡単に無限ループに入る。
例えばこんなパターン
\D(?!123)
っで、"ABC123"を与えた場合、文字「C」にマッチしなければいけないが、マッチしない。また、パターンが
\D*(?!123)
になると無限ループする。(ほとんど出来て無いじゃん!)
原因は幅0を実装しているところにあって、2つ目のパターンだと、文字「A」は「\D」と否定先読みの両方を見る。っで、否定先読み(肯定でも)の条件にマッチすると、次の文字に行かずその場にとどまる(幅0の実装)。そうすると、結局文字列"ABCD123"の先頭から同じパターンを繰り返すので無限ループ突入となる。
っと、ここまで書いてちょっと解決案っぽいのが思いついた。要するに先にマッチしたものがあった場合にアサーションに突入しなければいいのではないだろうか?ちょっと試してみよう。

2011-12-12

ジョークプログラム(sleep sort)

sleep sortなるものを実装してみた。
元ネタはここGenius sorting algorithm: Sleep sort
消えてると寂しいので一応引用。
Genius sorting algorithm: Sleep sort
1 Name: Anonymous : 2011-01-20 12:22
    Man, am I a genius. Check out this sorting algorithm I just invented

    #!/bin/bash
    function f() {
        sleep "$1"
        echo "$1"
    }
    while [ -n "$1" ]
    do
        f "$1" &
        shift
    done
    wait

    example usage:
    ./sleepsort.bash 5 3 6 3 6 3 1 4 7
2 Name: Anonymous : 2011-01-20 12:27
    >>1
    Oh god, it works.

    But I don't like to wait 218382 seconds to sort '(0 218382)
3 Name: Anonymous : 2011-01-20 12:31
    >>2
    yes the worst case is very big
まぁ、要素ごとにスレッドを止めて終わった順に値を表示するだけ。
Sagittariusで書いてみた。append!が破壊的かつSRFI-18をサポートしてる処理系なら何でもいけるはず・・・
(library (sleep-sort)
    (export sleep-sort)
    (import (rnrs) 
            (srfi :1)
            (srfi :18))
  (define (sleep-sort lst)
    (let* ((new (list '()))
           (threads (map (lambda (e)
                           (unless (integer? e)
                             (assertion-violation 'sleep-sort
                                                  "integer required but got" e))
                           (make-thread (lambda ()
                                          (thread-sleep! e)
                                          (append! new (list e))
                                          e)))
                         lst))
           (r (map thread-start! threads)))
      (map thread-join! r)
      (cdr new))))
こんな感じで使う
(import (sleep-sort))
(print (sleep-sort '(5 4 6 2 8 9)))
;; => (2 4 5 6 8 9)
上記のコメントにもある通り、最悪時間(というか計算時間?)は要素内の最大値になるので、馬鹿でかい数値だと10分くらい返ってこないとか普通にありえるので要注意。(ソートが終わらないから仕事ができないという言い訳にはなるけどw)

追記:
びっくりするくらい2番煎じだった件・・・ scheme(gauche)でもsleep-sort

英語に対する感覚

前に英語で書いた記事にコメントが付いていた(スパム扱いされていたので気づくのに遅れた)。
これはそのコメントを読んでちょっと気になったことについて。

前置きとして、批判的な意味合いはまったく無く、コメントやご指摘がいただけるのは非常にうれしいことだと考えています。もしここから以下を読んで不快に思われたらごめんなさい。ということで一応分けてみる。やたら長くなったし。


2011-12-11

Inside of Sagittarius: Library system

I am not sure whether somebody is interested in this topic or not. However if there is someone who is hesitating to use Sagittarius because he/she does not know about inside. (Well, I just wanted to write something about Sagittarius in English, sorry)

The reason why I am writing this article is Sagittarius has a little bit different library system comparing with Ypsilon and mosh. (Sorry, I don't know about other implementation) Those two implementations does not have real library system, as far as I understood it has more like just alpha-conversion. So you can not operate or explicitly call any library with it. On Sagittarius, however, libraries are also a first class object. So you can actually do something with it. (I have no intention to make its APIs public, though). Because of this, Sagittarius has sort of namespace. (The same symbol can be bind to different values in different libraries).

What is the good things of it? Unfortunately, I can only say one good thing with it which you can re-define existing value somewhere in the library somebody wrote. So you can even patch the libraries which is written in C. Well, this is actually not so secure, however it is very convenient for debugging. (I used this behaviour to debug macro expansion.)

How is it implemented? It is actually really simple. The VM has library table which is created in Scheme or C and hold it to make sure no duplicated library exists. And library itself has a hashtable and some meta information. The hashtable's key is symbol and value is gloc. Gloc is sort of handle for bindings.

What is the *bad* thing of it? Well, I don't like to write this answer but every implementation have good/bad things and user must know it. Because of this library behaviour, Sagittarius can not have explicit macro expansion phase, so all for import keyword will be ignored. And because of this, (could be because of my insufficient skill), Sagittarius' syntax-case can not compromise a few R6RS requirements.

Sagittarius is still under developing however it has already a lot of useful libraries (maybe not documented yet...). If you like the idea and want to try R6RS implementation, why don't you try it?

2011-12-08

コードをいじっていない

一応、1週間の休暇中でコードを触らないと決めたので触っていないのだが、アイデアは出そうなので取り留めないことをメモしておこう。

正規表現書き直しについて
マッチが既存のものより3倍程度遅いが、これはひょっとしたらマッチさせるたびにメモリの割り当てが3回発生してるからかもしれない。なので、現状マッチさせる際に作成しているコンテキストをマッチャー作成時に初期化して再利用したら高速化されるかもしれない。これでなお遅かったらなんだろう?
Possesiveマッチとか後方参照とかどうしよう?RE2はサポートしてないんだよね。パーサーはCL-PPCREを参考にしたので、その辺対応してるのに、VMは対応(まだ、だといいな)してない。考えないと。

リーダーマクロについて
これは実装手順になっていくのかな?現状ではまぁ普通にスイッチ文で一文字ずつ見ている。次のリリースもしくはその次位には細かく分けられたリーダーを用意して都度プロシージャーを呼び出すようにする。ただし、Cで実装されたものを単純にapplyすると遅そうなので、それは直接呼び出すようにする(引数さえ調節可能、ってかVMはそうしてるし)。その後、リーダーマクロ用のテーブルにマクロのセットを足してディスパッチするようにしてやる。ユーザー定義のリーダーマクロはそこができてから実装するようにする。多分、文字の登録もしくはディスパッチャ(2文字)の登録になるはず。CLの実装も確認しておきたい。xyzzyのソースを読む必要があるか?
(まずはCLのリーダーマクロをいじってみろという話もあるが・・・)

CLOSについて
これは0.3.0くらいに入れたい機能だが、実装方針をとりあえず立てておきたい。ソースが結構大きくなっているので、少しずつ置き換えるというのが難しいかもしれないが、最初は即値クラスから実装(fixnum、文字、boolean、etc)。一気に置き換えるなら現状のタグを消してコンパイルかけて一つずつつぶしていくという地味な作業になるだろうか?気になるのはタグの11ビット以降を利用しているもの(文字列とか)。別にフラグを構造体に持たせる必要がでるのか、現状のようにヘッダー内でなんとかしてしまうか悩むところ。
クラス階層として、文字列、ベクタ、バイトベクタをシーケンスクラスのサブクラスにしようかはちょっと悩むところだが、ハッシュテーブルとツリーマップはディクショナリクラスのサブクラスにしたいところ。
総称関数は多分後回しにできるので、先にクラス構造を入れてしまいたい。
まずはTinyCLOSのソースを熟読するところから始める必要はあるだろう。

もし何方かSagittariusを使っていて、こんな機能がほしいってのがあったら是非教えてほしいですm(_ _)m

2011-12-05

Reader macro preparation

Since I want to add CL like reader macro to Sagittarius, I have been thinking how. I think I had a solution for it so I'm going to memorise it.
Since R7RS draft has been released 4 times and it has different reader macro for bytevector (blob in R7RS or also bytevector?), I need to switch readers between R6RS and R7RS. By default, it can be both, but if user (for now only me...) explicitly specified the mode with shabang #!r6rs or #!r7rs, it should enable or disable some R6RS or R7RS specific reader macro. Well, it is actually easy to just switch with current solution (currently I just see the flag of it and check). But it's not so smart when R8RS or R9RS appears.
So, I'm thinking to add reader macro sets to VM and for future even libraries. The concept is really simple, I just need predefine reader macros for R6RS and R7RS it can be shared its implementations and when #!r6rs or #!r7rs appears switch the set. For this purpose, this behaviour must be per file like current shabang and by default it should have everything (just my preference)
How to do it? The point will be 2 or more letters reader macro such as #vu8(...) or #u8(...). I am thinking I will add 2 sets to VM. One is one letter reader macro and other one is 2 letters reader macro and 2 letters are high priority (or else bytevectors will be invalid vector syntax ...)
Well, I wrote about reader macro however first of all I need to finish replacing regular expression library...

LA行ってきた

今回はバカンスではなく、仕事の面接ということでダウンタウンがメインだった。面接の結果はまだ出ていなく、ボールは向こうが持っている状態。ただ、ボールがもしこっちに来た際には決断をしなければならない。いく前は割りとLAに行こうかなと思っていたのだが、今は揺れている感じ。
いくつか理由がある。良いところと悪いところ両方。少し頭の中をまとめていこう。

良い点
  • まず間違いなく給料があがる。それも下手したら3倍くらい。
  • うちの彼女がアメリカに行きたがっている(NYCなので東海岸だが・・・)
  • ビザを出してくれるアメリカの企業はほとんどないので、次はないかも
悪い点
  • アメリカにいるのに日系企業で日本のコミュニティにいたら、なんか違う。
  • 生活面ががらりと変わる。特に気候とか。夏場40度もあるって聞いたから多分融ける。
  • RX-8は諦める必要がある。(持っていくのが不可能に近い)
  • IT系でも今やってる分野からかなり離れるので次を考えたときに不安。
  • あのLA訛は慣れるのに時間掛かりそう。
大きな部分を占めている順に書いてみた。悪い点が多いのだが、よい点の一番上はかなりでかい。悪い点の下2つは割りとどうでもいいしw
良い悪い関係なく揺れる点ももちろんいくつかあって、それらも含めて考えないといけない。正直人生の岐路としてはかなり大きいので、ボールがこっちの来ないまま「あの時は残念だったね」なんて言っていた方が楽かなぁとも思ったりする。優柔不断な性格には結構きつい・・・

2011-12-01

LAに到着

着陸アプローチが2回あったり、空港が停電してたりとあんまりろくなことがなかったが(機内食のチキンカレーは旨かったか)、無事LAに到着。
思っていた100倍でかい街でちょっとうろたえていたり。あまりにでかすぎて既にオランダが恋しいというチキン野郎。

何故ここにいるのか、(しかも独りで)、実は面接を受けに来ているのです。そう、ひょっとしたら(また)移住するかもしれない。オランダ気に入ってるので、給料の額面とか次第ではあるけど。(まだ決まってない)
自分自身こんなに国を転々とするとは夢にも思っていなかった。本当どこでこんなイベントフラグ立てるんだろう?
どうでもいいが、LAの人の英語が聞き取りずらい・・・オランダ訛に慣れすぎたか・・・