2026/02/28 9:12

「Fortran は fpm をコンパイルします。」

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

要約

LFortran は現在、Fortran パッケージマネージャ（fpm）をコンパイルできるようになり、ベータリリースに向けた重要なマイルストーンを達成しました。2025年4月に開かれ、2026年2月7日にクローズされた課題の後、Clang の C++ モデル（Fortran 固有拡張付き）からインスパイアされた fpm のクラス階層の包括的リファクタリングが行われ、コンパイル中に露出したすべてのバグと欠落機能を修正しました。プロジェクトの CI パイプラインは現在、各コミットで fpm テストスイート全体を実行し、フラッキーな問題を早期に検出します；進捗バーは 9 / 10 に達しており、中規模コード（≈500–1,000 行）で約 90 % の正しいコンパイル／実行性能に相当します。

fpm は、M_CLI2（CLI パース）、toml-f（TOML 設定）、fortran-regex、fortran-shlex、および Jonquil の 5 つの主要ライブラリに依存し、全体を通じてモダンな Fortran 機能を使用しています。ランタイム境界チェックはデフォルトで有効になっており、最近の upstream PR が関連バグを修正しました。

ローカルで fpm を構築するには：

git clone https://github.com/fortran-lang/fpm

cd fpm && git checkout d0f89957541bdcc354da8e11422f5efcf9fedd0e

```
lfortran 0.60.0
```
と
```
gfortran
```
を含む Conda 環境を作成。
```
fpm --compiler=lfortran test …
```
を実行。

Apple M4 MacBook Pro でのコンパイルは、LFortran 使用時に約 16 秒（gfortran 時は約 42 秒）かかります。タイムレポートではビルド時間の約 75 % が LLVM IR をオブジェクトコードへ変換する処理に費やされており、カスタムバックエンドを使用すればこの速度を十倍に向上させる可能性があります。

今後の作業： 中規模コードへの対応を通じてベータ版を完全に達成します。残っているギャップは共配列サポートとパラメトリック派生型（PDT）です。

本文

LFortran が fpm ― Fortran パッケージマネージャー ― をコンパイルできるようになりました

2025 年 4 月に問題を立ち上げ、2026 年 2 月 7 日にクローズしました。
fpm は私たちが構築し成功裏に動かした中で最も複雑なプロジェクトです。
システムレベルのツールとして他のプログラムを実行し、環境変数を読み取り、コマンドライン引数を解析し、ファイルやディレクトリの入出力、依存関係を理解するために十分な Fortran をパースします。
LFortran はほぼすべての最新 Fortran 機能（クラス、継承、allocatable コンポーネント、コンストラクタ、クラス配列、

SELECT TYPE

、

ASSOCIATE

、左辺自動再割り当て、文字列・文字列配列など）を使用しています。
fpm を構築する過程で LFortran の数十のバグや機能不足が露呈し、それらすべてを実装しました。

その結果、LFortran はベータに近い状態（進捗バーは現在 9/10）です。
私たちにとって「ベータ品質」とは、N 行（例：N = 10 000）のコードが約 90% の確率でコンパイルできることを意味します。実際には N = 500 または N = 1 000 で達成していますが、大規模なコードではまだです。

ここまで来た経緯

クラス、仮想関数・継承のリファクタリング
Clang が C++ クラスを扱う手法に触発され、Fortran 固有の拡張を加えて同様のアプローチを実装しました。
CI テスト
コミットごとに fpm のすべてのテストがコンパイル・実行される継続的インテグレーションを構築。多くの PR を通じて CI が合格すると安定していると判断できます（ただし隠れたバグは残っている可能性があります）。
fpm の 5 つ主要依存ライブラリへの対応
- ```
M_CLI2
```
  ― コマンドライン引数解析
- ```
toml-f
```
  ― TOML 設定ファイルの読み込み
- ```
fortran-regex
```
  ― パターンマッチング
- ```
fortran-shlex
```
  ― シェルライク構文処理
- ```
Jonquil
```
  ― JSON データ管理

ビルド手順

git clone https://github.com/fortran-lang/fpm
cd fpm
git checkout d0f89957541bdcc354da8e11422f5efcf9fedd0e   # latest main

conda create -n fpm lfortran=0.60.0 fpm gfortran
conda activate fpm

# LFortran をコンパイラとしてテストを実行
fpm --compiler=lfortran test \
    --flag --cpp \
    --flag --realloc-lhs-arrays \
    --flag --use-loop-variable-after-loop

--fast

や

--separate-compilation

オプションも併用可能です。

注記: gfortran コンパイラはテスト時にのみ必要で、ソースコードのビルドには使用されません。
将来的にはテストから gfortran をハードコーディングせずに改善する予定です。

実行時動作

LFortran はデフォルトで境界チェックを有効にしており、誤った形状や未割り当て配列の使用でランタイムエラーが発生します。これにより実際の upstream バグが判明し PR で修正されました。コンパイル時と実行時のチェックを強化し、コードは「動く」か「明確なエラーで失敗する」のどちらかになるよう努めます。

コンパイル速度

Apple M4 MacBook Pro

$ time fpm build --compiler=gfortran
[...]
real    42.342s   user    39.902s   sys     2.050s

$ time fpm --compiler=lfortran build \
      --flag --cpp \
      --flag --realloc-lhs-arrays \
      --flag --use-loop-variable-after-loop
[...]
real    16.641s   user    15.533s   sys     0.968s

コンパイラバージョン

$ gfortran --version
GNU Fortran (conda-forge gcc 15.2.0-18) 15.2.0

$ lfortran --version
LFortran version: 0.60.0
Platform: macOS ARM
LLVM: 19.1.1
Default target: arm64-apple-darwin24.6.0

単一コンパイルのプロファイリング

--verbose

を付けて最長コマンドを手動で実行します。

lfortran -c app/main.f90 \
    --cpp --cpp --realloc-lhs-arrays --use-loop-variable-after-loop \
    -DFPM_RELEASE_VERSION=0.12.0 \
    -Ibuild/dependencies/fortran-regex/src \
    -J build/lfortran_29F2E0FA2D75FE0A \
    -Ibuild/lfortran_29F2E0FA2D75FE0A \
    -Ibuild/lfortran_5D5DD1C987059777 \
    -o build/lfortran_29F2E0FA2D75FE0A/fpm/app_main.f90.o \
    --time-report

出力（抜粋）

Allocator usage of last chunk (MB)                     0.284
Allocator chunks                                       7.000
------------------------------------------------------------
Component name                                     Time (ms)
------------------------------------------------------------
File reading                                           0.450
Src -> ASR                                            93.267
ASR passes (total)                                   178.630
    ...
LLVM IR creation                                     329.712
LLVM opt                                               0.000
LLVM -> BIN                                        12539.240
...
Total time                                         13204.171

ASR
= Abstract Semantic Representation、LFortran が主に使用する IR です。

完全ビルドの内訳

タスク	時間 [s]	割合
全ファイルを一つの ASR にコンパイル	3.5	21.1 %
ASR → ASR パス	0.2	1.2 %
ASR → LLVM IR	0.3	1.8 %
LLVM IR → オブジェクトファイル	12.5	75.3 %
リンキング	0.1	0.6 %
合計	16.6	100 %

主なボトルネックは LLVM IR をバイナリオブジェクトにコンパイルする処理（総時間の約 ¾）です。独自バックエンドを実装すれば ~10 倍高速化でき、全体ビルド時間を ~5 秒に短縮できると見込んでいます。

今後の展望

現在はアルファ段階です。LFortran が中規模コードを高確率でコンパイルできることに自信が持てたらベータ品質を発表します。
coarray と parametrized derived type（PDT）は未実装ですが、ベータ後に取り組む予定です。スケジュールは不透明ですが、数か月以内に進める見込みです。

新しいサードパーティコードがコンパイル可能になるたびに発表を続けます。

参加しよう

新人貢献者大歓迎！興味があれば Zulip で連絡してください。
LFortran の開発は挑戦的でやりがいがあります。学習機会も豊富です。

謝辞

以下のサポーターに感謝します：

Sovereign Tech Fund (STF)
NumFOCUS
QuantStack
Google Summer of Code
FLOSS/fund
John D. Cook
LANL
GSI Technology

GitHub、OpenCollective、NumFOCUS のスポンサーも含め、現在 131 名の貢献者がいます！

議論

Fortran Discourse: https://fortran-lang.discourse.group/t/lfortran-compiles-fpm/10744
X (旧 Twitter): https://x.com/lfortranorg/status/2026706098426884401

同じ日のほかのニュース

一覧に戻る →

2026/03/03 7:32

メタ社のスマートグラスの裏側にいる作業員は、全てを見渡すことができます。

## Japanese Translation: > Metaの新しい「Meta Ray‑Ban」メガネは、仕事・旅行・リアルタイム翻訳・プライバシー制御を一つのAIアシスタントとして位置付けられています。EssilorLuxotticaと共同で製造され、スウェーデンで販売される予定で、2023‑24年に200万台から2025年秋には700万台へと売上が急増する見込みです。このデバイスはサーバー側で処理を行う必要があり、ローカルでの対話は不可能です。アプリは電話にインターネット接続がなくても、常にMetaサーバーにアクセスします。 > Metaのプライバシーポリシーでは、ユーザーが明示的にオプトインしない限り、音声・テキスト・画像・動画を自動的に取得することが許可されています。すべてのコンテンツはAIによって自動または手動でレビューされる可能性があり、オプトアウトの選択肢はありません。プライバシー専門家は、ユーザーがしばしばメガネのカメラがAIアシスタントに話しかけた際に録画していることを認識していない点を指摘し、透明性の欠如を強調しています。 > データ注釈作業はサブコントラクター（例：ナイロビのSama）に委託されており、従業員は極めてプライベートな資料（例：トイレ訪問、セックスシーン、銀行カード情報など）をレビューすることがあります。匿名化は不完全であり、照明が悪い場合には顔が見えてしまう可能性があります。Metaの利用規約では保存場所や詳細な取り扱いについて具体的に示されておらず、ヨーロッパの幹部はGDPR準拠がサーバー所在地よりもデータ保護基準に依存していると指摘し、法的責任はMeta Irelandに帰属すると述べています。 > スウェーデンのプライバシー保護機関はまだ製品をレビューしていないため、ユーザーが自分のデータがAIモデルのトレーニングや広告ターゲティングにどのように使用されるかを十分に理解できていないという懸念があります。MetaはクラウドベースのAI処理を維持しつつメガネの販売を継続する計画であり、これがGDPR監視の強化につながり、企業や消費者がウェアラブルAIデバイスにおけるより明確なオプトインデータポリシーを要求する動きを促す可能性があります。

2026/03/03 6:09

Macintoshへようこそ（お帰りなさい）。

## Japanese Translation: --- ## Summary 著者は、最近の macOS リリース―特に不安定な「macOS Tahoe」―が継続的なバグと頻繁な UI 変更に悩まされており、システムの安定性やユーザー体験を侵食していると主張しています。主要な問題点は次の通りです： - **Time‑Machine バックアップ** は古いスナップショットが削除されない限り失敗します。 - **Spotlight** のタグインデックスは不完全な結果しか返さず、インデックスを再構築したり Finder を再起動しても部分的にしか解決しません。 - **Finder** は Spotlight クエリ中や検索結果の更新時にハングします。また、外部ファイルが作成された後にフォルダ内容を更新できず（*Go To Folder* やパスオートコンプリートといった回避策も限定的で、しばしば Finder の再起動が必要になります）。 - **AirPods Pro** は約 1 秒後に音声の不具合を起こし、ファームウェアや OS アップグレードでは問題は解決されません。 - **全画面ウィンドウ** は Cmd + Tab で切り替えるとフォーカスが失われ、キーボードショートカットが機能せず、ウィンドウをクリックするまで Safari のビデオコントロールに影響します。これらの問題は複数の macOS リリースおよび Mac モデル（著者自身の M1 Max 2021 を含む）で継続しており、Apple 自身のコンポーネントに起因することを示しています。著者は、アイコン変更やダークパターン UI の微調整といった Apple の迅速な美観修正が長期的信頼性を損ねる可能性があると警告しています。将来のアップデートでバグが対処されることは期待できるものの、安定性よりも視覚的洗練を優先することへの懸念があります。 **Rosetta 2 の段階的廃止** は ARM64 Linux コンテナサポートに依存している開発者にとってさらに悪影響を及ぼし、アプリケーションの互換性を脅かす恐れがあります。総じて、著者は Apple に対し、短期的な美観更新よりもソフトウェア安定性、謙虚さ、および長期的利用価値に再集中するよう訴えています

2026/03/03 5:30

ブリティッシュコロンビア州、時刻変更を廃止し一年中サマータイムを採用

## Japanese Translation: ### 改訂要約ブリティッシュコロンビア州は、2026年11月1日付で「太平洋時間（Pacific Time）」と呼ばれる夏時間を永久に採用し、それ以降の時刻変更をすべて終了します。デービッド・エビー首相は月曜日にこの決定を発表し、3月8日（最後の春先進調整）が最終的な移行となると述べました。この動きは、2019年の公衆意見調査で回答者の93％が健康・安全上の理由から永久夏時間を支持したことに続くものです。エビー氏は子供やペットの睡眠不足、二度の時刻変更による車両事故増加を強調しました。歴史的に、BC州は1918年以降に時刻を切り替えてきました（法務長官ニキ・シャルマ氏が指摘）。州政府は最終変更前に住民に8か月の調整期間を設け、カリフォルニア州、オレゴン州、ワシントン州といった米国隣接州にも同様の法案採択を促しています。東部BC地域（例：デイソンクリーク）はすでに年間を通じて山岳標準時を観測しているため除外されます。新制度下では、バンクーバーの永久夏時間で最も早い日の出は6月5:06 AM、最も遅い日は12月9:08 AMです。夕暮れは12月5:14 PMから6月9:22 PMまで変動します。この変更は生活品質の向上、事故リスクの低減、およびイエローナイフ州と同じ年間を通じて夏時間を採用することでBC州を調和させることを目的としています。