[DE | EN | FR | JA | ES | KO | PT]

Brave GNU Worldの新しい号へようこそ。 今号では「古典」の紹介後、 やや技術的な部分に入りますが、 それほど技術的でない読者の方にも興味がもてるのではないかと信じます。

GNU grep

Bernhard RosenkraenzerがGNU grep [5] の新しい管理者になったので、 この機会にプロジェクトのことを少し書こうと思います。

ほとんどのGNU/Linux利用者は、 もうきっとGNU grepをご存じで、 毎日のように使っていると思います。 ですが、 まだこれに慣れ親しんでいない人がいるかもしれないので、 簡単にその機能の紹介をしたいと思います。

GNU grepは、 ファイルや、 標準入力から、 あるパターン (テキスト文字列であることも多いですが) をさがしだし、 パターンに一致したり、 含んだりする行を出力します。 パターンを含むファイルを特定するために、 複数のファイルを検索することもできます。 文書を処理し字句をさがしだしたりすることから、 他のプログラムの出力を適切な情報にまで絞り込むことまでが、 典型的な使用法です。

grepはまず間違いなく、 あらゆるUnix風システムで標準的なコマンドです。 またGNU grepは、 標準機能のほかにも、 ディレクトリーの再帰探索や、 語を基本とした出力の機能もあります。

すでに多年にわたって数多くのシステムで使われ続けていますので、 日常利用への用意の点で疑うべきところはないでしょう。 GNU grepの正確な年齢について、 私は確かではないのですが、 ChangeLogは1993年にさかのぼり、 FSFの著作権告知は、 Linuxカーネルの作られる約3年前の1988年からになります。 プロジェクトの年齢を無視してこの特色の興味深さを語ることはできません。 なぜかというと、 こんなに年を重ねてでさえも、 これがFree Softwareの元気さを示しているからです。

ここ数年、 80人以上がGNU grepに貢献していて、 開発はいまだに継続しています。 課題リストには、 POSIX.2への完全準拠と、 若干の新しいオプション用の小さい変更があります。 その中には、 たとえば"--max-count"オプション、 PCRE (Perl互換正規表現) 用のスイッチ、 色つき出力での強調オプションなどがあります。

これほど年季の入り、 安定し、 ひろく使われているパッケージであっても、 手助けは必要です。 GNU/Linux、 FreeBSDへの移植性のため、 開発版を喜んで試験し、 バグ捜しをしてくれる利用者は、 特に大歓迎です。 また今度の管理者は、 英語、 ドイツ語、 フランス語だけを話すので、 多バイト・サポートがちゃんと機能しているのか、 判断することができないのです。

ですから、 「多バイト地域」の利用者には、 試験への参加を促したいところです。

GNU UnRTF

Zachary T. SmithによるGNU UnRTF [6] は、 最近GNU Projectに参加しました。 Rich Text Format (RTF) の文書が、 これで他の形式に変換できます。 RTFは、 ときどきWindows利用者の間での文書交換に使いますが、 他のテキスト処理系でも、 整形情報つきテキストの保存に使います。

このプロジェクトのおかげで、 今やこういった文書を、 純粋なテキスト、 HTML、 LaTeX、 PostScriptに変換できるようになりましたから、 RTFそれ自身や、 それに依存したものを使っている人はだれでも、 このプロジェクトの恩恵を受けることができます。

プロジェクトの許諾は、 変わることなくGNU General Public Licenseでしたが、 昔の"rtf2htm"という名前になじみのある人もいるでしょう。

開発過程での焦点は今、 2つあります。 文字変換とLaTeXへの出力です。 さらに将来、 もっと多い対象形式のサポートを予定しています。 進行中の開発をのぞけば、 このプロジェクトは、 利用の準備ができています。

QTreeMap

Alexander RawassによるQTreeMapプロジェクト [7] は、 Qtウイジットの"Treemap"を、 GNU Lesser General Public Licenseの下で、 実装するものです。

深い階層や木は、 マウスのクリックで畳んだり広げたりできる構造の一種でよく表示されます。 Treemapは、 全階層を一目で表示できる能力を提供します。

原理というものは具体例をあげることで簡単にわかるものですから、 ここでは、 ハード・ディスクの利用量を視覚化するためにQTreeMapを使うKDirStat [8] の操作で説明してみようと思います。

QTreeMapは、 長方形の領域に表示されます。 長方形の全領域は、 視覚化されるパーティションの全容量を表わします。 ディレクトリーやファイルは、 その大きさに比例して表示されます。 パーティションで有効な空間の3分の1を占めるディレクトリー構造は、 同じく3分の1の有効な表示領域をとります。 全構造の半分の大きさを含んだ、 構造の下位ディレクトリーは、 表示サイズの半分になり…という具合です。

Treemapは特に、 ファイル・システム、 ネットワーク・トラフィック、 コンテンツ/組織管理図のような、 大きさに依存する階層の表示が必要な状況でも役に立ちます。

QTreeMapは、 古典的TreeMap、 二次元TreeMap、 さまざまな採色スキーム (しかも正規表現に基づいた) をサポートしています。 生成されたTreeMapは、 ビットマップも含めてXMLでロード、 保存が可能です。

作者によれば、 QTreeMapの特殊な問題は、 いつものKDE固有の問題同様、 "Sequoia View" (QTreeMapを触発した独占的プログラム) にある"Cushion"アルゴリズムのないことです。 しかし、 Alexanderは数理的概念を見つけることができず、 実装できないようです。

Pythonによるアルゴリズムの試作後、 AlexanderはQTreeMapをC++で書きました。 彼によると、 2つの類似したプロジェクトがあるそうですが、 どちらもJavaで書かれています。 KDirStatとKProf [9] で示されているように、 QTreeMapは使える状態にあり、 興味のある開発者は見てみるべきでしょう。

Dap

Susan BasseinによるDap [10] も、 また新しいGNU Projectのメンバーです。 「データ解析と表現 ("Data analysis and presentation")」 の略であるDapは、 GNU General Public Licenseの下でリリースされています。

Dapは、 統計診断や教育でよく使う図表の視覚化、 解析、 データ管理用の基本関数を提供しています。 また、 データ集合の管理にも役立ちます。 Susan自身、 自分の税金計算や、 自社従業員への支払い準備にDapを使っています。

プログラムはCで書かれており、 Cの経験のある利用者なら、 パッケージについてくる例を勉強すれば、 特に問題はないでしょう。

すでにGNU Projectには「R」という統計パッケージがあるので、 今や選択肢が2つあることになります。 Rはオブジェクト指向である一方、 Dapは手続き型アプローチをとっています。 独占的プログラムである「S」、 「S-plus」の利用者なら、 Rの方がお好みでしょう。 Freeではない「SAS」パッケージを前に利用したことがあるなら、 Dapの方が、 早くなじめるでしょう。

またDapは、 メモリーにやさしくなっています。 Rは最初にファイルを全部メモリーに読み込みますが、 Dapは行指向なので、 大量のデータにむいています。

Susanの指摘による問題は、 DapはRよりも統計分析が少ないこと、 そして、 速度の最適化をしたことがないことです。 そういった弱点の修正は、 機能の拡張や改良と同様、 今後の開発の目標です。

このような問題にもかかわらず、 Dapは約3年も使われ続けており、 全面的に試験済なので、 興味のわいた利用者にはおすすめです。

GNUComm

以下3つのプロジェクトは、 対話的な構成部分を基に、 柔軟で完結した通信環境をつくろうとする、 GNUCommメタ・プロジェクト [11] の推進、 という目的を追求しています。

GNUCommメタ・プロジェクトの一部には、 第16号 [13] で紹介した「テレフォニー・サーバー」のBayonne [12] があります。 GNUComm開発の焦点には、 GNU Enterprise [14] プロジェクトとの統合と、 相互運用性があります。 GNU Enterpriseは、 いわゆる「エンタープライズ・リソース・プランニング (ERP)」 の分野での、 完結した解をあたえることに取り組んでおり、 Free Softwareをこの大きく独占的な領域にもちこもうとしています。 さらなる情報は、 Brave GNU Worldの第24号 [15] をご覧ください。

GNU ccRTP

ccRTP [16] プロジェクトの目標は、 RFC標準の「リアルタイム転送プロトコル ("Realtime Transport Protocol")」の実装で、 これは、 ネットワーク上で (音声やビデオのような) 時間に依存するデータを伝送可能にするものです。

ストリームは、 受取り側で正しく割付けできるよう、 時間情報をふくんだパケットで伝送されます。 こういう場合ふつう、 UDPパケットを使います。 なぜなら、 同期を乱すようなネットワークの障害では、 伝送が妨げられないからです。

ccRTPは、 GNU General Public Licenseの下、 C++クラス・ライブラリーでこのオブジェクト指向を実装しています。 作者のDavid SugarとFrederico Montesino Pouzolsは、 ccRTPをもっとも多目的、 効果的、 標準準拠のRTP実装にしたいと望んでおり、 これまでその方向で、 いくつかの段階を経てきました。

GNU ccRTPは、 ポイント・ツー・ポイント伝送、 多重入力ストリーム、 「リアルタイム制御プロトコル ("Real-Time Control Protocol")」 (RTCP) 同様、 マルチキャストもサポートしています。 さらに、 IPv6への移行も準備中で、 RFC 2833にあるデータ・ストリーム内からの通知のような機能を可能にする混合モードのデータ・ストリーム同様、 リアルタイム・パケット・フィルタリングも可能です。

部分的なパケット再構築、 「サービス等級 ("Class Of Service")」に基づく経路づけ同様、 ビデオ・データに必要な高い伝送速度も可能となっており、 すでにライブラリーは、 クライアントとサーバーに使うことができます。

現在、 作業は「資源予約プロトコル ("Resource ReSerVation Protocol")」 (RSVP) とRTCPサポートの仕上げに入っています。 次の段階は、 現在欠けているプロジェクトのちゃんとした文書化です。

リアルタイムの専門家や、 よい文献の著述者による手助けは大歓迎です。 後者は特に、 ほとんどの人が考える以上に見つけるのが困難なものです。

GNU ccAudio

ccAudio [17] も、 David Sugarの始めたプロジェクトです。 名前からわかるとおり、 その目標は、 メモリー、 ハード・ディスク上にある音声データ操作用の「汎用目的」ライブラリー作成にあります。

ccRTPと同じく、 ccAudioもGNU General Public Licenseの下、 C++のクラス・ライブラリーとして実装されており、 GNU Bayonne-Projectからきたものなので、 GNUCommメタ・プロジェクトの一部となっています。

ccAudioは現在、 libsndfileなどのライブラリーをもちい、 ハード・ディスク上の音声データへのアクセスをサポートし、 基本的な音声信号処理機能を提供しています。 これは、 音声データを離散標本とみなし、 そして、 RIFFヘッダーなどを扱うことができます。

音声データをバイト形式のバイナリー・バッファーとしてではなく、 標本集合として扱うという点は、 特に注目に値する、 とDavidは考えています。 またこれは、 標本の符号化形式、 エンディアン順、 多チャンネルの差も理解します。

ccAudioの有効なプラットホームは、 Win32もふくんだUnix風システムで、 この分野の開発者なら、 一目見てみるべきでしょう。

今後の開発は、 動的ロード可能なソフトウェア・コーデック (codec) のよりよいサポートと、 組込み音声コーデックのさらなる追加です。 Davidは、 (高速) フーリエ変換 (FFT) と、 音声混合、 変換のさまざまな形式をccAudioに組み入れることを検討しています。 デジタル音声信号処理の経験者は、 かなり手助けになるでしょう。

ccScript

ちょうどCommon C++、 Bayonne、 ccRTP、 ccAudioのように、 GNU ccScript [18] もDavid Sugarの管理下にあるプロジェクトで、 これで五大管理者 ("Penta-Maintainer") になった、 と彼は嬉しそうに話したものです。

GPL配下のccScript C++クラス・ライブラリーは、 状態遷移イベント駆動系のリアルタイム・アプリケーション用仮想装置 (VM) を提供します。 このアセンブラ風記述言語は、 GNU BayonneやGNUCommプロジェクトの他の部分で、 利用者との対話スクリプトに使われています。

すぐわかることですが、 実行速度の定義されていることは、 まさにccScriptの書かれた目的であるようなリアルタイム環境では、 非常に重要な意味をもちます。 ccScriptでは演算は全部、 確定的です。 この規則の唯一の例外は、 これが不可能であるような、 データベース参照をはじめとした演算です。 それが理由で、 複素数や不定式をあつかうことができないのです。

ccScriptは一般的な機能やマクロをサポートしてはいますが、 これをGuileやTclのようなプロジェクトと混同してはいけません。 これらはもっと多目的で、 リアルタイム能力に対応するものがないからです。

ccScript開発の次の段階では、 構文が多少、 再構築、 明確化されるでしょう。 また言語のより多くの部分が、 ロード可能になるはずです。 このプロジェクトでは、 文書化の点でも手助けが必要です。 ですので、 もしそうしたいとお思いでしたら、 ぜひどうぞ。

もういいかな

今月号は、 もういいでしょう。 最後に指摘しておきたいこととしては、 "GNU Transport Layer Security Library" (GNUTLS) では新しいロゴをさがしていて、 「GNUTLSロゴ・コンテスト」 [19] の始まったことがあります。 もしあなたが自分の工芸品をGNU Projectの一部にしたいのなら、 これはいいチャンスです。

はげまし、 お考え、 コメント、 ご批判、 新しいプロジェクトについては、 もちろんメール [1] にてお願いしたいところです。