AURのpandoc-static

AURのpandoc-staticパッケージが更新できず詰まっていたので、記載。

pandoc-staticがicu<54を要求しているために起きていた。 この問題は既に報告され、修正したとしているが、それでも以前問題があった。

更新のしようがなくなってしまっていたので、pandoc-staticを削除してからアップデートし、そしてpacndoc-staticを入れなおす。

だが、GnuPG鍵が確認できず、エラーになる。 これも解決したとしているが、解決されていなかった。

gpg --keyserver pgp.mit.edu --search-keys fauno

でいけた。

ガラケー(フィーチャーフォン)が生産終了

論点

日経新聞の報道によって、フィーチャーフォンが生産を終了しAndroidに一本化するということでネットがざわめいている。

今回はこの問題について掘ろうと思う。

日本のケータイはITRONの時代が長かった。 2GまではだいたいがITRONだったからだ。一番大きいのは、docomoのmovaがmTRONだったことだろう。

3Gのフィーチャーフォンは、より汎用性が高いという理由でSymbian OSとなっている。

NECとPanasonicはLinuxベースの独自OSだった。 昔もSymbian OSのケータイは存在していたし、百花繚乱の感がある。

ここで「ガラケーを終了し、ガラケー型のスマホ「ガラスマ」に移行する」という説明に無理があることがわかる。

スマートフォンの定義は何か。 ガラケーの定義は何か。

今までフィーチャーフォンであれ、eLinuxを積極的に使ってきたのである。そして、OSも固定ではなかったし、一方で独自開発という前提があったわけでもない。 その意味では、I-TRONからSymbian OSへの移行同様のことだとみなしてもよい。

問題は次の二点だ。

  • フィジカルキーは残るのか
  • Androidに集約される

それぞれ述べる。

問題点

フィジカルキー

人々の意識の中でスマホとガラケーを隔てるものはフィジカルキーの有無ではなかろうか。

実際、Androidはフィジカルキーを当初想定していなかったし、そのためにSHARPは中国市場にAndroidベースのOSで「ガラケー風」のスマホ(ここでいうガラスマ)を提供するためにAndroidにかなり手を加えたという。

現在はAndroidはフィジカルテンキーをサポートするが、それでもタッチ主体の思想であり、フィジカルキーのサポートはかなり乏しい。

そのため、物理キーボードに関してはかなり制限される。

かつて私が使っていたW21S(Sony Ericson)はジョグダイアルを採用、さらにPOBoxの非常にアグレッシヴな予測変換により、PC並の入力速度を手に入れていた(ほとんどテンキー入力が不要なレベルで、文章の平均タイプ文字数は3だった)。

指をなぞるだけで大抵の打ちたいないように届く。今のAndroid(Mozc)の変換よりもはるかに精度が高く、一覧性もいいため予測変換が非常に使いやすかった。

こうしたハードウェア的な柔軟性がAndroidはあまりない。 構造的にできないのではなく、その仕組みがないだけなので、手を入れれば将来的には可能だが。

また、世の中にはiPhoneからはじまったタッチ信仰があるため、フィジカルキー付きのケータイをバカにする傾向はかなり強い。

とはいえフィジカルキーにこだわる人は多いので、このあたりはある程度は対処されるだろう。 だが、ジョグダイアルの復活はほぼ望めなくなったと言っていい。

Android

Androidは原則、Googleアカウントとの紐付けを要求する。と同時に、その登録時にはGoogleが個人情報を収集し、利用することに同意するよう迫る。

これはAndroidを素の状態で使うとよくわかる。 一方、Androidがプリインストールされているスマホはその手順がないため、紐付けられない状態で利用可能だ。

だが、その状態でもGoogleアカウントでなく携帯電話のIDで送信されているだけだ。そのアクセスを停止するとまともに機能しない。

そして、Playストアを利用しようとするとGmailを登録しろと言われる。この時点で紐付け完了だ。 最近は、支払い方法を選択する必要があります、や電話番号を登録する必要があります、などといってさらなる情報を提供させる。 スキップ可能なのだから、かなり悪質だと思う。

それに対して、基本的に「したことしかしない」フィーチャーフォンの安心感は非常に強い。

また、近年は改善が進んでいるようだが、リアルタイム性の高いケータイメールが使えないのは、私にとっては決定的だ。 (私のスマホは使えるが、彼女のものは古いために使えないようだ)

この、「ケータイとしての利便性に劣る」「プライバシーの管理ができない」という点でAndroidへの集中は非常に困る。

「ガラスマ」

SHARPは先に、「ガラホ」を名乗るAQUOS K SHF31をリリースした。

「Androidのガラケー」である。

Androidでありながら、Googleアカウントに対応しない(だからストアも使えない)。 しかも、通じようであればその設定が制限される次元でメーカー側がアプリの動作を厳しく制限することで、意図しないバックグラウンド通信を制約している。

まずこの点で、プライバシーの観点から見て、まさにガラケーである。

さらに、タッチに対応しない、フィジカルテンキー付きの、まさにガラケーの外観をしている。

Androidの使い勝手のため、キーパッド全体をタッチパッドとして使えるという工夫があり、Androidブラウザを使用するが、それはフィーチャーフォンとしての進化の範疇だろう。

使い勝手の面でも、キーはフィーチャーフォンらしい仕様となっている。おそらくは、ショートカットキーの動作も作りこまれて、「フィーチャーフォンの使い心地」そのものなのだろう。

このように「真面目に作りこんだガラスマ」がいかに出てくるかによって、それは被害なのか進化なのかがわかれることになりそうだ。

hp pavilion x2 10 修理へ

hp Pavilion x2 10のカメラが動作しないために、修理送りとなった。

Skype for Windows Desktop起動時に「全面緑」で動作しない。カメラはインジケータランプはついているのにだ。 Firefox Helloで試すと真っ白。

そして、今回はチャットサポート。 前回と同じ方の対応で、やりやすかった。

「カメラ」アプリでテスト、ドライバ削除からの再起動、BIOSリセットからの再起動と試したものの改善せず、引き取り修理へ。

ついでに、先の液晶の傷?問題も見てもらうことに。

2時間もお付き合いいただき、ありがとうございました…

しかし、私、ハードウェア不良ひく確率高くないか。先日もカメラ初期不良で送ったばかりだし、その前はThinkPadをファクトリー送りにしたし、電熱スリッパも送ったし、なんか憑いてる。

LGディスプレイの顛末

まぁ、次の通りだ。

LGの回答
LGの回答
  • 色がおかしい→否定&交換(下記と同一)
  • 画像がおかしい→肯定&交換
  • アダプタが鳴く→否定&交換

結果としては

  • 画像がおかしい、という点は直った
  • 色はやはり白いが、色が出ていないという部分は直った
  • アダプタの鳴きは多分直った
これでみても右が白っぽく色も出ていない
これでみても右が白っぽく色も出ていない

結論としては

  • フォームで散々サポートを拒否した上、今回も受け取りも経過報告も一切なしで送ってきたので、結構苛立つ
  • 製品品質もひどい
  • 今後LG製品を買うことはないだろう
  • 素直に交換されているので、最終的にはダメだったわけではない(品質は悪いが)。経過や品質を気にしない人はいいと思う。
  • 少なくとも詐欺商品の類ではない
  • 品質に関して、高級なやつは違うのかもしれないけれど、それは分からない。22EN43と22EN33がこれだけ品質が違うので大いにありうる

Linux Tips

YouTubeのプレイリストからタイトルを抽出する

結局使わなかったのだが、ワンライナーで書いた。 比較的素直なHTMLなので解析は簡単。行指向ではないので、PerlでなくRubyにした。

$ curl 'https://www.youtube.com/playlist?list=<playlistid>' | ruby -e "s = STDIN.read" -e 's.scan(/<a class="[^"]*pl-video-title-link[^"]*"[^>]*>(.*?)</m) {puts $1.strip }' | grep -v 動画は削除されました

ffmpegでh.264/aacな360pのmp4を

元動画は1080pのmovまたはmp4。 オーディオはいじらず、元々aac(ac3)。

$ ffmpeg -i <infile> -vcodec libx264 -s 640x360 -crf 34 -strict -2 <outfile>.mp4

ちなみに480p(16:9)は720×280。 -crfの値は18-28が推奨されている(小さいほど高ビットレート)が、今回はモバイル向けなので34を指定。

なお、6の増減でビットレートはおよそ1:2の変動となる。

ffmpegでCowon M2向けの動画を作る

COWON M2はXVidとmp3のAVI動画で、解像度は320×240またはWMVをサポートするとある。

WMVだと結構サイズが大きいので、AVIで作る。 ソースは前回と同じくh.264*ac3のMOVまたはh.264*m4aのmp4。

$ ffmpeg -i <infile> -vcodec libxvid -acodec libmp3lame -b:v 372k -b:a 128k -s 320x240 <outfile>.avi

随分としょぼい解像度の上にアスペクト比も壊れる(プレイヤー側で調整することは可能)が、案外見られる。 ただし、360pでも細部は潰れてしまっているのでよく分からない部分は出てしまう。

XineのUIの文字化けを直す

fontにHerveticaを要求しているので、フォントエイリアスを設定すれば良い。

hp Pavilion x2 10

Pavilion x2 10
Pavilion x2 10

概要

hp Pavilion x2 10はhpが2014年10月に発表したDetachable 2in1 PCだ。

BayTrail-M世代のAtomプロセッサとWindows 8を組み合わせるもので、1kgを切る軽量さと、39800円(税別)という低価格が特徴だ。

購入動機は、e440が重かったからだ。

本来、音楽を軸に活動するつもりであり、モバイルの携行ということは視野になかった。 仮にコンピュータを主軸とするとしても、モバイルが必要なライフスタイルではないと思い、稀に携行する程度であれば2kgを越えるe440でも問題ないと考えていた。

だが、実際は、「PCが必要かどうかはわからないが、営業のためにあったほうが良い」ケースは多々有り、 e440を携行していたが、体を壊すことが多すぎる。

そこで、やはりモバイルPCは必要だという結論に至った。

元々はPanasonicのRZ4が欲しかったのだが、18万円級というと前倒しで投入できるようなものではない。 そこで、軽量で使える、なるべく安いもの、かつ操作性に差がでるラップトップだけに、その点も考慮して選んだのが、私が信頼するhpのPavilion x2 10だった。

10.1インチというモバイルとしても小型のラップトップ、 さすがに750gと超軽量なRZ4にはとても敵わないが、それでも960gとかなり軽い。

検討はしたものの、それほど深く考えずに買った。 だが、これが思わぬ伏兵だった。

ちなみに、クーリエ保守3年をつけたため、トータルでは6万円を越える程度だった。

性能

性能面では、AtomプロセッサなのでCPUは速くない。 Core Mプロセッサは動作周波数は低いが、Core i5並の性能を出しているようなので、それと比べても遅いかもしれない。

また、何よりRAMが2GBしかないので、下手な使い方はできない。 さらに、eMMC32GBというストレージはその使い方もかなり制約される。

つまり、考え方を変える必要がある。

「これはタブレットである」

スマートフォンで全力のコンピューティングをしようと考える人が稀であるように、タブレットでもそれは変わらない。 Surfaceが全てをまかなえるようなPRをしているが、実際はそうはいかない。

メインマシンが他になければ成立しないモバイルだ。 実際、細かな打ち合わせやデモンストレーションを行う時はe440を持参することになるだろうから、2台どころか3台目である必要があるということになる。

はじめてのコンピュータに勧めるようなものではない。 あくまでも「モバイルのためのもの」だ。

1280×800という画面なので、なおのこと常用は厳しい。

携行

携行性は、960gで大変に良い。

ただし、恐らく手に持った時にまず驚くだろうと思う。 重いのだ。 この重いというのは、片手で縁を持った時の重量感がe440と同じくらいだ、ということを意味する。

だが、バッグにいれて携行する場合は話が全く別だ。

だが、それだけであれば「軽いが、最高に軽いわけではない」で終わっていた。 ここにDetachableである強みが加わった。

軽量である上にむき出しで携行されることを前提にしたものであり、コンピュータバッグで携行しなくても、百均のクッションポーチで携行できる。

e440をアンチショックケースとPCバッグの組み合わせで持ち運ぶと4.4kgほどになる。もちろん、大きな専用バッグを含めてだ。 対して、x2 10ではその重量は1kgをわずかに越える程度であり、既存のバッグに入れることもできる。

加えて、detachableである以上、キーボードを外して使うことができるし、必ずしもキーボードはなくても良い。 キーボードを必要とする状況が想定されないなら、キーボードを外して、そもそも持たないという選択肢もあるのだ。

ちなみに、実測値はキーボード側が322g、本体は606gとのこと。

hpは実測に近い値を掲載値としていることに交換が持てる。

タブレットとして使える、というメリットは案外大きく、先日は電車で立っている間はタブレットとして使用し、吸われた時にキーボードを装着して使用した。

RZ4のようなConvertibleタイプだとキーボードは裏側にくるため、タブレットにした時に重く、持ちにくい。

実はマイレージ性能が素晴らしい。 11時間45分としているが、動画連続再生で11時間を越えたデータがある。RZ4は17時間以上を公称するが、同様の方法で11時間台にとどまる。

このマイレージ性能の素晴らしさに対して、Windowsの起動が速く、またWindows 8がモバイル的な仕様に対応しスリープが高速化されていることからAndroidスマートフォンのように使える。

そして、本当にもつ。

microUSBで充電するが、供給電力は4A+… モバイルバッテリーでの充電は難しい。停止すればいけるか。

キーボード

このPavilion最大の特徴が、キーボードカバーだ。

それが特徴たる点としては、まず布であることだ。布でタブレット自体をカバーする構造で、しかも全体はカバーしない。

さらにこれがドックであり、スタンドでもあるという。 これについては後述する。

キーボードは10インチに詰め込んだにしてはオーソドックスなものとなっている。

多少気をつける必要はあるが、普通に打てるし、扱いにくいラップトップが多い昨今としては結構快適だ。

ただ、PageDnやEndなど、私が多用するキーがFnとの組み合わせになっている点だけちょっと困る。

ファンクションキーは機内モードもあり使いやすい。

タッチパッドはクリックのないものでやや使いにくい。

マルチタッチによるスクローリングがSynapticsとは逆(画面タッチと同じ)になっていることに戸惑う。 ちなみに、エッジに関しては画面に対するものと同じスワイプ効果をもたせている。

Bluetoothではなく優先接続なので確実で素早く、さらにBluetoothのチャンネルを消費せずに済む。

変形

キーボードカバーに端子が出ており、タブレットをここに合わせる。マグネットがあり、吸着するのでつけやすく外れにくい。タブレットを持ってキーボードを持ち上げることは問題ない。

キーボード側は拡張端子を持たない。キーボードを外すことで機能が制限されることはない。

キーボードカバーはマグネットを持ち、これがタブレット背面に吸着する。だから、カバーの状態ではしっかりカバーされて外れることはまずない。

そして、これがスタンドになる。吸着位置はカバーになるところを含めて3箇所、つまりディスプレイ角度は2段階。

無段階調整できないのか!と思ったが、意外と困らない。

ちなみに、非公式な方法としてフラップを内側に折ればもう2段階調節できる。

このスタンドが本体よりうしろにはみ出すので接地面積が増える…というが、立体的に考えるとその上に本体がくるわけで、そんな小さな斜めの空間に物があるなら、カバーを畳んでもたれさせればよい気がする。

この布カバースタンド、結構丈夫で、実はキーボード「も」支えられる。 つまり、PC使用中に筆記が必要になった場合に、キーボードを本体側に倒して畳み、奥に押し込んで手前スペースに筆記する、ということが可能。 狭い机を広く使える。

(クラムシェルならどけるしかないだろう。「縦に畳める」ために素早く出し入れできるということだ

x2 10 奥に畳む
x2 10 奥に畳む

さらに布なので、そのまま折り返して使用することができる。 hpは「スタンドモード」と称し、カバー底面の下にキーボードがくる、つまりむき出しのキーボードが机につく形の状態で利用可能としている。 動画を見たりSNSを見たりに適した状態か。タッチ対応なのでこの状態で操作可能。

x2 10 スタンドモード
x2 10 スタンドモード

hpらしいアイデアとサービス心にあふれたこのカバー、実に素晴らしい。

これの難点は、足の上では結構使いにくいこと、手持ちではタブレットにしないと使えないことだ。

Windows8 (BayTrailとLinuxとタッチディスプレイ)

実は私はWindows8のまま使用している。

なぜならば、Bay Trailの32bit UEFIへの対応が、Linuxでは(も)結構大変だからだ。

しかもタッチ関連のセットアップも結構大変だったりするので、とりあえず諦めた。Windows Tablet向けのチューニングがディストリビューションで提供されるようになるまでは放置、と考えたのだ。

だが、実はWindows8が結構よかった。

いや、私はWindows8は「一体何を考えているんだ」と思うほど苛つく代物だと思っている。

だが、タッチができるようになっただけでその印象は大きく変わる。なるほど、確かにタッチで使いやすいUIだ。

Linuxはキーボードを意識しているし、だからこそ速い。だが、キーボードを失った時、Linuxの標準的なUIは必ずしもWindowsよりも優れていない。

コマンドでの設定が可能なことについても、キーボードがないとあまりうれしくない。

だが、まずマウスでカーソルを持っていくことなく、パッとタッチすれば良い、というのは意外なほど「良い」。タッチパッドはなくても良いかもしれない、と思うほどだ。

腕の揚げおろしを考えれば手元のタッチパッドのほうが良いケースもある。特に、スクロールはほとんどの場合タッチパッドが良い。

だが、ウェブページの中にスクロールできるブロック要素がある場合などは、どちらをスクロールするかの調整はタッチディスプレイのほうがしやすい。

専用のファンクションボタンがあるような使い勝手だ、と言えば伝わるだろうか。 多分、これは10.1インチだからだ。30インチもあるような巨大ディスプレイでタッチするのは明らかにしんどい。

加えて、入力フォームに「タッチでフォーカスすると」ソフトウェア・キーボードが現れる。キーボードで入力するか、ESCキーを押すと消える。出し入れは任意にできる。 この仕様は、結構快適。自分がしようとしていることを一歩先んじて用意してくれる。

この点に関してはLinuxのタッチUIはほど遠い。ほとんどの環境でバーチャルキーボードは手動で出すものだし、Plasma Activeのキーボード出現タイミングはちょっとおかしいと言われている。

このバーチャルキーボードが結構使いやすいのもいい。記号に関しては基本的にわけられているが、数値へと切り替えた時に一緒に出てくる。テンキーモードは「on/off」であり、日本語入力も「on/off」である。スマートフォンよりもスペースがあるからだが、この方式は結構使いやすい。 特に、パスワードで記号も入れる私の場合、Androidでのパスワード入力はかなり辛いのだ。

ちなみに、Androidのいずれのキーボードとも異なる、もっと物理キーボードに近い配列も良い。 それでいて、数字のフリックもでるきようにはなっている。

また、Windows8はIMEの切り替えが可能になった。ほとんどの人には必要ないと思うが、かな入力にしている私の場合、バーチャルキーボードでかな入力は事実上できない(アルファベットキーしか表示されないため、打てないキーがかなりたくさんある)。そこで、MS-IMEはローマ字、Google日本語入力はかなにしている。これによって切り替えが可能だ。

※Google日本語入力はインスタントにローマ字とかなを切り替えることはできない

密かにMS-IMEは劇的に改善されている。こんなによくなっているとは驚きだ。

画面回転はいずれの方向に対しても自動。 回転は遅く、さらに事前アクションがあるため、素早くは変わらないが、あまり回転させるものでもないと思うので、意図せず回りにくいほうが嬉しい。

フォントレンダリングはそれなりに改善されたようだが、依然としてFreeTypeよりはるかに劣る。にじまず見やすいが、非常に見づらい条件がある。だが、MacTypeを動かすにはメモリに余裕がない。

相変わらず設定はしづらく、Windows Update中にスリープに入ってコケてしまうが、それでもいくつか改善された部分がある。 その最たるものはネットワーク関連で、アダプタの設定は今までよりも表に出された。

ただ、Modern UI上のアプリがデスクトップとは独立であることや、設定がModern UI上で一部だけできることは混乱を招く。 ちなみに、Modern UIのSkypeはMicrosoft IDでログイン(サインオン)する仕様で端末にMicrosoft IDを紐付けることを前提とする。だが、デスクトップSkypeを入れた場合に関してはそれは独立だ。

Microsoft IDの端末への紐付け、というのは、AndroidがGMailアドレスを要求するのと話は同じだ。 だが、Androidは勝手に電話番号やクレジットカード番号まで送らせようとするので、それと比べてMicrosoftのやり方は、Windows 8現在ではジェントルだと言える。Modern UIを拒否すれば別に登録する必要もないのだ。

これがModern UIだけ(Windows PhoneあるいはWindows ARMのように)ならば、うんざりしていたものと思われるが。

デザイン

非常に特徴的で素敵だ。

hp

hpは製品はもちろん、サポートも丁寧で好きだ。

そのサポートの素晴らしさだが、まずいきなり「初回ブート前にLinuxをブートしてバックアップを取る」に失敗、チャットで結構好まれない質問をしたのだが、丁寧に答えていただいた。

…CDブートの可否については調べて追ってメールで伝えるとのことだったが、メールがないのはご愛嬌。自己解決したしね。

ただ、製品に関してはフィルムをはがしたら、液晶に傷?があったのが残念。 白く、汚れではなさそうなこすっても変わらないものだった。

これについて申し出なかったのは、フィルムはがしと保護フィルムはりを同時にやったために元々ついていたことを確認できなかったためだ。

その時は開封動画をとめてしまっていたというのもある。

総括

5倍近い値段のLet’s Note RZ4に対して、資金的余裕がなく一時的な方策として導入したのだが、実際は価格差がなくても悩むほどの逸品だった。

使い勝手もよく、hpらしい心配りで誠実な製品だ。 モバイルとしてはベストに近いものだと思う。

これが適しているのは、スマホのような受け身な使い方ではなく、キーボードを欲したりPCでなければやりづらい作業を外出先でスキマ時間を活用してPC作業を行いたい人だ。

ハッカーや趣味プログラマ、あるいは忙しい人、外出や出張が多い人、小説を書くなどの生産活動をPCで行っている人などに適しているのではないか。

時間の有効活用に、あるいは機会の活用に適しているように思う。

ManjaroのVirtualBoxとGrub-probeにおけるunknwon filesystem

なぜかKVMが死んでしまったので(KVMのデータを格納するディレクトリをシンボリックリンクにしたら動かなくなった。戻しても動かなかった)ふたたびVirtualBoxに戻る。

だが、既にVirtualBoxが動かないからKVMを試したのであって…

KVMを再インストールしても動かなかったので、VirtualBoxを試すが、

Kernel driver not installed (rc=-1908)

だ。virtualbox-host-modulesをインストールしろと言われるのだが、これをインストールするとvirtualbox-host-dkmsが入る。

そして、既にこれは入っている。

kernel versionの違いによる問題だろうかと思い、まずは3.19での起動にトライする。

これまでのところ、Grub-Probeが

unknwon filesystem

でコケるために、update-grubがコケる。

恐らくはSSDのみならば問題なく動くだろう。もしそれでうまくいかないとすれば、システムを再インストールすれば良いということになる。最も厄介なのは、Windowsを導入しているディスクに起因する場合だ。

そしてSSDのみにしてみたが、うっかり/etc/fstabにWindowsのエントリを残していたので、とりあえずdm-crypt plainのディスクのみを除去し、2つのディスクで起動した上でupdate-grubしてみた。

うまくいった。もしかしたら、dm-crypt plainなディスクを含む場合にgrub-probeがコケるのかもしれない。あるいは、たまたまdm-crypt plainのディスクが中途半端にファイルシステムとして認識されるデータを置いてしまったのかもしれない。

そして再起動してVritualBoxを…うまくいかない。

色々調べたが、dkmsサービスが動作していない可能性が考えられた。既にやってあるはずだが、それは再インストールの前だったかもしれない。

systemctl enable dkms

自動的に再起動がかかるが、シャットダウンに失敗する。強制停止した上で再起動。

だが、これでもうまくいかない。

そして調べていくと、dkmsのモジュールをインストールしなくてはならないようだ。 これは、パッケージのインストール時に示される。

dkms install vboxhost/4.3.26

そしてビルドしようとするが失敗する。エラーメッセージからkernel headerがないことは見当がつく。

yaourt kernel headers

もう一度ビルド

dkms install vboxhost/4.3.26

これで動くようになった。

ネストされた構造のためのPureDocのTOC展開

ネストTOC機能

文書からTOCを作る上で、やはり構造的にネストしたいことはあると思う。 最もポピュラーなのは、ulをネストさせることだろう。

だが、難しいのは、例えば最初にh4が来て、次にh2が来て、などということがありうるのだ。そして、h3は存在しないかもしれない。

間の全てのレベルが存在することにするのか。順に礼儀正しく登場すると仮定していいのか。

結局だが、汎用性のある仕様として次のようにした。

  • 最低レベルはオフセットかまたは実際に使われた最も大きいヘッダーに基づく(数え方としてはmin)
  • レベルの変遷に応じて変遷分proc4openproc4closeを呼ぶ。例えば->(l, ol) { "<ul>" }のように書く。
  • 当該レベルまではopen/closeした後はproc4eachを呼ぶ。

    def nest_expand(proc4open, proc4close, proc4each, offset=nil) result = [] mi = self.min { |i| i.level } or return nil mi = mi.level

     if ! offset.respond_to?(:to_int) || offset > ( mi - 1 )
             offset = mi - 1
     end
    
     cur = offset
    
     self.each do |i|
         if i.level > cur
             (i.level - cur ).times {|n| result << proc4open.call( ( i.level - (i.level - cur - 1 - n) ), ( i.level - offset - (i.level - cur - 1 - n) )) }
         elsif i.level < cur
             result << (cur - i.level).times {|n| proc4close.call( (cur - n), ( cur - n - offset ) ) }
         end
    
         result << proc4each.call(i.level, (i.level - offset), i.title)
    
         cur = i.level
     end
    
     result.join

    end

eRubyでは内部のメソッドがputsすればいいような言い方をされることが多いが、それは先に出力されてしまっていたので、置換できるようにするために一旦配列に格納した。

テンプレート側の記述量が多く、また直感的でないというデメリットはあるが、なんとかうまく処理できた。

instance_evalと定数

しかし、むしろ苦戦したのは、ProfileでTOCを含めることだった。

Profileは基本的にそれ自体がPureDocを拡張したRubyコードである。

文章としてヘッダーを含めているわけでもないので、TOCを作るためのとっかかりがないのだ。

そこで結局は

  • テンプレート側でテーブル手前にリンクを貼る
  • profileであとから各カテゴリをヘッダとして登録する

という方法を取ったのだが、意外な理由でうまくいなかった。 というのは、

instance_evalで評価した場合、そのコンテキストが認識する定数にアクセスできない」

のだ。PureDocはソースをObject#instance_evalを使って解析するため、この問題にひっかかっってヘッダーの登録ができなかった。

そこで、PureDocに登録用のメソッドを追加することとなった。

簡単に書いているが、profileは整頓されていない部分が多く、結構大変だった。

Rubyのサブクラス内のスーパークラスのネストされたクラス

意味が分からないと思うが、ちょっとした疑問だ。

class A
  class B
  end
end

Class AA < A
  B
end

このコードではAAの中のBA::Bになる。 つまり、AAのコンテキストの中でBは使用可能だ。

class A
  class B
    def hi
      puts "Hi"
    end
  end
end

class AA < A
  class B
    def hihi
      puts "HiHi"
    end
  end
  
  def initialize
    @b = B.new
  end
  
  def b
    @b.hi
    @b.hihi
  end
end

aa = AA.new
aa.b

このコードでは

class AA
  class B
  end
end

AA::Bが作られ、@b#hiがないためエラーとなる。

class A
  class B
    def hi
      puts "Hi"
    end
  end
end

class AA < A
  class B < B
    def hihi
      puts "HiHi"
    end
  end
  
  def initialize
    @b = B.new
  end
  
  def b
    @b.hi
    @b.hihi
  end
end

aa = AA.new
aa.b

この場合は、

class B < B

によって、A::BをスーパークラスとするサブクラスAA::Bが作られる。

この定義によってBという名前がオーバーライドされることとなる。

class A
  class B
    def hi
      puts "Hi"
    end
  end
end

class AA < A
  B = B
  class B
    def hihi
      puts "HiHi"
    end
  end
  
  def initialize
    @b = B.new
  end
  
  def b
    @b.hi
    @b.hihi
  end
end

aa = AA.new
aa.b

これが本来意図するところだ。 オープンクラスを用いてスーパークラス内で定義されたクラスを拡張したいのだろう。

そこで

B = B

によって

AA::B = A::B

とした上でクラスを開けば良いのだ。

だが、今回の場合はPureDocのために実験した。PureDocではサブクラス内での#instance_evalによって評価された時に呼ばれるメソッドが名前でこのクラスのインスタンスを生成するため、あくまでもサブクラス(AA相当)の中に閉じ込められたクラス(B)でしかない。

ということは、そのクラスは

AA::B = A::B

ではなく

AA::B < A::B

であることが本来望ましいのではないだろうか。