投稿

Type 3 フォントが埋め込まれた古い PostScript データになっている論文をそこそこ綺麗な PDF にする

これを使う。 CTAN: Package pkfix 以下利用例(論文ではないけれど) $ pkfix-helper Lions\ -\ 1977\ -\ Lions\'\ Commentary\ on\ UNIX®\ 6th\ Edition.ps lions-helper.ps Reading Lions - 1977 - Lions' Commentary on UNIX® 6th Edition.ps ... done. Total number of Type 3 fonts encountered: 16 Bitmapped fonts are typeset at 300 DPI. Finding character widths ... done. Reading TFM files ... done (103 TFMs in 193 scaling variations). Matching fonts: Processing Fn ... done (cmsl10 @ 1X, mismatch=0.53898). Processing Ff ... done (cmtt10 @ 1X, mismatch=0.19819). Processing Fg ... done (cmbx12 @ 1X, mismatch=0.36583). Processing Fi ... done (cmbx10 @ 1X, mismatch=0.42627). Processing Fk ... done (cmti10 @ 1X, mismatch=0.20169). Processing Fj ... done (cmbx12 @ 1.2X, mismatch=3.41283). pkfix-helper: Best match for Fj is rather poor Processing Fe ... done (cmssi10 @ 1X, mismatch=0.37342). Processing Fo ... done (cmr17 @ 1X, mismatch=0.12955). Processing Fb ... done (cmsl10 @ 1.2X,

時刻取得・時間計測

イメージ
本稿では,Linux カーネルで扱える時計のうち,PTP(Precision Time Protocol)という IEEE 1588 で策定されている高精度な時計をクロックソース[1]にする場合について追っていこうと思います。 Linux における時刻同期:NTP と PTP Linux や Windows,macOS といった現在の OS のシステムクロックは,一般的にはインターネットを通じて NTP(Network Time Protocol)が同期するようになっています。 NTP を使っていればインターネットに接続されている際には大きく時刻がズレることはなく,たまにネットワーク接続が失われていてもクォーツ時計は安物の振り子式ほど時間はズレません。 では,NTP は設計としてどのくらいの誤差が考えられているのでしょうか。NTP の設計者 David L. Mills 博士は自身が実装した PDP-11 向けの OS「Fuzzball」上の実験でそれを示しており,答えは数十ミリ秒です[2]。現代のマシンと OS ならば数ミリ秒までは迫れるかもしれません。ちなみにこの論文が発表された翌年には NTP version 2 が RFC から発行されています[3]。(現在は version 4。) NTP は日常的な利用には十分な精度があります。しかし,マイクロ秒やナノ秒といった単位での高精度さが目的ではありません。日本の NTP のサーバーとして有名な NICT(情報通信研究機構)は日本標準時の決定をしており原子時計も所有していますが,インターネットを介して NICT などのサーバーにアクセスしている時点でミリ秒やひどいときは数秒の遅れが発生するでしょう。LAN に NTP サーバーがあったとしても,アルゴリズムとして数ミリ秒の遅延を許容しています。そこで高精度な時刻同期のために存在するのが PTP です。 PTP とは PTP とは,ネットワークデバイス内の時計を高精度に同期する仕組みです。グランドマスタークロックと呼ばれる時計をマスターとして設置し,LAN の NIC たちがそれを元に同期するといったような仕組みになります。これによって,パケットのタイムスタンプをハードウェアで高精度に打つことが可能になったり,この PTP をクロックソースとし

コードカヴァレッジ計測

イメージ
コードカヴァレッジとは あるプログラムコードについて実行した際に、実際にコード中の命令を何割実行したかを数値に表したものを言う。 計測手法 方法は様々である。たとえば、Linux kernel の fuzzer である Google の syzkaller を用いれば、ユーザーアプリケーションへの入力を自動で変化させつつコードカヴァレッジを確認させてくれる。また、Linux kernel のコンフィグ自体にもカヴァレッジについてのコンフィグが存在する。これは masami256 さんのブログなどが詳しい 。 今回は gcc に組込みの手法でカヴァレッジテストを実行する手法についてメモをする gcov gcov がカヴァレッジ情報を .gcov という拡張子でダンプすることでカヴァレッジを確認できる。このコマンドは gcc に附属している。 使い方を見ていく このようなソースコードを用意し、次のようにコンパイルする。 $ gcc -fprofile-arcs -ftest-coverage -o cov_test cov_test.c すると次のようなファイルが用意されるはずだ。 $ ls cov_test cov_test.c cov_test.gcno これでカヴァレッジテストの準備は完了した。では、実際にカヴァレッジテストを行なってみよう。まずは、何も引数を与えずコンパイルしたコードを実行する。 $ ./cov_test ./cov_test: you need to pass arguments at least 1 $ ls cov_test cov_test.c cov_test.gcda cov_test.gcno .gcno に加えて .gcda が追加されている。このファイルがカヴァレッジテストの結果を格納している。ここで、 gcov コマンドを用いてみよう。 $ gcov cov_test.gcda File 'cov_test.c' Lines executed:38.89% of 18 Creating 'cov_test.c.gcov' cov_test.c というコード全体が 18 行で、そのうち 38.89% が実行されたということを物語っている。また、

静電容量Helix (EC Helix) NiZ スイッチ ver. ビルドログ (β2)

イメージ
前書き 兼ねてより自作キーボードに興味はあったのですが静電容量無接点式スイッチ(東プレスイッチ)の分割が実現できそうになるまでやらないと公言しておりました。以前より Custom Topre Guide など指針になるものがちらほら出てたようなのですが,今年の春先ごろ 銀鮭( @sorojake )さんが Booth で『 真の静電容量キーボードを作る本 』というものを出しているのを見掛け,どうやら PCB 設計勉強したり発注しなきゃいけないかなあと思っていたのですが,ありがたいことに Helix ベースのキットを出して貰えるということで,今回β2 版のテスターとして購入・製作しました。 長くなりましたが,次から実際に製作した過程とそのメモです。 実は初自作キーボード。 disclaimer β2 版のビルドログなので正式版とは異なる可能性があります。ご了承ください。 ビルドログ 道具・機材 静電容量Helix ラバードームタイプ(β2)キット NiZ のハウジングと軸×100 東プレ OEM キーボードのジャンクから剥いだラバードームと円錐型スプリング Hitachi 2050 という 80 年代ぐらいのワークステーション付属のものらしい。 いまならビットトレードワンさんが製作しているものを買うほうが簡単だし安いはず。 遊舎工房にも置いてあった。 これを買う場合はハウジングや軸もセットだから NiZ から何か買う必要はなし。 キーキャップ ENJOYPBT ABS Doubleshot Dolch 遊舎工房実店舗で購入 したけど,KBDFans で自分で買うほうが安いかも(ただしその場合届くまでのタイムラグがある) Pro Micro×2,OLED×2,LED (SK6812mini)×54,M2 スペーサー 8mm(OLED 保護アクリル用) いずれも遊舎工房の実店舗にて購入 アクリルプレート Helix 向け 2mm 厚(押し出し・クリア) 遊舎工房オンライン発注サービス利用 ジャンパ用銅線,絶縁テープ うっかり買うの忘れてたので製作直前で適当にホームセンターで購入 はんだこて先 (HAKKO T18-S9),フラックス (HAKKO FS

SuperH開発ストーリー

かつてルネサスのサイトに掲載されていたが消滅してしまい,Internet Archive にもアーカイヴされていないがウェブ魚拓には残っていた。しかし話数とそのリンクを一覧するのが面倒なため以下にメモしておこうと思う。 第一話 第二話 第三話 第四話 第五話 第六話 こういうドキュメントは大切なので消さないで欲しいなあ……。

Line of Code (LoC) の計測

LoCの計測で一番簡単だと思われるのは次のような方法である。 find ./src -type f -name '*.c' -o -name '*.h' | xargs wc -l この例では ./src ディレクトリに含まれる C 言語のソースファイルとヘッダファイルについて全て wc(1) に食わせて行数を出力する,といったことを行なっている。 しかしこれでは,プロジェクトで利用する言語が増える度に find(1) のオプションを調整しなければならないし,コード内の空行やコメント行を全く考慮しない。 cloc そこで,実は cloc という便利な LoC 計測ツールがあるらしい。 https://github.com/AlDanial/cloc このコマンドでは,単純にプロジェクトのディレクトリを引数として渡すと,どういう言語がどのくらい使われており,それぞれに含まれる空行とコメントはどのぐらいか,といったことを一覧表示してくれる。 しかし,私はLinux kernelにおける各サブシステムがコード全体のうちどのぐらいを占めているかを知りたかったため,次のように cloc を実行した。 cd /usr/src/linux/ for dir in $(find . -maxdepth 1 -type d ! \( -name '.*' -o -name 'Documentation' -o -name 'LICENSES' -o -name 'samples' -o -name 'scripts' -o -name 'tools' \)); do echo $dir cloc $dir done > ~/linux_loc.txt すると linux_loc.txt には次のような出力が得られる。 ./arch 16005 text files. 15902 unique files. 4299 files ignored. github.com/AlDanial/cloc v 1.72 T=28.79 s (406.7 files/s, 90104.3 line

GitHub で一番古いコミットを辿る

git clone したレポジトリを開いて git log でも眺めれば済む話なんですが,ちょっとコードが気になったとき Web ブラウザから閲覧してて最初のコミットはいつか,なんて気になったときにいちいち clone はしたくない。 そういうときは次の手順で古いコミットが確認できます GitHub の該当プロジェクトのページから「Insights → Network」を開く 「Shift + ←」あるいは「Shift + h」で一番古いコミットまでカーソルを移動 グラフ上の該当ノードをクリック ただし,cVim のような Vim 互換のキーバインドをブラウザに導入する extension を入れてるとキーバインドがこっちに取られるので微妙に上手くいかないこともある。 追記 モバイル端末のひとはがんばってスクロールしてください(コミット歴のページで Older をタップしつづけるよりかはマシかもしれない)