日記帳だ! with Tux on Libserver

コンピュータはなんでエネルギーを消費するんだろうかってのはかなりの疑問ですよね。
計算結果にエネルギーが蓄えられるわけではないですし。
まぁ実のところ熱になっているだけで、そうとするならばコンピュータは暖房だということになる。
最近は低消費電力のCPUとか流行ってますけど、そりゃ当然のことではありますよね。
だって究極的には電力いらないはずなんだから。
白熱電球がいかに効率が悪いと言われても、あれは光というエネルギーに変換されてるわけですから。

---

さて、なんかIronRubyとかあるので試してみた。
IronRuby
IronPythonのパクリのような気もしますが、まぁそういうものです。
iirbを起動してみた。IronRubyのirbだからiirbなんですね。
あと本体の名前はirなんだね。多分IronRubyだからってirbにしたら対話的コンソールのirbとかぶるからだと。
起動遅いですけど、これは.NET Frameworkの初期化が結構遅いというのが理由かなと。
IronPythonのもっとも残念だったのはそこだと思います。それはIronRubyでも一緒ですね。
まぁ.NET Framework 4.0からDLRの内蔵が始まるみたいだからこれによって速くなったらうれしいなとかいうのはある。
それまでは残念ですが広く使うのは難しそうです。

---

起動したら普通のRubyのようにirbできるはず。

p (1..100).map{|x| x**2}.inject(0){|s,i| s+i}

基準となってるRubyのバージョンはよくわからないけど1.8.7以前であることは間違いないでしょう。
さてここからがむしろポイントで.NETのライブラリを使えるよって所です。
まぁ試してみましょうか。

System::Console.WriteLine "Foobar".GetType.ToString
fs=System::IO::StreamReader.new('C:\work\req.txt')
begin
  puts fs.read_to_end
ensure
  fs.Close
end
a=System::Array[System::Int32].new(10)
(0..a.Length-1).each do |i|
  a[i]=i**2
end
puts a.inject(0){|s,i| s+i}
l=System::Collections::Generic::List[System::Int32].new(a)
f=System::Action[System::Int32].new do |x|
  x.times do
    print "#{x}"
  end
  print "\n"
end
f.Invoke(10)
l.ForEach(f)

まず、Rubyのオブジェクトの型を聞いてみると、IronRuby.Builtins.MutableStringという。
IronPythonではこれについてはSystem.Stringであると言ってきたので違いますね。
ところでRubyではメソッドの呼び出しに括弧は不要なのでこんな調子でOKです。
一見するとメソッドかプロパティか区別がつきませんが、これはRubyのよいところではありますね。
System::Console.WriteLineというのはちょっと変わった表記ですね。なんで::やねんと。
どうもIronRubyではクラス名まではこう書くみたいです。
System::ConsoleってのはRubyの言葉で言うと、Class型のオブジェクトなんですね。
まぁ.NETなんかの感覚だとわからないけど、Rubyとかはクラス名自体がオブジェクトなんですね。
というかクラスの定義自体Classクラスの拡張という形でやっているはずだし。
なのであえてSystem::ConsoleのWriteLineメソッドっていうわけでSystem::Console::WriteLineとは書いてません。
実際はSystem::Console::WriteLineでも使えるんですけどね。

---

それでStreamReaderを使ってみましたが、特にusing構文はないよと。
そういうわけでRubyのbegin～rescue～ensure～end構文で書いています。
Pythonではwith構文ってのが追加されたはずだけどRubyではそんなものいらないので。
ところで.NETってメソッド名はReadToEndのように書きますけど、Rubyではread_to_endのように書くんですね。
これを読み替えて使えるみたいです。
Ruby使いにも親しみやすいようにとのこと。
ジェネリックな型はSystem::Collections::Generic::List[System::Int32]のように書きます。
そういえばIronPythonもこうでしたね。
それで配列もSystem::Array[System::Int32]のようにかけるようになっています。
配列の作成は個数指定でやるのは普通にnewでいけますね。
ただRubyの配列からのコピーはどうやってやるんだろ。この辺はIronPythonと逆ですね。
Rubyといえばブロック付きメソッド呼び出しですが、これはデリゲートの作成に使えます。
できたデリゲートはRubyのProcみたいにf[10]とかできるかと思いきやできない。
残念。こうやってInvokeメソッド使えばいいですね。
List<T>のForEachメソッドに渡しているが、この引数を省略してブロック付きメソッド呼び出しではだめみたい。

---

まだかゆいところに手が届かないという感じではありますけど悪くはないですね。
最後のデリゲート型の引数を省略してブロック付きメソッド呼び出しできるようにしたり、
RubyのArrayと.NETのArrayの変換を簡単にしたりというのはやってほしいものですが。
まぁIronPythonも当初は散々でしたから今後改善される分もあるでしょうし。
ただ何よりも問題なのは初期化に時間を食うこと。
それさえ無ければ全部IronRubyのアプリケーションを作ったりしても楽しいと思うんだけどな。
まぁ最近は.NETで開発しなきゃいけないことは減りましたけど、やっぱりWindowsフォームは.NETで作ると楽ですからね。
この辺でIronRubyとか活用して行けたらと思うのだけど…
まぁ期待しておきましょう。

---

Author : hidemaro
Date : 2009/05/09(Sat) 23:42
.NET Framework | comments (0) | trackback (0)

Visual Studio 2008を入れてみた。今更って感じはするけどね。
やはりデリゲートを(sender,e)=>{ } とかすれば作れるのは便利ですね。
C# 3.0の新機能ですが、ありがたいものです。
それで新しくIEnumerable<T>の拡張メソッドがいろいろあるわけですが、
中にはRubyやらPerlで身近なものも結構あることに気付いた。

---

まぁとりあえず見てみよう。

    static void Main(string[] args) {
      Dictionary<string,int> hash=new Dictionary<string,int>();
      hash["Foo"]=32;
      hash["Bar"]=53;
      hash["John"]=52;
      hash["Taro"]=54;
      hash["Ken"]=62;
      hash["Bob"]=65;
      System.Console.WriteLine(hash.Select((kv) => kv.Value).Aggregate(0,(sum,cur) => sum+cur));
      foreach (var group in hash.Where((kv) => kv.Value>50).OrderBy((kv) => kv.Key).GroupBy((kv)=>kv.Value/10)) {
        System.Console.Write("{0} : ",group.Key);
        foreach (var cur in group) System.Console.Write("{0} ",cur.Value);
        System.Console.WriteLine();
      }
      Random myrnd=new Random();
      var uniq=Range(1,100).Select((dummy) => myrnd.Next(100)).Distinct().OrderBy((cur)=>cur);
      foreach (int cur in uniq) {
        System.Console.Write("{0} ",cur);
      }
      System.Console.WriteLine();
    }
    static IEnumerable<int> Range(int from,int to) {
      for (int i=from; i<=to; i++) yield return i;
    }

PerlやRubyのmapはSelectまたはSelectManyと覚えておきましょう。SelectはSQLの言葉ですね。
SelectManyはリストを渡したら開いてくれる、Selectはそういう処理をしてくれないやつ。
Rubyのinject、PerlのList::Util::reduce相当のものがAggregate、
一見気付きませんよね。けどこれです。ここでは総和を求めている。まぁSum使えばいいんだけどね。
Whereはgrep相当のものです。まぁこれもSQLの言葉です。というか大概SQL由来だったりします。
SortByだってSQL由来ですね。IEnumerableをソートするというのも相当不気味な状況ですが。
Rubyのuniq、PerlのList::MoreUtils::uniq相当のものはDistinct、言うまでもなくSQL由来。
ところで標準では範囲でIEnumerable作れなかったから、Rangeという静的メソッドを用意しておいた。
これで1から100までの数字を順番に渡していくオブジェクトが出来た。

---

結構いろいろありますね。
あとList::MoreUtils::natatimeとかあればいいんですけどね。
それと、ForEach拡張メソッドとかも用意して欲しかったな。
いや、C#のforeach構文とは別のものなんですけどね。
System.Collections.Generic.List<T>クラスにあるんですけどこんなの。

      List<int> list=new List<int>();
      list.ForEach((int cur) =>
      {
        System.Console.Write("{0} ",cur);
      });

引数にデリゲートを取るわけです。なんの意味があるんだという話ですが、
実はちょっと性能がいいらしいです。不思議な話ですが。
メソッド呼び出しの回数がだいぶ違うそうです。IEnumerable使ってると呼び出しが多いんだとか。
まぁそういう理屈で言えば、IEnumerableの拡張メソッドにForEachなんて用意しても性能では意味はないけど、
しかしList<T>で使えて、他のIEnumerable<T>でも使える方がおもしろいと思うんだよね。
まぁそんなところ。

---

たまには活用してあげてください。Aggregateとかすごい活用しがいがあると思いますよ。
あとはSelectぐらいかなぁ。Whereも時々役に立つかも知れないけど。
そうそう、C# 3.0から型推論に対応しているから、型が明らかならvarを書くとタイプ量が減らせる。
var uniqの行のvarは本来ならSystem.Linq.IOrderdEnumerable<int>と書くべきなのだが、それはあまり重要じゃない。
というわけでvarとか使ってます。
ただ、foreach (var cur in group)のvarは、System.Collections.Generic.KeyValuePair<string,int>だから結構重要かも。
だから書いておいた方がいいかもしれないけど、Visual Studioなら、そのvarのところにカーソルを重ねれば型名が見れる。
なのでその点ではあまり心配ないかも。
なお型推論するのはコンパイラなので、コンパイルしてできたコードはちゃんと型名を書いたのと一緒ですよ。
そういう面でも心配する必要はないですね。

---

Author : hidemaro
Date : 2009/04/15(Wed) 23:49
.NET Framework | comments (0) | trackback (0)

なんかC# 4.0なんて考えてるらしい。動的型って…
IronPythonで開発してて思ったが、.NET Frameworkのライブラリは複雑すぎる。
System.Drawing.SizeとSystem.Drawing.Pointを使い分ける意味がわからない。
別に大きさ2のタプルでもいいじゃないか? と思わんこともない。
そういう都合を考えると、コンパイル時確認していただける仕組みは便利なんですよ。
そしてVisual Studioもそのように設計されている。
C# 3.0で型推論のvarが導入されたけど、あれは匿名型を使うときに必要だからですね。

var foo=new {first="Taro",last="Yamada"};

この無名の型の名を知らないから、varというキーワードを使うと。
それ以外にも使い道はあれど、あまり意味はないでしょう。
もっとも動的型導入の理由というのはJavaScriptとの連携とかいうのもあるそうだが。

---

.NET Frameworkのリフレクションの力でどの程度できるか試してみた。
といっても当然のことを書いてるだけですが…

  public static class DynamicWorld {
    static public object call(this object self, string name, params object[] args) {
      return self.GetType().GetMethod(name, Type.GetTypeArray(args)).Invoke(self, args);
    }
    static public object prop(this object self,string name) {
      return self.GetType().GetProperty(name).GetValue(self, null); ;
    }
    static public void prop(this object self, string name, object value) {
      self.GetType().GetProperty(name).SetValue(self, value, null);
    }
    static public object newobj(this string type, params object[] args) {
      return Type.GetType(type).GetConstructor(Type.GetTypeArray(args)).Invoke(args);
    }
    static public object callstat(this string type, string name, params object[] args) {
      return Type.GetType(type).GetMethod(name, Type.GetTypeArray(args)).Invoke(null, args);
    }
  }

未だC# 3.0をまともに使ってるわけではないが、これはC# 3.0が前提。
これ拡張メソッドなのよね。

sb.prop("Length", 0);
DynamicWorld.prop(sb,"Length",0);

下のように表記すべきを上のように簡略化できると。
とりあえずインスタンスのメソッドとプロパティにだけ対応させてみた。
本当はインデクサとかにも対応できるのだがかなりめんどくさいので。
IronPythonも結局こういうものの固まりだと思う。

---

さて、試しに全部これでプログラム書いてみた。

object sr="System.IO.StreamReader".newobj(@"C:\test.txt");
object sb="System.Text.StringBuilder".newobj();
sb.prop("Length", 0);
while (!(bool)sr.prop("EndOfStream")) {
  sb.call("AppendLine", sr.call("ReadLine").call("Trim").call("PadRight", 20, '_'));
}
sr.call("Dispose");
"System.Console".callstat("Write",sb);
"System.Console".callstat("ReadKey", false);

拡張メソッドと可変長引数のおかげでそれなりに違和感なく使えます。
ただ、条件はbool型だろとかいうので、型変換が必要だったりというのはある。
しかしこれだけで動的に呼び出しているのです。
試しに、どっか大文字と小文字を入れ替えてみる。
コンパイルは通るものの、動かすとどっかで例外が出る。
これが動的に呼び出している証拠です。

---

作ってみて言うのもあれだが、あんまり使い道は思いつきませんけどね。
ただ割と簡潔に書けていますね。
.NET Frameworkのリフレクションの強さの証明と言えないこともない。
本当になんでもありの環境ですね。
それにしてもC# 4.0か…けど.NET Frameworkは2.0系のままなんだろうな。
だから動的型使ったソースコードも上に書いたようにされるのかな?
まぁそんな風に思わんこともない。

---

Author : hidemaro
Date : 2008/11/23(Sun) 23:10
.NET Framework | comments (0) | trackback (0)

10月末から、今日までひたすら続いてた工作がやっと終わった。
11月はゆとりある一ヶ月になってほしいですね。
けどそれは無理だと思う。試験あるし。

---

Windowsフォームでラベルというのはよく使う。
その変な使い方というわけで、Regionプロパティの話。

import clr
import System
clr.AddReferenceByPartialName("System.Windows.Forms")
clr.AddReferenceByPartialName("System.Drawing")
myform=System.Windows.Forms.Form()
mylabel=System.Windows.Forms.Label()
mylabel.Size=System.Drawing.Size(100,100)
mylabel.BackColor=System.Drawing.Color.LightPink
mylabel.TextAlign=System.Drawing.ContentAlignment.MiddleCenter
mylabel.Text="丸"
zone=System.Drawing.Drawing2D.GraphicsPath()
zone.AddEllipse(0,0,100,100)
mylabel.Region=System.Drawing.Region(zone)
myform.Controls.Add(mylabel)
myform.ShowDialog()

IronPythonなら簡単に試せますね。
重要なのは、zoneというGraphicsPathのインスタンスを作って、
そこに円状の領域を設定、これでもってRegionを作成し、設定。
これにより何ができるのかというとコントロールの表示領域が円状になる。
実際実行してみると、ピンク色の円の中に"円"という字が書いてある。
このピンク色の円こそがラベルです。

---

まぁ今回は文字列が書いてあるからラベルっぽいけど、
文字列ないにも関わらずラベルでこれを描いているときがある。
無駄じゃないかというのはあるかも知れんが、実は便利。
PictureBoxの場合、一時的に書くのは非常に容易なのだが、
もしウインドウの影に隠れたりして、再描画するとき復帰しない。
復帰するためにはGrapicsに空のBitmapをセットしてから書けばよいのだが…
まぁその都合は@ITで紹介されてるな。「PictureBoxコントロールにグラフィックを描画するには？」
有名な事実だとは思いますけどね。
けど、この方法ならそんなこと気にしなくてもOK。

---

しかもこのRegionで切り抜く方法は重なり合いが発生したときにも有利。

mytbox=System.Windows.Forms.TextBox()
myform.Controls.Add(mytbox)
myform.ShowDialog()

驚くことに、ラベルの下にきちんとテキストボックスが表示されてる。
これは実はかなりすごいことなんです。
Regionで指定した範囲しかコントロールの領域じゃないんです。
だからClickイベントを設定して、丸まってる部分をクリックしても反応無し。
ただ透明に設定することとの違いについては、

mylabel.BackColor=System.Drawing.Color.Transparent
myform.BackColor=System.Drawing.Color.LightBlue

としたときの動作を見ればよくわかります。
背景色が透明になれば、テキストボックス全体が透けそうですね。
しかし、透明であるべきラベルの領域は全域真っ青。
この透明というのは、親コントロールの上に子が配置される前の表示そのものが背景という意味。
なので、親コントロールの上に配置した2つ以上のものが重なり合うと悲しい結果になる。
まぁ、この性質を理解して、Aの上にB、Bの上にCを重ねるという方針なら、
Aの子にBを、Bの子にCを登録すればいいのです。わかりやすい。
まぁなかなか理解してない人は混乱する話です。

---

まぁこんな風にしてラベルでいろいろ作りました。
ラベルは切り絵のように使うことができるということです。
明らかに使い方がおかしいだろと言われたけど、
しかし使えるものは便利に使いたいものです。
Regionプロパティはそれを支援してくれますよ。

---

Author : hidemaro
Date : 2008/11/01(Sat) 23:23
.NET Framework | comments (0) | trackback (0)

微分方程式難しいねぇ…そりゃそうですか。
未知関数の微分積分を含む方程式ということで、
基本的には関数当てゲームというわけで、そりゃ難しい。
式を変形して積分して解くんですけどね。
一階線形微分方程式の解の公式なんてのがあって、まぁ覚えればいいと思うのだが、
とんでもない式だし、うまく積分できないならその方程式は解けんぞと。
しかし、自然界のいろいろを表す式って微分方程式も多いそうだ。
例えばだけど、RLC直列回路に直流電圧をかけたら、正弦波交流電流が流れることとか。
L(di/dt)+Ri+(1/C)∫idt=E、という方程式を解けばわかるんだよね。
まぁいろいろあるんですよということです。

---

最近3つのソフトウエアを同時に設計・開発してる。
1つはほとんど完成してるのだが、残り2つが大変。
プロトタイプを作って、機能を実装して…ということを繰り返してる。
まぁ小規模なプログラムだからできることですよね。
それで、Rich Text Formatを取り扱おうかなとか思って調べてた。
RTFなんだが、これが非常に冗長。圧縮するとすごい容量が減る。
というわけで圧縮したものをBase64に変換しておこうと。
IronPythonで開発してるが、try～finallyだらけで読みにくいので、C#で書こう。
どうもPython 2.5からwith構文というのがあるそうだが、残念ながらIronPythonでは実装されてない。
まずファイルを開き、圧縮したものをBase64に変換してコンソールに出力する件。

using( System.IO.FileStream fst=new System.IO.FileStream(fname,System.IO.FileMode.Open) ){
  byte[] buf=new byte[fst.Length];
  fst.Read(buf,0,buf.Length);
  using(System.IO.MemoryStream mst=new System.IO.MemoryStream()){
    using(System.IO.Compression.GZipStream gzst=
      new System.IO.Compression.GZipStream(mst,System.IO.Compression.CompressionMode.Compress)){
      gzst.Write(buf,0,buf.Length);
    }
    byte[] gzbuf=mst.ToArray();
    Console.WriteLine( System.Convert.ToBase64String(gzbuf) );
  }
}

using構文でC#ですら目が痛いが、IronPythonでは全部try～finallyで書いてるのでさらに目が痛い。
System.IO.Compression.GZipStreamにおいては、
書き込まれたら圧縮処理して、コンストラクタで指定されたストリームに書き出すストリームを提供、
コンストラクタで指定されたストリームから展開処理したものを、読み込むことができるストリームを提供、
のどっちかをできる。
しかし使いにくい仕様なんですよ。
圧縮時、あらかじめ、System.IO.MemoryStreamで圧縮結果を受けるストリームを作っておく、
コンストラクタで、このストリームと、System.IO.Compression.CompressionMode.Compressで圧縮モードだとする。
それで、GZipStreamのに、Writeで書き込む。
そして、GZipStreamを閉じたら、圧縮処理完了。受けるストリームには完全な結果が入ってる。

---

展開処理だが、これは明らかにめんどくさい。
Base64をバイト列に変換して、MemoryStreamのストリームに書き込んでおく。
GZipStreamのこのストリームを展開するストリームを作る。
このストリームを直接使えればいいのだが、Seek不可なので困ることがある。
System.Windows.Forms.RichTextBoxのLoadFileメソッドでRTFのストリームを渡したかったのだが、
Seekできんみたいな例外を投げるので、無理なんだなと。
そうなるとMemoryStreamのストリームにGZipStreamのストリームからReadしたのをWriteすると…
こんな作業をしないといけない。これがかなりめんどくさい。
以上の処理をするもの。

byte[] gzbuf=System.Convert.FromBase64String(gzb64)
using(System.IO.MemoryStream rtfst=new System.IO.MemoryStream()){
  using(System.IO.MemoryStream gzmst=new System.IO.MemoryStream()){
    gzmst.Write(gzbuf,0,gzbuf.Length);
    gzmst.Position=0;
    using(System.IO.Compression.GZipStream gzst=
      new System.IO.Compression.GZipStream(gzmst,System.IO.Compression.CompressionMode.Decompress)){
      byte[] buf=new byte[1024];
      while(true){
        int readlen=gzst.Read(buf,0,buf.Length);
        if(readlen==0)  break;
        rtfst.Write(buf,0,buf.Length);
      }
    }
  }
  rtfst.Position=0;
  rtfboxLoadFile(rtfst,System.Windows.Forms.RichTextBoxStreamType.RichText);
}

これはひどい。上で説明したとおりのことが書いてあります。
gzmst.Position=0; rtfst.Position=0;
はいずれもMemoryStreamにWriteした後、改めてスタート地点に戻って、
ここからReadしていただくという意味です。
ToArrayで配列に変換する分にはあまり気にしないけど、Readで読むときは重要。
あと、GZipStreamを読み取るのに、1024Bytesのバッファを用意して、
ループ回して、読み取り成功分だけMemoryStreamに書いていく。
Readの返り値は読み取り成功のバイト数だが、読めなくなれば0になるのでこれで抜けてる。
さっきのFileStreamでは、Lengthプロパティがあったけど、GZipStreamでは使えない。
だからこういう、まぁ正攻法でやらんといかんと。

---

これの使い道だが、TCPとかで通信するときデータを圧縮すると。
そのとき、データをGZipStreamのにWriteして、受けるMemoryStreamの中身を送信すると。
受信してMemoryStreamに投げ込んだら、これをGZipStreamで受けてReadしてMemoryStreamにWrite、
最後にMemoryStreamの中身を確認すれば本当に送りたかったデータがあると。
まぁこういう使い道が多そうです。
ちなみに。System.IO.Compression.DeflateStreamという類似したクラスがあります。
DeflateはgzipやZIPの原理です。Deflateを使ってgzipを実現してるのね。
今回のは別にgzipでなくてもDeflateでもよかった気はするが、gzipの方がデバッグに便利だしいいや。
こんな手間をかけてやるかは知らんが、有用なライブラリなので使うといいと思う。

---

Author : hidemaro
Date : 2008/10/24(Fri) 23:27
.NET Framework | comments (0) | trackback (0)