Skip to content
2017年4月7日 / masterq

前職でオススメのタイル型ウィンドウマネージャを聞かれたので僕なりの解説をしてみました

「今twmかi3かxmonadで悩んでます」
「ぉ。宗教戦争ですね!それぞれの利点がありますよ!」
「これは話すと長いので家に帰ったら詳細を書きますー」

などという会話が某L社のチャットで流れたのをキッカケにして僕の中でなにかがはじけました。そのチャットでの発言をブログにも残しておこうと思います。

1st: 「twmについて」

“X11R4以降、標準のウィンドウマネージャとしてXサーバに同梱されている。” https://ja.wikipedia.org/wiki/Twm

これが唯一無二の強みです。例えばNetBSDのようにOSがパッケージに分割されておらず、ベースシステムとパッケージ(pkgsrc)にわかれている場合、i3wmやxmonadを使いたければpkgsrcでインストールせねばなりません。ときおり競合によって使用不能になるケースもあるかもしれません。twmならベースシステムに含まれているので、NetBSD OSのアップグレードさえ成功すれば問題なく使えます。Linuxでは「全てがパッケージ」という考え方が主流ですが、BSDではベースシステムと{ports,pkgsrc}がわかれているのが主流です。その場合自分の作業基盤が{ports,pkgsrc}に依存していると非常事態のときに身動きが取れなくなります。

R社時代にSさんという伝説のハッカー社員がいました。彼は20世紀にNetBSDを使ってプリンタを設計しようという狂ったアイデアを影で推進した張本人です。彼は「最後の砦」でした。だれにもわからないNetBSD kernelのバグを彼はコードをタグジャンプしたりカーネルデバッガを時折使ったりするだけで解決していました。彼はtwmのユーザでした。彼のデスクトップは「左上: xterm」「左下: xterm」「右側上下: Emacs」というワークスペースのまま、まったくワークスペースを切り換えことなくハックしていました。

そんなBSDカーネルハッカーになりたいあなたにおすすめなのはtwmです!

2nd: 「xmonadについて」

”このウィンドウマネージャは、関数型プログラミング言語Haskellで書かれている。” / “実行中に、設定ファイルを変更しリロードすることで、カスタマイズ可能である。” / xmonad – Wikipedia https://ja.wikipedia.org/wiki/Xmonad

この「設定ファイル」とは何者で、どんな文法なのでしょうか?なんとそれはHaskell言語そのものなのです!具体的な設定ファイルの例はこちらから閲覧できます / https://wiki.haskell.org/Xmonad/Config_archive

実は実際にはxmonadはアプリケーションではなくライブラリでしかないのです。実際最小のxmonadの設定ファイルは以下で記述できます。

https://wiki.haskell.org/Xmonad/Config_archive#Minimal_xmonad_config_files

import XMonad
 
main = xmonad defaultConfig {
      modMask = mod4Mask -- Use Super instead of Alt
    , terminal = "urxvt"
}

なるほど。だからXモナドなんですね。名は体を表わすという訳です。

というとはこの設定ファイルの中ではありとあらゆるHaskellのライブラリを使って自由に拡張可能なことになります。Haskell言語は近年ではおそらく最も豊かな型システムを持つ言語でしょう。それは国際学会ICFPにおけるHaskell言語の扱いを見れば一目瞭然です。 / ICFP 2017 http://conf.researchr.org/home/icfp-2017

icfp2017

Haskell言語だけ特別扱いで2日間ぶちぬきの #シンポジウム が開かれます。一方OCamlなどの言語には1日間しか与えれていません。そしてOCamlのそれは #ワークショップ です。日本でいうところの #学会 と #お勉強会 の違いのようなものでしょうか。とにかくHaskellは今ぶっちぎりで最先端をはしる高階な言語なのです。(高階なことが良いか悪いかは別にしてですが)

そんな世界一イケているソフトウェア設計言語Haskellで自分のデスクトップを自由自在に拡張したい。カスタマイズしはじめると止まらない貴方におすすめなのがxmonadです!

3rd: 「i3wmについて」

“i3 is a tiling window manager designed for X11, inspired by wmii, and written in C.” / i3 (window manager) – Wikipedia https://en.wikipedia.org/wiki/I3_(window_manager)

え、C言語で書かれているのはいいんだけど、他になんか特徴はないの?って思うんじゃないでしょうか。じゃじゃーん。実はとりたてて特徴がないタイル型ウィンドウマジェージャがi3wmなのでーす。

i3wmはデフォルトの設定を特に弄らなくても容易にステータスバーがいいかんじに表示されるようになっています。キットインしたらすぐ使える。そしてだれもが「まぁ、、、無しってことはないデフォルト設定だなぁ」と納得してしまう。そんなぼんやりしたタイル型ウィンドウマネージャの凡人です。

でもね。人間を想像してみてください。特別な人ってどこかいびつだから特別なのではないでしょうか?20世紀のしっかりした日本製品は特別な人が設計したのではありませんでした。凡人の集団が凡人なりに努力をして、凡人なりの落しどころを作り、丁寧な再発防止をした結果産まれたMade in Japan。それを支えたのは凡人達だったのです。

“俺は普通だから変わったとこもないから、好きなものだって特別にはないんだ” / http://www.uta-net.com/song/221954/

そう #普通であること に悩み、そしてそれでも生きるあなたにこそおすすめしたいのが、i3wmです!

あなたは…?

さぁ3人のペルソナ、あなたは誰を選びますか?誰になりたいですか?その思いが答です。

2017年2月17日 / masterq

エホバの証人の友人との手紙1: 生命の起源に関する見方について

メールをやりとりしているので、なんとなく自分の信仰を表明するためにはりつけます。。。

> 表題の件について,イタリアのロボット工学者のコメントをどうぞご覧ください。
> 下記のリンクから動画をご覧いただけます。
> https://www.jw.org/ja/%E5%87%BA%E7%89%88%E7%89%A9/%E3%83%93%E3%83%87%E3%82%AA/#mediaitems/OriginsLife/pub-pcr_J_2_VIDEO

ありがとうございます。拝見しました。同意できる点も多かったです。

しかし、一人のソフトウェアエンジニアとして強調したいのは、この世界全体が誰か一人もしくは集団の手によって意図的に設計されたのだとしたら
「あまりにも完璧に構成されすぎている」
ということです。仮に全知全能な人間が存在したとしてもこのような設計は不可能だったに違いないという直感があります。この直感はなんらかの製品が完璧であることを理論的に検証することができても、「実際の動作」が安定しているかどうかを検証するのは(おそらく)不可能だという認識から産まれています。
また、経済がだんだんと「生命」をおびてきていることも私のガイア信仰をうらづけています。株式の乱高下は地球全体の生命の鼓動のように私には感じられるのです。そして(今のところ)経済は指数関数的な成長を裏付けています。私個人の考えでは、この指数関数的な成長は数学の指数関数的成長にささえられていると考えています。

数学記号の誕生を年表で。美しい

つまり、私のガイア信仰におけるガイア全体の成長は個々人の血のにじむ苦悩の上にささえられ、そして(願わくば)このガイア信仰によって人類はよりよい生活が得られると考えるのです。この成長によって中期的にはベーシックインカムのようなさらなる自由とおそらくはさらに高次元の苦悩を人類は手にするでしょう。

https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF%E3%82%A4%E3%83%B3%E3%82%AB%E3%83%A0

私はこのような人間全体の成長を深く信じています。まとめると私達一人一人は経済という生命の細胞の1つでしかないのかもしれないのです。

> ※どのアドレスを使ったらよいか分からなかったため,念のため全部にお送りし
> ておきます。

基本的に個人のメールはkiwamu@gmail.com宛ての方が良いかもしれません。
# じゃあ仕事の名刺わたすなよ、という話でもありますが、これも何かの御縁。仕事上でのお付き合いもある可能性もありますので…

また、キリスト経だけではなく他の宗教にも手をのばしてみることを深すおすすめします。

スリー・カップス・オブ・ティー https://www.amazon.co.jp/dp/4861139414/
神道の逆襲 https://www.amazon.co.jp/dp/4061495607/

前者はイスラム教を、後者は神道を現代的に解釈したおした書籍です。
どうか今の時代において他の宗教への尊重も人類には必要なのだということを(百もご承知だとは思いますが)理解していただくことはできないかと考える日々です。
# もちろん仏教徒もエホバの証人を理解すべきでしょう

2017年2月2日 / masterq

僕の職歴3

ちょっと人物紹介をはじめてみようと思います。第一回の今夜はEさんです。

Eさんとぼくが某社で出会ったのは新人研修が終わったあと、職場配属OJTにてでした。当時某チームではペアリーダが二人、新人につくことになっていました。1年間の研修テーマの運用面を見る人と、そのテーマの技術的な面をささえる人の二人です。

ぼくの研修テーマは以前書いたとおりbootloaderの開発だったのですが、その前に仕事に慣れるために新人二人でEthernet MACのテストプログラムを書くことになっていました。しかし所詮新人です。libcのないところでC言語を書いたこともなければ、DMAについてもよく知らないわけです。
MACの仕様書はあるのですが、そこそこ分厚い本でしかも英語でした。そもそも何がわからないのかさえわからない状態におちいってしまいました。

そこでEさんに教えてもらおうと思ったのですが、
「この本全部読んだの?」
と聞かれました。
残念ながらそのページの全てを読んでいたわけではありませんでした。ただ少しズルをして手っ取り早く知識を得たかったのです。するとEさんはその仕様書を床に投げて、ディスプレイに目をもどしてしまいました。かなり傷付いて本をひろってあたりを見回したのですが、誰もフォローしてくれません。自分でやるしかないんだな、と思いました。そのMACのテストは新人の同期ががんばってくれてなんとかなりました。

Eさんはいつもは机で寝ているか、歯磨きしているか、単行本を読んでいるかのどれかなのですが、なぜか仕事のoutputだけは順調に出すという魔法使いでした。

数年後、なぜかEさんとは仲良しになりました。Eさんは色々なことを知っていました。当時のWindows Updateがなぜ機器によって失敗することがあるのか。WindowsのAPIのよくわからない話。スレッドについて。文字コードについて。COCOMの輸出規制について。なぜかカーボンナノチューブについての議論が掲示板に。

あの時、どうして彼が厳しい態度であったのかは、10年後になった今やっと実感できるようになりました。

2017年2月1日 / masterq

僕の職歴2

bootloaderの開発が一段落したころ、無線LANチップそのものを開発とする話がありました。無線LANチップの中には実は小さなCPUが入っていて、そのCPU上で動作するプログラムを書くという案件です。やったことがない仕事をするのが大好きだったので、一にも二にもなくとびつきました。

まずAtherosのホスト側ドライバのソースコードが公開されていたので、それを読んで気になるところをメモしました。その後できあがってきたプロトタイプのでっかいボードの起動確認をしたりしていたのですが、他業務と並行で工数調整をしながら進める能力がかけていて、途中で戦力外通告されてしまいました。プロジェクトに大変迷惑をかけましたが、安易に仕事を引き受けてはいけないという良い経験になりました。

そうこうしている内に新製品のBIOSのメーカを既存製品と違う会社にしようという案件がもちあがりました。英語が苦手でしょうがなかったのですが、米国東海岸に行って身振り手振りでOSサイドからBIOSへの要求項目を説明したら1週間程度である程度動作するBIOSを作ってくれました。あの時ぼくのつたない英語力を使う機会をくれたKさんには感謝しています。

その後にアサインされたのは巨大な組込みシステムの起動時間を10秒にする、というプロジェクトでした。この10秒というのはkernelの起動だけではなく、BIOS=>OS=>アプリ=>画面表示の全てを10秒におさえなければなりません。まず最初に左記の起動シーケンスを横断で測定できる簡単なツールを開発しました。これで、測定にかかる手間を一気に削減できました。その後、各ステージでかかっている時間が長いものから順番に削減検討しました。本来は各アプリの開発担当を呼んで、削減依頼をかけるべきです。しかし、IPCでからみあった起動シーケンスは定常状態とは異なり、1アプリの中だけで完結しません。アプリAの処理に時間がかかっているのは、アプリBの処理待ちで、さらにアプリBはディスクのmountを待っている、ようなことが多発していた訳です。そこで、一旦一人で起動ログを横時間軸の散布図にして、ギャップの大きい部分にしぼり、その処理待ち合わせの依存を解析しました。その解析結果もってアプリの修正をコンサルタントするようにしました。

このような方法を取ったのですが、それでも10秒を達成するのは困難でした。ディスクの読み込みに時間がかかっていたためです。そこで、アプリを画面表示に必須なものと、そうでないものの二種類に分けて、前者のみをディスクから読み込み/起動、後者は画面表示が完了してから読み込むようにしました。この方法で10秒起動を達成できたのですが、アプリのIPC接続関係が変動するとバグを引き起こすという諸刃の剣です。当然、機種が出る度になんらかの障害を引き起こしてしまうことになりました。もっと良い方法がなかったのか、今でも悩むことがあります。

2017年2月1日 / masterq

モナドって何だろうか

モナドって何だろうかということを昔考えていたときのメモが見つかったので、以下にはりつけておこうと思います。何かの役に立てば。


@s_h_i_g_e_chan さんと勉強会をしました。前回の勉強会で疑問だったモナドの別の例を学ぶためです。

結局モナドってなんなんだろうと思って図にしてみたが、Haskell文法以上の何かにさえなりませんでした。。。Haskell文法以上に抽象化した表現はできないということでしょうか。

まず↓のようなdo文があったとしましょう。

↑を>>=に変換すると↓のようになるわけです。

ここまではどのようなモナドでも同じ形を取ります。というかHaskell文法そのものです。
例として以下のようなdo文を例にして、もっと詳しく処理内容を見てみましょう。

-- リストモナド定義
instance Monad [] where
  m >>= f  = concatMap f m
  return x = [x]
  fail s   = []
instance MonadPlus [] where
  mzero = []
  mplus = (++)
-- do文の例
do x <- [1,2,3]
   y <- [3+x,6+x]
   [x,y]

どのようなモナドかわかれば、具体的な実行イメージはできます。

前回の勉強会ではdo文が一行実行したら次の行を実行していっているように見えましたが、リストモナドは使い方によってはツリー状に次の行が分裂して実行されていくように見えます。

なぜそのようなことになるかというと、>>=がconcatMapになっているためです。concatMapは「第一引数の関数を第二引数の要素それぞれに適用して、その結果のリストをconcatする」ように動作するため、第一引数で指定された関数(この場合はλxだったりλyだったり)がリストの個数だけ実行されます。

。。。なんか言えば言うほど当たり前のことしか説明できないのですが、>>=によってdo文の次の行がどのように実行されるのか、いかようにも決められるワケです。それでもdo文のλスコープによって計算は前後に分離されます。do文が出現したら順序制御したいんだなって思えばいいのかな?

そーゆーワケでリスト内包表記はリストモナドのdo文です。なるほどです。

-- do文で
do x <- [1,2,3]
   y <- [3+x,6+x]
   return (x,y)
-- リスト内包表記で
[(x,y) | x <- [1,2,3], y <- [3+x,6+x]]

.

2017年2月1日 / masterq

僕の職歴1

なんとなく書きはじめてみます。ところどころごまかしてあるのは、守秘義務らしきものを回避しています。たぶんこのレベルなら大丈夫かな?

某社に入社したのは2001年ぐらいでしょうか。そのころ社内のプロジェクトでx86を組込みシステムに使おうとしていました。で、僕が新人時代に担当したのは

  • BIOS
  • 某Option BIOS
  • bootloader

と起動まわりでした。(その当時僕はもー本当にRuby厨で、C言語まともに書いたことなし、アセンブラもさっぱりな状況でした。よくソフト部門配属になったもんです。)

とりあえずまずはじめに某オープソースプロジェクトのbootloaderをパクって某社要求を満たすような機能をみようみまねで実装しはじめました。で、おそらく皆さんハマると思うreal modeとprotect modeの移行やその逆でのバグに当然悩まされることになりました。何年かまともに動作していたように見えたのですが、潜在バグが上記移行コードに潜んでいて、某Iさんに多大なるご迷惑をかけました。。。すいません。

その後、当該のbootloaderを組込みストレージから起動するためにOption BIOSを書きました。当然full real modeで某ASICのデバドラを書く工数も頭もないので、先輩KさんにC言語で書いてもらったアルゴをごにょごにょっとしてOption BIOS化しました。あの頃の僕の頭の中にはメモリマップドI/Oでデバイスというモノが全く思い描けてませんでした。(今もデバドラをイチから書いたことはないのですが。。。ヘタレです。。。)

bootloaderがそこそこ軌道にのった後は、機種毎抽象化のためのしくみを作った後は特になんもしてないです。機種を担当していただいている方々に毎度毎度多大なるご迷惑をかけている毎日です。

あ、そうそう。bootloaderでもう一つ面白い話題があって、某公開鍵暗号をbootloaderに組み込んだことがありました。某オープンソースプロジェクトからコードをパチってdecryptだけをねじこんだような思い出があります。でも、このイカレた試みはもう実機には搭載されていません。。。ちょっと残念ではあります。

2016年12月24日 / masterq

AtomではじめるVerilogプログラミング

この記事は Atom Advent Calendar 2016 の24日目の記事みたいです。

はじめに

こんばんは。元気ですか?僕は仕事やら論文やらの進捗がわるくて体調が悪化しています。そんなこんなで家族とはなれてスタバでThinkPadと向き合うクリスマスイブ。。。がんばっていきましょう。

えー皆様普段Verilogを読み書きするのにどんなエディタをお使いでしょうか。Vivado。そうですよね。そうなんです。でも前回の記事で解説したように、IceStormを使ってHDL合成する場合、どんなエディタを使えば良いでしょうか。

もちろんEmacsやVimを使うこともできますが、ここは1つ流行のAtomエディタを使ってみましょう。この記事では当該エディタをインストールする環境としてDebian GNU/Linuxを仮定していますが、WindowsでもMac OS Xでも同様に使えるはずだと思います。

環境整備

なにはともあれFPGAボードが必要です。この記事ではiCEstickを使います。Mouserから買えますが、2600円と安いので送料がかかってしまいます。なんかの発注ついでに買いましょう。

ice_1

次はソフトウェア環境を整備しましょう。まずAtomエディタをインストールしましょう。

$ wget -O atom.deb https://atom.io/download/deb
$ sudo dpkg -i atom.deb

その後いくつかAtom内から使われるDebianパッケージをインストールします。

$ sudo apt-get install gtkwave iverilog

iverilogはVerilogのシミュレータで、gtkwaveはシミュレーション後の波形を見るためのツールです。前者はVerilogの構文チェックにも使われます。

さらにAtomを起動して”Ctrl-,”を入力して設定タブを出していくつかパッケージをインストールしましょう。まずはVerilog関連のパッケージであるlanguage-verilogとlinter-verilogをインストールします。

verilog-atom

次にPlatformIOという統合開発環境を使うために、platformio-ide-terminalとplatformio-ideパッケージをインストールしましょう。

platformio-atom

上記のパッケージのインストールに完了すると以下のようにAtomの再起動が要求されます。

platformio-reboot

“Reload now”を選んで、Atomを再起動させましょう。すると以下のようにPlatformIOのWelcomeタブが表示されます。これで環境整備は完了です。

platformio

とりあえずプロジェクトを作ってみる

新しいプロジェクトを作ってみましょう。Welcomeタブから”New Project”ボタンを押下してみます。

platformio-new

プロジェクトの設定ウィンドウが出るので、以下のようにiCEstickボードを選択します。

setting-lattice

次に適当なディレクトリをプロジェクトディレクトリとして”led”というディレクトリを作って選択します。

setting-other

led

これでプロジェクトの設定ができました。”Process”ボタンを押下しましょう。

process

ここでなんやかんやツールチェーンを読み込むのでしばらく待ちましょう。その後以下のようなエラーが表示されてしまうでしょう。

error

これはまだプロジェクトディレクトリに何も設定されていないためです。びっくりせずにとりあえず×ボタンでエラーメッセージウィンドウを消しましょう。

ledプロジェクトのsrcディレクトリにファイルを追加しましょう。1つ目は”led.pcf”ファイルで、以下のようにポートの番号を列挙します。

set_io D1 99
set_io clk 21

次にVerilogでLチカを書きましょう。ledプロジェクトのsrcディレクトリに”led.v”ファイルを追加して、以下のようにコードを書いていみます。

module led #(parameter N = 29)(input clk, output D1);
  reg [N-1:0] cont;
  reg rstn = 0;

  always @(posedge clk)
    rstn <= 1;

  always @(posedge clk)
    if (!rstn)
      cont <= 0;
    else
      cont <= cont + 1;

  assign D1 = cont[N-6];
endmodule

iCEstickをPCのUSBポートに挿した上で、プロジェクトをアップロードしてみましょう。左ペインの右矢印ボタンを押下します。

upload

するとiCEstickボードのD1 LEDがチカチカしたら成功です!

より本格的なプロジェクト

もっとちゃんとしたプロジェクトの例を見てましょう。まずはサンプルプロジェクトをgit cloneしましょう。

$ git clone https://github.com/platformio/platform-lattice_ice40.git

その後、当該プロジェクトのplatform-lattice_ice40/examples/counter/ディクトリをplatformioのプロジェクトとしてオープンします。

platformio_open

open_counter

すると以下のようなcounterプロジェクトが登録されているはずです。

proj_counter

それではやはりiCEstickをPCのUSBポートに挿した上で、プロジェクトをアップロードしてみましょう。

upload_counter

すると以下のようにiCEstickのLEDにカウントアップされるはずです。

mov_counter

さらにターミナルを開いて、platformio run –target sim と入力してみましょう。
terminal

するとなんとシュミレーション結果の波形が表示されるではないですか。ちゃんとLEDがカウントアップされているタイミングが見えますね。

gtkwave

シミュレーションを実行するにはテストベンチファイル(counter/src/counter_tb.v)とgtkwaveの設定ファイル(counter/src/counter_tb.gtkw)を作る必要がありますが、そこさえ作りこんでしまえば後は快適にGUIから操作できそうです。

さいごに

IceStormやiverilog、gtkwaveコマンドを使えば、これのような開発環境はこれまでも使用することはできました。しかしAtomとPlatformIOをIDEとして使うことで、統合開発環境として使うことができ、ぐっと使いやすいと感じるのではないでしょうか。