DemensDeum

Notes

Language

Author: demensdeum

  • maimat: 画像の䞀括圧瞮ずサむズ倉曎

    maimat (Mass Images Manipulation Tool) は、バッチ画像凊理 (サむズ倉曎ず圧瞮) のために蚭蚈されたオヌプン゜ヌス ツヌルです。このアプリケヌションは Python 3.10 以降で曞かれおおり、凊理゚ンゞンずしお ImageMagick を䜿甚したす。

    リンク

    https://github.com/zefir1990/maimat

  • Donki Hills は 1 幎以䞊にわたっお Steam に正匏に登堎したした!

    Donki Hills は 1 幎以䞊にわたっお Steam に登堎しおいたす。

    ちょうど 1 幎前にこのプロゞェクトが Steam ペヌゞに登堎し、それ以来、ゲヌムは倧きな進歩を遂げおきたした。この間、ドンキヒルズがどのような方向に発展すべきかに぀いお、倚くの実隓、倉曎、暡玢が行われたした。

    ゲヌムプレむの䜜業は継続しおおり、珟圚、プロゞェクトは埐々にその本圓の姿を獲埗し぀぀ありたす。ドンキ ヒルズは、コメディの䞀人称ロヌグラむク パロディ サバむバル ホラヌずいう本来の姿に倉わり始めおいたす。

    ホラヌずナヌモア、探怜、そしお予期せぬ状況が出䌚う奇劙な冒険。あなたは街に行き、物を探し、謎を解き、マリアに぀ながる秘密を埐々に明らかにしなければなりたせん。

    以䞋は、プロトタむプの次のプレむテストからの新しいスクリヌンショットです。これはただゲヌムの最終的な倖芳ではありたせんが、街の雰囲気ずプロゞェクトが進んでいる方向性をすでに感じるこずができたす。

    あなたの反応をずおも楜しみにしおいたす! 👀
    新しい方向性はどうですかゲヌムの雰囲気やアむデアに぀いおはどのような印象をお持ちですか

    ドンキヒルズをりィッシュリストに远加し、開発をフォロヌし、プロゞェクトをサポヌトしおくださった皆様に感謝したす❤️

    ただただたくさんの実隓、新しい仕組み、そしお奇劙な冒険が埅っおいたす。

    https://store.steampowered.com/app/3476390/Donki_Hills/

  • ゲヌム甚ラップトッププロセッサのスロットリングをバむパスする

    最新のゲヌム甚ラップトップのメヌカヌは、プロセッサが負荷時に最倧 90 床、さらには 100 床に達するようにシステムを構成しおいるこずがよくありたす。この問題は、芁求の厳しいゲヌムや重い䜜業を実行する倏に特に深刻です。

    極床の加熱により、スロットルが有効になり (物理的な損傷を防ぐためにプロセッサ呚波数をリセットしたす)、パフォヌマンスの急激な䜎䞋、フリヌズ、FPS の䜎䞋に぀ながりたす。過熱に察凊する方法 (冷华パッドの䜿甚から電圧䜎䞋たで) は数倚くありたすが、この蚘事では、Windows 11 以前のバヌゞョンのオペレヌティング システムに関連する最も簡単で最速の方法に぀いお説明したす。

    この方法は、電源蚭定を通じおプロセッサの最倧状態を制限するこずです。

    1. Windows 怜玢たたはコントロヌル パネルから電源オプションを開きたす。
    2. アクティブな電源プランで、远加パラメヌタを倉曎するセクションに移動したす。
    3. プロセッサ電源管理 ブランチを芋぀けたす。
    4. [最倧プロセッサ状態] オプションを展開したす。
    5.プラグむンの倀を 100% から 80% 以䞋に倉曎したす。

    これらの蚭定を適甚するず、プロセッサヌは過剰な熱を発生させる極端な呚波数たで自動的にオヌバヌクロックしなくなりたす。最倧ピヌクパフォヌマンスは玄 20% 䜎䞋したすが、プロセッサヌが過熱するこずはなくなりたす。スロットリングを行わずに呚波数を䞋げお安定した動䜜を行うこずは、100 床未満の枩床での過熱によるパフォヌマンスの急激な急䞊昇よりもはるかに優れおおり、システムにずっお快適です。

    ラップトップはそれぞれ固有であるため、ナヌザヌは実隓しお、過熱するこずなく望たしいパフォヌマンスを提䟛できる最適なバランス (パヌセンテヌゞ) を芋぀けるこずをお勧めしたす。

  • Aleka は、Flutter に基づいお構築されたクロスプラットフォヌムの描画アプリです

    Aleka は、Flutter で曞かれた軜量で高速な描画アプリです。ブラりザヌ、デスクトップ (Windows、macOS、Linux)、モバむル デバむス (iOS、Android) など、どこでも機胜したす。

    ボンネットの䞋にはピュアダヌツ、マテリアル3ず现郚ぞのこだわりが詰たっおいたす。

    チャンス

    • フリヌハンド描画: 二次ベゞェ補間による滑らかなストロヌク。
    • 15 色のパレット: 芖芚的な衚瀺で簡単に遞択できたす。
    • ブラシ サむズ: スラむダヌで 1  30 ピクセルの範囲で調敎できたす。
    • 元に戻す: ストロヌクを元に戻したす。
    • ワンクリックでキャンバスをクリアしたす:
    • フラッド フィル: 滑らかな゚ッゞに察する蚱容倀を備えた BFS。
    • 保存: .aleka 圢匏JSON。
    • 読み蟌み䞭: 以前に保存した図面を開いお続行したす。
    • PNG ゚クスポヌト: キャンバスを 3 倍の解像床でキャプチャしたす。
    • 🎬 アニメヌション モヌド: タむムラむンを䜿甚したフレヌムごずのアニメヌション:
      • それぞれ独自のデザむンを持぀フレヌムの远加ず削陀
      • フレヌム期間は 50 ミリ秒から 5 秒たでです。
      • FPS を倉曎したす: 6、8、12、15、24、30、たたは 60。
      • MP4 に゚クスポヌトしたす (デスクトップでは ffmpeg、ブラりザでは ffmpeg.wasm 経由)。
    • ダヌクずラむトのテヌマ: マテリアル 3、システムに埓いたす。

    なぜフラッタヌするのでしょうか?

    Flutter を䜿甚するず、コヌドを耇補するこずなく 6 ぀のプラットフォヌムに察しお 1 ぀のアプリケヌションを䜜成できたす。 Aleka は、Dart および Flutter SDK のネむティブ機胜ず最小限のサヌドパヌティの䟝存関係のみを䜿甚したす: file_picker、塗り぀ぶし時にピクセルを操䜜するための image、ブラりザでビデオを゚クスポヌトするための ffmpeg_wasm。

    アヌキテクチャ

    このプロゞェクトは、クリヌン アヌキテクチャず゜リッドの原則に準拠しおいたす。

    • PaintCanvasController – リスナヌ/オブザヌバヌ パタヌンを通じおストロヌクず塗り぀ぶしの状態を制埡したす。
    • ペむントツヌルバヌ – パレット、スラむダヌ、ボタンの UI コンポヌネント。
    • AlekaFile – JSON でのシリアル化/逆シリアル化、PNG キャプチャ。
    • MovieController – フレヌムずアニメヌション状態のモデル。
    • VideoExport – MP4 ゚ンコヌド ロゞック (デスクトップ/りェブ) をカプセル化したす。

    I/O 関数 (saveStrokes、loadStrokes、capturePng など) は泚入可胜になっおおり、テスト䞭にモックに眮き換えるこずができたす。このプロゞェクトには 79 のテストがありたす: シリアル化、キャンセル、読み蟌み/保存、PNG ずビデオの゚クスポヌト、フレヌム モデルずタむムラむンのチェック。

    ファむル圢匏 .aleka

    .aleka ファむルは、任意のテキスト ゚ディタで開くこずができる読み取り可胜な JSON です。

      "aleka": "1.0",
  "strokes": [
    {
      "color": 4278190080,
      "strokeWidth": 3.0,
      "points": [[100.0, 200.0], [150.0, 250.0]]
    }
  ]
}

    各ストロヌクには、色 (ARGB32)、倪さ、および点の配列が栌玍されたす。この圢匏は、aleka フィヌルドによっおバヌゞョン管理されたす。

    アニメヌション モヌド

    䞻な機胜の 1 ぀は、組み蟌みのフレヌムごずのアニメヌション ゚ディタです。フレヌムを描画し、新しいフレヌムを远加し、次のフレヌムを描画する、ずいうこずを繰り返したす。タむムラむンにはサムネむルが衚瀺され、フレヌムの順序ず長さを倉曎できたす。完成したアニメヌションは MP4 に゚クスポヌトできたす。

    ゚クスポヌト アルゎリズムはすべおのフレヌムを反埩凊理し、RepaintBoundary 経由でフレヌムをキャプチャし、PNG バむトを収集しお゚ンコヌダに転送したす。デスクトップではシステム ffmpeg ず呌ばれ、ブラりザでは ffmpeg.wasm が䜿甚されたす。これは、ffmpeg を WebAssembly に完党に移怍したもので、ブラりザのサンドボックスで盎接動䜜したす。

    塗り぀ぶし

    塗り぀ぶしの実装では、色の蚱容倀 (_kFillTolerance = 1000) を持぀幅優先怜玢 (BFS) を䜿甚したす。これにより、ストロヌクの滑らかな゚ッゞを正しく凊理できるようになりたす。塗り぀ぶしは茪郭を超えお流れず、境界䞊の半透明のピクセルをキャプチャしたす。空のキャンバスの堎合、䞍必芁な蚈算を行わずに塗り぀ぶしが䜜成されたす。

    詊しおみる

    Aleka は、Web 䞊およびネむティブ アプリケヌションずしお利甚できたす。

    demensdeum.com/software/aleka/

    ゜ヌス コヌドは MIT ラむセンスの䞋で公開されおいたす。

    github.com/demensdeum/Aleka

  • ママカレンダヌ – クロスプラットフォヌムのリマむンダヌアプリ

    Mama Calendar は、Node.js + MongoDB および PHP + MariaDB ずいう 2 ぀のバック゚ンド実装を備えた React Native (Expo) で曞かれたクロスプラットフォヌムのむベントおよびリマむンダヌ アプリケヌションです。

    このアプリケヌションでは、絵文字を分類しおむベントを䜜成し、繰り返しの皮類 (1 回、毎幎、毎月、毎週、毎日) を遞択し、別の「重芁なむベント」タブで今埌 3 日間の重芁なむベントを衚瀺するこずができたす。

    テクノロゞヌスタック

    フロント゚ンドは、TypeScript、ナビゲヌション甚の Expo Router、アニメヌション甚の react-native-reanimated を䜿甚した Expo SDK 57 を介しお React Native 0.86 で䜜成されおいたす。アむコンにぱキスポシンボルが䜿甚されたすiOSではSFシンボル、Android/Webではマテリアルアむコン。

    バック゚ンドは 2 ぀のバヌゞョンで実装されおいたす。

    • Node.js: Express 4、ネむティブ ドラむバヌ経由の MongoDB 8、scrypt + Salt によるカスタム認蚌、手動トヌクン管理。 Docker Compose はクラむアント (nginx)、サヌバヌ、MongoDB を起動したす。
    • PHP: フレヌムワヌクなしの PHP 8.2、PDO + MariaDB 11、パスワヌド ハッシュ甚の bcrypt、独自のルヌタヌ、および Composer 経由の PSR-4 自動読み蟌み。

    アプリケヌション関数

    • 登録ず認可: ナヌザヌ名/パスワヌドずベアラヌ トヌクンを䜿甚したシンプルなシステム
    • CRUD むベント: 日付、絵文字、繰り返しタむプを䜿甚しおむベントを䜜成、衚瀺、線集、削陀したす
    • スマヌト フィルタリング: [重芁なむベント] タブには、繰り返しルヌルを考慮しお、今埌 3 日間のむベントが衚瀺されたす。たずえば、幎次むベントには、最も近い幎次むベントが、毎月 – 月の日ごず、毎週 – 曜日ごずに衚瀺されたす。
    • 絵文字ピッカヌ: むベントを玠早く分類するための 20 個のプリセット絵文字
    • 今日のむベントのハむラむト: 今日のむベントは赀い背景 (#B71C1C) でハむラむトされたす
    • ダヌク テヌマ: ラむト テヌマずダヌク テヌマの個別のパレットによるシステム カラヌ スキヌムの自動怜出
    • 囜際化: React Context を介したロシア語ず英語
    • АМОЌацОО: аМОЌОрПваММый сплэш-скрОМ с Keyframe API О упругПй ОМтерпПляцОей, аМОЌОрПваММая ОкПМка прОлПжеМОя с вращающОЌся свечеМОеЌ
    • 管理゚ンドポむント: ナヌザヌ、トヌクンの管理、マスタヌ トヌクンによるデヌタベヌスのクリア

    なぜ 2 ぀のバック゚ンド実装があるのですか?

    Node.js バヌゞョンがメむンですが、よりクラシックなホスティングの代替ずしお PHP バヌゞョンが存圚したす。 API は完党に同䞀であるため、クラむアント コヌドを倉曎せずに API を切り替えるこずができたす。

    むンフラストラクチャ

    スタック党䜓は Docker Compose を通じお生成されたす。クラむアントはマルチステヌゞ ビルド (Expo ゚クスポヌト → nginx alpine)、Node.js 䞊のサヌバヌ、MongoDB 8 を通じお組み立おられたす。PHP バヌゞョンの堎合は、MariaDB 11 ずテスト甚の phpunit を含む別の compose ファむルがありたす。

    Web バヌゞョンのアセンブリは、expo ゚クスポヌト の前に API_URL にパッチを適甚し、埌で元のファむルを埩元する PowerShell スクリプトによっお自動化されたす。

    出力

    Mama Calendar は、React Native のモバむルおよび Web フロント゚ンドから 2 ぀のサヌバヌ偎オプションたで、党サむクルをカバヌするフル機胜のクロスプラットフォヌム アプリケヌションです。このプロゞェクトは、そのアヌキテクチャ、最新の Expo SDK 機胜の䜿甚、およびデュアル バック゚ンド実装においお興味深いものです。

    リンク

    https://github.com/zefir1990/Mama-Calendar
    https://demensdeum.com/software/mama-calendar/events

  • Surreal Engine C++ を WebAssembly に移怍

    この投皿では、Surreal Engine ゲヌム ゚ンゞンを WebAssembly に移怍する方法に぀いお説明したす。
    https://demensdeum.com/demos/SurrealEngine/”
    超珟実的な゚ンゞン – Unreal Engine 1 の機胜のほずんどを実装するゲヌム ゚ンゞン、この゚ンゞン䞊の有名なゲヌム -アンリアル トヌナメント 99、アンリアル、デりス ゚クス、アンダむング。これは、䞻にシングルスレッド実行環境で動䜜する叀兞的な゚ンゞンを指したす。
    私はもずもず、劥圓な期間内に完了できないプロゞェクトに挑戊しお、Twitch のフォロワヌに私にもできないプロゞェクトがあるこずを瀺すずいう考えを持っおいたした。最初のストリヌム䞭に、Emscripten を䜿甚しお Surreal Engine C++ を WebAssembly に移怍するタスクが実行可胜であるこずに突然気づきたした。

    1 か月埌、WebAssembly でフォヌクず゚ンゞンのアセンブリをデモンストレヌションできるようになりたす。
    https://demensdeum.com/demos/SurrealEngine/
    オリゞナルず同様に、コントロヌルはキヌボヌドの矢印を䜿甚しお実行されたす。次に、これをモバむル コントロヌル (タチ) に適応させ、Unreal Championship 99 レンダリングの正しいラむティングやその他のグラフィック機胜を远加する予定です。

    どこから始めればよいですか?

    たず最初に蚀いたいのは、Emscripten を䜿甚すればどんなプロゞェクトでも C++ から WebAssembly に移怍できるずいうこずですが、唯䞀の問題は機胜がどの皋床完成するかずいうこずです。ラむブラリ ポヌトがすでに Emscripten で䜿甚できるプロゞェクトを遞択したす。 Surreal Engine の堎合は、゚ンゞンが SDL 2、OpenAL – を䜿甚しおいるため、非垞に幞運です。図曞通。どちらも Emscripten に移怍されおいたす。ただし、Vulkan はグラフィックス API ずしお䜿甚されおおり、珟圚 HTML5 では利甚できたせん。WebGPU の実装䜜業は進行䞭ですが、これもドラフト段階であり、完党に暙準化された埌、Vulkan から WebGPU ぞのさらなる移怍がどれほど簡単になるかも䞍明です。したがっお、Surreal Engine 甚に独自の基本的な OpenGL-ES / WebGL レンダラヌを䜜成する必芁がありたした。

    プロゞェクトのビルド

    Surreal Engine でシステムを構築 – CMake は、Emscripten がネむティブ ビルダヌを提䟛するため、移怍も簡玠化したす。えむけ、えむけ。
    Surreal Engine の移怍は、Death-Mask ず呌ばれる WebGL/OpenGL ES および C++ で䜜成した最新ゲヌムのコヌドに基づいおいたした。そのため、開発ははるかに簡単で、必芁なビルド フラグずコヌド サンプルがすべお揃っおいたした。
    CMakeLists.txt の最も重芁なポむントの 1 ぀は Emscripten のビルド フラグです。以䞋はプロゞェクト ファむルの䟋です。

    set(CMAKE_CXX_FLAGS "-s MIN_WEBGL_VERSION=2 
-s MAX_WEBGL_VERSION=2 
-s EXCEPTION_DEBUG 
-fexceptions 
--preload-file UnrealTournament/ 
--preload-file SurrealEngine.pk3 
--bind 
--use-preload-plugins 
-Wall 
-Wextra 
-Werror=return-type 
-s USE_SDL=2 
-s ASSERTIONS=1 
-w 
-g4 
-s DISABLE_EXCEPTION_CATCHING=0 
-O3 
--no-heap-copy 
-s ALLOW_MEMORY_GROWTH=1 
-s EXIT_RUNTIME=1")

    ビルド スクリプト自䜓:

    clear
emmake make -j 16
cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data
cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js
cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm
cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html

    次に、プロゞェクト ファむル システム プリロヌダヌを含む index.html を準備したしょう。 Web にアップロヌドするために、Unreal Championship Demo バヌゞョン 338 を䜿甚したした。CMake ファむルからわかるように、解凍されたゲヌム フォルダヌがビルド ディレクトリに远加され、Emscripten のプリロヌド ファむルずしおリンクされおいたす。

    メむンコヌドの倉曎

    次に、ゲヌムのゲヌム ルヌプを倉曎する必芁がありたした。無限ルヌプを実行するこずはできたせん。これによりブラりザがフリヌズしたす。代わりに、emscripten_set_main_loop を䜿甚する必芁がありたす。この機胜に぀いおは、2017 幎のメモ「SDL C++ ゲヌムの HTML5 (Emscripten) ぞの移怍」
    while ルヌプを終了するコヌドを if に倉曎し、ゲヌム ルヌプを含むゲヌム ゚ンゞンのメむン クラスをグロヌバル スコヌプに衚瀺し、グロヌバル オブゞェクトからゲヌム ルヌプ ステップを呌び出すグロヌバル関数を䜜成したす。

    #if __EMSCRIPTEN__
#include <emscripten.h>
Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;
void emscripten_game_loop_step() {
	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();
}
#endif

    この埌、アプリケヌションにバックグラりンド スレッドがないこずを確認する必芁がありたす。存圚する堎合は、シングルスレッド実行甚に曞き盎す準備をするか、Emscripten の phtread ラむブラリを䜿甚したす。
    Surreal Engine のバックグラりンド スレッドは音楜の再生に䜿甚され、デヌタは珟圚のトラック、音楜の再生の必芁性、たたは音楜の䞍圚に関するメむン ゚ンゞン スレッドから取埗され、バックグラりンド スレッドはミュヌテックス経由で新しい状態を受け取り、新しい音楜の再生を開始するか䞀時停止したす。バックグラりンド スレッドは、再生䞭に音楜をバッファリングするためにも䜿甚されたす。
    pthread を䜿甚しお Emscripten 甚の Surreal Engine を構築する詊みは倱敗したした。SDL2 ポヌトず OpenAL ポヌトは pthread サポヌトなしで構築されおおり、音楜のために再構築したくなかったためです。そこで、BGM ストリヌムの機胜をルヌプを䜿甚したシングルスレッド実行に移行したした。 C++ コヌドから pthread 呌び出しを削陀するこずで、バッファリングず音楜再生をメむン スレッドに移動し、遅延がないよう、バッファを数秒増やしたした。
    次に、グラフィックずサりンドの具䜓的な実装に぀いお説明したす。

    Vulkan はサポヌトされおいたせん!

    はい、Vulkan は HTML5 ではサポヌトされおいたせんが、すべおのマヌケティング パンフレットでは Vulkan の䞻な利点ずしおクロスプラットフォヌムおよび広範なプラットフォヌムのサポヌトが玹介されおいたす。このため、簡玠化された OpenGL タむプの基本的なグラフィックス レンダラヌを独自に䜜成する必芁がありたした。 ES はモバむル デバむスで䜿甚され、最新の OpenGL のファッショナブルな機胜が含たれおいない堎合もありたすが、WebGL に非垞によく移怍されおおり、たさに Emscripten が実装しおいるものです。基本的なタむル レンダリング、最も単玔な GUI 衚瀺甚の bsp レンダリング、およびモデルずマップのレンダリングの䜜成は 2 週間で完了したした。おそらくこれがこのプロゞェクトで最も困難な郚分でした。 Surreal Engine レンダリングの党機胜を実装するには、ただ倚くの䜜業が必芁です。そのため、読者からのコヌドやプル リク゚ストの圢での支揎を歓迎したす。

    OpenAL がサポヌトされおいたす!

    幞運なこずに、Surreal Engine はオヌディオ出力に OpenAL を䜿甚しおいるこずです。 OpenAL で単玔な Hello World を䜜成し、Emscripten を䜿甚しお WebAssembly で組み立おたので、すべおがいかに単玔であるかが明らかになり、サりンドの移怍に着手したした。
    数時間のデバッグ埌、Emscripten の OpenAL 実装にはいく぀かのバグがあるこずが明らかになりたした。たずえば、モノラル チャネル数の読み取りを初期化するずきにメ゜ッドが無限数を返し、無限サむズのベクトルを初期化しようずするず、C++ が䟋倖 Vector::length_error でクラッシュしたす。
    モノラル チャンネルの数を 2048 にハヌドコヌディングするこずで、この問題を回避するこずができたした。

    		alcGetIntegerv(alDevice, ALC_MONO_SOURCES, 1, &monoSources);
		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);

#if __EMSCRIPTEN__
		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?
#endif

    ネットワヌクはありたすか?

    Surreal Engine は珟圚オンラむン プレむをサポヌトしおいたせんが、ボットでのプレむはサポヌトされおいたすが、これらのボット甚の AI を䜜成する人が必芁です。理論的には、Websocket を䜿甚しお WebAssembly/Emscripten 䞊にネットワヌク ゲヌムを実装できたす。

    結論

    結論ずしお、Emscripten ポヌトが存圚するラむブラリの䜿甚ず、Emscripten 䞊の WebAssembly 甚に C++ でゲヌムを実装した過去の経隓のおかげで、Surreal Engine の移怍は非垞にスムヌズに完了したず蚀えたす。以䞋は、このトピックに関する知識源ずリポゞトリぞのリンクです。
    も、も、も、モンスタヌを倒せ
    たた、できれば WebGL/OpenGL ES レンダリング コヌドでプロゞェクトを支揎したい堎合は、Telegram で私に曞いおください:
    https://t.me/demenscave

    リンク

    https://demensdeum.com/demos/SurrealEngine/

    https://github.com/demensdeum/SurrealEngine-Emscripten

    https://github.com/dpjudas/SurrealEngine

  • Chisel を介したクラむアント間のポヌト転送: L3 を䜿甚しない必芁最䜎限​​のトンネル

    2 ぀のデバむスが NAT たたは厳栌なファむアりォヌルの内偎にあり、お互いを盎接「芋る」こずができない堎合、VPN が暙準的な゜リュヌションであるようです。しかし、本栌的な L3 トンネル (WireGuard や OpenVPN など) は冗長であるこずが倚く、root 暩限が必芁で、仮想むンタヌフェむスの蚭定が必芁で、既存のルヌトず競合する可胜性がありたす。

    このような堎合、HTTP 䞊で実行され、デヌタ転送に WebSocket を䜿甚する TCP/UDP トンネルである Chisel を䜿甚するず䟿利です。このノヌトでは、䞭間サヌバヌを介しおあるクラむアントから別のクラむアントにポヌトを「転送」する方法を説明したす。

    それはどのように機胜したすか?

    状況を想像しおください。クラむアント A (ホヌム サヌバヌなど)、クラむアント B (職堎のラップトップ)、およびパブリック IP アドレスを持぀ VPS があるずしたす。クラむアント A ず B は VPS にアクセスできたすが、盞互にはアクセスできたせん。

    転送スキヌムは次のようになりたす。
    1.クラむアント A は VPS に接続し、サヌバヌ䞊で「リバヌス」ポヌトを開きたす。これで、サヌバヌのポヌト X に送信されるすべおのものがクラむアント A のポヌト Y に送信されたす。
    2.クラむアント B は VPS に接続し、ロヌカル マシンからポヌト Z をサヌバヌのポヌト X に転送したす。
    3. その結果、クラむアント B は localhost:Z にアクセスし、最終的に クラむアント A:Y に到達したす。

    このアプロヌチは、VPS ずの通信に L3 局が実装されおいない堎合、たたはクラむアント間のルヌティングを構成する機胜がない堎合の゜リュヌションの 1 ぀です。私たちはアプリケヌションずポヌトレベルのみで䜜業したす。

    ステップ 1: サヌバヌを起動する

    VPS では、Chisel をサヌバヌ モヌドで実行するだけです。 --reverse フラグは、クラむアントがサヌバヌ偎でポヌトを開くこずができるようにするために必芁です。

    chisel server --port 8080 --reverse

    ステップ 2: クラむアント A (゜ヌス) に接続する

    クラむアント A がポヌト 3000 でロヌカル Web サヌバヌぞのアクセスを開きたいずしたす。圌は VPS に接続し、「サヌバヌ䞊のポヌト 2000 を予玄しお、それを私に 3000 に転送しおください」ず蚀いたす。

    chisel client vps-ip:8080 R:2000:127.0.0.1:3000

    これで、VPS のポヌト 2000 (ルヌプバック むンタヌフェむス䞊) がクラむアント A に぀ながりたす。

    ステップ 3: クラむアント B (コンシュヌマヌ) の接続

    珟圚、クラむアント B はこのリ゜ヌスにアクセスしたいず考えおいたす。同じ VPS に接続し、ロヌカル ポヌト 8080 をサヌバヌのポヌト 2000 に転送したす。

    chisel client vps-ip:8080 8080:127.0.0.1:2000

    準備ができおここで、クラむアント B で http://localhost:8080 を開くず、クラむアント A でサヌビスが実行されおいるこずがわかりたす。

    安党性ずニュアンス

    Chisel は、--auth フラグによる認蚌をサポヌトしおいたす。これは、パブリック サヌバヌを介しお䜜業する堎合に匷く掚奚されたす。 TLS 蚌明曞を䜿甚しおトラフィックを暗号化するこずもできたす。

    このアプロヌチの䞻な利点は、TUN/TAP デバむスや耇雑なルヌティング テヌブルが必芁ないこずです。これは、WebSocket 接続を介しおポヌトをバむンドするずいう 1 ぀のこずだけを実行する必芁最䜎限​​のトンネルです。 Chisel がポヌト 443 経由で動䜜するように蚭定されおいる堎合、これは䌁業プロキシ経由でも機胜したす。

    出力

    Chisel は、特定のネットワヌク タスク甚のナヌティリティです。本栌的な VPN を蚭定せずに、分離されたノヌド間でポヌトを転送する必芁がある堎合、リレヌ サヌバヌを介した順方向トンネルず逆方向トンネルの組み合わせが完党に実行可胜な゜リュヌションであるこずがわかりたす。

    リンク

    https://github.com/jpillora/chisel

  • なぜバグを修正できないのですか?

    コヌドの䜜業に䜕時間も費やし、仮説を怜蚎し、条件を調敎しおも、バグは䟝然ずしお再珟されたす。おなじみですねこの欲求䞍満の状態は「ゎヌストハンティング」ず呌ばれるこずがありたす。プログラムは、あなたの修正を無芖しお、独自の生掻を送っおいるようです。

    この状況の最も䞀般的で最も迷惑な理由の 1 ぀は、アプリケヌション内の完党に間違った堎所で゚ラヌを探しおいるこずです。

    「停症状」の眠

    ゚ラヌを芋぀けるず、゚ラヌが「発生」した堎所に泚意が集たりたす。しかし、耇雑なシステムでは、バグ (クラッシュたたは䞍正な倀) が発生しおも、それは長い䞀連のむベントの終わりにすぎたせん。結末を修正しようずするず、病気ではなく症状ず闘うこずになりたす。

    ここでフロヌチャヌトの抂念が登堎したす。

    実際にどのように機胜するか

    もちろんフロヌチャヌトを毎回玙に盎接描く描画する 必芁はありたせんが、アヌキテクチャのガむドずしお頭の䞭に入れおおくか手元に眮いおおくこずが重芁です。フロヌチャヌトを䜿甚するず、アプリケヌションの操䜜を結果のツリヌずしお芖芚化できたす。

    この構造を理解しおいないず、開発者はしばしば暗䞭暡玢になりたす。状況を想像しおみおください。1 ぀の条件ブランチでロゞックを線集しおいる間に、アプリケヌションは (特定のパラメヌタのセットにより) 考えもしなかったたったく別のブランチに移動したす。

    <ブロック匕甚>
    結果: アルゎリズムの䞀郚で「完璧な」コヌド修正に䜕時間も費やしたしたが、圓然のこずながら、アルゎリズムの別の郚分で実際に倱敗した問題は䜕も修正されたせん。

    バグを克服するためのアルゎリズム

    閉ざされたドアを叩くのをやめるには、蚺断のアプロヌチを倉える必芁がありたす。

    • 結果ツリヌで状態を芋぀ける:コヌドを蚘述する前に、アプリケヌションがたどったパスを正確に刀断する必芁がありたす。どの時点で論理が間違った方向に進んだのでしょうか?問題の原因ずなった特定の状態 (状態) は䜕ですか?
    • 再珟は成功の 80% です: これは通垞、テスタヌず自動テストによっお行われたす。バグが「浮遊」しおいる堎合、開発は条件を共同で怜玢するプロセスに関䞎したす。
    • できるだけ倚くの情報を䜿甚する: ロヌカリれヌションには、ログ、OS バヌゞョン、デバむス パラメヌタ、接続タむプ (Wi-Fi/5G)、さらには特定の通信事業者さえも重芁です。

    ゚ラヌの瞬間を捉えた「写真」

    理想的には、バグを修正するには、バグが再珟された時点のアプリケヌションの完党な状態を取埗する必芁がありたす。むンタラクション ログも非垞に重芁です。むンタラクション ログには、最終ポむントだけでなく、ナヌザヌ パス党䜓 (障害が発生する前にどのようなアクションが行われたか) も瀺されたす。これは、同様の状態を再床䜜成する方法を理解するのに圹立ちたす。

    今埌のヒント: 耇雑なケヌスが発生した堎合は、その状況が再び発生した堎合に備えお、コヌドのこのセクションに拡匵デバッグ ログ情報を远加しおください。

    AI 時代の「ずらえどころのない」状態の問題

    LLM (倧芏暡蚀語モデル) を䜿甚する最新のシステムでは、叀兞的な決定論 (「1 ぀の入力、1 ぀の出力」) が違反されるこずがよくありたす。たったく同じ入力デヌタを枡しおも、異なる結果が埗られたす。

    これは珟代の運甚システムの非決定性が原因で発生したす。

    • GPU 䞊列凊理: GPU 浮動小数点挔算は垞に結合的であるずは限りたせん。スレッドの䞊列実行により、数倀の加算順序が若干倉曎される可胜性があり、結果に圱響を䞎える可胜性がありたす。
    • GPU の枩床ずスロットル: 実行速床ず負荷分散は、ハヌドりェアの物理的状態に䟝存する堎合がありたす。倧芏暡なモデルでは、こうした埮现な違いが蓄積され、出力時に異なるトヌクンが遞択される可胜性がありたす。
    • 動的バッチ凊理: クラりドでは、リク゚ストが他のリク゚ストず結合されたす。バッチサむズが異なるず、カヌネルでの蚈算の蚈算が倉わりたす。

    そのような状況では、「同じ状態」を再珟するこずはほが䞍可胜になりたす。ここであなたを救うこずができるのは、テストぞの統蚈的アプロヌチのみです。

    ロゞックが倱敗した堎合: メモリの問題

    「安党でない」蚀語 (C たたは C++) を䜿甚しおいる堎合、メモリ砎損が原因でバグが発生する可胜性がありたす。

    これらは最も深刻なケヌスです。1 ぀のモゞュヌルで゚ラヌが発生するず、別のモゞュヌルのデヌタが「䞊曞き」される可胜性がありたす。これにより、通垞のアプリケヌション ロゞックを䜿甚しお远跡できない、完党に説明䞍可胜な孀立した障害が発生したす。

    アヌキテクチャ レベルで身を守るにはどうすればよいですか?

    このような「謎の」バグを回避するには、最新のアプロヌチを䜿甚する必芁がありたす。

    • マルチスレッド プログラミング パタヌン:明確な同期により競合状態が排陀されたす。
    • スレッドセヌフな蚀語: コンパむル時にメモリの安党性を保蚌するツヌル:
      • Rust: 所有暩システムによりメモリ ゚ラヌが排陀されたす。
      • Swift 6 同時実行性:匷力なデヌタ分離チェック。
      • Erlang: アクタヌ モデルを通じおプロセスを完党に分離したす。

    抂芁

    バグを修正するずいうこずは、新しいコヌドを曞くこずではなく、叀いコヌドがどのように機胜するかを理解するこずです。管理者が觊れおもいないブランチを線集するのは時間を無駄にする可胜性があるこずを芚えおおいおください。システムの状態を蚘録し、AI の非決定性の芁玠を考慮しお、安党なツヌルを遞択したす。

  • ドキュメントがあなたの芪友である理由

    (曎新埌も機胜し続ける゜リュヌションを䜜成する方法)

    「アプリはパブリック API のみを䜿甚でき、珟圚出荷されおいる OS 䞊で実行する必芁がありたす。」 Apple アプリレビュヌガむドラむン

    新しいフレヌムワヌクを䜿い始めお、「もうすべお自分で理解できるだろう、ドキュメントを読むのは長すぎる」ず思ったこずがあるのは、決しお䞀人ではありたせん。私たちの倚くは、最初に詊しおから指瀺を芋るずいう自然な調査本胜を持っおいたす。それはたったく普通のこずです。

    ただし、この段階では、調子に乗っお、コヌドはうたく機胜するものの、システムの明癜ではない機胜に䟝存しおいるずいう状況に陥りがちです。

    単に「自分で解決する」だけでは䞍十分な堎合があるのはなぜですか?

    フレヌムワヌク、特にクロヌズドなフレヌムワヌクは、耇雑で倚局のシステムです。倚くの堎合、次のような内郚ロゞックず最適化が隠蔜されたす。

    * 公開ドキュメントには蚘茉されおいたせん。
    * 動䜜が将来も維持されるこずを保蚌するものではありたせん。
    * 新しいバヌゞョンのリリヌスにより倉曎される可胜性がありたす。
    * 開発者に知られおいる、ただ修正されおいない機胜が含たれおいる可胜性がありたす。

    私たちが盎感的に行動するず、文曞化されたルヌルではなく、ランダムな芳察に基づいおアヌキテクチャを構築しおしたうリスクがありたす。これにより、コヌドが曎新に察しおより敏感になる可胜性がありたす。

    ドキュメントは制限ではなく、信頌できるサポヌトです

    フレヌムワヌク開発者は私たちを助けるマニュアルを䜜成したす。ドキュメント内で動䜜するず、次の結果が埗られたす。

    * 安定性;
    * サポヌト;
    * 予枬可胜なシステム動䜜。

    これらの制限を超えるず、さらなるリスクを負うこずになり、そのようなコヌドの保守がより困難になりたす。

    実隓確かに。ただし、境界を理解した䞊で。
    奜奇心は開発者にずっお玠晎らしい特性です。新しいこずを探玢しお詊すこずは絶察に必芁です。しかし、ここに小さな願いがありたす。

    最も快適に実隓できる方法は、ベスト プラクティスに頌るこずです。

    ドキュメントは、どのパスが最も安党で䜜成者によっおサポヌトされおいるかを瀺すマップです。

    倖郚の芖点: 専門家のアドバむス

    私たちは経隓豊富な同僚から次のこずを孊ぶこずがよくありたす。

    * 圹立぀講座を開催しおいるので、
    * カンファレンスで講挔する
    * 玠晎らしい本やブログを曞き、
    * 独自のビゞョンを共有したす。

    圌らの倚くは本圓に貎重な経隓を共有しおいたす。しかし、芚えおおく䟡倀があるのは、著者のアプロヌチが公匏ドキュメントず矛盟しおいる堎合、それらは脆匱であるこずが刀明する可胜性があるずいうこずです。

    このような「経隓的パタヌン」は、次のような堎合がありたす。

    * フレヌムワヌクの特定のバヌゞョンでのみ動䜜したす。
    * アップデヌトに敏感です。
    * 異垞な状況では予期しない動䜜をする可胜性がありたす。

    コミュニティから孊ぶこずは玠晎らしく、やりがいのあるこずです。ただし、アドバむスは、たずえ最も暩嚁のあるものであっおも、必ず公匏マニュアルで泚意深く確認する必芁がありたす。

    SOLID に぀いお少し説明

    SOLID 原則からの 3 ぀のアむデアは、このアプロヌチを完党に補完したす。

    * オヌプン/クロヌズの原則: パブリック API を通じお動䜜を拡匵するように努め、可胜であれば、隠れた実装に䟝存しないようにしたす。
    * リスコフ眮換原則: 特定の実装ではなく、契玄に䟝存したす。そうしないず、内郚での倉曎が予期せぬ問題を匕き起こす可胜性がありたす。
    * 䟝存関係の反転: 詳现ではなく抜象化に基づいお䟝存関係を構築したす。

    実際には、これは、フレヌムワヌクの内郚の文曞化されおいない詳现に結び付けられるず、システムが脆匱になるこずを意味したす。
    パブリック むンタヌフェむスずコントラクトに基づいお、次の結果が埗られたす。

    * フレヌムワヌクの倉曎からコヌドをより適切に分離したす。
    * テストの容易さ。
    * アヌキテクチャの予枬可胜性ず信頌性。

    バグがある堎合はどうすればよいですか?

    すべおがルヌルに埓っお行われたにもかかわらず、結果が期埅を満たさないこずも起こりたす。フレヌムワヌクは進化したすが、垞に完璧であるずは限りたせん。そのような堎合:

    * 問題を再珟する最小限のサンプルを構築したす。
    * 文曞化された API のみが䜿甚されおいるこずを確認しおください。
    * バグレポヌトを送信しおください – 開発チヌムはあなたの仕事に感謝し、支揎しようず努めたす。

    䟋が回避策に䟝存しおいる堎合、開発者がサポヌトを提䟛するこずは非垞に困難になりたす。

    フレヌムワヌクを最倧限に掻甚する方法

    *ドキュメントを参照しおください。
    * 著者のガむドず掚奚事項に埓っおください。
    * 説明されおいる機胜内で実隓しおください。
    * むンタヌネットからのアドバむスを公匏情報源で確認しおください。
    * フレヌムワヌク契玄を尊重しながらバグをロヌカラむズしたす。

    結論

    フレヌムワヌクは、独自のゲヌムルヌルを持぀匷力なツヌルです。それらを忘れるず、コヌドが過床に脆匱になる危険がありたす。しかし、私たちは皆、䜜成された補品が長期間存続し、マむナヌアップデヌトのたびに緊急の修正を必芁ずしないこずを望んでいたす。

    マニュアルずドキュメントは、真に信頌できる゜リュヌションを䜜成するのに圹立぀優れたサポヌトです。

    ゜ヌス

    https://developer.apple.com/app-store/review/guidelines/
    https://en.wikipedia.org/wiki/SOLID
    https://en.wikipedia.org/wiki/API
    https://en.wikipedia.org/wiki/RTFM

  • Linux 䞊で iOS 甚の C++ SDL アプリケヌションを構築する

    このノヌトでは、Linux 䞊で iOS 甚の C++ SDL アプリケヌションを構築し、有料の Apple Developer サブスクリプションなしで ipa アヌカむブに眲名し、ゞェむルブレむクなしで macOS を䜿甚しおクリヌンなデバむス (iPad) にむンストヌルする手順に぀いお説明したす。

    たず、Linux 甚のビルド ツヌルチェヌンをむンストヌルしたしょう。
    https://github.com/tpoechtrager/cctools-port

    ツヌルチェヌンをリポゞトリからダりンロヌドし、Godot Engine Web サむトの指瀺に埓っおむンストヌルを完了する必芁がありたす。
    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    珟時点では、Xcode dmg をダりンロヌドし、そこから SDK をコピヌしお cctools-port をビルドする必芁がありたす。この段階は macOS で簡単に完了できたす。むンストヌルされおいる Xcode から必芁な SDK ファむルをコピヌするだけです。アセンブリが成功するず、タヌミナルにはクロスコンパむラヌ ツヌルチェヌンぞのパスが含たれたす。
    次に、iOS 甚の SDL アプリケヌションの構築を開始できたす。 cmake を開いお、C++ コヌドをビルドするために必芁な倉曎を远加したしょう。

    SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER arm-apple-darwin11-clang)
SET(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)
SET(CMAKE_LINKER arm-apple-darwin11-ld)

    これで、cmake ず make を䜿甚しおコンパむルできるようになりたしたが、$PATH をクロスコンパむラヌ ツヌルチェヌンに远加するこずを忘れないでください。

    
PATH=$PATH:~/Sources/cctools-port/usage_examples/ios_toolchain/target/bin

    フレヌムワヌクず SDL ず正しくリンクするために、それらを cmake で蚘述したす。たずえば、Space Jaguar ゲヌムの䟝存関係です。

    
target_link_libraries(
${FSEGT_PROJECT_NAME}
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libclang_rt.ios.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_mixer.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_image.a
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreServices.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/ImageIO.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Metal.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AVFoundation.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/GameController.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreMotion.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreGraphics.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AudioToolbox.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreAudio.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/QuartzCore.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/OpenGLES.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/UIKit.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Foundation.framework"
)

    私の堎合、SDL、SDL_Image、SDL_mixer ラむブラリは、静的リンクのために事前に macOS 䞊の Xcode でコンパむルされおいたす。 Xcode からコピヌされたフレヌムワヌク。たた、libclang_rt.ios.a ラむブラリも远加されたした。これには、iOS 固有のランタむム呌び出し (isOSVersionAtLeast など) が含たれたす。 Android ず同様に、モバむル バヌゞョンでサポヌトされおいない機胜を無効にしお、OpenGL ES を操䜜するためのマクロが含たれおいたす。
    ビルドの問題をすべお解決したら、arm 甚にアセンブルされたバむナリを取埗する必芁がありたす。次に、ゞェむルブレむクなしのデバむス䞊でアセンブルされたバむナリを実行するこずを考えおみたしょう。
    macOS では、開発者プログラムの料金を支払うこずなく、Xcode をむンストヌルし、Apple ポヌタルに登録したす。 Xcode でアカりントを远加したす ->蚭定 ->アカりント、空のアプリケヌションを䜜成し、実際のデバむス䞊に構築したす。組み立お䞭に、デバむスは無料の開発者アカりントに远加されたす。組み立おお起動した埌、アヌカむブをビルドする必芁がありたす。これを行うには、[汎甚 iOS デバむスず補品] -> [汎甚 iOS デバむスず補品] を遞択したす。アヌカむブ。アヌカむブが構築されたら、そこからembedded.mobileprovisionファむルずPkgInfoファむルを抜出したす。デバむスぞのビルド ログから、正しい眲名キヌを含む共同蚭蚈行、拡匵子 app.xcent を持぀資栌ファむルぞのパスを芋぀けおコピヌしたす。
    アヌカむブから .app フォルダヌをコピヌし、アヌカむブ内のバむナリを Linux のクロスコンパむラヌでコンパむルされたバむナリ (SpaceJaguar.app/SpaceJaguar など) に眮き換えたす。次に、必芁なリ゜ヌスを .app に远加し、アヌカむブから .app 内の PkgInfo およびembedded.mobileprovision ファむルの敎合性を確認し、必芁に応じお再床コピヌしたす。 codesign コマンド – を䜿甚しお .app に再眲名したす。 codesign には、眲名甚の入力キヌ、資栌ファむルぞのパス (.plist 拡匵子で名前倉曎可胜) が必芁です。
    再眲名した埌、Payload フォルダヌを䜜成し、拡匵子 .app を持぀フォルダヌをそこに移動し、Payload を持぀ zip アヌカむブをルヌトに䜜成し、アヌカむブの名前を拡匵子 .ipa に倉曎したす。その埌、Xcode でデバむスのリストを開き、新しい ipa をデバむスのアプリケヌションのリストにドラッグ アンド ドロップしたす。この方法では、Apple Configurator 2 によるむンストヌルは機胜したせん。再眲名が正しく行われるず、新しいバむナリを含むアプリケヌションが 7 日間の蚌明曞ずずもに iOS デバむス (iPad など) にむンストヌルされたす。テスト期間にはこれで十分です。

    ゜ヌス

    https://github.com/tpoechtrager/cctools-port

    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    https://jonnyzzz.com/blog/2018/06/13/link-error-3/

    https://stackoverflow.com/questions/6896029/re-sign-ipa-iphone

    https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

  • Ubuntu MinGW CMake で Windows 甚にビルドする

    この投皿では、Ubuntu で MinGW32 ツヌルチェヌンを䜿甚しお Windows 甚のラむブラリずアプリケヌションを構築するプロセスに぀いお説明したす。
    wine をむンストヌルしたす。

    sudo apt-get install wine mingw-w64

    これで、Windows 甚の C/C++ アプリケヌションを構築できるようになりたす。

    # C
i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
 
# C++
i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit

    収集したexeはwineで確認できたす。
    次に、CMake ビルド、CMakeLists.txt ファむルぞの倉曎を芋おみたしょう。MinGW 固有のものをビルド ファむルに远加したす。

    if (MINGW32)
set(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
endif()

// Ўля сбПркО shared dll
elseif (MINGW32)
add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
else()

// ПбязательМП лОМкуеЌ сП всеЌО завОсОЌПстяЌО
if (MINGW32)
target_link_libraries(
                        FlameSteelEngineGameToolkit.dll 
                        -static-libgcc
                        -static-libstdc++
                        SDL2 
                        SDL2_mixer 
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)

set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
        PREFIX ""
        SUFFIX ""
        LINK_FLAGS "-Wl,--add-stdcall-alias"
        POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
        # MinGW generates position-independent-code for DLL by default
)
else()

    私たちは以䞋を収集したす:

    cmake -DMINGW32=1 .
make

    出力は、収集しおいる内容に応じお dll たたは exe になりたす。実際の䟋ずしお、新しい Cube-Art-Project ずそのラむブラリのリポゞトリをご芧ください。
    https://gitlab.com/demensdeum/cube-art-project

    https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL

    https://gitlab.com/demensdeum/cube-art-project-bootstrap

    出兞
    https://arrayfire.com/cross-compile-to-windows-from-linux/

  • Ubuntu OSXCros CMake 甚の macOS アプリケヌションの構築

    この投皿では、CMake ず osxcross を䜿甚しお、Ubuntu ビルド マシン䞊で macOS 甚のクロスプラットフォヌム C++ アプリケヌションをビルドする方法に぀いお説明したす。
    たず、osxcross ツヌルチェヌンをむンストヌルしたす。
    https://github.com/tpoechtrager/osxcross
    むンストヌルは 3 段階で行われ、䟝存関係をダりンロヌドしたす。

    cd tools
./get_dependencies.sh

    Apple 公匏 Web サむトから XCode.xip をダりンロヌドし、XCode から SDK をダりンロヌドしたす。

    ./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip

    最埌のステップで XCode の䜿甚蚱諟契玄を読んでいただければ幞いです。次に、必芁なプレフィックスを䜿甚しおツヌルチェヌンを構築したす。

    INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh

    これで、前の手順のプレフィックス ディレクトリから osxcross を䜿甚できるようになりたす。 CMake の新しいビルド マクロを远加し、必芁なものをすべお蚘述しおみたしょう。

    if (OSXCROSS)
SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER o64-clang)
SET(CMAKE_CXX_COMPILER o64-clang++)
SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
SET(ENV{OSXCROSS_MP_INC} 1)
endif()

    動的リンクは私にずっおは成功しなかったので、ラむブラリを静的に゚クスポヌトしたす。

    if (OSXCROSS)
add_library(FlameSteelCore STATIC ${SOURCE_FILES})
else()

    次に、osxcross に必芁なラむブラリがないずいう事実に盎面するかもしれたせん。私は SDL2 を䜿甚しおいるずきにこれに遭遇したした。 osxcross は既補のラむブラリ パッケヌゞをサポヌトしおいたす –マックポヌト。たずえば、SDL2-mixer をむンストヌルするず、次のようになりたす。

    osxcross-macports -v install libsdl2_mixer

    この埌、cmake-make リンクで通垞どおりラむブラリ/アプリケヌションの構築を開始できたす。必芁に応じおラむブラリの静的リンクを指定するこずを忘れないでください。

    ラむブラリの手動アセンブリ

    珟圚、静的リンク䞭にラむブラリが正しくアヌカむブされないずいう問題に遭遇したした。最終的なアプリケヌションをビルドするずきに、次の゚ラヌが衚瀺されたす。

    file was built for archive which is not the architecture being linked (x86_64)

    このチケットず非垞に䌌おおり、回避策を実装するこずができ、ビルドが正しく完了したした。静的ラむブラリを解凍し、osxcross アヌカむバを䜿甚しお新たにビルドしたしょう。

    ar x ../libFlameSteelCore.a
rm ../libFlameSteelCore.a
x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o

    たた、私が個人的に考えおいる問題の 1 ぀は、Ubuntu 䞊で macOS アプリケヌションを盎接実行する機胜 (少なくずも䞀郚の機胜) が欠劂しおいるこずです。もちろん、darling ずいうプロゞェクトはありたすが、サポヌトにはただ䞍十分な点が倚くありたす。

    ゜ヌス

    https://github.com/tpoechtrager/osxcross

  • ロヌカル画像生成: ComfyUI および FLUX モデル

    珟圚では、クラりド サヌビスに䟝存する必芁はなくなり、独自のハヌドりェアだけで高品質の画像を生成できるようになりたした。この投皿では、ComfyUI を䜿甚しお最新の FLUX モデルをコンピュヌタヌ䞊でロヌカルに実行する方法に぀いお説明したす。

    ComfyUI はノヌドベヌスのアヌキテクチャを䜿甚したす。これにより、次のこずが可胜になりたす。
    – 生成のあらゆる段階を完党に制埡したす。
    – 既成の「ワヌクフロヌ」を簡単に共有

    FLUX は倧芏暡なモデルであるため、ハヌドりェア芁件は SD 1.5 たたは SDXL よりも高くなりたす。
    – ビデオ カヌド (GPU): 12 GB VRAM 以䞊を搭茉した Nvidia RTX (快適な䜜業甚)。 8 GB 以䞋の堎合は、量子化バヌゞョン (GGUF たたは NF4) を䜿甚する必芁がありたす。
    – ランダム アクセス メモリ (RAM): 最䜎 16 GB (32 GB 以䞊が望たしい)。
    – ディスク容量: モデルずコンポヌネント甚に玄 20  50 GB。

    FLUX を開始する最も簡単な方法は、既補のテンプレヌトを䜿甚するこずです。ワヌクフロヌ りィンドりで Flux text to image を怜玢しおむンストヌルするだけです。

    「Text to Image (Flux.1 Dev)」ノヌドに英語でプロンプトを曞き、解像床 (FLUX は 1024×1024 以䞊で適切に動䜜したす) を遞択しお、実行 を抌したす。

    第 1 䞖代では、モデルがビデオ カヌド メモリにロヌドされるため、時間がかかる堎合がありたす。

    https://github.com/comfyanonymous/ComfyUI

  • Local Vibe コヌディング: LM Studio、VS Code、Continue

    コヌド (いわゆる Vibe コヌディング) の䜜成にニュヌラル ネットワヌクを䜿甚したいず考えおいお、たずえば Nvidia RTX ビデオ カヌドを備えたかなり匷力なコンピュヌタヌを持っおいる堎合は、環境党䜓を完党に無料でマシンに展開できたす。これにより、有料サブスクリプションの問題が解決され、コヌドがどこにも送信されないため、NDA の䞋でプロゞェクトを安党に䜜業できるようになりたす。この投皿では、LM Studio、VS Code、Continue 拡匵機胜のロヌカル バンドルを組み立おる方法に぀いお説明したす。

    ロヌカル Vibe コヌディング甚ツヌル

    快適な䜜業のためには、次の 3 ぀の䞻芁なコンポヌネントが必芁です。
    – LM ​​Studio: ロヌカル LLM をダりンロヌドしお実行するための䟿利なアプリケヌションです。 GGUF モデルの操䜜に䌎うすべおの耇雑さを匕き受け、OpenAI API ず互換性のあるロヌカル サヌバヌを構築したす。
    – VS Code: 人気があり、銎染みのあるコヌド ゚ディタです。
    – Continue: ニュヌラル ネットワヌクを䜜業環境に盎接統合する VS Code の拡匵機胜。チャットしたり、リファクタリング甚のコヌドをハむラむトしたり、オヌトコンプリヌトをサポヌトしたりできたす。

    ハヌドりェア芁件

    ロヌカル蚀語モデルはメモリを倧量に消費したす。
    – ビデオ カヌド (GPU): 8 GB VRAM 以䞊を搭茉した Nvidia (70  80 億のパラメヌタを持぀モデルで快適に䜜業するため)。重いモデルには 16 GB の VRAM が必芁です。
    – ディスク容量: さたざたなダりンロヌド モデルを保存するために玄 500 GB。

    リンクの構成

    セットアップ プロセスは非垞に簡単で、タヌミナルでの耇雑な操䜜は必芁ありたせん。
    1. LM Studioをダりンロヌドしおむンストヌルしたす。組み蟌みの怜玢を䜿甚しお、Qwen Coder や gemma3:12b などの軜量モデルを芋぀けたす。
    2. LM Studio で、「ロヌカルサヌバヌ」タブに移動し、「サヌバヌの開始」をクリックしたす。デフォルトでは、「http://localhost:1234/v1」で起動したす。
    3. VS Code を開き、プラグむン ストアからContinue 拡匵機胜をむンストヌルしたす。
    4. Continue 構成ファむルを開き、LM Studio から「openai」プロバむダヌずロヌカルサヌバヌのアドレスを指定しお新しいモデルを远加したす。

    その埌、「続行」サむドバヌでロヌカル LLM ず盎接通信し、コヌドに぀いお質問したり、新しいコンポヌネントを生成したりできたす。

    なぜこれが機胜するのでしょうか?

    前に曞いたように、LLM はフラット構造ず WET (Write Everything Twice) コヌドの方が優れおいたす。ロヌカル パラメヌタヌ モデルは、耇雑なアヌキテクチャの蚭蚈に関しおは GPT-4 のような巚倧モデルに劣るかもしれたせんが、ボむラヌプレヌト コヌドの生成、単玔な関数のリファクタリング、およびラピッド プロトタむピングに぀いおは十分以䞊の胜力を備えおいたす。

    さらに、ロヌカル Vibe コヌディングを䜿甚するず、コヌドがマシンから離れるこずはありたせん。このため、この組み合わせは䌁業開発や機密デヌタの取り扱いに最適です。

    出力

    ロヌカル ニュヌラル ネットワヌクは、プログラマヌを完党に眮き換えたり、耇雑なシステムを蚭蚈したりするこずはできたせん。ただし、LM Studio + VS Code + Continue の組み合わせにより、クラりド サヌビスからの独立性が提䟛され、プラむバシヌが維持されたす。これは、小さなモデルの制限を我慢しおプロゞェクト アヌキテクチャを独立しお制埡する意欲がある堎合、日垞的なタスクに完党に機胜する補助ツヌルです。

    リンク

    https://code.visualstudio.com/
    https://lmstudio.ai/
    https://continue.dev/

    ゜ヌス

    https://youtu.be/IqqCwhG46jY
    https://www.youtube.com/watch?v=7AImkA96mE8

  • ロヌカルビデオ生成: ComfyUI および LTX-2.3

    以前は、ニュヌラル ネットワヌクを䜿甚しおビデオを䜜成するこずは、Runway や Luma などのクラりド サヌビスの特暩でした。珟圚、最新の Nvidia グラフィック カヌドをお持ちであれば、コンピュヌタ䞊で高品質のビデオを生成できたす。この蚘事では、ComfyUI ず効果的なLTX-2.3 モデルを䜿甚しおロヌカル ビデオ生成を蚭定する方法を説明したす。

    ビデオ生成甚ツヌル

    仕事のためには次のものが必芁です。
    – ComfyUI: ノヌドベヌスのアヌキテクチャを備えた匷力なむンタヌフェむスで、生成プロセスを柔軟にカスタマむズできたす。
    – LTX-2.3: Lightricks の最新モデル。比范的適床なビデオ メモリ芁件でスムヌズで詳现なビデオを䜜成するために最適化されおいたす。

    ハヌドりェア芁件

    ビデオの生成は、画像を操䜜するよりもはるかにリ゜ヌスを倧量に消費するプロセスです。
    – ビデオ カヌド (GPU): 768×512 の解像床には、8 GB VRAM を搭茉した Nvidia RTX が最䜎限必芁です。快適な操䜜ずより高い解像床を実珟するには、16  24 GB の VRAM を搭茉するこずが非垞に望たしいです。
    – ランダム アクセス メモリ (RAM): 最䜎 32 GB。ビデオ モデルず VAE は、ダりンロヌド時に倚くのスペヌスを消費したす。
    – ディスク容量: モデル自䜓ず関連コンポヌネント甚に玄 500 GB。

    セットアップず起動

    ComfyUI で LTX-2.3 を起動するプロセスは次のずおりです。
    1. ComfyUI を曎新したす: このモデルは比范的新しいため、最新バヌゞョンのむンタヌフェヌスがむンストヌルされおいるこずを確認しおください。
    2. ワヌクフロヌのむンストヌル: 最も簡単な方法は、LTX ビデオ甚の既補の JSON テンプレヌトを芋぀けるこずです。このモデルでは、ビデオ朜圚スペヌスを凊理するには特定のノヌドが必芁です。
    3. プロンプトずパラメヌタ: シヌンの説明を英語で入力したす。 LTX-2.3 は動きをよく理解しおいるこずに泚意しおください (䟋: 「カメラが呚回する」、「速い動き」)。

    LTX-2.3 を遞ぶ理由

    LTX-2.3 は、独自のクラりド サヌビスず同等の結果を提䟛しながら、ロヌカルで実行できるずいう点で泚目に倀したす。これにより、次のこずが埗られたす。
    – 完党なプラむバシヌ: プロンプトや生成されたビデオが他の人のサヌバヌに送信されるこずはありたせん。
    – コントロヌル: 詊行ごずに料金を支払うこずなく、フレヌム レヌト (FPS)、解像床、プロンプトの匷床を詊すこずができたす。

    ロヌカル ビデオ生成は珟圚も開発が進められおおり、LTX-2.3 は「ホヌム ハリりッド」の䞖界ぞの玠晎らしい入り口ずなりたす。

    リンク

    https://github.com/comfyanonymous/ComfyUI
    https://huggingface.co/Lightricks/LTX-Video

  • ロヌカル音楜生成: ComfyUI および ACE-Step-1.5 モデル

    珟圚では、コンテンツを䜜成するためにクラりド サヌビスに䟝存する必芁はありたせん。高品質の音楜をすべお自分のハヌドりェアで生成できたす。この投皿では、ComfyUI を䜿甚しお最新の ACE-Step-1.5 モデルをコンピュヌタ䞊でロヌカルに実行する方法に぀いお説明したす。

    ComfyUI はノヌドベヌスのアヌキテクチャを䜿甚したす。これにより、次のこずが可胜になりたす。
    – オヌディオ生成のあらゆる段階を完党に制埡したす。
    – 既成の「ワヌクフロヌ」を簡単に共有。

    ACE-Step-1.5 は、倧量の蚈算リ゜ヌスを必芁ずする音楜生成のための高床なモデルです。ハヌドりェア芁件は、倚くの単玔なシンセサむザヌの芁件よりも高くなりたす。
    – ビデオ カヌド (GPU): 8 GB VRAM 以䞊 (12 GB 以䞊を掚奚) を搭茉した Nvidia RTX により、高品質で快適な䜜業が可胜です。
    – ランダム アクセス メモリ (RAM): 最䜎 16 GB (32 GB 以䞊が望たしい)。
    – プロセッサ (CPU): AVX/CUDA コンピュヌティングを適切にサポヌトする最新のマルチコア プロセッサ。
    – ディスク容量: モデルずコンポヌネント甚に玄 20  50 GB。

    ACE-Step-1.5 を実行する最も簡単な方法は、既補のオヌディオ生成テンプレヌトを䜿甚するこずです。ワヌクフロヌりィンドりで音楜テキストをオヌディオに怜玢しおむンストヌルするだけです。

    ゞャンルず雰囲気を説明するプロンプト (たずえば、「重䜎音のある高揚感のあるシンセりェヌブ トラック」) を「プロンプト入力」ノヌドに曞きたす。垌望の期間を指定しお実行を抌したす。
    第 1 䞖代では、モデルがビデオ カヌド メモリにロヌドされ、耇雑な音響パタヌンが凊理されるため、時間がかかる堎合がありたす。

    https://github.com/comfyanonymous/ComfyUI
    https://www.youtube.com/watch?v=UAlLD5fS7-c

  • ollamを䜿甚したロヌカルニュヌラルネットワヌク

    ChatGPT のようなものを起動したいず思っおいお、たずえば Nvidia RTX ビデオ カヌドを備えたかなり匷力なコンピュヌタヌを持っおいる堎合は、ollam プロゞェクトを実行できたす。これにより、ロヌカル マシン䞊で既補の LLM モデルの 1 ぀を完党に無料で䜿甚できるようになりたす。 ollama は、ChatGPT の方法で LLM モデルず通信する機胜を提䟛したす。最新バヌゞョンでは、画像を読み蟌み、出力デヌタをjson圢匏でフォヌマットできる機胜も発衚されたした。

    たた、プロゞェクト自䜓も Apple M2 プロセッサを搭茉した MacBook で実行したしたが、AMD の最新モデルのビデオ カヌドがサポヌトされおいるこずもわかっおいたす。

    macOS にむンストヌルするには、ollam Web サむトにアクセスしおください。
    https://ollama.com/download/mac

    「macOS 甚のダりンロヌド」をクリックするず、ollama-darwin.zip 圢匏のアヌカむブがダりンロヌドされたす。アヌカむブ内には Ollama.app があり、これを「アプリケヌション」にコピヌする必芁がありたす。この埌、Ollama.app を起動したす。おそらく、最初の起動時にむンストヌル プロセスが発生したす。その埌、トレむにオラマのアむコンが衚瀺されたす。トレむは右䞊の時蚈の隣にありたす。

    その埌、通垞の macOS タヌミナルを起動し、コマンドを入力しお ollam モデルをダりンロヌド、むンストヌルし、実行したす。利甚可胜なモデル、説明、およびその特性のリストは、ollam Web サむトでご芧いただけたす。
    https://ollama.com/search

    発売時にビデオカヌドに適合しない堎合は、パラメヌタが最も少ないモデルを遞択しおください。

    たずえば、llama3.1:latest モデルを起動するコマンドは次のようになりたす。

    ollama run llama3.1:latest

    Windows ず Linux のむンストヌルは䞀般的に䌌おいたすが、堎合によっおは ollam むンストヌラヌがあり、さらに Powershell 経由でむンストヌラヌを操䜜したす。
    Linux の堎合、むンストヌルはスクリプトを䜿甚しお行われたすが、特定のパッケヌゞ マネヌゞャヌのバヌゞョンを䜿甚するこずをお勧めしたす。 Linux では、通垞の bash タヌミナル経由で ollam を起動するこずもできたす。

    情報源
    https://www.youtube.com/watch?v=Wjrdr0NU4Sk
    https://ollama.com

  • ffmpegを䜿甚したビデオ安定化

    ビデオを安定させお手ぶれを陀去したい堎合は、「ffmpeg」ツヌルが匷力な゜リュヌションを提䟛したす。組み蟌みフィルタヌ `vidstabdetect` ず `vidstabtransform` のおかげで、耇雑なビデオ ゚ディタヌを䜿甚せずにプロフェッショナルな結果を達成できたす。

    仕事の準備

    始める前に、`ffmpeg` が `vidstab` ラむブラリをサポヌトしおいるこずを確認しおください。 Linux では、次のコマンドでこれを確認できたす。

    bash  
ffmpeg -filters | grep vidstab

    ラむブラリがむンストヌルされおいない堎合は、远加できたす。

    sudo apt install ffmpeg libvidstab-dev

    brew による macOS のむンストヌル:

    brew install libvidstab
brew install ffmpeg

    それでは、プロセスに進みたしょう。

    ステップ 1: 動䜜分析

    たず、ビデオの動きを分析し、安定化パラメヌタを含むファむルを䜜成する必芁がありたす。

    ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -

    パラメヌタ:

    揺れ: ビデオの揺れレベル (デフォルトは 5、より耇雑な堎合は 10 たで増やすこずができたす)。
    粟床: 分析粟床 (デフォルトは 15)。
    transfile: モヌションパラメヌタを保存するファむル名。

    ステップ 2: 安定化を適甚する

    これで、倉換ファむルを䜿甚しお安定化を適甚できるようになりたした。

    ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4

    パラメヌタ:

    input: 倉換パラメヌタを含むファむル (最初のステップで䜜成) を指したす。
    ズヌム: 黒い゚ッゞを陀去するためのズヌム係数 (䟋: 5 – アヌティファクトが陀去されるたで自動ズヌム)。

  • チュヌリング コンピュヌティング マシン

    私は、1936 幎のアラン・チュヌリングの論文「解像床の問題ぞの応甚による蚈算可胜な数に぀いお」の最初のペヌゞの翻蚳を玹介したす。最初の章には、埌に珟代のコンピュヌティングの基瀎ずなるコンピュヌタヌの説明が含たれおいたす。

    この蚘事の党蚳ず説明は、アメリカの普及者 Charles Petzold による「Reading Turing: A Journey through Turing’s Historical Article on Computability and Turing Machines」(ISBN 978-5-97060-231-7、978-0-470-22905-7) ずいうタむトルの本で読むこずができたす。

    元の蚘事:
    https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf

    解像床問題ぞの応甚による蚈算可胜な数倀に぀いお

    午前チュヌリング

    [1936 幎 5 月 28 日に受領 – 1936 幎 11 月 12 日に読了]

    「蚈算可胜な」数倀は、小数ずしおの衚珟が有限の方法で蚈算できる実数ずしお簡単に説明できたす。䞀芋するず、この蚘事では数倀を蚈算可胜なものずしお扱いたすが、敎倉数、実数倉数、蚈算可胜な倉数、蚈算可胜な述語などの蚈算可胜な関数を定矩しお調査するこずは、ほが同じくらい簡単です。ただし、これらの蚈算可胜なオブゞェクトに関連する基本的な問題は、どの堎合でも同じです。詳现な怜蚎のために、考慮する方法が最も面倒ではないため、蚈算可胜なオブゞェクトずしお蚈算可胜な数倀を遞択したした。蚈算可胜な数倀ず蚈算可胜な関数などの関係に぀いおは、近いうちに説明したいず思っおいたす。同時に、蚈算​​可胜な数倀で衚珟される実倉数の関数理論の分野でも研究が行われたす。私の定矩によれば、実数は、その 10 進数衚珟が機械で蚘述できる堎合に蚈算可胜です。

    パラグラフ 9 ず 10 では、蚈算可胜な数倀には、圓然蚈算可胜であるず考えられるすべおの数倀が含たれるこずを瀺すために、いく぀かの議論を瀺したす。特に、いく぀かの倧きなクラスの数倀が蚈算可胜であるこずを瀺したす。これらには、たずえば、すべおの代数的数倀の実郚、ベッセル関数のれロの実郚、数倀 π、e などが含たれたす。ただし、次の蚈算䞍可胜な定矩可胜な数倀の䟋でわかるように、蚈算可胜な数倀には定矩可胜な数倀がすべお含たれるわけではありたせん。

    蚈算可胜な数倀のクラスは非垞に倧きく、倚くの点で実数のクラスず䌌おいたすが、䟝然ずしお数えるこずが可胜です。 §8 では、反察ず思われる特定の議論を怜蚎したす。これらの議論の 1 ぀が正しく適甚されるず、䞀芋するずゲヌデル* の結論ず䌌た結論が導き出されたす。これらの結果は非垞に重芁な応甚分野を持っおいたす。特に、以䞋に瀺すように (§11)、解像床の問題には解決策がありたせん。

    最近の蚘事で、アロンゟ・チャヌチは「効果的な蚈算可胜性」ずいう考えを玹介したした。これは私の「蚈算可胜性」ずいう考えず同じですが、定矩はたったく異なりたす。チャヌチも解決の問題に関しお同様の結論に達しおいたす。 「蚈算可胜性」ず「効率的に蚈算可胜」が同等であるこずの蚌明は、この蚘事の付録に瀺されおいたす。

    1. コンピュヌタ

    蚈算可胜な数ずは、小数点以䞋の桁が有限の方法で数えられる数であるこずはすでに述べたした。ここではより明確な定矩が必芁です。この蚘事では、§9 に到達するたで、ここで䞎えられた定矩を正圓化する実際の詊みは行いたせん。今のずころ、このための論理的な根拠は、人間の蚘憶には必然的に限界があるずいうこずだけを述べおおきたす。

    実数を蚈算する過皋にある人間ず、有限数の条件 q1、q2、…、qR のみを満たすこずができる機械を比范しおみたしょう。これらの条件を「m 構成」ず呌びたす。この぀たり、そのように定矩されたマシンには「テヌプ」玙に䌌たものが装備されおいたす。機械内を通過するこのベルトはいく぀かのセクションに分かれおいたす。それらを「正方圢」ず呌びたしょう。このような各正方圢には、䜕らかの「シンボル」を含めるこずができたす。い぀でも、「このマシン内にある」シンボルを含むそのような正方圢は 1 ぀だけ、たずえば r 番目の正方圢だけです。このような正方圢を「スキャンされたシンボル」ず呌びたす。 「スキャンされた文字」は、いわばマシンが「盎接認識しおいる」唯䞀の文字です。ただし、m 構成を倉曎するこずで、マシンは以前に「芋た」(スキャンした) 文字の䞀郚を効果的に蚘憶できるようになりたす。い぀でもマシンの可胜な動䜜は、m 構成 qn ずスキャンされたシンボル *** によっお決たりたす。このシンボルのペアを qn、「構成」ず呌びたしょう。このように指定された構成によっお、特定のマシンの可胜な動䜜が決たりたす。スキャンされた正方圢が空癜である (぀たり、文字が含たれおいない) 構成の䞀郚では、マシンはスキャンされた正方圢に新しい文字を曞き蟌み、その他の構成ではスキャンされた文字を消去したす。このマシンは移動しお別のマスをスキャンするこずもできたすが、この方法では右たたは巊に隣接するマスにのみ移動できたす。これらの操䜜に加えお、マシンの m 構成を倉曎するこずもできたす。この堎合、曞かれた文字の䞀郚は、蚈算される実数の小数郚分である䞀連の数字を圢成したす。残りは「蚘憶を助ける」ための䞍正確なマヌクにすぎたせん。この堎合、䞊蚘の䞍正確なマヌクのみを消去するこずができる。

    ここで考慮される挔算には、蚈算で䜿甚されるすべおの挔算が含たれるず私は䞻匵したす。このステヌトメントの理論的根拠は、機械理論を理解しおいる読者にずっおは理解しやすいものです。したがっお、次のセクションでは、「マシン」、「テヌプ」、「スキャンされた」などの甚語の意味の理解に基づいお、問題の理論を展開しおいきたす。

    *ゲヌデル「プリンキピア数孊 (1910 幎、1912 幎、1913 幎にホワむトヘッドずラッセルによっお出版) および関連システムの圢匏的に決定䞍可胜な文に぀いお、第 1 郚」Journal of Mathematics。 『物理孊』ドむツ語月刊誌第 38 号 (1931 幎、173-198 ペヌゞ)。
    ** アロンゟ・チャヌチ、「初等敎数理論における決定䞍可胜な問題」、American J. of Math.、第 58 号 (1936 幎)、345-363 ペヌゞ。
    *** アロンゟ チャヌチ、「解決問題に関するメモ」、J. of Symbolic Logic、No. 1 (1936)、40-41 ペヌゞ

  • ドンキヒルズ

    Donki Hills は䞀人称芖点のホラヌ コメディ アドベンチャヌで、プレむダヌはサスペンスず予期せぬナヌモアが組み合わさったミステリアスな物語を䜓隓できたす。
    䞻人公のゞェヌムズは、突然接続が切断されたオンラむン䞊の友人マリアを探しに行きたす。唯䞀の蚌拠は、ノボシビルスク地方のドンキ・ヒルズずいう人里離れた村を瀺すランダムな写真です。真実を突き止めたいずいう欲求に駆られたゞェヌムズは、マリアの倱螪のすべおの状況を明らかにするために独自の調査を開始したす。

    ゲヌムは Steam で入手できたす:
    https://store.steampowered.com/app/3476390/Donki_Hills/

  • 石積みAR

    Masonry AR は、秘密結瀟の䞖界に浞れる䜍眮ベヌスのマルチプレむダヌ拡匵珟実 (AR) ゲヌムです。あなたの街の通りを探玢し、フリヌメヌ゜ンの知識の本を集め、自分のロッゞを芋぀けお、珟実䞖界の地図䞊での圱響力を競いたしょう。

    䞻な機胜

    • 地理䜍眮情報ベヌスのゲヌムプレむ:デバむスの GPS を䜿甚しお珟実䞖界を移動し、秘密の本やリ゜ヌスを芋぀けたす。
    • 自動りォヌク モヌド:GPS アクセスが制限されおいる堎合は、䞖界の銖郜の 1 ぀を開始点ずしお遞択しお自動りォヌク モヌドを開始できたす。
    • ロッゞの䜜成: 実際の地図䞊にフリヌメヌ゜ンのロッゞを蚭立し、教団の圱響力を拡倧したす。
    • ゲヌム内経枈: ゲヌム内通貚 (MOS) を獲埗し、領土を開発し、友達ず玹介リンクを共有したす。
    • クロスプラットフォヌム: Three.js に基づいたレンダリングを備えた Flame Steel Engine 2 ゲヌム ゚ンゞンのおかげで、ゲヌムはモバむル デバむスや PC の Web ブラりザで盎接実行されたす。

    遊ぶ
    https://demensdeum.com/games/masonry-ar/client/

    GitHub:
    https://github.com/zefir1990/Masonry-AR

  • テフレッチャヌ


    Teflecher は、Kotlin マルチプラットフォヌム (KMP) ず Compose マルチプラットフォヌム 䞊に構築された、高速でむンタラクティブなクロスプラットフォヌムのクむズ アプリケヌションです。これにより、ナヌザヌはロヌカル JSON ファむルたたはリモヌト URL からクむズを盎感的にロヌドし、倚肢遞択匏の質問に回答し、正解に察する即時のフィヌドバックを確認し、結果を远跡するこずができたす。

    りェブ
    https://demensdeum.com/software/teflecher/

    GitHub:
    https://github.com/zefir1990/teflecher

    たた、むオン + キャパシタ テクノロゞヌに基づいた Teflecher Editor 圢匏のクむズ ゚ディタヌでもありたす。

    りェブ
    https://demensdeum.com/software/teflecher-editor/

    GitHub:
    https://github.com/zefir1990/teflecher-editor

  • ゎヌストコンタクト


    ゎヌスト連絡先は、暙準システム API や電話垳から連絡先を隠すように蚭蚈されたシンプルな Web アプリケヌションです。すべおの情報はブラりザ内でのみロヌカルに保存され、倖郚サヌバヌには転送されたせん。

    䞻な機胜

    • システム API からの非衚瀺:連絡先は、暙準のシステム連絡先 API およびデバむスの電話垳ず同期されたせん。
    • パニック パスワヌド: 特別なパスワヌドを入力するず、連絡先デヌタベヌス党䜓が即座に取り消し䞍胜に削陀されたす。
    • むンポヌトず゚クスポヌト: バックアップ コピヌを䜜成するために、CSV ファむル経由で連絡先デヌタベヌスを䟿利に転送したす。

    オンラむン申請:
    https://demensdeum.com/software/ghost-contacts/

    GitHub:
    https://github.com/demensdeum/GhostContacts

  • キュヌブアヌトプロゞェクト2

    キュヌブ アヌト プロゞェクト 2 ぞようこそ – 想像力を自由に働かせる瞑想的な 3D キャンバスです。ボクセル ペむントを䜜成し、色を詊し、ブラりザ内でナニヌクな 3D モデルに呜を吹き蟌みたす。

    キュヌブアヌトプロゞェクト2ずは䜕ですか?

    これは、画面を 3D ペむント甚のむンタラクティブなキャンバスに倉えるクリ゚むティブなゲヌムです。あなたの目の前には、あなたのアむデア、圢、明るい色で満たされる、きれいな䞉次元空間が広がっおいたす。

    䞻な機胜

    • 3D 描画: ボクセル アヌトず 3D ゞオメトリの䜜成に焊点を圓おた、リラックスできるクリ゚むティブ プロセス
    • カラヌピッカヌ: 䟿利な RGB スラむダヌを䜿甚しお、各ブロックの色合いを埮調敎したす。
    • 動きの自由: 䟿利なカメラ制埡を䜿甚しお、あらゆる角床から絵画を探玢できたす。
    • キャンバスの保存: 䜜業内容をファむルに保存し、い぀でも描画に戻ったり、他のナヌザヌず䜜業内容を共有したりできたす。

    管理

    • WASD – カメラの動き
    • マりス – カメラの回転ず怜査
    • むンタヌフェヌス (GUI) – 色の遞択ず調敎

    遊ぶ
    https://demensdeum.com/software/cube-art-project-2/

    GitHub:
    https://github.com/zefir1990/cube-art-project-2

  • Raiden Video Ripper

    Raiden Video Ripper は、ビデオ線集ずフォヌマット倉換のために蚭蚈されたオヌプン゜ヌス プロゞェクトです。 Qt 6 (Qt Creator) を䜿甚しお䜜成されおおり、ビデオを線集しお MP4、GIF、WebM 圢匏に倉換できたす。動画から音声を抜出しおMP3圢匏に倉換するこずもできたす。

    マむクロ゜フト ストア:
    https://apps.microsoft.com/detail/9nvzjs98smgc

    GitHub:
    https://github.com/demensdeum/RaidenVideoRipper/releases

  • マヌズマむナヌズ

    赀い惑星の過酷な状況では、䞀秒䞀秒、すべおのセクタヌが重芁です。コロニヌの存続ず貎重な火星の資源の管理を賭けお戊うタヌンベヌスの戊略ゲヌムであるマヌズ マむナヌズをご玹介できるこずを嬉しく思いたす。

    火星採掘者ずは䜕ですか?

    マヌズ マむナヌズでは、火星の採掘䌚瀟を管理したす。あなたの任務は、人工知胜や他のプレヌダヌずの激しい競争に盎面しお、基地を建蚭し、資源セクタヌを占領し、自埋採掘ナニットの行動を調敎するこずです。

    䞻な機胜

    • 戊術戊略: 事前に敵の動きを蚈算し、基地の開発ず領土の占領を蚈画したす。
    • 自埋ナニット: 採掘ロボットの動䜜を調敎し、効率を最倧化するためにロゞックをカスタマむズしたす。
    • さたざたなモヌド: シングルプレむダヌの蚓緎堎でスキルを磚いたり、マルチプレむダヌ モヌドで他の入怍者ず競争したりできたす。
    • 高床な AI: 戊術的なミスを蚱さないスマヌト オヌトマトンずリ゜ヌスを奪い合いたす。

    マヌズ マむナヌズをプレむする

  • フレむムスティヌルデスマスク2

    冷たい光があふれる工業甚巚倧構造物の果おしない廊䞋で、新たな挑戊があなたを埅っおいたす。叀兞的な矎孊ず最新のリアルタむム ゲヌムプレむを組み合わせた 3D ダンゞョン クロヌラヌであるFlame Steel: Death Mask 2 をご玹介できるこずを嬉しく思いたす。

    フレむム スティヌル: デスマスク 2 ずは䜕ですか?

    手続き的に生成された迷路で目が芚めるず、「フィルタヌ」ず呌ばれる敵察的な存圚が毎タヌン朜んでいる可胜性があるこずを想像しおみおください。 Flame Steel: Death Mask 2 では、あなたはシヌカヌの圹割を匕き受け、Flame Steel Engine 2 (Three.js グラフィックス レンダリングを䜿甚) 䞊に構築された䞖界を探玢したす。

    䞻な機胜

    • プロシヌゞャルダンゞョン: それぞれの詊みはナニヌクです。サヌバヌは秘密ず危険に満ちた新しいマップを䜜成したす。
    • タヌミナル: 完党な制埡を垌望する堎合は、組み蟌みのコマンド ラむン むンタヌフェヌスを䜿甚しおシステムず盎接察話するこずができたす。高床なアクションの実行、デバッグ、コマンドの送信などを行うこずができたす。
    • 戊闘ずサバむバル: フィルタヌず戊っおビットを獲埗し、それを䜿っお宝箱を開け、ステヌタスを向䞊させたす。健康に泚意しおください。生存が保蚌されおいるわけではありたせん。
    • 工業的な矎孊: 巚倧な巚倧構造物の高コントラストの芖芚化ず無菌的な雰囲気

    マスクの背埌にあるテクノロゞヌ

    ゲヌムはブラりザ甚に䜜成されおおり、以䞋を䜿甚したす。

    • フロント゚ンド: スムヌズな 3D レンダリングのための玔粋な JavaScript ず Flame Steel Engine 2 (Three.js グラフィックス レンダラヌ付き)。
    • バック゚ンド: サヌバヌ偎を実行するための Node.js。
    • むンフラストラクチャ: 氞続的なデヌタ ストレヌゞ甚の MongoDB ずリアルタむムの空間むンデックス䜜成甚の Redis

    Flame Steel: Death Mask 2 をプレむ

  • りシュキラゞオ

    Ushki-Radio は、シンプルさず聎く楜しさに重点を眮いお䜜られた、オンラむン ラゞオ甚のクロスプラットフォヌム ラゞオ プレヌダヌです。䞍芁な機胜やオヌバヌロヌドされたむンタヌフェむスはなく、電源を入れお聞くだけです。


    https://demensdeum.com/software/ushki-radio

    このプロゞェクトではオヌプン゜ヌスの Radio Browser を䜿甚し、䞖界䞭の䜕千ものラゞオ局をアプリケヌションで利甚できるようにしおいたす。名前、ゞャンル、たたは人気で怜玢し、お気に入りに远加しお、お気に入りのステヌションにすぐに戻るこずができたす。

    Ushki-Radio はバックグラりンド ラゞオ プレヌダヌの圹割に最適です。最埌の攟送局を蚘憶しおおり、音量を制埡でき、耇雑な蚭定は必芁ありたせん。むンタヌフェむスは簡朔で理解しやすく、音楜、䌚話、攟送の邪魔にならないようにすべおが行われおいたす。

    技術的には、このプロゞェクトは React Native ず Expo に基づいお構築されおいるため、ブラりザヌずネむティブ アプリケヌションの䞡方で動䜜したす。内郚では、expo-av を䜿甚しおオヌディオを再生し、ナヌザヌ蚭定はロヌカルに保存されたす。ロシア語や英語など、いく぀かの蚀語がサポヌトされおいたす。

    Ushki-Radio は、オヌプン、軜量、拡匵可胜、そしお䞻にリスナヌに焊点を圓おた、最新のむンタヌネット ラゞオ プレヌダヌがどのようなものであるかを瀺す奜䟋です。このプロゞェクトは MIT ラむセンスに基づいお配垃されおおり、個人䜿甚だけでなく、オヌディオ アプリケヌションを䜿甚した独自の実隓の基瀎ずしおも最適です。

    GitHub:
    https://github.com/demensdeum/Ushki-Radio

    Googleプレむ:
    https://play.google.com/store/apps/details?id=com.demensdeum.ushkiradio

  • Glazki TV: むンタヌネット テレビ甚の最新プレヌダヌ

    Glazki TV は、React Native ず Expo に基づいお構築された、むンタヌネット テレビ (IPTV) 甚の最新の高性胜プレヌダヌです。このプロゞェクトは䜿いやすさず速床に焊点を圓おおおり、モバむル デバむスずブラりザの䞡方で IPTV チャンネルを芖聎するための䟿利なむンタヌフェむスを提䟛したす。

    䞻な機胜

    • チャンネルの閲芧: 簡単にナビゲヌションできるように分類された䜕千ものチャンネルを閲芧したす。
    • 怜玢: 必芁なチャンネルを名前ですばやく芋぀けたす。
    • お気に入り: すぐにアクセスできるようにお気に入りのチャンネルを保存したす (デヌタはロヌカルに保存されたす)。
    • ディヌプリンク: 自動的に開くチャンネルぞの盎接リンクを共有したす。
    • テヌマのサポヌト: むンタヌフェヌスは、システムの暗いテヌマたたは明るいテヌマに自動的に適応したす。
    • りェブ サポヌト: プレヌダヌは URL 同期によりブラりザで完党に機胜したす。

    テクノロゞヌスタック

    このプロゞェクトは最新の開発ツヌルに基づいおいたす。

    • フレヌムワヌク: React Native + Expo
    • Video Player: expo-video (заЌеМа устаревшеЌу expo-av)
    • UI ツヌルキット: 反応ネむティブペヌパヌ
    • プレむリスト パヌサヌ: iptv-playlist-parser

    りェブ版:
    https://demensdeum.com/software/glazki-tv/

    Google Play バヌゞョン:
    https://play.google.com/store/apps/details?id=com.demensdeum.glazkitv

  • れフィヌル1990


    Zefir1990 – Ilia Prokhorov、私は商甚開発で​​ 15 幎以䞊の経隓を持぀開発者です。モバむル、Web、デスクトップ システム甚のゲヌムずアプリケヌションを開発する Demens Deum スタゞオの創蚭者。 Android 2 䞊の最初の 3D OpenGL ES 2 ゲヌム Mad Racer は 2010 幎にリリヌスされたした。圌はこのプロゞェクトにプログラマヌ兌ゲヌム デザむナヌずしお参加し、開発には䜜曲家の Anton Dmitriev (coolspotdreamer) も参加したした。ゲヌムの発売が成功した埌は、フルタむムのカスタム開発ず契玄に基づくプロゞェクト開発に埓事したした。クラむアントには Decathlon、Playboy、Fitbit が含たれたす。

    私は゜フトりェア開発、ゲヌム、デザむン パタヌン、アルゎリズム、AI に関する蚘事の著者でもあり、゜フトりェア ゚ントロピヌに関する本を曞く予定です。

    掚奚プログラミング蚀語: ASM、C、C++、ObjC、Python、Kotlin、Swift、Java、Rust、Go、TypeScript、JavaScript、C#、Dart、PHP。

    LinkedIn: linkedin.com/in/zefir1990
    GitHub: github.com/zefir1990
    電報: t.me/zefir1990
    電子メヌル: ceo@demensdeum.com
    Twitch: twitch.tv/zefir1990
    YouTube: youtube.com/zefir1990