#齊藤さんいるかな。mingwでgdbmを使われているようですが、このgdbmはmsysのやつですか? それともmingw dllで動作するように独自コンパイルしたやつですか? msysのgdbmだとすると、動かすにはmsys dllが必要ですよね?
#mingw版のバイナリ配布をする場合、msys dllには依存できないので、どうしようか考えてます。
#というかそもそもうちのmingw+msysでgdbmがなんか動かないぞ…
#スタティックリンクしました。
#gdbm のコンパイル時に --disable-shared にしてます。
#なるほど。ソースからコンパイルしたってことですね。
#mingw+msys下で普通に./configure+makeでした?
#--prefix=/mingw もつけとかないと gcc が探してくれません。 コンパイル時オプションはそのふたつだけです。
#了解です。gdbmはGPLなんで、バイナリ配布するとしたらgdbmをスタティックリンクしたモジュールを本体とは別に配布することになるかなあ。
#むむ。flockにまつわる定義が見つけられなくてfailするな > gdbm on mingw
#msys絡みで足りないものがあるのかな?
#どこかにパッチがあったかも。
##どちらにせよ別配布になるので、とりあえず0.9は現状で出しちゃう方向でいます。
#これすんごく面白い: http://www.cowlark.com/2009-11-15-go/ Google Goと「ある言語」との比較 (言語マニアならどの言語かすぐにわかっちゃうけど)。 #しかし、concurrencyの言語レベルでのサポートっていうのは、一巡するのかなあ。Schemeも一番最初のやつにはconcurrencyの組み込みサポートがあったんだよね。いつの間にかなくなってしまった。
#R3RSからしか知らない...
#最後まで読むと面白い!RT : shiro: これすんごく面白い: http://www.cowlark.com/2009-11-15-go/ Google Goと「ある言語」との比較 (言語マニアならどの言語かすぐにわかっちゃうけど)。 #おもしろい> Brand X
#shiroさんとhigeponさんにgoogle goに対する現状の意見を聞いてみたい
#うーん、Goの重要は言語仕様よりむしろ実装(ランタイム、コンパイラ)だと思うんで、そこは使ってみないとわからないですね。
#s/重要は/重要な点は/
#実際使われるのかなー? というところにかなり疑問がありますが > go
#Erlang並にスケールするならかなり使えるんじゃないかと思います。
#外の人が使わなくても中の人がこつこつ使ってればかなり仕様実績を積み重ねられるのでは。ErlangだってEricssonの中で使われてた時期が何年もあったんじゃないでしょうか。
#なるほどー
##ネイティブコンパイルってのは Google 内部の要求に思えますね。そこが Erlang と違う。
#Erlang は自分で使っていてやっぱり遅いなと思います(腕がないからかもしれませんが)
#Erlangはどっちかというと耐障害性に重点を置いてるような印象がありますが、そのへんはどうですか。
#耐障害性のフレームワークはあって部品はそろっています。ただやっぱりノウハウがないとつらいなと感じます。Ericson のエンジニアにあって自分にないのはノウハウ。
#>Erlang
#C/C++/Java 風の文法は普及するかもと思わせますね>golang
#あのシンタックスはださいな... と思ってしまうのですが... > golang
#go-mode.elがいまいちなだけかも
#まあそうなんですが、世の中の大半は Java プログラマーと思うと(ry
#結局 Google は C++ はもういやになったのかもしれませんね。20 % プロジェクトから昇格させたって事は多少本気かもしれない。
#シンタクスなんて飾りですよ(ry
#コンパイル時間の問題は深刻だったんじゃないでしょうか >C++
#私もUnreal Engine使ってた時にコンパイルの遅さに悩まされました。
#コンパイルは分散コンパイルでどうにかしていると聞いた事があります、リンカは分散できないので gold を作ったとか。
#分散コンパイルも起動時のオーバヘッドがあるんですよね。リンカも含めて結局は従来のC/C++のツールチェインの問題なので、そこをいじるなら言語から全部書いちゃった方が手っ取り早いという発想はありだと思います。
#そうした場合の問題点は枯れるまで時間がかかるってことなんですが、Googleくらいの規模でがしがし使ってたらわりと早く枯れるかもしれませんし。
#そうですね。しかし面白い物はほとんど Google からでてくるな。
#しかしgoogleはなんでplan9が好きなんだろう? やっぱ分散やってるとそうなるのかなー
#「googleが好き」なんですかね? あれだけバックグラウンドの厚い人がいれば、むしろ「関わった人たちが好き」という方が説明になっていそうな。GoについてはKen ThompsonやRob Pikeがやってるわけですし。
##google osの2こ右
#なるほど。ただ、googleもあれだけ大所帯ですから、「googleはこれが好き、これが嫌い」というような主体があり得るのかなあ、というふうには思います。(会社の空気として何となくの傾向というのはあるでしょうし、また会社内での目立つ人物の好みというのが外から見えるということもあるでしょうが、「Naughty DogはLispが好き」というような話とはレイヤが違うのかなあと)
#なるほどー
#googleは現代のbell研みたいになってきてますねー
#--prefix=/mingw は gdbm の configure に必要っていうつもりだったんですけど…
#/mingw/lib にインストールして欲しいところが素のままだと /msys/1.0/lib の方にインストールされちゃって、 gcc が見付けてくれないという感じ。
#何らかのdbm系ライブラリが存在することはunixではデファクトだったんだけど (NISとかsendmailとかが使ってた)、gdbm系入れるのは色々面倒だなあ。*BSDはdbm系ライブラリには何を使ってるんだっけ。Berkeley DB?
#BSDライセンスで軽いやつがあるなら、フォールバックとしてバンドルしちゃうって手もあるかもしれない。
##そういえばそのへんがよくわからなくてdbm.bsddbをほったらかしにしていたような気がする。
#http://bit.ly/353cDE これですか? RT : shiro: 今のBerkeley DBは完全にBSDライセンスと互換じゃないのかな。 #はい。最初のライセンスの第3項は、"complete source code for the DB software and any accompanying software that uses the DB software" をつけなくちゃならないっていうcopyleft的な項目になってますね。
#NetBSD が OS と一緒に配布してるのは db 1.85 ですね。
#最近のBSD DBって、sleepycatからOracleに買われた奴のことを指すんですかね?
#いや、sleepycatの時のライセンスもなんかbsdコンパチじゃなかったような気がする。
#なるほど
#1.85ってことはかなり前にforkしたのかな。
#db4ってのは違うわけですね
#QDBMもTokyo CabinetもLGPLだからだめですね
#SQLiteバンドルってわけにはいかないか。 http://bit.ly/TsZx8 #1.85 が import されたのが 1996 なので、13 年前?
#SQLiteはちょっと性質が違うというか。単純なkey-value storeがあればいいわけで (まあkey value storeとして使えないわけじゃないけど)
#fsdbmをもうちょっと真面目に実装するってのが一番無難かもしれない。
#でも NetBSD では /etc/s?pwd.db も alias.db もそれで賄っているのでそれで大抵は足りるということかも
#まあ、berkeley dbのトランザクションとか色々アドバンストな機能は、dbm互換として使ってる限りは必要無いわけですしね。
#fallback っていう用途ならメンテナンスのし易さといった観点で選べばいいのかな
#何か妥当なものがないかと検索してたらこのチャットがひっかかった。
#Googleさん捕捉が早いなー
#1.86まではBSDライセンスってことみたいですね。 < Berkeley DB
#Windowsの日本語版使ってる方って、コンソールウィンドウ(cmd.exe)で日本語ってどうやって出してますか? うちにあるのはXPもVistaも英語版なんですが、eastern language supportを入れてもコンソールのコードページは932にできず、フォントもデフォルト以外はLucida Consoleしか出てきません。
#chcp 65001してフォントをLucida Consoleにすればλとかは表示できるんで、単にフォントの問題だと思うんですが。
#レジストリ見ると932にしたらMSゴシックが使われる感じなんだけど932に出来ないしなあ。
#(chcp 932すると"Invalid code page"と言われる)
#Consolasフォント入れてみたけどやっぱり日本語は駄目みたいだなあ。λは出る。
#日本語版だと Shift_JIS でだせばそのまま表示されます。たしか。
#逆に英語版の動きをエミュレートしたい場合は、英語モードみたいなのがあったような。
#chcpって実行すると何が出ますか。
#あ、いま会社なので日本語版がためせないんですけど、chcp で出てくる結果は、Windows の言語設定で設定できます。
#会社の Windows Vista 64 は 437。
#英語版はそうなんですよね。で、多分日本語版だと932になってると思うんですが、問題は英語版windowsで932にしようとしてもできないってところで…
#言語設定が日本語になってないとcp932が選べない、とかそういう制約があるのかなあ。
#んー、アジアフォントセットをインストールしていれば、日本語にできましたよ。えっと、どうやるんだったかな。
#というかできればunicodeで使いたいし、cp65001 (utf-8) は選べるわけで、あとはcp65001対応のコンソールフォントがあればいいって話なんですが、検索してもそういうものが出てこない。
#(ああ、LucidaやConsolasはcp65001対応といえばそうなんだけど、CJKが入ってない)
#なんか、Vista の言語設定は XP とも微妙に違うみたい……。
#コンソールなんてあんまりサポートする気が無いのかなあMS。
#Control Panel -> Regional and Language Options -> Administrative にある、Current language for non-Unicode programs で Japanese ってでてきません?
#XPで日本語環境にしたらCP932が選べてフォントもMSゴシックが選べるようになりました。
#コードページの選択は言語設定に依存するってことですね。まあレガシーのコードページだと言語を決めないと解釈できないから理屈のうえでは正しい設計か…
#日本語環境でもコンソールをcp65001に切り替えると、選択できるフォントからMSゴシックが外れ、LucidaとConsolasだけになります。で、日本語は化ける。
#kore
#これ、やっぱりcp65001対応の多言語フォントファイルがひとつあればいい話じゃないのかなあ。誰か作ってないかなあ。
#というか他のアプリでは言語設定英語でも日本語表示出来てるわけで、つまりはコンソール自体が対応しきれてない(レガシーである)ってことなのか。
#Lucida Sans Unicode にして、Windows API で表示するときに UTF-8 -> WCHAR に変換したら、大体の文字は表示できたんですけど、
#Windows の言語設定を日本語にすると韓国語が出ないとか、英語にしておくと日本語も韓国語も出るとか、いまいち挙動が良くわかりません。
#WriteConsoleWを使ったってことですか?
#ああ、すいません、フォントの描画です。
#ああ、了解。コンソールのコードページはアプリから変えられるけど、フォントの設定はユーザに変えてもらわないとだめっぽい。
#なので、Windows API レベルで、どんな言語でもオッケーな方法って、ないんじゃないかなぁとおもって。
#MinGWのプリコンパイルバイナリを配布するのに、できればutf-8でコンパイルしとくのがトラブるが少ないと思うんだけど、そうするとかようにコンソールで日本語が出ないということになるなあと悩んでたんです。
#shift-jisでコンパイルしとけば日本語環境で使ってる人は日本語が見られるけど、それって日本語圏にしかメリットないし。
#Gauchebox推奨にしてみんなMeadowから使ってもらうか。
#出力するときにコード変換ポートかますのを推奨するとか。
#出力のコードページを見て932だったらshift-jisに変換するってことはできますね。ただ、cp65001にしてるユーザがutf-8 gaucheを使った場合、プログラムから見たら全てのunicode文字を素通しでいいはずなんですよ。単にフォントが対応してないってだけで。
#んー、おしいですねぇ。あ、でも、Windows 的には UTF-8 のバイト列は、中でいっかい WCHAR に変換しないと文字として認識できないでしょうから、UTF-8 を素通りさせるのはむりなんじゃないでしょうかね。
#フォントを描画するときに、かならず文字単位で座標の計算をしないといけないから。
#フォントだけで解決しない気がするんですけど。
#うーん、それはランタイムで解決されてるんじゃないでしょうか。現に、出力コードページが932の状態でshift-jisバイト列を出力すれば日本語は表示されるわけですし、出力コードページ65001の状態でutf-8バイト列のギリシャ文字はやっぱりちゃんと表示されるわけです。
#まあcp932(や、その他のCJKローカルコードページ)の場合だけ特殊なハックを仕込んで幅可変フォントに対応してるって可能性は無きにしもあらずですね。cp932に限れば、漢字は倍の幅ってことで座標計算できるわけで。
#真面目にunicode汎用にしようとするとフォントの方から情報を取らないとならないから、そこまでは面倒でやってないのかも。
#なるほど。
#UTF-8 がそのまま通れば、ぼくのしごともだいぶ楽になるんですよねぇ。
#Gauche/mingwについては、まともなフロントエンド(emacs)とかをかませばutf-8で問題ないのでとりあえずこれで行くかなあ。後は何かのオプションをつけたら独自にコンソールを開いて何とかする、とかいう方向の方が悩まずに済みそうだ。
#PLTみたいに独自のシェルを作るしかないのか>Windows
#そっちの方が話が楽な気がします。Windowsのいろんなセッティングに悩まされるより。
#Windows console APIにはだいたいGaucheからアクセスできるようになってるんで、Gaucheだけで独自コンソール書けないかなあ。まだちゃんと見てないからわからないんですが。
#Windows版でcmd.exeシェルを捨てるなら、Benjaminさんのアイデア通りMeadowのロゴをGaucheロゴにした方が良いのか。でもMeadowのロゴはMeadowのインストーラーが作ってるんだよな。
#それはMeadowを公式Gaucheシェルとしてバンドルしてしまおうってこと?
#Gaucheboxに限ってはその方が自然かも>Meadowがシェル
#Gauche MinGW単独のインストーラの場合はcmd.exeをシェルにするしかないですね。またはPLT方式で何か作るか...
#今悩んでるのはそっち>単独インストーラ
#cmd.exeがUTF-8を通さないのはWindowsのバグなんだから、堂々とUTF-8で出荷するというのはどうでしょう。
#0.9はそれで行くしかないでしょうね。将来的には、例えば出先のマシンでちょろっとgosh欲しいと思った時にさくっとダウンロードして使えると嬉しいので、それなりに便利にしたくはあります。