情報系の備忘録

だらだらと A first look at WebAssembly performance http://www.stefankrause.net/wp/?p=405 WebAssemblyとJavaScript実装との性能比較。 結果としては、速いこともあれば遅いこともある。 一年前ははっきりと遅かった のだから進歩していると解釈できるのかな？ パフォーマンスが同等であればわざわざ手を出すほどでもないかと思いつつも、 バイナリサイズがコンパクトであることを考えると現段階でも優位性が高いといえなくもないか。

駄文を書きたくなったのでテキトーに。 映画なんかで逃亡者が走っているのを見ると、小さい頃の夢を思い出してしまう。 当時は警察官になるのが夢だった。 この夢はすぐに諦めることになった。親から「太っていると犯人を捕まえられない」と指摘されたのだ。親は冗談だったかもしれないが、小学生にもなっていない子供にはそこまでは気づけない。 警察官になるのを諦め、同時に運動能力を必要とするものすべてを諦めてしまう。そして、勉学に希望を見出して精を出し始める。 鈍い小学生が成績トップになるのは簡単なことではなくて3年もかかってしまった。 皮肉なことに3年の月日は小学生の体を変えてしまうのには十分な期間だった。 身長が急激に伸び、肥満体型からスレンダーに変化した。足は長くなるし、筋肉も急速に発達した。その結果、運動能力でもトップクラスになってしまうのだった。 続きは、、、予定していない。

仕事でPHPを使うことが多いし、もっと興味をもってみるかということで行ってみた。 ので、雑感をまとめておく。 HHVM/Hackの話 「素のPHPを実行するだけでも高速化のメリットがある」 というのはもう無理があるんじゃなかろうか。ベンチマークは所詮ベンチマークとはいえ、PHP7と比較して大差があるわけじゃない。それなのに環境を変えるリスクを背負えるはずもないし。 「async/await」 例としてでたクルクルSQLについては、言語的にはリクエストを投げまくる点は変わらず、その点は他のレイヤーで解決するべき問題とばっさり。他言語だってそうだし、そんなもんってノリなのかな？ 「型はしっかり書け」 ごめんなさい。もっと推論してやさしくしてください。型チェックはありがたいけど、JavaやGoみたいになっていくなら普通にそっちを使いますわ。 「コンバーター？切り替えオプションあるから地道に手で変換するべし」 ほら、これだって推論器が強ければ、作業も楽になるし。 てか、不完全でもコンバーターあれば実際問題としては全然状況ちがうんでは。 IPv6の話 IPv6には繋がらないけど審査は通ったから「IPv6対応」事案には、会場爆笑。 PHP ASTの話 ASTを引っこ抜けるライブラリは、今のところ実行前のASTをコピーしてるだけ。後の質疑応答で実はそうではなくて同じものとか、一体どっちや？ 発表資料などはtwitterを検索するといくつかヒットする。 運営側でとりまとめてくれると楽なんだけど、2015のサイトをみても無いし、今年もないんだろうなぁ。

Haskell, OCaml版を無事に実装し終えて、今後のことについて迷っている。 今考えられる個人プロジェクトは、大まかには2つである。 1. lisp 処理系 2. サーバー まず、lisp 処理系について掘り下げてみる。 こちらについては、多言語実装と高速化、多機能化の3つを挙げることができる。 多言語実装では、いかに挙げる言語での実装を目標としている。 * lisp, scheme * sml * elixir * rust * c * c++ まだまだ挙げようと思えば挙げられるが、有益な経験を得られると思えるものみに絞った。 多言語実装を通して、その言語に慣れ親しむのが主な目的である。 このプロジェクトに取り組む前は、動的手続き型言語(Ruby, JavaScript)でのみ 実装できただけであったため、その後に続くGo, Haskell, OCamlは得るものが多かった。 しかし、静的型づけ、関数型と歩を進めたあとでは、そのあとに続く言語での 得られるものは少ないのではないかという不安がある。 ただし、lisp自体の習熟は、なぜlispの生産性が高いと言えるのかをよく理解できていないため、 プロジェクトを進める価値はまだ十分にあると言えそうである。 以上の不安から、浅い部分で経験を積むのではなく、深いところに踏み込んでいくことを考えている。 その候補としては、処理系の高速化や多機能化が挙げられる。 高速化に関しては、ゼロ知識のため他のプロジェクトを読むのが主な作業になるだろう。 そこで得られた知見を自分のプロジェクトなり他人のプロジェクトなりにコミットして、 ベンチマークの成績を挙げられれば、わかりやすい励みになると思われる。 多機能化については、Peter Norvig実装から脱却して、ひとつのOSSプロジェクトへと成長させる ことを意味している。ここでは、what's new に答えられるかどうかがプロジェクトの真価を 問われる部分かと思われるが、まずは既存の仕様を理解し忠実に実装するという点を目標としたい。 自分のレベルから考えて、それだけでも十分高度な目標であろう。 次に、サーバーについて考えてみる。 こちらについては、フレームワークの構築とサーバーそのものの実...

だいぶ前のことになりますが、Peter Norvig 先生の Lispy を参考に別言語での再実装していました。 kawakami-o3/yaLispy 最近、新たに Go, Haskell, OCaml での実装を追加しました。 Go雑感 先に実装していたRubyやJavaScript版とほぼ同様に実装できているものの、 Cell型の定義にいろいろ含まれていて冗長に感じます。 Cライクの言語実装でよく見かける定義ですが、もっといいアイデアはないものか。 Haskell雑感 Go実装の前に取り組んだ時はいろいろわからず苦労していましたが、 型の取り扱いに慣れてくると割とすんなり実装できてしまいました。 唯一、構文解析でリスト構造を生成する関数で手間取りました。 相互再帰している構文解析器、これももう少しシンプルに実装できないものか。 OCaml雑感 Haskellの実装後に取り組んだこともあり、つまづくところはほぼなく完了しました。 Haskell版のソースと見比べると若干整って見えます。 Haskellはオフサイドルールがある割には表現力が高くて、ごちゃごちゃしがちなのでしょうか?

deadが多い、減らない場合はautovacuumされていないかもしれません。

かなり前に書いたものなので間違っているかもしれないです。

(何年か前の書きかけ物) 値の整合性チェック "assume ..."とあれば、それに関してはチェックはいらない

(何年か前の書きかけ物) 初めてスコアが出せそうなアセンブリコンテストを逃してしまったので、深く反省するべきだと思う。 技術、知識不足 次に似たような案件が来るかもしれないので、自分が考える範囲の実装は継続するべき。 スタートの遅さ 登録後すぐに開始できる。。。かもしれないので、現在アクティブになっているプロジェクトに即座に参加してみるのはいいかもしれない。開発期間を多くもらえるかどうか知ることが出来る。 労働時間の不足 モチベーションを長期間維持しつつ、他の要件に囚われないこと、あるいはすぐ片付ける技術を身につけるべき 正直、正月気分で遊んでいた時間が長かった。バグレースの方がまだ時間を使っていた。 生活スタイルとして、開発する時間を習慣付ける。だらだら開発しない。

(何年か前の書きかけ物) AirSRM Practice roomが不調になった時非常に役に立ってくれた AirSRM だけど、最近はよく物足りなさを感じる。 何が物足りないかは割りと明確で、「人のソースや Editorial にアクセスしづらい」ということが挙げられる。 SRMの練習する場合「問題を読んでコードを書く」だけで終わることはほとんど無い。Div 2 Easy ならかれこれ 300 問は解いてきたけど、人のソースを読んでみると文法の見落としや「なるほど」と思える技に出会えたりする。解けない問題について、Editorialを参照することも頻繁にある。 ところが、現在の AirSRM が生成するウェブページは result ページへのリンクを含んでいるだけという状況にある。

$ for i in `git checkout HEAD | grep 'D\s\+' | sed -e 's/D\s\+//'`; do git checkout HEAD -- $i; done

いつものようにgit-svnで更新していたところ、以下のようなエラーに遭遇した。 $ git svn fetch FILE was not found in commit HASH (REVISION) (FILE, HASH, REVISIONは伏せ字) どうも無視しているディレクトリの中身にコミットがあったらしく、変更を適用しようとしてエラーになっている。 そのファイルを仮に、 hoge/foo.c としておく。 エラーの根本原因となっていたのは .gitignoreで、もともとは hoge と書いていたのだが、 hoge/ とスラッシュまで含めて書くのが正しかったようである。 上記の修正ができない場合でも、 $ git svn fetch --ignore-path hoge のようにオプション指定すればエラーは回避できる。

もう数年前のこととなってしまったが、チェス上級者をあと一手まで追い詰めたことがある。 まだ大学院の学生だった頃の話で、たまたま同じ研究会に参加していたイギリス人がチェスに精通しているということでリクリエーションでその力を披露していた。  私が観戦していた一局では既に彼のイギリス人は巧者だということが判明しており、挑戦者は諦め模様であった。 それまでの数局を見てチェスでの駒運びをいくらか覚えた私は、単純な好奇心から横槍を入れてしまった。 ナイト、ポーン、ビショップ、クイーンとたった一つ空いた穴を攻め立てて、あと一手でチェックメイトのところまで攻め立てることができた。 無論、彼の上級者を落とすまでには至らず、私の攻めは徒労に終わってしまった。私と同じく観戦していた研究者等がその手もあるのかと感嘆してくれたのは嬉しかったし、次の対戦者に私を指名してくれたのも誇らしかった。 しかし、次の対局では全く話にならず惨敗してしまった。 なんのことはない。彼はこれまでの対局で手を抜いていただけだった。 私の何気ない一手に対して、熟考に熟考を重ねた上で無難な手を打つという戦略をとったのである。一方の私は数局前までは素人で彼の攻め方を真似ただけであったのだ。 結果は言うまでもないが、どうもこのあたりができる人間とできない人間の差のように思えてならない。

var code = 'this.hello = function() { console.log("hello"); };'; var obj = {}; eval.call(obj, code); obj.hello() 的なことしたいなぁ〜。できないのかなぁ〜。

不勉強ゆえに「なんだかよく分からない」状態が長く続いていたが、ようやく「とりあえず使える」程度には理解できた。 class Demo   def initialize     @arr = (0..9).to_a   end   def eachLambda fn     @arr.each do |i|       fn.call(i)     end   end   def eachYield(*arg,&block)     @arr.each do |i|       yield i,*arg       #block.call(i,*arg)     end   end end Demo.new.eachLambda lambda {|i|   puts i*i } Demo.new.eachYield do |i,n|   puts i*i end Demo.new.eachYield(2) do |i,n|   puts i**n end 最近"hoge.each {|i| Foo.new(i) {|i| ... } }"のようなコードを頻繁に書いていて、だんだんコピペが億劫になってきていた。外側のブロック部分は変わらず、中身の"..."の部分だけが違うだけだというのに、すべてを記述しなければならなかった・・・自分の理解不足ゆえに。 ちょっと工夫してみようということで、すぐに思いついたのは「"..."部分をlambdaで渡そう」ということだった。そうして出来たのが、上の例にある"eachLambda"だ。呼び出し時のlambdaが浮いてる感じがする点や、いかにもブロックでありそうなところを"{}"で書かなければならない点を除けば、概ね満足できるものだった。 しかし、これを人に使ってもらう段階になって「やっぱりブロックで渡したいよね」ということになり、「yield、何やってるかよく分からない」状態から再入門することになった。 そうしてようやく、上の...

EclipseのJavaコンパイラであるECJをAntで呼べるようにして、Jenkinsでビルドできるようにしたというお話。もっといい方法があるという方、是非ご一報くださいますようお願い致します。 Javaの開発環境としてEclipseを採用しているところは多いだろうけれど、Jenkinsと連携しようとすると困ることがある。Jenkinsで使うJavaコンパイラをOracleから持ってくると、途端にビルドできなくなってしまうからだ。 この原因は単純にEclipseで使っているJavaコンパイラとOracleで配布されているJavaコンパイラの挙動が異なるからである。 ならば、Eclipseのコンパイラを使うようにJenkinsを設定出来れば(ここではAntを使う)問題は解決できるはずである。 EclipseのコンパイラECJを使う話はググるとたくさんでてくるけれど、同様にbuild.xmlを記述してもうまくビルドできない。入れ子になっているjarファイルを引っこ抜いて、CLASSPATHに追加しなければAntでビルドすることはできない。逆にいうと、CLASSPATHの設定さえできれば、あとはJenkinsでもうまくビルドできるということである。 ぼちぼち編集して詳しく解説していく予定です

結論：ちょっぱや import java . io .*; class StringAppend { public static void main ( String [] args ) { for ( int i = 0 ; i < 50 ; i += 5 ) { long start = System . currentTimeMillis (); String str = "" ; for ( int j = 0 ; j < 100 *( i + 1 ) ; j ++) { str += "aa" ; } System . out . println ( "" + i + " " +( System . currentTimeMillis ()- start )); } System . out . println ( "" ); for ( int i = 0 ; i < 50 ; i += 5 ) { long start = System . currentTimeMillis (); StringBuilder str = new StringBuilder (); for ( int j = 0 ; j < 100 *( i + 1 ) ; j ++) { str . append ( "aa" ); } System . out . println ( "" + i + " " +( System . currentTimeMillis ()- start )); } } }

ちょっと不安になったのでメモ import java.io.*; class HaveInt {   private int i=0;   public void set(int i) {     this.i = i;   }   public int get() {     return i;   } } class A extends HaveInt { } class B extends HaveInt { } class Main {   public static void main(String[] args) {     A a = new A();     B b = new B();     a.set(1);     b.set(3);     System.out.println(a.get());     System.out.println(b.get());   } }

AirSRM on github AirSRMがついに C++/C# のコードを吐けるようになりました。 最近はpractice roomの方はだいぶ調子がよくなってきて、期を逸した感が強いですが、ようやく仕上げることが出来ました。 使い方は Java とほぼ同じですが、設定ファイル AirSRM.config を編集する必要があります。たとえば、C++であれば、 language = cpp C# であれば、 language = cs のように設定します。 後は以下のように問題のダウンロードとシステムテスト用コードの生成などを行います。SRM 525 Div 2 Easy を C++ で解こうとした場合は、 % ruby AirSRM.rb --srm=525 --division=2 --level=1 % emacs RainyRoad.cpp % g++ RainyRoad.cpp % ./a.out % ruby AirSRM.rb --srm=525 --division=2 --level=1 --systemtest % g++ TestRainyRoad.cpp % ./a.out C# であれば、 % ruby AirSRM.rb --srm=525 --division=2 --level=1 % emacs RainyRoad.cs % mcs RainyRoad.cs % mono RainyRoad.exe % ruby AirSRM.rb --srm=525 --division=2 --level=1 --systemtest % mcs -main:TestRainyRoad TestRainyRoad.cs RainyRoad.cs % mono TestRainyRoad.exe となります。