emacs の org-mode では、 .org ファイル内に C や python 等ソースコードを書いて、 export 時にそのソースコードを色付けした状態で載せることができる。 この機能を babel と言う。 babel では、ソースコードの色付けだけでなく、 dot や plantuml 等のグラフ生成言語を利用することで、 .org ファイル内に書いたグラフ生成言語からグラフを生成して、 所定位置にグラフを挿入することもできる。 今回、 org-mode 9.3.5 の babel を使って dot の画像を出力しようとしたところ、 エラーしたので原因を追ってみた

この記事は、emacs 用 reviewboard モードの宣伝である。 <https://github.com/ifritJP/emacs-reviewboard-front> reviewboard は、ソースコードレビューを Web 上で行ない記録するためのツール。 今は github の Pull-Request に代表されるように Web 上のソースレビューが普及しているが、 reviewboard の初版が 2007 年であることを考えると、 当時は先進的なツールだったと思う。 そんな reviewboard を emacs で操作するモードを今になって作ったので、 どれ程の人が使うかは不明だが、折角なので宣伝しておく。 機能 このモードでは、次の機能を提供する。 修正ファ

プログラムを組む際、ラッパー関数を作ることは良くある。 このラッパー関数のオーバーヘッドが気になったので簡単に調べてみた。 計測用サンプルは次の通り。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #include<stdio.h> typedef void (func_t)( int val1, int val2 ); void func( int val1, int val2 ) { printf( "%d %d", val1, val2 ); } void wrapper0( int val1, int val2 ) { func( val1, val2 ); } void wrapper1( func_t * pFunc, int val1, int val2 ) { pFunc( val1, val2 ); } void wrapper2( int val1, int val2, func_t * pFunc ) { pFunc( val1, val2 ); } main() { wrapper0( 0, 1 ); wrapper1( func, 0, 1 ); wrapper2( 0, 1, func ); } 関数 func() をコールする 3 種類のラッパー関

以前 C 言語の関数ポインタによる関数コールのオーバーヘッドがどの程度なのか調べたが、 今回は可変長引数(va_list)処理のオーバーヘッドについて調べてみた。 結果 初めに結果から書くと、 可変長引数(va_list)処理のオーバーヘッドは、めちゃめちゃ掛る。 また、引数の数に応じて時間が増加する。 所感 今回の実験によって、 va_list 処理には当初の想定を遥かに越えたオーバーヘッドが かかることが分った。 個人的には、コン

「日本の全てのソフトウェアプロジェクトは必ず技術的負債になる」というタイトルですが、 次の条件を満す場合に限ります。 「プロジェクトに関わるソフトウェアエンジニアの大半が技術に無関心」 動機 このネタは、次の記事を読んで個人的に思うことがあったのをきっかけに 書いています。 オブジェクト指向プログラミング – 1兆ドル規模の大失敗 <https://okuranagaimo.blogspot.com/2019/07/1.html> 大企業の技術系インターンシップに参加した <https://blog.browniealice.net/post/internship2019winter/> ソフト開発で世界と闘った及川卓也氏が見た

emacs のバージョンを 26.2 に変えたことで、 色々と細かいところの使い勝手が変っている。 その中で、 → 等の一部のフォントが半角表示されるようになったのが 微妙にストレスだったのでちょっと追ってみた。 原因 原因、と言うよりは起因と言った方が良いかもしれないが、 → 等の一部のフォントが半角表示されるようになったのは、 フォントに "DejaVu Sans Mono" を使用していることに起因していた。 これを "Bitstream Vera Sans Mono" に変更することで、現象が治った。 全く同じ環

これは seekable な stream と none_seekable な stream の使い分けに関する記事です。 使い分けが十分出来ている人は読まなくても大丈夫です。 皆さんは bitstream という単語をご存知でしょうか？ AV (Audio&Visual) が好きな人や、 それらの業界に関係のある人ならそこそこ聞く単語だと思いますが、 一般的にはあまり馴染の無い単語でしょうか。 馴染の無い人の為に身近な HDD レコーダを例に挙げて説明すると、 HDD レコーダはデジタル放送の電波に乗っているデータをそのまま記録していますが、 この

コレ を作るにあたって、データの serialize/deserialize の方法を調べた結果、 marshmallow_dataclass に落ち着きました。 いくつか調べた中で、パッと見、直感的に出来そうだった、というだけの理由ですが。。 実際、面倒な処理はほとんど無く、 serialize/deserialize が可能になりました。 使い型 marshmallow_dataclass は、 クラスを宣言する際に @dataclass デコレータを付けて宣言し、 メンバの型を宣言するのが基本です。 こんな感じ。 1 2 3 4 5 6 7 8 9 10 @dataclass class LogItem: # ゲームタイトル title:str # 日付 date:int # テキスト text:str # テキスト長 len:int メンバの宣

4 月頃から、英語のレベルを上げるため参考書を買って勉強をしている。 その参考書を使った最低限の基礎英語の復習は終ったので、次のステップに進むことにした。 基礎が終った後の学習方法には何が良いのか色々と調べてみたが、 色々な意見があるが最終的には「持続できるものが良い」というのが結論のようだ。 まぁ、「持続すること」が英語学習で最も難しいことは、 私自身が何度も挫折した経験があるので認識している。 そもそも、先

だいぶ前に買って放置していた Raspberry pi zero w をセットアップしました。 Raspberry pi zero w と言えば「小型軽量」が売りなんで、 今回はポータブルな IOT デバイスとして使う事を目的として、 Bluetooth の機能(ファイル転送、 IP over Bluetooth) のセットアップをしました。 イマドキ Bluetooth なんて、 最新のイメージでセットアップすればすぐに使えるだろうと思って余裕でした。 しかし、実際には目的の機能が動作するまでに、かなりの時間が掛ってしまいました。 少なくとも、パッケー