以前 lunescript の紹介記事を書いている時に、 lunescript の日本語訳がふと気になったんで調べていたんだが、 その時の Google 翻訳の結果が衝撃的だった。 <https://ifritjp.github.io/documents/lunescript/tutorial1/#headline-3> で、久し振りに Google 翻訳で lunescript を翻訳してみた。 その結果は次の通り。 めでたく lunescript の日本語訳が lunescript になった。 これは、 LuneScript が Google に固有名詞として認識されたということだろうか？ それとも、該当する単語が登録されていないから、 とりあえずそのまま表示しているだけなんだろうか？

tunnel ツールのネタを書いた時、 dot を使ってグラフを作った。 dot は手軽にグラフを書ける便利なツールだが、 レイアウト制御に難があると思う。 グラフ作成ツールの利点と欠点 dot などのグラフ作成ツールの利点には次が挙げられる。 ノードのリンクを指定するだけで、後はツールが良い感じにグラフを自動で作成してくれる。 パワポ等でグラフを作成するのと比べると、これは大きな利点だ。 そして多くの場合、ツールが作成するグラフは、それなり

go で proxy server を建てるには、 github.com/elazarl/goproxy を使うと簡単に実現できる。 https://github.com/elazarl/goproxy github の readme を見れば、簡単な使い方が載っているので特に問題はないだろう。 ただ、一点だけハマったポイントがあるので書いておく。 proxy 環境下で goproxy を使う場合の注意点 1 2 3 4 5 6 7 8 9 10 11 12 13 package main import ( "github.com/elazarl/goproxy" "log" "net/http" ) func main() { proxy := goproxy.NewProxyHttpServer() proxy.Verbose = true log.Fatal(http.ListenAndServe(":8080", proxy)) } github の readme にサンプルとして上記コードが載っている。 基本的にこれで問題ないのだが、 proxy 環境下で動かす場合には注意が必要だ。 多くの場合、 proxy 環境下

とある理由から 「Tunnel/Reverse Tunnel over websocket」 が必要になったので作ってみた。 「Tunnel/Reverse Tunnel over websocket」 が何かというと、 「websocket を tunnel にして別の TCP 通信を通すもの」だ。 「Tunnel/Reverse Tunnel over websocket」 とは 「Tunnel/Reverse Tunnel over websocket」を少し具体的にいうと、 次のような構成で通信を可能にするモノだ。 frame

技術情報を GitHub Pages で公開するにあたって、 Hugo を使うことにした。 Hugo は Markdown で静的サイトを構築するツールだが、org-mode にも対応している。 「対応」といっても、当然完全なものではない。 今回 Hugo を org-mode で使ってハマった点を紹介する。 *「TITLE は文書の先頭に書く」 hugo で使用する .org のファイルは、先頭に TITLE を書かなければならない。 .org に記載されている #+TITLE 自体は認識しているようなのだが、 それが先頭に無い限りその記事のタイトルと

raspberry pi に SSD を接続して簡易 NAS にしている。 この簡易 NAS では、 SSD を取り外ししやすいように autofs によるマウントを設定した。 しかし、SSD を接続すると PCManFM の自動マウントが動いて autofs が正常にマウントできない現象が発生した。 そこで PCManFM の自動マウントを無効化した。 PCManFM の自動マウントを無効化 ~/.config/pcmanfm/LXDE-pi/pcmanfm.conf の以下の設定を変更する。 mount_on_startup=0 mount_removable=0 これで、PCManFM の自動マウントを無効化できる。

emacs lisp の quote でハマったのでネタに書いておく。 1 2 3 4 5 6 (defvar hoge-val nil) (defun hoge-init () (setq hoge-val '(:val nil)) ) (defun hoge-set () (plist-put hoge-val :val "1")) 上記のように変数 hoge-val に対して plist-put で処理する関数を定義して、 次のようにコールすると。 1 2 3 4 5 6 7 8 (let (val1 val2 val3) (hoge-init) (setq val1 (plist-get hoge-val :val)) (hoge-set) (setq val2 (plist-get hoge-val :val)) (hoge-init) (setq val3 (plist-get hoge-val :val)) (message (format "%s %s %s" val1 val2 val3))) 最後の (message (format "%s %s %s" val1 val2 val3)) で "nil 1 1" が出力される。 てっきり、 "nil 1 nil" が出力されるものだと思っていた。 なぜなら、val3 をセットする直前に hoge-init を実行しており、 この hoge-init は hoge-val を

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 種類のラッパー関