C/C++のテストハーネス

  • CppUTestとUnity
    • https://github.com/cpputest/cpputest
    • https://github.com/ThrowTheSwitch/Unity
    • どちらも似たような雰囲気。
    • それなりのコミット。
    • Googleのような後ろ盾がないなかではよくやっていると思う。
    • Unityは…スローザスイッチってなんやねんという気持ち悪さがある（コミュニティ主導じゃないの？）
    • CppUTestは…未解決のIssuesが多い印象
    • 総じてどちらもこなれており、実用に堪えるだろうと判断。
  • Google Test
    • https://github.com/google/googletest
    • さすがGoogleの後ろ盾といったところ。
    • Star数やコミット頻度も申し分ない。
    • だがCMake好きな感じが抵抗ある。
    • 多分、それが一番簡単な導入法なんだろうけど、そういう方便なんだろうけど、ちょっと嫌な感じ。

CppUTestとUnityを触ってみて、使い勝手の良い方をしばらく使ってみようと思う。
この2つがどうしても嫌な感じだったら、Google Testを使う。

TDD

TDDをやりたくなった。

しかもC/C++で…。

C/C++のテストフレームワークがそもそも少ない。

とりあえずGoogleTestを触ってみた。

なんとCMakeが必要らしい。そんなことある？

https://google.github.io/googletest/quickstart-cmake.html

はまったところ

  • テストケースは.cppにする
    • 同様に、Cをincludeするときはextern "C"が必要

サウンドプログラミング2021-05-05

昨日の書き残し

  • リアルタイムで速度を変化させる
    • ひとまずwaveを全部メモリに置いてループ再生する
    • キーボードの左右で速さを変える
  • 逆再生もできる
  • コールバックごとに再生速度を変えればいけそう
  • リサンプリング検討
    • 直前のやつではよくない。平均をとる

さて

要はDJっぽいことをやってみたいすね

やったこと

サウンドプログラミング2021-05-04

サウンドプログラミングをやってみる。

前提

いろいろ簡単にやりたいのでPythonで。

環境

  • Python 3.9
  • python-sounddevice & python-soundfile
    • pyAudioという選択肢もあったが、waveファイルのオープンにPython標準モジュールを使っている＆それがWAVE_FORMAT_IEEE_FLOATに対応しておらず苦しすぎたのでやめた

やったこと

サンプルを触る

python-sounddevice.readthedocs.io

  • Play a Sound File
    • 天才。ndarrayを渡して秒で終わり
  • Play a Very Long Sound File
    • 天才。コールバック形式もお手のもの
  • Play a Sine Signal
    • 天才。パラメーターで周波数設定できる優しさも好き

スロー再生

  • Play a Sound Fileをいじった
    • 元々のdataの倍の長さのarrayを作る。それをlongfileとする
    • longfileにdataを重複させながら入れる
      • 0,0,1,1,2,2,3,3,4,4, ...みたいに
    • 再生すると半分の速度になる
    # こうなっていたものを
    data, fs = sf.read(args.filename, dtype='float32')
    sd.play(data, fs, device=args.device)

    # こうした
    data, fs = sf.read(args.filename, dtype='float32')
    # expand start
    longdata = np.empty( (len(data)*2, 2), dtype='float32')
    for i, d in enumerate(data):
        longdata[2*i] = d
        longdata[2*i + 1] = d
    # expand end
    # sd.play(data, fs, device=args.device)
    sd.play(longdata, fs, device=args.device)

簡単だ。もっとクレバーな方法がありそうだがまあいいだろう。

さて次にやりたいことは…と固まってしまった。ソシャゲみたいに次やることが明確だったら楽なのに。
逆に考えると、次にやることをあらかじめ用意しておかないと、人間って動けないんだなと感じた。
ソシャゲの遊ばせ方はうまい。それを自分のやりたいことに応用できれば。

さて、明日やりたいこと

  • リアルタイムで速度を変化させる
    • ひとまずwaveを全部メモリに置いてループ再生する
    • キーボードの左右で速さを変える
  • 逆再生もできる
  • コールバックごとに再生速度を変えればいけそう
  • リサンプリング検討
    • 直前のやつではよくない。平均をとる

Angband

久しぶりにローグライクをやりたくなって、macOSにAngbandをインストールした。

https://rephial.org

操作を全然忘れていた。
hjklを押したらなんだそれ'?'でヘルプ見ろと言われたので見る。
えっなんで移動じゃないの。
ひとまずヘルプを見た…。
なんとOriginal KeysetとRoguelike Keysetに分かれていた。Originalはhjklでない。デフォルトがOriginalということか〜
キャラ作成ごとにキーセットの設定をチクチク直していくだろう…。

というわけで設定の'='を覚える。

このゲームは操作面でも指になじませる必要がある。
変な操作のクセをつけたくないので、極力vanillaでやろうと思う。

最初、一般人を見かけたのでぶつかっていったら殴ってしまった。申し訳ない。
証拠隠滅に頃してしまおうかと思ったが、瀕死になったら逃げていったのでやめた。

次に店へ。
そういや英語なんだよなと真剣に気づく。
まあ、英語の勉強がてらじっくり読んでいこう。
そう、店のものがさっぱりわからない。どうやって説明を見るんだ？

売り物の説明を見るのは'x'。
自分が持っているアイテムの一覧を見るには'i'。

結構読んだ。単語が凝っている感じがする。あとつるはしの説明が秀逸だと思った。こうやって英語で物の形を説明するんだなって。

結局後述のクラッシュで最初のデータは飛んでしまった。
萎えたので今日のところは終了。

hjklはviなので大丈夫だが、yubnがなじまない。
はやく慣れて冒険したいな。

面白かった英語

  • administer
    • 投与する、治療を施す
  • Rations of Foodの説明
    • This nutritious but fairly bland food, called cram by the Lake-men who make it is familiar to anyone contemplating long journeys.
      • Google翻訳: この栄養価が高いがかなり味気ない食べ物は、湖の男たちによってクラムと呼ばれ、長い旅を考えている人にはなじみがあります。
  • Pickの説明
    • A heavy mining tool with a long, slightly curved head that tapers to chisel points on both ends.

macOS版で起きていること

  • Subwindow setupでDisplay player (extra)をやると落ちる
  • 起動するたび、Termの各ウィンドウがタブで1枚になってしまう
    • OSの「書類を開くときはタブで開く」を「常に」以外にする

WebGLとEmscripten（とオーディオ）

WebGLとEmscripten

今日の調べ物は、WebGLとEmscriptenについて。
今日最初に見たこの記事が真理だったようだ。

https://emscripten.org/docs/porting/multimedia_and_graphics/OpenGL-support.html

ここからリンクされている、
https://github.com/emscripten-core/emscripten/tree/master/tests/glbook

このglbookテストコードが素晴らしい。Web上で他のプラットフォームとほとんど同じコードが動く。
Webで動くことを想定したCを書けるということだ。
幻想かもしれない。本当はもっとWeb専用処理とかで地獄を見るのかもしれないが、今は喜んでおく。今のところの理想的な環境だ。

この記事と同列にEGLの記述があったので見てみたが、これは微妙っぽい。対応プラットフォームがAndroidしかないみたい？ひとまず自分の環境（macOSのブラウザ）で動かす分には考えなくていいだろう。

次のアクションはどうしよう？glbookのテストコードを動かしてみる？

Emscriptenとオーディオ

ついでにAudioのページも見てみた。

https://emscripten.org/docs/porting/Audio.html

はあ…すごい。OpenALで書けるんだ。Web Audioをバックエンドとして動くと。

考えを改める

いや驚いた。
失礼な話、今までEmscriptenに不信感があった。ちゃんと動くのとか、内部実装はボロボロなんじゃないとか。でもいまバックグラウンドを調べていてそれが払拭されつつある。テストコードがいーっぱいあるのも見た。
これは本気で使ってみる価値のあるプラットフォームなんじゃないかと感じ始めている。

早速実際に動かしてみたいけど、まずはデバッグがらみのツールチェーンを知りたい。
デバッガとかブレークポイント貼れたりするのか？絶対無理だと思うんだが。できたら感動。

あとはテスト。どうやるんだろうね？Cに対してかけるのか？それともコンパイル後のバイナリをブラウザ上でテストできるのか？

今日はこんなところで。

Webでネイティブ + 日記

Webでネイティブコードが動くしくみを見てみたくなった。
まずはどんな技術があるのか調べてみる。
雑調査なのであんま信じないでね。そこんとこよろしく！

Cのコードをブラウザ上で動かすしくみとしては、自分は以下2つを知っている。

しかし、違いはさっぱりわからない。
あとは、WebGLというものも気になる。これはOpenGLなのか？Cで動くのか？

Emscripten

要は、C/C++ → LLVMビットコード → WebAssemblyをやるコンパイラだと。
以前は最終成果物がasm.jsだったらしいが、どこかのタイミングでWebAssemblyになったようだ。

WebAssemblyとasm.js

ちょっと脱線して、これらの違いについて。
どちらもEmscriptenの成果物となる、ブラウザ上で動くコードを出力するしくみだ。
歴史が古いのはasm.js。出力コードを見てみるとただのJavaScriptに何やらメモリ操作のしくみがついただけの代物に見える。この感想、偉い人から見たらひどい侮辱をしていると思う…まあ知らんけど。とにかくJavaScriptそのものでロジックを実現しているようだ。
それに対してWebAssemblyはバイナリを出力する。本当にパフォーマンスを気にしてバイナリ化しているようだ。ということはブラウザ側にWebAssemblyインタプリタとかランタイムを持っているんだと思う。
実行速度はWebAssemblyが有利、と。

なんとなく、すでにasm.jsはほとんどWebAssemblyに置き換えられている感じがする。
asm.jsの優位性は古いブラウザで動くことか？まんまJSだし。あとはCのロジックとJavaScriptの同時実行みたいなことができるのかもしれない。だがそんなのいかにも面倒そう。極力したくはない…。
いまはひとまずasm.jsのことは忘れることにする。

Emscriptenに戻って

閑話休題。
とにかくEmscriptenはC/C++ → LLVMビットコード → WebAssemblyだと。
前者の矢印はEmscriptenに限ったことじゃないので放っておくとする。
後半はなにやらfastcompだのBinaryenというものを使っているらしい。ふーん。さっぱりわからん。
今日はこのくらいでいいや。

WebGL

WebGLはOpenGLそのものではない。
各種3DCG APIのラッパーのようだ。確かにブラウザの下のハードウェアを使うんだし納得だ。だいたいは本当にOpenGLだのESを使っているが、WindowsだとDirectX 11なのだと。へー。

実装はJavaScriptでやるみたい。JavaScriptのAPIとGLSLかな。
描画先はcanvas。
サンプルコードを見ると簡潔にまとまっている。OpenGLをやる以前にウィンドウを出すのが面倒という時代は過去か。今3DCGをやるならWebGLが楽かもな。

おまけ: JavaScriptで知ったこと

そういえば、WebGLのサンプルコードを見てquerySelectorというものを知った。

これってjQueryでやってる楽ちん構文そのものじゃね？あれ？これ使っていればjQueryいらないんじゃね？とも思ったがそんなに簡単じゃないかね。
今もjQueryってデファクト的な、とりあえず入れておけみたいなライブラリなのかな？今はブラウザ側もいよいよ機能強化されてきて、いらなくなってるのではないかと思っているんだけど。

そうそう自分こんな感じなんだよね。5年前くらいの知識で止まってる。
今はトランスパイル当たり前の時代かな。そういったところも知っておきたいな。

もう一言

Twitterでこんな記事を見かけた。

https://note.com/rewritethestar/n/n1d8b989b267a

毎週3000文字だって。つれえ。と思ったら、この記事3000文字超えてた。
まあURLで相当字数稼いでるけど…。
本気でしっかり論理立てて、自分の言葉だけで書いたら大変なんだろうな。
3000字ってどんなもんなんだろう。大学入試の小論文でどんくらい書いただろうか。文章を書くときに文字数を意識することなんてないからさっぱり想像できない。
こういうこと伝えるのなら何千文字くらい必要だな、なんてぱっと出てきたらかっこいいな。「伝える力」に自信を持っている感じ。

要を外さず簡潔にわかりやすく書く力を鍛えたい。テクニカルライティング的な。
文章って好きなんだ。音声とか動画より、情報量をものすごく小さくできるから。
ただでさえこういったアドバンテージがある文章を、さらに磨いて綺麗にしたい。いろんな人に伝わりやすくする工夫を、文章の側から極めたい。

どっちかっていうと、自然言語が好きなのかもな。