[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part16 (978ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
910: 896 2011/12/28(水)20:44 AAS
>>909
od コマンドが無いんで（Windows 7 環境）適当なバイナリエディタで見てみた
-------------------------------
{-# LANGUAGE CPP #-}
-------------------------------
7B 2D 23 20 4C 41 4E 47 55 41 47 45 20 43 50 50 20 23 2D 7D
-------------------------------
全く問題ないですよね
とりあえず、問題の stm パッケージさえインストールできれば作業は進むから、
#ifdef __GLASGOW_HASKELL__ などのマクロを外して自力でプリプロセスしようと思います
ですが、ひとつ問題が
#if ! (MIN_VERSION_base(4,2,0))
これは今使ってる base のバージョンが例えば 4.3.1.0 の場合、
これと #endif で挟まれている部分のコードは生きるんですよね
911: 896 2011/12/28(水)21:41 AAS
あかん
たとえ stm パッケージが無事インストールできても、
他の必要なパッケージで同じ問題が起きることに気づいた
もう OS 再インストールしか方法はないのかも知れん
912: 896 2011/12/28(水)21:59 AAS
意味も分からず解決してしまった
mingw-get-inst-20111118.exe をインストールしていたんだが、
これをアンインストールして、そのインストール先の mingw フォルダも全て削除したら、
何事も問題なく C のプリプロセッサ（CPP オプション）が使えるようになった
環境変数に mingw フォルダ内のどこかへのパスがあったわけでもないんだが、
なんでこれで解決するのか意味が分からない
GHC 内の mingw と干渉していたのではないかと思うが、
今まで普通に GHC と外部の mingw は共存できてたと思うんだが・・・
まぁいいや
お騒がせしました
913: 2011/12/30(金)15:54 AAS
windowsなんて捨ててlinux/mac系でやれば楽なのにね。
914: 2011/12/30(金)17:05 AAS
全くだ
915: 2011/12/30(金)17:09 AAS
馬鹿には無理
916: 2011/12/30(金)17:30 AAS
むしろ馬鹿ほどmacだと思う
917: 896 2011/12/31(土)11:39 AAS
wxHaskell を使ってるんだけど、以下のコードの挙動が予想外だ
（dc は paint イベントのハンドラの第1引数 DC () 型）
drawText dc "abc" (Point 0 0)
[ textColor := green
, textBgcolor := blue
]
俺の予想だと、青色の背景に緑色の文字が表示されると思ってたんだ
でも実際は、透明の背景に青色の文字が表示される
これは正しい挙動なのか、それともバグなのか？
[環境]
OS : Windows7
GHC : 7.2.2
wxPack : 2.8.12.01
wx : 0.12.1.6
wxCore : 0.12.1.7
918(2): 2011/12/31(土)11:48 AAS
wxHaskellは知らないけど
wx的にはwxDC::setBackgroundMode()で挙動が変化したような?
919: 2011/12/31(土)13:36 AAS
>>918
ありがと
ただ、残念なことに、今の wxHaskell では
DC の BackgroundMode を設定できないみたいだ
それらしい関数やプロパティが見当たらない
920(2): 2011/12/31(土)16:32 AAS
これじゃね
外部ﾘﾝｸ[html]:hackage.haskell.org
921: 2011/12/31(土)18:43 AAS
>>920
あ、なるほど dcSetBackgroundMode か
頭文字 s とか b で探してた
（部分一致とかで検索できないと不便だなぁ）
ありがと
922: 2011/12/31(土)19:26 AAS
>>918,920
dcSetBackgroundMode 関数に 100（wxSOLID）を設定してみたところ、
文字の背景に色が付きました
しかし、これだけでは背景の色は真っ白でした
そこで、次の様にしてみたところ、意図通りの結果
背景が黒で文字が赤色になりました
withBrushStyle (brushSolid black) $ \b -> do
dcSetBackground dc b
dcSetBackgroundMode dc 100
dcSetTextForeground dc red
dcSetTextBackground dc black
drawText dc "abc" (Point 0 0) []
どうも、drawText 関数とか set 関数で設定する textColor や textBgcolor は
正しく反映されないみたいです
（textBgcolor が文字の色になり、textColor が反映されない？）
おかげさまで目的は達成できました、ありがとうございました
時間がとれたらバグ報告してみようと思います（英文作るのにかなり時間がかかるんで）
923: 2011/12/31(土)23:24 AAS
よいHaskellを！
来Haskellは更に良いHaskellになるよう祈ってます。
924: 2012/01/01(日)00:00 AAS
おめでとう
925(2): 2012/01/01(日)21:54 AAS
なんだよ。789、790あたりを見てから、やっぱりモナドは注目すべきなんだろう
と思ってちょっと調べていたんだが、もうとっくの前に情報処理上で和田英一
さんが喝破しているじゃないか。やっぱりモナドなんて騒ぐほどのものじゃねえよ！
｢関数プログラミングの泣き所は入出力を含む副作用である。．．．Haskellは
シリアルに計算を進めるメカニズムのmonadを考案し、これを解決したと言っ
ているが、関数型を一部手放したと言うべきであろう。Lispにも最初からprog
があった。｣
926: 2012/01/01(日)22:18 AAS
理解が追いつかないことでの話のすり替えだね
927(1): 2012/01/01(日)22:30 AAS
和田英一って適当なこと言うんだな
「関数型を手放した」というのは意味不明だし、
モナドとIOを区別してないのは(言いたいことは分からんでもないが)雑な議論
928: 2012/01/01(日)22:36 AAS
和田サンは鞍とキーボードを同一視するくらいの人だからな
モナドとIOなんて同じようなもんなのだろう
達観してる
929: 2012/01/01(日)22:39 AAS
うーん。そうとも限らないよ。
やみくもに理解･学習しようとするだけでなく、理解･学習に値する事か
どうかも時々気にしておいた方がいいよ。
930: 2012/01/01(日)22:40 AAS
ああ、HHKの人か
キーボードは良いけど発言はいただけないな
931: 2012/01/01(日)22:45 AAS
>>925
お前、自分の考えは言わないのな
932: 2012/01/01(日)22:49 AAS
追従する学習者たちは細かい区別を気にする。創造的達人は大きく同一視
できる。いずれ時がたつと後者に収斂する。
933(2): 2012/01/01(日)22:55 AAS
>>927
あなたはモナドを発明した人かそれとも学習しつつある人か
934: 2012/01/01(日)22:56 AAS
じっじゃんだからなぁ。もう８０超えてるんだぜ
935: 2012/01/01(日)23:00 AAS
年は関係ない。
若い凡百のHaskellプログラマーの見解を聞くより、ずっと傾聴に
値する。
936: 2012/01/01(日)23:01 AAS
>>933
モナドを発明した人ではないよ
学習しつつあるとは言えなくもない。別に積極的には学習してないが
937: 2012/01/01(日)23:16 AAS
>>933
微分積分などの計算方法と違って、
モナドって発明というよりは発見なんじゃないか？
誰かは忘れたが、圏論の中でモナドの構造を見抜いた
違うか、ある共通の構造を見抜いて、それにモナドと名前を付けた
まぁその応用は発明に近いかも知れんが
Moggi氏が、言語の表示的意味論の構造を要素分解するのに、
そのモナドという眼鏡（見方・枠組み）が使えることを見いだした
で、Wadler氏が、表示的意味論に使えるのなら、
ある意味それに近い関数型言語にも利用できると閃いた
938: 2012/01/02(月)00:49 AAS
上の方にpdfのリンクあったろ
発作起こしてないで読め>>925
939(1): 2012/01/02(月)02:01 AAS
FFI 関連について質問です
C言語で構造体と、それを引数として受ける関数などを作りました（*.h、*.c）
*.hsc ファイル内でそのヘッダファイルを include し、
C言語で定義したのと同じ構造のデータ型を定義しました
そして、Storable 型のインスタンス宣言の中で、
#size や #alignment マクロを使って
Storable.sizeOf や Storable.alignment を定義しました
（#alignment マクロは下記のサイトのものをそのまま使いました
外部ﾘﾝｸ:stackoverflow.com
ghc 7.2.2 ですけど、まだ組み込みマクロではないようですね）
そのあと、ghc2hs コマンドで *.hsc から *.hs を生成し、
また *.c をコンパイルして *.o を生成し、
それらを一緒に ghc でビルドしようと思います
（まぁ実際は、*.c のまま ghc に一緒に放り込んでも良いわけですが）
そこで質問なのですが、この場合、
*.c は ghc 付属の gcc、あるいは別に用意した同Var.の gcc でコンパイルしないと、
構造体のメモリマップが ghc2hs の解釈と（理論上は）合わないと思うのですが、
この認識は間違ってないでしょうか
正確に言えば、ghc の -pgmc オプションで指定したC言語コンパイラ、
hsc2hs の --cc オプションで指定したC言語コンパイラ、
そして *.c をコンパイルしたC言語コンパイラ、
この3つのコンパイラが同じ物でないと危険なのではないでしょうか
（たまたま、VC++ のコンパイラなどとその辺りの仕様が同じ場合もあるでしょうが）
上下前次1-新書関写板覧索設栞歴
あと 39 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.033s