dyama's page – ページ 36 – 万年エンドユーザのブログ。バイクとカヤックでうろうろしてキャンプするのが好きです。

鎮守府史跡探訪〜佐世保軍港クルーズ〜

投稿日: 2016年4月9日2016年4月10日投稿者: dyama

色々と私を遊びに連れ出してくれる920さんのお兄さんで、佐世保観光コンベンション協会の吉川拓朗さんがガイドを務める、佐世保の軍港クルーズに参加しました。

佐世保の「軍港クルーズ」、今季の運航始まる : 社会 : 読売新聞（YOMIURI ONLINE）

今シーズンは4月4日から始まったそうで、今日は初めての週末。晴天とまではいかないものの、天気にも恵まれていて絶好のクルーズ日和でした。

まず最初に向かったのは、JR佐世保駅。駅構内にある「佐世保観光情報センター」の受付にて、軍港クルーズのチケットは販売されています。改札が1つしかない小さな駅ですので、すぐに見つけることができると思います。情報センターの入口の向かって右手には佐世保駅名物（？）のボンビーの石像があります。そういえば、結構長い間居座ってますね（笑）

情報センターのカウンターで言えば乗船チケットを購入することができます。1時間のクルーズで1人2000円でした。

桟橋は情報センターがあるJR佐世保駅から目と鼻の先です。チケットにも地図が印刷されていますが、JR佐世保駅のみなと口を出て正面にある、佐世保五番街を貫けたところにあります。佐世保駅を出るとすぐに綺麗な公園とその後に広がる海を見ることができます。

歩いて数分の距離です。JR佐世保駅は特急みどり号で新鳥栖駅や博多駅まで直通で行けますので、アクセスのしやすさもすばらしいですね！

遊覧船は、まるで阪神タイガースを思わせるカラーリングです（笑）。普段、一般の船が航行できない海域にも入るそうなのでとにかく目立つ色なのかもしれません。佐世保湾の広さは、横須賀港の2倍、長崎港の10倍もの海域があり、その8割が軍用に指定されているらしいです。この鯨瀬埠頭周辺は、その中でも限られた貨客船埠頭で西海市の大島や五島行きのフェリーもここに着きます。

遊覧船は2つのデッキがあり、どうせなので見晴しが良さそうな上のデッキに上がりました。全体の定員は60名ほどらしいです。

ガイドを勤める拓朗さん。制服姿がカッコいい！

オンラインゲーム「艦隊これくしょん」のブームで、いわゆるガチな方々が多いのかなと思ったらそんな事もありませんでした。意外で少し驚いたのが、年配の方、特に一人で乗られている年配のご婦人の方などがいたこと。

上のデッキの後部左舷側の席に座っていると軍港にはおよそ似合わない品の良さそうな格好の年配のご婦人が上がってこられたので、席を譲ろうと立ったところ、「いいのよ、私は陸側を見たいから」と笑顔で返され、デッキにあった台を右舷側に置いて座られていました。自分らは初めての乗船でしたが、右舷が陸側ということをご存知のところ、何度も乗られている方のようでした。

※ 実際に佐世保港内を半時計廻りで航行したので、右舷が陸側（艦艇が停泊している方向）でした。なお、クルーズが終わった後から拓朗さんに伺った話では、航路は変更になることがあるようです。 ※ あ、別の年配の男性に席は譲りましたよ！どうせカメラを構えてずっと立ってるつもりだったので…（笑）

さあ、いよいよクルーズの開始です！

乗り場の隣に停泊していた佐世保市の防災船「つくも」。船上火災などに対応するための船らしいです。写真では分かりづらいですが、赤い放水器が船上に2つ見えます。こういう細かなところにも拓朗さんのアナウンスがあり、とても分かりやすかったです。

緑色の屋根の建物が米軍第7艦隊の司令部施設です。左手には桜、右手には米軍艦、奥には旧佐世保海軍工廠時代から使われていて現役で稼働している佐世保重工業(SSK)の250トンカンチレバークレーン…というよく考えたらスゴい組み合わせ。国連旗も掲げられているのですが、NATO軍の艦艇も入ってくるかららしいです。

米海軍ワスプ級強襲揚陸艦、ボノム・リシャール。全長257メートル、オスプレイなどの垂直離着陸機を運用しているヘリ空母らしいです。米軍艦艇は全然知らないので現物を眺めながら解説を聞くとよく分かります。この艦の乗員は、東日本大震災の時、米軍による「トモダチ作戦」で以前佐世保を母港にしていた強襲揚陸艦エセックスに乗って、多くの被災者を救援をした方々とのことです。

米海軍サン・アントニオ級ドック型輸送揚陸艦、グリーン・ベイ。ステレス型の面白い形をしてます。現在は女性が艦長をしているとのことです。

米軍の艦艇2隻が停泊しているすぐ隣には、我が海上自衛隊の立神岸壁に停泊中のイージス艦「ちょうかい」がいました。なぜすぐ近くに停泊しているかというと…

海上自衛隊立神岸壁は、上図のように米軍佐世保基地の先端に位置しています。港湾海域は広いわりに陸地が狭いため、米軍、自衛隊、SSK、一般の港湾施設が密集しまくっています。矢印の赤線が遊覧船の航路です。この航空写真でも平瀬係船池に停泊する米軍艦艇と海自艦がすぐ近くにあるのが分かります。せまいぞ！

なお、戦前までは緑線の米軍基地と青線のSSKはすべて日本海軍の施設でした。

左がちょうかい、右がグリーン・ベイ。ほんとに近いです。

はりきって一眼レフと望遠レンズを持っていきましたが、クルーズの前半はハンディカムで動画撮影をしていました。このあたりの写真はすべてハンディカム撮影です。画質がイマイチなのはご愛嬌。ただ、手ぶれ補正はなかなか優秀でした。

ちょうかいの船尾、トランサム板にあるラッパ状のものは曳航型のソナーを出す部分らしいです。

ちょうかいの隣に停泊中の海上自衛隊とわだ型補給艦「はまな」。インド洋にて多国籍軍に洋上補給した実績がある艦です。

2014年に就航したばかりのあきづき型護衛艦「すずつき」。イージス艦のサポートが任務の一つらしいです。倉島岸壁は一般公開があるため艦内にまで入ることができますが、立神岸壁は米軍基地内を通らなければならいため、一般人は近づいて見る機会がほとんどありません。

SSKの250トンカンチレバークレーン。大正2年に建てられ現在でも稼働中です。立神係船池の中央にあり、右側は米軍施設、左側はSSKになります。ちなみにこのクレーンは（どのタイミングかは分かりませんが）電飾が付けられて光っている時があります。

戦艦武蔵の艤装工事を行なった第4ドック（旧第七船渠）。ちょうど大型のバルクキャリアーがドック内に入っていました。

この後、米軍赤崎岸壁へと遊覧船は進んで行きましたが…

米軍の原子力潜水艦が停泊していたため、カメラ撮影をしないでくださいとアナウンスが流れました。慌てて録画を止めます。潜水艦の近くには、機関砲を備えた米軍の小型艇がこちらを監視してウロウロしています。乗船前には「撮影NGになることもある」という情報を知らされてはいなかったので、少し驚きました。停泊している艦艇にもよると思いますが、こういうこともあるんだなと。

なお、当たり前といえば当たり前ですが、監視している小型艇の米兵の方も遊覧船から手を振ると振り返してくれるくらいフレンドリーだったので危険なことは一切ありません。任務ご苦労様なのです。

原潜を通り越した後の米軍赤崎貯油所のタンク。原潜は燃料補給の必要がほぼない為、給油ではなく乗員の休養や食料の積み込みのために停泊していたようです。

佐世保湾内に面した針尾島・浦頭埠頭。終戦直後の復員で100万人以上の兵士、一般人がここから日本各地へ帰っていった場所です。左手の記念公園の桜が咲いているのが分かります。

崎辺地区にある海上自衛隊佐世保教育隊施設。ここで若い自衛官が訓練を行っているらしいです。崎辺も陸からはあまり見る機会がないので、軍港クルーズならではの風景です。

訓練用のカッターボートが吊ってあるのが見えました。

米軍の前畑弾薬庫。建物の周りに立っているのはすべて避雷針らしいです。建物を囲むように盛ってある土塁は万が一の爆発時に爆発エネルギーを上に向けるためのものとか。写真のような建物が海沿いにいくつもあり、4万トンもの弾薬が常備されているらしいです。噂ではここに核兵器があるとかないとか…。瓦屋根なのは、旧日本海軍時代から使ってた建物っていうことでしょうか。

前畑弾薬庫のすぐ隣にある前畑造船所。はしけ状の浮いている乾ドックです。こっち側から見るのは初めて。

さらにその隣にある、旧日本海軍の水雷庫。100メートル以上ある横長の石造りの建物です。屋根にはソーラーパネルが見えます。ここに日本海軍が誇る酸素魚雷を格納していたらしいです。

最古の Ruby 実装をちょっとだけ覗いてみました

投稿日: 2016年4月4日2016年5月25日投稿者: dyama

職場で定期的にやることになった Ruby 勉強会の資料作りをしていて、ブロック構文を投げてメソッド側から述語を呼ぶコールバック機能はいつから設計されているのかな、と気になって調べていました。

ドキュメントにも、以前から

(ブロック付きメソッドは)最初はループの抽象化のために用いられていたため、特にイテレータと呼ばれることもあります。

メソッド呼び出し(super・ブロック付き・yield) (Ruby 2.3.0)

という記述があります。(現在では、File.open() 時の自動後処理や、Proc や lambda の述語的な記述用途でもあるので、必ずしもイテレータではないです)

いろんなページを見ていると、

私家版Ruby史

という Ruby の歴史を分かりやすくまとめたページを見つけました。

最古の Ruby

今から20年以上前、1994年初夏のバージョン 0.49 が最古のスナップショットらしいです。下記からダウンロードすることができます。 (それ以上古いスナップショットは、Matzさんの転職のどたばたとHDDのクラッシュによって失われてそうです。)

ftp://ftp.ruby-lang.org/pub/ruby/1.0/

each メソッドはイテレータとして説明があるものの、サンプルで使っているところを見つけることができませんでした。 (意外なことにサンプル中の繰り返しは for ... in 構文を多用してます)

以下、spec ファイルにあったイテレータの説明です。

** イテレータ

イテレータとは制御構造(特にループ)の抽象化のために用いられるメソッドの一種である. イテレータの呼び出しは以下の構文で行なわれる.

do 文1 using 変数文2 end [ do ]
「文2」をブロックとして設定し, 文1のメソッドをイテレータとして評価
する. 文1のトップレベルのメソッドだけがイテレータとして呼び出され, 
レシーバを表す式や, 引数の式はイテレータとしては呼び出されない. 文
1に複数の式があれば各々がイテレータとして順に呼ばれる.
イテレータ内でyield valueが実行されると, その値がdo文で指定された変数に代入されブロックが実行される. ブロックの実行が終了するとその値は yield式の値として返される. あるメソッドがイテレータとして呼び出されたかどうかは関数iterator_p()で知ることができる. 中にはEnumerableモジュールのgrepメソッドのようにイテレータとして呼ばれた時と普通のメソッドとして呼ばれた時とで動作が異なるメソッドもある.

for 変数 in 式文 end [ for ]
式の各要素に対し文を実行する. これは以下のdo文と等価である.

    do (式).each using 変数
      文
    end

よって式の値のオブジェクトがメソッドeachを持たない場合, forを実行
すると例外が発生する.

今の do |var| ... end 構文ではなく、do ... using var ... end という形をしてたんですねー、面白い。例外処理も begin ... end ではなく protect ... end で囲んであって色々と興味深いです。

最近の構文しか知らない方は、ぜひダウンロードして読んでみることをオススメします。

また Ruby でイテレータを、という考え方は設計段階からあったようです。

ずいぶん長い間いろいろな言語をつまみぐいして，よさそうなものを拾い集めてきました．rubyはそういう概念の集合でもあります．例えば例外とかイテレータとか．

[ruby-list:63] Why ruby

ちなみに C# は2005年暮れに発表された 2.0 まで、yield キーワードがなかったため、コルーチンすら書けませんでした。こわい。

MLやCVSを詳しく追っていったわけではありませんが、ブロックを投げてなんでもやっちゃえる動きは、その後の最適化、考え方の抽象化によって定着・進化していったのだと思いました。

Raspberry Pi と Ruby で「Lチカ」をやってみました

投稿日: 2016年4月3日2016年4月7日投稿者: dyama

ラズパイを何年も前に購入して Raspbian を入れて ssh できて、X も動いてふぅ…と、ひと落ちつきした後、全然触っていませんでした。

せっかくラズパイを持っているんだからと思い立ち、ヤフオクで売っているキットを購入。子供の頃からやってみたかった電子工作に初挑戦です。

設計

Fritzing というソフトが GUI でブレッドボード上にいろいろ乗せてみることができるようだったので、ダウンロードして使ってみました。初心者でも分かりやすくて良いソフトですね！

Windows 版を使ってみたんですが、GLESとかQtといった香ばしそうなライブラリが同梱されていました。

それで、作ってみたのは下の図です。自分の持っている初代の Model B までパーツ一覧に入ってて嬉しい。

これは回路図とは呼ばない気がします。呼び方すら分かりません。

とりあえず、GPIO#x → 抵抗 → LED → GND としとけば良さそうなので、単純に5組配線してみました。

コマンド

ラズパイで LED 制御っていうのは、もはや散々語り尽くされた感があるので、自分の覚書としてすら書いておく意味があまりない気もするのですけれど、一応書いておきます(・ω・`)

export GPIONO=27 # 制御したいGPIOの番号

echo $GPIONO > /sys/class/gpio/export            # これで制御可能状態になる
echo out > /sys/class/gpio/gpio$GPIONO/direction # たぶん電流の流れる方向だこれ

echo 1 > /sys/class/gpio/gpio$GPIONO/value       # 電流ON
echo 0 > /sys/class/gpio/gpio$GPIONO/value       # 電流OFF

echo $GOIONO > /sys/class/gpio/unexport          # これで制御可能状態をやめる

Raspbian には、最初から入っているかどうか分かりませんが、自分が使っているバージョンでは入っていた gpio というコマンドが使えるようです。

export GPIONO=27
gpio 27 export out
gpio 27 unexport

なんとなく触っただけですが、export と unexport、direction の設定がこれで出来るようです。

配線が終わり、まずはシェルスクリプトで

while :; do echo 1 > /sys/class/gpio/gpio$GPIONO/value; sleep 1; echo 0 > /sys/class/gpio/gpio$GPIONO/value; sleep 1; done

してみると、LED 一つを1秒ごとにチカチカすることができました！

どうせなので Ruby でやる

他所のラズパイを使ったLチカの記事は、大抵シェルスクリプトや Python を使ってますが、どうせなので Ruby でやります。…と言っても、↑のコマンドを呼び出すだけのものですが ;)

追記

記事を書きながらラズパイ上の mruby でLチカしてる人はいないかな、いるだろうなっと検索したところ、松本亮介さんが3年以上前にされていました。

人間とウェブの未来 – Raspberry PiのGPIOをmod_mrubyで操作してブラウザからLEDを光らせてみた

しかも自分のラズパイと同じモデルっぽいし、mruby-WiringPi を使ってちゃんと…！さ、さすが！

動かすぞい

キットについていた説明書やネットの情報を頼りに組んだら、すごく簡単にできました。

ソフトウェアからハードウェアを見える形で制御できるって魅力的ですね！

電流やらΩやら、その辺の計算は全然分かりません。とりあえず、最終的に GND に落とし込めばいい…という程度ですが、必要に応じて触っていければいいなぁと思いました。

駆逐艦の模型の探照灯に LED を埋め込んだりできたら楽しそう。

Ruby (とHSP)によるライフゲーム

投稿日: 2016年3月1日2016年5月8日投稿者: dyama

高校生の頃買った、奥村晴彦先生の「C言語による最新アルゴリズム辞典」で知ったライフゲーム。当時は C を覚えたばかりで、グラフィカルなソフトなんてほぼほぼ書けませんでした。最新アルゴリズム辞典ではグラフィックを使わず端末上の文字で各セルを表現するものでしたが、どうせなら綺麗な見た目でやってみたいと思ってなつかしの HSP でちまちま書いてみていました。そのキャプチャ動画を↓に載せています。

[embedplusvideo height=”356″ width=”584″ standard=”https://www.youtube.com/watch?v=iFUeLVTxWvc?fs=1″ vars=”ytid=iFUeLVTxWvc&width=584&height=356&start=6&stop=&rs=w&hd=0&autoplay=0&react=1&chapters=&notes=” id=”ep3525″ /] [Lifegame – YouTube]1

マウスを押下した場所に R ペントミノを配置することができるので、安定期に入ったセルをかき混ぜて遊ぶことができます。タイムスタンプを見たら10年以上前ですね、こわい。

HSP の動かせる環境がないので動確はしていませんが、元になった(はずの)コードを貼りつけておきます。 (ところで、HSP をやっている人って今いるのかな？)

最近に Ruby で書いてみたものも掲載します。

手元の環境(PuTTY経由)では、カーソルの表示・非表示のエスケープシーケンスが上手く動いてませんね。

鎮守府史跡探訪〜陸軍佐世保要塞石原岳堡塁〜

投稿日: 2016年1月23日2018年12月12日投稿者: dyama

色々とお世話になっている920さんの運転する車で、長崎県西海市にある陸軍・佐世保要塞の石原岳堡塁に行ってきました。

920さんのお兄さんの吉川拓朗さんは、去年話題となった「佐世保軍港クルーズ」で船上ガイドを勤めている方で、佐世保の歴史・特に明治期以降について大変お詳しい方です。今の季節は寒いので軍港クルーズの定期運航はないようですが、この日もチャーター便での出航があったようです。そんなお兄さんのご提案で、夕方から「石原岳堡塁」に連れていってもらえることになりました。

石原岳堡塁は森林公園として整備されていて、地図を見てもわかるとおり、ちょうど佐世保港の入口付近にあります。敵艦の侵入に備えて陸軍が明治期・日露戦争の頃に設営した堡塁らしいです。

佐世保から西海橋を経由して北西に進むとあります。佐世保に住んでいてもこちら方面には用事がないため、ほとんど来たことがありません。さいかい交通のバスすら久々見た感…。

公園に到着すると、周りを緑に囲まれた自動車が数台止められそうな駐車エリアがあり、その奥に上の写真のような史跡が見えていました。想像以上にちゃんとしている！

駐車エリアに設置されていた立て看板です。

この堡塁は、記録によると、佐世保軍港防衛のために1897年（明治30年）10月21日に起工し、1899年（明治32年）12月31日に竣工したもので、全面積は約2haあります。標高73〜77mに備えられた砲種は、クルップル式10センチカノン砲6門、鋼製9センチ臼砲4門、砲座数は7基となっておりました。この後、1929年（昭和4年）6月14日には、陸軍の台帳から全部が除籍されました。（佐世保要塞築城史より）

日清戦争が明治27〜28年、日露戦争が明治37〜38年なので、ちょうど艦隊戦でドンパチやっていた頃に設営されたようです。お兄さんのお話によると「太平洋戦争の始まった頃は日本の海軍力が増強・制海権もしっかりして、このような本土防衛のための対艦射撃施設は不要になっていたのでは」とのご説明がありました。

なるほど、太平洋戦争時期に佐世保湾に敵艦が入ってくるような状況ではもはや日本が負けているような状況でしょうし、昭和初期の陸軍は既に大陸への進出を伺っている頃合いでもあります。昭和4年に除籍されたことに納得がいきました。

堡塁は一段低く掘ったコンクリートと石積みの堅牢な壕の中にたくさん並んでいました。木々が生い茂る小高い山の中にこんなに立派な建造物があるのは、まるで異世界に来たみたいな感覚。思わず「おおっ」と声をあげてしまいました。

並んだ堡塁の向かって左手には、地下へとゆるやかに下るトンネルが…。

中に入ってみると、外よりは少し暖い感じがしました。なんだかミステリーハンターになった気分です（笑）。 30メートルほど奥に進むと、突き当たりが二手に分かれており、それぞれ小部屋がありました。

50mm の単焦点レンズしか持っておらず、小さな空間を全体で撮ることができなかったので分かりづらいと思いますが、壕の中に侵入してきた敵を射撃するトーチカのようでした。

分厚い石造りの壁に空けられた小窓からは外が伺えます。

辺りも薄暗くなっておりブレてしまっていますが、トンネルを出て外堀の中を進むと、トーチカを外側から見ることができました。

駐車エリアにあった案内板です。中央にある堡塁跡から左上に描いてある説明書きがないイラストの部分にあるトーチカまで地下トンネルで行き来できるようでした。

この案内板にはテントのイラストや、トイレ・炊事棟が描かれているので、この堡塁にも泊まることができるのかな、と思いました。

九州でも大雪となる前日の寒い日だったので、自分たち以外の利用者はなく、とても静かでした。

mruby で有理数を扱う mruby-rational を書きました

投稿日: 2015年12月18日2016年1月10日投稿者: dyama

本家 CRuby の Rational クラスは、バージョン 1.9 から require せずに使えるようになっていますが、mruby では本体に組み込まれておらず、該当するような mrbgem も見つからなかったので書いてみました。

dyama/mruby-rational

mruby はかなり基本的な機能以外は徹底的に削ってあり、組み込まれた機能も ISO に準拠するような形で実装されています。

Ruby の ISO を確認したところ、Rational クラスは特に入ってないみたいでした。ということで、mruby-rational では挙動を CRuby 1.9.3 のリファレンスに合わせるように書いています。

mruby-rational を使うと、次のように有理数を用いた計算ができます。

a = Rational(1, 4)
  => (1/4)

b = Rational(2, 3)
  => (2/3)

a + b
  => (11/12)

(a + b).to_f
  => 0.91666666666667

x = Rational(1, 3) * 2
  => (2/3)

y = Rational(1, 2)
  => (1/2)

x * y
  => (1/3)

CRuby では rational.c として C で実装されていますが、mruby-rational は Ruby だけで実装しています。必要となるメソッドが Ruby だけで十分そうだった点、せっかくコンパクトな mruby の実装なのだから、gem のコードも簡潔に書きたかった点、などなどいろいろ理由はありますが、本当は自分の書いたコードにあまり自信を持ってないので、風通しをよくして他の方でもバグを見つけてもらいたいな、といった狙いもあります。

中で行なっている約分では、最大公約数を見つけるのにユークリッドの互除法を用いています。

既知の問題点(2015-12-18時点)

ある程度、CRuby の Rational と区別して切り分けして使う分には使えると思いますが、まだまだ互換性がありません。今日までのところ、計算上の精度まわりもチェックをしていませんのでこれから叩き上げたいところです。

Rational.initialize が外に出てる

Kernel.#Rational からインスタンスを作成する際、Rational.convert 経由で普通に Rational.new しています。つまり外からも new が叩けます。 CRuby だったらアクセサで隠して send でぶっ叩いたり、caller で呼出元によって例外を吐いたりと色々方法がありそうですが…。もう少し勉強してなんとかならないか考えます。

ちなみに CRuby の rational.c では、rb_undef_method(CLASS_OF(rb_cRational), "new") しておいて C 関数でインスタンス作っているようです。ずるい！

inline static VALUE
nurat_s_new_internal(VALUE klass, VALUE num, VALUE den)
{
    NEWOBJ(obj, struct RRational);
    OBJSETUP(obj, klass, T_RATIONAL);

    obj->num = num;
    obj->den = den;

    return (VALUE)obj;
}

Rational.convert も private じゃなく形式的に CRuby と合わせているだけなので、利用者サイドの観点からすると不要なのかもしれません。

初期化時に投げられる引数の種類が少ない

個人的に Rational クラスに求めているものは、分子と分母のペアなのでさほど困りはしないのですが、mruby-rational では今のところ

Rational(2, 3) # => (2/3)
Rational(5)    # => (5/1)

という作り方しかサポートしません。つまり、下記のように文字列を一つ渡す

Rational('1/3')  # => (1/3)
Rational('0.33') # => (33/100)

ではエラーとなります。CRuby では、string_to_r_internal() でガリガリやっているっぽいです。また、CRuby では

Rational(0.3)
  => (5404319552844595/18014398509481984)

となる Float を一つだけ取る初期化も

Rational(0.3)
  => (5.4043195528446e+15/1.8014398509482e+16)

という具合にBIGNUM周りの違いが出ています。

Complex クラスとの整合性はとらない

CRuby では、Complex 型を取り扱う挙動も rational.c に含まれていますが、これはそのままでいいんじゃないかな、と思っています。

なんとなく方向性は分かってきたので、少しずつ手を入れていきたいと思います。

mruby から Lua を呼び出すための mruby-lua を書きました

投稿日: 2015年12月8日2015年12月9日投稿者: dyama

mruby は、こちらでも述べられているように組み込み言語として広く使われている Lua を強く意識した実装になっています。

mruby も Lua もそれぞれ、他システムに組み込むのが簡単ということだけあって、多からず相互利用の試みは mruby が登場した当初からあるようです。

Lua から mruby を呼ぶのは、ngx_mruby などでちらほらお名前を見かける松本亮介さんが「Lua上でmrubyを動かすための禁断のLuaライブラリを作った」という記事を3年以上前に書かれています。

人間とウェブの未来 – Lua上でmrubyを動かすための禁断のLuaライブラリを作った

matsumoto-r/mruby-on-Lua

禁断とされている（勝手な思い）Lua上でmrubyを動かす

と、なんだか言葉を濁しつつ書かれているところを見ると、mruby 界隈に暗に「打倒 Lua」の風潮があるのではないかと邪推しちゃいます…(笑)。

また、

RyanScottLewis/lua-mruby

というのもあるようです。(これも3年以上前)

時間をかけて調べたわけではないですが、mruby 側から Lua を呼び出す形のちゃんとしたものはなかったようなので、試しに書いてみました。

それまで Lua といえば、漠然と「オンラインゲームの AI スクリプトとして使われている軽量言語」というイメージしかありませんでした。昨日、Lua の具体的な構文も知らないまま、とりあえず C と C# から Lua を使うデモコードを書いてみたら、なるほど簡単。自分なんかでも、2つの言語環境のライブラリのダウンロードからコーディング、実行まで数十分でできてしまいました。

言語仕様もコンパクトに抑えられ、API ではスタックを使って(ちょっと煩雑になる部分はあるにしろ、考え方そのものは)シンプルにコーディングできます。組み込みスクリプト環境に求めるものや規模にもよるとは思いますが、大抵の場合 Lua で事足りるのも納得できます。

拡張性が高く、ポータビリティもよく、言語の中身自体も簡単で敷居が低い Lua は魅力的ではありますが、それはあくまでもダイナミックに保持しなければならないリライタブルなコード部分を限定する場合に限るんじゃないかな、とも思います。というのも mruby を使うと、「スクリプト機能」という部分的なものだけではなく「システム全体を Ruby の上で書く」ことも、より容易になると考えているからです。柔軟で高次元な言語基盤を持つ mruby をグルー言語として使い、その上で各種アプリが動作する形がメンテナンスの上でも生産性の高さでも強みになりそうです。

mruby も Lua も Windows や組み込み機器といった「スクリプト環境の砂漠地帯」に持っていくための良いツールになります。目的の用途にあった形でお互いを上手く利用することができたらいいな、と思いました。

mruby-lua について

Github で公開しています。Lua5.2 を使っています。

dyama/mruby-lua

README.md に書いてあること以上でも以下でもないので、ここであんまり書くこともないんですが、mruby から Lua VM を呼び出して実行することができます。

Lua#dostring は Lua スクリプトを含む文字列として、 Lua#dofile は Lua スクリプトファイルのパスを受けて実行します。 Lua#[] と Lua#[]= は、Lua 上のグローバルなオブジェクトを取得・設定することができます。昨日 Lua を触りはじめて mruby-lua を書いてみて今日なので…まだ mruby と Lua 上の型を相互変換している箇所において一部対応していない型があります(2015/12/8現在)。

より高級な mruby が動く環境で Lua スクリプトを呼び出すことにどれだけの意味があるかは分かりませんが、Lua スクリプトをデータ記述言語として使う既存のシステムとのやり取りとか…何かに使えるのかな…。

mruby-regexp-pcre の String#gsub について

投稿日: 2015年12月4日2015年12月25日投稿者: dyama

IIJ さんが開発している mruby 向けの正規表現ライブラリ iij/mruby-regexp-pcre を使ってたら、本家 CRuby と違う挙動の部分を見つけました。

# 文字列の先頭に空白が含まれている場合、それを取り除く。
"foo".gsub /^\s*/, ""

上の "foo" の場合では、先頭に空白は含まれていないので、そのままの文字列 "foo" が返ってくるはずです。 iij/mruby-regexp-pcre を使うと、これが空の文字列 "" として返ってきてました。 CRuby1.9.3 でチェックしてみたところ、"foo" が返ってきています。

最初は mruby の String#gsub の問題かなと思って mruby/mruby のコードを追っていましたが該当箇所が見つかりません。よく考えてみたら、正規表現ライブラリは mruby の基本実装には組み込まれていないはずなので mruby/mruby に問題箇所があるわけがありませんね。2013年の下記の issue を見てみても、「正規表現ライブラリはちゃんと切り分けて、String#gsub なんかの挙動は拡張側で適宜上書きしようぜ！」という流れが見てとれました。(英語苦手だけど)

Library independent RegExp ・ Issue #841 ・ mruby/mruby

また、一瞬だけ本家 CRuby で使用している正規表現ライブラリは鬼車であって、mruby-regexp-pcre は PCRE である違いも考えましたが、

"foo".gsub /^\s*/, ""

で空文字が返ってくるのは、そもそも使用しているライブラリ以前の問題のような気がしました。

ということで、iij/mruby-regexp-pcre の該当コードを読んでいると String#gsub を上書きしているコードがありました。対象部分をデバッガで追ってみると、位置指定子(^)があるにも関わらず、1文字ずつ正規表現マッチ→マッチしたインデックスだけを用いて(空文字で)置換→元文字列がなくなるまでくりかえし、という挙動をしていたため、恐る恐る issue を投げてみました。 (颯爽と手直ししてプルリクできるくらいの能力がどこかに落ちてないでしょうか！)

2015/12/7 追記

レポートしておいた部分をしっかり修正していただけました！感謝多謝です。

C++のクラス宣言の文法について

投稿日: 2015年9月23日2015年9月23日投稿者: dyama

C++ビギナー向けに書いた文章です。

C++の入門書では、クラスの書き方を次のように教えているものが多いと思います。

class MyClass
{
  // ...
};

int main()
{
  MyClass foo = new MyClass();
  // ...
}

クラス定義と呼び出しを分けて記載されています。これ、初めて見た時に文法が覚えにくい気がしていました。クラス定義の一番最後の「;」を忘れてコンパイルエラーになることもしばしば。

C#では、同じクラス定義でも

class MyClass
{
  // ...
}

と、一番最後の「;」は必要ありません。それどころか付けているとエラーになります。

C++ ではなぜこのような文法なんでしょうか。

答えは C++ の文法は C を踏襲しており、C にこそその本質があります。 C ではクラスは存在しないため、同じメンバを持つ入れ物である構造体の宣言文法と置き換えて説明します。

メンバを持つ型定義の基本形

C においても、多くの入門書では構造体の宣言を次のように複数行に分けて書くことが多いと思います。

struct {
  int x;
} foo;

これだと文法が分かりづらいため、一行にしてみましょう。

struct { int x; } foo;

はい！一行になりました。それぞれの変数名などをより一般的な用語に置き替えると次のようになります。

struct { メンバ定義 } 変数名;

さらにこの宣言文を抽象的に書くと

型 変数名;

という形に集約することができます。お気付きでしょうか？

int n;

などの通常の変数と同じ文法です。つまり、struct { メンバ定義 } の部分はただの「型」なのです。

struct { メンバ定義 } 変数名;
~~~~~~~~~~~~~~~~~~~~~
    ↑ ただの型

この形をよく覚えてください。これを基本形だと考えればいいでしょう。

コード例

基本形を用いたコードの例です。

int main()
{
  struct { int x; } foo;
  foo.x = 123;
  printf("x = %d\n", foo.x);
  return 0;
}

struct { int x; } の部分はまるごと型を表しているため、struct { int x; } 型の変数 foo が使われているのが分かると思います。

タグ名

さて、C の文法ではこの宣言した構造体に別名(タグ名)を付与することができます。

struct Hoge { int x; } foo;

Hoge の部分がタグ名です。この宣言以降は

struct Hoge bar;

という文法で、{ から } までの定義部分を書かずに用いることができます。

さらに、変数を宣言せずに型のみを宣言する場合は、

struct Hoge { int x; };

とし、変数名を省略します。

コード例

タグ名を用いたコードの例です。

int main()
{
  struct Hoge { int x; };
  struct Hoge foo;
  foo.x = 123;
  printf("x = %d\n", foo.x);
  return 0;
}

3行目で構造体の宣言と定義のみを行い、Hoge というタグをつけています。 4行目でさきほどつけたタグを元にして、変数 foo を宣言しています。

typedef

少しよりみちになりますが C は文法上、型名 struct Hoge の struct を省略することができません。つまり、

struct Hoge foo;

は正しい変数宣言。

Hoge foo;

はあやまった変数宣言となります。そこでよく用いられるのが型名に別名を与える typedef です。

typedef int abc;

と書いておくと、それ以降は

abc n;

は

int n;

として解釈されます。一見、#define マクロのように名前が置換されただけのように見えますが、typedef はプリプロセッサレベルではなくコンパイラ（構文解析器）レベルで正しく「型」として認識されるため、より安全なコードを書くことができます。

さて、この typedef を用いて struct を書かずに済む宣言をしてみましょう。

typedef struct { int x; } Hoge;

先ほどの基本形と似ていますが、typedef の構文であるため、別名は末尾になります。（変数名と混同しないようにしましょう）これでコード中で

Hoge foo;

と書くと、

struct { int x; } foo;

として解釈されるようになります。なお、C++では typedef を行わなくても struct を省略する事が可能です。

C++ で

C++では、C文法の上位互換がありますので、

struct Hoge { int x; };

という構造体宣言・定義がそのまま使えます。

この文法をそのままクラス定義にも用い、

class Hoge { int x; };

といった記法を行うわけです。末尾にちゃんと「;」がいますね。構造体と同じ文法である以上、クラスも

class { int x; } foo;

という具合に無名クラス、変数宣言付きの記述も可能になっています。

C/C++の構造体・クラスの宣言は、ひとつの「文」として記述しているわけです。

C# では

C#ではCやC++に似た文法を採用しつつ、構文解析がより具体化しています。

class { int x; } foo;

のようにクラスの定義と変数の宣言を同時に行うことはできず、

class Hoge { int x; }

というクラス名・タグを持つ宣言のみに限定されています。変数を宣言する必要がないという理由からか、末尾の「;」も付けません。C/C++ では「1文」だったものが、C# では「1節」になっています。

CやC++では煩雑になりがちな型の宣言や変数の定義を文法上制約して、できるだけすっきりとした構造にすることが目的だと考えられます。

ただ、C# では

int Main()
{
  class Hoge { int x; }
  // ...
}

という具合に、メソッド内でのみ利用したい「使い捨て」クラスを文法上定義することができなくなる弊害が出てしまいました。

これが実際に問題になっていたのか、C# 3.0 から「匿名型」という文法が導入されました。

var foo = new { x = 0 };

明示的にメンバの型を指定することができなかったり、型を決定するために初期値を指定しなければならなかったりと色々と残念な状態になっています。

また、

int x = 0;
var foo = new { x };

という初期化、型決定、メンバ名の決定というもはやカオスな機能を提供していたり、動的にヌルヌルしているかと思えば一方で

var foo = new { x = 0, y = 0 };
var bar = new { y = 0, x = 0 };
// foo と bar は宣言（定義？）順が違っているので別の型

という C の構造体かよ！と勢いよくツッコミを入れたくなる仕様だったりします。

文法という側面だけを見ても、ラムダ式や Func 型など、他にもいろいろと首をかしげる部分が多い言語です。 Java を駆逐し、Ruby や Python のような柔軟性を模索していると言えば聞こえがいいですが、他の言語に比べても後手後手にまわっている Microsoft の「商売戦略仕様」が見え隠れしているのは気持ち良いものではありません。

艦船キットコレクション Vol.6 スリガオ海峡 1/2000 駆逐艦「山雲」

投稿日: 2015年8月31日2015年8月31日投稿者: dyama

エフトイズの艦船キットコレクション Vol.6 スリガオ海峡 1/2000 駆逐艦「山雲・満潮・朝雲」のうち、山雲を作りました。これら3つは同型艦ですので、一つのキットの中に同じモデルが3組入っています。

山雲は朝潮型駆逐艦6番艦。スリガオ海峡にて米駆逐艦の魚雷攻撃を受けて轟沈、乗員全員が戦死している艦です。昭和18年、祖父が乗っていた潜水母艦「長鯨」を護衛しつつ日本本土に戻る際に以下のようなエピソードがあったようです。

11月中旬、「山雲」は駆逐艦「若月」と共に日本本土へ向かう巡洋艦「鹿島」と潜水母艦「長鯨」を護衛する。19日、「山雲」は船団を追跡していた米潜水艦「スカルピン」を発見する。「山雲」は爆雷攻撃を加えて「スカルピン」に損傷を与え、浮上した同艦を砲撃により撃沈した。「山雲」は米潜水艦乗組員42名（41名とも）を救助した。乗組員達は「龍田丸」の仇を討とうと色めきたったが、小野(山雲艦長)はそれを制して救助を行い、コーヒーやトーストをふるまったという。

その後、スカルピン乗員は捕虜として空母「雲鷹」「冲鷹」に分乗して本土に輸送されている途中、米潜水艦により冲鷹は撃沈。乗っていたスカルピン捕虜21名のうち救助されたのは1名だけだったそうです。戦時下とはいえ、なんとも切ない話です。

自分が購入したものはフルハルVerでした。それでもパーツ数は18個と非常に少ないです。（洋上Verは13個）

実物は全長118メートルの特型並みに大きい船体。モデルは10円玉と比較しても非常に小さいのが分かります。細かい作業が苦手な自分でも20分程度で組むことができました。いつもどおり、部品を切り取って接着するだけの素組みです。

アップの写真で見ると、さすがにモールドが甘い気がしますが、プラスチックモデルの、さらに食玩というジャンルでこのクオリティはいつも凄いなあと感心していしまいます。

12.7センチ連装砲や61センチ4連装魚雷発射管がコンパクトに配置されている姿が格好いいです。レイアウトに比較的余裕があって艦ごとにまちまちな戦艦よりも、太平洋戦争中〜後期に竣工した軽巡・駆逐艦の姿はしっくりと安心感がある形をしていて大好きです。

なお、艦船キットコレクションは Vol.7 が既に出ているようですので、積み艦を早くこなしていかないと…。