読者です 読者をやめる 読者になる 読者になる

ブログっ...!

自分についてのメモしかないので、見る価値がないよ。(人に説明する思いやりが皆無に近いよ。)

Unicodeでつまずく

プログラム書いてると、目視すれば明らかにあっているのに、予想したような答えにならない!てなことはよくある。
だいたい、自分の不注意。

しかし極たまにその「だいたい」に例外的に当てはまらないときがあって、
一例として日本語文字列操作のとき。

今日自分がTAをやっている授業で、emacsを使う生徒にそういう類の災難が。
「"… で … “ = ”… で … “ が false にevalされる。なんで??」
と困っている生徒。

emacs上でevalしても、
ターミナル上のOCaml対話モードで実行しても同じ結果。

ぐっ、これはUnicodeのアレがアレでこうでは…

こういういわゆる汚い部分は実は去年結構聞いたことがあった。
(汚いと言っては失礼かもしれない、けど実際汚い。)

数学やってるときに、「レジスタにこの数字を mov してー」と言わない。
日本語話すときに、「その発音を文字コードに書きあらわすとー」とか言わない。
まるで数学の式を書くようにプログラムを描きたいし、喋るように日本語をpcに打ちたい。
そんな願望を叶えるため、裏方でわっせわっせと汚い部分と触れ合っているお方がインターン先にいらっしゃった。

実際自分もインターン初期頃に bidi 関連の小さいバグを直していて、
そしてインターン先で初めて気づいた。
「あらゆる言語を表示すんのって、大変なんだな…」
初めてそっちの話を聞いたときは、あまりにも日常にない会話だったので目眩がした記憶があるw
まあ実際、私もそのときになるまでそのへんの汚い問題は知らなかった。
先代(?)が標準作ってわっせわっせ綺麗に隠蔽してくれてたので、
そんな汚いところは知らず平和に生活をしていたわけである。
(汚い汚い連呼してすみません。。)

しかし、先に戻って、このエラーである。
「"… で … “ = ”… で … “」
一体どうしてこの右の「で」が「で」ではなく「で」になってしまったのかわからないが、
で (\u3067)
で (\u3066\u3099)
この見た目が同じ「で」っぽく見える二つが混在してたのが原因。

ばびぶべぼ
(\u3070\u3073\u3076\u3079\u307C)

ばびぶべぼ
(\u306F\u3099\u3072\u3099\u3075\u3099\u3078\u3099\u307B\u3099)

う、う、、

/(>__<)\

結合文字つかった濁音つきの文字は、
後ろにカーソルキー合わせて delete キー押すとその結合文字だけ消えるし。
前方の文字に結合しているから、カーソル移動させても2つ飛ばしになるし。

emacs で、結合文字使った濁音を入力する方法あるんだろうか。
(外部からのコピペではなく、素直に入力して)
一体この「で (\u3066\u3099)」どこからきたのか、結局わからなかった。

私もエディタ作らないと、この類の問題には触れ合えないきがするぞ。。
しかし、下の参考にした3つ目のサイトも言っているが、ページ内検索すると 「で (\u3067)」「で (\u3066\u3099)」どっちもハイライトされてるのが微笑ましい(^ - ^ ))にこにこ….

見た:

Text Escaping and Unescaping in JavaScript

Unicodeのgrapheme cluster (書記素クラスタ) | hydroculのメモ

日本の文字とUnicode 第3回 | 大修館書店 WEB国語教室

久々に

これは久々の更新である。三ヶ月ぶり。

何をやってもうまくいかない日、そう錯覚してしまう日、 何のやる気も起きない日、 やる気はあるが「やることがたくさんある」と思うと始まりが億劫になる日。。

こうやって忙しさにかられない生活をのんびり送っていると、 そういうパッとしない日の数が多くなったように感じる。

ベッドから出るタイミングを逃し、空腹に我慢できなくなると、漸く立ち上がる。
パンにケチャップやチーズ、バターや砂糖をかけるのも面倒くさい。でもちゃんとかける。
何も考えたくないので、オーブントースターの扉越しに焼き目がつくまでの過程をひたすら観察。
食べる。
まだお腹が減っている。
次はパンにマヨネーズをかけて焼く。再び観察。
食べ終える。
すると、喉が乾いてくる。

水を飲むのはあまり好きではないのだけど、まあ飲んでみる。
水道水一杯。
そういえば、パンの食感がぱさぱさしていた。買って2週間たったパンだった。
いい加減、仕事をしなくてはと、pcに向かう。

いや、これが不思議なことに全く!全く何もする気が起きない。
ツイッターを適当に流し見て3時間経った。頭がパッとしないのでよし風呂に入ろうと、今湧かしたところ。 朝起きてお風呂に入ろうか、でも面倒だ、という葛藤(?)を六時間経ての快挙である。

頭の中のもやが風呂に入って少し薄くなるといいのだが。
極端に言えば、「19 + 19の計算に10秒かかる」(これはただの例だけど)
いつも行う簡単な作業が、明らかに時間がかかる。
出た答えにも自信が持てない。やもすると、どのように導いたのか忘れる。

昨日、一日中「寄生獣」という漫画を読んでいた。
物語を読む人には、考察好きな人、主観で入る人、キャラクターの個性を見る人、様々だと思うけど
自分は圧倒的に物語に入り込むタイプ読み方をする。

人間の周囲に見えないカメラが浮かんでいるイメージ。
連続したコマの間に省略されたシーンも頭で補正して、滑らかに動かす。
人物の移動した距離、その世界で経った時間も含め、
並行して違う場面で生活するそれぞれの人物をなるべく考える。
各ワンシーンに対して思考を巡らし、疑問を持つようにする。

(しかし、これは作品による。
読者の想像を掻き立てるような構図のセンスや展開がなければ保たない。 )

この読み方の場合、バトル漫画(私は寄生獣をバトル漫画だと思っているが…)だと、
入り込めれば入り込めれるほど(それほど素晴らしい作品であるほど)、
休憩を入れずに一気に読み進め読み終えたときの疲れというのは、もう凄まじい。
現実と物語の区別がつかなくなる。

良い作品であるほど、疲れる読み方だと思っている。

んで、寄生獣はすごく良かった。素晴らしかった。 今日疲れている理由はそれじゃないかな。

読み終えて頭がボーッとしているというのに、 もう一度あの物語の世界に入っていたくって、朝方まで、1巻から10巻の最後まで再び読んだ。

あー、なんだが。
すごく一服したい気分だ。

お風呂入って少しはさっぱりしたけど。
どっちつかずのまま、中途半端な世界でぼんやりするのは。

良い漫画を読むといつも死にたくなる。

まなび1

トライ木の話になった。
トライ木って、人工知能の辞書とかの恐ろしく大きいデータのためのデータ構造だと思っていたのだが。

私はほぼ毎日と言っていい程、このトライ木にお世話になっていたらしい。

以下はMakefileの一例。
all : foo.exe
foo.exe : foo.o
gcc foo.o -o foo
foo.o : foo.c
gcc -c foo.c -o foo.o

MakefileのこのA : Bという記法は、Aの生成にはBが必要という意味。
make Aとやれば、Aが生成される。
$ make
は make all の略。

この各々のファイル (func.o, func.cなど) は
C言語がコンパイルされて実行可能になるまでの流れ - にょきにょきブログ
で丁寧に説明されている。

foo.c から foo.exeに至るまで、

foo.c --cpp--> foo.i[-E] --cc1--> foo.s[-S] --as--> foo.o[-c] --ld--> foo.exe [-なし]

こんな過程がある。
・cpp : Cプリプロセッサ
・cc1 : Cコンパイラ
・as : アセンブラ

(A)「 --cpp--> --cc--> --as--> 」部が gcc がやっているもの。 gccのことをコンパイラだと思っていた今までだったが、実は「コンパイラドライバ」 コマンドを実行していろいろなツールを動かす役目。 clangは (A) 部をまとめて行うため、コンパイラと呼んでよいらしい。

foo.c
int main() { puts("hello"); }

foo.sを生成すると、アセンブリ語がこんな感じで並んでいるイメージ 左はアドレスだと思って

foo.s

a ラベル 命令
0 main: push hoge
5 call _puts
10 ret
12 hoge: .string "hello\0"

foo.sからfoo.o間はアセンブラの仕事。 上記の例だと、hogeが示すアドレスは一体何かを具体化する。hoge は 12 に置換されるイメージ。 ファイル内で閉じてアドレスの解決を行うために、並列作業が可能である。(.oを作るまではマップ並列)。 たとえfoo.c, bar.c の中に依存関係があっても、ファイル内で閉じていた解決なので。 この時点ではputsのアドレスはまだ解決されない。 プロトタイプ宣言はされているが、実体は定義されていない。 (他のファイルでputsが定義されている場合はリンカのお仕事、この場合はlibcの関数なので後のローダのお仕事) これ以降はローダのお仕事。

リンカは規格の決まったヘッダーを用意する。
ELF, Mach-O (object file format) $ file file.o で見るとよい。
-------
|header|
-------
| text |
-------
| .data |
-------
| .rel |
-------
まだ解決されないアドレスを rel に載せ、relはtextを参照する形になっている。

一方、libcも同じ過程を経て、リンカに渡る。 リンカは puts は アドレスA, printf は アドレスB, ... みたいな巨大な参照関係を示したトライ木を作成し(Mach-Oの場合. ELFはハッシュ)、それをローダに引き渡す。 libc.so/ libc.dylib

ローダーは「実行時になるまでわからないメモリのどこか」にプログラムが配置された後、 これによって決定された実際の(?)アドレスを各ファイルに教えて、参照関係を再びただす。

実行時には各ファイルのアドレスが依存するために、ローダーの作業を並列化しても高速化は望めないらしい。 リンカもリデュース。

てふぅ...

mac ports にて tex live をインストールした。 とくに問題は起きなかったけど、一応メモのために。

texlive @2016 (tex) TeX Live metaport

$ sudo port selfup
$ port variants texlive

TeX Live/Mac - TeX Wiki ここでいうフルインストールは、おそらくfullオプションのことかな。 (very large!)とか書いてあるけど、、(実際大分時間かかった)

$ sudo port install texlive +full

tex live をインストール エラー。

Error: org.macports.activate for port texlive-context returned: Error: Failed to install texlive-context Please see the log file for port texlive-context for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_tex_texlive-context/texlive-context/main.log Error: The following dependencies were not installed: texlive-context ....

ログファイルをみる。

:info:activate dyld: Library not loaded: /opt/local/lib/libpixman-1.0.dylib :info:activate Referenced from: /opt/local/bin/texlua :info:activate Reason: Incompatible library version: texlua requires version 35.0.0 or later, but libpixman -1.0.dylib provides version 33.0.0

リビルドが必要なよう。 libpixmanをアップデート。

$ sudo port -n upgrade --force libpixman

-n はいろいろ結果を出力するのをやめてくれるオプションぽい。

MacPorts Guide ProblemHotlist – MacPorts

時間をかけてtex liveをインストールしたはいいが、後にmac texのほうが幸せそうだと気づいた。(あほすぎる) homebrew で楽々インストールできるらしいので、

$ brew update
/usr/local/Library/Homebrew/cmd/update.sh: line 36: safe_cd: command not found Initialized empty Git repository in /Users/name/.git/ fatal: No path specified. See 'man git-pull' for valid url syntax

updateスクリプトのsafe_cdコマンドが定義されていない...

brew/update.sh at master · Homebrew/brew · GitHub シェルスクリプト弱者なので、このsafe_cdコマンドが一体どうやって定義されているのかわからない。。

brewコマンド全てが効かなくなっていることに気づく。

/System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby: No such file or directory -- /usr/local/Library/brew.rb (LoadError)

調べたらすぐに解決策がでてきた。
mac でbrew がおかしくなった(brew updateができない)のを解決 - Qiita
$ cd /usr/local
$ git reset --hard && git clean -df

(これ、ある程度自分で原因を特定してから、実行すればよかったと後悔。おかげで本来の原因がなんだかわからなくなってしまった。時間がなくて急いでいたのもあり、残念だ)

$ brew update
error: The following untracked working tree files would be overwritten by merge: .... Please move or remove them before you can merge. Aborting Error: Failure while executing: git pull --ff --no-rebase --quiet origin refs/heads/master:refs/remotes/origin/master

Error: Failure while executing: git pull --quiet origin refs/heads/master:refs/remotes/origin/master · Issue #49006 · Homebrew/legacy-homebrew · GitHub

$ git fetch && git reset --hard origin/master
git fetch && git reset --hard origin/master error: unable to unlink old 'bin/brew' (Permission denied)
fatal: Could not reset index file to revision 'origin/master'.

$ sudo git fetch && sudo git reset --hard origin/master
HEAD is now at 755be9a Merge pull request #1659 from dersvenhesse/patch-1

すると、.gitファイルが消滅した... エェ このコマンド実行で消滅するのは意味がよくわからない。 この一連の作業で自分に失望。 もうこんな原因追求しない解決策をとるのは気持ち悪いので、有意義に時間があるときにやるべきことだと反省した。

Homebrewを一度アンインストールした。 とはいってもディレクトリを消去しただけ。 再度インストール。その後、

$ brew update
Error: Could not link: /usr/local/share/doc/homebrew Please delete these paths ... と言われた。

$ rm -rf /usr/local/share/doc/homebrew

あとはこれに従って、mactexをインストールした。 MacでTeXを使おう(brewで最短5ステップ)

ちなみにこの消滅した.gitのリモートレポジトリは GitHub - ambientwanderer/homebrew: The missing package manager for OS X. 再インストール後のリモートはこれだった。 GitHub - Homebrew/brew: The missing package manager for macOS

これについてはよくわからないので、後日調べるとする。 homebrewの一度目のインストール、二度目のインストールも同じやり方でやったはずである。

くそぅ。。

かっこいいMakefile使いになりたい。 パッケージマネージャと仲良くなりたい。

このまま仕組みをしらないままとはまずいなぁ。 別のOCamlのバージョンを使いたい用があったので、 opam switchで切り替え、再び元のバージョンに舞い戻ったんだが、

File "none", line 1:
Error: Error on dynamically loaded library: dlljs_of_ocaml.so: dlopen(dlljs_of_ocaml.so, 138): image not found

js_of_ocamlのdllがないと言われてコンパイルできなくなった。 (今まで長らく幸せだったので、混乱する私) とりあえずこうした。

# sudo ln -s /usr/local/bin/js_of_ocaml /opt/local/lib

「では、もう一度...」

# make

_人人人人人人人人人人人人人人人人人人人人人人人人人人人人_

File "none", line 1:
Error: Files main.cmo and ../fuga/hoge.cma(Hoge)
make inconsistent assumptions over interface Hoge

 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

「」

make cleanを挟んだらうまくいった。 Hogeモジュールのファイルは特にいじってないのだがはて。

dllのエラー直前まで完了した仕事を継続して再開すると、 新しくない/正しくないファイルとの古いdependent関係も使い回されるとかで発生するエラーなのか(適当)

make ... 勉強しよう... (⌒-⌒)ニコニコ...

検索してたらこんなのが出てきた。。
>>>
どっから始めるのがよかですかねぇ....

stackoverflow.com

くずのつぶやき

すごく好きな作品の作者との会話を思い出した。

私「なんでこんなの作れたんですか?」
A「毎日朝から夜まで作業する。周囲の馬鹿にする声は気にせず、悩んだら寝て起きたらまた始める。」
私「なぜ自分はこんなことをしてるか意味は考えたりしない?」
A「考えないですね」

そういう人間になれたら人生様々な可能性がある、かっこいいし羨ましい。
人を感動させることもできる。
残念ながら自分とは無縁の能力だと思った。

私のように時間を無駄に使うこともない。
人生何もしないには長過ぎる。
精神の健康のためには(生きることの意味を自分の中に留めておくためには)、何かをすることが必要だ。 それができない。

「なぜしなくてはいけないの」
そういう下らない問にやる気をなくして、考えることさえ放棄する。
いつまでも自分の心動かすものを待っている。 いつか、自分の可能な限りの時間を全てつぎ込むほど夢中になれるような何かがくるのを待っている。

まあ、でも言ってしまえば、なんてダサい人間なのだ。 頭ではわかっているんだけど、ねえ。。

「なぜしなくてはいけないの」
という問に万人が納得できるような答えを与えられる人はまずいない。
まず、そういう解答は存在しない。
自分の思考世界で閉じるような(自己満足できるような)理由ならば存在するが、それは一歩その人の思考世界から離れてしまえば効力を失う。

だから理由がほしいのならば、自己完結するしかないのだ。
そして自己完結させるには何かしらの思い入れがないといけない。
例えば、「xxするのが好き。」「自分にはxxしかない。」とか。
思い入れが思い込みに発展し、理由となって、執着になる。
この思い入れを生成するには、まず「何かを始める」しかない。

なのに、始める前から「なぜやらないといけないの」と言って、理由がないからはねつける。

自己完結できる人は、「他人がなんと言おうと自分はこう思うのだ」と強い意志をもって日々の時間を積み上げ、そしていつか成し遂げて、その集中力や執着心や熱意の結晶とも言える完成品で人々に感動を与える。
その姿のなんとかっこいいこと、羨ましいことか!!

まあ、ようするに暇なんだな。
あるいは「本来なら忙しいはず」なのに、逃げていて、時間が無駄にあるんだな。
日々作業に終われ、忙しく走り回る生活ならば、理由が定かでなくても「やらなくては」となるのだ。

退屈は一番の病だと脳化学の先生が言っていた。

「ではやればいいんじゃん」と言われても、やろうという気分にならない。
それでも前にはいくつもの課題があって。
速く片付けなければいけないのに、やろうとするとすぐに集中力がきれ、別のことを始める。
一度好奇心がつくと、寝ないで作業することもあるが、ほんとにごくたまに。

人間やることがないと、意味を失うから死にたくなるのだ。
生きる意味を考えることをせっかく放置したのにこのざま。
あー、ださい。

楽して死ねるボタンがあるなら今すぐ押してしまいたい。
または、感情や意識を失くしたい。

ネズミを見に行った

すごかった。

イソターソ先の社員さんにこの大会の動画を見せてもらった8月。 当時は、その動画を見てゲラゲラ笑っていただけだった。 どう実装されているのか、とか仕組みを特に考えず、 ただ、いくつも並ぶ駐車場(トラップの行き止まり)に丁寧に一個ずつ入っていくネズミがアホらしくてひたすらに面白かった。 壁にがつがつ当たるネズミを見て、ランチ中に爆笑したのを覚えている。

全国大会が11月にあると聞いた。ので決勝だけ行ってみた。

これ、すごかったwww 思った以上に熱があがった。 会場一致で
「おおーー!!(歓喜)」
「ああーー!!(残念)」
「おおーー!!(感動)(拍手)」
と、選手とともに一喜一憂するのは、スポーツ観戦のようだった。

そして生で見ると、不思議に思うことがどんどん出てくる。

・ネズミと相性がよく、かつ最短路である経路を探す
・物理運動とソフトウェアの組み合わせ、誤差とか
(内がもつ情報と、外(物理上)の情報の差、大変そう。電気工作やったことない人間なので...)
・座標をどうとっているの
・まがり角を極力減速せずに曲がる人すごい
ジェネリックに迷路をどう認識しているのか
(迷路には多種のトラップがあり、しかしトラップに見せかけた正解路もある。 例えば駐車場トラップに特化したような対策をとってしまうと、偽トラップに柔軟に対応できなくなるんじゃ。)

聞くと、座標についてはタイヤの回転・角度で求めているらしいが、スリップすることがあると、座標を誤って保持してしまって誤動作しがちらしい。 座標が狂うと、内情報では壁がないはずなのに、壁にぶつかったりしてしまう。(そうするとだいたいリタイヤ)

しかし、上位のほうになっていくと、スリップも含めた補正を効かせているらしい。 この辺、意味わからないが... レベルの高い人はねずみの重さを思い切り削減するため、その誤差の補正もすると。

決勝は予選の順位の低い人順にだいたい出場してくるので、終盤に近づくにつれ、みんなヒートアップ。

こじネズミ (こジマさん)、ふぁんとむ (まツイさん)、が一番印象に残っている。 最も自分と相性の良い、最短経路を一、二度の探索で見つけてしまう。 この二体は、もはや背伸びをしなくては見えない(ほとんど壁で見えない)(特にこじネズミのほう)。 直線距離が一番得意なこの二体は、一見すると遠回りに見えてしまう経路をあえて選び、 最後の一直線でとんでもなく加速する。 凄まじかった。。

結局一位をとった人(前年の優勝者、予選の一位(つまり決勝のオオトリ))は速度パラメータを最大にする前に最高記録を出してしまった。 「一位になることが決まったら、使おうと思っていた最大パラメータがあります。」 とラスト走りで、披露。全速力なのに、どこにもぶつからず、完走。
これが再び決勝最高記録になった。
これが最高に盛り上がった。
パフォーマーとしても、すごかった...

結論。すげえ楽しかった。 スポーツ観戦みたいだった。 しかも、不思議&感心する部分が多いので、絶えず考えているため、見ていて飽きない。

社員さんが、大会後、PRに来ていた社会人の人を紹介してくれた。(ありがたい)
そこにハンダ付けから行うメカネズミキットがあった。 ちょうど初めて見たかったし、買うか!となるも、 げえええ!高え!46,000 wwwww

ちょっと衝動買いするには学生には辛い。

また次回にしよう。
(しかし、そうなると、数年のスパンでやらない可能性が出てくる。。なるたけ早めに。。)

すぐ近くに解説してくれる方がいてありがたかったし、
おかげでよりいっそう楽しめたと思う。
本当にありがたかった。
メカ可愛いと思った。ミニ四駆してえ。
ジャイアンに没収されそうだが。。

じゃ(^^)ノシ