本記事は Vim Advent Calendar 2013 の 47 日目の記事です。 46 日目は @zoncoen さんによる、Unite-autojumpをつくった でした。 今回は地味に便利なあの機能です。 まとめ :help gR :help Virtual-Replace-mode よくある話 あなたが不幸にも以下のようなコメントに出会ってしまったとします。 /********************************************/ /* */ /* 関数の処理: */ /* 2014年1月16日 氏名 */ /* */ /********************************************/
2014-01-20 CPSで実装したモナドは何故速いのかモナド変換子の速さを測ってみる - モナドとわたしとコモナドCPSでモナドを実装すると速くなるらしい。以前、その理由について考えてみたのだが、結論に達しなかった。そこで、続きを書く。まず、Twitterである方に教えていただいたのだが、CPSで実装したモナドは、非CPSで実装したモナドに比べて次の2点の理由により高速であるという。データの生成/分解が抑えられるから合成時に継続を破棄できるからどういうことなのだろうか。Maybeモナドを例として以上の2点を確認したい——。と、確認したかったのだが、検証したところ、1点目については結論を得たものの、2点目については「速くならない」という矛盾した結論が出てしまった。そこで、以上の1点目についてのみ検証した記録をつける。非CPS版Maybeモナドまず、非CPS版のMaybeモナドの定義は以下
この記事はVim Advent Calendar 2013の42日目の記事になります。 Neocomplete.vimのfile_includeを使いこなす さて、今回の記事ではneocompleteのfile_includeを使いこなしてみます。 file_includeとは、ファイルパスを補完してくれるアレです。file補完との違いは、特定のキーワードや変換を含んだ補完が出来る点です。 キーワード(requireや#include)があると補完が始まり 指定されたパスの中から候補を探し、変換して表示します。(例:system.os) 内部では、path, include, includeexprなどが使われています。(pathの参考 –> Vim中級者を脱する Path編) neocompleteを拡張する file_includeを拡張する際には、neocompleteの設定をしてあ
Understanding Pointers, Ownership, and Lifetimes in Rust published on December 21st, 2013 Update 2015-03-15 I have updated this post to reflect the new syntax for boxes or owned pointers in in rust 1.0. In the last couple of weeks I have been looking into Rust, a new language developed by the good folks at Mozilla. Rust is fairly unique in that it is aimed at the same space as C++: a systems progr
Memory management is the heart of operating systems; it is crucial for both programming and system administration. In the next few posts I'll cover memory with an eye towards practical aspects, but without shying away from internals. While the concepts are generic, examples are mostly from Linux and Windows on 32-bit x86. This first post describes how programs are laid out in memory. Each process
What are the stack and heap? Where are they located physically in a computer's memory? To what extent are they controlled by the OS or language run-time? What is their scope? What determines their sizes? What makes one faster?
© 1984-2024 British APL Association All rights reserved. Archive articles posted online on request: ask the archivist. K by Arthur Whitney Introduction K is the executable notation at the heart of a high performance programming platform. It is designed for analyzing massive amounts of real-time and historical data – ideal for financial modelling. K is fast, comprehensive, accessible and productive
Kona What is Kona? Kona is the open-source implementation of the k3 programming language. k is a synthesis of APL and LISP. Although many of the capabilities come from APL, the fundamental data construct is quite different. In APL the construct is a multi-dimensional matrix-like array, where the dimension of the array can range from 0 to some maximum (often 9). In k, like LISP, the fundamental dat
Continuing my work on my PhD, I found the need for a hash function. Of all the options available, I've found that MurmurHash has been a good fit for my use case. Unfortunately there wasn't yet a Haskell wrapper for the C++ implementation, so I decided to create one. For the impatient the library is available on Hackage under Dish, MurmurHash3, API Documentation is also available. When interfacing
Rewrite rules are a powerful tool that you can use to optimize Haskell code without breaking backwards compatibility. This post will illustrate how I use rewrite rules to implement a form of shortcut fusion for my pipes stream programming library. I compare pipes performance before and after adding shortcut fusion and I also compare the peformance of pipes-4.0.2 vs. conduit-1.0.10 and io-streams-1
Vim Advent Calendar 2013 の 49 日目の記事です。 Vim script は行指向、もっと言うとコマンド指向の言語です。そう言った点で、シェルスクリプトに近いです。 Vim script if hoge ==# "HUGA" " if コマンド " ↓echo コマンド echo 'hi' endif " endif コマンド シェルスクリプト if [ "$HOGE" = "HUGA" ] # if コマンド then # then コマンド echo hi # echo コマンド fi # fi コマンド シェルクリプトの if なんかは if コマンドとは呼ばないかもしれないですが、そういう風にも見れるということで。 さて、行指向と言っても、1行が長くなったら途中で折り返したいものです。 シェルスクリプトでは行末に \ があると、次の行は現在の行の継続行とみ
「O/Rマッパー」や「ORM」と聞くだけで顔をしかめる人もいらっしゃいます。たぶん過去にひどい目にあったんでしょうね。その大きな理由の一つがパフォーマンスでしょう。 一昨年のYAPC::Asiaに参加したとき、ORMは使うなという話を4回くらい聞いたのが印象的でした。DBのデータはハッシュで返すか、DBIをそのまま使うほうが良いと。弊社でもパフォーマンス上の問題をわかりづらくしてしまうことから、ORMを使用しないプロジェクトがいくつかあります。 まあ、そりゃDBI使うほうが高速に動くとは思います。 しかし、僕が使っているのは実用的な言語であるCommon Lispです。実行効率と抽象化がとても得意な言語です。さらに優れたオブジェクトシステムであるCLOSも仕様に含まれています。 そこで、既存のO/RマッパーにCommon Lispらしさを加えてみるとどうだろう。 そう思って作ってみたのが、
Here is a question and answer stolen from another website: “I have [an] nginx log file, and I want to find out market share for each major version of browsers. I am not interested in minor versions and operating systems.”(http://serverfault.com/questions/89773/get-list-of-user-agents-from-nginx-log). The answer that got accepted was one of those Jedi like answers that showed the power of true Unix
import .baconとかfrom . import egg とかの書式ってなんなんだ?という疑問を小耳に挟んだので、なんかがんばっちゃうよ。 spam/egg.pyからspam/bacon.pyをインポートするときって、import baconとか書いちゃうよね。 だが、ちょっと考えてみて欲しい。 bacon.py spam/egg.py spam/bacon.py こんな構成の場合はどうなるだろう。 spam/eggからimport baconすると、 このときのbaconは、spam/bacon.py だ。 このとき bacon.py は、spam/bacon.pyにかくされてしまっている。 じゃあ、トップレベルにあるbacon.pyはどうすればインポートできるのか? こうした問題を解決するのがPEP328 http://www.python.org/dev/peps/pep-0
背景 Python 2 用のコードを書くときは、 Python 3 対応を見越して # -*- coding: utf-8 -*- from __future__ import division, print_function, absolute_import をテンプレとして書いています。 __future__ はファイルごとにバラバラだと混乱を招くので、今関わってるプロジェクトでもこれを新規ファイルのテンプレとして登録してもらってます。 Python 3 の構文、リテラルを有効にする __future__ のうち、 unicode_literals だけは今まで使っていなかったのですが、ふと「あ、やっぱり使うべきだな」と思いついたので、そのへんをまとめます。 第三の文字列型 native string Python 2 には2つの文字列型 str (bytes) と unicode が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く