電装工芸日記
- 舞台照明機器の製作とか -
タグ「Ｃ言語」を含む投稿［64件］（2ページ目）
プロセス間通信を大別しますと、SharedMemory(mmap含む)、Pipe、Queueです。左から「速いけど扱いが難しい」→「扱いが簡単だけど遅い」となるようです。
SharedMemoryは初期定義でメモリサイズを指定しなければなりませんが、型の指定は無く、ポインタを使った変数アクセスの要領で使えます。メモリサイズが最初から固定されるので実質的には型が決まった変数となりますが、読み出してもデータが残ることが特性でしょうか。
PipeはマネージされないQueueと思って捉えています。FIFOみたいな挙動で単純な受け渡しをする一時スタックです。
QueueはPipeが高度にマネージされFIFOまたはLIFOとして機能するイメージです。遅いのが難点ですが、速度を求めないなら便利な手段です。
SharedMemoryとPipeはどちらが速いか論争があるようですが、消さなければ残るメモリーと読みだしたら消える一時スタックというそもそもの違いがある上に、転送速度は誤差レベルの違いしか無いように思われますので、用途に合わせて使い分けるだけかなと・・・。
ネットの情報にも教科書にも、これらの違いを一覧してくれる情報がほとんどありません。関数のパラメータや動作特性などのそもそもの説明がなく、どれが速いか遅いかって比較があればましな方です。コピペの様なソースコードに「俺ってスゲーと思わね？」って感じの斜め上の応用を加えたコードが書かれている物ばかり。説明をしてくれる気持ちはありがたいのだけど、中途半端な応用に本筋が埋もれたサンプルコードを誰が喜ぶのかと疑問を感じたりしています。大変勝手な言い方ですが、検索結果が無駄に多くなって分かりやすい情報が埋もれてしまいますので、ガチのプロは見向きもしない、初心者には伝わらない、そんな「俺スゲーでしょ解説」はお控え願いたいものです。斜め上の応用は書く人それぞれのクセであって一般論とは言い難いのですし。
上記はネット検索で迷宮を彷徨ってしまった思いからの愚痴です。わかってんなら書けよとか言われそうですが、人に教えられる程習得出来たら是非書きたいものです。
#Ｃ言語
SharedMemoryは初期定義でメモリサイズを指定しなければなりませんが、型の指定は無く、ポインタを使った変数アクセスの要領で使えます。メモリサイズが最初から固定されるので実質的には型が決まった変数となりますが、読み出してもデータが残ることが特性でしょうか。
PipeはマネージされないQueueと思って捉えています。FIFOみたいな挙動で単純な受け渡しをする一時スタックです。
QueueはPipeが高度にマネージされFIFOまたはLIFOとして機能するイメージです。遅いのが難点ですが、速度を求めないなら便利な手段です。
SharedMemoryとPipeはどちらが速いか論争があるようですが、消さなければ残るメモリーと読みだしたら消える一時スタックというそもそもの違いがある上に、転送速度は誤差レベルの違いしか無いように思われますので、用途に合わせて使い分けるだけかなと・・・。
ネットの情報にも教科書にも、これらの違いを一覧してくれる情報がほとんどありません。関数のパラメータや動作特性などのそもそもの説明がなく、どれが速いか遅いかって比較があればましな方です。コピペの様なソースコードに「俺ってスゲーと思わね？」って感じの斜め上の応用を加えたコードが書かれている物ばかり。説明をしてくれる気持ちはありがたいのだけど、中途半端な応用に本筋が埋もれたサンプルコードを誰が喜ぶのかと疑問を感じたりしています。大変勝手な言い方ですが、検索結果が無駄に多くなって分かりやすい情報が埋もれてしまいますので、ガチのプロは見向きもしない、初心者には伝わらない、そんな「俺スゲーでしょ解説」はお控え願いたいものです。斜め上の応用は書く人それぞれのクセであって一般論とは言い難いのですし。
上記はネット検索で迷宮を彷徨ってしまった思いからの愚痴です。わかってんなら書けよとか言われそうですが、人に教えられる程習得出来たら是非書きたいものです。
#Ｃ言語
ホール管理の増員で置きダヌキ。
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは４コアありますが手続き型処理はもちろんマルチスレッドでも１コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはＯＳ次第とはいえプロセスを分散しておけば１コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#Ｃ言語 #[Art-Net]
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは４コアありますが手続き型処理はもちろんマルチスレッドでも１コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはＯＳ次第とはいえプロセスを分散しておけば１コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#Ｃ言語 #[Art-Net]
先週末は現場が被りまくりでオロオロしてましたが、今週は比較的ヒマなので少しはネタを進められそうです。
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#Ｃ言語 #[Art-Net]
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#Ｃ言語 #[Art-Net]
共有メモリの読み書きのタイミングを考えています。
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は１プロセスで動作します。RaspberryPiでも１プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#Ｃ言語
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は１プロセスで動作します。RaspberryPiでも１プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#Ｃ言語
「error: Unable to find vcvarsall.bat」とのエラーで困ったものの解決しました。
以下、オレメモであります。
あえて gcc を使うのは Linux で標準だからです。
VSCode で gcc を使う
2023年9月10日実施
● OS
エディション: Windows11 Pro x64
バージョン: 21H2
● Visual Studio Code
バージョン: 1.74.2 (user setup)
※ ダウンロード量が 1.8GB くらいあるのでネット回線が良好な環境での作業を推奨します。
● gcc をインストールする
・gcc を GitHub からダウンロード
https://github.com/niXman/mingw-builds-b...
「Release of 13.1.0-rt_v11-rev1」の項から Windows64bit版
ダウンロード項目: x86_64-13.1.0-release-win32-seh-msvcrt-rt_v11-rev1.7z
・圧縮ファイルなので解凍する。.7z ファイルは CubeICE で解凍可能。「mingw64」フォルダが出来る。
・「mingw64」フォルダごと任意の位置に配置する。"C:\Program Files"が適当？」
・PATH を通しておく。環境変数のPATHに「mingw64\bin」を追加する。今回は"C:\Program Files\mingw64\bin"とする。
「Windowsメニュー」→「設定」→「システム」→「バージョン情報」
→「関連リンク」の行の「システムの詳細設定」をクリック。
→ ウィンドウ下の方の「環境変数」をクリック。
→ 上段のリスト、PATHの行をクリックし、「編集」をクリック。
→ 表示されたリストに"C:\Program Files\mingw64\bin"を追記する。
→ 追記したら閉じる。
・確認
コマンドプロンプトか Power Shell で次を実行
> gcc -v
もろもろ表示された最後に以下が表示されればOK。
gcc version 13.1.0 (x86_64-win32-seh-rev1, Built by MinGW-Builds project)
● Microsoft C++ Build Tools をインストールする
・microsoft のサイトよりインストーラーをダウンロード
https://visualstudio.microsoft.com/ja/vi...
※「Microsoft C++ Build Tools」で検索しても上記 URL に行きつかない。試行錯誤中、偶然行きついた。
・ブラウザの「Build Tools のダウンロード」をクリックすると「vs_BuildTools.exe」がダウンロードされる
・ダウンロードしたインストーラーを起動する。
・「Visual Studio Installer」と画面が出てファイルのダウンロードが始まる。
・画面が切り替わり、右項目「インストールの詳細」に「MSBuild Tools」が表示されているの確認。
・左項目「C++によるデスクトップ開発」をクリック。右項目「インストールの詳細」に追加されているのを確認。オプションはデフォストのまま。
・右下の「インストール」をクリック。終わるまで待つ。ダウンロード量が 1.7GB ある。かなり時間がかかる。
・終了したら Windows を再起動する。
● VSCode の設定・・・拡張機能をインストール
・C/C++ Extension Pack
・Code Runner
● VSCode の設定・・・拡張機能の設定
・Code Runner
Code-runner: Run In Terminal
→ チェックを入れる
Code-runner: Executor Map
→ settings.json をクリック
→ "c" に -fexec-charset=CP932 を書き加える
- "c" : "cd $dir && gcc $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
+ "c" : "cd $dir && gcc -fexec-charset=CP932 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
次のサイトの例題がコンパイル出来、Python からの呼び出しで動作しました。
「PythonからC言語の関数を呼び出す（基本編）」
Ｃ/Ｃ＋＋のライブラリを Python で呼び出せると製作の幅が広がります。
手始めにしては難しい課題ですが、DoctorMX を Python から使えるようにしてみたいですね。
#Ｃ言語 #Python
以下、オレメモであります。
あえて gcc を使うのは Linux で標準だからです。
VSCode で gcc を使う
2023年9月10日実施
● OS
エディション: Windows11 Pro x64
バージョン: 21H2
● Visual Studio Code
バージョン: 1.74.2 (user setup)
※ ダウンロード量が 1.8GB くらいあるのでネット回線が良好な環境での作業を推奨します。
● gcc をインストールする
・gcc を GitHub からダウンロード
https://github.com/niXman/mingw-builds-b...
「Release of 13.1.0-rt_v11-rev1」の項から Windows64bit版
ダウンロード項目: x86_64-13.1.0-release-win32-seh-msvcrt-rt_v11-rev1.7z
・圧縮ファイルなので解凍する。.7z ファイルは CubeICE で解凍可能。「mingw64」フォルダが出来る。
・「mingw64」フォルダごと任意の位置に配置する。"C:\Program Files"が適当？」
・PATH を通しておく。環境変数のPATHに「mingw64\bin」を追加する。今回は"C:\Program Files\mingw64\bin"とする。
「Windowsメニュー」→「設定」→「システム」→「バージョン情報」
→「関連リンク」の行の「システムの詳細設定」をクリック。
→ ウィンドウ下の方の「環境変数」をクリック。
→ 上段のリスト、PATHの行をクリックし、「編集」をクリック。
→ 表示されたリストに"C:\Program Files\mingw64\bin"を追記する。
→ 追記したら閉じる。
・確認
コマンドプロンプトか Power Shell で次を実行
> gcc -v
もろもろ表示された最後に以下が表示されればOK。
gcc version 13.1.0 (x86_64-win32-seh-rev1, Built by MinGW-Builds project)
● Microsoft C++ Build Tools をインストールする
・microsoft のサイトよりインストーラーをダウンロード
https://visualstudio.microsoft.com/ja/vi...
※「Microsoft C++ Build Tools」で検索しても上記 URL に行きつかない。試行錯誤中、偶然行きついた。
・ブラウザの「Build Tools のダウンロード」をクリックすると「vs_BuildTools.exe」がダウンロードされる
・ダウンロードしたインストーラーを起動する。
・「Visual Studio Installer」と画面が出てファイルのダウンロードが始まる。
・画面が切り替わり、右項目「インストールの詳細」に「MSBuild Tools」が表示されているの確認。
・左項目「C++によるデスクトップ開発」をクリック。右項目「インストールの詳細」に追加されているのを確認。オプションはデフォストのまま。
・右下の「インストール」をクリック。終わるまで待つ。ダウンロード量が 1.7GB ある。かなり時間がかかる。
・終了したら Windows を再起動する。
● VSCode の設定・・・拡張機能をインストール
・C/C++ Extension Pack
・Code Runner
● VSCode の設定・・・拡張機能の設定
・Code Runner
Code-runner: Run In Terminal
→ チェックを入れる
Code-runner: Executor Map
→ settings.json をクリック
→ "c" に -fexec-charset=CP932 を書き加える
- "c" : "cd $dir && gcc $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
+ "c" : "cd $dir && gcc -fexec-charset=CP932 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
次のサイトの例題がコンパイル出来、Python からの呼び出しで動作しました。
「PythonからC言語の関数を呼び出す（基本編）」
Ｃ/Ｃ＋＋のライブラリを Python で呼び出せると製作の幅が広がります。
手始めにしては難しい課題ですが、DoctorMX を Python から使えるようにしてみたいですね。
#Ｃ言語 #Python
「Open DMX USB」について考えていたのは移動中アタマが空いていたからです。
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
今回の LTC Player と LTC Generator のパソコン側のシステムは全て Python で書いています。
その過程でオブジェクト指向を世に出した先達の気持ちを垣間見ることができたワケですが、そうなるとＣ言語でやってきたこともＣ＋＋にしてみたくなる。時間と脳味噌に空きが無くて１年近く止まっている Art-Net の パッチマシン も完成させたい気持ちがあるのですが、Ｃ＋＋で書いたらスマートに書けそうな気がしてきています。
Ｃ＋＋と言っても ANSI の Ｃ言語にオブジェクト指向を追加して書きやすくしたモノとしか思えませんし、実際、ANSI の Ｃ言語の記述やライブラリが混在しても大半が動きます。記述の違いは少なくありませんが、標準語に対する津軽弁や鹿児島弁の違いより容易いと思われます。
ただ、Art-Netパッチはデータベースや財務系の処理をするとの近い気がしますので、SQL や COBOL を勉強しておくと参考になりそうな気もします。これらは群のデータを扱うことに特化していますからね。Ｃ言語で SQL を扱うのは敷居が高そうですし、この時代 COBOL の情報を探すのは無理がありそうですから、Python で SQL を扱う勉強を少ししようと思います。
#Ｃ言語
その過程でオブジェクト指向を世に出した先達の気持ちを垣間見ることができたワケですが、そうなるとＣ言語でやってきたこともＣ＋＋にしてみたくなる。時間と脳味噌に空きが無くて１年近く止まっている Art-Net の パッチマシン も完成させたい気持ちがあるのですが、Ｃ＋＋で書いたらスマートに書けそうな気がしてきています。
Ｃ＋＋と言っても ANSI の Ｃ言語にオブジェクト指向を追加して書きやすくしたモノとしか思えませんし、実際、ANSI の Ｃ言語の記述やライブラリが混在しても大半が動きます。記述の違いは少なくありませんが、標準語に対する津軽弁や鹿児島弁の違いより容易いと思われます。
ただ、Art-Netパッチはデータベースや財務系の処理をするとの近い気がしますので、SQL や COBOL を勉強しておくと参考になりそうな気もします。これらは群のデータを扱うことに特化していますからね。Ｃ言語で SQL を扱うのは敷居が高そうですし、この時代 COBOL の情報を探すのは無理がありそうですから、Python で SQL を扱う勉強を少ししようと思います。
#Ｃ言語
ホール管理の増員で操作盤の置物になっているだけなので調べモノをし放題です。
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python