Googleが既存の社内のPythonコードをGoで実行するためのPython実装を公開している。 Google Open Source Blog: Grumpy: Go running Python! google/grumpy: Grumpy is a Python to Go source code transcompiler and runtime. Googleの発表によれば、YouTubeのフロントエンドサーバーとYouTube APIはほとんどPythonで書かれているという。現在、YouTubeのフロントエンドはCPython 2.7で実行されているが、CPythonの制約により効率化には限界があるのだという。 GrumpyはPython 2.7のコードをGoのコードに変換するツールgrumpcの実装だ。grumpcはPythonで実装されていて、astモジュールでPyth

freeeの保有する特許5503795について読んで解釈を試みたがやはり新規性も技術的価値もわからないしゴミだったのでfreeeのエンジニアは早くfleeするべき freeeが特許侵害でマネーフォワードに訴訟を起こしたそうだ。freeeのプレスリリースでもその事実を記載している。 特許権侵害訴訟の提起について | プレスリリース | freee株式会社 これによると、マネーフォワードが侵害したとfreeeが主張している特許は、特許第5503795号だそうだ。他の特許については触れていないのでこの特許を読んでみることにする。 特許 第5503795号 会計処理装置、会計処理方法及び会計処理プログラム - astamuse この特許は本当にゴミなのだが、私の解釈した限りで、この特許を使った技術的な実装とは以下のようなものだ。ここで、この特許が主張している文脈やアイディアは無視して、単なる根本的

引き続き、2014-05-pre-Rapperswil mailingをレビューしていく。 N3980: Types Don't Know # 「型はハッシュのことなんざ知ったこっちゃねえんだよ」という挑発的なタイトルの論文 ある型をunorderedコンテナーに対応させるには、ハッシュ値が計算できなければならない。ユーザー提供したクラスは、ユーザーが自力でstd::hashを特殊化してハッシュ値の計算を実装しなければならない。問題は、適切なハッシュの計算というのは、極めて難しい技術であり、そんじょそこらの並のプログラマーは正しく書くことが出来ない（我は書けるなどと豪語するのはバカの証拠である） これまで、N3333やN3876で、バカでもユーザー定義型をハッシュ対応させられるようにしようという提案が出ていたが、これはどちらも、std::hashに既存の対応した型を放り込んでハッシュ値を生

2014-05 pre Rapperswil mailingが公開された。ざっとタイトルを眺めると、今回も面白そうな論文がちらほらある。早速レビューしていこう。 N3967: C++ Standard Library Active Issues List N3968: C++ Standard Library Defect Report List N3969: C++ Standard Library Closed Issues List 標準ライブラリに存在が認知されている既存の問題集、修正済みの問題集、議論の結果実は問題ではなかったとされた問題集。 N3970: Technical Specification for C++ Extensions for Concurrency, Working Draft 新しい並列実行ライブラリを含むConcurrencyのTechnical Sp

C++11の時間関係のライブラリは、非常に美しい設計をしている。 まず、経過時間そのものを表すdurationがある。Cライブラリでいえば、time_tの値の単位を指定するクラスだ。Cライブラリでは、time_tの値は秒であったが、C++では、単位を指定できるのだ。 durationでは、単位ライブラリであるratioを使って、秒、ミリ秒、マイクロ秒などといった時間単位を表現している。 秒 std::chorno::seconds ミリ秒 std::chrono::milliseconds ナノ秒 std::chrono::nanoseconds 時 std::chrono::hours それ以外の、独自の刻みがほしいとしても、簡単に作成できる。 4分33秒 using four_minutes_thirty_three_seconds = std::chrono::duration< l

Bazaar-NG: 7 years of hacking on a distributed version control system Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。 Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。 この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。 黎明期 < ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。 2004年、筆者は、 SambaのコントリビューターであるMartin Pool

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