linux-packaging-mono/mcs/class/I18N/CJK/Test/texts/japanese2-utf8.txt

こっちは半角カナはナシ。

Mono Directions

Miguel de Icaza
miguel@novell.com

(翻訳 : Atsushi Eno
atsushi@ximian.com)

これは2005年11月17日に公開されたMono 1.2リリース直前(?)のロードマップのようなもの。原文はこちら。訳注はこの色で下線付きになっています。

私たちはちょうどMono 1.1.10 をリリースしたばかりで、これは今のところ私たちの最善のリリースです。 このリリースでMono 1.2に関する重要な未完成機能は、Windows.Formsの実装です。

この文書で、私はNovellのMonoチームの開発の方向性を示します。 Monoコミュニティによる他のMono開発の全体的な見通しについては、いま私がまとめているところであり、後日公開される予定です。

また、NovellにおけるMonoの内部利用とか、.NET 2.0リリースなど外部的要因などを受けて、このチームの優先順位がどのように移り変わっているのか、という点も説明します。
目次

    * コード開発プロセス
    * Windows.Forms
    * 2.0 サポート
    * Mono Debugger
    * MonoDevelop IDE
    * Mono 仮想マシン: 移植
    * Precise Garbage Collector
    * コード生成および最適化
    * C# コンパイラ
    * Visual Basic コンパイラ
    * コードアクセスセキュリティ
    * ASP.NET
    * APIの安定性
    * Gtk#
    * Google Summer of Code プロジェクトの統合
    * JScript コンパイラ

コード開発プロセス

Mono 1.1.xxシリーズが1.0.xxに存在する数多くの重要な修正を加えられてきたことから、私たちはユーザー・開発者ともに、Mono 1.1.xxシリーズに移行することを推奨しています。

リグレッションを回避するために、私たちは数多くのことを行ってきました:

    * 私たちは全てのテストをリリース前のプロセス`make distcheck'に統合し、既知のバグを残したままで（正確には、通るものとされているテストが通らないままで）リリースしないようにしています。
    * 私たちはNUnitテストが通過するように、あるいは環境固有のもの（インターネットにアクセスしたり特定のホストに接続したりするようなもの）については、標準で無効とするようにして、バグを修正してきました。
    * 新機能は別のブランチで開発し、完成した際にその機能をメインのリポジトリに「上陸」させるような開発を始めました。

私たちはこの別ブランチ開発を新しい文字列照合フレームワーク、ASP.NET実装（新しいやつ）、新しいクロスプラットフォーム レジスタ アロケータ、Cairo 1.0移行の際に適用してきました。そして、現在同じことをVMの最適化、正確なガベージコレクタ、C# 2.0コンパイラについて行っています。（え、そうなの?）

この基本的なアイディアは、1.1.xxシリーズをリリースとし、単なる開発リリースではなく、製品上にデプロイできるようなものとするためです。これはカーネル2.6.xxリリースの精神に通じるものがあります。

一般的なルールとして私たちは新機能を作るまえにバグを直します。

1.1.xx開発のサイクルで行われてきたことの詳細については、それぞれのリリースのノートを参照してください: 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 1.1.9, 1.1.10.
Windows.Forms

Windows.Formsの部分だけが、私たちが公式にMonoをMono 1.2にリネーム出来ない要因となっています。 これにはまだいくつかの機能が含まれていません。私たちの計画では、不足している機能を今月の終わりまでに完成させ、それからバグフィックスと、私たちがオープンソースでアクセス可能なWindows.Formsアプリケーションをテストする段階に入ります。 現時点で、これに3ヶ月程度費やすことを計画しています。

Mono 1.2における私たちの目標は、.NET 1.1のAPIを実装するWindows.Formsをリリースすることであり、2.0のAPIはこれに含まれてはいません。

完成しているといえない主要な不足部分は:

    * Multiple Document Interface (MDI).
    * MDIが存在する場合におけるメニューのマージ
    * RichTextBoxではいくつかの機能がありません: 選択のマージン、箇条書き、インデント、いくつかのpublicなメソッドおよびプロパティ

私たちのWindows.Forms実装は、レンダリングを行うGDI+ APIと、ホストウィンドウシステムと通信する比較的小さなドライバの上で実装されています。 私たちのGDI+実装は、Unix上ではCairoをレンダリングエンジンとして使用しています。ウィンドウシステムのドライバとしては、ふたつの完全なドライバ（Unix/X11とWin32）とひとつの開発中ドライバ（OSX）があります。

いくつかのマイナーな不足機能としては:

    * デフォルトのWindows.FormsツールキットとしてのTango Project のアートワーク統合
    * MacOS XのWindows.Formsドライバの完成
    * コントロールの透過のサポート
    * ダブルバッファリング: ダブルバッファリング自体はサポートしていますが、Microsoftの実装のコントロールの設定と互換性を維持するだけのために、多くのコントロールにおいて無効となっています。私たちはこの設定を変更してユーザーの使用感を改善することでしょう。

このリリースでは明示的に見送られる機能がいくつかあります。それらは外部から貢献されない限り1.2には含まれず、Mono 2.0まで待たなければならなくなることでしょう:

    * Pango. 現在のところ、Windows.FormsはテキストをGDI+ APIでレンダリングするという制限があり、従って国際化テキストや複合スクリプト（英語とアラビア語の混合など）をPangoの機能を使用してレンダリングする機能は全くありません。
    * コントロールをGNOMEのルックアンドフィールにマッチさせるGtk+テーマモジュールの作業
    * GDI+実装にはベジエ曲線ベースのリージョンのサポートが含まれていません（矩形のみサポートされています）。
    * 入力メソッド（漢字などは一切入力できません）
    * 印刷

WinForms のページで進捗を載せています。
2.0 サポート

2.0の基盤となる作業は、2003年中頃に、新しい変更点がECMAに提出されてから直ちに始まりました。これは、C# 2.0コンパイラの作業と、ジェネリクスをサポートするためのVMの変更のために、十分な時間を与えてくれるものでした。現在これらはいずれも完成したものとしています。

ILアセンブラとILディスアセンブラはほぼ完成しており、ジェネリクスベースのライブラリもすぐにラウンドトリップできるようになる予定です。

コア部分は、最新版のIronPython とNermerleが動作するために十分な完成度となっています。

開発者達は、2.0で利用可能になった新機能を使い始め、ランタイムとコンパイラのバグ を登録するようになりました。

現在のところ、私たちのポリシーは、ライブラリでは1.1プロファイルをサポートするというものでした。2.0プロファイルは、開発されてはいるものの「もし割れちゃったら、両方とも手で支えて持っていてちょうだい」（怪しい訳文だが、原文は"if it breaks, you get to keep both pieces"）というものでした。コンパイラとランタイムの2.0サポートに関するバグは継続的に修正されてきました。

.NET 2.0のリリースに伴い、私たちは開発の取り組みを2.0プロファイルの最も重要なエリアに移動しています。

次のMono 1.2のリリースまでには、このプロファイルの最も重要な部分を含めたいと思っていますが、2.0 APIの完成度については、何も約束できる状態にはありません。Mono 1.2はWindows.Formsが完成した時にリリースされます。

System.Xml 2 はほぼ完成しており、mscorlibとSystemの2つのアセンブリはまだ多くの作業を必要としています。

ASP.NETについては、ASP.NET のセクションを参照してください。
Mono Debugger

Martinがデバッガの作業を継続しています。現在のところ、1.xアプリケーションをデバッグすることができます（2.0はCecilのジェネリクスサポートが完成し次第サポートされるでしょう）。

現在のデバッガをテストするには、SVN上にあるMonoとdebuggerを使用しなければなりません。これらは急速に変更されているためです。

私たちはいま、デバッガの制限とインターフェースについて、フィードバックを受け付けています。現在のところ、コマンドラインデバッガのみが動作するようになっています。私たちのWebサイト上にあるデバッガ ガイドも読んでください。

もしデバッガ上の問題を発見したら、バグレポートを登録してください。
MonoDevelop IDE

Lluisは、ASP.NET 2.0の開発から、MonoDevelop IDEの開発に移動しています。

私たちのMonoDevelopのゴールで最も重要なものは、これが十分にソリッドなものとなって、報告された全てのクラッシュを起こすバグを根絶することです。

機能的には、MonoDevelopは今やEclipseに類似するプラグイン アーキテクチャをサポートしています: コンポーネントは、ダウンロードして、アプリケーションを再コンパイルせずにインストールすることができます（ こちらを参照)

GUIデザイナの統合は現在進行中です（今のところGlade3ですが、利用可能になり次第Steticに置き換えたいと思っています）。

最後に、デバッガインターフェースが安定し次第、MonoDevelopのデバッガ インターフェースを再び有効にすることを計画しています。
Monoの仮想マシン: 移植

この1年間の間、Mono JITは、それ以前にサポートされていたプラットフォーム（x86, PowerPC, SPARC, SPARC 64ビット, S390）に加えて、3つの新しいアーキテクチャ（x86-64, Itanium, Armプロセッサ）に移植されました。

現時点で、Novellのチームには新しい移植の計画はありません。ただし、コミュニティのメンバーには、S390xおよびMIPSのサポートへの関心を表明している人もいます。
正確なガベージコレクタ

（いつも思うんですが、precise garbage collectorってどう訳せばいいのかしらん）

Paoloは新しいガベージコレクタ (GC) エンジンの作業に取りかかっています。現在のところ、MonoのGCインターフェースはほとんど差し替え可能なものです（別のGCに差し替える作業は数ヶ月前に行われました）。（といっても別にBoehm GCから変わったわけではありません。少なくともmain treeでは）

新しいGCエンジンは正確で、世代管理があり、コンパクト化を行うコレクタとなります。つまり、MonoのGCは、メモリが不必要になり次第オペレーティングシステムに戻せるようになります。

このコレクタを迅速に出荷するために、いくつかのトレードオフが伴います。たとえば、新しいGCがこのスタックを保守的に扱うことで、2つの作用があります: Monoを組み込みで使用する人にとっては、新しいGCを使用するのが簡単になりますが、これは数多くのピン留めオブジェクト(pinned objects)についてフラグを立てることになるでしょう。

私たちは、新しいGCのコードが、2月あるいは3月辺りにテスト可能になっていることを臨んでいます。コードは12月には上陸を始めることでしょう。
コード生成と最適化

私たちは新しいコード最適化のために少なからず時間を費やしてきました。このコードはメインのMonoリポジトリに投下できる用意が出来つつあります。今後数週間のうちに、さまざまなパッチが投稿されるのを待っていてください。

現在のところ、生成コードのパフォーマンスを改善する以下の部分について、作業が進められています

    * デフォルトでより強力な最適化を有効にする（インラインとfastdce）。これらについては、どんな重要なリグレッションも回避することが求められます（生成されたコードの品質についても、JIT時間についても）。
    * 新しい最適化フレームワーク（HSSAベースのプラットフォーム）と、それに基づく最適化（PREとGVNPRE）。
    * ツリーベースの中間表現(IR)の解消と、CILコードから命令リストIRの直接生成。

Massiが最近高速不使用コード削除 (Fast Dead Code Elimination）のコードを投稿し、その説明をblogの投稿に掲載しました。

MassiはHSSAベースのフレームワークとそれに基づく不使用コード削除の作業も行っています。この最適化については今週中に（もう過ぎましたが）メーリングリストにレビュー用に投稿される予定です。

いったんこれら2つの作業を終えたら、MassiはFastDCEとCopyPropとインラインをMonoのデフォルト最適化の一部とする作業に入ります。これは直ちに目に見える結果をもたらすことでしょう。

いったんこのHSSAの計画が実行されたら:

    * コピー伝播(copy propagation)の実装
    * 完全な余剰削除 (full redundancy elimination) （部分的削除よりはスポットしやすいものです）。
    * 部分的余剰削除 (partial redundancy elimination）（スポットするのも扱うのも難しい）

コードの品質は、冗長コード削除によって生じる一時変数の追加によって、悪影響を受けることがあり得ます。この問題を解決するために、私たちはレジスタ確保 (register allocation)をフィードバックする機構を必要とします。これは現在まだ存在しないものです。

上記の問題（およびその他の問題）を解決するために、ZoltanがツリーベースのIRをMonoから削除する作業を開始しました。

このステージを解消することで、レジスタ確保はベターな仕事ができるようになります（現在はレジスタ確保がツリーノード内部では見えません）。いったんこれが用意できたら、冗長削除の最適化が、実際にレジスタ確保とのインタラクションで生成コードの品質を向上するかどうかを、決定することが出来ます。この新しいIRセットアップの開発は、別のブランチで行われる予定です。
C# コンパイラ

C# コンパイラには2つのエディションがあります:

    * gmcs: 最新のECMA仕様（第3版）を完全にサポートし、2.0ライブラリを参照するバイナリを生成します。
    * mcs: 最新のECMA仕様（第3版）からジェネリクス拡張を除外したものをサポートします。1.0ライブラリを参照するバイナリを生成します。

2005年11月時点でのgmcsコンパイラのサポートには、ひとつ足りない機能があります: 標準仕様における最終段階でのnullable typesの変更です。それ以外は、コンパイラは機能的には完成したことになっています。

C#コンパイラは私たちの作業のコアとなっているので、私たちはバグフィックスにフォーカスをあて続けます。最新のC# 3.0の機能は、実装するのは簡単ですが、まだ待たなければならないでしょう。
Visual Basic

私たちは去年、自由なVisual Basicコンパイラを完成させるつもりでした。現在コンパイラはベータ段階にあり、Novellはコンパイラ開発への資金投入を打ち切りました。

Mono Brazilの人々がコンパイラの開発とメンテナンスを引き継ぎました。

VB コンパイラは古いmcsのforkに基づくもので、もともとはRafael Texeiraによって作られました。2.0のジェネリクスをサポートするように現在のコンパイラをアップグレードするには、'gmcs'のフレッシュコピーから始めて、VBコンパイラに加えられたさまざまな変更をマージする必要があると考えています。
コードアクセスセキュリティ

コードアクセスセキュリティ (CAS) はバージョン1.1.4からMonoでも利用可能になっています。これは'mono'をコマンドラインオプション --security 付きで実行すると有効になります。

CASは非常に進展した段階にあり、Mono 1.2でも利用可能になるでしょう。しかし、CASは次のMonoのメジャーリリースまでは完成を保証しません。まだコード検証の機能が不足していますし、2.0では新しい未実装のCASの機能が存在します。

このコードを管理しているSebastienは、クラスライブラリにCAS属性を追加し関連するテストを作成する作業で多忙ですが、現在のCASの状態をこちらにまとめました。

CASのパーミッションがいかに設定されるか、という点については、彼がこちらにまとめました。

Sebastienは、FxCopに近い精神に基づく一般的なバグ発見ツールを作成しました。これは私たちのライブラリで適切にCASルールを設定するために使用されています。Gendarmeのページで詳細を知ることが出来ます。
ASP.NET

私たちは、Mono 1.1.9で、根本的にアップデートされて大幅に高速化し省メモリになったバージョンのASP.NETをリリースしました。私たちの新しい実装ではパフォーマンスを改善するためのさまざまなトリックを使用しています。この辺りは今後ブログることになるでしょう。

Mono 1.1.10で、Gonzaloは新しい自動コンフィグレーションオプションをApacheモジュールに追加しました。今では、mod_monoをセットアップすると、その他の言語モジュールと同様に振る舞うことになります。たとえば、ユーザーや管理者が.asmx, .ashx, aspxファイルを公開ディレクトリから削除しても、MonoのASP.NET実装が、ASP.NETコンフィグレーションを変更することなく取り扱われます。

ASP.NETの2.0サポートについては、新しいコンフィグレーションAPIに依存しないさまざまなコントロールが既に実装されています（メニュー、ツリー、マスターページ、グリッドビューおよびそれらが要求するもの）。

Chris Toshok がLluisからASP.NET 2.0の開発を引き継いで、次のASP.NETの機能群（プロファイル、ポータルパーツ、およびその依存関係）の基盤となる、新しいSystem.Configurationネームスペースをほぼ終了しました。

ChrisはまたAtlasのオープンソース実装の作業も多少行いました。
APIの安定性

APIの安定性について: System.*については安定しており、私たちは"corcompare"ツールを使用して、その互換性を検証しています。.NET 1.1.xのAPIは（Mono 1.0 の機能に記述したとおりに）実装されています。

一方、Mono.* ネームスペースはまだ流動的なものです。

Mono.Cairoアセンブリは、その下にあるCairo 1.0ライブラリにおける変更を吸収しました。私たちは以前のAPIの設計にあった初期の問題と制約に対処して、さまざまな変更を行いました。

Mono.Posix アセンブリは、新しいネームスペースに統合されました: Mono.Unixは、Unixにアクセスするための、より柔軟なバインディングとハイレベルの.NETっぽいAPIを提供します。これはなまのUnix アクセスのみを含んでいたMono.Posixとは対照的なものです。
Gtk#

Gtk#のバージョン2.4がリリースされました。このリリースの新しい機能はこちらにまとめられています。これは、現時点で最も一般的に利用可能なGtk 2.4にバインドされています。

私たちは、Gtk# 1からGtk# 2に移行する開発者のために、アップグレードガイドを作成しました。

Gtk#の開発という側面では、新しいバージョンがテスト版として利用可能です。これはGtk+ 2.8のAPIにバインドし、その一部となる新しいメソッドとCairoのプロパティにアクセスできるものです。

データバインディングをGtk#でサポートする作業は、現在のところWindows.Formsが完成するまで一時停止しています。私たちは、Mono 1.2が出荷されてから、データバウンドできるGtk#の作業に戻ることを予定しています。
Google Summer of Code プロジェクトの統合

GoogleのSummer of Codeプログラムのおかげで開発されたプロジェクトのうち、いくつかは統合してあります。

    * Mario SopenaによるMonodocのかいぜん（コラボレーション、Mozilla統合、CSS化）
    * xbuild: msbuildの実装がツリーの中に含まれていますが、デフォルトではコンパイルされません。Marek Sieradzki作
    * DataGridView, Pedro Martinez作
    * xaml コンパイラとヘルパークラス。Iain McCoy作
    * Javascriptランタイムの改善。Florian Gross作

私たちはMichael HutchinsonとBlagovest DachevによるASP.NETエディタの統合を計画しています。
ADO.NET 2

T SenganalがADO.NETのメンテナンスを引き継ぎ、ADO.NET 2の機能を使用している開発者とともに、そのプロバイダをMonoで動作するようにする作業を始めます。
JScript

CesarはJScript実装でMozillaの全てのJavaScriptテストを通過させる寸前までいっています。

もしJScriptコンパイラとランタイムの進捗を追跡したいのであれば、Mono webサイトにあるJScript のページ を見てください。
おしまい

最後まで辿り着きましたね。おめでとう!