yamaguchi.txt

開発日記。備忘録代わりだよ。

GSoC進捗報告(第二週)

実装

パッチがAcceptされました!
f:id:yamaguchi_1024:20170519190103p:plain

まあ簡単なところはできたんじゃないの?という感じです。

来週

わりと大部分に影響を与えるコードの変更をするつもりで、その変更をちょっと試してみてコードレビューに投げてこれでいいか確かめてもらいます。
あとはもうちょっと拡張性があるようにshellの部分を変更したりできたらいいな。

感想

英語のスカイプミーティング、良いんだけどつらい・・・。
文字なら何回も読み返すことによって理解することができるけどスカイプ越しで英語で向こうに二人いる状態で二人で話されると分からない・・・。
大体の意味はわかっても細かいニュアンスが全然分からない・・・。
結論は分かっても議論の流れが分からない・・・。
何回も聞き返したりするの本当に申し訳ない・・・。
二人のメンターさんはドイツ人とブルガリア人で英語が母国語って訳じゃなくて私と同じなのに完全にペラペラで、ほんとごめんなという気持ちが強い。

それ以外は楽しいです!

GSoC進捗報告(第一週)

進捗を報告することができるのは進捗が良い時だけですよね・・・。更新しなくなったら察してください。一応GSoCは平日のフルタイムワークという形になっていて週の進捗報告スカイプも金曜に設定されているので金曜日に進捗を報告することは自然なことです。ブログに書いて人に見られると進捗生まなきゃという気分にもなって最高です。

実装

Community Bonding Periodとは言いつつすでにパッチなどは投げているので実装を始めようかという話になり、普通に実装を始めています。
今週は単純なフラグの補完を実装しました。bash上でこんな感じに補完されます。

yamaguchi@ubu:~$ clang -f
Display all 873 possibilities? (y or n)
yamaguchi@ubu:~$ clang -isys
-isysroot       -isystem        -isystem-after  
yamaguchi@ubu:~$ clang -fno
Display all 307 possibilities? (y or n)
yamaguchi@ubu:~$ clang -fsyntax-only --v
--verbose            --verify-debug-info  --version            --via-file-asm  

これだけでも既存の補完よりは高機能なんじゃないかと思います。(clangで実際に実装されているフラグしか表示されないので)

実装はbashにしているのではなく、clangのDriverにしています。bashは引数を付けてclangを呼び出すだけです。
なぜかというと、今までbashシェルスクリプトでハードコーディングされてたフラグの補完をを内部で動的に生成することによって将来の全てのバージョンに対応し、呼び出すだけで全てのシェルから簡単に使える機能にするためです。

来週

テストケースを書いて、パスの補完を実装して、別のところに関数を移すか決めます。これらを終わらせてreviewに投げます(宣言)

感想

すごく楽しいです。
予定では三週間くらいを想定してたのが5日で終わったので進捗は悪くはないんですが、何かが終わると他にも無限にやることが湧いてきて一向に終わる気配がないです。zshなど他のシェルに移植するのはともかく、他のclang-toolsとかgccにまで移植する事になったらどうなっちゃうんだろう・・・。生きてるかな・・・。

GSoCに採択された話

Google Summer of Code 2017でLLVMに出していたbash-completion for clangというプロジェクトが採択されました!プロジェクトの詳細はこれからいくらでも書く機会があると思うので、今回の話は「どうやったらGSoCに通るの?」という事に焦点を当てたいと思います。日本からは毎年数人しか受かってないはずなので日本語の文献はとてもとても少ないので、来年応募したいなと思う人の参考になればと思います。

最初に、そもそもGSoCの存在を教えてくれてその後も色々相談にのってくれたhakatashiさん、パッチの投げ方からproposalの内容まで始めから今まで本当に沢山のアドバイスをくれたメンターのRaphaelさん、Vassilさん、ありとあらゆる相談に乗っていただきLLVMのノウハウを沢山教えてくださったRui Ueyamaさん本当にありがとうございました!この人々がいなかったら応募していたかも怪しいです。

Organizationを選ぶ

OrganizationをLLVMにした理由としては、Freebsd, Openbsd, LLVM, GNUなどを見ていてピンときたプロジェクトがLLVMにあったことと、成長著しい有名オープンソースという感じでかっこいい!と思ったという単純な理由です。コンピューターを速くしたいという私の思想にも合っていたのでとりあえずメーリスにメールを送ってみたのが始まりです。一日くらいでpotential mentorのRaphaelさんとRuiさんからメールをいただき応募に向けての活動が始まりました。
これはhakatashiさんにも言われたことなのですが、下手な鉄砲を数打っても当たらないので完璧なproposalを一つのorganizationに出すのが良いのかなぁという気がします。

First Contact & proposalの準備

Proposalを書き始める前にメンターのRaphaelさんに実力を示す意味でもclangにパッチを投げてみたらどうかと提案していただき、3月中旬から環境構築を始めていました。コンパイラのビルドというのはものすごいリソースを使うので環境構築が本当に大変で、ノートパソコンでは動かないのでデスクトップPCを買ったりなど頑張りました。
一番最初に提案してもらったバグがなかなかトリッキーで時間がかかり、別のパッチをはじめてコードレビューに投げたのがproposal締め切りの1日前とかだった気がします。
f:id:yamaguchi_1024:20170506005000j:plain
メンターさんとのメールです。たくさんやり取りをしました・・。
応募前にcommit historyが必要なのかどうかはorganizationによるかと思いますが、普通に考えてあった方が良いとは思います。

Proposal

3月下旬からはproposalを書き始め、100を優に越えるくらいのコメントを頂きました。LLVMディベロッパーの方々はもちろん、先輩やネイティブの友達に文法をチェックしてもらったり意見をもらったりなど本当にありとあらゆる人の力を借りました。
docs.google.com
これが実際のproposalです(CVは個人情報が載っているので消しました)。右上のコメントというところをクリックしてみるとわかる通り、本当にたくさんコメントをいただきました。コメントを頂けるということは関心を持ってもらえているということなのでとても良いことかなと思います。

Proposalを提出した後

4月になりproposalを提出した後もパッチを投げ続け、これは単純に趣味でやったことですが結果的には選考に有利に働いたと思います。コミッタにもなれて嬉しかったです。

最後に・・・。

自分には技術力が足りないんじゃないかと思う人に一言。これは持論ですが、プロの開発者は本当にすごいので我々学生の技術なんて等しくゴミレベルにきっと見えていて、多少の技術力の差なんて圧倒的プロの前では無に等しいのでそんなことを気にするよりも成長曲線の微分係数の大きさをアピールする方がいいと思います。


これは始まりでしかないのでマージされるように頑張ってデスマしていきたいと思います。応援よろしくお願いします!

DラッチとRSラッチでDflip-flopを作る時のnotの位置

先週のハードウェア実験で得た知見です。アナログ回路の話です。

最初はこのような回路を作りました。これだとクロックの立ち上がりでデータが捕獲されないのですが、何故かわかりますか?
f:id:yamaguchi_1024:20170430125632p:plain

波形図はこのようになります。
f:id:yamaguchi_1024:20170430125638p:plain
D flip flopはnotゲートの遅延によってクロックの立ち上がりのみでデータを出力に通すわけですが、上の回路だと データがDラッチを通過する速度 < clockがnotゲートを通過する速度になってしまったようで、波形図の①でデータがDラッチを通過しQに出て、RSラッチのsetに入るときにはRSのclockは0になっていました。

以下のようにnotの位置を変えるだけでクロックの立ち下がりでデータが捕獲されるようになり、治りました。
f:id:yamaguchi_1024:20170430125635p:plain

波形です。
f:id:yamaguchi_1024:20170430125641p:plain


これで一時間くらい溶かしたのですが他にも、
入力がグラウンドにショートしているのに気づかず一時間溶かす
回路には全く触れていないのにwaveformsをいじったら綺麗な波形が出るようになった
などがあり超楽しかったです。

4月のLLVM活記録

Closedなやつから。

1. Fix a bug which access nullptr and cause segmentation fault
null pointerを参照して死んでいたので、Nullかどうかのチェックを入れました。

2. Add path from clang to doxygen document include header
Clangのdoxygenが "#include " みたいだったのを #include "include/clang/Sema/Sema.h"になるように変えました。

3. Emit warning when umbrella directory does not exists
clangのmoduleという機能の中で、umbrellaという"ディレクトリ内にあるヘッダファイル全てをmoduleに追加する"ようなディレクトリが存在しない時にエラーを吐いていたのを、warningに降格しました。

4. Changed llvm/CMakeLists.txt and added relative path to llvm doxygen
2と同じことをLLVMdoxygenに対して行い、LLVMのCMakeLists.txtをClangと同じような書き方に(パスの通し方など)直しました。

下の3つはまだマージされてないです。
5. Fix a bug that -isysroot is completely ignored on Unix
一番最初に投げたパッチですが、難しいバグでどこまでが仕様なのかわかっていないのでマージされないでいます。
isysrootという、ヘッダのルートディレクトリを指定するフラグがUnixで全くハンドリングされていないのでそれを直しました。

6. Fix a bug that warnings generated with -M or -MM flags
まだマージされてないです。
-M,-MMというMakefileを自動生成するフラグでMakefileにwarningが入るバグを直しました。

7. Fix a bug that -Wmissing-braces fires on system headers
-Wmissing-bracesという括弧が足りないよというwarningが、ユーザーにはどうしようもないsystem headerに対しても出るバグを直しました。

PCのメモリをいじったらPCIE Bus errorになってrebootできなくなった時

こんな感じのエラーが出て困っている人を対象にしています。
f:id:yamaguchi_1024:20170430115848j:plain

いろいろ原因があるとは思いますが、PCIE Bus errorでぐぐってカーネルパラメーターを設定するという方針で間違っていないと思います。
私の場合はActive State Power Managementが原因だったので、以下のようにpcie_aspm=offを設定したら治りました。

一時的にカーネルパラメーターを設定して試してみる。

1. GRUBのメニューで起動したいカーネルにカーソルを合わせて"e"を押す
2. linuxで始まる行があるので、行末(おそらくquiet splashの後)にpcie_aspm=offを追加する
3. Ctrl+xでブートする

上の操作で治ったら恒常的にパラメーターを追加する。

1. $ sudo vim /etc/default/grub
2. 以下のような行に追加したいパラメーターを書く。
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=off"
3. $ sudo update-grub


Wikipediaによるとバッテリーの寿命を伸ばすために導入されたようですが、エラーが出るのはつらいですね。

ブラウザではアクセスできるのにcurlでhtmlが取ってこれない時

curlのUser Agentが弾かれているのかもしれません。ブラウザのUser Agentをホワイトリストにしてそれ以外を弾くようにしているサイトもあるみたいです。
何のUser Agentで通信しているかは、-vオプションを付ければわかります。

$ curl -A "Mozilla/5.0" https://www.example.com

などとしてUser Agentを偽装しましょう。