Rebol 3 のさまざまなブランチ、特に新しい REN ブランチとの違いは何ですか?
それらが実行されるプラットフォーム、機能セット、コード構成、C 標準への準拠ですか?
1504 次
1 に答える
13
これは時代遅れになる運命にある回答であるため、Community Wikiに設定されています。この情報は2015 年 9 月現在のものです。したがって、しばらくしてからこの回答を更新する場合は、日付も変更してください。
rebol.com からの Rebol3 のバイナリ ダウンロード
最後のビルドは 2011 年 3 月 5 日で、オープン ソース リリースより前の日付です。
GUI サポートなし、HTTPS サポートなし、シリアル ポート サポートなし、UDP サポートなし、スマート コンソールなし...
64 ビット ビルドはありません。バイナリは、Windows x86、OS/X (PPC または x86)、Linux (x86 または PPC)、FreeBSD x86 用です。
Rebol2 バイナリは多くの「難解な」システム (BeOS、AIX、Windows DEC Alpha、QNX、Solaris など)用にアーカイブされていますが、Rebol3 用の同様のバイナリは提供されていません。唯一の「奇妙な」ビルドは Amiga 用で、OS4 PowerPC Amiga のみです。Amiga エミュレーター用の Rebol3 の成功したビルドは報告されていません。
Github rebol/rebol での Rebol3 のオープン ソース リリース
オープンソース化は 2012 年 12 月 12 日でした。
rebol.com バイナリ ダウンロードは、このリリースの一部として再構築されませんでした。ただし、コミュニティ メンバー (SO の @earl)は、rebolsource.net でビルド ファームを作成し、この GitHub マスターが更新されるたびにそれに従います。GitHub の rebol/rebol master が 2014 年 3 月以降更新されていないことを考えると、このダイナミズムは現在十分に活用されていません。
リリース時にソースをビルドすると、2011 年 3 月 5 日のビルドと機能的に区別できない (?) 実行可能ファイルが得られました。これは、公開の準備のためのいくつかのクリーンアップと Apache ライセンスの編集以外に、ソースにほとんど変更が加えられていないことを示唆しています。
マイナー パッチとバグ修正は散発的に統合され、ほとんどの PR は放置されていました。執筆時点で受け入れられた最後の PR は2014 年 3 月 3 日で、これは 1 年以上前のことです。
承認された中で最も顕著な「破壊的」な PR は、FUNCTION 名を転用したことです。古いアリティ 3 形式を壊して、ローカル収集 FUNCT としてのはるかに有用な実装 と見なされるようにすることは価値があると考えられていました。(これにより、RebolはFUNCTION がアリティ 2 であり、同様に動作するRed と一致するようになりました。) FUNCT は、レガシー コードのためにそのまま保持されました。
採用された最も重要な非破壊的なPR は、おそらくIF、UNLESS、または EITHER ボディの周りにブロックを必要としないことです。これは、この言語の自由形式と非ボイラープレートの哲学に適合するものとして、そこにあることを知っている人々の間で好評を博しています。これにより、一部のコード構成が「よりきれい」になり、プログラマーにより多くの選択肢が与えられますが、他の何よりも問題が発生することはないようです。それは確かに よりもスピードバンプでは
if [condition] [...]ありません。実際、この機能が追加されたことを知っている人はほとんどいないようです。 (誰かが Red に耳を傾けて、IF と IF/ONLY を取得できることを確認できる場合、それが理想的です。)RETURN/REDO が削除されました。理論的根拠は、関数が可変アリティで効果的に動作することを許可し、これは不要であり、仕様から関数のアリティを予測できなくなったため、大地を奪ったというものでした。Lispスタイルのマクロを追加するように圧力をかけているLispユーザーは、それについてあまり心配していないように見えるので、おそらくこのスタンスは再検討する必要があります. (ここ StackExchange の世界では、これは Programmers.SE の質問を引き起こしました。Rebol (または Red) は Lisp スタイルのマクロの恩恵を受けますか?、まだあまり回答を得ていません。)
サフィリオンのフォーク：「サフィール」
Rebol のオープンソース化に先立ち、Saphirion AGは Rebol テクノロジーと特別な関係を築いていました。彼らはソースにアクセスでき、Rebol3 GUI 機能の開発作業のほとんどを担当していました。また、HTTPS などの他の機能もいくつか追加しました。
Saphir はWeb サイトからバイナリ ダウンロードとして入手できますが、32 ビット Windows でのみ提供されます。かつて、Saphirion から Android 用の実験的な .APKがありました。
Saphir のソースの一部 (すべてではない) は、オープンソース化後にリリースされました。注目すべき省略は、アンドロイド ビルドと、再コンパイルする必要なく、圧縮されたスクリプトとリソースをインタープリターのバイナリに挿入する方法をカプセル化するための Rebol3 コードでした。
(注: Apache2 ライセンスの下では、自分の派生作品のソース コードをリリースする必要はありません。)
GitHub の Rebolsource での「コミュニティ」統合
GitHub rebol/rebol の統合が滞っているため、rebolsource/r3 でフォークが確立され、作業をステージングできる「コミュニティ ビルド」になりました。
Rebolsource の変更は保守的であり、リポジトリがコミュニティに委譲された場合に、GitHub の rebol/rebol が「Rebol が考案された精神で」変更を採用する方法を示すことを目的としているようです。 (その精神については、こちらを参照してください。) したがって、HTTPS を実装するための大規模なサードパーティの暗号化ライブラリの代わりに、議論の余地のないバグ修正と微調整が統合されました。また、Cコンパイラ以外にビルド依存関係を追加することは許可されていません（たとえば、GNU autotoolsはありません）。
コミュニティ ビルドのバイナリは、自分でビルドできない人のために必要に応じて作成されました。
Github zsx/r3 の Atronix Engineering の Rebol "3.0"
Atronixは、Rebol を使用する産業オートメーション ソリューション プロバイダーです。その方法については、エンジニアリング ディレクターの David den Haringによるビデオで説明されています。彼らのZOE ソフトウェアは、Rebol のバージョンに基づいて構築されています。
オープンソースの後、Atronix は Saphirion と提携して GUI を Linux に移植しました。Atronix は、ソースが開発されたときに公開しています。David den Haring は、上のビデオで、開発した独自のコンポーネント (産業用制御ドライバー) が 1 つしかないことを指摘しています。それ以外は、彼らが行っているすべての Rebol 開発のソースを喜んで共有しています。
Atronix は、Rebolsource からの 64 ビット パッチを統合し、Windows 64 ビット ターゲットを作成し、Windows および Linux x86/x64、Linux ARMv7 向けの開発ブランチの最新バイナリを提供しています。
Atronix ビルドでは、Saphir の機能に加えて、/INPUT、/OUTPUT、/ERROR を使用したCALLのサポートが追加されました。また、LIBRARY!、ROUTINE! を実装する外部関数インターフェイスも追加されました。そしてSTRUCT！非 Rebol 動的ライブラリと通信するため。Windows と Linux でのカプセル化のサポートももたらします。
Rebol の「宗教」は都合の良いものと相いれないことがあったため、Rebol ベースのビルド プロセスは必要に応じて手作業で編集された makefile と Visual Studio プロジェクトに置き換えられました。FFI ライブラリは、ビルドする GNU autotools への依存を導入しました。
すべての Atronix ビルドには GUI が含まれているため、「コア」ビルドはありません。繰り返しますが、Linux と Windows のみです。
レンC
(偏見メモ: このフォークは@HostileForkが開始したイニシアチブであり、最もよく知っており、最も熱心に話します。)
Ren-C は、Atronix のコードベースから Core ビルドを抽出したものとして始まりました。これにより、HTTPS、拡張 CALL、Foreign Function Interface などの機能が、Rebolsource が構築できる基本的にすべてのプラットフォームに提供されました。 2015 年 7 月/9 月の更新Ren/C は、コンソールでの行継続、ユーザー インフィックス関数、いくつかのバグ修正をサポートしています...
Ren-C は、R3-Alpha で大規模な変更を行い、基本的な問題を修正します。これは、より多くの情報を提供する Trello で追跡されます。GitHub wiki として新しいFAQがあります。定義的にスコープされた返品などの重要な問題は解決されており、他の未解決の問題に継続的に取り組んでいます。
Atronix の R3/View にはいくつかの追加の依存関係が必要でしたが、Ren/C は C コンパイラ以外でビルドできるようにし、すべての手作りの makefile/projects を排除しました。
32 ビット版と 64 ビット版の両方の Windows、Linux、Mac を超えて、Ren/C はHaikuOSやSyllableなどの小規模プレイヤー向けにも構築されています。これは、C89 コードのターンキー ビルドが (単に として) どのように広範に機能するかを示す
make -f makefile.bootのに、これらの特定の OS の特に大きなユーザーベースが存在するのとは対照的に、より興味深いものです!言語の厳密さの観点から、Ren/C は最新の技術を推し進めています。C89 としてもビルドできますが、C99 および C11 としてもビルドできます。また、C++98 から C++14 としてビルドすることも検証されており、いくつかの戦略的な変更により
#ifdef __cplusplus、C コードよりも一種の静的分析ツールとして最新の C++ を利用できます。警告が発生し、タイプエラーがすべて修正され、「const correct」です。必要な変更は、Rebol のベースライン C コードをより正確にするだけでなく、全体的によりクリーンで明確なソースにするために慎重に検討されました。C 開発者の観点からは、Ren/C は、C を知っている人なら誰でも「自信を持って変更」し、新しい機能を試すことができるように、安定しており、組織化され、十分にコメントされている必要があります。つまり、定義的にスコープされた return (実際には書かれているがプッシュされていない) を実装したり 、NewPathのような機能を開発したりできることを意味します。
アーキテクチャの観点から、Ren/C は実行可能ファイルをまったく持たないことを意図しています... しかし、Rebol インタープリターを他のプログラムに埋め込むためのライブラリーとなることを意図しています。これは、Red との連携も想定して設計された Ren/C++ の基礎となっています。
テストの観点から、Ren/C はエンジニアリングの厳密さとゼロ バグ トレランスのためにすべてを形にするつもりです。これは、 Address Sanitizer、Valgrind、および両方で最高の設定を渡すことができるテストスイートを使用して、メモリをゼロで埋めて初期化されていないメモリアクセスを隠すなどの慣行を回避することを意味します。
すべての追加機能を有効にすることで、Ren/C の実行可能ファイルのサイズは Rebolsource のほぼ 2 倍になりましたが、これをどのように削除できるかを確認するための監査はまだ行われていません。Zlib と PNG のエンコード/デコードの重複したコピーがあることが確認されています。前のコード) . また、使用したいコーデックのみを選択的に統合するビルドを実行できるようにすることも議題です。
Ren/C は現在、Atronix と Rebolsource の利害関係者がその開発と方向性に参加しており、「Rebol Core」に進化する可能性が高まっています。現在、Ren Gardenをサポートするコードとしてリンクされており、同様のアプローチを使用して、Atronix の R3/View、次に Rebolsource、そしておそらく最終的には rebol/rebol 自体で使用されるライブラリとしてセットアップされる可能性があります。
Oldesのフォーク
(バイアス注: この編集は、2019 年 2 月 28 日に Oldes 自身によって追加されました)
コミュニティブランチからフォークされました。Atronix/Saphirion からやみくもにすべてを取得することなく、元の Carl のリリースに近いコードを維持することに重点を置いていますが、これらのブランチからゆっくりと良いものを拾い上げようとしています。
Ren-Cとは異なり、このバージョンは新しい構文を導入しようとしているのではなく、元の Rebol2 と新しいRed 言語に近づけようとしています。
于 2015-07-20T13:13:57.580 に答える