AtomとかいうGitHub発の不自由なテキストエディターについて
GitHubが存在を公開した（流出したと言うべきかもしれないが）、Atomというテキストエディターの話題で持ちきりである。 このテキストエディターは、邪悪な不自由ソフトウェアであるので、自由の価値を重んずる読者は使ってはならないことはもちろんである。自由、不自由をさておいても（もちろん、さておくことはできない相談だが）、もちろん、敬虔なVim教徒である読者は即座に了解しているだろう。AtomがEmacsよりはいくらかは--自由の価値を重んじない浅はかな利用者にとっては--使いやすくなる可能性はないでもないが、Vimの牙城を崩すことは不可能である。Vimを倒すものはVimであり、NeoVimかもしれないが、Atomであることはありえない。その点で、我々信徒は安心できる。 さて、このAtomというテキストエディターは、自由ソフトウェアではない。その理由は、以下で言及されている。 Why is
ドワンゴに入社した
そう。タイトル通りだ。筆者、江添亮はドワンゴに雇用された。一体、どのような経緯でドワンゴに入社するに至ったのか。また、どんな仕事をしているのか。それを説明するには、時系列を追って書いたほうがいいだろう。 2013年8月21日 ふとみると、以下のようなサブジェクトのメールが届いていた。 【ご相談】ドワンゴ主催の C++11, 14 に関する勉強会にスピーカーとしてご参加頂けないでしょうか C++11？ C++14？ なんと、日本にC++14などという単語を知っている企業があったのか。しかし・・・ドワンゴ？ SPAMだろうか。いや、こんなにピンポイントなSPAMがあるわけがない。 それにしても解せないメールだ。ドワンゴといえば、もちろん、あの有名なニコニコ動画の企業だ。ニコニコ動画と言えばWebサイトだ。ニコニコ動画やその関連サービスの開発にC++を使っているのだろうか。いやまて、たしか子会社
1/9998 = 0.0001 0002 0004 0008 0016 0032 0064 0128 0256...
1/9998 = 0.0001 0002 0004 0008 0016 0032 0064 0128 0256... \(\frac{1}{9998}\)は、4桁で2^13まで2の累乗のパターンが出現する。 \[\frac{1}{9998} = 0.0001\;0002\;0004\;0008\;0016\;0032\;0064\;0128\;0256\;0512\;1024\;2048\;4096\;8193\;6387\;\cdots\] Hacker Newsによれば、これは以下のような理由による。 The pattern will break down once you get past 8192, which is 2^13. That means th\cdots | Hacker News このパターンは8192を超えると破れる。つまり、このパターンはすごいことに52桁も継続
本の虫: Clang VS 自由ソフトウェア
オープンソースで有名なEric S. Raymondが、自由ソフトウェアで有名なRichard Stallmanに、GCCのアンチプラグインポリシーについて突っ込んでいる。 GCCは、長年、コンパイラーのモジュール化を政治的な理由で行っていなかった。もし、例えばパーサーや意味解析だけを分離して使えるようにしたり、内部表現を規格化したりしてしまうと、GCCの一部が、不自由なソフトウェアに取り込まれたり、あるいは不自由なソフトウェアがGCCのプラグインという形で入り込むことになってしまう。これは、利用者の自由を第一とする自由ソフトウェアにとって、悪夢のような未来である。そのような未来を未然に防ぐために、政治的な理由で、GCCのはプラグインに反対するポリシーを採用している。もし、GCCを改良したければ、自由なソフトウェアとなるべきなのだ。そして、GCCのプロジェクトに参加するべきなのだ。 とはい
bzrは死につつある。Emacsは移行しなければならない
bzr is dying; Emacs needs to move Emacsのソースコードは、Bazaarでバージョン管理されてきた。しかし、Bazaarは分散バージョン管理システムとしては、Gitに敗北したし、もはや死につつある。Eric S. Raymondは、Emacsは他のバージョン管理システムに移行しなければならないと書いている。 私がこの投稿をしている理由は、バージョン管理システムとその周辺ツールのエキスパートとしての責務であって、この議論に参加したいがためではない。 bzrバージョン管理システムは死につつある。ほとんどの点で、もはや死んでいる。dev listは死んでいるし、Canonicalのほとんどの内部プロジェクトはbzrを捨ててgitを使っているし、古参開発者の一人が、なぜbzrが失敗したかについて書いている: http://www.stationary-trave
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
ClangがC++14の機能完全に到達！ 繰り返す！ C++14の機能完全に到達！
[llvm-project] Revision 194194 Clang - C++98, C++11, and C++14 Status とうとう、ClangがC++14の機能を完全に実装し終えたそうだ。もちろん、まだ既知、あるいは未知のバグがあるだろうが、とにかくC++14の機能的には完全にそろった。 これは素晴らしい。 ちなみに、Hacker Newsでは、このSVNコミットのリヴィジョン番号が、194194であることに着目して、狙ったのかと言われている。 それに対して、100100から194194までの数字には、194個もの同じ3数字二つの組み合わせがあり、別に特別な数字ではない、また、123321のような、他の意味で興味深い数字まで含めると、実に多くの「面白い」数字があると反論されている。 また、Interesting number paradox（興味深い数字のパラドックス）を
Linus Torvalds、Linuxの32bit版の優先度は低いと表明
[Phoronix] Linus Acknowledges 32-Bit Linux As Less Important 32-bit版のLinuxカーネルにおける、既存のある問題を修正したLinuxカーネル3.12に対するパッチのpullが、Linusによって退けられた。理由は、Linusは3.12のリリースを遅らせたくないからだという。すでに壊れていて、それほど問題になっていない問題を修正するのに、カーネルのリリースを遅らせたくないこと、それに、32-bit版の優先度は低いと言っている。 Linux-Kernel Archive: Re: [git pull] fixes for 3.12-final On Sun, Nov 3, 2013 at 11:54 AM, Al Viro wrote: > たしか、前にこういうことで32bit版のiget()が深刻に壊れて、 > それで、もう
GNU Make 4.0にGNU Guileが組み込まれた
GNU Make 4.0 released GNU Make 4.0がリリースされた。 今回のリリースでは、GNU MakeはSchemeの実装であるGNU Guileを組み込んだ。これにより、Makefileの中でSchemeが書けるようになる。 その機能は、GNU Make ManualのGuile Functionの項目で説明されている。まだ、オンライン版のGNU Make Manualが2010年から更新されていないので、コミット時のドキュメントの差分のリンクする。 8.13 The `guile' Function 具体的な組み込み方法としては、make側にguileという関数が追加され、この引数に文字列を与えると、SchemeとしてGuileで処理されるようになる。おそらく、このように。 Hello.o : $(guile (string-append "hello" ".c"
C++1yに提案されている不透明エイリアス(opaque alias)
[PDF注意] N3741では、C++1yに向けて、不透明エイリアス(opaque alias)が提案されている。 不透明エイリアスとは、Strong typedefなどとも呼ばれてきた機能で、typedefに似ているが、別の型として認識される別名の宣言機能だ。 C++には、Cから受け継いだtypedef指定子という機能がある。また、最近はもう少しまともな文法の、エイリアス宣言がある。どちらも機能も、「typedef名」という型に対する別名を宣言する。 typedef int Integer ; // typedef指定子 using Number = int ; // エイリアス宣言 typedef名は、ソースコード中に、型名で意味を記述させることができる。例えば、年齢とかお金とか身長とかだ。 using Age = int ; using JPY = int ; using Heigh
最悪のプログラミング言語、BANCStar
Following is the email I received from Google for this article. This is so unhelpful to identify the cause. After carefully reviewing the article, I found one URL that was flagged to contain malware(probably usual old domain expired and purchased by other problem) so I removed that link. Please review and re-publish this article. I hope Google's flagging system tells me why it trigger the flagging
MAC OS Xのsudoにパスワードを入力しなくてもよくなるバグ
Mac OS X Sudo Password Bypass | Hacker News Mac OS X Sudo Password Bypass ≈ Packet Storm 管理者権限を持つユーザーで、かつ、一度でもsudoを実行したことのあるユーザーならば、パスワードを入力しなくてもsudoが使えてしまうバグが発覚した。 sudoというのは、ご存知、管理者権限でプログラムを実行するプログラムだ。sudoを一度実行すると、しばらくの間（デフォルトでは15分間）、認証がキャッシュされ、sudoはパスワード入力なしで使えるようになる。この機能により、管理者権限を必要とする作業を集中して行う短時間の間に、何度もパスワードを入力する煩わしさをなくしている。 MAC OS X 10.7-10.8.4のsudoは、この「しばらくの間」を判定する方法にバグがあり、システムクロックを1970年1月1日
おそらくgccのバグ
以下の要素の参照は曖昧か - ここは匣 以下のコードは、gccとclangで解釈が異なる。 namespace NS { template < int N > struct NS { constexpr static int value = N ; } ; } int main() { using namespace NS ; NS<0>::value ; // gcc says a name 'NS' is ambiguous. // clang says 'NS' is class template name NS::NS ; } gccは名前NSを曖昧だとするが、clangは曖昧なくクラステンプレート名NS::NSだとする。 規格に照らし合わせると、おそらくclangの実装が正しく、gccの実装はバグであると思われる。3.4の冒頭に書いてあるように、 Name Lookupは、文法が
OpenBSDのコンパイラー
'Compilers in OpenBSD' - MARC List: openbsd-misc Subject: Compilers in OpenBSD From: Miod Vallat <miod () online ! fr> Date: 2013-07-31 21:19:11 Message-ID: 20130731211911.GE17582 () tazenat ! gentiane ! org 最近の議論(Default software in the base)は、近い将来、OpenBSDではClang/LLVMをシステムコンパイラーとして使う方向になっている。この議論は、これ以上発展していないが、現在OpenBSDのデファクトなコンパイラーメンテナーである私が思考の帯域を浪費してみようと思う。 だいたい、私はOpenBSDのシステムコンパイラーの保守に立候補したわけじ
ハードウェア乱数生成器は信頼できるか
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
LinuxカーネルのMLにおける悪口の励行についての議論勃発
Linuxカーネルのメーリングリストは、常に罵詈雑言に満ち溢れているが、そういうのは辞めて大人になろうという主張がSarah Sharp[1]によってなされた。なかなか面白い。 きっかけは、いたって日常的な罵倒混じりの議論に、Sarah Sharpが横槍を入れたところから始まった。 LKML: Sarah Sharp: Re: [ 00/19] 3.10.1-stable review On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org> wrote: * Linus Torvalds <torvalds@linux-foundation.org> wrote: On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote
C++14にやってくる見た目に分かりやすい新機能
C++14のCDも公開され、いよいよC++14も形になってきた。いま書いている本はC++11だが、C++14はGCCとClangといった二大C++コンパイラーで数年のうちに実装されるだろうから、もうすぐ実際に使うことができる。 今回は、詳細な説明は省いて、サンプルコードで新機能を語りたいと思う。以下の新機能は、すでにドラフト入りしており、正式採用はまず間違いない機能である。ちなみに、コンパイルしていないので正しいかどうか検証していない。 2進数リテラル int bi = 0b11110000 ; // 10進数リテラルでは240 2進数の記述が直感的になる。 自動ストレージ上に確保される動的な長さの配列 void f( std::size_t size ) { int buf[size] ; // OK } もちろん、クラスの配列も可能だし、コンストラクターやデストラクターも正しく呼ばれる
デニス・リッチーによって書かれた最初のCコンパイラーがGitHubで公開
mortdeus/legacy-cc · GitHub デニス・リッチー(1941-2011)によって書かれた発展途中の初期のCコンパイラーのソースコードがGitHubで公開されている。ソースコード自体は、まだデニス・リッチー存命の頃から公開されていたが、この機会に紹介してみる。 ライセンスは許諾的で、このライセンス文を同梱すること、並びに、ソースコードから生成されたバイナリはラインセンス文を出力することとなっている。 追記：ライセンスに関してふと思った。このライセンスは名義が企業で、著作権を盾に同意を求めている。日本では、映画以外の団体の著作権の保護期間は公開後50年である。UNIXと付属するソフトウェアのソースコードは当時から公開されていた。ということは、1973年に制作されたこのCコンパイラーのソースコードは、日本国内では、2024年に著作権が切れるのだろうか。 詳しい経緯は、以下の
LLVM 3.3のリリーススケジュール案
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
Bristol会議でC++14ドラフト入りが決まった提案一覧
C++14が来年に迫っている。先日行われたBristol会議の投票により、C++14のドラフトに正式に入ることが決まった提案の一覧を紹介する。ここで紹介されている提案は、すべてC++14入りが決定している。この先も細かい変更があるかもしれないが、基本的には変わらない。来年2014年に正式に発行される予定のC++14におそらく入る。 また、論文はすでに公開されている論文を、議論の結果修正したものなので、すでにこのブログでは全て解説しているはずだ。以下から探してくれたまえ。 本の虫: C++WG 2013-03-pre-Bristol mailingの簡易レビュー 本の虫: C++ 2013-01 mailingの簡易レビュー 本の虫: 2012-11 post-Portland mailingの簡易レビュー 本の虫: 2012-09 pre-Portland mailingのあまり簡易ではな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
