K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]

新規投稿 | 開設者ホームページへ戻る | ヘルプ

[1504] Re:「プログラミング言語を作る」のURL
投稿者:(ぱ)こと管理人
2010/02/17 00:41:47

>> 本に掲載したURLにリダイレクトを置くことで対処いたしました。 >と書かれていますが、エラーページが表示されているようです。 まさかと思って試してみたところその通りでした。 どうやら、リダイレクトのページをhttp://kmaebashi.com/devlang/ 直下(bookの 下でなく)に置き、置いたときの動作テストもそこを確認してしまったようです。 さきほど修正いたしました。 ここに書いても仕方がないのかもしれませんが、辿りつけなかった方には 重ね重ね申しわけありませんでした。お詫び申し上げます。 通りすがり様、情報ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1502] 「プログラミング言語を作る」のURL
投稿者:通りすがり
2010/02/16 08:14:14

こんにちは。 > 本に掲載したURLにリダイレクトを置くことで対処いたしました。 と書かれていますが、エラーページが表示されているようです。 私はドメイン名からトップに飛び無事に辿り着けましたが…
[この投稿を含むスレッドを表示] [この投稿を削除]
[1501] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:(ぱ)こと管理人
2010/02/14 00:08:06

青餓鬼さん、yuyaさん、ありがとうございます。 管理人が放置してしまいましてすみません。 この結論を関連ページに追記しました。ありがとうございました。 >とりあえず、Macの人に対しては >「とりあえずUTF-8版を試してください。 >駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 >って指針で、多くの人に使ってもらえそうですね。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1500] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:yuya
2010/02/11 22:20:01

青餓鬼さん、試していただいてありがとうございます。 とりあえず、Macの人に対しては 「とりあえずUTF-8版を試してください。 駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 って指針で、多くの人に使ってもらえそうですね。 私のほうも、ここらで追究を一段落させていただきます。 ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1499] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:青餓鬼
2010/02/11 16:04:04

>(1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか? Mac OSX 10.5の方はコマンドの追加もなく、ちゃんと動きました。 >(2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 >差し支えなければ echo $LC_ALL も試してみてください。 echo $LC_ALL の実行結果は、Mac OSXの10.4、10.5共に(空文)でした。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1496] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:yuya
2010/02/03 18:05:11

>私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した echo $LANGの結果は(空文)でした。 >ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 返信ありがとうございます。 (1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか? (2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 差し支えなければ echo $LC_ALL も試してみてください。 MacOS X のことは全然分かんないや……。FreeBSDベースらしいということと、 http://homepage3.nifty.com/toshi3/osx2t.html の最後に >Mac OS Xではファイル名はUTF-8、Unixに由来する部分では日本語EUC、 >従来のMac OSに由来する部分ではShift-JISと、複数の文字コードが混 >在して使用されている。 と書かれていて、とにかく複雑なことになってる、ってことは分かりました。 あと、Unicode正規化の方式も違うようで、 http://labs.unoh.net/2007/09/unicode-on-mac.html 手元で実験できない私としては混沌とするばかりです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1495] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:青餓鬼
2010/01/31 16:05:29

>export LANG=ja_JP.UTF-8 > >で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 >ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか? 私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した echo $LANGの結果は(空文)でした。 ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 環境変数LANGに何も指定されてなくても日本語が表示されるところを見ると別の環境変数があるのでしょうが、それについての解説は見つけることはできていません。 以上
[この投稿を含むスレッドを表示] [この投稿を削除]
[1494] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:yuya
2010/01/24 17:04:03

export LANG=ja_JP.UTF-8 で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[1493] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:青餓鬼
2010/01/23 15:03:36

Macで実行する際、UTF-8の場合exportコマンドで環境変数を指定すると、正常に実行することがわかりました。 >export LANG=ja_JP.UTF-8 このコマンドを実行した後に DIKSAM を実行すると、サンプルと同じ結果を得ることができます。 Macの技術解説書にこのあたりを体系的に記述したものが見あたらず、たまたま読んだコマンドリファレンスの、別のコマンドの実行例に、上に掲げた一文があり、早速実行すると、エラーなく実行できました。 なお、EUCの場合は、ターミナル上の日本語表示が文字化けしますので、別の環境変数があるのかもしれません。これ以上、深入りは当面控えておきます。 以上
[この投稿を含むスレッドを表示] [この投稿を削除]
[1492] Re:ホームページと本との違いについて
投稿者:ぽむじぃさん
2010/01/19 10:32:35

>HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 >死んでしまうのはおかしいと思うのですが…… >念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した >上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが >死にはしませんでした。(Windows Vista環境) > 私もcrowbarcer_ver.0.2をターミナルで実行したところ時間はすごく掛かりましたが正常に終了しました.申し訳ないです.こちらも確認すべきでした. 私が開発環境はMacのXcodeです.GUIにcrowbarを組み込んでいます.ちなみにOS Xの10.6です. どこか実装にミスがあるのかもしれませんね^^;要素が大きくなるときだけGC_mark()で止まってるようなのですが難しいですね.本当にお手数かけました.
[この投稿を含むスレッドを表示] [この投稿を削除]
[1491] Re:ホームページと本との違いについて
投稿者:(ぱ)こと管理人
2010/01/19 03:08:15

>尚,私の環境では200*200*200では4秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました. >実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました. HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 死んでしまうのはおかしいと思うのですが…… 念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した 上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが 死にはしませんでした。(Windows Vista環境)
[この投稿を含むスレッドを表示] [この投稿を削除]
[1490] Re:ホームページと本との違いについて
投稿者:ぽむじぃさん
2010/01/17 18:24:47

>>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています. >>#GCされないようにおまじない >>CRB_push_value(inter, &ret); >> >>CRB_pop_value(inter); > >これは、ネイティブ関数内で確保したオブジェクトがGCされないように >スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に >(面倒くさいという意味で)負担をかけますので、 >Webページ版においても以下のページで方法を変更しています。 > >http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html > >前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 >本の方では、最初から後者の方法で実装しているわけです。 >本では、後者の方法について、171ページで説明しています。 > >>私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >>ところで止まってしまいます.私の実装ミスか,その部分のコードが足りない >>せいなのか分からないので質問させていただきました. > >crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が >増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても >オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では >確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の >中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する >方がよいのでしょうが、現状ではそうなっていません。 >ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 >200×200×200だと30秒近く待たされました。 > >簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという >方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを >動かすかという閾値で、現状では256KBになっています。 > 早速の返信ありがとうございます. 私はver0.2を参考にしていたのでそれ以降を見ていませんでした.申し訳ありません.最後まで読んで質問するべきでした. >>多次元ですと、現状の実装では確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります なるほど納得しました.実装ミスというわけではないのですね.安心しました. 尚,私の環境では200*200*200では4秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました. 実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました. どうしても多次元で要素数が多い場合にも対応する必要があるため本当に助かりました. 有り難うございます.
[この投稿を含むスレッドを表示] [この投稿を削除]
[1489] Re:ホームページと本との違いについて
投稿者:(ぱ)こと管理人
2010/01/17 16:03:31

>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています. >#GCされないようにおまじない >CRB_push_value(inter, &ret); > >CRB_pop_value(inter); これは、ネイティブ関数内で確保したオブジェクトがGCされないように スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に (面倒くさいという意味で)負担をかけますので、 Webページ版においても以下のページで方法を変更しています。 http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html 前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 本の方では、最初から後者の方法で実装しているわけです。 本では、後者の方法について、171ページで説明しています。 >私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >ところで止まってしまいます.私の実装ミスか,その部分のコードが足りない >せいなのか分からないので質問させていただきました. crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が 増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では 確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の 中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する 方がよいのでしょうが、現状ではそうなっていません。 ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 200×200×200だと30秒近く待たされました。 簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという 方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを 動かすかという閾値で、現状では256KBになっています。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1488] ホームページと本との違いについて
投稿者:ぽむじぃさん
2010/01/17 05:13:07

配列の確保、およびネイティブ関数の書き方についての質問です サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています. #GCされないようにおまじない CRB_push_value(inter, &ret); CRB_pop_value(inter); ところがこのコードの部分は本書及び,サンプルソースでも書かれていませんでした. これは必要ないということでしょうか? またそのような関数名はないようなのですが,eval.cのpush_value(),pop_value()のことでしょうか? 私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()のところで止まってしまいます.私の実装ミスか,その部分のコードが足りないせいなのか分からないので質問させていただきました.
[この投稿を含むスレッドを表示] [この投稿を削除]
[1487] Re:質問
投稿者:(ぱ)こと管理人
2010/01/15 08:18:32

>crowbarのfor文どのように実装されているのですか。 >本を何回も読みましたが見逃してしまっているかもしれませんので、本にあるならば、ページ番号を教えてください。 p.115でwhileの実装についてコード込みで説明しています。 p.115には、「ここから呼び出される関数を全部見ていくのは紙面の無駄ですので、 ここでは代表としてwhile文で呼び出されるexecute_while_statement()を取り上げ ます。」と書いてあります。 紙面節約のため代表としてwhileを取り上げているわけですから、forについての 直接の説明はありません。whileを参考にソースを読めばわかるという意図で 省略しているわけです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1486] 質問
投稿者:高校生
2010/01/14 13:45:57

crowbarのfor文どのように実装されているのですか。 本を何回も読みましたが見逃してしまっているかもしれませんので、本にあるならば、ページ番号を教えてください。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1484] Re:質問
投稿者:(ぱ)こと管理人
2009/12/23 21:19:00

>create.oなどOファイルがありますが、これには機械語とリンク処理に必要な情報が含まれている、と考えていいのですか。 何を知りたいのかわかりませんが、その通りです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1483] 質問
投稿者:高校生
2009/12/21 11:55:46

create.oなどOファイルがありますが、これには機械語とリンク処理に必要な情報が含まれている、と考えていいのですか。Oファイルを見てみると機械語みたいなものが書いてありました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1481] Re:質問
投稿者:(ぱ)こと管理人
2009/12/05 10:24:21

>前回はすみません。知りたかったのは、ファイルの題名です。 そのソースファイルでやっていることが理解できているのなら、題名くらい、 自分でつければよいでしょう。 そもそもなぜ「題名」などというものをつけなければいけないのかわかりませんが。 学校のレポートに書くというのなら、それを私にまるごと聞くのはカンニングと同じです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1479] Re:質問
投稿者:(ぱ)こと管理人
2009/11/28 14:18:56

>crowbar_book_0_1の >string.cとmain.c(memoryフォルダに入ってないほう)の説明がほしいのですが。 >ファイル名や中身からしてなんとなくわかる気もするのですが、 出張中につき手元に本はないのですが、 main.cといえば、これですよね。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/1.html このページの、 http://kmaebashi.com/programmer/devlang/crowbar.html 「Cからcrowbarを呼び出す」 は、説明になっていませんか? また、string.cについては、 http://kmaebashi.com/programmer/devlang/crowbar_0_1.html にて、以下のように説明しています。 | 文字列リテラルに関しては、開始の時点でcrb_open_string_literal() を | 呼び出し、途中の文字はcrb_add_string_literal()で追加、最後は | crb_close_string_literal()で文字列終了、という手順を踏みます。 | その間、文字列は、string.c中の st_string_literal_bufferという | static変数に保持されています。 説明不足でわからないのかもしれませんが、どこがどうわからないのか 言ってもらわないと、回答のしようがありません。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1478] 質問
投稿者:高校生
2009/11/26 13:04:12

crowbar_book_0_1の string.cとmain.c(memoryフォルダに入ってないほう)の説明がほしいのですが。 ファイル名や中身からしてなんとなくわかる気もするのですが、 簡単にでもいいのでお願いします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1476] オブジェクト指向再入門/「オブジェクトに仕事をさせる、ということ」のソースについて
投稿者:(ぱ)こと管理人
2009/11/22 18:33:00

メールにてご指摘がありました。 以下のページのソースコードにおいて、 http://kmaebashi.com/programmer/object/shigoto.html Java版の以下のソースに間違いがありました。 // コロンで区切るためのStringTokenizerを生成 StringTokenizer st = new StringTokenizer(line, ":"); // 著者名を(複数)取り出す writers = st.nextToken(); // コンマで区切られた著者名を順に切り出すために // 新たなStringTokenizerを生成 StringTokenizer st2 = new StringTokenizer(line, ","); i = 0; while (st2.hasMoreTokens()) { writer[i] = st2.nextToken(); i++; } 著者名を順に切り出す対象は、その前のStringTokenizerで取得した writersですから、以下のようにしなければいけません。 // コンマで区切られた著者名を順に切り出すために // 新たなStringTokenizerを生成 StringTokenizer st2 = new StringTokenizer(writers, ","); 現在海外出張中でオリジナルが直せませんので、取り急ぎお知らせします。 すみませんでした。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1475] Re:質問
投稿者:(ぱ)こと管理人
2009/11/21 01:33:54

>util.cについて教えてください。 >/* BUGBUG >CRB_NativeFunctionProc * >    . >    . >*/ >とコメントにしたのはなぜでしょうか。 おそらくは昔はネイティブ関数とcrowbarの関数を別々の連結リストで 管理していたところ、あるとき一本化して、この関数だけ残骸として 残ったようです。無視してください。 リリース前にはきれいにしておくべきでした。すみません。 >/*FALLTHRU*/というのは何かの指令なのですか。 >C ソースコード検査プログラムの lint と関係ありますか。 lintと関係あります。 Cのswitch caseというのは、「breakを書かないと下に落っこちていく」という とんでもない仕様になっているので、よくbreakを書き忘れてはまる人が いるわけです。そこでlintはそれを検出する機能があるわけですが、 といって、本当に「下に落っこちていく」動きにしたい場合に警告が出て しまったのでは困りますので、その警告を抑止するコメントが/* FALLTHRU */です。 とはいえいまどき昔ながらのUNIXのlintを使っている人は少ないでしょうし、 gccとかだと無視するようなのであまり意味はないかもしれませんが。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1473] 質問
投稿者:高校生
2009/11/18 11:54:00

util.cについて教えてください。 /* BUGBUG CRB_NativeFunctionProc *     .     . */ とコメントにしたのはなぜでしょうか。 /*FALLTHRU*/というのは何かの指令なのですか。 C ソースコード検査プログラムの lint と関係ありますか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1472] Re:DIKSAM_book_0_4のLinuxでの実行結果について (その2)
投稿者:(ぱ)こと管理人
2009/11/18 02:59:27

>UTF-8版がエラーとなり、 >EUC版がうまくいったのはたまたまLANG環境変数が一致したからですか? たまたまというか、たいていのLinux環境はEUCかUTF-8のどちらかであり、 それに対応するためにふたつの配布パッケージを用意しているわけです。 ところで青餓鬼さんにお願いですが、この掲示板で誰かの投稿に返信する際は、 「新規投稿」リンクではなく、対象の投稿の「返信」リンク(右上にあります)を 使っていただけないでしょうか。 「スレッド順インデックス」で見たときに、応答の流れが見えますので。 http://kmaebashi.com/bbs/thread.php?boardid=kmaebashibbs
[この投稿を含むスレッドを表示] [この投稿を削除]
[1471] Re:DIKSAM_book_0_4のLinuxでの実行結果について (その2)
投稿者:yuya
2009/11/18 01:13:48

こちらはVineLinuxでLANG環境変数がja_JP.UTF-8な環境で試してみました。 ちょうど青餓鬼さんと逆に、test.dkmはUTF版では正常動作し、EUC版では Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. アボートしました とのメッセージが出ました。当然といえば当然の結果ですね。 これは納得が行きましたが、あとは青餓鬼さんが前に書いていたMacの結果だけが気になりますね(文字コード以前に、素のバイト列のままだった)。 むし返すようで申し訳ないんですけど、Macでの環境変数LANGは何だったのか、 よければ教えてもらえませんか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1470] DIKSAM_book_0_4のLinuxでの実行結果について (その2)
投稿者:青餓鬼
2009/11/17 14:43:18

Vine Linuxでの echo $LANG の実行結果は ja_JP.eucJP でした。 UTF-8版がエラーとなり、 EUC版がうまくいったのはたまたまLANG環境変数が一致したからですか? 大変勉強になりました。 以上
[この投稿を含むスレッドを表示] [この投稿を削除]
[1469] Re:質問
投稿者:(ぱ)こと管理人
2009/11/17 03:22:16

>crowbar_book_0_1に、debubgフォルダとmemoryフォルダがあったのですが >これらは何のためのフォルダなのですか。 「高校生」さんが書籍版「プログラミング言語を作る」をお持ちなら、 92ページにディレクトリ構成の図があります。メモリ管理モジュール MEM(memoryフォルダ)の説明はp.92からありますし、デバッグ用モジュール DBG(debugフォルダ)の説明はp.96からです。 Web版なら、以下のページに説明があります。 http://kmaebashi.com/programmer/devlang/crowbar_0_1.html こちらにはdebugのほうの説明はないので補足すると、たとえば 以下のソースが例として挙げられると思います。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/22.html#57 >if (cond.type != CRB_BOOLEAN_VALUE) { > crb_runtime_error(statement->u.if_s.condition->line_number, > NOT_BOOLEAN_TYPE_ERR, MESSAGE_ARGUMENT_END); >} >DBG_assert(cond.type == CRB_BOOLEAN_VALUE, ("cond.type..%d", cond.type)); このDBG_assert()を通るときにはcond.typeは絶対にCRB_BOOLEAN_VALUEであるに 決まっているわけですが、万一なにかの思い違いでそうでなかったとき、 DBG_assert()はメッセージを2行吐いて異常終了します。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1468] 質問
投稿者:高校生
2009/11/16 11:28:34

crowbar_book_0_1に、debubgフォルダとmemoryフォルダがあったのですが これらは何のためのフォルダなのですか。 一通り見たのですが難しいです。 こんな質問ですみません、学校のレポートにまとめなければならないので...。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1467] Re:DIKSAM_book_0_4のLinuxでの実行結果について
投稿者:(ぱ)こと管理人
2009/11/15 21:32:30

>2.UTF-8版の場合 >次のようなメッセージを2回表示しアボートします。 > >Assertion Failure (WC_format != NULL) file .. error.c line .. 92 当方のUbuntu Linuxで再確認しましたが、正常動作しました。 確認ですが、この時のLANG環境変数の値は何になっているでしょうか? Linuxなら、LANG環境変数の値は「echo $LANG」で確認することができます。
[この投稿を含むスレッドを表示] [この投稿を削除]