12月31日
小さな修正がたくさん。前回紹介した機能の不具合を修正。この問題は、含まれているモジュール関数に対してシンボル ノードを 1 つだけ作成することに関係しています。含まれているモジュールでは関数は変数であり、モジュール名前空間では関数は実際には関数です。
別の問題は、フォーム f(a==b) の関数呼び出しの解析でした。引数マッチャーは、本来あるべき「a=」を破棄していませんでした。
‘SAVE’ として宣言されているステートメント関数の仮引数の問題を修正しました。これらの引数のエンティティに ‘DUMMY’ 属性を適用しないことで問題を解決しました。
12月20日
関数宣言パーサーの修正に問題があったようです。クリスマスに帰る準備をしているので、今日は直す時間がありません。私の兄弟は DSL 接続を持っているので、私はいくつかのことを行うことができるかもしれませんが、多くを期待するつもりはありません. 30日頃にアリゾナに戻る予定です。
12月19日
昨夜の修正により、多くのことが修正されました。LAPACK はほとんどコンパイルされるようになりました。別の問題が修正されました。インターフェイスに含まれるプロシージャのタイプに応じて、ジェネリック名に ‘function’ または ‘subroutine’ 属性を指定する必要があります。サブルーチンと関数が混在するジェネリック インターフェイスのエラー メッセージも追加されました。
しばらく前に、Michael Richmond が、関数が独自のプログラム単位で持つ属性に関係する問題を報告しました。結果変数が指定されていない限り、関数名は実際には「変数」です。これにより、最初に g95_match_actual_arglist() の重要な修正が行われました。実際の引数リストは、BT_PROCEDURE の typespec を使用して、プロシージャ名を並べ替えの式として使用できる場所の 1 つです。
とにかく、問題は修正されたようです。
12月18日
‘intrinsic’ 属性を追加していた関数 g95_match_optional() を修正しました。これにより、LAPACK ライブラリによって作成されたモジュールで問題が発生し、そのディレクトリ内の他のすべてをコンパイルできなくなりました。
12月17日
見逃していた昨日の残りの問題をいくつか修正しました。これには、定数を表していない式ノードで数値演算を実行しようとすることが含まれていました。
構造コンストラクターのマッチングの問題を修正しました。コンポーネントが親名前空間からのものである場合、コンポーネントがコピーされませんでした。
g95_charlen 構造体がモジュールで読み書きされるようになりました。
12月16日
変更を完了し、新しい式サブルーチンを式パーサーにフックしました。私がテストした限り、物事は元の場所に戻っています。今夜遅くに実行される自動テスト スイートに備えて、CVS への変更をチェックインしました。Sourceforge はハードウェアをアップグレードしましたが、セキュア コピーはまだうまく機能しません…
また、FSF の新しい割り当て手順を反映するために、投稿ページにいくつかの変更を加えました。
12月15日
今夜はあまり時間がありませんが、オーバーホールの作業が続きます。残された唯一のことは、式を単純化するための現在のスキームを削除し、新しいサブルーチンをメインの式パーサーにフックすることです。この新しいスキームは、私が以前に考えていたよりもさらに一般的なものになるようです。私が現在行っていることは、配列引数を持つものであっても、組み込み式の単純化を処理する必要があります。
12月13日
算術オーバーホールにさらに取り組みました。テストを開始する準備がほぼ整いました。その後、初日から存在していたクラフトを削除できます。
私は FSF から彼らの新しい代入手順に関する回答を得て、Walter に返送しました。彼は SELECT CASE ステートメントのオーバーラップ チェックを実装することを考えていました。明日のどこかでウェブページを更新しようと思います。私はスキーに行くので、そうではないかもしれません…
12月12日
うわあ！丸一週間が過ぎました！何と言えばいいでしょうか? やらなければならないことをやり遂げようとして忙しかったのです。Walter Silvestri から、著作権譲渡フォームへのリンクが壊れていることがわかりました。私が知る限り、フォームはウェブ上で利用できなくなりました。
正気な人々は、フリーソフトウェアに専念する組織が、その組織に貢献するために必要な法的形態を隠す理由を不思議に思うでしょうが、FSF はエリートの狂気に少なからず与えられています。たとえば、この3 番目の段落を確認してください。
人称代名詞に性別があることに腹を立てる人は、おそらく他にも深刻な問題を抱えているでしょう。
とにかく、私は状況再割り当てフォームに取り組んでいます。
今夜の G95 の内容は、F 言語が fortran に課す制限のリストを書き留めることでした。これは、長らく放置されていた投稿ページの刷新の一環です。Walt Brainerd はしばらく前にこれらのリストを送ってくれましたが、私は紛失しましたが、より包括的なリストが彼の Web サイトにありました。
12月5日
まだ arith.c 内で再配置中です。私が取り組んできた変更は、基本的に式の単純化を並べ替えるものです。考えられるすべての式を単純化できることはそれほど重要ではありません。バックエンドは式ツリーのさまざまな部分で定数の折りたたみを処理し、フロントエンドでこれを複製しても意味がありません。
フロントエンドが実行できなければならないことの 1 つは、完全に定数で構成される式をコンパイル時に適切な定数に減らすことです。たとえば、PARAMETER の値を決定します。
以前のバージョンでは、式パーサーが式ノードのツリーを構築していました。その後、定数式を正しい定数に還元できる再帰的単純化関数が呼び出されました。初期化式では、関数参照は、他の場所の関数参照とは異なり、組み込み関数に自動的にバインドされます。単純化関数には、このように関数を攻撃するためのフラグがありました。
新しいバージョンでは、順序が少し変わります。式パーサーに、結合する必要がある 2 つの被加数がある場合、次の呼び出しが行われます。
g95_add(op1, op2)
これは、2 つのノードの合計である新しいノードを返します。2 つのノードが定数である場合、新しいノードは op1 と op2 の算術和になります。後で、式が初期化式である場合、現在の単純化関数の簡素化されたバージョンは、適切な組み込み関数ハンドラーを呼び出してその処理を行います。
美的な再配置のように聞こえますが、これにより、特にコンパイル時に組み込み式を削減する関数内で、算術演算がはるかに簡単になります。Katherine Holcomb が気付いたように、g95_arith_* 関数は使いにくいものです。
特に厄介な場所の 1 つは、配列コンストラクターから作成された配列定数です。このスキームでは、g95_add() を呼び出すだけで、配列を処理していることに気づき、g95_arith_plus() を繰り返し呼び出してその仕事を行います。新しいスキームでは、同じ関数を使用して式を構築および縮小できます。
しばらくの間、これを計画していましたが、本当の原動力は、テスト スイートの問題の大部分が初期化式の削減の失敗であることに気付いたことです。
12月4日
式ノードのオーバーホールにさらに取り組みます。変更はそれほど大きなものではありませんが、g95 が式パーサーとして始まった初期の頃から存在していた g95 の一部に対するいくつかの基本的な変更を反映しています。詳細は後で説明します。かなり遅れています。
12月2日
Andreas Schweitzer さんが、INQUIRE 文の IOLENGTH 形式の解放に関連する内部エラーを報告しました。問題は修正されました。
Rob Cermak さんは、エラーのあるモジュールからモジュール ファイルが書き込まれていることを指摘しました。ソース ファイルを再コンパイルする必要がないと ‘make’ プログラムに思い込ませるので、これは非常に悪い考えです。この場合、モジュール ファイルが書き込まれず、既存のモジュール ファイルが削除されるように変更しました。
配列定数を処理し、組み込み演算をより簡単にするために、式処理のオーバーホールを開始しました。
11月30日
Rob Cermak さんは、KIND 組み込み関数に対する昨夜の修正により、g95 によって正常に解析されるソース ファイルの数が大幅に増加したと報告しました。Mark Dewing は、fortran 90 ソース ファイルのディレクトリを読み取って makefile を作成するために使用できる、いくつかの perl ツールの URL を投稿しました。うまくいけば、これでさらに改善されるでしょう。
昨夜のジレンマの 3 つ目の方法を思いつきました。代わりに、適切な型が親プログラム ユニットにある場合は、派生型のコンポーネント リストを単純にコピーすることにしました。これは事実上、別個であるが等しい型を定義します。派生型の解析にさらにいくつかの診断を追加しました。これで、型を 1 回しか定義できなくなりました。
コマンドライン オプション -ffree-form および -ffixed-form も追加されました。これは先日メーリングリストに出てきました。ファイル名の拡張子に関係なく、ソース ファイルが固定形式または自由形式として解析されます。
11月29日
テスト スイートで見つかったいくつかの小さな問題を修正しました。これらには、KIND() 組み込みのコア ダンプが含まれていました。また、内部エラーの代わりにプレースホルダー コードを生成するように構造 I/O を変更しました。構造を印刷するためのコードの生成は、コードを生成するための機械が増えるまで待たなければなりません…
その夜の主なジレンマは、型の前方参照でした。型が定義される前に、派生型の関数を宣言できる特別なケースがありました。この特殊なケースが実際のルールであることがわかりました。派生型の変数は、型自体の前に宣言できます。
ホスト プログラム ユニットでは、これが問題を引き起こします。派生型変数が宣言されている場合、それは何を参照していますか? タイプが後で定義される場合、それが使用されます。型が定義されていない場合は、親プログラム単位で定義された型が使用されます。これらの typespec 構造体は何かを指す必要があるため、最初に使用するときに型のシンボル ノードを作成する必要があります。しかし、それは後で間違いであることが判明するかもしれません。
2 つの可能性が示唆されます。最初の非宣言ステートメントが検出されたときに名前空間全体をパスし、適切なものを指すように typespec 構造を更新するか、派生型 typespec ノードを指定してシンボル ノードを返すアクセサー関数を記述します。
現時点では、typespec 構造からシンボル ノードに移動する必要がある場所があまり多くないため、関数または単に何かをインライン化する方向に傾いています。match_varspec() は注目すべき例外です。
11月26日
プロシージャ名が保存される場所が変更されました。通常、親の名前空間に保存されるようになりました。これをデバッグしたところ問題ないようです。RK コードはエラーなしで解析されるようになりました。
Erik Schnetter さんが、名前の一致に関する問題を報告しました — 31 文字ではなく、30 文字しか一致しませんでした.
11月23日
モジュール内のインターフェイスの保存と読み込みをデバッグしました。うまくいくようです。これに取り組んでいて本当に気のめいるのは、Fortran 95 のこれらの暗いコーナーを使用する人がほとんどいないという認識です…
11月22日
オペレーター インターフェイスにプライベート属性とパブリック属性を追加しました。これらは、これらの定義がモジュールにエクスポートされるかどうかを制御します。また、symbol_attribute のパブリック ビットとプライベート ビットを 1 つのビットフィールドに変更しました。これにより、2 つのビットが両方ともゼロである必要がなく、ACCESS_UNKNOWN を簡単にテストできます。
PRIVATE シンボルを保存する必要があるケースに遭遇しました。検討：
モジュールa
プライベート g1
インターフェイス g
モジュール手続き g1
終了インターフェイス
含む
サブルーチン g1(x)
論理×
プリント *, x
サブルーチン終了
エンドモジュール
g はモジュールと共にエクスポートされるため、「アクセス可能」でなくても g1 を実行できます。「call g1」ではエラーが発生しますが、「call g(.TRUE.)」では期待どおりにリンクして実行されます。この場合、新しいネームスペース内の g1 のローカル名が不正なものになる必要があります。
11月20日
いくつかのバグ修正をチェックインしました。g77 からオプション -fdollar-ok を追加しました。これにより、エンティティ名にドル記号を使用できます。
11月19日
g95_interface 構造は削除され、インターフェースは g95_symbol ノードをリスト内でリンクすることによって処理されるようになりました。変更はそれほど広範囲ではなく、デバッグされています。モジュール内の PUBLIC および PRIVATE 属性ステートメントの処理に関するいくつかの作業が行われました。これらの属性は、使用に関連付けられたシンボルを変更します。
より大きな変更点は、アクセス モードがモジュール内のシンボルに保存されないことです。モジュールが別のモジュールによって使用されている状況では、いずれにせよプライベート シンボルは 2 番目のモジュールにはなりません。将来のアクセシビリティは、 2番目のモジュール。
MODULE PROCEDURE ステートメントで定義された名前を関数名にするためのサポートも追加されました (サブルーチンのサポートは既に存在します)。
現時点では、selected_real_kind() 組み込み関数が常にデフォルトの real kind を返すように、Katherine Holcomb の Intrinsic.c に関する作業にパッチを当てました。これにより、多くのコードをエラーなしで解析できます。
11月15日
Katherine Holcomb は、少なくともコンパイラ自体の内部で組み込み関数を実装するための最初の試みである、intrinsic.c への大規模なパッチをチェックインしました。私の論文プロジェクトの問題が現在、g95 の進行を妨げています。
11月13日
インターフェイスの処理方法のオーバーホールを開始しました。特に、g95_interface は厳密には必要ではないようです。別の構造を使用せずに、シンボル ノードをリンクすることでインターフェイスを作成できると思います。今夜、おそらく数日間はチェックインしません。
11月11日
回帰テストの問題数を減らすという考えで、さらに多くのバグ修正が行われました。シンボル ノードへの参照カウントを追加しました。
11月10日
回帰テストで見つかった問題を修正し、さまざまな分野で多くのバグ修正を行いました。これらのエラー数が大幅に減少すると、不注意で導入された新しい問題を見つけやすくなります。
11月9日
昨日と今日はインターフェイスについて作業しました。これは、インターフェイスなどを保存/復元する前に完全にサポートする必要があるという意味で、モジュールからの脱線です。明らかになったことの 1 つは、シンボル ノードが複数の名前空間に存在できる必要があるということです。たとえば、モジュール プロシージャに関連付けられた名前は、モジュールの名前空間に存在する必要があります。これは、含まれているすべてのプログラム ユニットがその名前を見つけられる必要があるためです。また、サブプログラムの名前空間に存在する必要があります。これは、含まれている名前空間内でその名前を再利用できないためです。プログラム単位内に含まれるプログラム単位についても同じことが言えます。
要するに、シンボル ノードを正しく解放するには、シンボル ノードで参照カウントが必要になるということです。これは、使用関連付けによって複数回参照されるシンボルにも必要です。
11月7日
今夜は選挙観戦。今回は特に誰かを支持する時間はありませんでしたが、私は政治中毒者のようなものです。
11月6日
Niels Jensen から送信された、削除された機能の一致に関連するいくつかのパッチをさらに適用しました。インターフェイスの処理を改善する作業を開始しました。まだ何もチェックインされていません。
11月5日
Niels Jensen から送信された、削除された fortran ステートメントの一部、具体的には ASSIGN ステートメント、割り当てられた GOTO および H 記述子に一致するパッチを適用しました。
11月4日
f77 テスト コードの 1 つが文句を言い続けていた、フォーマット チェックに関するいくつかの繰り返し発生する問題の修正に取り組みました。問題は、以前に取り組んだ問題でした。つまり、文字列である (フォーマット ステートメントではない) フォーマットを精査することです。私は本質的にコードを元の方法に戻しました。つまり、ソース ファイルではなく文字列から読み取るようにしました。ソースファイルから読み取ると、エラー軌跡を出力できましたが、いくつかの問題がありました。1 つ目は、複数の文字列を連結することでフォーマット文字列を計算できることです。この場合、ソースを読み取るメソッドは失敗しました。2 つ目は、ソース ファイルを文字列に変換したり、エスケープ文字を正しく取得したりするのが複雑だったことです。だから私は物事を元に戻しました。
また、スキャナーに関するいくつかの問題の修正にも取り組みました。Tobi は、固定モードで行末コメントを食べるコードを少し前に追加しました。無料モードで類似のコードをいくつか追加しました。また、標準に従って、この場合「&」が行の最後の文字であるという文字コンテキストでの継続行の要件を強化しました。
11月3日
「あいまいな」ビットの実装に取り組みました。少し考えた後、g95_get_symbol() が呼び出されるたびにあいまいさをチェックすることを忘れないようにするのではなく、g95_get_symbol() をより精巧にすることにしました。問題は、g95_get_symbol() がシンボルを返し、あいまいなビットを中間の symtree に格納する必要があることでした。エンティティ (シンボル) はあいまいな参照を持つことができますが、別の名前による完全に明確な参照も存在する可能性があります。
あいまいなビットは symtree に格納する必要があるため、それをチェックする論理的なタイミングは、シンボル自体を検索するときです。これにより、g95_get_symbol() が常に機能してシンボル ノードを返す前に、新しいノードを作成する必要がある場合でも、失敗状態を返さなければならないという問題が発生しました。これは、参照されているすべての場所を調べて変更することを意味しました。
また、シンボル属性構造に use-associated ビットを追加しました。関数解決規則と、use-associated 変数を他の変数とは異なるものとして扱うその他の条件があります。特に、USE に関連付けられた変数の属性は、USE… の後で変更することはできません。
11月2日
モジュールの読み取りと書き込みのバグをさらに修正しました。g95 を使い始めた初日に、約 16k 行の長さの Runge-Kutta コードをダウンロードしました。約 2 か月前に、モジュールを編集して解析しました。今では何の助けもなしに解析されます。使用される唯一のものは、全体の種類を決定する整数パラメーターです。しかし、それはうまくいきます！
ふざけて、他の f90 コンパイラがこの RK コードをどのように処理するかを調べてみました。g95 が残したモジュール ファイルの長さは 44k でした。ascii 形式はバイナリ形式よりも効率が悪いと考えましたが、ディスクが安価であることを合理化しました。IBM xlf90 コンパイラーは、長さが 440k のモジュールを残しました。SGI f90 は、PGI と同様に内部エラーでクラッシュしました。Compaq fortran は 160k モジュールを残しました。公平を期すために言えば、g95 は必要なものすべて、特にインターフェースを書いているわけではありません。一方で、モジュールが 4 倍以上拡大する様子は見られないため、g95 モジュールはスペースを効率的に使用できるように見えます。そして、それらは多くの問題なしに小さくすることができました.
バイナリも更新しました。
「リンク」セクションに、Rob Cermak の g95 リグレッション結果ページへのリンクを追加しました。これにより、私や他のユーザーがページを見つけやすくなります。Rob はメーリング リストにアップデートを投稿しました。これは繰り返す価値があります。
追加:
Ben Turner は、スイートに含めるコードを送信するのに忙しくしています。
変更点:
* Andy は、どのコードにフラグを立てる必要があるかについてコメントを送信しています
「失敗するはず」または完全に削除されます（後日フラグが立てられます）。
* テストを行う順序は重要です。一部のファイルには
サポートする .mod ファイルを探す前に、一部のコードがビルドされます。
IE: Makefile がこれらをビルドする順序でビルドします。
もの。これは整理するのに時間がかかります。
次のようなことを試して修正してください。
“致命的なエラー: モジュール ファイル ‘best_rational.mod’ を開けません
読み取り: そのようなファイルまたはディレクトリはありません”
*コアファイルの検出といくつかの些細なものの取得を修正
デバッガー (gdb)。5 (任意) に設定された test_suite のエラー コード。
参照: http://gwynedd.rutgers.edu/g95/reports/2000/11/01/g95.html
* 進行中: 追加の概要/ナビゲーション ページ
* 回避するための fork()/watchdog のことを考えてください
無限の解析ループとその他の可能性があるもの
現れる。
11月1日
モジュール読み取りのバグをいくつか修正しました。G95 は単純なモジュールを読み取ることができるようになりました。
10月31日
Rob Cermak は、Ben Turner が数週間前の電子メールで言及されたすべての fortran 90 パッケージを追跡していることを私に知らせました。ありがとうベン！
昨日、Physical Review of 1955 に掲載された記事を読んでいました。その記事は、私の論文に関連する分子結合計算に関するものでした。驚いたことに、計算に使用した IBM 701 のプログラミングを支援してくれた IBM の “J. Backus” に著者が感謝しています。これは、彼が最初の fortran コンパイラの作成に実際に関与した時期でしたが、fortran の歴史に関する私の情報源によると、それは 704 で実行されました…
g95 に関する限り、モジュールを読み取るサブルーチンはパーサーによって呼び出され、読み取り時にデバッグが開始されます。
10月30日
Tobi Schlüter さんは、モジュールのサブルーチンが現在のディレクトリ以外のディレクトリにあるファイルを操作できるようにするパッチを送信しました。
また、Rob Cermak の自動回帰結果も調べました。彼は毎晩チェックされる非常に多くの Fortran 90 プログラムを追加しました。
モジュールを読み取るために必要な残りのコードのほとんどを追加しました。コンパイルはできますが、まだまったくテストされていません。
10月29日
その日の前半は、g95_array_spec 構造体をシンボルとコンポーネント構造体から解きほぐすことに費やしました。現在、これらの構造体は g95_array_spec 構造体を含むのではなく、それを指しています。
モジュールに関する作業が増えました。多くの変更がチェックインされました。単純なモジュール (変数のみ) が正しく記述されるようになりました。
10月28日
今日は変更点が多い。モジュール書き込みサブルーチンは、モジュールが解析された後、最上位から呼び出されるようになりました。ただし、2 つの実数からなる単純なモジュールはまだうまく機能しません。明日、うまくいく可能性が高いときに、物事を確認してみます…
10月26日
今日はコードはありませんが、正しく機能するようにシンボル テーブルをどのように構成する必要があるかについて多くのことを考えました。ファイル ‘modules’ が doc サブディレクトリにチェックインされました。私が J3 で会った Digital の Stan Whitlock は、ある時点で、モジュールの実装を 3 回書き直さなければならないと言いました。理由がわかります…
10月25日
モジュールの最上位の読み取りおよび書き込みサブルーチンの作業を開始しました。何が起こらなければならないかについて、もう少し考える必要があることは明らかです。
今日、Michael Metcalf から約 0.5 メガのテスト ケースが郵送されてきました。私は彼の Fortran フォーラム マガジンに、次号に登場する無料の Fortran コンパイラの進化についての記事を書きました。
10月24日
モジュールを処理するための変更されたシンボル テーブル サブルーチン。また、先週 module.c に加えられたかなり大規模な変更もチェックインしました。Fortran 90/95 の F サブセットを解析するためのオプションも追加しました。
10月20日
GMP 整数と浮動小数点数の読み取りと書き込みが追加されました。コードはまだチェックインされていません。残りの低レベルの作業を完了する代わりに、最初に高レベルの作業を完了して (名前空間全体を保存するなど)、デバッグを開始できるようにします。
数日前、私はしばらくやりたかった計算を行う新しいプログラムの作業を開始しました。Fortran 77 では解決できないほど複雑です。この問題に取り組むには、構造と再帰が本当に必要なので、現在、fortran 90 で最初のプログラムを書いています。言語はその中でプログラムを書くことでした。コンパイラを書くことも悪い方法ではありません….
10月18日
モジュールの読み取りに関する詳細。イテレータ、コンストラクタリスト、各種定数の読み書きを追加。ここでやるべきことはまだたくさんあります。
10月16日
よし、戻る。今朝の私の「日課」で多くの問題が解決され、g95 のどんちゃん騒ぎが始まっているのを感じることができます。今夜はモジュールの作業に時間を費やしました。ロードして保存する必要があるデータ構造はたくさんあります。それらのほとんどは現在コード化されていますが、最悪の場合、シンボルノード自体が最後になり、赤黒ツリーに格納される方法にいくつかの変更が伴います.
まだ何もテスト (またはチェックイン) されていません。これは主 に、名前空間が保存されるときに、シンボル ノードの I/O が最初に発生するという事実によるものです。これらすべての異なるサブルーチンの相互リンクも、これを「オール オア ナッシング」のような命題にする傾向があります。
10月11日
たくさんのバグレポートを処分しました。g95_match_init_expr() を修正して、定数構造体と配列コンストラクターを認識できるようにしました。
10月8日
Tobi Schlüter は、g95 がファイルを検索するときに検索するディレクトリを指定する -I オプションを追加しました
. モジュールでより多くの作業を行い、最初のチェックインを行いました。コンパイルされますが、実際にはまだ何も呼び出されていません。
10月7日
今日はモジュールに取り組みました。まだチェックインしていません。Souceforge は scp 接続の受け入れに問題があるようです….
10月6日
Tobi Schlüter は、インターフェイス ブロックに共通ブロックが存在しないバグを修正しました。これが合法であると自分自身に納得させるのにしばらく時間がかかりましたが、私が知る限りでは. インターフェイス ブロック内の共通ブロックはどのような用途に使用されますか? Tobi は、Vikram bir Singh によって報告されたタイプミスも修正しました。
数日間怠けてから、モジュールを読み取るために必要なサブルーチンを開始しました。現在デバッグ情報の書き込みに関与しているいくつかのサブルーチンは、サブルーチンの書き込みのすぐ隣でサブルーチンの読み取りができるように、symbol.c から module.c に移動される可能性があります。
10月3日
ファイルの終わりのパーサーの処理を作り直しました。Michael Richmond は、少し前にエラーが生成されなかったときに、この領域の問題を指摘しました。解析サブルーチンは、予期しない EOF が呼び出し先によって検出されたかどうかを示すフラグを返すために使用され、この値をスタックに伝達する必要がありました。これで、longjmp() で問題が解決しました。予期しない EOF は、コンパイラに関する限り、ショーストッパーです。
10月1日
Rob Cermak は、彼の自動テスト スイートを開始しました。最初のいくつかの問題レポートを確認しました。テストのいくつかは正しくありませんでしたが、いくつかの問題も見つかりました。そのうちのいくつかは、関数表現に対する昨日の変更に関係していました。
少し前に Michael Richmond によって発見されたいくつかの問題を修正しました。
9月30日
関数とプロシージャがシンボル ノード内に格納される方法の変更が完了し、デバッグされました。うまくいけば、物事は「正しい」ことに少し近づいています。自宅で CVS を使用することに慣れてきました。
Michael Richmond はしばらく前に、型宣言内の SEQUENCE ステートメントが不適切にエラーとしてフラグ付けされたことを報告するメールを送信しました。PRIVATE プロパティにも誤ってフラグが立てられていたので、その時点で頭の中で物事を逆に考えただけだと思います。また、検出される競合の数が大幅に拡大されました。
Rob Cermak は、回帰テストのために g95 がエラーコードを返すように要求しました。コードは次のとおりです。
0: すべてうまくいった
1: 警告が発行されました (エラーなし)
2: エラーが発行されました
3: 致命的なエラー (ファイルが見つからない、メモリ不足など)
4: 内部エラー (非常に悪い)
彼はまた、g95 の実行の最後にエラーと警告の数を出力するためのパッチを送信しました。これは、-v スイッチが使用されている場合に特に役立ちます。
Bill Wendling は、テスト用のランダム Fortran プログラム ジェネレーターを提案し、Mark Dewing は即座に Python で実装しました。このプログラムは、ここ にあるテンプレート ファイルとともにここにあります。基本的な考え方は、一晩でテストできる多くの疑似ランダム fortran プログラムを生成するテンプレート ファイルから始めることです。
9月27日
シンボルのドキュメントが完成しました。リポジトリの doc/syms にあります。ドキュメントに準拠するようにソースを修正しました。最大の変更点は、関数とサブルーチンの表現方法です。コードはコンパイルされますが、おそらく動作しません。
9月25日
シンボル ドキュメントにさらに取り組み、すぐにプライム タイムの準備が整う予定です。シンボルについて持っていたいくつかの誤解を発見しました。たとえば、名前が定義済みの演算子である場合、それは同時に他のものになる可能性があります…最初にこれを正しく理解できればよかったのですが、最初はすべての問題に気づいていません。
別のニュースとして、FSF は Michael Richmond から著作権の譲渡を受けました…万歳！
9月24日
Michael Richmond は、ダミー プロシージャの問題に関するバグを送信しました。これは、私がこれを正しくしようと試みたのが 3 回目かそこらなので、明らかにもっと熟考する必要がありました。ダミーの手順 (対実際の手順) を表す問題により、g95_symbol 構造が手に負えなくなり始めていることがわかりました。したがって、私はこのかなり中心的な構造を説明する文書の作成に取り掛かりました。
9月23日
Sourceforge の CVS デポジトリを有効にして、現在のソースをそこにインポートしました。CVS アーカイブへの直接リンクは こちらです (メイン メニューも変更されています)。また、J3 Web サイトへの壊れたリンクを修正しました。
9月22日
夜のラスベガスへのドライブは楽しいものです。フェニックスはそれほど素晴らしい街ではありません。丘が多すぎて、実際に中に入る前にそのすべてを見ることができませんが、ラスベガスは違います。南東から近づくと、約 110 マイル離れたところに、間にある丘の上に輝きが見えます。ルクソールホテルのピラミディアンに内蔵されたサーチライトでラスベガスだとわかります。フーバーダムを越えた後、曲がりくねった道をぐるぐると下り、やがて峠に到着。峠を越えて小高い丘を登ると、いきなり全体がライトアップされ、広大な渓谷が広がります。
ホテルはストリップの近くにあり、その丘の上から簡単に見つけることができたので、ホテルを見つけるのは問題ありませんでした。登録するのに少し問題がありました。実際には聞いたことのない方法で私の名前を台無しにしてしまったからです。ホテルは素敵な場所でした–たくさんの部屋と、朝の無料の朝食。クロージング業務から、J3がそこでさらにいくつかの会議を行う予定であることを理解しています.
会議自体には、約 16 名の参加者がありました。メンバーの約 3 分の 1 は、Compaq、Sun、Intel、Cray、HP、NAG などのベンダーからのものでした。他のメンバーは、NASA、JPL、数人の大学関係者、その他の企業など、世界中から集まりました。
新しい言語仕様を作成するプロセスは、膨大で複雑な本を書くことになります。新しい機能が必要な人、または単に何かを片付けたい人は、シリアル番号が与えられ、その番号の下に書かれた「論文」を提案します。論文は、委員会全体に報告される前に、投票によって論文を可決しなければならないサブグループに送られます。前回の会議では、4 つのサブグループがありました。主要な f2k 言語の問題を扱う「データ」、C 言語との相互運用性を現在最終調整中の「相互運用」、Fortran 90 の穴を解釈する「interp」(解釈) です。 /95 を実行し、必要に応じて f2k をクリアしようとします。
論文が委員会を通過すると、著者は編集内容を最終決定し、1 日の終わりに印刷物をテーブルに置いて、翌朝の投票のために人々が読むことができるようにします。過酷なスケジュールです。一日中会って話し、夜の半分読み書き。強迫的な飲酒やギャンブルへの衝動を満足させることができなかった人々から、いくつかの苦情を聞きました.
委員会のほとんどはすでに g95 プロジェクトについて聞いていたので、私は彼らに現在の立ち位置を知らせました。彼らの何人かは私たちの幸運を祈っていました。g95 が内部でどのように機能するかについては、ほとんど話しませんでした。Sun の担当者は、私が以前に書いたコンパイラの数を尋ねました。私は「うーん、どれも、これは私の最初のものです」と言わなければなりませんでした。
また、Fortran 95 を十分に吸収して、何が起こっているかのほとんどを理解し、小さな方法で貢献し、人々がどこに立っているかを把握するために使用される拘束力のない投票であるいくつかの「ストロー投票」に参加することさえできます。問題 – それらは、ほとんどのことが全会一致で可決される主な理由です。
話し合いはとても友好的でした。他の多くの集まりとは異なり、そこにいた人々は喜んで説得されました。企業の代表者は、会社によって特定の方法で投票する必要がある場合があると説明されましたが、私の印象では、企業は主に、Fortran の最先端を定義するのではなく、最先端がどこにあるかを知るために代表者を求めているようです。私が知る限り、誰もがそこにいたかったので、f2k が可能な限り優れていることを確認することに関心がありました。
技術的な問題に関する限り、f2k は巨大な言語になりつつあります。人々は、f2k は f90/f95 に対して、f90 は f77 に対してであると言っていました。新しいものには、ポリモーフィズム、コンストラクター関数とデストラクタ関数、出力内容に応じて I/O 中に呼び出されるユーザー定義可能なデータ転送関数、ストリーム I/O (レコードなし)、および C との相互運用性が含まれます。その特定の会議では議論されませんでした。しかし、ここにはたくさんのものがあります。
カンファレンスから得たもう 1 つのことは、fortran の特異な性質についての理解が深まったことです。たとえば、C では、次のような予期しないことを行うことができます。
*strchr(文字列, “x”) = ‘\0′;
strchr() は完全に適切な文字ポインタを返し、’*’ で逆参照できるからです。Fortran では、式
(/ 1, 2, 3, 4 /)
は配列定数ですが、次のような記述はできません
i = 1、4を行います
print *, (/ 1, 2, 3, 4 /)(i)
遠藤
添え字は、古い配列式ではなく、名前付き変数の後にのみ許可されるためです。そして、同様に奇妙な制限がたくさんあります。何が起こったかというと、標準化される前の C の進化とは異なり、この言語には多くのことが徐々に定着していったということです。
私は本当に楽しい時間を過ごしました。できるときに戻ってきます。
