12月31日
戻る。
実引数リストの解析を少し手直しすることから始めました。キーワード引数が表示されると、残りの引数もキーワード引数でなければならないという規則があります。プロシージャのインターフェイスが変更される可能性があるため (内部プロシージャである可能性があるため)、明らかなエラー チェックの一部は後で延期する必要があります。
そこから、仮引数リストの比較が壊れました。このコードは、新しいインターフェイスを追加できるかどうかを確認する部分にありました。アイデアは、新しいインターフェースを古いインターフェースのそれぞれと「比較」して、2 つの正式なインターフェース間であいまいな実引数リストが存在しないことを確認できるようにすることです。これらの規則は、セクション 14.1.2.3 にあります。
これを行った後、g95_compare_formal_actual() のコードを修正して、オプションの引数を適切に処理できるようにしました。また、新しいバージョンでは、実引数リストが正しい順序で再リンクされ、存在しないオプションの引数に対応する空白ノードが追加されます。
途中で、左側または右側が型解決に失敗した場合に g95_check_assignment() をバイパスするコードを解決フェーズに追加しました。これにより、’unknown’ を LHS に変換することが不可能であるという迷惑なメッセージが表示されましたが、現在はなくなりました。
古いコードには明らかにバグがたくさんありましたが、解決策が十分に機能していなかったため、目立ちませんでした。Steve Kargl のテスト コードは面倒ですが、非常に基本的なもので、現在は機能しており、g95 テスト スイートに追加されています。
サブルーチンと関数を同じインターフェイスに入れることができるという厄介な啓示もありました。Fortran 標準は、何が禁止されているかを示し、その結果にあまり踏み込まないことが多いという点で、少し厄介です。現在のコードは、ジェネリック名が正しくないある種の関数またはサブルーチンであると想定しています。幸いなことに、修正には主にコードの削除が含まれます。
12月21日
すべての仮引数リストを強制的にモジュールに書き込む小さな修正を行いました。これで昨夜見つかったバグは解決しましたが、すぐに別のバグに遭遇しました。派生型を返す関数が正しい型を持っていないようです。
明日の朝、家に帰るので、今年のg95はこれが最後になりそうです。
12月20日
苛立たしいバグを乗り越えて、小さくて簡単に修正できるバグに集中することにしました。ミラー スイートを放棄して、globsol に戻りました。globsol は、475 個のファイルのうち約 6 個のファイルしか問題なく解析できました。現在、依存モジュールが欠落しているため、約 80 ファイルしかコンパイルできません。g95_check_pointer_assign() のチェックを g95_variable_attr() を呼び出すように修正しました。ポインター性などの属性は式ノードには格納されませんが、コンポーネントの参照リストを走査することで判断できます。基本シンボルがチェックされていましたが、これはまったく正しくありません。
次の困難は似ていました-参照ノードのリストの代わりにベースシンボルからランクを取得しました。いくつかの最初の試行の後、これを行うのに最適な場所は、変数の指定が一致した直後 (参照ノードを生成する) であることに気付きました。
12月16日
派生型のホスト関連付けが機能するように、昨日と今日の変更を行いました。typename が仕様で後で定義される場合に備えて、プログラム単位で typename が最初に見られるときに、シンボル ノードを作成する必要があります。コンポーネントが宣言される前に派生型が「使用」される場合、名前はホストに関連付けられた派生型を参照する必要があります。これが発生すると、既存のシンボルが削除され、すべての参照がホスト ユニットのノードにリダイレクトされます。
その後、インターフェイスを比較する際のコア ダンプを修正しました。仮引数リストが十分に長くない場合、segfault が発生するまで継続していました。
その後の問題はSCALE機能の問題でした。組み込みシンボル テーブルでは、実際にはジェネリック組み込みである場合に、特定の型と種類がありました。単純化サブルーチンに固有の右の選択を追加しました。また、一定の単純化が 2 の基数を想定していることにも気付きましたが、これも修正されています。
この時点で、Alan Miller の quad.f90 は正しく解析および解決されます。万歳！
次のバグは配列性に関するもので、これがパーサーの最後のフロンティアです。しばらくの間、改良に取り組みましたが、今回は事前にもう少し考えました。式ノードに実際に格納する必要があるのは式のランクだけであり、完全な形状ではないという考えが生まれました。
12月13日
Nicolas Produit は 2 つのバグを報告しました。最初のバグは、ケース ラベルがケース セレクターの後にスペースを挟まずに続いた場合の不正な構文エラーでした。適切な場所に g95_gobble_whitespace() への呼び出しを追加しましたが、すべて問題ありません。2 番目のバグは、モジュールの作成に関するものでした。彼のコードは現在のバージョンでは壊れていないので、うまくいけば問題ありません。
12月12日
名前空間をロードするためのコードを完成させた後、以前に欲しかった啓示の 1 つを得ました。入れ子になったインターフェイス ブロックによって作成された入れ子になった名前空間を実際に再構築する必要がないことに気付きました。そのままにしておくと、インターフェイス内のシンボルは、匿名シンボルとしてプライマリ名前空間に読み込まれます。これは、既に正常に機能しているメカニズムです。物事はまだ正しいことを指しており、すべてが問題ありません。書いたばかりのものをたくさん削除してしまい、うまく機能しているようです。
12月10日
Michael Richmond は別のコア ダンプについて書いています。今回は代替リターンでサブルーチンを解決するときです。ある意味では、仮引数リストの処理が急速に変化していることを考えると、これはそれほど驚くべきことではありません。
モジュールの読み取りを非常に役立つように更新するのが少し遅すぎました。私が持っているものでは、シンボルが正しい名前空間に配置されていないことはわかっていますが、現在のコードでこれがどこで発生するかはわかりませんでした。私はいくつかをやり遂げたので、明日それに取り組む必要があります。
12月9日
g95 との良い一日。インターフェイス内のインターフェイスの保存と復元に対処する方法を見つけました。それには、シンボルがどの名前空間にあるかを示す数字を各シンボルとともに格納する必要があります。保存されるすべてのシンボルは、以前と同じテーブルにあります。シンボルの名前は、このテーブルでは重要ではないことに気付きました。インターフェイスを持つシンボルが通常のトラバーサルで見つかった場合、その名前空間などを再帰的に保存するだけです。
これに取り組んでいる間に、私は最終的にあちこちに散らばっているほとんどの解決サブルーチンを取り除き、それらを新しいファイル resolve.c に入れました。この「新しい」ファイルにはすでに約 1,000 行が含まれており、他のファイル、特に expr.c のサイズが大幅に縮小され、現在は約 1500 になっています。
インターフェイスの解像度も少し変更しました。これらは解析後に型解決されます。これらはスコープ単位であるため、型を判別するために必要な情報はこれ以上ありません。サブルーチン g95_set_default_types() が呼び出されていましたが、それだけでは十分ではありませんでした。この場合、名前が変数であるかプロシージャであるかにかかわらず、変数のフレーバーも設定する必要があります。プロシージャの場合、その情報はインターフェイス自体を解析することによって既に設定されています。残りの FL_UNKNOWN は実際には FL_VARIABLE です。
Thomas Koenig は、私が昨日紹介した g95 の問題点を指摘してくれました。シンボルを書き込むためのループは、モジュールに何も書き込まれなくなるまで走査を行います。トラバーサル後の古いファイル位置 (fpos_t) と新しいファイル位置を比較して、これを確認していました。さて、大きなファイルをサポートする Linux システムの場合、fpos_t は int ではなく、私が思っていたように long long でさえないことがわかりました。それは構造構造であることが判明しましたが、これはうまく比較できません。
そこで、module_locus 構造体の行カウンターと列カウンターを比較する元のスキームに戻ります。モジュールの作成は機能しているように見え、昨日追加した新しい読みやすさの変更により、見やすくなっています。次に、新しい形式の読み取りに進みます。
12月8日
今日は g95 で質の高い時間を過ごしました。モジュールの書き方を書き直しました。モジュールのロード方法により対応するようになりました。アクセス指定が許可されている場合、シンボルが書き込まれます。これらの記号が他の記号を参照する場合、それらの記号も同様に記述されます。多くの古いぎこちなさがなくなり、モジュールの形式がわずかに変更され、デバッグ目的で人間が読みやすくなるように改善されました。
しばらく標準を調べた後、インターフェイスは相互に含めることができ、これらの介在するインターフェイスは引数リストで使用される型を定義でき、これらの引数はホストに関連付けることができることがわかりました。G95 はこの種のものを解析しますが、モジュール ファイルにロードして保存する必要があります。
これは、シンボル以外の他のエンティティを参照するには、より一般的なアプローチが必要であることを意味し、シンボルは必ずしも最初の名前空間に表示されるとは限りません。
ああ、DSL 接続も回復しましたが、これには十分な時間がかかりました。もうストローでインターネットにアクセスする必要はありません…
12月2日
形式引数リストを書き始めて途中までやってみると、モジュールの書き方が脆弱で、同じように動作する 2 つのトラバーサルに依存していることに気付いたので、1 回のトラバースで動作するようにする方法を考えることに取り組みました。
また、モジュールの読み取りがどのように機能するかについて、モジュールのドキュメントを更新しました。これはかなり古くなっています。
12月1日
MSN の顧客になることを避けようとしたため、ここ数日、私の DSL 回線がダウンしています。電話会社や新しい ISP の技術サポート担当者と充実した時間を過ごしています。どちらも、問題は相手にあると主張しています。したがって、ネットへの現在の接続は、ersatz PPP を使用した 14.4K 接続を介しています。
それでも、まだ SSH 経由で sourceforge にアクセスできるので、まだいくつかのことができます。形式的な引数リストを保存するという現在の問題は、今日の午後に行き詰まりました。これまで行ってきたことを破棄し、元の計画に近いものに戻ることにしました。特別な仮引数構造を保存して復元する代わりに、仮引数に関連付けられたシンボルの部分的な名前空間を保存します。私が実行していた主なプログラムは、派生型を処理する方法でした。
また、モジュール プロシージャ シンボルがどのように処理されるかについても、多くのことを考えてきました。2 つの個別の名前空間で 2 つのシンボルを維持する現在の方法は、非常にエラーが発生しやすいと判断しました。現在の計画は、両方の名前空間が同じシンボルを指すようにすることです。これにより、はるかにうまく機能するはずです。内部プログラムも同様に機能します。メイン シンボルは、両方の名前空間でも表示されます。
11月27日
昨夜の落書きのいくつかを、正式な引数リストを格納するための実行可能なスキームに変換することに少し取り組みました。チェックインはありませんが、ある程度の進歩はありました。私は馬鹿が書いた不必要に複雑なコードをデバッグするのに長い一日を費やしました。
11月26日
少し前に Steve Kargl がくれたテスト プログラムを実行したところ、驚いたことにコアがダンプされました。長い調査の結果、前回とは別の場所に投棄されていたことが判明しました。現在の問題は、仮パラメータと引数リストがモジュールに保存されていないことです。私はすぐに解決策を考え出しましたが、それでは不十分であることがすぐに明らかになりました。正式なパラメーターには独自の名前空間があり、それは私が持っていたものではありませんが、それ以下で済むと思います。
途中で、正式なパラメーターの型は他の型の前に解決する必要があることに気付きました。これは、本体を解決する前に、すべてのモジュール プロシージャのインターフェイス全体を把握する必要があるためです。これを行うためにいくつかのコードを追加しました。
G95 は現在 33,000 行の長さです。
11月25日
文字列プール コードが機能するようになりました。それは機能しているようで、近いうちにさらに多くの文字列が追加されるでしょう。
内積コードを実行すると、別の問題が明らかになりました。配列参照が式ノードに到達しません。私は、必要のない「形状」へのいくつかの紛らわしい参照を再構築するのに時間を費やしました。
関数解決コードを追加すると、多くの問題が明らかになりました…
11月24日
今日はいくつかのことができました。ホストの関連付けに新しい規約を実装しました。変数がホストに関連付けられている場合、現在の名前空間の symtree はホスト名前空間のシンボル ノードを指します。これにより、以前にホストに関連付けられていたものをユーザーが変更しようとしたことを検出できます。
型情報が伝播されていない関数解決の問題をいくつか修正しました。
dot_product() の単純化関数を開始しました。それはあなたが思いつくことをしません。実際に引数をコピーし、引数の型に基づいて正しいライブラリ関数を選択します。これにより、内部型変換関数の名前など、さまざまな定数文字列の文字列プールの必要性が浮き彫りになりました。
11月20日
Malcolm Cohen は、fortran の解釈に関する私の質問に答えました。私の例は標準にまったく準拠していないことが判明し、彼はその理由を突き止めることができました。この問題や同様の問題に対処するために、データ構造を変更することについて少し考えました。大きくはありませんが、緊張するほど基本的なものです。感謝祭の週末は、伝統的に fortran にとって良い時期でした。
11月18日
他のことで忙しくなり、さかのぼって型宣言をめぐって問題にぶつかりました。Miller テスト スイートの問題は、型宣言のホスト関連付けの失敗であることを確認しました。G95 は、使用後に型を宣言できるケースも処理する必要があるため、これを誤って処理します。これは、私には完全に間違っているように思えます。J3メーリングリストに通訳依頼を投稿しました。
Miller スイートを機能させるには、最終的には正しいとは限らないかもしれませんが、いくつかのクラッジをまとめる必要があると思います。
Steven Bosscher は、SGI がプロジェクトをサポートしていないにもかかわらず、Pro-64 コンパイラの開発が継続されていることを指摘する手紙を数日前に送りました。Open-64という名前で sourceforge にあり ます。
11月13日
Steven Bosscher は内部ドキュメントを texinfo フォーマットに変換し、そこから pdf に変換しました。リンクはページの上部にあります。
先週の追加の 2000 件のヒットについて誰も説明していないので、ボットの仕業のようです。
11月12日
Steve Kargl は、最新のスナップショットからのモジュール手順でも失敗したテスト ケースを送信しました。現在のg95で試してみましたが、静かに失敗しました。モジュール プロシージャである関数のタイプは、モジュール プロシージャ自体の前に決定する必要があることに気付きました。つまり、モジュール プロシージャが相互に呼び出すことができます。
これを行うコードをいくつか追加しました。パッチは複数のソース ファイルにまたがっていますが、それほど大きくはありません。スティーブンのコードは機能し、私の小さなテスト ケースは機能しますが、この混乱全体を引き起こしたミラーのクワッド精度モジュールはまだ機能しません。原因は、派生型が同等であるべきときに同等として表示されないことです。このクマは以前に頭をもたげてきたので、直すのは簡単ではありません。
Steven Bosscher さんは、DO ループと FORALL ループが表示されている st.c で不要なキャストが行われていることを指摘しました。私はそれをこの現在のパッチに追加しました。
11月11日
オーバーロードされた組み込み演算子に関連付けられたモジュール プロシージャが機能するように、より多くの作業が行われました。いくつかの新しいコードが追加されましたが、ほとんどは既存のコードの再配置でした。再配置は、すべての規則に準拠するために必要であり、同じシンボル名を 2 つの異なる名前空間に保持するという厄介な必要性に対応するために必要でした。
私はほとんどそれを持っていますが、それは遅くなっています。
Web 統計を見ていたら、11 月 8 日に 2000 ページ ビューの急増があり、9 日に約 800 ページ ビューが続きました。先月 Linux World News で取り上げられた記事では、通常の 200 ～ 300 ヒットを上回る約 700 ヒットが生成されました。これがどこから来たのか知っている人は、私かメーリングリストにメールしてください.
11月10日
昨日、Udo Grabowski の恒星モデル コードをダウンロードしました。’tar tvfz’ を実行する以外に何もする機会はありませんでしたが、g95 でテストするには大量のコードのように見えます。
今日、関数の解像度に対する小さな修正がたくさんあります。今のところ、モジュール プロシージャがどのように機能するのかということに行き詰まっています。主なテスト コードは Alan Miller の quad precision パッケージであり、組み込み関数と同じ名前の汎用インターフェイスを定義するなど、多くのことを行います。
11月7日
Michael Richmond は、最後の一連の変更に対してバグ レポートを送信しました。非常にばかげたミスにより、外部関数がコア ダンプを引き起こしていました。いくつかの単純なケースは正しく機能しているように見えるので、明日はさらに詳細なテストを行うつもりです. ここ数日間話していた変更がチェックインされました。
Katherine は -l1 オプションに関して若干の変更を加えました。
Steven Bosscher は現在、CVS リポジトリへの書き込みアクセス権を持っています。私はバックアップを作成しました… 🙂
11月6日
3 つのケースそれぞれの解決を処理するすべてのサブルーチンを作成しました。このコードは本当に未加工で、場合によっては非常に間違っている可能性があります。いくつかのテストの後、チェックインします。
11月5日
Michael Richmond が、私が 2 日前に紹介したバグについて書き込んでくれました。問題は、CHAR() が汎用関数であり、独自の (そして唯一の) 固有であることです。私が最初に make_generic() を書いたとき、これが可能だとは思いませんでした。実際に起こったことは、CMPLX が CHAR 固有のものになってしまったということです。彼のコードは次のとおりです。
キャラクター※2 あ
A = CHAR(1)
「1」は「(1,0)」に変換され、A に割り当てられたときに爆撃されました。
Tim Prince は、SGI ライブラリに関するリストへのメッセージを書き込んでいます。彼の最高のセリフは次のとおりです。
通常の C プログラマーが Fortran と移植性を軽視するマイナーケース
最悪の問題には、プロトタイプを作成せずに関数を使用したり、SGI 固有のヘッダーを使用したり、16 進数の配列で浮動小数点数を定義したりすることが含まれます (あまり移植性がありません)。
Steven Johnson さんは、config.guess が MacOS システムを識別できなかったのは古い config.guess が原因であると説明し、新しいバージョンを見つける場所を示すメモを送信しました。新しいバージョンは MacOS を認識します。問題は、コンパイル ファーム マシンに Python がインストールされていないことです。
config.guess は x86 BSD の認識に関する問題を修正したため、テスト スイートには 5 台の通常のマシンが含まれています。現在の結果はすでに出ており、すべてのプラットフォームで成功と失敗が同じように見えます。
Wolfenstein Test 2 を数時間プレイしたにもかかわらず、セクション 14.1.2.4 のルールを実装して、プロシージャ コールが一般的か、特定的か、または不明かを判断しました。私のお気に入りの戦術は、味方が手榴弾を手に入れた後、手榴弾を前方の掩蔽壕の前に放り込み、続いて正面玄関から奇襲攻撃を行うことです。唯一の大きな変更点は、プロシージャがインターフェイス本体内にあるかどうかにフラグを付けるために少し追加する必要があったことです。次に行うことは、これら 3 つのケースのそれぞれで関数名を解決するための手順を実装することです。おそらく明日のいつか、これらを行う必要最小限のルーチンがあるときにチェックインします。
11月4日
今日、ティム・プリンスからメモを受け取りました。彼は pro64 libio の構築に取り組んでおり、その I/O コンポーネントを特定しました。彼がどこにいるのか楽しみです。
テスト スイートに追加したい MOM3 という無料で入手できる天気予報コードを見つけました。これはGeophysical Fluid Dynamics Laboratoryによって作成され、ダウンロードできます。これは約 75,000 行のコードで、Fortran 77 コードとして誕生し、しばらくの間 fortran 90 に向けて変化しているように見えます。一見すると、コードはプリプロセッサ ディレクティブを多用しており、g95 に適したものにするために少し作業が必要です。
Jonathan Dursi は、それを形にすることを志願しました。
誰かが寄付したい大きなコードを持っている場合、またはコードが利用可能であることを知っている場合は、私たちに知らせてください.
11月3日
今日、ウド・グラボウスキから手紙が届きました。彼は、テスト スイートに使用するコードの 1 つを提供するつもりでした。NDA は大西洋を 3 回横断しましたが、全員が満足するまでに、しばらく彼から連絡がありませんでした。彼は休暇中で、米国南西部でロードトリップをしていたことが判明しました。
セクション 14.1.2 の関数解決規則の実装に取り組み始めました。
名前が一般的な関数名か特定の関数名かをチェックする関数のペアをintrinsic.cに追加しました。名前が両方になる可能性があるため、そこにあった関数は機能しませんでした（たとえば、ABS（）など）。シンボルのリストには、CHAR()、INDEX()、LLT() などのような、思いもよらない一般的なものや特殊なものがたくさんありませんでした。これらは別の文字の種類をサポートするためにあると思います。
11月2日
アルファ アーキテクチャのみにかみついたように見えるフロア簡略化機能のコア ダンプを修正しました。テスト スイートの 87% がコンパイルされ、スイートの 1% でエラーが発生すると、残りの 12% はテストされません。残りの問題を調べてみたところ、機能の解決が飛び出したので、このクマに取り組む時が来たのかもしれません。
11月1日
Marcus Lundblad のコードを見る機会があり、実際の引数リストを操作するコードにコア ダンプが発生する原因が見つかりました。怖い。
Michael Richmond は、私が昨日修正しようとした MIN()/MAX() の返される型の欠陥を指摘する手紙を送りました。詳細は機能しましたが、ジェネリックには問題がありました。ある時点で正しいタイプを設定していましたが、後で壊れていました。
autoconf 2.50 へのアップグレードにより、テスト スイートで問題が発生しました。config.guess は、power pc アーキテクチャでわずかに異なる名前を返します。これも修正されました。
10月31日
マーカスはそれらのファイルの残りを送信しましたが、私はまだそれらを見る機会がありませんでした. MAX() 関数に関連するコア ダンプを修正し、正しい型を返すように MIN/MAX ファミリをアップグレードしました。
10月30日
Marcus Lundblad はコアをダンプするプログラムを送信しましたが、そのプログラムはメールに含まれていないモジュールを使用していたため、問題を再現できませんでした。私はしばらくの間、ミラー スイートに残っている 2 つのコア ダンプのうちの 1 つを追跡しました。ダンプはいくつかの GMP ルーチン内にあったため、何が起こっているのかわかりませんでした。バイナリチョッピングのプロセスの後、問題は MAX() 内にあると思います…
また、追跡する必要のあるテスト スイートに関する問題もいくつかあります。
10月28日
Marcus Lundblad は、他の人が指摘した問題について書き込んでいます。configure スクリプトは、ビルド システムに実際にインストールされている場合、GMP ライブラリを見つけるのに問題があります。–with-gmp-dir が CPPFLAGS と LDFLAG の値を変更するように、スクリプトを単純化しました。次に、スクリプトは通常どおりインクルードとリンクの試行を行います。このアプローチは、数週間前に Steven Johnson によって実際に提案されました。
autoconf をバージョン 2.52 にアップグレードしました。これは、毎晩のダウンロードで tarball に反映されます。
コンパイルする MacOS バージョンを入手しましたが、問題は config.guess がシステムを識別できないことです。これは、 –build=none オプションが必要であることを意味します。これにより、通常のテスト スイートに追加することが難しくなります。
また、simplify.c でいくつかのコア ダンプを削除する作業も行いました。
10月24日
Ross Bogue は、MacOS X で g95 を動かすには何が必要かを尋ねた。私は彼に GMP が主な問題であると話し、彼は間違ったアセンブラ ライブラリを使わずに GMP をコンパイルする方法を見つけ出した。を使用すると、
–target=なし
、それから GMP はアセンブラ コードに凝ろうとせず、純粋な C を使用します。彼はそれを動作させ、些細なプログラムで成功を報告しましたが、それ以上の動作をすると思います。
これを Mac の sourceforge コンパイル ファームで複製しようとしたところ、ライブラリが正常にビルドされましたが、リンクしようとすると問題が発生しました。autoconf のインストールが古すぎて Mac のアーキテクチャを認識できず、構成の問題が発生することが判明しました。そこで、かなり古い (2.13) autoconf のアップグレードを開始しました。
私は今晩、Steven Bosscher のコードの一部を変更し、(CONTAINS のような) ステートメント ラベルを持つべきではないステートメント ラベルのチェックを上方に移動して、エラー レポートがバッファリングされるのではなく即時に行われるようにしました。
今夜、論文を印刷しました。160 ページで 3M の追記があり、まだ書きかけの小さなセクションが 1 つあります。予想外のスリルでした。
10月22日
ステートメント ラベルが 2 回定義される問題を修正しました。これにより、多くのテスト スイートが失敗していましたが、LAPACK77 は Linux/x86 で問題なく解析できるようになりました。スイートがより定期的にコンパイルされるように手配する必要があります。
10月21日
先週は g95 とはあまり関係のないことがたくさんありました。私の論文はほぼ完成し、私は病気になりました。固形物を食べずに 2 日間過ごした後、消化器系の再起動がほぼ完了しました。
g95 ニュースでは、テスト スイート ドライブが完成し、CVS にチェックインされているようです。現在のテスト マシンは、x86 linux、alpha linux、ppc linux、および sun space です。
誰かがネット上に別の OS/アーキテクチャのマシンを持っていて、早朝のサイクルを寄付したい場合は、それを使用できます。テスト プログラムは自動的にクリーンアップされ、ほとんどのマシンで実行するのに約 30 分かかります。必要なのはアカウントだけです。寄付に興味がある場合は、私にメールしてください。
メーリングリストでバックエンドとライブラリに取り組むことについて話し合っていたので、私が見ることのできるマイルストーンのリストを投稿しました。
10月15日
コンパイル ファームへのアップロードとコンパイル ファームからのダウンロードが機能しないことがわかりました。そこにあるファイルが壊れていたので、別の方法を見つけなければなりませんでした。午前0時53分現在、動作しています。これは、3 つまたは 4 つのテストベッドを意味するため、悪化させる価値があるはずです。g95 に戻る前に、これ以上の作業が必要ないことを願っています。
10月14日
今日と昨日、再び回帰テスト スクリプトに取り組みました。彼らはほとんど準備ができています。g95 のコンパイル方法とテスト方法に関する一連の情報をここで更新しました。貢献している人々は、テスト スイートの独自のコピーをダウンロードし、mkf90.py を使用して自分の作業を確認する必要があります。
久しぶりの g95 での最初の大規模なテストでは、テストが実行されていない間にかなり壊れていたことが示されています。私はテストに多くの時間を費やしてきましたが、これまで以上にその重要性を確信しています。
また、sourceforge との間でファイルを送受信するための作業もいくつか完了しました。これにより、すぐにテスト マシンをいくつか使用できるようになります。アップロードは正常に機能しますが、ダウンロードで奇妙なことが起こっています。
Steven Johnson は、他のマシンの g95 構成に、自分のマシンの構成データが残っているという奇妙な動作についての質問に答えました。基本的な要点は、アップグレードすることでした。これは、物事を修正するための非常に簡単な方法です。
10月11日
テスト スイート スクリプトに取り組み、マスター ドライバーとローカル ドライバーの最初のリビジョンを CVS にチェックインしました。mkf90.py の新しいバージョンもあります。これは、開発者によるローカル テスト用のスタンドアロン プログラムとして、および local_test.py によってインポートされたモジュールとして機能するようになりました。
暫定結果ページはhttp://g95.sourceforge.net/results で見ることができ ます。
10月10日
メールは戻ってきましたが、アドレスはすぐに変更されます。
後藤分岐の処理を改善するために、Steven Bosscher が 1、2 日前に送信したパッチを追加しました。
10月9日
あなたが今日か昨日私にメールを送ったとしても、おそらく私には届かないでしょう。とにかく、andy@xena のアドレスがこれ以上長く続くとは思っていなかったので、別の電子メールをアクティブ化しようとしています。
10月7日
長い間更新がありませんでした — 非 g95 は多忙を極めていました。私の委員会がそれを終えた後、私の論文が利用可能になるかどうか、何人かの人々が尋ねてきました. すべてが終わったら、論文と私の論文へのリンクをここに置きます。
私は HP コンパイルの問題について Michael Richmond と、さまざまな問題について Steven Bosscher と話し合ってきました。彼は、文字の SELECT CASE ステートメントのテストとジャンプのコードをほぼ完成させました。Steven はまた、私のドキュメントの一部を texinfo に変換しています。プレビューはよさそうでした。
Toon Moene さんが興味深いメールをメーリングリストに投稿しました。彼は、私たちが実際に GCC バックエンドで作業を開始する時期を楽しみにしています。少し考えてみたところ、今すぐ着手できない理由がわかりませんでした。主な問題は、実際に取り組む人です。トゥーンは志願したようで、彼の著作権譲渡はすでに FSF に登録されています。
今夜、テストスクリプトにもう少し取り組みました。出力は正しく表示され、最終結果を sourceforge にアップロードするスクリプト部分が完成しました。さらにテストが必要ですが、結果は数日で表示されるはずです。
9月30日
Steven Kargl は、gmp が実際にインストールされている gmp ライブラリーを見つける configure スクリプトに関するいくつかの問題についてメモを送りました。うまくいっているようです。
Steven Bosscher は、文字ケースに必要な SELECT CASE 分岐とジャンプにまだ取り組んでおり、分岐制限を強制しないという g95 のいくつかの欠陥に遭遇しました。
今週末は色々とやりました。ウェブページを作成するためのテスト プログラムを作成する作業を開始しました。今のところ半分くらいは動いています。
9月27日
今日は論文作業が一段落したので、テスト スイートの作業を増やしました。この時点で、sourceforge からファイルをダウンロードし、tarball を作成し、リモート マシンに送信し、展開し、g95 を構成し、コンパイルしてリンクします。次に、テストのコンパイルを開始し、結果を収集します。結果はまだダウンロードされていませんが、ダウンロードされると、結果から Web ページが作成されます。
これについて言及したかどうかはわかりませんが、現在のテスターは一度に複数のマシンを駆動します。最終的な出力には、予備のサイクルを寄付してくれる人からの結果が表示されます。
9月24日
今日はあまり時間がありませんが、リモート スクリプトを動作させることができました。ここで必要なのは、結果をダウンロードし、結果の Web ページをビルドしてアップロードする部分だけです。現在の混乱は 1200 行の Python であり、そのうちの約 500 行が既に配置されています。
9月23日
Steven Johnson は、20 日に私たちにリンクしたのは Linux World News であり、これらすべてのヒットを引き起こしたと報告しました。彼はまた、私が実装した構成システムにさらにいくつかの調整を加えることを提案しました。
Steven Bosscher は、文字 SELECT ステートメントの分岐とジャンプを実装するパッチを送信しました。整数選択の場合、gnu バックエンドは範囲を既に認識しており、SELECT をジャンプ テーブルに変換することもできるため、引き続き使用します。これは、SELECT を実装する最も高速な方法です。
私はテストスイートで進歩を続けてきました。私は、ローカル マシンで実行し、さまざまなテスト プログラムをコンパイルするスクリプトに取り組んできました。これはほとんどが mkf90.py スクリプト (CVS の /test の下にあります) のコピーであるため、ほぼ完了です。この後は、結果を収集して Web ページを作成するだけです。
Return to Castle Wolfenstein の Linux バージョンをダウンロードすることで、進行が妨げられました。どういうわけか、自分がドイツ国防軍の狙撃兵になるとは思っていませんでした…
9月21日
ここ数日間、スティーブン・ジョンソンが美徳を絶賛してきた魔法の「メイク・ディスト」は本当にうまくいっているようです. tarball をダウンロードしたい人は、すべてのディストリビューションと同じように見える tarball を取得します。’configure’ と ‘make’ と入力するだけで、必要なファイルを取得できます。configure.in やその他の設定ツールに変更を加える人にとっては、少し複雑です。configure に渡されるいくつかの引数を指定して「autogen.sh」を実行する必要があります。g95 の場合は、gmp ライブラリが存在する場所です。 .
昨日、ウェブサイトには記録的なヒット数があり、通常の 2 倍強でした。私たちにリンクしてくれた人に感謝します (彼らがどこから来ているのかわかりません)。
9月20日
Steven Johnson と私は、autos についてメールでやり取りしています — autoconf、automake、autoheader などなど。私の側で少し抵抗した後、彼は私に光を見させてくれたと思います。とにかく、このビルドは私が思っていたよりもずっと複雑です。詳細についてはまだ議論中です。
Steven Bosscher は、END および end of block ステートメントのステートメント ラベルを処理するバグを発見しました。これは、いずれ対処する必要があります。私も先日、メールボックスを整理していて、g95 が型と型をエラー メッセージに出力する方法の変更に関する彼のパッチを見つけたので、すぐに適用する必要があります。
9月17日
Steven Johnson は、configure.in を見て笑って、いくつかの改善点を提案してくれました。彼は、私が長い間頭を悩ませていたいくつかのことを行うためのより良い方法を教えてくれました。私は彼にいくつかの問題を説明する手紙を持っています。
Steven Bosscher は、選択するものをさらに追加するパッチを送信しました。主に、範囲の上下に無制限の間隔を追加することを扱います。
今日トビからメールが来ました。彼はマルセイユで交換プログラムを行っています。インターネットのアクセスが非常に悪いので、最近読んでいる 802.11 に関する戦争推進記事のいくつかを指摘しました。うまくいけば、^H^H^Hより良い接続がすぐに見つかるでしょう。
キャサリンはすぐに転職し、未解決の問題を解決するために取り組んでいます。彼女は来月の g95 にもっと時間を割きたいと思っています。私は、論文の作業に関連して、彼女のクラスターで約 10,000 CPU 時間を使用したと考えています。これには非常に感謝しています。私に関する限り、g95 はすでにいくつかの重大な配当を支払っています。
彼女の義理の家族はメサからそれほど遠くないアリゾナ州サプライズに住んでおり、彼女は数か月後にここに来るかもしれません. インターネットで知り合った男性と食事に行くことを説明しなくてもいいように、彼女の夫も夕食に招待しました…
Steven B. が先日見つけた eval_intrinsic() のバグを修正しました。”A”<“Z” のような式は、解析時に削減されませんでしたが、現在は削減されています。
9月15日
少なくとも今のところ、autoconf に関連する策略を終了しました。Makefile を削除し、Makefile.in、configfigure.in、config.sub、config.guess、install-sh、configure を追加しました。configure スクリプトは、autoconf を実行することによって configure.in ファイルから生成されるため、厳密にはソース ファイルではありませんが、最近ではほとんどの人がソフトウェアを構築する方法であるため、存在しています。
新しいシーケンスは、’configure’ を実行して Makefile を生成し、次に make を実行することです。configure スクリプトは現時点で単一の g95 固有の引数 –with-gmp-dir=PATH を取ります。これは、g95 に、システム ライブラリが通常行く場所にインストールされていない場合に GMP ライブラリを見つける場所を指示します。どのホスト構成が実行されているかに応じて、複数の可能なライブラリに対してリンクできるようにするテストのサポートもあります。
Steven Bosscher は、私たちが取り組んでいる文字列を比較する際の問題をいくつか指摘しました。新しい関数 g95_compare_string() を追加しました。この関数は、fortran のように文字列を比較し (異なる長さは最後にスペースを埋めます)、ASCII と潜在的に非 ASCII の照合シーケンスも処理します。キャサリンは、ASCII 以外の文字セットの取り扱いについて良いスタートを切ったので、これで終わりだと思います。
