_ 体調が、すさまじく悪いというほどではないがよくない。日中だるい。 たまらず昼休みに横になったりすると夜眠れない。 雨がちなので運動もできない…と悪循環だ。雨はしばらく続くらしい。 水曜あたりから湿度は高いものの気温もさほど上がらず日差しもないので、 夜は扇風機だけで十分眠れるようになっている…が、体調が上向きになることもない
_ OpenTKはひと休みして、GL.ReadPixelsでとってきた データを動画化する試行をしてみた。ffmpegやlibavcodecに絡んだ モジュールはいくつか見つかった。ひとまず FFMediaToolkitを 使っている。他にあったものは、ドキュメント (どれもあまりない) や サンプルを眺めつつ、モジュールのソースを流してみたところ、 FFmpeg.NETは、 ffmpeg.exe のフロントエンドにしか見えない。 FFMpegCoreは、 Input pipingというものが使えそうだ。まだ試してないけど。 Xabe.FFmpegは商用と フリーのデュアルライセンスらしい。 商用で使う気はないしフリー版でも機能制限があるわけではないようだけど、 ひとまずあとまわしにしている。
_ といった調査の末まずFFMediaToolkitを使ってみる。いくつか不審な点があるものの うまく動画を作ることができるようになった。 MediaBuilder.CreateContainer に与えるパスがフルパスじゃないと ArgumentExceptionが出るように作られている。目的が不明だ。 あとCodecが、libavcodecの中にある AVCodecID より随分少ない。 alphaチャンネルつきの、AV_CODEC_ID_PRORES、AV_CODEC_ID_QTRLE、 AV_CODEC_ID_UTVIDEO などなどが相当するらしいのだが、 そういったものが存在しない。
_ それとこれはライブラリ側ではなくF#と私の理解力側の問題なのだが、 FFMediaToolkit.Graphics.ImageData をクラス内のフィールドとして持とうとして うまくいかない。ImageDataはC#側で ref struct として定義されており、 これがなにやら気に入らないらしい。 FS0412、FS0437 といったエラーが。 私が直面している問題と同じなのか、 それらがどう解決されている/されようとしているのかよくわからんものの、
_ あと、今のところ実害はないが内部でSystem.Drawingに依存しているというのが 少々ひっかかる。現在触っている範囲ではSizeくらいしか使っているものが なさそうに見えるし、Linuxの.NET 5で普通に使えているので問題ないが…
_ 寝て起きてあらためて ref structの説明 を読んでみたら、 ref structというのはそういうもんだった。私ができないと騒いでいたものは ref structなら当然という話なので、とても恥ずかしい。
_ 先日書いた関数型言語らしい ゲームアプリの構造とは？ みたいな話を追ってゆく中で、 FRPがまさにきみの求めるものだ的なことを書いているのを複数箇所で目撃した。 米国の中央銀行みたいなやつではない…とボケようと思ったらあっちはFRBだった。 強化プラスチックでもない。 と、滑った上にボケを重ねる強メンタルを発揮した上であらためて探してみたところ、 Functional Reactive Programmingのことを言っているらしい。 ふむふむ… (ピンと来ていない) このキーワードで出てくるページ・スライドや論文を たくさん読もう
_ Elmは、 関数型言語を中心としたプログラミングパラダイムをいろいろ模索しているように 見える (もちろんF#でもやっているけど)。MVUなんかもElm発祥らしいし、 きちんと学習して追いかけるようにできたほうがいいのかしら？ と思う。 ただWebに載せたいということだと、 Fableの出来がよいのでそっちを使うことになるかしら… なおそんなElmはFRPとはお別れしたらしい
_ いろいろ問題は残っていつつも動画をとる算段もついてきたので、 OpenTKの方を進めることにした。第一歩としてiconちゃんを表示して動かす 伝統芸能testspriteをやるべき時が来たことを感じた。
_ ひとまず正射影のProjectionにして、画面の真中に表示する。 元々の座標系と上下逆なのでさかさまに… このあたりどう統一するのがいいのだろうか。ひとまずテクスチャ座標を ひっくりかえしておく。
_ そして抜き色ができていない。 まずSkiaSharpでカラーキーをどうすればいいのか？という問題がある。 そのための機能が存在するのかどうか、 あれこれ探してみたけど見当たらなかったので、SKBitmapの中の ピクセルを1つずつ見てカラーキーと一致したらアルファを0にする…という なんともみっともない方法になってしまった。そしてそのように できあがったテクスチャを貼り付けてみたところなんか透けてない。 テクスチャにする直前のSKBitmapをpngに落として見てみたら、 カラーキーのところがちゃんと透過になっているのだけど… で、今でもglEnable(GL_BLEND) とかが必要であることを知る。 ひとまず1こだけだがiconちゃんがカラーキー有効な状態で画面中心に 置かれるようになった。よかったよかった。
_ よかったのでiconちゃんを複数表示させてみた。iconちゃんのサイズを 後から手に入れようとして実はuseで解放されてしまっていた…みたいな しょうもないミスをしてしまっていた。ObjectDisposedExceptionが 出ていたのだろうとは思うのだけどそういった内容が表示されずに黙って 即死していたのはなんでかな… いろいろ構造は見直す余地はあるものの、 もともとのLearnOpenTKとtestspriteを合成して表示できるようになったので 思わず動画を 上げてしまった。これまでFreeMindの動画しか上げてなかったので11年ぶりの 動画だ…それがこれかという感じがするしawesomeface.pngが神経を逆撫でする えらい動画になってしまった
_ 久しぶりに雨が降らない一日だった。気温はそんなに高くないはずなのに 蒸し暑い。
_ 冷蔵庫を移動した。事務所でこれまで使っていた SJ-D14B-W (pdf) を住居スペースへ。 137Lらしいので、先日事務所に導入したもの (350L) は2.5倍の 容積があることになる。
_ 移動にあたり台車が必要なのだがどうしたもんか… 2〜3日のレンタルで3000円という感じらしいのだが、同じくらいの金額で 安いものなら買えることが分かったので3000円弱のものを購入した。 滑車部分は自分でとりつける必要があるらしい。 附属のレンチは強度が足りていないようで、 締めているうちにどんどんレンチ側にダメージが加わり、だんだん締められる強さが 弱くなってしまった。そしてレンチで締めるにはいろいろな個所にぶつかってしまって 大変に窮屈だ。こんなときにインパクトドライバーでもあれば捗るのかもしれないが 残念ながら備えていない。バリも多く残っていて削らないと滑車をきちんと つけられないところもあったり… そして実際に冷蔵庫を載せて動かしてみたところ、 滑車の回転があまりうまくないようで、進行方向と滑車の向きが一致しないことが 多数発生した。そうなると滑車というよりはただゴム面をひきずっているだけなので うれしくない。
_ などといったマイナートラブルがありつつ、住居スペースになんとか 持ち込むことができた。持ってきたら持ってきたで、 廊下に物が多かったりと苦労はあったけど、住居スペースまでの移動に比べると 小さな問題だった。電源を延ばすための延長ケーブルを用意したりで 稼働させることができるようになった。いろいろ汚れているので 洗ったりで本格運用は明日からかなー、さっそく薬味とか冷蔵保存が必要なものを 揃えてゆこうと思う。あと今まで認知の乱れによって読めなかった 開栓後要冷蔵のものも収納してゆくつもりだ。
_ TOEIC SQUAREのアカウントが失効した。そういえば先月そろそろログインしないと 失効するよというメールが来ていたような気がする。最後に受けたのが 2016年6月なので… えっもう5年も前なの？ なのですでにTOEIC SQUAREに入っても参照できる成績は残っていない (たしか2年前までしか遡れなかったと思う) し、この先TOEICを再度受けることは たぶんないと思うので、まあいいか〜結局900点超えられなかったのは心残りといえば 心残りだが
_ Outlook (Web版) で先日から署名がつかなくなってしまった。 あまりきちんと調べていないのだが、私はメールをプレーンテキストで送る設定に しているので、それが問題のように見える。HTMLに指定すると署名がきちんとつくし… 挿入する署名は内部のエディタ的なもので編集できるんだが、 もちろん書式はいっさい指定していないものの、ここで 形式を指定できるようには見えないので、プレーンテキストで使える署名に なっていないんだろうか…という気がする。 それならなぜこれまでは問題なかったのか、というと、 書式をすべて無視してプレーンテキストとして貼り付けられていた、か、 署名がプレーンテキストではなかったのでプレーンテキストで作成するという指示を 無視してHTMLにしていた、か、のどちらかなのだろう。なんだか後者を疑いたく なってしまうのだけどWebインターフェースだとヘッダの中身を見るということを する手段が提供されているのかいまひとつわからない。いずれにしても HTMLにするつもりはないし、署名がつかないのは困る…
_ なお仕事ではメールに署名つけてこない人がもともとけっこう多くいるように 感じている。もちろん今回挙げた問題のようにつけたくてもつけられない、という わけではないのだろう。そしてこれも偏見なのかもしれないが 大きめの企業の人達ほど署名をつけてこないケースが多い。署名をつけると 不利益になったり、不利な立場に置かれるような文化なのだろうか… 署名から連絡先を とりだしたり所属部署を調べたりするといったことができないので こちらとしては不便でしょうがないのだが…
_ およそ1年前に買ったうまいたれ (1L 4本)が そろそろなくなりそうになっている。1年かけてゆっくりとうまいたれを 取り入れてきて、今でも忠誠心は変わらない…と言いたいのだが、やはり 入手性が悪くて欲しいときにすぐ買えないというのは考えものだ。 そろそろなくなりそうだな、と思ったら近所のウェルマート(懐)とか キムラ(まだあるのかしら)に赴いて6〜700円のボトルを買えば済んでいた時代は 過ぎてしまったのは仕方ないとしても、送料を含めると1Lあたりの単価が倍くらいに なってしまうし、少しでも送料の負担を減らすためにまとめて買うと、 さすがに消費に時間がかかる。賞味期限は10ヶ月なので、今のペースだと 最後の方は賞味期限切れの状態で使っていることになる。
_ なのでうまいたれと近いコンセプトのものを模索したほうがいいのかしら、 うまいたれから浮気したいわけでもないのに心苦しいのだが… というところで 「めんみ」の存在を思い出した。めんみなら北海道限定とはいえキッコーマンの 製品だし、amazonで1本単位で買うことも可能だ。ということで試してみた。 うまいたれを使い切る前なので比較をすることもできるし
_ さっそく比べてみたところ、やはり互換性があるというところまで似ているわけでは ないようだった。うまいたれは徹底的に鰹ベースの旨味と風味なのに対して、 めんみは他の魚や昆布の風味を強く感じる。冷たい麺のつけ汁として、 暖かい麺の汁として、それぞれ試してみた限りでは、やはり暖かい方でその違いを 強く感じる結果となった。うまいたれの代用といわれると、ちょっと物足りなさを 覚える。ではおいしくないのかというと、そんなことはないので、単に 旨味を強化した醤油ベースのやつ、と考えれば普通に優秀だと思う。 このあたりはどちらが好みなのか、どちらがより多く体内に流れているのか、 という領域の話で、どちらが優れているかという問題ではないのだろう。 そんな問題の中で代用を考えるというのは無理があるんだろう…
_ 作業に手間取ってずっと家にくすぶらせていたこれらを実家に送付した。 電源入れたらすぐに使えるように設定した…つもりだがうまくいくだろうか。 これでうまくいくようなら今後の機器も同様に対応できるのでよいのだが
_ なお交換前のiPad miniはやはりいろいろおかしいようで、電源ボタンなのか ホームボタンなのかが暴れていたりするので継続して使うのは無理そうだ。 能力と時間が十分であれば自力で修理したりすることも考えられるが… 少なくとも現時点の私ではとどめを刺して終わりだろう。
_ iPad miniに残っている写真データをどう転送したもんか… という点については、 AirDropなる機能でできることがわかったのでそうした。 あと、初期設定をいろいろやったといっても、さすがに指紋登録を やることはできないので、手順を紙に印刷して入れておいた。 iPad内で撮ったスクリーンショットをどうやって取り出すか…悩んだ末 メールで送ることにした
_ 手順書を書くためにLibreOffice Writerを使った。 Impressは過去何度か使ったが、Writerは、まともに使ったのは初めてかもしれない。 なんだかんだでリボンインターフェースに慣れてしまった身としては、 メニューまわりの見通しの悪さにうんざりしてしまうのだった。 そしてアプリ側としては一貫性のある動きなのかもしれないがこちらとしては 理解不能な挙動をするあたりはWordによく似ている。 あと不安定？みたいで何度か落ちた。
_ 雨雲は海岸線寄りに偏っているようで、私が住んでいるあたりはほとんどまとまった 雨が降っていないが、実家のほうではかなり大雨が続いているらしい。 熱海では大規模な土砂崩れがあったとか
_ 実家に届けたiPadはすぐに使いはじめることができたようなのだが、 Nestの方は不発だった。スマホをスピーカーモードにしてもらって 私が音声で操作みたいなことは普通にできて、 現在の天気やらYouTube Musicやらの再生ができた。なのでWifiの接続は 普通にできているようなのだが、こちらからのDuoの発信に反応しない。 なんでだろ
_ 寝入って数十分でぱっちり目が覚めてしまった。 朝まで眠れんコースだと思われる…悪循環の始まりだ。ぱっちり目が覚めたくせに 頭が冴えているわけではないので何かコードを書いたりする気力が出てこない。 なにしろ悪循環だからな
_ 以前も書いた通りdotnet buildやら dotnet run やらが遅い。今いじっているソースなんてfsファイル4つ合わせても 600行そこそこしかない小さなプロジェクトなんだが、ちょっといじって ビルド→実行までに7秒以上かかっている。Visual StudioでF5押したときとは 随分な違いだ。
_ Slow build with msbuild and dotnet cli - Issue #7850 - dotnet/sdkなどなど、 dotnetが遅いというissueはけっこう上がっているし、改善したという話も 出ているようなんだが、あんまり変わった感じがしない。 いろんなオプションつけてログ出したりできるようで、それを眺めている限りでは 特定の処理がやたら遅いとかブロックしているというよりは、万遍なく遅いという 感じに見えてしまう。そしてdotnet buildとかは自身がかかった時間を 表示してくれるんだが、timeで計測した結果とは1秒ちょっとの差がある。 そんなものたちの積み重ねによって結果としてこのようなハイパフォーマンスを 実現しているのだろう。やるせない
_ それにしてもちょっといじって結果を見るまで7秒以上… というのはちょっと苦痛だ。 この手の待ち時間では1〜2秒なら待ったうちに入らないが、5秒を超えると苦痛… みたいな閾値があるように思う。 あきらめて別のことをするには短かいし、 毎回じっと待つには長い。
_ F#でOpenGL使いたかったのでOpenTKを使っている。OpenTKは以前使っていた Tao Framework の後継として指定されていたものだが、OpenTKは OpenGL/OpenAL/OpenCL だけなので Tao Frameworkがサポートしていたライブラリたちの多くは使えない。 たとえばSDLとか…気付いたらSDLともすっかり疎遠になってしまったもんだ。 最後に使ったのはMucom88をいじっていた頃なので、 もう2年前かーそれも音まわりだけだし
_ SDLを使いたければそれはそれで用意可能だけど、 2Dの画像処理はSkiaSharp使っており、SDLがあるといい場面というのは…あるかしら？ キーボードとマウスはOpenTKがめんどう見てくれるし、 ジョイスティックは使わないし… OpenALを使いたいという気持があまりないので、 オーディオが必要ならSDL使いたいかもしれない？ただ SDL_soundは使わなくてもいい気がするので、そうなるとどうなるんだろう (しらんがな) ちょうどSDL_imageじゃなくてSkiaSharp使うからVideo系で SDLを使う必要ないか〜というのと同じような感覚。 あとは周辺ライブラリか… フォントのレンダリングは今のところ SkiaSharpでいけそうに思えているのでSDL_ttfは大丈夫そうだし、 SDL_netはいらんだろう。SDL_rtfはもともと使っていない。…あれ、 どこかでやっぱりSDLも使うようにするか〜という話になる予定だったんだが、 なかなか思い通りに行かないな…
_ あっそういえばCD-ROMを使いたかったような気がしてきた…!!!! (SDLにももうないよ)
_ 眠れないので結局朝方まで起きていて、そういえば今日は5日だから Dr林のサイト更新の日だった…と読み進めていって、最後に表題のコラムを読んでより眠れなくなった。 「林の奥」の中でも、というよりDr林のこころと脳の相談室の中でも 極立って異質のコラムだと思う。 指摘や注意喚起といったレベルのものはこれまでもあったけど、 ここまで明確に批判と主張を含んだものは見たことがない。
_ この時期に五輪を開催することは負けがはっきりしているギャンブルである (9の要約) というのは確かにその通りだと思うのだけど、 なぜそこまでして…？ というのが見えてこないのは変わらない。 そこを今どうこうできる問題ではないのだろうけど、 少なくともここで書かれている「結果」は、 COVID-19の感染に関するものだけであって、その点について原理上「勝ち」は ありえないのだから、そもそもギャンブルとして成立していないだろう。 国民の(世界の)命を賭金にしたギャンブルというのは形としては その通りなんだろうけど、そこに何か強大なリターンがあるのか、 やらないと強大なペナルティがあるのか、単に今更後に引けないだけなのか？
_ 倫理観の欠如はもちろんあると思うがそれだけでここまで大それたことを することはないと思うのだけど…そこには信じがたいほどの現状認識の甘さだとか もっとはっきり言うと馬鹿・無能みたいな成分がないとさすがにこうはならんだろう。 それは政府や菅首相だけの話ではなく、 推進する側であるIOCやスポンサーにも同じことが言えるわけで…だからこそ Dr林は単にこの人達の倫理観は欠如しているだけというシンプルな結論を 信じたいと表明しているのだろう。 歴史上の「大それたこと」として容易に結びつくもの(戦争)もこんな風に 避けがたいこととして形づくられていったのだろうか、と思うと恐しい。
_ なんだか世界史講義録のピューリタン革命のときの 描写、 チャールズ1世を処刑したときの民衆の反応を思い出してしまう。 いざそういうものに向かって進んでいって、後戻りできない瞬間を突破したときの 反応というものはこんな感じなのだろうか
_ 久しぶりに見に行ってみたらおよそ10年ぶりになる 新しいシリーズがいくつか始まっていた。 現代史編と、 時間切れ!倫理らしい。 これは楽しみだ。
_ 私は高校の頃に世界史の授業をとったけど授業にも内容にも まったく興味を持てず身につかなかったので世界史に関係する教養がほとんど ゼロに近い状態のまま社会人になってしまった。 初めてサイトの存在を知ったのが2005年 (もう10年近く交流がないがtyuyuさんお元気だろうか。 とても忙しくされていたのを覚えているが…)で、 実際に読み始めたのが4年後の2009年で、 何回か読んだ結果、世界史なんもわからんという状態から 脱出することができて、歴史に関係する本などに対する苦手意識もなくなったし (歴史苦手な状態で読んでいたMASTERキートンもあらためて読み直したらまた 面白いかもなーと思ったが手元にないので読み直せていない)、 世界史講義録自体も書き物として面白いので繰り返し読んでいた。 おそらく数十回は繰り返し読んだと思う。
_ というほどのこともないが両手で杖ついて歩くアクティビティを、 雨の合間を縫って継続している。両方同時→片方ずつ、みたいなのを10分おきに 切り替えながらやっていると飽きも来ないし適度な運動になっている。 ただ杖から手を離さないスタイルだと11分30秒/kmあたりが限界なような気がしてきた。 足の痛み以前にこれ以上のスピードを出すには どういう身体の動きをすればいいのかしらという気がする。
_ 11分30秒/kmだと多少は早目の徒歩と大差ないペースなので負荷としてはまったく たいしたことない。運動としての負荷ではなく身体パーツの負担という意味では、 杖を握っている手・手首、と、膝あたりにはやはり多少は負担がかかっているようだ。 そしてこれ以上のペースにしようと思うと杖を手から離して歩く文字通りの ノルディックウォークをしなければいけない気がしている。 しかしまだ早い気がするな… 今のペースで歩いていても足の痛みを一切感じないという ほどではないので、せめてあと1ヶ月くらいは ガマンしないとだめかなと思っている。常に痛いというわけではないし、 翌日に残るほどでもないので回復のための適度な負荷という感じかなと 思っているがどうだろうか
_ 設定済の状態にしたつもりだったNest Hub Maxが着信してくれなかった件、 あれからいろいろ思い返してみたけどあまりこれだという原因が思いつかない。 自宅のWifiルータがフィルタしているとかかなーとちょっと思うが、 実際に様子を見てみないとわからん…MeetとかDuoは20000近くのポートのtcp/udpを 使うらしいので、そのあたりが開いていないと通話ができないだろう。 そこらへんが開いていないと着信もできないのだろうか？ というのはちょっと腑に落ちないが…
_ とても蒸し暑い日が続いている。気温は30度弱で、たまに雨降って…という連続だ。
_ 11分30秒/kmが限界だーと言っていたが、痛みが持続しない範囲で スピードを意識してやってみたところ10分50秒/kmになった。 やはり一瞬左足が痛くなるタイミングがあるものの、翌日まで残ることは なかったのでこのくらいなら大丈夫らしい。息は多少荒くなるけど息が あがるほどではないし、汗もそこまでひどいことにはなっていない。なので 負荷はまだまだ全然少ないようだ。
_ 足への負担はあまりないのに対して、指への負担はわりと大きいようで、 翌日になってもキータイプが少々苦痛になる。これは握る力が強すぎるというのも 原因としてあるのかもしれない。完全に手を離してまた握るという流れであれば さほど手に負担はないように思うけど、今はできるだけしっかり握って…ということを 心がけてやっているので、かえって指には負担が大きいようだ。 グローブでも使わないとまずいかしら？暑いからあまりやりたくないのだが
_ LearnOpenTKはChapter1をひと通り 終わらせたし、構造はいじりながら見直してゆけばよいし、 1フレームごとにどうにかするという点もなんとかなりそうなので、 他に必要なものを1つずつやっつけつつ、実際にShotcutとの連携を探ってゆきたい。 こういう取組自体を録画したり配信したりというのが当初のねらいだったのだが、 仕事終わった後に事務所で妻と過ごしながらいろいろ試行錯誤したり 勉強したりするという流れがわりとよく機能しているので、住居に戻ってきてから さあ録画するか…ということにはあまりならない。
_ 事務所のぷにぷに(VAIO Duo11)ではShotcutとの連携あたりをいじるのは 主にメモリ上の問題で厳しいので、そのあたりは他の環境でやるしかないだろう。 事務所では動画に絡まない部分の試行錯誤や、ほかの勉強をするように シフトしてゆきたい。
_ そんなことを考えながら文字装飾についてあれこれやってみる。 Skia(Sharp)にはPathとかShaderといった他の描画ライブラリでもよく見るやつが あるので、それで縁取りの文字やグラデーションつきの文字を実現することが できるはずだ。 SkiaSharpは docs.microsoft.com にドキュメントが上がっているので親しみやすい。 SkiaSharp Graphics in Xamarin.Forms - Xamarin | Microsoft Docsは step by stepの解説といて読みやすいし分かりやすい。 Referenceも 慣れている形式なので使いやすい。 元々のSkiaが、あんまりドキュメントが豊富とはいえないし、 リファレンスの解説もかなり表面的で分かりづらいので、とくに前者の ドキュメントは貴重だと思う。
_ 流れとしてはSurfaceViewでやったときと だいたい同じだと思う…と言いつつSurfaceViewでどうやったのかを 覚えていないのだが。これで5000兆円欲しい! なども作ることができるはずだ。 と思いながら実物を見てみたら、いろいろ手が込んでいるんだなあということを あらためて知った。
_ 文字装飾ができるようになったので今回必要としているものの断片はだいたい 揃ったと思う。subtitleを作るだけならSkiaSharp単体でやったほうがいいし、 動きのあるものはOpenTKと組み合わせて動画にする (アルファつきの動画は まだ作れていない) か、フィルタとして実装するなどの方法があるだろう。
_ OpenGL自体の理解があいかわらず怪しいし、↑の通り自分が使える範囲で 満足してしまうと普通どう使うもんなのか？みたいな知恵がいつまでたっても つかないので、勉強時間にWebGL2あたりをやっておこうかな…と思っている。 OpenTKでがんばってもいいんだが、教材あまり多くないし、 ちょっといじってすぐ確認という点ではWebGLの方があきらかによいだろう。
_ Electronのアプリがどうこう以前にFirefoxがメモリ喰いすぎている問題があるようだ。 Firefoxってそういうソフトだった
_ あとメモリ4GBしか積んでないのにZFSを使っているのもメモリ使用量的には 不利な要素かもしれない。もう動画関係に使う予定はないし こっちはZFSやめてもいいんだが、 やめてもたいして効果がなかったらやだな…とも思うのでむずかしいところだ
_ ギャンブルの話、 何を賭けているかはわからないがとんでもないハイリスクなものだった、 という倫理観がぶっこわれている場合の他に、 ない可能性に賭けているのではないかという馬鹿寄りの話があったら それこそ浮かばれないわけだが、 そんなときに思い出すのは「あるニートは賭けにでた。」のあれだ (あるニートは賭けにでた。/ 一酸化炭素が部屋に充満する前に / 見知らぬ愛らしい女の子が「お兄ちゃん♪」って / 玄関からお邪魔してくることに、生死を賭したのだ)
_ 立場が態度を決めるという面はたしかにあり、 つまり本人の情緒の部分ではとてもとれないような、しかし総合的に考えて 正しい選択をとらなければいけないとすれば、そこには立場から来る責任や 覚悟が後押しするのだろう。 一方で、たとえば私利私欲や保身といった、 倫理観の欠如している状態からくる動機で生命を弄ばれるのでは 少々溜らないものがある。とはいえ単に馬鹿で無能だった結果このような 形になってしまった、というよりは、明確な悪意の存在があったほうがまだましと 思ってしまうような発想が私にはあるのだが…(以前も同じようなことを書いていたが)
_ あと一貫性がないルール(ただしオリンピック・パラリンピックは除く)を 見せられると「ただしイケメンに限る」の逆パターンみたいだな、 と思ってしまうのだった。
_ これも以前同じようなことを書いた気がするが、 私がこういった文章を書くのは記録を残したいという動機が大きい。 いつ何があった、というものはいろんな手がかりで後から調べるのが 難しくないことが多いけど、そのときどう思ったのか、周囲はどのように なっていた (と自分には映っていた) のか、といった記憶は後から 振り返ることがとてもむずかしい。それは単に思い出すのがむずかしいという だけでなく、間違っていたり美化したり、辛すぎる部分がマイルドになったり、 むしろよい経験だった、 というような当時の印象とは正反対の落着きかたをしてしまうこともあるので、 当時どうだったのかという点については記録を残しておくほかない。 みっともないような走り書きであっても残しておきたいと思うのはそういう理由だ。
_ 記録することとそれを公開することは行動としては別にイコールではないのだが、 自分がこう思っている/思っていたということを少しは読んでいる方々に 知ってもらいたいという気持もあるんだろう。あとは 公開 (ZHT) 向けの仕掛はあるけどprivate用の仕掛の整備が20年くらい 滞っているという理由もあるが…
_ テレワーク生活はまだまだ続きそうだし、 向こう1〜2ヶ月で変わることはないと思うが、 とはいえ終了する可能性も見えてきているわけなのでさらに生活を見直す時期かなー とちょっと思ってきた。運動といえば歩くことくらいしかできず、その状態だと まだまだ健康になるには程遠い感じがするし
_ ひとまず睡眠リズムを整えるため、昼休みに仮眠とるのはやめることにした。 フトン敷けばすぐに眠れてしまうのは尊いというほかないし、 3〜40分の仮眠の効果は絶大なのだが、絶大なだけに夜の睡眠がおろそかになりがちだ。
_ 仮眠の効果は、眠気がなくなるというだけでなく、 目を休ませる効果も見逃せない。仮眠自体が目の疲労回復に役立っているだろうし、 その間モニタを見ていないので余計な酷使になっていない、という面もあるだろう。 寝ずに起きていろというのはそんなに難しいことでは ないけども、PCをだらだら見ていたら休憩にならん気がするし、 かといってこの時期の炎天下で散歩というのもあまりよいとは思えない。
_ モニタを見ていることには違いないが動いているものではないので まだましかしら…ということでTEDICTを復活させてみた。昼休みになったら スマホをChromecastにキャストして、Bluetooth接続のキーボードつなげて 取り組んでいる。打ち損じによるロスもイライラもないので やはり極めて快適だ。 スピーカーから出てくる音で聞きとりをするのはかなり 難易度が高いのでBluetooth接続のヘッドホンを使っているが、慣れてきたら スピーカーでやることで手軽に難易度を上げることができてよいかもしれない。
_ TEDICTは月に何度かupdateが走っているので今でも細々と変わっているようだ。 よくなっている、と感じるよりも何かおかしい感じることの方が多いような 気もするが… 今回は再生がループせずにどんどん先まで進んでしまうという 症状がある。常に起きるわけではないようだが…全部埋めた後に再生する際には 確実に再現している。
_ 11分/kmを切るくらいのペースで歩こうとするとやはり足の負担などが 大きいようで、2日連続でやると多少ダメージが残るようだ。 その後1日置いて歩いたときには、常に痛いというほどではないけど痛みを感じる 場面が増えたかな〜という程度に悪化していた。なのであまり無理しないペースを 心がけて、11分ちょっと/kmくらいで歩くと負担が減って楽に歩けるようだ。
_ といった感じで歩く方については少しずつペースも掴めてきているのに対して、 手の方の負担が大きいというのは変わっていない。日中のキータイプにも 支障が出ているので、これをなんとかしないと日常の取組にすることは むずかしい。まずはグローブを買うか… 関節の痛みの他に親指の側面あたりが 擦れるという症状もあるので、これは連続＋長時間でやるとマメになるパターンだろう。 これもグローブによって緩和されることが期待できる。
_ 指関節へのダメージはこれまでのものとは大きく異なり、親指以外の4本に 万遍なくダメージが行っているようだ。これまでは人差指に集中していたから そこだけサポーターで保護すれば痛みを覚えずキータイプなどができていたのだが…
_ ポールウォーキング向けというようなグローブはいくつか存在する。 どれも通気性よさそう。擦れ防止のグリップがついている程度で、 指の曲げを保護するような動機はあまりなさそうに見える。 自転車用のグローブはどうかしら？と思ったんだが、 太さや力のかかり方も違うのでやはり専門のものがいいのかしら？ 指の関節はテーピングなどで保護したほうがいいのかもしれない。
_ 自宅に冷蔵庫が導入されたのでBRITAでも買おうかしらと思った。 これまで自宅と事務所の水は2Lペットボトルのものを、 月6箱(1箱6本)のペースで注文して使っていた。生協なので玄関口に配達してくれて とても便利。これでお茶、コーヒー、 炊飯やら炊事やら、をやっていて、ぎりぎり足りるか足りないかというペースだった。 私と妻のコーヒーとお茶をつくるだけで1本半は消費するので、 これを毎日やっていたらやはり足りないことが多い。
_ こういった消費の一部をBRITAで代用できないかしら？ と思いつつ探してみたところ、 最近はいろんな浄水器が出ていることを知った。以前よくあった、 水道管の途中で分岐して専用のボックス的な器具を経由する…みたいなものの他に、 蛇口部分に取り付けるだけみたいなものもあるようだ。 といっても大昔にあった、蛇口の先端をカバーするだけのメッシュ状のあれではなく (今でもあるのだろうか？)、きちんとフィルター経由して浄水するようなものらしい。 クリンスイ、トレビーノ、なんてのはよく聞くブランドだったが、 一方で表題の機械はそれらよりはちょっと高目で、野暮としか言いようがないような 見た目をしている。いろいろ検討した結果、見た目で浄水するわけではないし… ということで表題の機種を選んだ。
_ 蛇口の先端の形状によってとりつけできたりできなかったりするようだ。 それはこのタイプの浄水器であればどれも同じらしいが。 うちの自宅の蛇口は泡沫蛇口と呼ばれるタイプらしい。 泡沫蛇口は、先端部分のネジが外側に切られているか 内側に切られているかでさらに2つのタイプに分かれるようだ。などなど。 そして呼び径が22mmじゃないとだめっぽい記載になっており、 ノギスで計った限りでは21.6mmとかそんな感じなんだけどこれは22mmだと 理解していいのかしら？ と不安を覚えつつ試してみたところ問題なく装着できた。
_ 使い勝手は… 浄水の出るペースは思ったほど悪くないと思う。昔よくあった、 浄水にするとなかなか水が出てこないという感覚はほとんどない。 浄水じゃない方ではシャワーがあるのが便利だと思った。洗いものなどをする際に これまでの蛇口ではちょっと水の勢いの調整が難しいなあと思っていたので ちょうどよかった。そして浄水については普通に飲める水ができてよかった。 とくに浄水にしなくてもひどい味や匂いがしていたわけではないのだけど
_ ということでペットボトルの水の出番をかなり減らすことができた。 よかったよかった。 よかったのだが、冷蔵庫がきっかけで水のことを見直すことになったのに 結局導入したのがこれなので冷蔵庫関係ない。さっさと導入しておけばよかった。 ペットボトルの水は、 災害対策のことなどを考えると完全になくす必要はないと思うけど、 ごみもたくさん出るし、減らせるのはよいことだと思う。
_ 事務所のシンクも泡沫蛇口みたいなのだが、先端がかなり固くて外せていない。 手持ちのスパナはどれも20mmが限界だった。水まわりをメンテするときに使えるような 器具はあってもいいのかもしれない。
_ 梅雨が明けたようだ。去年は8月に入るまでずっと雨がちだった記憶がある。 今年は台風はどうなんだろ
_ 自宅で使ってみてよいものだと思ったので 事務所用も買った。泡沫蛇口がとれなくて 悲しかったので工具も買ったのだが、それが届く前に以前100均で買った 工作用のクランプを駆使してとり外すことができてしまった。
_ 浄水器を使い始めて1週間ほど経過した。 そのまま飲む以外の用途ではもう浄水でいいかなと思っている。 水道水の有害/まずくなる成分を 除去してくれるだけなので、できあがった浄水は、まずくない、であって おいしいにまでは至らない。 久しぶりにペットボトルの水を飲んでみたら やっぱりこっちの方がおいしいなあということになった。 なのでシンプルに飲むだけのときはペットボトルの水を継続することにした。 ぎりぎり悩むのはコーヒーだが…
_ 浄水のおかげで乾麺を茹でるときや、それを洗うときにも遠慮なく使えるので これはかなりでかい。もっと早く導入しておけばよかった。
_ 指先が開いているものではなくて全体を覆っていつつスマホの操作もできます的な、 おそらく登山用のものを意識した (本当に登山で使ったら使いものにならなそうな)ものらしい。 使い勝手を考えれば指先が開いているものの方がよさそうなんだが、 指を保護する目的を果たしてくれるかしら？と不安になった。
_ で、 試してみたが指に対する効果はいまひとつのように感じる。 杖を強く掴もうとしなければましになるのだろうか。 本来のノルディックウォークは指は添えるだけのような感じなので、 本来の形に戻せばいいのかもしれないが、そうなると今度は足の方が心配になる。 ただ現時点でより強い痛みを覚えるのは左足ではなく指の方だからな… 寝て起きるとほとんどの指が曲げ伸ばしに痛みを伴うような感じで大変よくない
_ FFMediaToolkitでProResなどが指定できなそうに 見える件、 コードのドキュメントによると、 サポートしているものだけ持ってきているが、 もし他のものを使いたければ FFmpeg.AutoGen.AVCodecID の方を 使うといいよという話らしい。 F#でenumをキャストするのはLangagePrimitives.EnumOfValueを使うようだ。
_ そしてProResを指定してみたところフレームを流しこむところでエラーになった。 yuv420pではだめだよ(意訳)とのことらしい。 こちらもImagePixelFormatにないものはFFmpeg.AutoGen.AVPixelFormat から 持ってくるといいらしい。ffmpegのソースを見て、AV_PIX_FMT_YUVA444P10なら 使えそうなのでそちらにした。 ネイティブのエンディアンに従って置換されるようなので 最終的に使われるのはAV_PIX_FMT_YUVA444P10LEらしい。
_ 今度はエンコードできたようなのだがとても遅い。目視で確認しただけだが、 H264のときは60fpsでもひっかかる感じはなかったのに対して、 ProResだとかなりこま落ちして10fpsそこそこという感じだ。 でかいというのは覚悟していたし実際でかいんだけど、遅いというのは予想外だった。 ともあれYUVA4444P10になったのでアルファチャンネルつきで出力できるように なったはずだ。なのでglClearColorで透明にしてみた。 ウインドウに出しているときはアルファを無視するのかな… 元々の、LearnOpenTKの頃に指定した鈍い緑っぽい色のままだった。 動画を再生してみると黒くなるのでアルファは効いているっぽいが…
_ Shotcutで取り込んでみたところきちんとアルファが効いた状態で使うことが できた。よかったよかった。これでアルファ値があればどうにかなるものについては ひと通り処理できるようになった。しかしちょっとした動きのあるクリップを 全部ProResでやったらえらい巨大になってしまうので大変かもしれないなあ〜 やはりフィルタで実現する方向も考えておかないとだめか〜
_ 思いがけないところで小島剛一さんの名前を目にした。 小島剛一さんといえば以前読んだ本の著者で、 あの緊迫した状況の数々、しかもその多くは身体や生命に危険を及ぼすものだった、 という内容を、2冊の著作だけとはいえ読んでいたので、 生半可な覚悟で喧嘩売っていいひとじゃないだろうと思った。
_ 「老害の若手 (これもイニシャルだとH氏になるのか) と若手の老害」 という表現を以前読んでとても上手な表現だなあと思っていたのだけど、 こういう人達は相手にするとそれだけ相手の延命につながるので、 構わないというのを信条としているのだけど、 若い方がこの人達の言説を消費しているようで、なんだか危ういなあと 思いつつ、単に面白がって楽しんでいるだけなら逞しいのかもしれないとも思う。 なおH氏(若手の…のほう)については、人物としてはまったく好感がないけど、 誰にでもできるものではないことをやってみせた人だと思うし、このような 人によって成し遂げられたのは幸運だったのかもしれないなあとも思う。
_ 土日は日中自宅にいないのでエアコンを止めて、日付変わる前くらいに 戻ってくると室温は30度弱、29.6度あたりまで上がっている。 で、今日は19時前まで仕事した後エアコンを止めて、22時前に戻ってきたところ 29.2度まで上がっていた。日はほとんど沈んでいたし、外は26〜7度といった あたりのはずなのだが、溜まっていた熱によってここまで上がるのか
_ 19:15の予約。打ってから15分ほど待合スペースで待機してから退散した。
_ 打ってから10分くらいしたときに、腹の中から頭の方に向かって 湧き上がってゆくなにかを感じて、その後に一瞬眩暈がした。 そしてなんだか身体が火照った感じが継続した。 身体の中で戦いがはじまったのだ… と思ったが、 ただの血管迷走神経反射というやつなのかもしれない。
_ 妻と待合わせして買物をして帰る最中には左腕がちょっとだるいかなと 感じるようになっていた。痛みはない。痛みといえば、注射そのものの 痛みもほとんどまったくなかった。インフルエンザの予防注射に比べても 本当にわずかにチクっとしただけで、身体に針が刺さったのにこんなに 痛くないもんなのかと驚いた。
_ 22時現在の体温は36.4度。19時前に計ったときは36.6度だったので、まだ 全然上がっていないようだ。頭痛はある…がこれは注射前からあったものが ひどくなっただけのようにも思える。20時過ぎにバファリンを飲んだ。
_ 23:45 注射したあたりが痛くなってきた。腕を持ち上げると痛みを覚える。 これがうわさのあれか。鎮痛剤も切れかけているので痛みを感じるように なったのかもしれない。 小一時間したらおかわりする予定。食後けっこう経過しているので タイレノールにしておくか…熱はまだぜんぜんない。36.6度。
_ 別にOpenTK触ってないときに表題にOpenTKを含めるのはうまくないので変更した。
_ さてShotcutというかMLTのフィルタとして使えるものとして frei0rのほかにffmpegのlibavfilterのプラグインがあるようだ。 あとShotcutがサポートしているのか分からんが OpenGL and GLSL in MLTというのもあるらしい。こちらは別の機会に試すことにする。
_ さてlibavfilterとfrei0rのどちらがいいのか、というと、よくわからんが frei0rの方があちこちで使えそうな印象がある。しかし私はF#で作りたいので CやらC++であれこれするのはできればやりたくない。 ソケットなりmemory mapped fileなりでフレームをやりとりするような仕掛があれば いいんだがなあ〜と思いながらソースを見てみたがそういうのはないらしい。 自分で作るしかないか…定められたシンボルをexportして 転がしておけば勝手に使えるようにしてくれる…んだよね (わかっていない)
_ 9時起床。体温は36.8度。 まあこの体温計は前後1度くらいの誤差があるのでよくわからん(すてちまえ)
_ 注射した個所付近が痛いというのは寝ている間もずっと続いているが 全身が痛いというほどではない。1時過ぎには寝ていたので睡眠時間は 十分だったと思うし、熱もないし、ちょっと頭痛があるかなという程度だったので 仕事できんこともなかったが念のため0.5回休み。午後はいろいろ予定が 入っているのでそれをこなしつつ1日を終えたい。
_ と思いながら寝て起きたらもう14時前だった。なんだかんだで身体もちょっと ダルいかもしれない。あと痛みがさほどではないのは鎮痛薬を飲んでいるからかも？ めし喰ってバファリンおかわりした。体温は36.8度±1度 (……)
_ 左腕を上げようとすると痛みが走るもののキータイプなどが憂鬱になることもない (どちらかというと指の関節炎の方がきつい)。
_ 22:30。体温は36.8度のまま。事務所にある誤差の少ない体温計で計ったので これはわりと真実に近い値を示していると思われる。 注射した個所付近の痛みもピークを超えた？ 頭痛はいつも通りだ。 ダルさはあいかわらずでなんだか眠い。
_ 結局熱は上がらず、注射した付近の痛みも広がることはなく、 ただ頭痛はそれなりで、あとダルい。横になればすぐ眠れるし… 昨夜は23時過ぎには寝た。水分とりすぎたせいか7時に起きてしまった。 そしてはっきりと目が覚めてしまい、眠れなくなった。 もう体力も戻ってきているのか？ と思いつつ起きる気にもならなかったので そのままフトンを暖めていたところ、うとうとし始めた直後にアラームで起こされた。 あらためて起きてみると頭痛とダルさはあいかわらずで、なかなか難儀だ。 体温は36度台のまま
_ 日中は、カゼひいたときのような節々のダルさを覚えた。注射した付近の痛みは 夕方にはかなり弱くなっており、ちょっとした動きでは痛みを感じないように なっていた。
_ frei0rでフィルタを作る話のつづき。枠組はそんなに複雑なものではないので、 他のフィルタを参考に最低限のものを作る。そしてそれをShotcutが 参照できそうなところに持っていった。が、フィルタの一覧のところに出てこない。
_ ディレクトリ構造をあれこれ眺めてみたら、 share/shotcut/qml/filters/ にフィルタごとにディレクトリができており、 その中にmeta.qmlというものがあることが分かった。 これでメタデータを定義したり、 UIをQMLで指定したりするらしい。 以前のShotcutはWebVfxというカテゴリでHTMLやQMLでサブタイトルを 作ったりできており、QtWebKitを切り捨てたときにそれらも 使えなくなってしまっていたので、てっきりQMLというやつももう時代遅れの テクノロジーなのかと思ってしまったがそうでもないらしい。 frei0rなどの外部プラグインのメタデータとUIをお手軽に記述できて 見通しよさそうに見える。
_ 他のフィルタの設定を見ながら メタデータとUI (空っぽ) を用意したところちゃんと認識して 動いてくれた。とりあえず作ったフィルタはinputをコピーするだけだったので、 ポインタを逆に走らせたり、エンディアンを変えたりで反転やら色味やらが 変わるのを確認した。なのでひとまず期待通りに動いているらしい。
_ フィルタのロードは起動後に1回しか行われない？ようで、 フィルタを再コンパイルしても動きが変わらない。まあ今後このフィルタは Memory mapped fileを用意して、 F#側でそれをいじるということをするつもりなので、いっぺん枠組をきちんと 作っておけば、フィルタの実態であるF#をいじることでShotcutの再起動をせずとも 動きを変えることもできるだろう。
_ Shotcutからのフィルタの使われかたを考えると、 複数のコンテキスト (instance) から、場合によっては同時に使われるケースも 想定しなければいけないかもしれない。 OpenGLを使っているケースを考えると、 複数コンテキストは工夫次第だと思われるが、同時というのはさすがにむりだろう。 ただ、Shotcutの設定群を見ると、対象のフィルタがスレッドセーフかそうでないかを 設定することができるようなので、そこで制御してもらうか、 フィルタ側で待たせるか、で、対応できるかなと思う。
_ 注射打ったところ周辺の痛みもほとんどなくなった。わざわざ押したりしなければ 痛みを感じることもない。いくらでも眠れるということもなくなった。 寝たのは朝方 (5時前くらい) だったのだが、8時過ぎには目が覚めてしまった。
_ frei0rのフィルタ側でmemory mapped fileを用意しておいて、 F#側のプロセスはそれを経由して受け取ったフレームを加工して返す… なんてことをしたいと思っている。新しいフレームが来たことをどうやって 伝えようかな、と少し悩む。MMF内で状態を管理して それを双方が監視するような運用がすぐに思い浮かぶが、非同期オブジェクト、 たとえばMutexとかを使ってできないもんか？ とも思った。 WindowsだとSystem.Threading.MutexはCreateMutexEx/OpenMutexでやっているので、 unmanagedとの同期をとるのはさほどむずかしくないが、 Linuxの場合はどうなのか…？ ソース (System.Private.CoreLib/src/System/Threading/Mutex.Unix.cs) を見る限りでは プロセスを跨いだMutexが実現できているようには見えないのだが… しかし検索してみるとLinuxでもきちんと使えていると書いているひともいる。
_ などと触ってもいないのに悩んでいたところ A bug story about named mutex on Mono | Andrey Akinshin 経由で Add named mutex for cross-process synchronization by kouvel - Pull Request #5030 - dotnet/coreclr - GitHubというpull requestを見つけた。 プロセスを跨いだやつというのはinter-processじゃなくてcross-processだったのか。 それはともかく差分を見てみたところ、 pal/src/ 以下にソースを追加したりいじったりもしている。 PALってなんだ？Platform Abstraction Layer？ どうやらそうらしい。 coreclrの構成を理解できていないので読解が遅い。
_ PTHREAD_MUTEX_ROBUST が使えるときはこれを利用したpthreadのmutexで 実現しているらしい。System.Threading.Mutexはロックしたスレッドが いなくなってしまった後に別のスレッド/プロセスが Mutexのロックを取得しようとすると AbandonedMutexException が帰ってくる ことになっているのだが、デフォルトの PTHREAD_MUTEX_STALLED だとその動作が 実現できないので PTHREAD_MUTEX_ROBUST が必須になっているんだろう。
_ さて今回のようにフレームごとに呼ばれるような作りの場合、 用がないときは長時間待ち状態で、使われはじめるとひっきりなしに 呼ばれることになるので、呼ばれるたびに10msec待たされますみたいな作りだと かなり使い勝手に影響しそうだ。ドキュメントによるとtimeoutを0にすると ブロックしないそうなので、SpinWaitにして、一定時間を超えたらSleepにする、 とかでいいのかな
> MemoryMappedFile.CreateNew("ahyahya", 1000L);;
System.PlatformNotSupportedException: Named maps are not supported.
UNIXでひと括りにされているので (Macでちゃんと動かなそうな)
shm* は使いたくないんだってさー (意訳)、
んなあほなー
_ 自力でP/Invokeでがんばった方が早い気がしてきた。shm*系だと 自前のメモリを共有メモリに仕立て上げることはできないので、 frei0rのサービス側から渡されるメモリをそのまま別プロセスに渡すことはできない。 となるとFullHDのRGBAなら毎フレーム8MBのメモリコピーを 2回しなきゃいけなくなり、あまりよろしくない。
_ …POSIX共有メモリというのがあったか。 そしてなんでmutexを使いたがっているんだ？同期をしたいのだから semaphoreではないか。そしてmmapも与えたアドレスを必ずマップしてくれる わけではないのだから結局コピーが必要になるのは避けられないのかー
_ 決してCのプログラムを書くのが久しぶりというわけではないのだが あほみたいなミスをいろいろして進みが悪かった。 ifの条件(非ゼロ/ゼロ)を逆にしていたり、errnoをチェックするつもりで 戻り値と比較していたり…
_ ひとまず枠組はできたので今度は相方のF#側だな
_ 腕の痛みもほぼなくなり、身体の違和感もほとんどなくなった。もう元の 生活に戻って大丈夫かしら
_ F#で組んでいて期待通り動かず、まずいのはF#やP/Invokeの部分なのか そもそもおかしいのかが分からないと追跡も大変なので F#で組みたいと思っているものもまずCで書いてみることにした。 いろいろ理解ができていない部分があって、shm_openした後にftruncateして サイズ分のメモリを確保しとかないとだめだったとか、昨日も書いたが mmapでとれるアドレスは第一引数に指定したものとは限らないなど。 PCいじってもうすぐ40年、UNIX触りはじめて20年くらい、こんなことも 分からないまま過ごしてきてしまった。
_ 動くようになったのでF#に移植したところ期待通り動いた。 semaphoreはsem_tという構造体で管理されていて、プロセスを跨ぐときは 共有メモリの中に入れておくらしい。他にも共有したい情報はあるので 構造体を作ってそこに入れておくことにしておいて、F#側でも構造体作って Marshal.PtrToStructure すればManagedの世界にひっぱってくることができるが… 別にsem_tの中身をF#側でどうにかしたいわけではないので、もともとの メモリの中身をそのまま使ってもらったほうがよい…ということで IntPtr(nativeint)とMarshal.OffsetOf でポインタ演算をして そいつを使わせるというやりかたにしてしまった。
_ ともあれこれでやりたいことの枠組はできたので、以前から作っている OpenTKのあれに組込むことで、1フレームずつ受け取ってそれを テクスチャに貼りつけて、加工してフレームバッファとってきて書き戻してあげれば frei0rのフィルタとして動作することができるはずだ。書いているだけでも 豪快に遅そうな感じがするがどんなもんだろう。10fpsくらいしか出なかったら もはやノンリニア編集とは言えない環境になりかねん
「やめることは一番簡単なこと、楽なことだ」とした上で、 「挑戦するのが政府の役割だ」と語った。えぇ(困惑)… やめられない状況に置かれているのではなく、 できると思っているということなのか。 ここまで狂ってたとは… 発言全体を見てもそのように考えているということを表現しているようにしか 見えない。 ワクチンが行き渡れば困難を乗り越えられると本気で考えているのかもしれない。 いつまでこんな大袈裟で無駄な対応を続けるんだと考えている層は 相当量いるわけだし、困難を乗り越えたように見せたりそう理解するような 流れになるのかもしれない。私は、これまでの取組が いつでも無効に終わる可能性は高いし、 次に今よりもよい形に進む保証もないと考えているので、恐しいことだと思う。
_ そんなオリンピックが今日から始まった。 始まってしまった以上できることといえば関心を持たず相手にしない、 というくらいしか思いつかない。もともと関心がないので、 相手にしないという態度を続けることは特に難しいことではないが…
_ 不満は果物に書いてミキサーにかけるとスカッとする （はず） :: デイリーポータルZを読んでいて、 そういえば自宅は冷蔵庫時代に突入しているので氷をつくったり 果物や野菜を保存したりできるようになっていたことを思い出した。 なのでミキサーがあればジュースつくったりできていいかもしれないと思った。
_ 探してみるといろんなものがあって例によって迷う。様々な要素について検討してみる:
_ タンブラー式は洗い物も増えずにいい気がするが、 最低バナナ1本＋αは入れられる容積がないと使いづらそうだ。
_ なんだか今日は眩暈がひどい。まっすぐ歩けないし本を読むのもちょっと大変
_ 日常生活における違和感はほとんどなくなったようだ。 腕は強く押せばまだ痛い。
_ ワクチン(モデルナ)の副反応としてあげられているものについて振返ってみる。 まあ副反応としてあげられているものの多くは日常生活で普通に 起きうるものなので、副反応が原因なのかは分からんが
_ ブラウザで使っているのだがけっこうな頻度でreloadに失敗する。 そういったケースではURLから入れなおすと普通にアクセスできる…はずなのだが 昨日あたりからブラウザを起動しなおしたり何をしてもアクセスできなく なってしまった。
_ シーケンスを眺めてみると、初回のリクエストがNS_ERROR_DOM_ABORT_ERRに なっていて、レスポンスがまったく取れていない。この症状で検索してみると、 app.slack.com のブラウザ内のStorageを消すといい、と言っている例が いくつか見つかった。それらの例ではストレージが2GBとか巨大になっていた。 そして私の環境でも2GBになっていた。INT_MAX超えてしまったので まずいのかな。それにしても2GBって… 消す気が最初からないということだろうか
_ アサヒビールがBEERY (リンク先20禁…Firefoxで見ると背景が白くなっていて文字がほとんど読めない) というのを出していて、これがアルコール分0.5%らしい。 0.5%の違いによってノンアルコールビールとは別次元のおいしさになった… とまでは思わないけど、確かに残り0.5%をなくすことで失われる別の何かを 感じさせる程度の差はある。
_ 黒い缶の次に白い缶 (香るクラフト) が出て、 こちらはホップ増量のものらしい。黒いほうは、 普通のラガービールのかわりとして飲めるなーと思いつつ少々の物足りなさを 覚えたりするのに対して、 白いほうは、IPAのかわりとして満足できる程度においしいと思った。
_ アルコール分1%未満というと、 以前から BREWRYとホッピーは大変によいものだと思っており、 こうやって選択肢が 増えるのはよいことだと思う。 BREWRYはあんまり近所では売ってないし、 ホッピーは瓶なのであまり溜めたくないという問題はあるが、 それに比べるとBEERYは大変にお手軽であるのもよい。
_ 昨日はほとんど寝て過ごしたところ、夜中に目が覚めてしまった。 眩暈はだいぶよくなったような気がするが完全にはなくなっていない。 単に寝すぎてふらふらになっているだけかもしれないが…
_ 実験はだいたいよい結果になったのでいよいよfrei0rのフィルタとして 仕立てあげるか…と思ったのだが、実験ではunmanage/manageは1対1だったのに 対して、frei0rにそのまま持ってくると f0r_instance_t の数だけsemaphoreやら共有メモリやらが必要になり、 かといってそれぞれに好き勝手な名前をつけるわけにはいかないので、 管理用のデータ構造が必要になってしまう。 Cで配列以外のデータ構造作りたくない病に長いこと罹患しているので Cで配列以外のデータ構造は作りたくない。とりあえず配列にしておいて 困ったら別のことを考えるか…
_ そもそもf0r_instance_tの数だけ同期オブジェクトを作るのは無駄なので、 共有するべきオブジェクトはキューのような形になっているはずだ。 しかし私はCで配列以外のデータ構造作りたくない病なのでキューもできれば 避けたい。というか複数プロセスから操作されるキューなんて書けねえよ… というのはさすがに言いすぎだがpthreadをきちんと使いこなす前に Javaだとか.NETのゆるふわな世界に行ってしまったので 準備運動をきちんとしなければいけない。 というよりそういう仕掛はすでにないのだろうか？…POSIX message queueというのが あるらしい。要求はqueue、戻りの監視はsemaphoreみたいな感じにするか
_ 今日も日中はかなり暑かった。17時半過ぎても日ざしが強くて難儀した。
_ 眩暈はだいぶよくなったがだるいのは変わっていない。
_ いろいろと実験していけそうかなーということになったのでfrei0rのプラグインとして 組み込んでみた。いろいろと無駄なところはありそうだが、ひとまず毎フレーム ちょっかい出して加工するということができるようになった。 まだOpenGL側には持っていっておらずSkiaSharpで文字を出すというところまでだが、 ここまで来ればあと少しだろう。 とはいえOpenGL側にまで持ってゆかなければいけないケースは 実はそんなに多くない気もちょっとしている。3Dエフェクト、 アルファブレンディング、GLSLなどが使いたくなったときには重要かもしれないが…
_ frei0rのフィルタは加工前フレームと時刻を貰ってどうにかするというもので、 Shotcut経由で使う場合は時系列順に呼ばれるとも限らないので、 直前の状態を必要とするような処理を書くことはできない。testspriteを やろうと思うと大変ということだな…まあちょっとしたモーションタイポや トランジションであれば特に問題ないだろう。 などと考えていて気付いてしまったのだが、毎度気付くのが遅いのだが、 音についてはfrei0rのフィルタでは何もできない。なので効果音を出しながら 絵を出す、みたいなことをする場合は他の手立てと併用する必要がある。 あとクロスフェードなど、 2つのフレームをもらってきて加工みたいなことも できない。なにしろ加工前フレームは1こしか貰えないからな… あれShotcutではどうやっているんだ？要調査
_ あれこれやってきたおかげで、OpenTKで作ったフレームやその連続したものを 画像・動画にしたり、frei0rのフィルタに仕立てたりできそうなので、 あとは実際にサンプルの動画でも作りながら必要なものを作ってゆけばよいと 思っている。本当はこういう試行錯誤自体を動画にするつもりだったのだけど、 ここまで細切れの時間を合わせると10時間くらい？ は費しているような気がするので、 いくらなんでもこの進みの悪さで配信はもちろん動画化するのも無駄だろう。 そしていろいろ凝ったことをしたくなってくると、 そのための仕掛をいちいち作るよりは結局HTMLの方がよかったんじゃないかという 迷いは常にあらわれてくると思われる。
_ 今後の想定について。 1) まずShotcutの一般的な編集手段にしたがって区間(producer)を 作っていって、shotcut:commentプロパティに加工の手がかりとなる メッセージを入れる、2) mlt(XML)からそういった情報を抽出して別ファイル作る、 3) そこで実際の指示 (形式などはこれから考える) を入れてゆく、 4) frei0rのフィルタで1〜3の情報を元に加工する… みたいなことを 考えている。これならShotcutでの映像編集はそのままで、 サブタイトルなどの加工は別ファイルでやりつつ、フィルタでリアルタイムに プレビューしたりできてよいかなーと思っている。 shotcut:commentではなくfrei0rのフィルタのプロパティにする方法もあると 思うが、1つ1つfrei0rのフィルタをつけてゆく操作自体をしたくないなあと 思っているのでこのように考えている。やってみたらいろいろ問題ありそうな 気もするけど
_ 今のところF#で書いているメリットはまったくない気がする。 SkiaSharpやOpenTKはunmanagedのメモリをきちんと取り扱ってくれるので 無駄なコピーは少なくなっているはずだが、 それでも最初からunmanagedの世界にいれば不要なコピーがすでに存在するし、 SkiaSharpやOpenTKの内部処理によってはさらに無駄があるとは思う。 しかしunmanagedの世界で書いていて楽しいプログラム言語に出会えていないという 問題はとくに今でも変わっていない。
_ そういやZig というのは、開発者本人がライブコーディングをがんがんやっていて、 それを見る限りではいろいろ有能そうに見えた。が、このひと以外が 使っている様子を見たことがないので、この人の関心が他所に移ってしまったら そこで終わってしまうのではないだろうか…という気がしてしまう (仕事でやっているようだしフルタイムの従業員も雇っているようなので趣味的な 関心といった次元の話ではないのかもしれんが)。 それと関連すると言ってしまっていいのか分からんが以前 forkしたみたいだ。
_ 4連休もあっという間に終わってしまった。まとまった時間を使ってやろうと 思っていたことを進められてよかったものの、全体的にだるくて大変だった。
_ ほどよい大きさでそこまで高いものではないこのブレンダーを選んだ。 3色あって、リンゴ、ココナッツ、オレンジらしい。 せっかくだから選んだのはリンゴだ。 型番の末尾が色を示しているようで、それぞれRG、CC、ORなので、 RGとは…RINGOのこと？
_ さっそくバナナやらミカン缶…じゃなくてパウチ入りのものやら、 あと先日買ったチアシードをふりかけて、牛乳入れて粉砕してみた。 とてもおいしいので一気に飲んだところ一気に腹を壊した。 もはや牛乳を急速に摂取できるような腹具合ではないようだ。ともあれおいしかった。 ただチアシードのカケラがけっこう口に残ってよくない。 今回は乾燥したまま入れたので、 次回は水に浸して発芽？させたもので試してみるつもりだ。 タンブラーに保存用のフタがついてきているので、寝る前にチアシードを 水に入れておいて、翌日果物などを入れて粉砕、 というサイクルがいいかもしれない。あとは牛乳じゃなくて豆乳にするというのも 工夫のしどころかもしれないが…こういうジュースはやはり牛乳のほうが おいしいと感じるのでむずかしいところだ
_ 音はわりと大きくて、昔の掃除器ってこんな感じだったなあ〜と思うような音を もう少しうるさくしたような感じがする。早朝夜中に使うのは無理そうだ。
_ 夜になって風が少し強くなってきた。あとちょっとだけ雨が降っている。 明日のお昼くらいまで台風の影響は続くようだ。 そんなに強い台風ではないようだけど
_ TrueNAS COREやめてUbuntuにしようか…という話をずっと保留にしていたが、 せっかくストリーミングに絡んで環境構築しているところなので一緒に 取り組むことにしようかなーと思いはじめた。 Ubuntuにすればデスクトップ環境としても使えるので事務所で使っている ぷにぷに (VAIO Duo11)のかわりにできそうとか、Dockerを遠慮なく使える、など いろいろメリットがありそう。 NAS単体として見た場合のTrueNAS COREのよさを捨てるのは もったいない気もしつつ、ZFSをさわって10年くらいたつのでストレージの トラブルシューティングができる程度の経験は積んだかなー (フラグ) と思う。
_ ブート用のディスクとプール用のディスクが それぞれ2台ずつあるような、TrueNAS COREを使っているときと同等の構成で raid1を組みながらRoot on ZFSを構築する、というのは以前VMで 予行演習したことがあった。 手順そのものは Ubuntu 20.04 Root on ZFS - OpenZFS documentationに書かれているのでその通りにやればよい… のだが、 どうもGRUBまわりでやっていることの全貌や意図が見えないままだったので あらためてドキュメントをきっちり読みなおしてみた。当時とは 手順がちょっと変わっているみたいで、いろいろ加筆修正されていたので ようやくやりたかったことが理解できた。気がする。これなら故障時の 対応もできそうだ。
_ あとバックアップを含めた体制を考えるときにちょっと気にかかるのがZsysの存在だ。 OpenSolarisのBoot Environmentみたいなことをやってくれているのは 分かるのだが、他にもいろいろやっていそうで、それをきちんと理解しないまま あれこれいじるのはよくないような気がしている。それでいて Zsys自体のドキュメントがほとんどないので全貌が分からない… と思ったら作者本人のblogで 複数回に分けて解説していた。これはこれで分かりやすくてよいのだけど、 ドキュメントの代わりになるかというとそうでもない…気がする。
_ ZFSまわりの管理の仕組、とくにバックアップやレプリケーションに関係するものは 他にもいろいろあるので、人によってはZsys無効にしてSanoid使おうぜ、 みたいなことを言っている人もいる。私自身はZsysに救われたケースは とくにないし、何者にも替え難いほどの価値を感じているわけではないものの、 自力で構築しようと思ったら大変な仕掛に見えるので、よく作ったなーという 気持があるし、それを作って標準としてゆこうという意思が見えるので きちんと理解してきちんと使ってゆこうとは思っている。まだdatasetの 標準構成やZsysの作りについては今後大きく変わる可能性もありそうだけど、 関係している人達はZFSを運用するにはどうすればいいのかを 一生懸命考えていて、確実によいものになっていると思うので、こちらも 積極的に使っていって評価するようにしてゆきたいもんだ、と思う。
_ Zsysでカバーできない部分は他のツールを使うことになるのだが、 できればZsysがやっていることをきちんと考慮したものの方がいいと思う。 最近は先程も名前を出したSanoidが人気らしい。 私は以前はZnapzendを使っていて、ローカルとレプリケーション先で スナップショットのサイクルを変えられたり、設定ファイルがなくて 全部プロパティだったりといったデザインが気に入っていたのだけど (特に前者)、 Sanoid (Syncoid) だとそういった細やかさはなさそうに見える。
_ Sanoidは使わずにSyncoidだけを使うという ソリューションのひともいるようだ。 スナップショットの管理はZsysやzfs-auto-snapshotにやらせているらしい。 Syncoidの同期の仕組はきちんと見ておいたほうがいいかもしれんなー、 ただSanoid/SyncoidはPerlで書かれているらしい。Znapzendもそうだった。 Perlは決して読み書きできないわけではないんだが、 他のプログラムよりも読むときにいろいろ消耗してしまい、 最終的には脳がもじゃもじゃになってしまう…のであまり長時間見ることはできない。
_ 雨風はほとんど強くなっていない。今日の夕方〜夜にかけて近付いてくるようだが、 予報ではほとんど雨は降らないようだ。どうも進路がけっこう北に寄ったようで、 東北あたりに上陸するようなコースになっているようだ。
_ 今朝もブレンダーでジュースを作った。 今回はきちんと水に浸したチアシードにしてみたがやはり口に残る。 最初から粉砕するのをあきらめて別盛りにするのがいいのだろうか… 粉砕した方が消化吸収にはよさそうな気もするが
_ だるいのは寝ている最中もエアコンをつけているというバチあたりな行為に 原因があるのではという気がしつつリモコンを眺めていたら「冷房省エネ」なる ボタンがあることに気づいた。押してみると設定温度が30度になった。 30度で冷房…？ 近くで手をかざしてみると、わずかに温度の低い風が 吹いているような…まあ扇風機と併用すれば眠れないこともないのでこれで 寝てみた。室温は29度弱
_ 寝起きがとくにすばらしかったわけでもなく、そしてけっこう寝苦しかった。 そもそも30度に設定する意味がわからんのでマニュアルを読み直してみた。 どうやらこのボタンは、設定温度を+2度して、風向を上下に揺らすような機能らしい。 風が流れていると涼しさを感じるので設定温度高目でも大丈夫なのです。 ということらしい…。
_ 設定温度が30度になったのは、もともとの設定が28度だったから それを+2したということなのか。設定温度28度でも外気温が高くなると ガンガン冷やしてきて、結果室温が22度台になっていたりするので 設定温度との相関がよくわからん。結果、日が出てきて気温が上がると 寒くなってきて、朝方には足が冷えきっているなんてことも
_ PDFを読んだり書いたりする用事が出てきたので 以前触ったiTextSharpを 使おうとおもったらそっちはもう古いのでitext7-dotnetにしましょうねという ことらしい。ライセンスがAGPLか…昔からそうだったかしら？ サーバサイドで動かす予定はないし別にAGPLを受け入れてもいいんだが、 仕事で使うとなると気をつかいそうだ
_ iTextSharpの頃に比べると構造もいろいろ変わっているようだ。 PdfDocumentとDocumentというのがあって、後者はわりとドキュメント構造を 意識した組版みたいなこともできそうに見える。まあ今回は自分の望む位置に 線を引いたり文字を置ければいいのでそちらは不要な気もするが…
_ そういえば私はAdobe嫌いなくせにPDFを使わないことに対する 努力をあまりしていないなあ〜と思った。読み書きにAdobeのソフトを 使わないとか、動的なやつを相手にしないとかでひとまず 妥協できているのかもしれない…が、せめて自分が作るものだけはOpenXPSに します…みたいなことを考えたことがなかった。 サードパーティのライブラリもあんまりないようだし、 Microsoftはクロスプラットフォーム化する気がないように見えるし…
_ 以前見た Procrastinationの話の中で、一生を升目で区切って自分が 人生のどのくらいのところにさしかかってきているのかを意識するという 話 (なんでそんなことをしなきゃいけないのかは動画の最後の方で話している) が 出てきて、ああこれは自分でもやったほうがいいかもしれない…ブラウザで いつでも見られるようにしたらいいのかな…などと思いながら2年くらい放置していた。 少し隙間の時間ができたのでやってみた。
_ グリッドレイアウトというとなんかそれっぽいCSSフレームワークを 使わないと大変なのかと思ったら、最近のCSSでは 普通にサポートされて いるようなので、それを使って升目を つくってみた。誕生日と現在時刻を元に、 1マス1ヶ月で80年分のマスを作り、過去・現在・未来を色分けして表示…という感じで だいたいイメージ通りのものができあがった。 できあがったものをLifetime mapという名前にしたのだが、 そこまでできあがってからあらためて動画を見直してみたところ、間違って 記憶しているところがあり、まず名前はLife Calendarだった。それから 1マスは1週間で、90年分の升目を作るらしい。ただそうなるとブラウザの1ページに 表示できるサイズではなくなってしまうので、 一望できるという特徴を失ってしまっては本末転倒だと思い月単位でよしとした。
_ その後発表者のサイト経由で Storeを見たら、 LIFE CALENDARのポスターが 売られていて笑った。 笑った後、これはひょっとして一週間ごとに塗りつぶしてゆくという 目的があるのかもしれないと気付き、それなら確かに一週間で1マスというのは 合理的だと思った。 なのでこんな感じの升目のPDFを生成するプログラムを作ろう… と思い2つ前のセクションの話に至る
_ frei0rのフィルタによって 動画をF#側のSkiaSharpやOpenTKからちょっかい出せるようになったのだけど、 どうせ凝ったレイアウトの図表などを作る段になってやっぱりHTML+CSSで レンダリングしたいよぉと考えるようになるのは目に見えているので そのあたりのやりかたも並行して検討することにする。
_ CefSharpは、 CEF (Chromium Embedded Framework) の .NETバインディングらしい。 結局こういうの使わないとだめなのかなー？と思う一方で、 CEFを使うならWebGLでどうにでもできそうなので、わざわざUnmanagedの世界に 持ってくるのは無駄な気もする。
_ MicrosoftはWebView2というやつを出しており、これはChromiumベースのEdgeの コンポーネントになっているようだ。なのでCEFみたいな使いかたが できるという点では有望だと思うんだが、今のところクロスプラットフォームでは ないらしい。
_ 他にもManagedのHTML+CSSレンダラはいくつかあったのだけど、もう何年も 更新が止まっていたりで、この先使い続けることができるのかちょっと 不安になる。そこまで先進的な機能を使うことはないだろうから、実際には まったく問題ないのかもしれないが…
_ 台風は、身近なところではほとんど影響がなく通りすぎていった。 ちょっと強めの風が吹いているかなと感じられることがある程度
_ ワクチン1回目の後2週間近く経過した。しんどかったり、天気が悪かったり、 。気分が乗らなかったりで久しぶりになってしまった。
_ 今回はかなりアグレッシブにやってみた。だいたい平均10分30秒/kmというペースで、 そして左足にダメージが残った。とはいえ痛みの範囲が骨折した個所だけでなく 足首あたりまで続いているので、骨折した部分がどうにかなったというよりは、 筋を痛めたとかそういう系統の話なのかもしれない。
_ あと歩いている最中に左腕がいたくなった。無理に力を入れたからかしら？ と思ったが、よくよく観察してみると痛みは注射を打った周辺に集中しているようだった。 日常生活ではほとんど痛くないが、 まだ痛みの根っこは残っているようで、強く圧迫すると圧迫されたことによる 痛み以外の痛みを覚えることになり、そしてこうやって筋肉を酷使すると、 まだなんか訴えてくるものがあるのかもしれない。
_ 住居スペースもついに生ごみ生活に突入してしまった。 私の生活が生ごみのようだという意味ではなく、 ミックスジュースを作って飲むようになったので、そのときに 生ごみが出てしまうという話。といってもバナナの皮くらいだけど
_ 住居スペースはそんなにごみの量が多くないので、ごみ捨ては月1〜2回程度しか していない。なのでごみ袋にそのまま捨ててしまうとさすがに腐ってしまうだろう。 こういうときはどうすりゃいいのか？ 乾かす、冷凍・冷蔵する、などがあるらしい。乾かすといえば、 これまで唯一の生ごみであったコーヒー豆とかお茶パックについては 干し網で十分に乾燥させてからごみ袋に入れている。なので バナナの皮も同じように乾燥させれば…と思わんこともないが、 乾くまでの間に発する匂いによって何やら虫を寄せつけそうだし、 近隣にご迷惑をおかけする可能性が高いような気がする。
_ となると冷凍・冷蔵か… 生ごみを食品の保存と同じ場所でするというのは あまり気持のよいものではないが、スペースは十分にあるのでその点は 問題ないだろう。あとは匂い移りについてだが… このあたりはポリプロピレンの 袋を使えばなんとかなるかな？ 味付け昆布やら素焼大豆などは ジッパーがついているし外に匂いがまったく漏れないのでちょうどいいかもしれない。
_ あとは生ごみ専用の袋を用意して収集日にきちんと捨てるとか、 事務所に持ってゆくなどもあるか…。身近に買物袋が溢れていた頃は そういう袋はいくらでもあったのだけど
_ iText7-dotnetは iTextSharpの頃と比べるといろいろ構造が見直されているのは分かるが、 よりすっきりした、分かりやすくなった…とは感じられないとっつきの悪さを 感じる。.NET版はあまり力が入っていないのかも？と感じられる部分があり、 たとえばプロパティがまったくなくなり、Get〜、Set〜 だけになってしまった。 各ページを処理するときもGetPage(no) でページをとってくる感じで、 Pagesみたいなプロパティがあるわけではない、とか。 あと、stringが適切な部分でStringを使っていたり、IDisposableを 実装してないクラスが多かったり、structじゃなくてclassしかなかったり、 IDisposableを実装するときもなぜか explicit implementation をしていたり…など、 あまりC#が堪能ではなくなってしまったのだろうかと感じさせるものがあったりする。
_ まず解析する方から。テキストをとりだすだけなら サンプルはあるし、便利なクラスも存在するのだけど、そのテキストが どんな位置にどんなフォント・サイズで印字されているかというのを構造分析の 手がかりにしたいと思うと、結局そういった便利なクラスが内部でやっていることを 真似して自力でやらなければいけないという例が多い。 クラスの階層構造が馴染めずドキュメントとサンプルを何度も往復することになった。 IEventListenerを実装するクラスに〜Listenerという名前がついていたり、 〜Strategyという名前がついていたりなど、ぱっと見では理解がむずかしいような ところもあって戸惑う。理由があってそうなっているようなので、僅かな ドキュメントやコメントを頼りに理解するほかないようだ。
_ そして模倣元の便利なクラスの処理を真似しようと思うと、internalの クラスに辿りついたりで結局駄目じゃねえかと涙することになることが複数回あった。 ページを解析させるとSAXっぽいコールバックモデルで中身を追うことが できるようになり、TextRenderInfoというやつがもらえるんだが、 このテキストがどこの位置にあるのか？ を調べようとすると いったんCharacterRenderInfoに喰わせてあげて、そいつが TextChunkを継承しているので、そいつのGetLocationでとってくる… ということを しなければいけないように見えるのだが、これしか方法がないのかしら。 元々手にしているオブジェクトを別のクラスに喰わせることで 別の情報を手に入れることができる…というのはなんだか違和感があるが、 必要最小限のものだけ渡しておいて、それ以上必要ならそいつを取り込んだ クラスがinternalのあれこれを駆使して用意してくれる…というのは それはそれでひとつのデザインのやりかたなのかもしれない
_ などと戸惑いながらテキストの解析を進めていたんだが、どうもテキストが 用紙の上から順番にとれるというものでもないらしい。このあたりは 元々のPDFの内容に従っているんだろう。なので行がとれるたびに処理すればいいと 思って書いていたロジックはちょっとだめっぽい。いったんページ全体を 受けとっておいて行でソートするみたいな処理をしなければだめそうだ。
_ その後今度はPDFを生成する方に進んだ。 以前のペン習字練習用紙生成のときのことは ほとんどまったく覚えていない。座標はポイント単位らしい。 そしてy軸の0は用紙の一番下で、値が増えると上に向かってゆくという座標系らしい。 元々のPDFがそういう作りなんだろう、たぶん… Lifetime mapを作るために四角形をたくさん並べて、ラベルを作って… というのはとくに難しいところもなかった。ただメソッドによってfloat32を 必要としていたり、doubleを必要としていたりと不統一があるのでちょっと厄介。 そんなにでかい数値を扱うわけでもないし、 C#ならfloatで統一してしまえば済むような気もするが、F#で書くとけっこうわずらわしい。
_ 用紙をA3にして、プレビュー見たところ悪くなさそうなので、セブンイレブンの ネットプリントで印刷してみたところ… ラベルなどが印字されていない。 升目はきちんと印字されているのだが… これは馬鹿には見えない文字という やつだろうか？ FirefoxのPDF.jsや、UbuntuのPDFプレビューするソフトなどでは 問題なく表示されるのに。ネットプリントの登録画面が残っていたので プレビューを見てみたところ、文字が下に溜まっている？ことを発見した。 あらためて印刷された紙を見てみると、大きな文字の頭の部分だけが用紙の 下端に印字されているのを発見した。
_ いろいろtry and errしたいところだがその都度ネットプリントを しに行くのも手間だし、20円とはいえ費用もかかるし、 登録後のプレビュー画面で検証できそうとはいえ、実際に印刷しないのに 登録しまくるのはいくらなんでもまずいだろう。 ペン習字練習用紙生成のコードと見比べてみると、 BeginText()〜EndText()で括っていない、移動をSetTextMatrixではなく MoveToでやっている、といった違いがあったので、そのあたりを合わせて、 再度ネットプリントに登録してみたところ、今度はプレビューでもきちんと 文字が期待通りの位置に印字されていたので、再度セブンイレブンで 印刷してみた。升目のそばに印字している文字が小さすぎて見えん… これは口にするのも憚られるあれ(老眼)ではなく、単に文字が小さすぎて 潰れているだけのように見える。ネットプリントは用紙としてはA3が最大らしいので、 あとはレイアウトを工夫するほかなさそうだ。今の文字の位置合わせなども かなりad-hocなので、きちんとレイアウトをするように直す予定。
_ 前回の足の痛みはやはり骨折に関係するものではなかったのではないか？ とすると足のダメージを過度におそれるよりは、もうちょっと先に 進んだほうがいいような気がしてきた。だめだと思ったらまたディフェンシブな 歩行に切り替えればいいわけだし… そしていつまで杖を使いつづけるのか？という問題もある。 今のところ、仮に走れるようになっても、一定の割合でノルディックウォークは 継続してゆきたいとは考えている。やはり足への負担は少ないだろうし、 今後長く歩いたり走ったりを趣味にしつづけるなら両方やったほうがいいだろう。
_ 目下の問題としてはいつから走れる状態になるのか？という点だが、 これは試行錯誤してみないと分からん気がする。 ただ、試しに走りだしたらすぐに痛くなって、 すごすごと家に引き返す…というのも悲しいので、どう見極めをしたものか… と悶々とした後、別に杖持ったまま走ればいいだけではないかと気付いた。 ノルディックウォークを1時間くらいやっているので、その一部を 杖を使わずに走ることにして、問題なければ少しずつ時間を長くする… といったような感じ
_ そんなことを考えながら40分ほど杖を使って歩いた後、10分だけ走ってみた。 安全を考えるならポールは短かく畳んでから持って走るべきなんだろうが 面倒なのでそのままだ。足のダメージ以前に10分連続で走ること自体が 大変にしんどかった。 1年前の状態に戻ってしまった。 足の方のダメージは、自覚できるものはまったくなかった。翌日もとくに痛みを 覚えることもなかったし…こんな感じで少しずつ距離や時間を伸ばしてゆけば 回復に近づくだろうか？なお杖で歩いているときは10分30秒/km、 走っているときは7分30秒/kmというペースだった。
_ 先月あたりに妻が買ったママチャリを借りて走った。 自転車に乗るのは本当に久しぶりで新鮮。そういえば坂を登るのが 大変な乗り物だった、なんてことすら忘れていた。変速なんてなくても 別にいいだろうと昔の記憶だけで考えていたけど、今の筋力では 変速がないといろいろ大変だった。 (サドルが低いとか、ハンドルが前に来すぎていて力を入れられないといった 問題はあるのかもしれないが)
_ 以前は自転車乗っていて、空腹やらいろいろ空っぽになって全身に疲労が まわるという経験はあったけど、特定の部位が強く疲れるみたいな 感覚はほとんどなかったように思う。 が、久々に乗ったところ、 坂道に限らず普段使っていない筋肉を使うようでかなり疲れた。
_ 自転車の細かいコントロールで戸惑うといったことはなく、 無茶なスピードを出すわけでもないのだけど、それでもやはり自転車というのは いろいろ恐い乗り物だなあと、久々だからか尚更そう思った。 すいすい、軽々と進むわけでもないというのもあって、今となってはあまり 好きな乗り物ではなくなってしまっている。それに加えて やはり指の痛みがひどくなっている昨今ではハンドルを握るのも わりと辛いというのが拍車をかけているように思う。
_ とはいえ徒歩よりは圧倒的に速いし、公共交通機関を使わずに5km以上の 移動になるとさすがに常に徒歩ではしんどいので、たまには使わせてもらう予定
_ SONYのVLOGCAM(ZV-1)の次のモデルが出るらしい。 センサーはAPS-Cで、Eマウントになったらしい。 VLOGCAMはあんまり広角ではなかったらしいので自分でレンズつけかえられるというのは メリットなのかもしれない… が、あんまり重くなってもどうなのかという気が しないでもない。どっちにしても持っていないのに余計な心配だが…
_ レンズとっかえられるようになったらもはやαシリーズと変わらないのでは、 というのが第一印象だった。まあVLOGに特化したチューニングとか、 バリアングルとか、EVF省略とか、いろいろ考えられているし、そもそも αシリーズほど高くないので、デジタル一眼レフの入門機としても いいのかしら…ただ静止画はとれないこともないだろうが別に力を入れている わけでもなさそうだけど
_ デジタル一眼レフを趣味としている方はレンズの沼にはまる恐怖、なのか 快楽なのか、をよく語るわけで、私はそうなるわけにはいかないので 買うとしてもレンズ一体型のカメラかなーなどと思ってきたわけだけど、 それは次に買うのがレンズなのかレンズを交換できるカメラなのかの 違いであって、沼への距離はたいして変わらないのではないかという 無闇なおそれもあり、それでもまあ一度は触ってみたいという気もしている。
_ レンズ交換式ではなかったと思うが、大きな筐体のカメラというと、 もう20年以上前にFujifilmのDS-300という、当時プロユースだということで 出ていたカメラを触ったことがある。 富士フイルムDS-300レポートなんてのを今になって見ると、 時代の違いを痛感するわけだけど、 当時DS-7の輪郭が眠いのにたまにギザギザで (すっかり忘れていたが 当時の記録を読み直してみたところJPEGのサイズを64KB未満にするように パラメータを調整していたらしいのでギザギザの方はそのせいかもしれない) 、 そして赤がどぎつい画像しか知らなかった私にはそれでも 衝撃だったのを覚えている。 その数年後には130万画素のカメラが5万前後で普通に手に入るように なっていたけど…
_ 外で動画を撮ることを意識すると、VLOGCAMの他にも GoProがあるし、あとDJIがOSMO POCKETの後継でDJI Pocket 2というのを 去年出しているようだ。それぞれ特色があって用途によって向き不向きがありそう。 DJI Pocket2のスタビライザーの機能やその動きを見ると自撮りに特化したような 印象を受けるけどそうでもないらしい。 GoProのシリーズはどちらかというともっと苛酷な動作環境で本領を 発揮するような感じのようだ。
_ ちょっとした撮影用途なら結局のところスマホで 十分だったりするのかもしれないが…ジンバルが欲しいだとか、 なにか飽き足らないものが出てきてから、 いろんなカメラの事を気にするくらいでどうにかなるのかもしれない。