デバッガに打ちのめされた

IDE最強

gdbに触れたことはあるものの、積極的に使っていくほどではなかった。

どうせ自分が書くプログラム程度ならprintデバッグで十分だろう、と。

最近ICPCに向けて研究室でもプロコンが盛んになってきている。

ついさっきまでゼミの課題であるTopCoderの問題に取り組んでいた。

最初は単純にどう書いたらいいかわからずウンウンやっていた。

自前で書いたやり方がどうも違う気がして仕方なく蟻本を開いた。

アルゴリズムの書き方はわかったけど、どうにもおかしい。エラーがとれない。

それも何か奇妙な値のとり方をしている。どこか実装をミスったか。

奇声をあげながらTypoを探していると同期がやってきた。

彼には既に「その問題はintじゃあふれるよ」とのアドバイスを受けていた。

変なエラーが治らない、一部だけ通って一部だけ通らない、と助けを求めると、

「longにしたのか、桁あふれしてるんじゃないか」という。

いや、さっきの助言通りlong long intにした、そんなことはないはず。

そう言うと彼は「変数の中身は確認した？ デバッグにVisualStudio便利よ」という。

いや、研究室用PCはMacだし。一応VirtualBoxに入って入るけど(DreamSparkという学生の特権)。

しぶしぶXcodeを使ってみることにした。使い慣れないIDEにものすごく苦労した。

「buildできない。runのボタンがない」「なにそれ(画面を見る)俺の知ってるXcodeと違う」

「ググってもよくわからない(情弱)」「プロジェクト作った？」「え、なにそれ？」「作れ」

想像以上に間抜けを晒してしまった。

でもライブラリやら何やらの依存があるきちんとしたソフト開発ならともかく、

一回問題を通すためだけに書き捨てるプロコン用のコードにもいちいちプロジェクトを作るのは

なんだか無駄が多いような気がしてならない。あまり好きになれない。

プロジェクトなしに生のソースをそのままコンパイルして実行したいのだけど。

あ、ちなみにエラーは桁溢れでした。

まさかlong long intが溢れるとは思ってもいなかった。

結局何から何まで彼の言う通りだった。

脱Emacs? まさか

そんなことがあって、「Emacsでコード書くのやめたほうがいいのかな」と少しへこんだ。

だが、ぐぐるとEmacsとgdbの連携はなかなか悪くないらしい。

周りの人は皆GUIが好きだと言うが、僕はCUIが好きなのでこっちのほうを覚ることにしよう。

とりあえず、まずはprintデバッグからの脱出、というところか。

あとでEmacs+gdbの自作チートシートを作っておこう。

研究資料検索システム

近況報告

研究室に入ってからかなり経った。学ぶことばかりだ。

しかし今年の目標として掲げたアウトプットがおろそかになってしまった。

新しく特殊なキーボードを注文した話とか、そのファームウェアを書き換えた話とかネタはある。

とりあえず今やりたいと思ってることを文章として残しておこうと思う。

研究資料検索システム

現在研究室にある資料、先輩方の残した論文やスライドはきちんと管理されている。

しかし現状の管理では「どこに誰が書いたものがある」がわかる程度で、その中身についてはファイルを開けてみないとわからない。

研究室が持つ資料数年分ともなればその量も結構なものとなる。

長く所属している人ならばどんな内容の資料があるかある程度想像つくだろうけれど、そうじゃない人は必要な情報を探し当てるのに遠回りをしてしまうかもしれない。

というか僕が先輩や先生に「こういうことについて調べたいけど、それについて調べた先輩っていますか？」とかいちいち聞くのが申し訳ないだけだったりする。

と、いうわけで研究室の資料をなんとかして内容から検索しやすいようにできないかと考えている。

計画

  • 研究に関連する主な資料は論文(tex, pdf)とスライド(ppt, pptx)
  • 各データの内容を対象にして検索をしたい
  • 含まれる文字列を抽出していろいろあれこれすればできそう(？)
  • texはテキストファイルと同じで直に扱える
  • pdfからの抽出はツールもライブラリもあるだろうし困らなさそう
  • スライドの2種類が鬼門かと思ったがpythonにライブラリがあるようだ(参考URL)
  • これらから抽出した文字列の中から名詞を抜き取り、ファイルの場所とひもづける
  • ファイルが含む名詞と場所とで索引構造を作り検索できるようにする

できたらいいなと思ってること

参考URL

pythonでオフィス快適化計画 - SlideShare 覚書ブログ: pythonで PowerPointを操作する。

win32.comとかpython-pptが使えるらしい。もっときちんと調べてコードを書きたい。

Pelicanになれる作業

苦労したこと

ともかく疲れた。もうPelican触りたくない。

Pelicanは公式ドキュメントがあるから設定には困らないはずなんだけど、それ以前の問題といったところ。

というか間違えて大事な部分にまで手をいれてしまったせいで一回はブログが投稿できなくなった。

仕方ないので諦めてPelican-quickstartをもう一度やり直した。こんなこと二度としたくない。

この記事を書くのだって二度目だ。一個前の投稿など何回書いたか、という気分。(あくまで気分)

Pelicanに移してまだ2回目の投稿だというのにもう当分したくない。

Pelicanについてわかったこと

  • make serveは連続してできない
  • pythonでエラーが出てもエラーログは役に立たない
  • モジュールとか例外の名前を読んだところで到底解決できない
  • 前後の自分の行動から察せよ
  • かなり柔軟、というか細かく指定ができそう

やること

  • 過去ブログのインポートができるかどうか調べる
  • ブログのカスタマイズ
  • markdownになれる
  • 記事を書く

ドメイン取得の罠

ブログについて
以前からBloggerでの投稿をなんとかしようとしてきた。
もっと簡単に、もっと手軽に。できればMarkdownで書きたい。
Markdown→HTML変換サービスはすぐに見つかった。
だが、Bloggerのスタイルシートの仕様上、これはうまくいかなかった。
じゃあ別ブログサービスに移行しようか、今だとやはりはてなかと悩んでいたところ、
友人がGithubPagesを使ってWebページで遊んでいるのをTwitterで見かけた。
いっそどうせなら、と思い僕もgithub.ioのブログ用リポジトリを作った。
Markdown変換ツールにはPlicanを使うことにした。
静的サイトジェネレーターというらしい。
軽くググったところ、候補としては他にも色々あったが、結局のところRuby,Python,javascriptのどれを使うか、みたいなところだった。
RubyでJekyllとかOctopressとかを使うのもアリだとは思ったのだが、やはりRubyはまだわかっていない気がするので無難な選択肢としてPythonのPelicanにした。

インストールはすぐに済んだ。使い方も難しくない。
ググって出てきたブログとかの通りにやればすぐできた。
gitの使い方を思い出すのに少し苦労した、というかghp-importがよくわかってなかった。
何度か繰り返しGithubへpush。
うん、できたできた。

どうせだからドメインも独自ドメインにしよう。
こういう機会にとっておくと後で何かに使えるかもしれない。いい経験になるだろう。
ということで早速友人に「ドメイン取得サービス何使った？」と聞いたところ「FC2」と返ってきたのでFC2ドメインにて取得。
一応他のサービスとも比較してみたが金額はさして変わらなかった。
それよりも使い勝手とか、身の回りに質問できる人がいるかどうかのほうが重要だ。
そしてFC2にて.comドメインを取得。契約に伴うあれこれに記入して、メール確認。

ようし！ これで独自ドメインが使えるぞ！

→　このウェブページにアクセスできません

ありゃ。
CNAMEを使ってgithub.ioのアドレスからリダイレクト(？)する設定になっていたはずだが、.comアドレスでは表示できないようだ。
試しにCNAMEを消去したところ、正常にブログが表示された。

どうもおかしい。ということで、もう少し確かめてみたところ、ドメイン側でもっときちんとした設定をする必要があったようだ。
FC2の管理ページからDNS設定を行い、digコマンドを使って確認する。
友人2人と自分のアドレスをそれぞれ比較してみる。
すると何故か僕のアドレスだけ反応がない。

ドメイン取得には時間がかかるようだ。

ググった結果、最長で2週間くらい見積もる必要があるらしい。
これから毎日PC起動後にターミナルを開いてdigコマンドを打っては閉じる作業が続く。

How To SLIME

Lisp

SLIME

LispのためのIDE(統合開発環境)、ということでここにある。
詳しくは「SLIME Lisp」などでググってもらえればわかると思う。
Land of Lispを読むにあたって結構便利だということがわかってきたのでまとめてみる。
なお、ほぼググった内容のまとめなので。

あ、Emacsの話です。

インストール

たしか

sudo apt-get install slime

して終わらせた。
.emacsもろくに書かなくて平気だったと思う。

これだけだとあんまりなので、ググって見つけたサイトのインストール方法を拝借してみる。

上記の本家サイトからGithubのページへ行ける。
そこからクローンないしダウンロードしたディレクトリを.emacs.d配下にslimeという名前で置く。
あとは.emacs(or .emacs.d/init.el)に以下を記述。

;; Clozure CLをデフォルトのCommon Lisp処理系に設定
(setq inferior-lisp-program "ccl")
;; ~/.emacs.d/slimeをload-pathに追加
(add-to-list 'load-path (expand-file-name "~/.emacs.d/slime"))
;; SLIMEのロード
(require 'slime)
(slime-setup '(slime-repl slime-fancy slime-banner))

なおこの説明ではLisp処理系にはClozure CLを使っているが、自分の処理系に合わせて変えてもらって構わない。僕のinit.elには”sbcl”で書かれている。

使い方

とりあえずemacs起動してM-x slimeで対話環境(REPL)が出る。
もちろんC-p C-nやC-a C-eなどEmacsキーバインドが使える。
履歴を辿りたいときはC-↑かC-↓でもできるが、M-p M-nを推奨。
大抵ミスるので、そういう時は別ペインに分割されて表示される内容から、選択する数字をタイプする。
例えばこんな感じ。

The variable HOGE is unbound.
   [Condition of type UNBOUND-VARIABLE]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Abort thread (#)

Backtrace:
  0: (SB-INT:SIMPLE-EVAL-IN-LEXENV HOGE #)
  1: (EVAL HOGE)
 --more--

この場合「hoge」という変数はないと言われている。
Backtraceについては特に言わなくてもいいだろう。
エラー周りの処理を吐く、どこの言語でもあるやつだ。
問題はRestartsの方で、REPLを再開するのに3種類の選択肢が用意されている。
内容を読んで0,1,2のどれかをタイプすればよい。

Lispソースから

本題はこちら。
仮にhoge.lispみたいなlispのソースがあったとする。
そのソースをemacsで開いて、SLIMEを起動。
すると以下のことができるようになる。
C-c C-c：関数一つのコンパイル
C-c C-k：ソース全体のコンパイル
C-c C-z：REPL呼び出し
要するにこれらを上手く使いこなせば、ターミナルからのコンパイルだとかプログラム実行だとかにソースと行ったり来たりをしなくて済むというわけだ。
emacsを起動してソースを開いてslimeを起動する。
そうしてコーディングをし続けて、途中でたまにC-c C-cだとかC-c C-zとかで確認すればいい。

いやだが待てよ？ 評価は？ C-jか？(それはelisp)
上記のコンパイル関連はあくまで「関数」に関してのコマンドだ。コンパイルした関数をそのままREPLで使えるという話。
たとえば関数fugaを定義したあと(fuga 10)を評価したい時、いちいちREPLに戻って(fuga 10)とやるのだろうか。
1回ならそれもいいが、もしfugaが頻繁に書き換わる関数だったら？ その度に実行動作を確認したい場合は？
fugaを書き換えてC-c C-cしてペインを移動してM-pで直前の(fuga 10)を呼び出して実行。
そういう手もあるだろう。
でももっといい手がある。上記のコマンドと同じように、ソースの画面からC-M-xで直接評価できる。
これでペインをまたいで履歴を一個戻して再実行、の必要がなくなる。C-c C-cしてC-M-xこれで済む。
正直これの便利さを言いたいがためにこの投稿を書いたといってもいい。
もっと詳しいことは下記の記事とか参考になる。
SLIMEのキーバインド - pattersonの日記
本家本元のマニュアルも一応見に行ったのだけど何故か読む気にならなかった。
表の形にしてあるだけでどうしてこうも読みやすく感じるのだろうか。

まとめ

まずは

sudo apt-get install slime

そして

C-x C-f hoge.lisp
M-x slime

その後は
1.コードを書く
2.C-c C-c & C-M-X
1と2を繰り返す。

参考

モダンCommon Lisp第3回: SLIMEの使い方 基礎編 | ありえるえりあ

Modern Common Lisp: 第5回 SLIMEの使い方 開発サイクルについて

sbcl+slimeの環境を整える - yutoichinoheの日記

StackEditを使ってMarkdown記法の投稿を書いてみた

ブログについて
StackEditを使って<a class="keyword" href="http://d.hatena.ne.jp/keyword/Markdown">Markdown</a>記法の投稿を書いてみた

StackEdit

ここから誰でも使える。
Chrome用アプリと聞いていたがブラウザ関係無しに使えそう。
とりあえずFirefoxとChromiumで使えることは確認した。

テスト投稿

とりあえずググった結果これが一番よさそう。
とはいうもののMarkdown記法を自分が使いこなせているのかといえばご覧の通りである。
まぁブログ投稿と練習を兼ねるということで。

コード確認

とりあえずこのブログで扱うであろう言語を全部確認していく。
 ;common lisp
 "hello,world"
 #python
 print('hello,world')
 //c++
 printf("hello,world");
 #ruby
 puts 'hello,world'
ちょっと面倒だったのでコメントとhello,worldのみ……
んん？ Lispのコメントだけ色づかない？
それともコメントの書き方間違ってる？

機能

基本的にMarkdownエディタとして使える。
2ペイン縦分割でリアルタイムに見れる。
簡単なショートカットキーも対応。(Ctrl＋Zだけしか使ったことないけど)
右上にあるいくつかのボタンに便利な機能がある。
左から順に5つある。
  1. 「Markdown syntax」
    Markdonのアンチョコ
  2. 「Table of contents」
    #とかの見出しで作るツリー構造とか見れる
  3. 「Document statistics」
    文字数、単語数、段落数をカウントしてくれる
  4. 「HTML code」
    HTMLコードを開いてくれる。デフォルトでハイライト(反転)済み。
  5. 「Open in viewer」
    プレビューの全画面表示。元に戻すにはどうしたらいいかと思ったら、左上の#記号を押せばよかった。
アンチョコは非常に便利。
他にも様々な形式でローカル保存できたりgoogle driveやdropboxdとの連携があったりとシンプルながらもありがたい機能がついている。

まとめ

まぁいくら便利にブログが書けたところで投稿に中身があって更新が続かなけりゃなんの意味もないんですけどね。

(投稿後追記)

うおおおおい！ 肝心のBloggerの方でコードがハイライトされてないじゃないか！
しかもHTML上ではきちんとh1,h2,h3ができてるのに実際にブログを表示するとフォントサイズがおかしい。
一体どうなってるんだ。

(解決)

どうやらBloggerに送る際に問題があったようだ。
Publish on Bloggerで選べるformatは三種類
最初紹介記事とかに載ってたようにHTMLを選んだ。
すると上記の通り上手く表示がされない。
次にmarkdownを試した。BloggerはMarkdown対応ではないので当然これも駄目。
そこでtemplateを選んだところ、すっきりとプレビュー通りにいった。
しかも驚いたことに、間違えて二重に投稿してしまったHTML版の投稿まで直っている。
これは単純に変換がどうこう。と言う前に何かjavascriptとかが入ってるかどうかの問題なのでは、と思い比較したらビンゴ。
 rel="stylesheet" href="https://stackedit.io/res-min/themes/base.css" />
 type="text/javascript" src="https://stackedit.io/libs/MathJax/MathJax.js?config=TeX-AMS_HTML">
templateにあったこれが鍵だったようだ。一回templateを下書きに戻して意図しない表示になってしまったHTML版の投稿にこれを加えたところ、template版と同じ表示になった。
だが投稿して確認したところ何かがおかしい。コードのハイライトも見出しサイズも合ってる。けど違和感を感じる。
見比べたところ、ブログ全体のレイアウトが変化している。そうか、スタイルシートの書き換えをしてしまったからか。
投稿内限定でスタイルシートを適用するようにしなくてはいけないらしい。
なんだかもう面倒になったのでとりあえず今回は保留

4章 条件と判断 メモ

Land of Lisp 学習書籍 Lisp
休みに入ったし、Lispを勉強し直そうと思ってLand of Lispを読み始めている。
Lispの本を読むのはいつだったか読んだ「初めての人のためのLisp」以来か。
SLIMEインストールした時とかちょっと触ったりはしてたんだけどね。
quoteの理解が中途半端だったけどデータモードとコードモードという説明のおかげで理解がはっきりしつつある。

本を読んでちょっと試しにコードを書いてみようとしたら怒られた。

temp1が無いぃ？ そりゃそうだ、ここで定義しようとしたんだから。
と、そこでsetqが定義ではなく束縛だと気づいた。ごっちゃにしてた。
というわけでdefparameterを使って本来やりたかったことを。
正直(1. 2)でなくていいのだけど、なんとなくこう書いてしまったので。

temp1とtemp2を定義。中身は一緒。途中で一応なか見を確認。
さてこれを比較。読んでた内容、4章の比較関数についての確認。

中身が一緒なのにeqでは違うと言われ、equalでは同じと返る。
「より進んだLisperは、ある種の状況のもとではコンスを敢えてeqで比較することがある」とある。ふむ。

つまりこういうことか。temp1とtemp1でeqが一緒なのは当たり前として、temp1をtemp2で束縛するとeqでも同じになる。
eqでは変数のポインタ(アドレス？)を比較し、equalでは評価した値を比較という感じだろうか。
確かこれ初めてのPythonの説明でも同じ感じのあったな。Rubyもこんな感じだったような。
確認してしまえばそこまで悩まなかった。
問題はマクロとかそれ以降だ……

ところでBlogにコード(特にLispのコード)載せる際、手軽でいい感じにハイライトしてくれる設定とかないですかね。

(10:26　更新)
とりあえずgistで。これが一番簡単でかつ覚えていやすい方法かな。
でも投稿編集画面をHTMLと行ったり来たりするの面倒だな。
なんとかしてMarkdown記法でblog投稿できないだろうか。

なんか軽くググった程度で手段は色々みつかった。皆考えることは同じらしい。
しかし今回はちょっと面倒なのであとにしよう。
しかしはてなブログはデフォルトでMD対応ですか……ブログ選択間違ったかなぁ。