はてなブックマーク

Vim 使いの「ブイ」(仮名)です。Vim のすゝめ改では、現代のテキストエディタについてのあらゆる話題をテーマに Vim の視点から見た話を行います。 今回のテーマは「なぜ Vim のシンタックスハイライトは遅いのか」です。 久しぶりに重い話を扱おうかと思っています。 1 Vim が遅い？ あなたは Vim でファイルを開いていて、「Vim が遅い」と感じたことはないでしょうか。 「Vim が遅い」にもいろいろな原因があり、プラグインが悪さをしていることもあります。しかし、外部のプラグインを入れていない状態でも遅いと感じたのなら、ほぼ「Vimのシンタックスハイライトが遅い」せいです。Vim のシンタックスハイライトを切れば症状は収まるはずです。 Vim のシンタックスハイライトを無効にするには、 syntax off を実行すればよいです。 それではなぜ Vim のシンタックスハイライト

今回はリダイレクト機能について書きます。 awkはリダイレクト機能があるので複数ファイルへの出力ができます。print文の後にファイル名を書くことで出力をファイルにリダイレクトできます。

皆さん御久しぶりです。Vim 使いの「ブイ」(仮名)です。 今回は Vim と暗号化機能について詳しく見ていくことにしましょう。 Vim には暗号化機能がありますが、neovim には実装されていません。それはなぜなのか、Vim の暗号化機能とは一体何なのか追っていくことに意味はあるはずです。 1 Vim の暗号化機能 Vim の暗号化機能とは、独自の暗号化を行ったテキストファイルを読み書きできる機能のことです。このファイルはファイルを暗号化したときに使用したパスワードを知っている人しか開けないので、平文のテキストファイルよりも安全になることが期待できます。 Vim の暗号化を使うには、暗号化したいファイルを開いた後に :X コマンドを実行するのが一番良いです。このコマンドを実行すると暗号化キーを確認のために二回入力する必要があります。一度暗号化を行うと、次に同じファイルを開いたときも暗号

本稿では、『UNIX Magazine』に掲載された『プログラマーの理想と現実』の連載記事を、一部修正の上再掲してきました。本誌の連載は前回の第11回で終了していますが、実際にはあと一回分、掲載されなかった原稿があるのです。今回は、本誌に掲載されなかった幻の最終回を掲載することにします。 これまでの記事と同様、執筆したのは10年以上前であり、現在の環境とは色々と異なることもありますが、プログラミングに対する心構えとしては現在でも通用するものがあると思います。 ・・・・・・・・・・ プログラムの論理構造や根本的なアルゴリズムはそのままで、ソースコードの表現をちょっとだけ工夫して実行速度を稼ぐ。私はこれを 小手先チューニング と呼んでいる。組み込みシステムなど、リソースに制約がある環境において、もう少し速くならないとすべてが水の泡というような切羽詰まった状況で使う最終兵器だ。 前回はループを速

gpg-agent は、GnuPG (GPG) においてパスフレーズによる認証状態を保持するために使用されるデーモンプログラムです。GPG における鍵管理が主な役割とはなっているものの、ssh-agent の機能の代替を行うこともできます。今回は gpg-agent を ssh-agent として使用することで、ssh-agent を使うよりもちょっと便利でちょっとセキュアに使う方法について紹介します。 ssh-agent の基本¶ さて、ssh-agent ですが、かつて学生時代にアルバイトをしていた当時「おもむろに eval ssh-agent と叩いて、ssh-add すればいい」と教わったものです。そうするとだいたいのシステムでは /tmp 以下に ssh-agent デーモンと通信するために使用される socket ファイルが作成され、この socket ファイル経由で秘密鍵を

その1：Ubuntu上でのmallocの性能について¶ Ubuntu上でマルチスレッドプログラムを開発していたところ、マルチコアCPU のマシンにも関わらずスレッド数を増やすと遅くなるという問題に遭遇しました。 あれこれ試したところ、mallocを置き換えることでスレッド数に応じて高速化するようになりました。 そこで、簡単なベンチマークでいくかのmallocの実装について性能の比較をしてみたいと思います。 比較したmallocの実装は以下のとおりです。 GLIBCのmalloc: Ubuntu Linux標準のもの jemalloc [1] : FreeBSDのmalloc。なんとなく安心して使えそう。Firefoxでも採用されている tcmalloc [1] : Googleが作った高速malloc 実験を行った環境は以下のとおりです。 OS: Ubuntu 12.4 CPU: Inte

2 合計 9496 9 -rwxr-xr-x 1 root root 986672 9月 27 2014 bash 9 -rwxr-xr-x 3 root root 30240 10月 21 2013 bunzip2 9 -rwxr-xr-x 1 root root 1713424 11月 15 2013 busybox 9 -rwxr-xr-x 3 root root 30240 10月 21 2013 bzcat 11 lrwxrwxrwx 1 root root 6 10月 21 2013 bzcmp -> bzdiff 9 -rwxr-xr-x 1 root root 2140 10月 21 2013 bzdiff ..

UNIXの発展とともに歩み続けてきた技術者集団、株式会社創夢

今回は awk,sort,uniq の組み合わせについて書きます。 awk を sort,uniq と組み合わせると同じ行がいくつあるかカウントすることができます。

この記事は、『UNIX Magazine』2004年2月号（2004年1月17日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ メモリ破壊バグとは？¶ メモリ破壊バグとは、配列に対する指標値の誤りや、ポインタ変数の誤りなどにより、意図しないメモリ領域を書き換えてしまい、以降のプログラム動作がおかしくなる、というものである。 頻繁に目にするのは、malloc()でメモリブロックを確保する際にサイズの計算を誤り、確保した領域をはみ出してデータを書き込んでしまう、というケースである。文字列のコピーを作成する際、終端のヌル文字用

「自動化されたテストはソフトウェアの保守に役立つが、テストを書くのも手間がかかる。いかに楽にテストを書くか、それが問題だ……」Vim 使いの「ブイ」(仮名)です。記念すべき 2 回目のテーマは「単体テスト」です。Vim 8.0 に大量追加された単体テスト関連の関数群。これらは何のために追加されたのか、Vim プラグイン開発での活用方法について解説を行います。 1 レガシーテスト¶ まずは、なぜ Vim にテスト関数が追加されたのか解説しなければいけません。テスト関数が追加されたのは、本体のレガシーな単体テストを置き換えるためです。 レガシーなテストとはいったいどんなものなのか、例を見てみましょう。みなさん、お手元の Vim ソースコード src/testdir/test1.in と src/testdir/test1.ok を開いてみてください。 https://github.com/vi

この記事は、『UNIX Magazine』2004年11月号（2004年10月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ プログラム開発の現場では、動作速度をもう少し速くしないとまずい、という状況に遭遇することがある。プログラムの全体的な動作が緩慢で利用者から不満が出たということもあるだろうし、一部の処理が実時間的な制約に間に合わないということもあるだろう。特に、組み込みシステムでは、限られた資源で最大の効率を発揮することが求められるため、動作速度に関する制約や要求も厳しくなり、プログラムの高速化は日常的な課題

この記事は、『UNIX Magazine』2003年8月号（2003年7月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ ここ数年、筆者はおもにUNIX系OS用のデバイスドライバを書くことを生業としている。取引先から仕様書をもらってコードを書き、動くものを納めるという職業プログラマである。この商売が成り立つのは、取引先の技術者に、デバイスドライバの開発は難しいから専門家に任せよう、という気持があるからに他ならない。 色々と周りを観察するに、世間一般の計算機技術者がデバイスドライバは難しいという意識を持っているのは、

Vimのすゝめ改 第6回Tree-sitter について Vim 使いの「ブイ」(仮名)です。Vim のすゝめ改では、現代のテキストエディタについてのあらゆる話題をテーマに Vim の視点から見た話を行います。 今回のテーマは「Tree-sitter」です。 1 Tree-sitter とは？ https://tree-sitter.github.io/t... Vimのすゝめ改 第5回neovim への Pull Request 紹介 Vim 使いの「ブイ」(仮名)です。Vim のすゝめ改では、現代のテキストエディタについ てのあらゆる話題をテーマに Vim の視点から見た話を行います。 今回のテーマは「neovim への Pull Request 紹介」です。 前回は Vim への Pull Request を眺めましたが、それ...

この記事は、『UNIX Magazine』2003年9月号（2003年8月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ デバイスドライバの開発においては、一発完動プログラミング の実践が本質的に重要であり、それがまたデバッグ段階での作業量にも大きく関係してくることは、前回述べた通りである。多くのプログラマが一発完動プログラミングを習得していてくれれば良いのだが、少なくとも筆者の見る限り、一発完動プログラミングを習得しているプログラマの割合は、年々どんどん減っているように思える。 一発完動プログラミングが習得されな

本稿では、『UNIX Magazine』に掲載された『プログラマーの理想と現実』の連載記事を、一部修正の上再掲してきました。本誌の連載は前回の第11回で終了していますが、実際にはあと一回分、掲載されなかった原稿があるのです。今回は、本誌に掲載されなかった幻の最終回を掲載することにします。 これまでの記事と同様、執筆したのは10年以上前であり、現在の環境とは色々と異なることもありますが、プログラミングに対する心構えとしては現在でも通用するものがあると思います。 ・・・・・・・・・・ プログラムの論理構造や根本的なアルゴリズムはそのままで、ソースコードの表現をちょっとだけ工夫して実行速度を稼ぐ。私はこれを 小手先チューニング と呼んでいる。組み込みシステムなど、リソースに制約がある環境において、もう少し速くならないとすべてが水の泡というような切羽詰まった状況で使う最終兵器だ。 前回はループを速

2 合計 9496 9 -rwxr-xr-x 1 root root 986672 9月 27 2014 bash 9 -rwxr-xr-x 3 root root 30240 10月 21 2013 bunzip2 9 -rwxr-xr-x 1 root root 1713424 11月 15 2013 busybox 9 -rwxr-xr-x 3 root root 30240 10月 21 2013 bzcat 11 lrwxrwxrwx 1 root root 6 10月 21 2013 bzcmp -> bzdiff 9 -rwxr-xr-x 1 root root 2140 10月 21 2013 bzdiff ..

この記事は、『UNIX Magazine』2004年11月号（2004年10月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ プログラム開発の現場では、動作速度をもう少し速くしないとまずい、という状況に遭遇することがある。プログラムの全体的な動作が緩慢で利用者から不満が出たということもあるだろうし、一部の処理が実時間的な制約に間に合わないということもあるだろう。特に、組み込みシステムでは、限られた資源で最大の効率を発揮することが求められるため、動作速度に関する制約や要求も厳しくなり、プログラムの高速化は日常的な課題

この記事は、『UNIX Magazine』2003年12月号（2003年11月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ C言語では、コンパイルの前にプログラムの字句を置き換える機能— マクロ 機能 が利用できる。マクロは確かに便利なものではあるが、バグを招きやすいことも事実で、巷では功罪が論じられている。 C++言語にはまだマクロが残っているが、JAVA言語にはもはや存在しないことからもわかるように、マクロは本質的にはプログラムのアルゴリズム記述に必須の機能ではない。にもかかわらず、マクロを一切使用していない

この記事は、『UNIX Magazine』2003年10月号（2003年9月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ プログラムのデバッグについて、実際の開発に役立つ事柄が書かれた書籍や記事には、あまりお目にかかったことがない。では、「おまえは書けるのか」と問われれば、やはり書けないと答えざるを得ない。 もし、今ここに現実のバグ現象があり、これを一体どのように克服すべきか、という議論を開発担当者と膝を付き合わせてやる、ということであれば、いくらでも話はできる。しかし、あらたまって「デバッグとは」と始めると、途

この記事は、『UNIX Magazine』2004年8月号（2004年7月17日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ デバイスドライバや組み込みファームウェアの開発を担当しているあなた、またはこれから担当するかもしれないあなたへ、格言をひとつ。 割り込みは来ない これは、デバイスドライバやファームウェアの開発にあたる技術者が持つべき心構えを説いたものだ。肝に命じておこう。 事実、私が担当したデバイスドライバやファームウェアの開発で、最初から正しく割り込みが来たケースはほぼ皆無だ。最初は必ず「割り込みが来ない！」

著者プロフィール asou 好きな OS は、FreeBSD です。が、最近購入した Mac mini がなかなか快適なので、Mac でいいかなと思うようになってきました。 連載一覧Blog Series Tabulator tips naka2020.07.29 更新 Vimのすゝめ改 v2021.07.21 更新 Vimとセキュリティ問題 v2019.02.01 更新 プログラマーの理想と現実 tom2015.07.08 更新 フレッツ光ネクスト用IPv6 PPPoEアダプターを作ってみる ko2012.12.05 更新 Gfarm takuya2013.10.17 更新 asou2018.10.03 更新 机上デバッグ asou2013.03.06 更新 Apache Solr で全文検索 toza2013.09.04 更新 自炊本をスマートフォンで読むための convertガナス

Vimのすゝめ改 第6回Tree-sitter について Vim 使いの「ブイ」(仮名)です。Vim のすゝめ改では、現代のテキストエディタについてのあらゆる話題をテーマに Vim の視点から見た話を行います。 今回のテーマは「Tree-sitter」です。 1 Tree-sitter とは？ https://tree-sitter.github.io/t... Vimのすゝめ改 第5回neovim への Pull Request 紹介 Vim 使いの「ブイ」(仮名)です。Vim のすゝめ改では、現代のテキストエディタについ てのあらゆる話題をテーマに Vim の視点から見た話を行います。 今回のテーマは「neovim への Pull Request 紹介」です。 前回は Vim への Pull Request を眺めましたが、それ...

この記事は、『UNIX Magazine』2003年11月号（2003年10月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ プログラムに入り込むバグは、大きく2種類に分けることができる。 一つは、プログラムの処理方法や手順が、意味的に目的を満足するものではなかったというもので、プログラムの目的や実装するアルゴリズムに対する理解が足りなかったり、事前検討が不十分であった場合に起きる。便宜上、このタイプのバグを アルゴリズムバグ と呼ぶことにしよう。 もう一つは、プログラムの意味は正しいものの、なぜか想定外の動作をし

この記事は、『UNIX Magazine』2003年9月号（2003年8月18日発売）に掲載された同名記事の初稿（著者から編集部に提出したもの）を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。 ・・・・・・・・・・ デバイスドライバの開発においては、一発完動プログラミング の実践が本質的に重要であり、それがまたデバッグ段階での作業量にも大きく関係してくることは、前回述べた通りである。多くのプログラマが一発完動プログラミングを習得していてくれれば良いのだが、少なくとも筆者の見る限り、一発完動プログラミングを習得しているプログラマの割合は、年々どんどん減っているように思える。 一発完動プログラミングが習得されな

著者プロフィール tom 当社設立直後に入社して約30 年、UNIX の移植、日本語化、デバイスドライバ開発、周辺機器ファームウェア開発などに継続的に携わり、現在も現役でUNIX 系OS の移植、改造などの開発業務を行う。社内でもっともプログラムを書いている人の一人。代表取締役社長。