Unixの歴史のgitレポジトリ
dspinellis/unix-history-repo 現在入手しうる限りの情報を使って、Unixの歴史を再現したgitレポジトリを作成する試みが行われている。 1972年から2015年までの入手可能な断続的なスナップショット、レポジトリ、研究記録を元に、単一の歴史を辿れるgitレポジトリを作り上げるというプロジェクトだ。 スナップショットからはソースコードと日付を、研究記録からは貢献者とブランチを、レポジトリからはすべての情報を得て、単一の歴史というメタデータを辿れるgitレポジトリを生成する。これはUnixの歴史研究のために非常に便利だ。 ちなみに、case-insensitiveなファイルシステム上に展開するとファイルの欠落を生じるそうだ。
歌舞伎座.tech #8 「C++初心者会」を開催した
歌舞伎座.tech#8「C++初心者会」 - connpass 5月17日に、歌舞伎座.thch #8 「C++初心者会」を開催した。 今回は、勉強会の初心者が発表できる場を設けようという意図から、発表枠には、初心者枠とガチ枠を設けた。これにより初心者が積極的に発表しやすくなるはずだ。さて、問題は参加者と発表者が集まるかどうかだ。いざフタを開けてみると閑古鳥が鳴いているようでは極めて痛い。 さて、connpassで告知と募集を開始すると、参加枠が即座に埋まっていく。どうやら勉強会の需要はあるようでまずは一安心だ。発表枠も埋まり始めたが、その参加者を見ると、どうも、技術的、勉強会的にみて、初心者とは思われない。 さて、公開直後の参加申し込みの波がひけてみると、参加枠と初心者枠は埋まっているものの、ガチ枠が埋まらない。どうやら、みなチョットデキル的な謙遜精神を発揮してしまったようだ。仕方がない
C++標準化委員会の文書集、2015-04 pre-Lenexa mailingsのレビュー: N4381-N4389
C++標準化委員会の文書集、2015-04 pre-Lenexa mailingsのレビュー: N4381-N4389 ISO/IEC JTC1/SC22/WG21 - Papers 2015 N4381: Suggested Design for Customization Points 現在、C++の標準ライブラリにはいくつかのユーザー側で挙動を変更できる箇所が存在する。 swap begin end だ。文面の解釈次第では、iter_swapも該当するかもしれないとのことだ。 論文は、標準ライブラリのうち、これらの挙動を差し替え可能な部分を、カスタマイゼーションポイント(Customization point)と名づけている。 この関数テンプレートは、std名前空間で定義されていて、汎用的な実装になっている。もし、独自のユーザー定義型に独自のswap/begin/end実装を書きたい
D4492: Bjarne StroustrupによるC++17の考察の翻訳
April 2015 : Standard C++ C++WG内部のMLで議論していた内容が、どこからか外部に流れて、様々なフォーラムで話題になっている。 “What will C++17 be?” -- Bjarne Stroustrup on C++17 goals : programming What will C++17 be? | Hacker News C++ Daddy Bjarne Stroustrup outlines directions for v17 • The Register Forums これを受けて、Bjarne Stroustrupは議論をまとめて標準化委員会の論文として公開することにしたが、それも時間がかかるので、ドラフトがC++財団にあがっている。 [PDF注意] D4492 C++17の考察 Bjarne Stroustrup このドラフトはLexe
InfoQのC++17についてBjarne Stroustrupへのインタビュー記事の翻訳
Stroustrup: Thoughts on C++17 - An Interview C++の設計者にして最初の実装者であるBjarne Stroustrupは、C++17の設計と新機能の議論の起爆剤となるための、ドラフトを公開した。Stroustrupによれば、C++17は以下の3つの設計目標がある。 巨大な依存関係のあるソフトウェアのサポートの改良 並列実行に高級なモデルのサポートの提供 コア言語を簡単にする 上記の設計目標について、StroustrupはC++17に入る以下もしれない機能を列挙した。Stroustrupの好ましいと考える機能の例が以下だ。 モジュール、ローカル性とコンパイル時間の改良 契約、仕様の改良 型安全union、関数型プログラミング風のパターンマッチを土台にしたものになるだろう コンセプト レンジ 統一関数呼び出し記法、仕様とテンプレートライブラリ利用を簡
Jacob Kaplan-MossのPyCon 2015における基調講演: プログラミングの才能という都市伝説
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTube The programming talent myth [LWN.net] PyCon 2015で、Djangoの貢献者であるJacob Kaplan-Mossが興味深い基調講演をしているので紹介する。LWM.netでほぼ全面書き起こしに近いまとめがあったので助かった。 自己紹介 Kaplan-MossはDjangoの貢献者であり、Herokuのセキュリテイ部門の部長である。PyCon参加者としては歴史が長く、その他のカンファレンスでもよく発表している。Pythonコミュニティは「自分にとってこの業界におけるとても重要なもの」であり、PyConの基調講演を行うということは、「自分のキャリア上の絶頂」である。 自分の最初のPyConの発表は2005年のことで、PythonとAppleScri
constexprで非定数式の状態を保持
Non-constant constant-expressions in C++ なんと、C++のconstexpr関数を呼び出すたびに戻り値を変える方法があるという。つまり、以下のstatic_assertが引っかかるコードだ。 int main () { constexpr int a = f (); constexpr int b = f (); static_assert (a != b, "fail"); } なんと、constexpr関数は状態を保持できる計算能力を備えているというのだ。 fはconstexpr関数である。 読んでみたところ、要するにこうだ。 noexcept演算子はオペランドが定数式かどうかを判別するのに使える。 // exprが定数式であればtrue constexpr bool b = noexcept( expr ) ; 未定義の関数は定数式ではない。
本の虫: 汎用コンピュータ戦争
28c3: The coming war on general computation Transcript: transcript.md at master from jwise/28c3-doctorow - GitHub 今夜は、著作権に関しての話はしない。著作権の話はもうたくさんしてきた。文化とか創造性の問題というのは興味深いが、正直なところ、もううんざりだ。僕のようなフリーランスのライターの日銭を稼ぐ現状の変化については、YouTubeで僕の昔のスピーチ動画を探せばいい。今夜は、もっと重要な話をする。汎用コンピューターについてだ。 汎用コンピューターというのは、実際、素晴らしいものだ。あまりに素晴らしいので、我々の社会はまだその真価を完全に把握していない。なんのためにあるのか、なぜ動作するのか、どうやって付き合っていけばいいのか。この疑問は、残念ながら、著作権の話へとつながる。
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳
10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか？ トーバルズ：俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた（データベースは別だが）。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。「誰が変更を行えるか」といった政治問題があるが、B
コンパイラーを負かす
roguelazer's website: beating the compiler なかなか面白かったので翻訳して紹介する。 たとえば、97%の場合において、僅かな効率など忘れるべきである。。早すぎる最適化は諸悪の根源である。とはいえ、残りの重要な3%の機会を逃すべからず。 -- Donald Knuth 計測せよ。計測するまで速度の最適化を施してはならぬ。たとえ計測したにせよ、一部のコードが残りを圧倒するまではまだ最適化してはならぬ。 Rob Pike 最新のWebサービスを主体とした技術の業界に長年浸かった我々は、パフォーマンスの問題を忘れがちである。SQLAlchemy ORMの中で行うリクエスト一つが8,9秒かかる中で、関数呼び出しひとつを3ミリ秒最適化したところで何になるというのか。とはいえ、時にはそのような最適化スキルを養っておくのもいいことだ。今回は、ある簡単な課題を最適化
goのgcコンパイラーがC実装を除去
all: merge dev.cc (a91c2e0) into master · b986f3e · golang/go Go言語のGoogleが実装するコンパイラーであるgcから、Cコードが取り除かれた。 今後のgc実装は、goによるセルフホストのみになる。 ブートストラップ計画は至って常識的なもので、前のリリースは次のリリースをコンパイル可能な状態を保つことで、ブートストラップ可能な状態を保つのだという。 Go 1.3+ Compiler Overhaul - Google Docs go言語の実装としてのgcは、libcにすら依存しておらず、ツールチェインがすべて既存のものにたよらず自前になっている。Googleの本気度を感じる。 ドワンゴ広告 この記事はC++に関係ないがドワンゴ勤務中に書かれた。ドワンゴではGoも使っているようだ。 ドワンゴは本物のC++プログラマーを募集してい
Linus Torvalds、HFS+に激怒
CVE-2014-9390 aka "Git on case-insensitive filesystems" I did not give the… gitが影響を受けた、HFS+で、一部の文字を区別しなかったり無視したりする問題に対して、Linusが吠えている。 マジで、HFS+はたぶん最悪のファイルシステムだな。クソすぎるぜ。NTFSもutf8の正規化で似たような問題（/の非正規化された表現を使用）があったが、まあ、今は修正されたんだろうよ。OS Xの問題は根本的すぎる。 そりゃ、古いさ。そりゃ、データ保護がクソすぎるってのはあるさ。だが、そういうのは、単に「すげーファイルシステムじゃない」って問題だ。「自分のケツすら拭けないマヌケによって設計された信じがたいクソ」ってわけじゃない。 HFS+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じ
OpenGLでムカつくこと
Rich Geldreich's Blog: Things that drive me nuts about OpenGL Valve社員のRich Geldreichが、OpenGLの設計が古臭すぎることについて不満を爆発させている。 OpenGLについてムカつくことを脳内ダンプしてみる（これは個人的な件秋であって、Valveや同僚の見解ではない。あと、ここ数年、OpenGLと格闘してきたので、今日は機嫌が悪い）。これを投稿する理由はこうだ。GL APIには再設計が必要だ。というのも、思うに、MantleやD3D12がどうせ昼飯前にOpenGL APIを駆逐してしまうだろうから、この問題については、今考える必要があるのだ。 ここに見れば些細な問題もある。単にAPIのトレースの問題というのもある。しかし、それらの問題が積み重なって、他の開発者にGL APIという環境に飛び込むよう誘うのを躊
JavaScriptの誕生と終焉
The Birth & Death of JavaScript — Destroy All Software Talks あの、Watのスピーカーとして有名なGary Bernhardtが、JavaScriptの誕生と終焉についてスピーチしている。 このスピーチは、2040年に行われているという設定である。JavaScriptが10日でやっつけ設計されたというところから始まり、JavaScriptが開発された地は、すでに放射能汚染されているという、2040年からみた歴史的事実を交えつつ、話は続く。 JavaScriptはあまりにも一般化してしまったため、皆JavaScriptで書くようになった。ただし、JavaScriptは遅いので、JavaScriptをネイティブコードにコンパイルしやすいようにする制限的な記法が流行した（整数型でいいところには、0をビット列論理和することにより、整数型で
クッキー・クリッカーについて
昨日、筆者はクッキー・クリッカーなるゲームを体験した。このゲームは、ゲームの本質を非常によく抽象化している。ここではそのゲームについて述べるが、読者には実感のため、並行してゲームを行なってもらいたい。 このゲームのプログラムはHTML/CSS/JavaScriptと、その他のリソースで構成されていて、ストールマンの自由四原則に合致する自由ソフトウェアではないが、一応は、制限的ながら、forkや改変を許諾している。このプログラムを動作させるには、まともなブラウザーが必要である。 Cookie Clicker まずみると、左に素晴らしくうまそうなクッキー、中央によくわからない列、右によくわからない小物が並んでいる。操作方法がよくわからない。まず、左にこれみよがしに配置してある、うまそうなクッキーをクリックしてみよう。 +1 なんと、クッキーが一枚得られた。続けてどんどんクリックしていくと、数十
ハードウェア乱数生成器は信頼できるか
How secure is Linux's random number generator? | Hacker News Hacker Newsで話題になっていたので。 主に暗号用途には、予測不可能な乱数が必要となる。予測不可能というのは、実装と内部状態が知られていても、なお将来の乱数が予測できないということだ。 たとえば、擬似乱数としてよく使われる線形合同法(Linear congruential generator)は、以下のように書ける。 namespace lcg { thread_local unsigned int seed ; void srand( unsigned int seed ) { lcg::seed = seed ; } int rand( void ) { // glibcの使っている値を拝借 seed = (1103515245 * seed + 12345
例外中に例外を投げるとか二重例外はエラーという俗説について
いよいよC++の参考書の執筆も例外にまで到達した。例外は、規格の文面量だけで言えば短いが、詳細を解説するのは難しい。なにせ、まともに日本語で解説している本は皆無だからだ。ついでに、規格の文面のバグも発見した。これはすでに報告済みなので、次のC++規格では修正されるはずだ。 ちなみに、"C++ 例外"で検索して出てくる情報の大半が間違っているか、十分な詳細を解説していない。責任は規格違反な実装、特にMSVCにある。MSVCの挙動が全てだと信じる愚者が、規格を参照せずMSVCの挙動をもとに解説を書いているからだ。 たとえば、例外をハンドルしていない状態でオペランドのないthrow式を実行すると、std::terminateが呼ばれる。 int main() { throw ; // std::terminateが呼ばれる } あるC++解説サイトでは、何故かstd::bad_exception
GNU/Linuxを動かせる最低スペックはATmega
Linux on an 8-bit micro? - Dmitry Grinberg 8bitマイクロでARMエミュレーターを実装してGNU/Linuxを動かした顛末が書かれている。 イントロ 初心者がマイクロコントローラーのフォーラムで、可愛いちっぽけな8bitマイクロでLinuxを動かせるかどうか質問するのはよくあることだ。大方は笑われるだけだ。Linuxフォーラムでも、Linuxの最低スペックは何かという質問がなされる。一般的な回答は、32bitアーキテクチャとMMUと、少なくともカーネルを載せるための1メガバイトのRAMだ。このプロジェクトは、そのようなありきたりな回答者を黙らせるためのものだ。右にみえる基盤のはATmega1284pだ。同じ物をATmega644aでも作って成功している。この基盤はこれ以外にプロセッサーを持たず、Linux 2.6.34をブートする。実は、完全なU
全プログラマーが知るべきレイテンシー数
Latency numbers every programmer should know — Gist L1キャッシュ参照 0.5ナノ秒 分岐予測失敗 5ナノ秒 L2キャッシュ参照 7ナノ秒 Mutexのロックとアンロック 25ナノ秒 メインメモリー参照 100ナノ秒 Zippy[Snappy]による1KBの圧縮 3,000ナノ秒 1Gbpsネットワーク越しに2KBを送信 20,000ナノ秒 メモリーから連続した1MBの領域の読み出し 250,000ナノ秒 同一データセンター内におけるラウンドトリップ 500,000ナノ秒 ディスクシーク 10,000,000ナノ秒 ディスクから連続した1MBの領域の読み出し 20,000,000ナノ秒 パケットを、カリフォルニア→オランダ→カリフォルニアと送る 150,000,000ナノ秒 Jeff Dean著(http://research.googl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
