Visual Studio Communityで(貧乏人の)F#が捗る

Visual Studio Community 2013 が公開され、個人開発者はこれを利用できるようになりました。今まではExpressがいまいちで、かといってランクを上げるには6万円ほど必要で、趣味で使い始めるにはとても敷居が高かったのです。
そして、開発ターゲット毎にエディションが異なり、さらに複数言語プロジェクトの混在を扱えないExpressは、F#を扱うのがとても大変でした。参考；VS2012頃のF#関連の記事。いつのまにか触らなくなってしまいました。

しかしVS Communityの到来により、またF#を考えるべき時期が到来したのかもしれません。
まず初回起動時に聞かれる開発設定の選択肢に姿が見え、


新規作成プロジェクトの選択肢にもいて、

 

ちゃんと複数言語混在ソリューションも作れます。これで、C#のGUIの裏側でF#のライブラリを使うことが、難しくなくなりました。



習得したい積み言語が積み上がっていて、F#は奥の方(やる気のかなり低い方)に埋もれてしまっていたのですが、今後.NETのGUIを組むときにはまた使ってみましょう。

F#のUnit Test、FsUnitの設定(VS2012)

問題点

F#でもテストを書こうと、NuGet経由でFsUnitをインストールしてみたものの、当初は動作させようとするとFileNotFoundExceptionが出て動きませんでした。"FSharp.Core, Version=4.0.0.0"というアセンブリを探していますが、手元のFSharp.Coreは4.3.0.0なのです。

解決方法

FsUnit公式のVisual Studio 11 Supportのところを読むと、Add-BindingRedirect projectnameを使えと書いてあります。
Powershellのコマンドのようですが、普通にPowershellを起動してもだめで、VisualStudioのメニューから起動する必要がありました。ツール→ライブラリ パッケージ マネージャ→パッケージ マネージャ コンソールです。

ここで Add-BindingRedirect コマンドを使えば、App.configが更新されて、無事FSharp.Coreを読み込めるようになりました。こんなつまらんことで、1時間以上はまりましたorz Microsoft(.NET)慣れした人なら、こんなことは無いのですかねえ。

FsUnitというよりNuGet自体のバッドノウハウでしょうか。なんだか微妙なパッケージ管理ですね…

FsUnitの設定

F# Library Projectは直接実行できないので、隣にF# Console Appのプロジェクトを作って、そちらでテストを書いています。普通にmain関数でテストを順々に呼んでいるのですが、このやり方は正しいのでしょうかね…？
Console Appについては昨日の記事参照。新規作成後、いらんファイル消して、NuGetでFsUnit入れて。さらにテストプロジェクトのReferencesを右クリックして、参照の追加→ソリューションからテスト対象のプロジェクトを追加しています。

F#アプリケーションを新規作成するためのテンプレート集

Visual StudioでF#を扱う場合、プロジェクトとして選択できるのは「F# Library」と「F# Tutorial」だけです。

以前、F#談話室(2)において、はじめてのF#入門コースとしてWindows Formを使ったアプリケーションを作る際には、Tutorialを改造して作り始める、ということをしていました。(記事→F#談話室(2) に参加してきた)

Microsoftのテンプレートギャラリーにある、F# Applications Windowsという拡張を入れると、新規作成でアプリケーションを作りやすくなるテンプレートがいくつかインストールされます。おそらくMicrosoft公式のものではないけれども、作者の所属がMicrosoft UKらしいので、どこぞの学生が適当に作ったレベルでもなさそうです。

F#Windows App (WinForms)

昔ながらのWindows Formを使うアプリのテンプレートです。

こんな感じの最低限のフォームが出ます。ラベルが1つある以外は何も機能はありません。
フォーム定義はMainFormfsにまとまっていて、ClientSize等のプロパティへの値代入と、ハンドラの定義のサンプルが多少書かれています。

F#Windows App (WPF)

Windows Formと似たような構成のWPF版。クリックすると文字が変わります。つまり、中央のコントロールのTextプロパティ変更と、ハンドラ追加のサンプルが最低限書いてあります。

F# Console App

コンソールアプリです。ただこれは、個人的にはあまり好きではありません。Argumentsという引数処理用の、おそらくテンプレート作者が書いた独自仕様のmodule(Argument.fs)が組み込まれていて、プロジェクトのテンプレートとしてはやや冗長です。
しかも、初期状態ではプロジェクトから「開始」を押してもちゃんと走らない。ソースコード中で「Required」と指定している第一引数がないのですぐ死んでいるのですが、ここはコンソールの窓に普通にHello Worldでも出して欲しかった。

雑感

入門向け勉強会やハッカソン、あるいは自分用の単純なGUIを作る際のベースとしては、良い感じではないでしょうか。

F#談話室 (4) に参加してきた

前回咳が止まらなくて病欠してしまったF#談話会、今回は無事参加できました。

• F#談話室(4)

自分の作業 (VS2012 for Web単体でF#ライブラリ プロジェクトを動かす)

15時頃着いて、まず馬券を買ったのちに作業開始…しようと思ったら、なんとVisual Studio 2012のWindows DesktopをノートPCに入れていなかったことが判明。C#からF#のライブラリを呼ぶものを今日は作ろうと思っていたのに、これは誤算です。
ただ、ライブラリ部分をC#から呼ぶだけならば、C#単体テストプロジェクトがfor Webでも作れるので、これでいけそうです。ビルド依存性の設定で、C#単体テストプロジェクトがF#ライブラリ プロジェクトに依存するように設定。

F#ライブラリ プロジェクトにはScript.fsxが入っているので、これが実行できればプロジェクト単体でいくつかテストも出来ると思うのですが、いまいち使用法がわかりません。普通に実行しようとすると、出力がライブラリなので実行できませんという、ライブラリプロジェクトに対してはごく普通のエラーメッセージが出るのみです。

F# Interactive を立ち上げて #load してみましたが、カレントディレクトリがWindowsのTempディレクトリになっているようで、使い勝手がイマイチですね。

作りたいものも決めていったのですが、実装作業の進みはいまいちでした。APIを調べながらの作業はノートPCで行うには不向き、かつどちらかというと設計段階でメモ帳に手書きみたいなフェイズであり、これ家でやった方がいいなあ…という感じでした。ノートPCで作業しても問題ないフェイズにしておくことを、次回以降は考えておきます。

LT

ヘヴィなトークが2時間くらいありました。16時→18時がLTだったので、結局参加時間のほとんどLT聴講に…！F#という言語をどう使うか？どういう利点があるか？というのは自分の謎でも、世間の謎でもあります。ヘビーユーザーの使いかた、というのは参考になりますね。
コンピュテーション式を使えるくらいになると、楽しくなるのかなあ。

C# (VS2012)のプロジェクトからF#のライブラリを呼ぶための初歩

Visual Studio 2012 Express Editionを使って、C#のWindowsアプリからF#のライブラリを呼ぶ。…ということをやりたかっただけなのに。VS2012では、F#はVisual Studio Express for Web、C#のデスクトップアプリケーションは、Visual Stidio Express for Window Desktopの担当に分けられていて、無用にめんどくさかったです。

手順

Windows DesktopのWPFアプリのソリューション内に、F#のライブラリプロジェクトを作成！ができれば簡単だったのですが、どうも上手くいかず、現在のところ以下の手順でなんとかしています。

1. for Webを使って、F#ライブラリプロジェクトを作成
2. そのプロジェクトで出来たdllを、for Windows DesktopのC#プロジェクト内「参照設定」に追加
• 参照設定→参照の追加で開いたダイアログ中の「参照」を押すとファイル選択ダイアログが出るので、選ぶ
• ライブラリプロジェクト名のdllがDebugとかReleaseとかの下にあるはず
• 同様にFSharp.core.dllも追加

 

fow Webの画面でF#をいじりつつ、for Windows Desktopの画面でWindowsアプリケーションをいじっています。どうにか1つに出来ないものかね…。

for WebでF#を動かすまでの話は少し前のポストの序盤に書いたので、あちらを参照で。

• F#談話室(2) に参加してきた | 賞味期限切れぷろぐらまー

あれ？DebugとReleaseどっちを追加すればいいんだ？切り替えるには、プロジェクトファイルに手を入れないといけないようです。F#で遊んでいる段階では常時Debugビルドでもいいんですが。

• 切り替え方法の参考：C#プロジェクトでRelease/Debugアセンブリを切り替える方法

プロジェクトを参照出来れば、こんなことをする必要はなく楽なのに。F#プロジェクトを含むソリューションを開こうとすると「このEditionではダメ」と言われてしまいました。出来る方法があったら知りたい。

• (2013/02/24追記) F#ライブラリは、--standalone をコンパイラに渡すと、F#関係もバンドルされたdllを生成できる (C#側でFSharp.dllを別に読まなくても良い)

• 方法：プロジェクトのプロパティ内のBuildタブ、Other flags: のところに入力
• 複数のF#ライブラリを呼ぶ場合は、各々が全てバンドルされてる意味はないと思う
• 参考： http://d.hatena.ne.jp/pocketberserker/20120118/1326874406

デバッグ

プロジェクトは分かれていても、for Windows Desktopの側からステップ実行したり、F#のソースにブレークポイントを張ったりできます。


F#で定義したところにステップインすると…

F#のソースがそのまま見えます。ブレークポイントも設置できます。普通にファイルを開いているだけなので編集もできますが、for Web上のF#ライブラリプロジェクトでビルドしないと反映されません。両側で編集しちゃうと危険。

技術的にはF#が混在することに全く問題なさそうだけれども、機能が潰されてる感じですね。普及段階なんだから、もうちょっとなんとかしてよ、と思います。

F#談話室(2) に参加してきた

今年も何か新しい言語に触ってみたいと思っていたところに、ちょうど入門コースのある勉強会があったので、参加してきました。

• F#談話室(2) on Zusaar

みんなで一斉に進めていきましょう形式ではなく、各自好きなことをやる集まりです。時間も夕方のLT以外は特に予定なく。

自分はF#の最初の一歩から始めたかったため、主催の七誌さんがビギナー向けとして用意してくださっていた資料を見ながら進めました。到着が17時、場所を閉めるのが20時、その間約3時間の参加でした。

環境のセットアップ (VS2012 ExpressでF# + Windowsフォームが遊べるまで)

無料のExpressでは、F#を使うまでに追加の作業が必要でした。F#を推進する気なら、最初から使えるようにしておけばいいのに…

• Visual Studio 2012 for Webをインストール
• Web Platform Installerを使って、追加コンポーネントとしてF#をインストール
• 検索窓にF#と入れると、それっぽいものが出てくる

環境としてはここまで。チュートリアルでは、C#の入門編でやっているようにWindowsフォームを表示させて遊びたいのですが、Visual F#のプロジェクトはライブラリとチュートリアルしか選択肢がありません。実用的には、ライブラリの利用のみが提示されている状態。
そこで、「F#のチュートリアルプロジェクトを作成し、元から書いてあるコードを抹消する」という方法により、F#でWindowsフォームの使えるプロジェクト構成を安直に入手することが出来る、と教わりました。

はじめての えふしゃーぷ

リバーシ(オセロ)のサンプルをいじって、ネット上の文法のリファレンスを見ながら、途中パワーユーザーの方のLTを挟んで、実質90分ほどかけて、なんとか自分で関数が書ける程度にまで進みました。(いきなりリファクタリングっぽいところから入る性分もどうかと思いますが…)
以下がそのコードです…と丸ごと貼るには少々長かったのでリンクのみ。
→https://gist.github.com/moccos/4967078

• 自作の関数を書いた
• 関数の引数に型が指定した
• enumっぽいもの(?)を使った
• if式、match式を覚えた
• for構文を使った
• 配列を使い始めた  (まだよくわかっていない気がする)

こんな状態です。石をひっくり返すロジックがないので、まだリバーシではなく石置きですね。

間違えたところ

• 関数の引数に型指定するとき、カッコをけちって失敗
• 関数呼び出すときに、引数足りなくて失敗

後者、C言語やJavaならば「そんな関数/メソッドないよ」というコンパイルエラーが出るところですが、F#は部分適用が効くので、違った形でエラーが現れます。boolを返す関数 myfunc x y を用いて if (myfunc 1) then ... と書くと、「boolじゃなくてint->boolがあるので型がおかしいよ」と言われるわけです。
ここでmyfuncの返り値を真っ先に疑ってしまいました。関数型言語そこそこに使っているのに、これは恥ずかしい…(ﾟДﾟ)

雑感

わりと無難な感じでF#の第一歩を踏み出せたような気がします。F#でいきなり何か作るのは難しくても、C#のプロジェクトの一部にF#のライブラリを混ぜ込むような感じで、徐々に浸食していけるように頑張ります。

言語自体については…mutableな変数が簡単に定義でき、クラスの概念があるので、Scalaと似たような立ち位置になるのでしょうか。JVMに対する.NET、Javaに対するC#、Scalaに対するF#、と。
ML系の言語が初めてなので、不慣れな文法や演算子にびっくりしながら進めてました。Erlangのときも、文法にはなかなか馴染めなかったので、新しい流儀に入るときはこんなものでしょうかね。全く抵抗を感じさせなかったScalaのすごさを改めて感じました。

Windows上でVisualStudio 2010と2012用にboostをビルド(x86/x64)

# はてなダイアリーから移動した記事です。あまり真面目に整形していません。

意外とめんどくさくて、次忘れそうなのでメモ。

ビルド環境

cl.exeでビルド。環境変数の設定がたくさんあって大変なので、無理せず、スタートメニューから辿れるビルド環境のコマンドプロンプトを使います。

• Windows SDK 7.1 Command Prompt
  • Microsoft Windows SDK v7.1の下にある
  
  

Visual Studio 2010のVisual Studioコマンドプロンプトだと、x86(32bit)しか作れないっぽいので、x64(64bit)のライブラリをビルドするのには必要。そもそも64bitバイナリをビルドする人はインストールしているはずですが。
Visual Studio 2012ではx86用とx64用のプロンプトが選べるので、2012だけならそちらで良いかも。

x86/x64の選択

setenv でさくっと設定できます。

Usage: "Setenv [/Debug | /Release][/x86 | /x64 | /ia64][/vista | /xp | /2003 | /2008 | /win7][-h | /?]"

/Debug   - Create a Debug configuration build environment
/Release - Create a Release configuration build environment
/x86     - Create 32-bit x86 applications
/x64     - Create 64-bit x64 applications
/ia64    - Create 64-bit ia64 applications
/vista   - Windows Vista applications
/xp      - Create Windows XP SP2 applications
/2003    - Create Windows Server 2003 applications
/2008    - Create Windows Server 2008 or Vista SP1 applications
/win7    - Create Windows 7 applications

Debug版とRelease版両方一度にビルドしてくれるので、そこを設定する必要はなさそうです。

> setenv /x64
または
> setenv /x86

ビルド時の引数による設定

まず、ビルド用の準備(共通)。解凍したboostソースコードのトップディレクトリで、バッチファイルを一撃。

h:\>cd boost_1_52_0
h:\boost_1_52_0>bootstrap.bat

あとは必要に応じてbjamへの引数を変えます。
参考：c++ - 64-bit version of Boost for 64-bit windows - Stack Overflow

• ターゲットバージョン
  • --toolset=msvc-10.0 など
    • 9.0が2008、10.0が2010、11.0が2012
• 出力先
  • --stagedir=x64 など
  • 指定したディレクトリの下にさらに lib が掘られて、そこに出力される
  
  

例：

bjam --toolset=msvc-11.0 --build-type=complete --stagedir=x86 stage
bjam --toolset=msvc-10.0 address-model=64 --build-type=complete --stagedir=x64 stage

64bit環境にしても、address-modelを設定しないと32bitになります。

32bitのビルドが行われる場合の、ビルド開始直後の表示例。

Performing configuration checks

    - 32-bit                   : yes
    - x86                      : yes

64bitのときは、32-bit の項目が表示されませんでした。(noと表示されるわけではない)

Performing configuration checks

    - x86                      : yes

出力ファイル

出力ファイル名は boost_random-vc100-mt-1_52.lib のように、コンパイラのバージョン入りになるので、バージョンごとに最終的な置き場所を変える必要はなさそうです。ファイル名のboostバージョンの前の部分に、gdと入っているのがデバッグ版です。boost_random-vc100-mt-gd-1_52.lib など。
ただし、どうやらこの長い名前をプログラマが意識する必要はなさそうです。

リンク

ヘッダをincludeしただけでビルドすると動いてしまい、なんだこりゃ？とヘッダを追いかけてみると、どうやら環境を判断して必要なlibファイルの名前を生成し、勝手にスタティックリンクしてくれているようです。あちこちに転がっているconfig.hppや、config/auto_link.hppなどが暗躍しています。
どうやらダイナミックリンクにしたい場合は…

• boost関係全てDLLにするなら、BOOST_ALL_DYN_LINKを定義
• 特定のライブラリのみDLLにするなら、BOOST_PROGRAM_OPTIONS_DYN_LINKのような個別定義を使用

Visual Studio 2010 Express + NUnit セットアップ段階のくだらない罠いくつか

# はてなダイアリーから移動した記事です。あまり真面目に整形していません。

環境はWindows 7 + Visual Studio 2010 Express Edition。

NUnit.orgがクソ重くて繋がらない

ダウンロードすべきファイルは別のドメインにあるようなので、ダウンロードページのGoogleのキャッシュからたどればOK。

セットアップ時に文句を言われる

2.6.0.1205をインストールしようとしたところ、こんなダイアログが出てインストールが止まりました。
2.5.10.11092 を試したらこれは出ませんでした。なんで2.6で突然古いバージョンの.NETが必要なんてことになってるんでしょうね？2.5系のインストールの時には、.NET1.1系はインストールオプションで選択できるようですが。


設定は詳しい記事があるので今更新しく書くことはなし。

• NUnit 2.5 の導入 Step by Step: TDD.NET

プロジェクトを読もうとすると文句を言われる

メッセージの通り、x86のバイナリをx64用のNUnitに食わせたので文句を言われています。
NUnitの実行ファイルには64bit(x64)版と32bit(x86)版があって、スタートメニュー等にショートカットが用意されているのはx64の方。同じディレクトリに32bitのnunit-x86.exeがあるので、32bitアプリはこっちで。Program Files (x86)の下なんですけどね…

コードを書き換えてもNUnit側で更新されない

NUnitの問題じゃないんですが、Visual C#の初期設定だと、上部のメニューバーにあるべきReleaseやらDebugやらの切り替えメニューが表示されず、Release版のみが作成されるようです。NUnitはDebugビルドを見ているようなので、初期設定のままではだめです。そして、コード書き換えたらビルドが必要です。

• 参考：Visual C# 2005 Express Editionで、Debug/Releaseビルドを切り替える - 極北データモデリング

Debugビルドできるように設定しておかないと、サンプルの実行もできなくて悲しい思いをすることになります。
(ここを設定する前にテスト用の設定に取り掛かる人は少ないかもしれませんが)